Kontrollera Sophos Firewall MTU och MSS vid VPN-problem

När en VPN-anslutning är upprättad men enskilda applikationer ändå hänger sig, tänker man ofta först på brandväggsregler, DNS eller motparten. Det är korrekt, men inte fullständigt. Vid stora paket, IPsec-overhead, PPPoE, SD-WAN eller ruttbaserade VPN kan även MTU och MSS vara orsaken.

Typiskt är ett felmönster som inte ser ut som en tydlig blockering: Ping fungerar, små webbsidor laddas, men filöverföringar avbryts, RDP fryser, HTTPS-inloggningar stannar eller VoIP blir instabilt. Artikeln placerar MTU- och MSS-frågor på Sophos Firewall utan att blint ändra värden eller bygga farliga shell-lösningar.

För grunderna i gränssnitt, zoner och XFRM passar först Konfigurera Sophos Firewall zoner och gränssnitt. Om en IPsec-tunnel inte alls upprättas eller ingen säkerhetsassociation är installerad, är Felsökning av Sophos Firewall IPsec VPN en bättre start.

Kort förklaring av MTU och MSS

MTU beskriver hur stort ett paket maximalt får vara på ett gränssnitt eller en väg. Om ett paket är större än vad vägen tillåter måste det fragmenteras eller så förkastas det. Vid VPN är detta särskilt relevant eftersom IPsec lägger till ytterligare headers.

MSS gäller TCP och beskriver hur stor nyttolasten i ett TCP-segment ska vara. Om MSS förblir för hög, trots att den faktiska vägen genom VPN, PPPoE eller andra överlägg är mindre, uppstår typiska TCP-problem: Återsändningar, stopp, långsamma anslutningar eller avbrott vid större datamängder.

Viktigt: MTU och MSS är inga justeringsvärden som man sätter lägre på måfå tills det fungerar. Båda värdena hör till vägen. Innan en ändring bör det vara klart vilket gränssnitt, vilken riktning, vilket protokoll och vilken tunnel som påverkas.

När man bör misstänka MTU eller MSS

MTU- och MSS-problem visar sig ofta bara vid vissa applikationer eller paketstorlekar.

Typiska indikationer:

VPN-tunnel är ansluten, men större nedladdningar eller uppladdningar hänger sig.
RDP, SMB, HTTPS, backup, ERP eller molnapplikationer fungerar bara delvis.
Små ICMP-tester fungerar, större dataöverföringar gör det inte.
VoIP eller konferensapplikationer är instabila endast över vissa VPN- eller SD-WAN-vägar.
Problemet påverkar endast PPPoE, en viss WAN, en ruttbaserad IPsec-sträcka eller ett XFRM-gränssnitt.
iPerf visar många återsändningar eller starkt varierande TCP-genomströmning.
Efter en leverantörsbyte, firmware-uppgradering, SD-WAN-ombyggnad eller VPN-migration uppstår plötsligt ett nytt felmönster.

Sådana symptom bevisar ännu inte ett MTU-problem. Ändå är de en bra anledning att inkludera MTU och MSS i analysen.

Inte förväxla med regel-, NAT- eller DNS-problem

MTU/MSS är oftast inte den första kontrollpunkten. Först bör det vara klart att trafiken i grunden tar den förväntade vägen. Annars justeras paketstorlekar, även om det egentligen är en regel, NAT, DNS eller returvägen som är fel.

Ingen trafik visas i Log Viewer: Loggning, klient-gateway, VLAN, rutt eller felaktigt testflöde.
Fel brandväggsregel-ID tillämpas: Regelordning, zon, källa, destination, tjänst eller användarmatchning.
NAT-regel-ID passar inte: NAT-ordning, originalfält, MASQ/SNAT/DNAT eller fel riktning.
Namn löses till en oväntad IP: DNS, Split DNS, FQDN-objekt, CDN eller IPv6.
Små och stora tester misslyckas lika: Regel, routing, NAT, målsystem eller motpart.
Endast stora överföringar hänger: Kontrollera MTU/MSS, fragmentering, Path-MTU-Discovery eller VPN-overhead.

För denna förkontroll passar Kontrollera orsaker till att Sophos Firewall-regel inte matchar, Använda Packet Capture i WebAdmin och Förstå NAT på Sophos Firewall. Först när regel, NAT, routing och DNS är rimliga, är det värt att verkligen följa MTU-/MSS-spåret.

Typiska platser på Sophos Firewall

På Sophos Firewall kan flera områden vara relevanta. Oftast påverkas inte hela brandväggen, utan en specifik väg.

WAN-gränssnitt: Leverantör, PPPoE, VLAN eller router framför kan minska den användbara paketstorleken.
XFRM-gränssnitt: Ruttbaserad IPsec skapar ytterligare overhead och behöver passande tunnel-MTU.
SD-WAN-rutt: En väg kan gå över annat WAN, MPLS eller VPN än förväntat.
Brandväggsregel: Säkerhetsfunktioner eller loggning hjälper vid avgränsning, men är inte själva MTU.
Motpart: Den andra brandväggen, moln-VPN eller leverantörssidan måste hantera samma väg korrekt.
Wi-Fi-gränssnitt: Sedan SFOS 22.0 MR1 nämner Sophos även MTU/MSS-justeringar för Wi-Fi-gränssnitt via CLI.

Vid ruttbaserad IPsec skapar Sophos Firewall XFRM-gränssnitt. XFRM-MTU-värden beräknas utifrån det fysiska gränssnittet och den maximala IPsec-overheaden och kan vid behov justeras. Detta är hjälpsamt, men ersätter inte en noggrann kontroll av den faktiska vägen.

Bevisa vägen först

Innan någon ändring bör man noggrant beskriva den berörda dataflödet. Annars optimerar man snabbt på fel gränssnitt.

Praktiska frågor:

Vilken käll-IP och destinations-IP påverkas?
Går trafiken över LAN, VLAN, WAN, XFRM, RED, SD-WAN eller fjärråtkomst-VPN?
Är endast en riktning påverkad eller båda?
Påverkar det TCP, UDP eller båda?
Fungerar små paket, men inte större överföringar?
Tillämpas verkligen den förväntade brandväggsregeln?
Finns det NAT, MASQ, TLS-inspektion, IPS eller applikationskontroll på vägen?
Har motparten en passande returväg?

För regel- och vägkontroll hjälper Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture. Vid NAT eller MASQ bör dessutom Förstå NAT på Sophos Firewall kontrolleras.

Diagnos med Log Viewer, Packet Capture och iPerf

Log Viewer visar om trafik tillåts eller förkastas. Den bevisar dock inte ensam om ett paket är för stort. För detta behöver man dessutom Packet Capture, reproducerbara tester och en tydlig tolkning.

Log Viewer

I Log Viewer kontrollera först:

Välj modul Firewall eller den berörda säkerhetsmodulen.
Filtrera på käll-IP, destinations-IP och tjänst.
Kontrollera vilken brandväggsregel som matchar.
Säkerställ att ingen drop-regel, fel zon eller fel NAT-regel är det egentliga problemet.

Om ingen trafik är synlig ligger problemet ofta före brandväggen, vid klient-gateway, VLAN, routing eller på motparten.

Packet Capture

Under Diagnostics > Tools > Packet capture kan man begränsa testet. En filter på exakt den berörda källan och destinationen är meningsfull. Därefter reproduceras ett enskilt test, till exempel ett HTTPS-anrop, en filöverföring eller en applikationsstart.

Viktigt är tolkningen:

Paket når inte brandväggen: Kontrollera klient, gateway, VLAN eller lokal routing.
Paket går in i tunneln, svar saknas: Kontrollera motpart, returväg eller fjärrbrandvägg.
Många återsändningar vid TCP: Kontrollera paketförlust, MTU/MSS, WAN-kvalitet eller överbelastning.
Små tester fungerar, stora överföringar hänger: Kontrollera MTU/MSS eller Path-MTU-Discovery.

För att använda verktyget passar Använda Packet Capture Tool i WebAdmin.

Testa paketstorlek med DF-bit

Ett ICMP-test med Don’t Fragment-biten satt kan hjälpa till att avgränsa användbar paketstorlek för en väg. Testet är inget fullständigt applikationsbevis, men visar ofta snabbt om stora paket fragmenteras eller släpps på vägen.

Viktigt: Den angivna paketstorleken är normalt ICMP-payload. Med IPv4 tillkommer 20 byte IP-header och 8 byte ICMP-header. En payload på 1472 motsvarar därför ungefär ett IPv4-paket på 1500 byte.

Exempel:

Windows:

ping -f -l 1472 <target-ip>

macOS:

ping -D -s 1472 <target-ip>

Linux:

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

Om testet med 1472 misslyckas kan payload minskas stegvis, till exempel 1464, 1452, 1412 eller lägre. Det viktiga är inte ett perfekt värde, utan skillnaden mellan fungerande och icke fungerande storlekar på exakt samma väg.

Dessa tester kan påverkas av ICMP-filter, leverantörer, cloud-gateways eller motparter. Kombinera dem därför alltid med Packet Capture, Log Viewer och ett verkligt applikationstest.

iPerf

iPerf är hjälpsamt när man kan mäta en sträcka reproducerbart. En egen iPerf-server på motparten är betydligt mer meningsfull än en offentlig iPerf-server. Om TCP-genomströmningen är låg och många återsändningar syns bör MTU/MSS kontrolleras tillsammans med WAN-kvalitet, CPU, motpart och säkerhetsfunktioner.

Proceduren finns i Felsökning av Sophos Firewall med iPerf och Speedtest.

Ändra värden endast målinriktat

Om misstanken är välgrundad bör ändringar vara små, dokumenterade och reversibla.

Innan en ändring:

dokumentera aktuellt värde
notera berört gränssnitt och berörd tunnel
välj underhållsfönster eller kontrollerad testtidpunkt
ändra endast ett värde per test
genomför före-/efter-test med samma applikation
informera motparten om ett site-to-site-VPN påverkas

Vid ruttbaserade VPN bör först XFRM-gränssnittet och den tillhörande IPsec-anslutningen kontrolleras. Vid PPPoE eller leverantörsöverlägg är ofta WAN-gränssnittet eller leverantörsvägen den avgörande punkten. Vid SD-WAN måste det dessutom vara klart vilken gateway- eller VPN-väg som verkligen används. Artikeln SD-WAN-routing för svarspaket och systemtrafik hjälper till att placera SD-WAN-vägar.

⚠️ Använd inte permanenta shell-hack. Direkt paketmanipulation via Advanced Shell, odokumenterade startskript eller spontana paketfilterregler är ingen ren lösning för produktiva brandväggar. Först bör de stödda Sophos Firewall-funktionerna kontrolleras.

Vad man bör undvika

Dessa mönster orsakar i praktiken mer skada än nytta:

Sätta MSS generellt mycket lågt för alla nätverk.
Ändra MTU-värden utan före-/efter-test.
Testa endast en riktning och dra slutsatser om hela VPN-vägen.
Använda shell-lösningar istället för WebAdmin- eller dokumenterade Device Console-funktioner.
Ignorera motparten, även om returvägen eller deras MSS-klämning kan vara inblandad.
Anta MTU/MSS som orsak, även om brandväggsregel, NAT, routing eller DNS inte har kontrollerats.
Låta debug-loggar eller paketfångster köras länge och fylla lagringsutrymme.

Om det redan finns lokala skript eller paketmanipulationer bör man först läsa Sophos Firewall-skript utan Cronjob: Risker och alternativ och dokumentera den gamla lasten ordentligt.

Felsökningstabell

VPN grönt, stora överföringar hänger: MTU/MSS, returväg, säkerhetsfunktion. Packet Capture och iPerf med samma väg.
Endast PPPoE-WAN påverkat: Leverantörsväg eller WAN-MTU. Kontrollera WAN-gränssnitt, gateway och leverantörsangivelser.
Ruttbaserat VPN instabilt vid stora paket: XFRM-MTU eller SD-WAN-väg. Kontrollera XFRM-gränssnitt, IPsec-anslutning och rutt.
VoIP över VPN endast delvis stabilt: SD-WAN, returväg, paketförlust, MTU. Kontrollera SIP/RTP-väg, SD-WAN-rutt och fångst.
TCP mycket långsamt, UDP normalt: MSS, återsändningar, TCP-fönster, paketförlust. Testa iPerf TCP/UDP separat.
Små paket fungerar, stora inte: Path-MTU-Discovery eller fragmentering. Testa paketstorlekar medvetet och kontrollera motpart.

Checklista

Kontrollera omedelbart:

Dokumenterad berörd källa, destination, tjänst och riktning.
Bekräftad brandväggsregel och NAT-regel i Log Viewer.
Genomfört Packet Capture med snäv filter.
Kontrollerad IPsec-status och byte-räknare om ett VPN är inblandat.
Kontrollerad motpart och returväg.

Om MTU/MSS är sannolikt:

Identifierad berörd gränssnitts- eller XFRM-plats.
Dokumenterat aktuellt MTU-/MSS-värde.
Planerat endast en ändring per test.
Fastställt testapplikation och jämförelsevärde.
Samordnat ändring med motpart om site-to-site-VPN påverkas.

Efter ändringen:

Testa samma applikation igen.
Jämför Log Viewer, Packet Capture eller iPerf.
Dokumentera nya värden och motivering.
Kontrollera övervakning de närmaste dagarna.

FAQ

Är MTU samma som MSS?

Nej. MTU gäller den maximala paketstorleken på ett gränssnitt eller en väg. MSS gäller TCP-nyttolasten per segment. De hänger ihop, men är inte samma sak.

Varför fungerar Ping, men inte HTTPS eller RDP?

Små tester kan fungera, även om större TCP-segment senare orsakar problem. Därför räcker inte en enkel ping som bevis på att hela vägen är frisk.

Måste man ändra MTU vid varje VPN?

Nej. Många VPN fungerar rent med standardvärden. En ändring är först meningsfull när den berörda vägen och felmönstret talar för det.

Vad är speciellt med XFRM-gränssnitt?

XFRM-gränssnitt hör till ruttbaserade IPsec VPN. Sophos Firewall skapar dem automatiskt i samband med IPsec-anslutningen. Vid ruttbaserade VPN bestämmer rutter, brandväggsregler och XFRM-gränssnitt tillsammans vart trafiken går.

Bör man tvinga MSS via Shell?

För normal drift nej. Shell-baserad paketmanipulation är svår att underhålla och kan efter uppdateringar, återställning eller HA-felövergång oväntat försvinna eller verka felaktigt. Stödda brandväggsfunktioner är att föredra.