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. Voorbeelden zijn DNS-verzoeken, downloads van signatures en authenticatieverzoeken. Bij diensten zoals DHCP, SNMP of Syslog hangt de indeling af van de rol en de verkeersrichting; niet al het verkeer naar een firewallservice is een uitgaande, door het systeem gegenereerde verbinding. Standaard verstuurt de firewall zijn eigen verkeer via de WAN-gateways onder 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. De Local service ACL onder Administration > Device access staat hiervan los: deze regelt toegang tot lokale firewallservices, niet de keuze van het uitgaande SD-WAN-pad. 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.

Een authenticatieserver bereiken via route-based IPsec

Een belangrijk bijzonder geval is een AD- of LDAP-server op het hoofdkantoor die de firewall van een vestiging zelf via een route-based IPsec-tunnel moet bereiken. Een normale LAN-naar-VPN-regel stuurt deze aanvraag niet, omdat de firewall het verkeer genereert. Bij een any-to-any-tunnel met geadresseerde XFRM-interfaces moeten de heen- en terugweg daarom bewust worden gepland.

In het volgende voorbeeld is 10.10.1.1 het zichtbare bronadres van de firewall op de vestiging, 10.10.2.15 de AD-server en TCP 636 de service voor LDAPS. Deze waarden zijn geen productstandaarden. Vervang ze door een vestigingsadres dat in de tunnel is toegestaan en waarvoor het hoofdkantoor een retourroute heeft, de werkelijke server en de daadwerkelijk geconfigureerde authenticatieservice.

1. Maak op de firewall van de vestiging een gerichte SD-WAN Route met Source networks op Any, de AD-host als Destination networks en de vereiste authenticatieservice. TCP 636 past alleen als de server daadwerkelijk LDAPS gebruikt. Gebruik het externe XFRM-adres via de lokale XFRM-interface als Primary Gateway.
2. Activeer Route only through specified gateways alleen wanneer de aanvraag bewust moet worden verworpen als de tunnel niet beschikbaar is. Controleer de schakelaar voor door het systeem gegenereerd verkeer zoals hierboven beschreven en activeer deze gecontroleerd voor deze procedure.
3. Leg op de Device Console eerst met show advanced-firewall de bestaande sys-traffic-nat-items en hun volgorde vast. Vertaal daarna het eigen bronadres van de firewall naar het geplande vestigingsadres. Dit adres moet passen bij de tunnel- en retourwegregels:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1

4. Maak op de firewall van het hoofdkantoor een SD-WAN Route voor de terugweg van de AD-host naar het vertaalde vestigingsadres via het externe XFRM-adres. Houd Source, Destination en Service net zo gericht als aan de kant van de vestiging.
5. Maak op het hoofdkantoor gelogde regels van VPN naar het servernetwerk en van het servernetwerk terug naar VPN, met de concrete hosts en services. De brede Any-voorbeelden uit productinstructies zijn niet geschikt als permanente configuratie.
6. Ping/Ping6 onder Administration > Device access voor de zone VPN is alleen nodig als het probe target een lokaal firewall- of XFRM-adres is. Voor een doorgestuurde host achter de tunnel zijn in plaats daarvan de juiste tunnel, route en zo nodig firewallregel vereist. Zet een tijdelijke Device Access-toestemming na de test terug naar de vorige toestand.

Voor de acceptatie worden een echte serververbindingstest en een gebruikersaanmelding uitgevoerd. Op de firewall van de vestiging verschijnt door het systeem gegenereerd verkeer onder Current activities > Live connections met Firewall Rule ID 0; op het hoofdkantoor moeten de verwachte gelogde regels matchen. Packet Capture moet de aanvraag en het antwoord op de geplande XFRM-interfaces tonen. Alleen een geslaagde ping bevestigt noch LDAPS, noch authenticatie en de retourweg.

Controleer bij de rollback eerst of de twee SD-WAN Routes, regels, gatewayobjecten en een tijdelijke Ping/Ping6-toestemming nog andere afhankelijkheden hebben. Verwijder de NAT-vermelding met exact dezelfde selectiecriteria; als bij het aanmaken ook netmask of interface is gebruikt, moeten deze eveneens in de delete-opdracht staan:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Controleer vervolgens met show advanced-firewall of alleen de bedoelde vermelding is verdwenen. Verwijder uitsluitend routes, regels en objecten die voor deze procedure zijn aangemaakt, zet beide globale SD-WAN-schakelaars en Route Precedence terug naar de gedocumenteerde vorige waarden en test het oorspronkelijke gegevenspad opnieuw.

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.

Onder Routing > SD-WAN routes moet ook duidelijk zijn hoe elke betreffende route reageert als een gateway uitvalt. Met Route only through specified gateways verwerpt de firewall het verkeer als de opgegeven gateways niet beschikbaar zijn. Zonder deze optie controleert de firewall de daaropvolgende SD-WAN Routes en daarna WAN Link Load Balancing. Als de geselecteerde Primary Gateway of het SD-WAN Profile wordt verwijderd, verwijdert SFOS ook de route; als alleen de Backup Gateway wordt verwijderd, blijft de route bestaan met None als backup.

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 de OUT-/IN-tellers van de SD-WAN Route.
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 vóór de test onder System services > Log settings of SD-WAN wordt gelogd. De vermeldingen verschijnen in de module SD-WAN van de Log viewer; bij doorgestuurd verkeer moet bovendien Log firewall traffic actief zijn voor de betreffende Firewall Rule. Noteer de vorige loggingstatus en herstel deze na de test als logging alleen tijdelijk is ingeschakeld.

Door het systeem gegenereerd verkeer wordt 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. De Local service ACL blijft de afzonderlijke controle voor toegang tot lokale firewallservices.

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?
• Toont Status bij aanvragen van de firewall zelf Generated en, waar van toepassing, bij antwoorden die aan de firewall worden geleverd Consumed?
• Komen Gateway ID, NAT ID en de Inbound- en Outbound-interface overeen met het geplande pad?

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

De betreffende systeemdienst controleren

Alleen een routematch bewijst nog niet dat de dienst werkt. Noteer vóór de test Destination IP, poort, verwachte Source-IP en verwachte Outbound-interface. Activeer vervolgens precies de betreffende functie, bijvoorbeeld een authenticatieverzoek of een DNS-lookup van de firewall, en controleer zowel Packet Capture als de bevestiging op het doelsysteem. Gebruik een niet-overeenkomende bestemming of een andere dienst als negatieve test; deze mag de gerichte route niet matchen.

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. Lees de huidige toestand op de Device Console met show routing reroute-connection en show routing reroute-snat-connection. SFOS kan verbindingen na uitval van een gateway omrouteren, maar voor SNAT-verbindingen moet op beide paden hetzelfde vertaalde bronadres behouden blijven. MASQ of verschillende vertaalde adressen kunnen een actieve verbinding tijdens het omrouteren onderbreken. In dit artikel worden deze twee waarden alleen gelezen en niet gewijzigd. 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. Zet gewijzigde SD-WAN Routes terug naar hun gedocumenteerde vorige waarden; verwijder routes die alleen voor de test zijn gemaakt nadat u de afhankelijkheden hebt gecontroleerd.
4. Verwijder tijdelijke sys-traffic-nat-vermeldingen met exact dezelfde selectiecriteria en controleer dit met show advanced-firewall.
5. Herstel firewallregels, gatewayobjecten, Device Access-toestemmingen en logginginstellingen die alleen voor de test zijn gewijzigd.
6. Test de beheerstoegang en het oorspronkelijke gegevenspad vanuit een niet-beïnvloed netwerk.
7. 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