Vai al contenuto

pfSense: rete, IP pubblici, porte, VPN

Fonte: pannello pfSense letto in sola lettura il 27/10/2026 (pagine di stato e configurazione); call del 19/10/2026 e del 28/10/2026; revisione scritta di Michele del 30/10/2026.

pfSense 2.8.1 (VM 101), uptime 117 giorni, pfBlockerNG attivo. Pannello: http://172.16.16.1/ (HTTP, raggiungibile dalla VPN).

Interfacce

Interfaccia Indirizzo Uso
WAN 185.31.66.187 + alias 185.31.66.185, 185.31.66.186 internet, gateway 185.31.66.1
LAN 170.10.0.1/24 VM su vmbr1
WG_VPN (tun_wg0, UDP 51420 su .186) 172.16.16.1/24 VPN degli impianti, 66 peer
WG_STS_CAVA (tun_wg1, UDP 51421) 171.16.16.1 site-to-site con la sede aziendale (Cava de' Tirreni), 1 peer con AllowedIPs 0.0.0.0/0

Gli uffici usano una VPN separata da quella dei clienti.

Uso degli IP pubblici

Logica (Michele, 28/10): ogni server fisico ha 3–4 IP pubblici assegnati alla rete, configurati come alias in Firewall → Virtual IPs. Le VM non hanno IP pubblici dedicati: i loro servizi si espongono con NAT sull'IP scelto. Non ci sono altri IP disponibili oltre a quelli elencati qui sotto.

IP Uso in entrata Uso in uscita
185.31.66.185 midserver prod (ServerIT): web, OME, SSH limitato ServerIT
185.31.66.186 FreePBX (SIP 5060/5160/5161, 8088/8089, RTP 10000–40000), endpoint WireGuard 51420. 80/443 liberi VPN, FreePBX, altre VM
185.31.66.187 Coolify dev (80, 443, OME dev) Coolify dev
185.31.66.229 host Proxmox (fuori da pfSense) —

NAT VPN → VM

IP VPN VM Note
172.16.16.253 170.10.0.108 ServerIT (prod) tutte le porte; è l'indirizzo che usano i box
172.16.16.252 170.10.0.107 Coolify dev
172.16.16.254 170.10.0.100 (VM 400, inutilizzata) fallback nel frontend di qAlarm

Cosa è esposto su internet verso la prod (185.31.66.185 → 170.10.0.108)

Porta Uso Valutazione
22 SSH limitato a 2 IP sorgente: ok
80, 443 Nginx Proxy Manager atteso
3333, 3334, 3478, 9999, 9000–10004 OME atteso
8080 (solo UDP) regola storica per il signaling il servizio ewelink è TCP: non raggiungibile
9090–9093 nessuno: sulla VM non ascolta niente regola morta, da rimuovere
1883, 6379, 8888 → 192.168.1.108 indirizzo inesistente regole morte, da rimuovere (diventerebbero un'esposizione se quell'IP venisse assegnato)

Non esposti da internet: MySQL 3306, Flask 5000, phpMyAdmin 7070, ewelink 8080/TCP, Redis, Mosquitto, NPM admin 81.

Regole della VPN

Confermato da Michele il 28/10: la rete non è segmentata, per scelta. Dall'ufficio qualsiasi PC raggiunge le macchine; le regole sono state aperte perché di volta in volta dovevano accedere persone diverse. Prima la rete era segmentata. Si può segmentare di nuovo, ma serve un elenco definito di chi deve accedere (dal 28/10: Lorenzo e Mattia).

Cosa limita oggi i box (Michele, 30/10)

  • Nella configurazione WireGuard di ogni box (il "certificato" del peer) gli AllowedIPs comprendono solo 172.16.16.1 (pfSense), 172.16.16.253 (ServerIT) e 172.16.16.254. Il box quindi instrada nel tunnel solo il traffico verso questi tre indirizzi: non manda nel tunnel traffico verso gli altri box né verso altre reti.
  • Le regole del firewall per i box sono sull'interfaccia WG_VPN, non sul gruppo di interfacce WireGuard.

Due limiti di questo assetto:

  • Gli AllowedIPs sono una configurazione del box, non del firewall: chi ha accesso amministrativo a un box può allargarli, e pfSense non lo impedisce se le sue regole lasciano passare tutto.
  • 172.16.16.253 è un NAT di tutte le porte di ServerIT: anche con gli AllowedIPs ristretti, un box raggiunge MySQL, Redis, phpMyAdmin ed ewelink del midserver, salvo regole su WG_VPN che lo impediscano. Anche il pannello di pfSense (172.16.16.1, HTTP) è nel perimetro raggiungibile.

Dettaglio delle regole lette il 27/10

Regole lette il 27/10: dopo alcune regole specifiche c'è un allow any → any, e il traffico WG_VPN → WG_VPN è consentito. La lettura del 27/10 attribuiva queste regole al gruppo WireGuard; secondo Michele le regole sono invece sull'interfaccia WG_VPN. Va riletto in quale scheda (Floating, gruppo WireGuard, interfaccia WG_VPN) si trova l'allow any → any e in che ordine viene valutato rispetto alle regole specifiche.

Nella call del 19/10 è stato detto che i clienti possono raggiungere solo midserver e server qAlarm. Gli AllowedIPs dei box spiegano in parte questa affermazione, ma non bloccano l'accesso alle porte interne di ServerIT. Cosa raggiunge davvero un box resta da verificare con la prova da un box (attività T0.4, MDM-005). Le regole vanno strette senza bloccare la sede di Cava, che deve continuare a raggiungere tutti i box.

Soluzione ideale

  • Il controllo è sul firewall, non solo sugli AllowedIPs dei box: su WG_VPN un box può aprire verso ServerIT solo midserver HTTP (5000) e MQTT (1883), più DNS/NTP se servono; tutto il resto da WG_VPN verso LAN, verso pfSense e verso WG_VPN è bloccato.
  • Cava (171.16.16.0/24) mantiene l'accesso ai box sulle porte che usa (RTSP, stream nginx, 5005, 1996, 2000, MQTT, web) e alla LAN per SIP, ewelink e midserver.
  • Il pannello di pfSense e l'accesso amministrativo alle VM sono raggiungibili solo da un elenco definito di persone (oggi Lorenzo e Mattia).

Cosa dobbiamo fare

  1. Rileggere le regole nelle schede Floating, WireGuard e WG_VPN e annotare dove sta l'allow any → any (T0.4, MDM-005). Serve per sapere su quale scheda intervenire.
  2. Prova da un box di test (comandi-verifica.md): annotare quali porte di ServerIT, pfSense e degli altri box risponde. Serve per misurare il problema reale, non quello dedotto dalle regole (T0.4, MDM-005).
  3. Scrivere la proposta di regole in questa pagina, separando box e Cava, e farla approvare (T0.4).
  4. Applicare le regole per gradi, con backup della configurazione e rollback, senza toccare gli AllowedIPs dei box (T10.5). Va fatto prima di considerare chiusa la messa in produzione.

Sede di Cava (171.16.16.0/24)

  • Tutto il traffico dal tunnel arriva da una sola sorgente, 171.16.16.100 (2.723 connessioni al 27/10), tradotta come 172.16.16.1 verso i box. È l'IP del peer WireGuard del firewall dell'ufficio di Cava (Michele, 30/10), cioè il punto di uscita della rete aziendale: anche i PC dei dipendenti collegati alla VPN aziendale (indirizzi 10.200.171.x) raggiungono i server di Netsons passando da qui. Dietro ci sono le postazioni della centrale, i PC dei dipendenti e il Raspberry di Michele.
  • Conseguenza: le prove di rete fatte da un PC aziendale non rappresentano quello che vede un box. Per le verifiche sulla VPN dei box si usa un box (comandi-verifica.md).
  • Cosa fa verso i box (porte spiegate da Michele il 30/10):
  • RTSP 8554/554 e porte 10101–10105 (video): su ogni box MDM Ubuntu è installato un nginx proxy (pannello sulla porta 81) con la funzione stream configurata su 554 e 10101–10105. Serve a raggiungere la porta dati degli NVR dei clienti quando il cloud del produttore non si può usare. È la voce di traffico più alta;
  • 5005: API del box usate per inserire/disinserire l'impianto e leggerne lo stato;
  • 1996: porta del vecchio sistema MDM di Marco Lucchese;
  • 2000: sistema di monitoraggio attivato sugli impianti GANZ, che rende disponibile una porta per il controllo;
  • MQTT, web.

Le porte 1996/2000 restano fuori scope (D15), ma vanno lasciate aperte da Cava verso i box. - Cosa fa verso la LAN: SIP verso FreePBX, watchdog ewelink, midserver. - Genera la maggior parte del traffico VPN (circa 98 TiB sulla regola Cava → VPN).

Peer WireGuard

  • 66 peer al 27/10: 60 attivi negli ultimi 5 minuti, 7 fermi da giorni o mesi.
  • Sono solo installazioni dei clienti (38 sul sistema MDM, le altre sul sistema vecchio): sulla VPN degli impianti non ci sono PC dei dipendenti, che passano dal tunnel di Cava (Michele, 30/10). Qualsiasi modifica alla VPN tocca tutti gli impianti.
  • Creazione di un nuovo peer: nuovo-peer-wireguard.md (chiavi dal client Windows, IP progressivo, PresharedKey generata su pfSense, fix del DNS su Ubuntu, controllo della VPN ogni 5 minuti).
  • La configurazione dei box usa come endpoint il nome receiver1.protexia24.com:51420, DNS 8.8.8.8 e MTU 1412.

Indirizzamento

170.10.0.0/24 e 171.16.16.0/24 non sono reti private (RFC 1918): sono range pubblici di altri, usati dietro NAT. Funziona, ma quegli indirizzi reali su internet non sono raggiungibili dalla nostra rete. Confermato da Michele il 30/10. Non cambiare ora; non estendere l'uso.

Rischi

  • pfSense è un punto critico unico (internet, VPN, tutti gli impianti).
  • Accesso amministrativo condiviso (utente admin), pannello in HTTP.
  • ~~Regole duplicate per FreePBX (WAN address e .186)~~: erano disattivate e dedicate al vecchio FreePBX; eliminate da Michele (30/10).