Problema port forwarding su VPN

[lonewolf]

Salve, ho cambiato firewall e sono passato da un OpenBSD (pf) configurato a mano su una Alix (che su una 100Mbps fa quel che può, in VPN pochi MBps) a una APU con pfSense 2.5.

Ho questa situazione: ho una connessione Eolo e una Wind 4G di backup. Prima di Eolo avevo un fornitore sfigato e la connessione andava giù spesso. La mia necessità è continuare a poter ricevere posta (con un server personale), potermi connettere in VPN a casa se sono fuori. Questo sempre, anche in caso sia in uso la connessione di backup.

Ho quindi un VPS con IP pubblico, server OpenVPN, port forwarding verso l'IP del client VPN.

A casa c'è il firewall con le due connessioni (Default gateway IPv4 MULTIWAN, che è un gruppo di gateways delle due connessioni), NAT Outbound con indirizzi NAT quelli delle connessioni (per uscire su Internet) e quelli dei client VPN (per "uscire" verso le VPN dalla LAN). Infine i port forwarding (con rispettive regole di firewall che vengono già automaticamente generate) da Eolo verso un server in DMZ e da VPN verso lo stesso server.

Queste sono le parti salienti della configurazione:

I port forwarding da Eolo funzionano perfettamente, quelli dalla VPN no. Nel dettaglio, il SYN arriva al server qui in DMZ, lui risponde col SACK... il SACK torna indietro peraltro instradato correttamente attraverso la VPN... peccato che mi arrivi con IP sorgente del server in DMZ! C'è qualcosa che non mi torna, per forza che non funziona! Sul server VPN mi aspettavo che le risposte tornassero con IP sorgente 10.0.50.11.

VPS pubblico cloud (server OpenVPN):

Server DMZ a casa:

PS: Giusto se a qualcuno venisse il dubbio che "così non può funzionare", con un il precedente fw funzionava, con pf configurato a mano. Se proprio non dovessi uscirne, toccherà tornare alla precedente situazione (ci va un po di tempo quindi non lo faccio solo per fare i tcpdump).

[kiokoman]

@lonewolf
hai la versione 2.5.0 o 2.5.1 di specifico?
nella 2.5.0 dovrebbe funzionare, nella 2.5.1 c'e' attualmente un bug in fase di risoluzione per le multiwan
eventualmente verifica anche Firewall NAT Outbound se è tutto ok
pfsense ha la funzione reply-to abilitata di default se non è il bug del 2.5.1 quella configurazione dovrebbe sicuramente funzionare senza problemi

[lonewolf]

@kiokoman said in Problema port forwarding su VPN:

@lonewolf
hai la versione 2.5.0 o 2.5.1 di specifico?
nella 2.5.0 dovrebbe funzionare, nella 2.5.1 c'e' attualmente un bug in fase di risoluzione per le multiwan
eventualmente verifica anche Firewall NAT Outbound se è tutto ok
pfsense ha la funzione reply-to abilitata di default se non è il bug del 2.5.1 quella configurazione dovrebbe sicuramente funzionare senza problemi

Giusta domanda. Ho installato la 2.5.0, solo che ho visto subito l'aggiornamento alla 2.5.1....... e visto che solitamente ci sono bug fix, stupidamente l'ho fatto Non pensavo introducessero bug (ne eliminassero tout cour delle feature, ad esempio ho notato che è sparito Wireguard, che per fortuna non uso).
Comunque sia, giusto per togliermi il dubbio ho provato a impostare direttamente Eolo come unico gateway, ma non cambia nulla. Indietro non si può tornare, a meno di non reinstallare tutto.
Il firewall Outbound in realtà funziona, problemi a uscire su Internet non ne ho, ne a usare l'altra VPN per lo smart working. Anche il NAT Outbound su IPv6 da ULA funziona perfettamente.
Conviene attendere una 2.5.2 (purché non sia "aspetta e spera" ) o c'è qualche workaround?

Non c'entra nulla ma ho notato cose piuttosto antipatiche se può essere utile segnalarle. Uso anche FRR e la prima cosa che ho notato nel translare la vecchia configurazione (in quel caso da file di configurazione OpenOSPFD) su pfSense è l'assenza della default route (Redistribute a Default route to neighbors) in OSPF6 di FRR, cosa però prevista da FRR se configurato a mano (default-information originate). Si può ovviare attivando la redistribuzione delle pfSense Kernel Routes... però... non è la stessa cosa )
Mentre in OSPF c'è la Redistribute a Default route to neighbors e funziona... ma non funziona FRR Static Routes, le statiche configurate sui Global settings non funzionano, vengono totalmente ignorate. Il workaround in questo caso è configurare le rotte tramite il routing di base di pfSense e poi anche in questo caso redistribuire pfSense Kernel Routes........ però non è un bella cosa, non dovrebbe funzionare così...

[kiokoman]

@lonewolf
no, la risoluzione del problema arriverà sicuramente in tempi brevi dato che c'e' mezzo forum che lo ha riscontrato, non dico domani ma sicuramente nelle prossime settimane.
se ti scarichi un backup della configurazione, reinstalli la 2.5.0 e ripristini il backup in 5 / 10 minuti hai risolto se il problema era quello

wireguard è stato rimosso per motivi di sicurezza, è stato rimosso anche da freebsd, ritonerà non appena i problemi saranno risolti, credo minimo un annetto ci vorrà comunque

[lonewolf]

@kiokoman said in Problema port forwarding su VPN:

@lonewolf
no, la risoluzione del problema arriverà sicuramente in tempi brevi dato che c'e' mezzo forum che lo ha riscontrato, non dico domani ma sicuramente nelle prossime settimane.
se ti scarichi un backup della configurazione, reinstalli la 2.5.0 e ripristini il backup in 5 / 10 minuti hai risolto se il problema era quello

Certo che potrei fare così, mi secca però! Dovrei scollegare tutto, smontare il coperto della APU per estrarre la SD, fare di nuovo il dd dell'immagine, rimontare e ricollegare tutto, collegarmi col cavo seriale... sarebbero ore perse...
Comunque se farò così o se aspetterò la 2.5.2 aggiornerò il topic con la conferma - spero - dell'avvenuta risoluzione del problema (spero!).
Grazie mille per la pazienza :)

[lonewolf]

So che vado OT, ma ho visto un'altra cosa che sinceramente "anche no"

/etc/inc/filter.inc

                        /* different size of IPv4/IPv6 header, https://redmine.pfsense.org/issues/11409 */
                        $mssclamp4 = "max-mss " . (intval($scrubcfg['mss'] - 40));
                        $mssclamp6 = "max-mss " . (intval($scrubcfg['mss'] - 60));

E infatti setto MTU 1492 MSS 1452... nelle regole mi trovo:

scrub on pppoe0 inet all max-mss 1412 fragment reassemble
scrub on pppoe0 inet6 all max-mss 1392 fragment reassemble

...ma io ho chiesto 1452 o 1412?!?! Giusto quel ticket, giusto differenziare fra IPv4 e IPv6... salvo però: 1) capire se IPv6 è abilitato su quella interfaccia (non lo è, quindi lo scrub su IPv6 è "di troppo") 2) perché -40?!!?
-40 sarebbe anche corretto, ma rispetto a MTU! Non rispetto al valore impostato manualmente del MSS!

[kiokoman]

@lonewolf
mi sembra giusto, quelloe' il valore calcolato per scrub non per l'interfaccia

[lonewolf]

@kiokoman said in Problema port forwarding su VPN:

@lonewolf
mi sembra giusto, quelloe' il valore calcolato per scrub non per l'interfaccia

...cosa mi sfugge? Per favore, avresti voglia di spiegarmi meglio? Che differenza c'è fra le due cose?

[kiokoman]

@lonewolf
c'e' anche scritto sulla descrizione del campo MSS,
tcp/ip header size =40 per ipv4 e 60 per ipv6

If a value is entered in this field, then MSS clamping for TCP connections to the value entered above minus 40 (TCP/IP header size) will be in effect.

MSS = maximum segment size
il termine è ingannevole
max-mss = maximum amount of data a segment can hold and does not include the TCP headers

questo significa che se MSS=1452 la dimensione massima di un segmento potrebbe arrivare a 1472 (con TCP header) o anche maggiore (in base a quante opzioni TCP sono incluse). creando frammentazione, di conseguenza mss-max viene calcolato con MSS - 40

[lonewolf]

@kiokoman grazie mille per la delucidazione!
Mi sono messo li a perdere mezza serata, comunque ho reinstallato e confermo che il downgrade alla 2.5.0 risolve il problema del port forwarding su VPN!