Kontrollera MTU och MSS i Sophos Firewall vid VPN-problem

Ett typiskt MTU-/MSS-problem ser inte ut som en tydlig blockering: VPN-tunneln är ansluten och ping fungerar, men nedladdningar avbryts, RDP fryser eller HTTPS-inloggningar fastnar. Orsaken kan vara den mindre användbara paketstorleken på vägen via IPsec, PPPoE, XFRM eller SD-WAN.

Om tunneln inte alls upprättas eller om det saknas en säkerhetsassociation bör man först använda Felsökning av IPsec VPN i Sophos Firewall. För gränssnittstyper och XFRM hjälper Konfigurera zoner och gränssnitt i Sophos Firewall.

Snabbdiagnos: påvisa ett MTU- eller MSS-problem

1. Bekräfta förväntat Firewall Rule ID i Log Viewer och, om NAT används på vägen, även NAT Rule ID. Om trafiken saknas helt eller fel regler tillämpas ska routing, zon, NAT eller DNS korrigeras först.
2. Notera Source, Destination, Service, riktning, TCP/UDP och den faktiska vägen via LAN, VLAN, WAN, XFRM, RED, SD-WAN eller Remote Access VPN.
3. Visa och dokumentera aktuell MTU och MSS på det berörda gränssnittet.
4. Genomför ett DF-test, en snävt filtrerad Packet Capture och samma verkliga applikationstest.
5. Ändra ett värde endast om det går att reproducera en skillnad mellan små och stora paket. Upprepa därefter exakt samma test.

Den allmänna regelkontrollen beskrivs i Testa en brandväggsregel med Log Viewer, Policy Test och Packet Capture. Vid ett avvikande NAT Rule ID hjälper Förstå NAT i Sophos Firewall.

Testa paketstorleken med DF-bit

För IPv4 tillkommer 20 byte IP-header och 8 byte ICMP-header utöver ICMP-nyttolasten. En nyttolast på 1472 motsvarar därför ett paket på ungefär 1500 byte.

Windows:

ping -f -l 1472 <target-ip>

macOS:

ping -D -s 1472 <target-ip>

Linux:

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

Om 1472 misslyckas minskas nyttolasten stegvis till 1464, 1452, 1412 eller mindre. Dokumentera både den fungerande och den felande storleken. ICMP-filter, internetleverantören, molngatewayer eller motparten kan påverka resultatet. DF-testet ersätter därför varken Packet Capture eller applikationstestet.

Bedöm MTU, MSS och den berörda vägen

MTU är den maximala paketstorleken för ett gränssnitt eller en väg. Större paket fragmenteras eller förkastas. MSS begränsar TCP-nyttolasten per segment. Om värdet förblir för högt trots overhead från VPN eller internetleverantör uppstår omsändningar, stopp och avbrott vid större datamängder.

MTU och MSS är inga allmänna justeringsvärden. Det är den konkreta vägen som är relevant:

• WAN, PPPoE eller VLAN: internetleverantören, en router eller en extra header minskar den användbara paketstorleken.
• XFRM: ruttbaserad IPsec skapar overhead; rutter, regler och XFRM-gränssnitt avgör tillsammans vägen.
• SD-WAN: ett flöde kan använda ett annat WAN, MPLS eller VPN än förväntat. Valet av väg beskrivs i SD-WAN-routing för svarspaket och systemtrafik.
• Motpart: returväg, fjärrbrandvägg, Cloud VPN och MSS Clamping måste passa den testade riktningen.
• Wi-Fi: sedan SFOS 22.0 MR1 kan MTU och MSS för befintliga Wi-Fi-gränssnitt ändras med de dokumenterade CLI-kommandona.

Misstänkta symptom är stora nedladdningar eller uppladdningar, RDP, SMB, HTTPS, säkerhetskopieringar, ERP, moln- och konferensapplikationer eller VoIP som bara slutar fungera över en viss VPN- eller SD-WAN-väg. Många omsändningar i iPerf, kraftigt varierande TCP-genomströmning eller ett fel direkt efter byte av internetleverantör, firmwareuppgradering, ombyggnad av SD-WAN eller VPN-migrering passar också in. Om små och stora tester misslyckas på samma sätt är regel, NAT, routing, DNS, målsystem eller returväg mer sannolika orsaker.

Kontrollera dataflödet med Log Viewer, Packet Capture och iPerf

Uteslut problem med regler, NAT och DNS

• Ingen trafik i Log Viewer: kontrollera klientgateway, VLAN, rutt, loggning och testflöde.
• Fel Firewall Rule ID: kontrollera ordning, zon, Source, Destination, Service och User Matching. Fler orsaker finns i Brandväggsregeln i Sophos Firewall matchar inte.
• Fel NAT Rule ID: kontrollera ordning, Original-fält, MASQ, SNAT, DNAT och riktning.
• Oväntad destinations-IP: kontrollera DNS, Split DNS, FQDN-objekt, CDN och IPv6.

Om VPN används ska även tunnelstatus och byte-räknare kontrolleras. Dokumentera TLS Inspection, IPS och Application Control så att testerna före och efter ändringen verkligen jämför samma väg och samma säkerhetsfunktioner.

Analysera Packet Capture

Under Diagnostics > Tools > Packet capture filtrerar man på berörd Source och Destination och reproducerar exakt ett HTTPS-anrop, en överföring eller en applikationsstart:

• Om paketen inte kommer fram ligger felet oftast hos klienten, gatewayen, VLAN eller lokal routing.
• Om paketen går in i tunneln men svar saknas ska motparten och returvägen kontrolleras.
• Många TCP-omsändningar tyder på paketförlust, MTU/MSS, WAN-kvalitet eller överbelastning.
• Om små tester fungerar men stora överföringar inte gör det ska Path MTU Discovery och fragmentering kontrolleras.

Användningen beskrivs i Använd Packet Capture i WebAdmin. Kör Packet Capture och aktiverade felsökningsloggar bara så länge som behövs, så att de inte tar upp onödigt lagringsutrymme.

Jämför iPerf med ett applikationstest

En dedikerad iPerf-server hos motparten ger mer relevanta resultat än en offentlig server. Testa TCP och UDP separat och bedöm låg TCP-genomströmning eller omsändningar tillsammans med WAN-kvalitet, CPU, motpart och säkerhetsfunktioner. Hela förloppet beskrivs i Felsök Sophos Firewall med iPerf och Speedtest.

Visa eller ändra MTU och MSS

WebAdmin och XFRM

Redigera det berörda gränssnittet under Network > Interfaces och öppna Advanced settings > Interface settings. Där finns MTU och Override MSS. XFRM-gränssnitt visas under sitt fysiska Listening Interface.

Sophos Firewall beräknar som standard XFRM-MTU utifrån MTU för Listening Interface och maximal IPsec-overhead. Om XFRM-MTU ändras manuellt måste den vara minst 113 byte mindre än MTU för Listening Interface. Om Listening Interface har 1400 byte får XFRM vara högst 1287 byte. Marginalen förhindrar paketförlust vid FastPath Offload när SSL/TLS-dekryptering används på IPsec-trafik.

Kontrollera värden i Device Console

Logga in via SSH, välj 4. Device Console i huvudmenyn och ange gränssnitts-ID:

show mtu-mss Port2

För fysiska gränssnitt dokumenterar Sophos följande syntax för ändringen:

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

Räkneexempel: om den verifierade MTU:n för IPv4-vägen är 1492 byte blir TCP-MSS utan ytterligare alternativ 1452 byte (1492 - 20 - 20). Det är varken ett allmänt SFOS-standardvärde eller en generell rekommendation för det fysiska PPPoE-gränssnittet.

⚠️ En ändring påverkar pågående trafik och kan avbryta SSH- eller WebAdmin-anslutningen. Den bör inte utföras via den enda hanteringsanslutningen på det berörda gränssnittet. Det måste finnas en lokal eller Out-of-Band reservåtkomst. Port2 är bara ett exempel och måste ersättas med ID:t för det gränssnitt som faktiskt har kontrollerats.

Spara de visade värdena i förväg. default ställer in Sophos dokumenterade produktstandardvärden, MTU 1500 och MSS 1460:

set network mtu-mss Port2 mtu default mss default

Det är endast en återställning om dessa värden var aktiva före ändringen. I annat fall måste utgångsvärdena som dokumenterades med show mtu-mss återställas uttryckligen.

Verifiera ändringen

• dokumentera berört gränssnitt, tunnel och utgångsvärden;
• välj ett underhållsfönster eller en kontrollerad testtidpunkt;
• gör bara en ändring per test;
• informera motparten vid site-to-site-VPN;
• kontrollera efter ändring och återställning med show mtu-mss Port2 att de förväntade värdena är aktiva;
• upprepa samma DF-, Packet Capture-, iPerf- och applikationstest;
• dokumentera nya värden, motivering och resultat;
• kontrollera övervakningen under de följande dagarna.

⚠️ Använd inga permanenta Advanced Shell-hack, startskript eller spontana paketfilterregler. De är svåra att underhålla och kan fungera felaktigt eller försvinna efter uppdatering, återställning eller HA-failover. Om sådana äldre lösningar finns hjälper Sophos Firewall-skript utan Cronjob: risker och alternativ.

Sänk inte MSS kraftigt för alla nätverk, testa aldrig bara en riktning och ignorera inte motparten. Om ett kontrollerat test inte ger någon förbättring ska det dokumenterade utgångsvärdet återställas.

Felsökning efter symptom

• VPN är aktivt men stora överföringar hänger: kontrollera MTU/MSS, returväg eller säkerhetsfunktion med Packet Capture och iPerf på samma väg.
• Endast PPPoE-WAN påverkas: kontrollera WAN-gränssnitt, gateway, leverantörsuppgifter och användbar paketstorlek.
• Ruttbaserat VPN är instabilt med stora paket: kontrollera XFRM-gränssnitt, IPsec-anslutning, rutt och 113-byte-regeln.
• VoIP över VPN är instabilt: kontrollera SIP-/RTP-väg, SD-WAN-rutt, returväg, paketförlust och Packet Capture.
• TCP är mycket långsamt, UDP normalt: kontrollera MSS, omsändningar, TCP-fönster och paketförlust med separata iPerf-tester.
• Små paket fungerar men stora gör det inte: dokumentera DF-testet och kontrollera Path MTU Discovery, fragmentering och motpart.

FAQ