Controleer MTU en MSS van Sophos Firewall bij VPN-problemen
Wanneer een VPN-verbinding tot stand is gebracht, maar afzonderlijke toepassingen toch vastlopen, wordt vaak eerst gedacht aan firewallregels, DNS of de tegenpartij. Dat is juist, maar niet volledig. Bij grote pakketten, IPsec-overhead, PPPoE, SD-WAN of route-based VPN’s kunnen ook MTU en MSS de oorzaak zijn.
Typisch is een foutbeeld dat er niet uitziet als een duidelijke blokkade: Ping werkt, kleine webpagina’s laden, maar bestandsoverdrachten worden onderbroken, RDP bevriest, HTTPS-aanmeldingen blijven hangen of VoIP wordt instabiel. Het artikel plaatst MTU- en MSS-onderwerpen in de context van Sophos Firewall, zonder blind waarden te wijzigen of gevaarlijke shell-workarounds te bouwen.
Voor de basisprincipes van interfaces, zones en XFRM past eerst Sophos Firewall zones en interfaces configureren. Als een IPsec-tunnel helemaal niet tot stand komt of er geen Security Association is geïnstalleerd, is Sophos Firewall IPsec VPN Troubleshooting een betere start.
MTU en MSS kort uitgelegd
De MTU beschrijft hoe groot een pakket maximaal mag zijn op een interface of pad. Als een pakket groter is dan het pad toestaat, moet het gefragmenteerd worden of wordt het verworpen. Bij VPN’s is dit bijzonder relevant, omdat IPsec extra headers toevoegt.
De MSS betreft TCP en beschrijft hoe groot het datadeel van een TCP-segment moet zijn. Als de MSS te hoog blijft, hoewel het werkelijke pad door VPN, PPPoE of andere overlays kleiner is, ontstaan typische TCP-problemen: retransmits, stalls, trage verbindingen of verbindingsonderbrekingen bij grotere hoeveelheden data.
Belangrijk: MTU en MSS zijn geen afstemmingswaarden die je willekeurig kleiner maakt totdat het op de een of andere manier werkt. Beide waarden behoren tot het pad. Voor een wijziging moet duidelijk zijn welk interface, welke richting, welk protocol en welke tunnel betrokken zijn.
Wanneer MTU of MSS verdacht zou moeten worden
MTU- en MSS-problemen komen vaak alleen voor bij bepaalde toepassingen of pakketgroottes.
Typische aanwijzingen:
- VPN-tunnel is verbonden, maar grotere downloads of uploads blijven hangen.
- RDP, SMB, HTTPS, back-up, ERP of cloudtoepassingen werken slechts gedeeltelijk.
- Kleine ICMP-tests werken, grotere gegevensoverdrachten niet.
- VoIP of conferentietoepassingen zijn alleen over bepaalde VPN- of SD-WAN-paden instabiel.
- Het probleem betreft alleen PPPoE, een specifiek WAN, een route-based IPsec-traject of een XFRM-interface.
- iPerf toont veel retransmits of sterk schommelende TCP-doorvoer.
- Na een providerwissel, firmware-upgrade, SD-WAN-herstructurering of VPN-migratie verschijnt plotseling een nieuw foutbeeld.
Dergelijke symptomen bewijzen nog geen MTU-probleem. Toch zijn ze een goede reden om MTU en MSS in de analyse op te nemen.
Niet verwarren met regel-, NAT- of DNS-problemen
MTU/MSS is meestal niet het eerste controlepunt. Eerst moet duidelijk zijn dat het verkeer in principe het verwachte pad volgt. Anders wordt er aan pakketgroottes gesleuteld, terwijl eigenlijk een regel, NAT, DNS of de terugweg verkeerd is.
| Observatie | Eerst waarschijnlijker dan MTU/MSS |
|---|---|
| In de Log Viewer verschijnt helemaal geen verkeer | Logging, client-gateway, VLAN, route of verkeerde testflow |
| De verkeerde Firewall Rule ID grijpt | Regelvolgorde, zone, bron, bestemming, service of gebruikersmatching |
| NAT Rule ID past niet | NAT-volgorde, originele velden, MASQ/SNAT/DNAT of verkeerde richting |
| Naam lost op naar een onverwacht IP | DNS, Split DNS, FQDN-object, CDN of IPv6 |
| Kleine en grote tests mislukken gelijk | Regel, routing, NAT, doelsysteem of tegenpartij |
| Alleen grote overdrachten hangen | MTU/MSS, fragmentatie, Path-MTU-Discovery of VPN-overhead controleren |
Voor deze voorcontrole passen Sophos Firewall regel grijpt niet: oorzaken controleren, Packet Capture in WebAdmin gebruiken en NAT op Sophos Firewall begrijpen. Pas als regel, NAT, routing en DNS plausibel zijn, loont het zich om de MTU-/MSS-spoor echt te volgen.
Typische plaatsen op Sophos Firewall
Op Sophos Firewall kunnen meerdere gebieden relevant zijn. Meestal is niet de hele firewall betrokken, maar een specifiek pad.
| Gebied | Waarom relevant |
|---|---|
| WAN-interface | Provider, PPPoE, VLAN of router ervoor kunnen de bruikbare pakketgrootte verminderen |
| XFRM-interface | Route-based IPsec genereert extra overhead en heeft een passende tunnel-MTU nodig |
| SD-WAN Route | Een pad kan over een ander WAN, MPLS of VPN lopen dan verwacht |
| Firewall-regel | Beveiligingsfuncties of logging helpen bij het beperken, maar zijn niet de MTU zelf |
| Tegenpartij | De andere firewall, cloud-VPN of providerzijde moet hetzelfde pad correct bedienen |
| Wi-Fi-interface | Sinds SFOS 22.0 MR1 noemt Sophos ook MTU/MSS-aanpassingen voor Wi-Fi-interfaces via CLI |
Bij route-based IPsec maakt Sophos Firewall XFRM-interfaces aan. XFRM-MTU-waarden worden berekend op basis van het fysieke interface en de maximale IPsec-overhead en kunnen indien nodig worden aangepast. Dit is nuttig, maar vervangt geen grondige controle van het werkelijke pad.
Eerst het pad bewijzen
Voor elke wijziging moet men de betrokken gegevensstroom duidelijk beschrijven. Anders optimaliseert men snel op het verkeerde interface.
Praktische vragen:
- Welke bron-IP en bestemming-IP zijn betrokken?
- Loopt het verkeer via LAN, VLAN, WAN, XFRM, RED, SD-WAN of Remote Access VPN?
- Is slechts één richting betrokken of beide?
- Betreft het TCP, UDP of beide?
- Werken kleine pakketten, maar grotere overdrachten niet?
- Grijpt echt de verwachte firewall-regel?
- Zijn er NAT, MASQ, TLS Inspection, IPS of Application Control op het pad?
- Heeft de tegenpartij een passende terugroute?
Voor de regel- en padcontrole helpt Firewall-regel testen met Log Viewer, Policy Test en Packet Capture. Bij NAT of MASQ moet daarnaast NAT op Sophos Firewall begrijpen worden gecontroleerd.
Diagnose met Log Viewer, Packet Capture en iPerf
De Log Viewer toont of verkeer is toegestaan of geweigerd. Hij bewijst echter niet alleen of een pakket te groot is. Daarvoor heeft men ook Packet Capture, reproduceerbare tests en een duidelijke interpretatie nodig.
Log Viewer
In de Log viewer eerst controleren:
- Module
Firewallof het betrokken beveiligingsmodule selecteren. - Bron-IP, bestemming-IP en service filteren.
- Controleren welke firewall-regel overeenkomt.
- Zekerstellen dat geen drop-regel, verkeerde zone of verkeerde NAT-regel het eigenlijke probleem is.
Als er helemaal geen verkeer zichtbaar is, ligt het probleem vaak voor de firewall, bij de client-gateway, VLAN, routing of op de tegenpartij.
Packet Capture
Onder Diagnostics > Tools > Packet capture kan men de test nauwkeuriger afbakenen. Een filter op precies de betrokken bron en bestemming is zinvol. Daarna wordt een enkele test gereproduceerd, bijvoorbeeld een HTTPS-oproep, een bestandsoverdracht of een applicatiestart.
Belangrijk is de interpretatie:
| Observatie | Betekenis |
|---|---|
| Pakketten komen niet op de firewall aan | Client, gateway, VLAN of lokaal routing controleren |
| Pakketten gaan de tunnel in, antwoorden ontbreken | Tegenpartij, terugroute of remote-firewall controleren |
| Veel retransmits bij TCP | Pakketverlies, MTU/MSS, WAN-kwaliteit of overbelasting controleren |
| Kleine tests werken, grote overdrachten hangen | MTU/MSS of Path-MTU-Discovery controleren |
Voor de bediening van de tool past Packet Capture Tool in WebAdmin gebruiken.
iPerf
iPerf is nuttig wanneer men een traject reproduceerbaar kan meten. Een eigen iPerf-server aan de andere kant is veelzeggender dan een publieke iPerf-server. Als TCP-doorvoer laag is en veel retransmits zichtbaar worden, moeten MTU/MSS samen met WAN-kwaliteit, CPU, tegenpartij en beveiligingsfuncties worden gecontroleerd.
De procedure staat in Sophos Firewall Troubleshooting met iPerf en Speedtest.
Waarden alleen gericht wijzigen
Als het vermoeden gegrond is, moeten wijzigingen klein, gedocumenteerd en omkeerbaar blijven.
Voor een wijziging:
- huidige waarde documenteren
- betrokken interface en betrokken tunnel noteren
- onderhoudsvenster of gecontroleerd testtijdstip kiezen
- slechts één waarde per test wijzigen
- Vooraf-/Achteraf-test met dezelfde toepassing uitvoeren
- Tegenpartij informeren als een site-to-site VPN betrokken is
Bij route-based VPN’s moet eerst het XFRM-interface en de bijbehorende IPsec-verbinding worden gecontroleerd. Bij PPPoE of provider-overlays is vaak het WAN-interface of het providerpad het beslissende punt. Bij SD-WAN moet ook duidelijk zijn welk gateway- of VPN-pad werkelijk wordt gebruikt. Het artikel SD-WAN Routing voor Reply Packets en System Traffic helpt bij het plaatsen van SD-WAN-paden.
⚠️ Geen permanente shell-hacks gebruiken. Directe pakketmanipulatie via Advanced Shell, niet-gedocumenteerde startscript of spontane pakketfilterregels zijn voor productieve firewalls geen schone oplossing. Eerst moeten de ondersteunde Sophos-firewallfuncties worden gecontroleerd.
Wat men moet vermijden
Deze patronen veroorzaken in de praktijk meer schade dan nut:
- MSS algemeen voor alle netwerken extreem laag instellen.
- MTU-waarden wijzigen zonder Vooraf-/Achteraf-test.
- Slechts één richting testen en daaruit conclusies trekken voor het hele VPN-pad.
- Shell-workarounds gebruiken in plaats van WebAdmin- of gedocumenteerde Device Console-functies.
- De tegenpartij negeren, hoewel de terugweg of hun MSS-clamping betrokken kan zijn.
- MTU/MSS als oorzaak aannemen, hoewel firewallregel, NAT, routing of DNS niet zijn gecontroleerd.
- Debug-logs of Packet Captures lang laten lopen en opslagruimte vullen.
Als er al lokale scripts of pakketmanipulaties bestaan, moet men eerst Sophos Firewall Scripts zonder Cronjob: Risico’s en Alternatieven lezen en de oude last correct documenteren.
Troubleshooting-tabel
| Symptoom | Waarschijnlijker gebied | Volgende controle |
|---|---|---|
| VPN groen, grote overdrachten hangen | MTU/MSS, terugweg, beveiligingsfunctie | Packet Capture en iPerf met hetzelfde pad |
| Alleen PPPoE-WAN betrokken | Providerpad of WAN-MTU | WAN-interface, gateway en providergegevens controleren |
| Route-based VPN instabiel bij grote pakketten | XFRM-MTU of SD-WAN-pad | XFRM-interface, IPsec-verbinding en route controleren |
| VoIP over VPN slechts gedeeltelijk stabiel | SD-WAN, terugweg, pakketverlies, MTU | SIP/RTP-pad, SD-WAN-route en capture controleren |
| TCP zeer traag, UDP normaal | MSS, retransmits, TCP-venster, pakketverlies | iPerf TCP/UDP gescheiden testen |
| Kleine pakketten werken, grote niet | Path-MTU-Discovery of fragmentatie | Pakketgroottes bewust testen en tegenpartij controleren |
Checklist
Direct controleren:
- Betrokken bron, bestemming, service en richting gedocumenteerd.
- Firewall-regel en NAT-regel in Log Viewer bevestigd.
- Packet Capture met nauwkeurige filter uitgevoerd.
- IPsec-status en byte-teller gecontroleerd, als een VPN betrokken is.
- Tegenpartij en terugweg gecontroleerd.
Als MTU/MSS waarschijnlijk is:
- betrokken interface- of XFRM-plek geïdentificeerd.
- huidige MTU-/MSS-waarde gedocumenteerd.
- slechts één wijziging per test gepland.
- Testtoepassing en vergelijkingswaarde vastgesteld.
- Wijziging met tegenpartij afgestemd, als site-to-site VPN betrokken is.
Na de wijziging:
- dezelfde toepassing opnieuw testen.
- Log Viewer, Packet Capture of iPerf vergelijken.
- nieuwe waarden en reden documenteren.
- Monitoring in de komende dagen controleren.