Sophos Firewall SD-WAN-routing voor Reply Packets en System Traffic controleren

SD-WAN Routes op Sophos Firewall zijn niet alleen relevant voor klassiek verkeer van clients naar internet. Afhankelijk van de omgeving kunnen ook Reply Packets en door het systeem gegenereerd verkeer worden beïnvloed. Juist daar ontstaan vaak lastig herkenbare routeringsproblemen: de regel ziet er correct uit en de gateway is actief, maar antwoorden lopen via het verkeerde pad of de firewall zelf bereikt een dienst niet via de verwachte verbinding.

Deze handleiding legt de twee CLI-opties reply-packet en system-generate-traffic uit, wanneer u ze moet controleren en hoe u wijzigingen veilig test. Begin voor de normale opbouw van een SD-WAN-route bij Een Sophos Firewall SD-WAN Route instellen en testen. Voor de algemene volgorde van statische routes, SD-WAN Policy Routes en VPN-routes is daarnaast Sophos Firewall Route Precedence veilig wijzigen relevant.

⚠️ Deze instellingen kunnen de productieroutering onmiddellijk beïnvloeden. Documenteer vóór een wijziging de huidige toestand, kies een onderhoudsvenster en zorg voor een duidelijk terugvalpad. Vooral brede SD-WAN Routes met Any, Route Precedence vóór Static Routes en ingeschakelde SD-WAN-routing voor System Traffic of Reply Packets zijn kritisch.

Basisprincipes en beperkingen

Wat de twee opties doen

Bij SD-WAN Routes moet u onderscheid maken tussen normaal doorgestuurd verkeer, antwoordpakketten en verkeer dat de firewall zelf genereert. De twee opties bepalen niet of een afzonderlijke SD-WAN Route correct is opgebouwd. Ze breiden uit welke verkeerstypen überhaupt door SD-WAN Policy Routing kunnen worden verwerkt.

De opties hebben verschillende functies:

• reply-packet: Geldt voor antwoordpakketten bij bestaand verkeer. Hiermee kan het retourpad in bepaalde niet-WAN-scenario’s via SD-WAN worden beïnvloed.
• system-generate-traffic: Geldt voor verkeer dat de firewall zelf genereert. Hiermee kunnen verbindingen van de firewall via gedefinieerde SD-WAN Routes worden geleid.

Schakel beide opties niet blind in omdat “SD-WAN niet werkt”. Bepaal eerst of het probleem werkelijk Reply Packets of door het systeem gegenereerd verkeer betreft. Bij normale verbindingen ligt de oorzaak vaak bij de firewallregel, NAT, Route Precedence, de gatewaystatus of een te brede SD-WAN Route.

Reply Packets

Reply Packets zijn antwoordpakketten bij bestaand verkeer. Sophos Firewall dwingt op WAN-interfaces in principe symmetrische routering voor dergelijke antwoorden af: antwoordpakketten moeten teruggaan via dezelfde WAN-interface waarop de oorspronkelijke verbinding is binnengekomen.

De optie reply-packet is vooral relevant wanneer antwoordpakketten in bepaalde scenario’s door SD-WAN Policy Routing moeten worden verwerkt. Een typisch voorbeeld is asymmetrische routering op niet-WAN-interfaces, bijvoorbeeld tussen LAN en DMZ.

Een belangrijke beperking: als het oorspronkelijke verkeer via de Default Route of WAN Link Load Balancing loopt, zijn SD-WAN Routes niet van toepassing op deze Reply Packets. De firewall gebruikt dan nog steeds het passende retourpad via de interface van de oorspronkelijke verbinding.

Typische controlevragen:

• Gaat het werkelijk om antwoordverkeer en niet om een nieuwe verbinding?
• Loopt het verkeer via WAN, LAN, DMZ, XFRM of een andere zone?
• Is er een SD-WAN Route die het retourpad bewust moet beïnvloeden?
• Is de route te breed, bijvoorbeeld met Destination Any?
• Heeft Route Precedence voorrang op een statische route of VPN-route?

Door het systeem gegenereerd verkeer

Door het systeem gegenereerd verkeer is verkeer dat Sophos Firewall zelf produceert. Afhankelijk van de omgeving gaat het bijvoorbeeld om DNS-verzoeken, downloads van signatures, authenticatieverzoeken, DHCP, NTP, Syslog of verbindingen met Sophos Central. Standaard gebruikt dit verkeer de actieve WAN-gateways uit Network > WAN link manager.

Bij dit verkeer zijn Incoming interface en Source networks niet bekend en daarom ongeschikt als selectiecriteria. Voor een SD-WAN Route die firewallverkeer moet verwerken, beperkt u dus alleen Destination networks en Services doelgericht; de overige criteria blijven breed. Een route met Destination Any kan systeem- en beheerverkeer anders onverwacht naar een verkeerd pad sturen.

Hiervoor is geen normale firewallregel vereist. In Current activities > Live connections heeft door het systeem gegenereerd verkeer daarom Firewall Rule ID 0. Als een specifieke Source-IP nodig is, volstaat een normale SNAT-regel evenmin: NAT-regels vertalen doorgestuurd verkeer. Voor firewallverkeer is afhankelijk van het scenario sys-traffic-nat in de Device Console vereist.

Daarnaast gelden twee praktische beperkingen:

• Als alle geconfigureerde gateways onder Network > WAN link manager uitsluitend als Backup zijn gemarkeerd, stuurt de firewall door het systeem gegenereerd verkeer niet via deze gateways. Minstens één gateway moet Active zijn.
• Door het systeem gegenereerd RED-verkeer op UDP 3410 is Layer 2-verkeer. SD-WAN Routes zijn daarop niet van toepassing.

Voorbereiding

Wanneer u deze instellingen moet controleren

De twee opties zijn vooral relevant bij complexere routeringsontwerpen. In eenvoudige omgevingen met één WAN-verbinding zijn ze zelden het eerste aanknopingspunt.

Zinvolle aanleidingen:

• Verkeer van de firewall zelf gebruikt niet het verwachte WAN- of VPN-pad.
• Syslog, Central, DNS, NTP of monitoring moet via een specifieke verbinding lopen.
• Route-based IPsec VPN met XFRM-interfaces wordt samen met SD-WAN Routes gebruikt.
• VoIP of ander gevoelig verkeer werkt via SD-WAN/VPN slechts in één richting.
• Packet Capture toont antwoorden op een andere interface dan verwacht.
• Na een upgrade gedragen SD-WAN, IPsec of NAT zich anders dan voorheen.
• Een brede SD-WAN Route beïnvloedt plotseling interne netwerken of beheerstoegang.

Betrek bij IPsec-scenario’s ook Problemen met Sophos Firewall IPsec VPN oplossen. Bij afzonderlijke verbindingen is Een Sophos Firewall-regel testen met Log Viewer en Packet Capture vaak het betere startpunt.

De huidige status weergeven

Voer de opdrachten uit in de Device Console, niet in de Advanced Shell. Als de toegang tot de console nog niet duidelijk is, helpt Via SSH verbinding maken met Sophos Firewall.

Controleer de status voor Reply Packets:

show routing sd-wan-policy-route reply-packet

Controleer de status voor door het systeem gegenereerd verkeer:

show routing sd-wan-policy-route system-generate-traffic

Daarnaast geeft WebAdmin onder Routing > SD-WAN routes in de tooltip met routeringsinformatie aan of SD-WAN-routing voor door het systeem gegenereerd verkeer en Reply Packets actief is.

Documenteer ook de huidige Route Precedence:

system route_precedence show

Leg vóór elke wijziging de actuele uitvoer vast. Alleen wanneer de eerdere toestand bekend is, kunt u later een correcte rollback uitvoeren.

De configuratie wijzigen

Opties inschakelen of uitschakelen

Schakel SD-WAN-routing voor Reply Packets in:

set routing sd-wan-policy-route reply-packet enable

Schakel SD-WAN-routing voor door het systeem gegenereerd verkeer in:

set routing sd-wan-policy-route system-generate-traffic enable

Voer daarna de statusopdrachten opnieuw uit en documenteer de uitvoer.

Gebruik de tegengestelde opdrachten om de opties gericht uit te schakelen:

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ Voer niet meerdere routeringswijzigingen tegelijk uit. Als Route Precedence, de SD-WAN Route, de NAT-regel en deze CLI-opties gelijktijdig worden gewijzigd, is een fout achteraf nauwelijks betrouwbaar toe te wijzen.

Veilige werkwijze voor wijzigingen

Een pragmatische werkwijze beperkt het risico:

1. Definieer het betreffende verkeer concreet: Source, Destination, Service, Zone en verwachte gateway.
2. Documenteer bestaande SD-WAN Routes, gateways en Route Precedence.
3. Controleer of Destination Any werkelijk nodig is.
4. Documenteer de huidige status van reply-packet en system-generate-traffic.
5. Wijzig slechts één optie.
6. Test met een duidelijk verkeersvoorbeeld.
7. Controleer Log Viewer, Packet Capture en gatewaytellers.
8. Documenteer het resultaat en voer pas daarna verdere aanpassingen uit.

Als de beheerstoegang kan worden beïnvloed, zorg dan voor een tweede toegangsmogelijkheid: een lokale console, een ander intern toegangspad of toegang vanuit een niet-beïnvloed beheernetwerk.

Validatie na de wijziging

Een groene gatewaystatus is na het inschakelen niet voldoende. Controleer of het gewenste verkeer werkelijk het verwachte pad volgt.

Live Connections, Log Viewer en SD-WAN-tellers

Controleer voor doorgestuurd verkeer in de Log viewer de firewall- en SD-WAN-gerelateerde gebeurtenissen. Voor relevante Firewall Rules moet Log firewall traffic actief zijn. Door het systeem gegenereerd verkeer wordt daarentegen niet door een firewallregel gestuurd. U herkent het onder Current activities > Live connections aan Firewall Rule ID 0 en aan de Inbound- en Outbound-interfaces.

Controleer het volgende:

• Gaat het om doorgestuurd verkeer met een Firewall Rule ID of om systeemverkeer met ID 0?
• Welke NAT Rule ID wordt bij doorgestuurd verkeer gebruikt?
• Welke gateway of interface verschijnt in het logboek?
• Zijn er drops, beleidsovertredingen of onverwachte beslissingen van beveiligingsfuncties?
• Toont de SD-WAN Route alleen OUT voor Requests of ook IN voor Replies? De tellers verschijnen alleen als de Source- en Destination-criteria overeenkomen met de betreffende richting.

Packet Capture

Met Diagnostics > Packet capture controleert u de werkelijke pakketstroom. Houd het filter bij routeringsvragen beperkt tot Source IP, Destination IP, Port en Protocol.

Vergelijk daarbij:

• Komt het pakket binnen op de verwachte interface?
• Verlaat het de firewall via de verwachte interface?
• Komt het antwoord terug?
• Wordt NAT toegepast?
• Is het retourpad voor Reply Packets plausibel?

Voor bediening en interpretatie is Sophos Firewall Packet Capture in WebAdmin gebruiken relevant.

Systeemdiensten controleren

Test bij door het systeem gegenereerd verkeer gericht de betreffende dienst:

• DNS: Voer een DNS-lookup op de firewall uit en controleer het bestemmingspad.
• NTP: Controleer de tijdstatus en bereikbaarheid van de NTP-server.
• Syslog: Controleer een testbericht of recent logboek op de collector.
• Sophos Central: Controleer de Central-verbinding en rapportage.
• Monitoring: Controleer SNMP, sFlow of externe controles op de collector.

Als door het systeem gegenereerd verkeer niet zichtbaar wordt, controleer dan of de route ten onrechte criteria vereist voor Source networks, Incoming interface, gebruiker of applicatie. Voor verkeer van de firewall zelf moeten vooral Destination networks en Services beslissend zijn. Als de andere partij een specifieke Source-IP verwacht, controleer dan ook de Source-IP en een mogelijke sys-traffic-nat-configuratie.

Fouten en afhankelijkheden

Veelvoorkomende fouten

• SD-WAN Route met Destination Any voor interne paden: Intern verkeer of beheerstoegang kan via WAN worden gerouteerd. Internetbestemmingsgroepen of concrete bestemmingsnetwerken zijn beter.
• Route Precedence plaatst SD-WAN vóór Static: Direct verbonden of statische netwerken kunnen onverwacht door SD-WAN worden gematcht. Controleer Route Precedence en plaats zo nodig Static vóór SD-WAN.
• system-generate-traffic actief zonder bestemmingsbeperking: Diensten van de firewall zelf kunnen het verkeerde pad gebruiken. Definieer bestemmingsnetwerken en Services daarom nauwkeurig.
• Reply Packets verward met normale nieuwe verbindingen: Daardoor wordt de verkeerde oorzaak onderzocht. Controleer Packet Capture en de stroomrichting.
• Een firewallregel gezocht voor door het systeem gegenereerd verkeer: Dit verkeer heeft Firewall Rule ID 0; normale firewallregels sturen het niet. Controleer route, dienst, Live Connection en zo nodig sys-traffic-nat.
• Direct Web Proxy behandeld als normaal HTTP/HTTPS-verkeer: Voor de directe proxy moet de SD-WAN Route de onder Web > General settings > Web proxy listening port geconfigureerde poort omvatten. Als alternatief kan Services op Any staan. Source Network en Incoming Interface matchen Reply Packets van proxyverkeer niet; voor het retourpad is minstens één WAN-gateway of een passende statische route nodig.
• Meerdere routeringswijzigingen tegelijk: De foutoorzaak blijft onduidelijk. Werk stapsgewijs en documenteer iedere test.
• Geen alternatieve beheerstoegang: WebAdmin of SSH kan vanuit het betreffende netwerk onbereikbaar worden. Bereid het onderhoudsvenster en toegangspad voor.

Een bijzonder kritisch risico ontstaat wanneer meerdere omstandigheden samenkomen: Route Precedence plaatst SD-WAN vóór Static, een brede SD-WAN Route gebruikt Any, en SD-WAN-routing voor door het systeem gegenereerd verkeer of Reply Packets is actief. In dat geval kan de toegang tot WebAdmin of SSH vanuit bepaalde interne subnetten verloren gaan.

Samenwerking met NAT, IPsec en VoIP

SD-WAN is zelden de enige factor. Bij veel storingen spelen ook NAT, IPsec of applicatiespecifiek verkeer een rol.

Bij SNAT is het belangrijk of dezelfde Source-IP via verschillende gateways behouden blijft. Wanneer MASQ of verschillende vertaalde Source-adressen worden gebruikt, kan failover of omroutering communicatieproblemen veroorzaken. Zie voor de basisprincipes NAT op Sophos Firewall begrijpen.

Bij route-based IPsec VPNs kunnen XFRM-interfaces worden gebruikt in SD-WAN Routes of SD-WAN Profiles. Controleer dan gezamenlijk de IPsec-status, SD-WAN Route, Route Precedence en firewallregels. De basisprincipes van route-based VPN zijn uitgelegd in IPsec Route op Sophos Firewall.

Bij VoIP-problemen is het ook zinvol om SIP, RTP, NAT en SD-WAN te controleren. In de release notes voor SFOS 22.0 MR1 staat een opgelost probleem waarbij VoIP-audio na een upgrade naar SFOS 22.0 GA slechts in één richting werkte via route-based VPN met SD-WAN-routing. De praktische aanpak staat in VoIP-problemen met SIP en RTP op Sophos Firewall oplossen.

Rollback en afronding

Rollback

Documenteer de oude toestand vóór de wijziging. Als daarna de beheerstoegang, systeemdiensten of het productieverkeer worden beïnvloed, improviseer dan niet verder. Herstel eerst de vorige toestand.

Concreet betekent dit:

1. Herstel de gedocumenteerde eerdere waarden voor reply-packet en system-generate-traffic met de passende enable- of disable-opdrachten.
2. Zet Route Precedence terug naar de vorige volgorde als deze is gewijzigd.
3. Schakel te brede SD-WAN Routes tijdelijk uit of beperk ze tot concrete bestemmingen.
4. Test de beheerstoegang vanuit een niet-beïnvloed netwerk.
5. Onderzoek pas daarna de werkelijke oorzaak verder.

Als WebAdmin en SSH vanuit één intern subnet niet meer bereikbaar zijn, maar vanuit een ander subnet nog wel, controleer dan vanaf daar eerst de brede SD-WAN Route, Route Precedence en de twee CLI-opties.

Checklist

• Huidige status van beide CLI-opties gedocumenteerd.
• Route Precedence met system route_precedence show gedocumenteerd.
• Betreffend verkeer concreet gedefinieerd.
• Voor systeemverkeer alleen Destination en Service als beslissende matchcriteria gebruikt.
• SD-WAN Route niet onnodig breed met Any opgebouwd.
• Route Precedence gecontroleerd.
• Minstens één WAN-gateway voor System Traffic als Active beschikbaar.
• Alternatieve beheerverbinding voorbereid.
• Slechts één wijziging per test uitgevoerd.
• Log Viewer en Packet Capture voor validatie gebruikt.
• NAT, IPsec en firewallregels eveneens gecontroleerd.
• Resultaat en rollback in het operationele logboek gedocumenteerd.

FAQ