Controllare MTU e MSS su Sophos Firewall in caso di problemi VPN

Un tipico problema di MTU o MSS non si presenta come un blocco evidente: il tunnel VPN è connesso e il ping funziona, ma i download si interrompono, RDP si blocca o gli accessi HTTPS rimangono in sospeso. La causa può essere la minore dimensione utile del percorso dovuta a IPsec, PPPoE, XFRM o SD-WAN.

Se il tunnel non si stabilisce o non è presente alcuna Security Association, consultare prima Risoluzione dei problemi IPsec VPN su Sophos Firewall. Per i tipi di interfaccia e XFRM, vedere Configurare zone e interfacce su Sophos Firewall.

Diagnosi rapida: dimostrare un problema di MTU o MSS

1. Nel Log Viewer verificare la Firewall Rule ID prevista e, se il NAT è coinvolto nel percorso, la NAT Rule ID. Se il traffico non compare o vengono applicate regole errate, correggere prima routing, zona, NAT o DNS.
2. Annotare Source, Destination, Service, direzione, TCP/UDP e percorso effettivo attraverso LAN, VLAN, WAN, XFRM, RED, SD-WAN o Remote Access VPN.
3. Visualizzare e documentare MTU e MSS correnti dell’interfaccia interessata.
4. Eseguire un test DF, un Packet Capture con filtro preciso e lo stesso test applicativo reale.
5. Modificare un valore solo se esiste una differenza riproducibile tra pacchetti piccoli e grandi. Ripetere poi esattamente lo stesso test.

La procedura generale è descritta in Testare una regola firewall con Log Viewer, Policy Test e Packet Capture. Se la NAT Rule ID non corrisponde, vedere Comprendere NAT su Sophos Firewall.

Testare la dimensione dei pacchetti con il bit DF

In IPv4, al payload ICMP si aggiungono 20 byte di intestazione IP e 8 byte di intestazione ICMP. Un payload di 1472 corrisponde quindi a un pacchetto di circa 1500 byte.

Windows:

ping -f -l 1472 <target-ip>

macOS:

ping -D -s 1472 <target-ip>

Linux:

ping -M do -s 1472 <target-ip>

Se 1472 non funziona, ridurre gradualmente il payload a 1464, 1452, 1412 o meno. Documentare sia la dimensione che funziona sia quella che non funziona. Filtri ICMP, provider, gateway cloud o il lato remoto possono falsare il risultato; il test DF non sostituisce quindi né il Packet Capture né il test applicativo.

Inquadrare MTU, MSS e il percorso interessato

La MTU è la dimensione massima dei pacchetti su un’interfaccia o un percorso. I pacchetti più grandi vengono frammentati o scartati. La MSS limita il payload TCP per segmento. Se rimane troppo alta nonostante l’overhead della VPN o del provider, si verificano ritrasmissioni, stalli e interruzioni con volumi di dati maggiori.

MTU e MSS non sono valori generici di ottimizzazione. Conta il percorso concreto:

• WAN, PPPoE o VLAN: il provider, un router o un’intestazione aggiuntiva possono ridurre la dimensione utile dei pacchetti.
• XFRM: IPsec route-based aggiunge overhead; route, regole e interfaccia XFRM determinano insieme il percorso.
• SD-WAN: un flusso può utilizzare una WAN, MPLS o VPN diversa da quella prevista. La selezione del percorso è descritta in Routing SD-WAN per pacchetti di risposta e traffico di sistema.
• Lato remoto: la route di ritorno, il firewall remoto, la VPN cloud e l’MSS clamping devono corrispondere alla direzione testata.
• Wi-Fi: da SFOS 22.0 MR1, MTU e MSS delle interfacce Wi-Fi esistenti possono essere modificati con i comandi CLI documentati.

Sono sospetti i download o gli upload di grandi dimensioni, RDP, SMB, HTTPS, backup, ERP, applicazioni cloud e di conferenza o VoIP che non funzionano solo su uno specifico percorso VPN o SD-WAN. Anche numerose ritrasmissioni in iPerf, un throughput TCP molto variabile o un errore comparso subito dopo un cambio di provider, un aggiornamento firmware, una modifica SD-WAN o una migrazione VPN sono segnali compatibili. Se i test piccoli e grandi falliscono allo stesso modo, sono più probabili regola, NAT, routing, DNS, sistema di destinazione o percorso di ritorno.

Verificare il flusso di dati con Log Viewer, Packet Capture e iPerf

Escludere regole, NAT e DNS

• Nessun traffico nel Log Viewer: controllare gateway del client, VLAN, route, logging e flusso di test.
• Firewall Rule ID errata: controllare ordine, zona, Source, Destination, Service e User Matching. Altre cause sono descritte in La regola Sophos Firewall non viene applicata.
• NAT Rule ID errata: controllare ordine, campi originali, MASQ, SNAT, DNAT e direzione.
• IP di destinazione inatteso: controllare DNS, Split DNS, oggetto FQDN, CDN e IPv6.

Se è coinvolta una VPN, controllare anche lo stato del tunnel e i contatori dei byte. Documentare TLS Inspection, IPS e Application Control affinché i test prima e dopo la modifica confrontino realmente lo stesso percorso e le stesse Security Features.

Valutare il Packet Capture

In Diagnostics > Tools > Packet capture, filtrare per Source e Destination interessate e riprodurre un solo accesso HTTPS, trasferimento o avvio dell’applicazione:

• Se i pacchetti non arrivano, il problema si trova in genere nel client, nel gateway, nella VLAN o nel routing locale.
• Se i pacchetti entrano nel tunnel ma non arrivano risposte, controllare il lato remoto e la route di ritorno.
• Numerose ritrasmissioni TCP indicano perdita di pacchetti, MTU/MSS, qualità WAN o sovraccarico.
• Se i test piccoli funzionano ma i trasferimenti grandi no, controllare Path MTU Discovery e frammentazione.

L’uso dello strumento è descritto in Utilizzare Packet Capture nel WebAdmin. Lasciare le catture e i log di debug attivati solo per il tempo necessario, evitando di occupare inutilmente spazio di archiviazione.

Confrontare iPerf con un test applicativo

Un server iPerf dedicato sul lato remoto è più significativo di un server pubblico. Testare TCP e UDP separatamente e valutare throughput TCP ridotto o ritrasmissioni insieme a qualità WAN, CPU, lato remoto e Security Features. La procedura completa è descritta in Risoluzione dei problemi su Sophos Firewall con iPerf e Speedtest.

Visualizzare o modificare MTU e MSS

WebAdmin e XFRM

In Network > Interfaces, modificare l’interfaccia interessata e aprire Advanced settings > Interface settings. Qui sono disponibili MTU e Override MSS. Le interfacce XFRM compaiono sotto la rispettiva interfaccia fisica di ascolto.

Sophos Firewall calcola per impostazione predefinita la MTU XFRM dalla MTU dell’interfaccia di ascolto e dall’overhead IPsec massimo. Se la MTU XFRM viene modificata manualmente, deve essere almeno 113 byte inferiore alla MTU dell’interfaccia di ascolto. Con 1400 byte sull’interfaccia di ascolto, per XFRM sono consentiti al massimo 1287 byte. Questa riserva evita la perdita di pacchetti durante l’offload FastPath quando al traffico IPsec viene applicata la decrittografia SSL/TLS.

Controllare i valori nella Device Console

Accedere tramite SSH, scegliere 4. Device Console nel menu principale e inserire l’ID dell’interfaccia:

show mtu-mss Port2

Per le interfacce fisiche, Sophos documenta la seguente sintassi di modifica:

set network mtu-mss <PortID> mtu <number|default> mss <number|default>

Esempio di calcolo: se la MTU IPv4 del percorso verificata è di 1492 byte, senza opzioni aggiuntive si ottiene una MSS TCP di 1452 byte (1492 - 20 - 20). Non si tratta né di un valore predefinito generale di SFOS né di una raccomandazione valida per qualsiasi interfaccia PPPoE fisica.

⚠️ Una modifica incide sul traffico attivo e può interrompere la connessione SSH o WebAdmin. Non deve essere eseguita tramite l’unica connessione di gestione dell’interfaccia interessata. Deve essere disponibile un accesso locale o out-of-band per il ripristino. Port2 è solo un esempio e deve essere sostituito con l’ID dell’interfaccia effettivamente verificata.

Salvare prima i valori visualizzati. default imposta i valori predefiniti del prodotto documentati da Sophos: MTU 1500 e MSS 1460:

set network mtu-mss Port2 mtu default mss default

Questo è un rollback solo se tali valori erano attivi prima della modifica. In caso contrario, ripristinare esplicitamente i valori iniziali documentati con show mtu-mss.

Verificare la modifica

• documentare l’interfaccia interessata, il tunnel e i valori iniziali;
• scegliere una finestra di manutenzione o un momento di test controllato;
• eseguire una sola modifica per ogni test;
• informare il lato remoto in caso di VPN site-to-site;
• dopo una modifica o un rollback, verificare con show mtu-mss Port2 che siano attivi i valori previsti;
• ripetere gli stessi test DF, Packet Capture, iPerf e applicativo;
• documentare i nuovi valori, la motivazione e il risultato;
• controllare il monitoraggio nei giorni successivi.

⚠️ Non utilizzare hack permanenti nell’Advanced Shell, script di avvio o regole improvvisate di filtraggio dei pacchetti. Sono difficili da gestire e possono funzionare in modo errato o scomparire dopo un aggiornamento, un ripristino o un failover HA. Se esistono configurazioni legacy di questo tipo, vedere Script su Sophos Firewall senza Cronjob: rischi e alternative.

Non ridurre drasticamente la MSS per tutte le reti, non testare mai una sola direzione e non ignorare il lato remoto. Se un test controllato non produce miglioramenti, ripristinare il valore iniziale documentato.

Risoluzione dei problemi per sintomo

• VPN attiva, trasferimenti grandi bloccati: controllare MTU/MSS, percorso di ritorno o Security Feature con Packet Capture e iPerf sullo stesso percorso.
• Solo la WAN PPPoE è interessata: controllare interfaccia WAN, gateway, dati del provider e dimensione utile dei pacchetti.
• VPN route-based instabile con pacchetti grandi: controllare interfaccia XFRM, connessione IPsec, route e regola dei 113 byte.
• VoIP instabile sulla VPN: controllare percorso SIP/RTP, route SD-WAN, percorso di ritorno, perdita di pacchetti e cattura.
• TCP molto lento, UDP normale: controllare MSS, ritrasmissioni, finestra TCP e perdita di pacchetti con test iPerf separati.
• I pacchetti piccoli funzionano, quelli grandi no: documentare il test DF e controllare Path MTU Discovery, frammentazione e lato remoto.

FAQ