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.

Observation	Först mer sannolikt än MTU/MSS
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.

Område	Varför relevant
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:

Observation	Betydelse
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.

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

Symptom	Troligare område	Nästa kontroll
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.