Sophos Firewall SD-WAN Controleer de routering voor Reply Packets en System Traffic
SD-WAN Routes op Sophos Firewall zijn niet alleen relevant voor klassiek client-naar-internetverkeer. Afhankelijk van de omgeving kan ook Reply Packets en door het systeem gegenereerd verkeer worden beïnvloed. Dit is precies waar moeilijk te detecteren routeringsproblemen vaak voorkomen: de regel lijkt correct, de Gateway is actief, maar antwoorden gaan via het verkeerde pad of de firewall zelf bereikt een service niet via de verwachte lijn.
In deze handleiding worden de twee CLI-opties reply-packet en system-generate-traffic uitgelegd, wanneer u deze moet controleren en hoe u wijzigingen veilig kunt testen. Voor de normale SD-WAN route-instelling past Sophos Firewall SD-WAN route en test instellen en testen als eerste. Voor de algemene volgorde tussen statische routes, SD-WAN-beleidsroutes en VPN-routes geldt ook Sophos Firewall Route Precedence veilig wijzigen.
⚠️Deze instellingen kunnen onmiddellijk van invloed zijn op de productieve routering. Voordat u een wijziging doorvoert, moet u de huidige status documenteren, een onderhoudsvenster kiezen en een duidelijke weg terug kennen. Bijzonder kritisch zijn brede SD-WAN-routes met
Any, Route Precedence vóór statische routes en geactiveerde SD-WAN-routering voor System Traffic of Reply Packets.
Waar de twee opties over gaan
Met SD-WAN Routes moet u onderscheid maken tussen normaal doorgestuurd verkeer, responspakketten en verkeer dat de firewall zelf genereert. De twee opties bepalen niet of een enkele SD-WAN-route correct is opgebouwd. In plaats daarvan breiden ze uit met welk verkeerstype rekening kan worden gehouden door SD-WAN Policy Routing.
De twee opties hebben verschillende taken:
reply-packet: Beïnvloedt antwoordpakketten op bestaand verkeer. Hierdoor kan het retourpad worden beïnvloed via SD-WAN in bepaalde niet-WAN-scenario’s.system-generate-traffic: Beïnvloedt het verkeer dat door de firewall zelf wordt gegenereerd. Hierdoor kunnen firewall-specifieke verbindingen via gedefinieerde SD-WAN-routes worden gerouteerd.
Beide opties mogen niet blindelings worden geactiveerd alleen maar omdat “SD-WAN niet werkt”. Eerst moet duidelijk zijn of Reply Packets of het door het systeem gegenereerde verkeer daadwerkelijk wordt beïnvloed. Bij normale verbindingen is de werkelijke oorzaak vaak de firewallregel, NAT, Route Precedence, Gateway-status of een SD-WAN-route die te breed is.
Reply Packets
Reply Packets zijn antwoordpakketten op bestaand verkeer. Sophos Firewall dwingt over het algemeen symmetrische routering af voor dergelijke antwoorden op WAN-interfaces: antwoordpakketten moeten terugkeren via dezelfde WAN-interface waarmee de oorspronkelijke verbinding binnenkwam.
De optie reply-packet is met name relevant als er rekening moet worden gehouden met responspakketten in bepaalde SD-WAN Policy Routing-scenario’s. Een typisch voorbeeld is asymmetrische routering op niet-WAN-interfaces, zoals tussen LAN en DMZ.
De belangrijke beperking is: Als het oorspronkelijke verkeer via de standaardroute of WAN Link Load Balancing loopt, zijn SD-WAN-routes niet van toepassing op deze Reply Packets. De firewall blijft dan het juiste retourpad gebruiken via de interface van de oorspronkelijke verbinding.
Typische testvragen:
- Is het echt antwoordverkeer en geen nieuwe verbinding?
- Gaat het verkeer via WAN, LAN, DMZ, XFRM of een andere zone?
- Is er sprake van een route SD-WAN die bedoeld is om de terugreis opzettelijk te beïnvloeden?
- Is de route te breed, bijvoorbeeld bestemming
Any? - Heeft Route Precedence effect vóór een statische route of VPN-route?
Door het systeem gegenereerd verkeer
Door het systeem gegenereerd verkeer is verkeer dat de Sophos Firewall zelf genereert. Afhankelijk van de omgeving kan dit DNS, NTP, Sophos Central, Syslog, updates, monitoring, authenticatiediensten of diagnostische verbindingen omvatten.
Bij dit verkeer herkent de firewall geen normale binnenkomende interface en een normaal bronnetwerk zoals bij doorgestuurd clientverkeer. Daarom moet u SD-WAN-routes bijzonder nauwkeurig plannen voor door het systeem gegenereerd verkeer: doelnetwerken en Services moeten verstandig worden gekozen. Een zeer brede route kan anders onverwacht het beheer- of systeemverkeer op een verkeerd pad brengen.
Daarnaast gelden er twee praktische limieten:
- Als alle geconfigureerde gateways onder
Network > WAN link managerzijn gemarkeerd als alleen Back-up, stuurt de firewall het door het systeem gegenereerde verkeer niet door. Minstens één Gateway moet Actief zijn. - Door het systeem gegenereerd RED-verkeer op UDP
3410is Layer 2-verkeer. SD-WAN Routes zijn hierop niet van toepassing.
Wanneer moet u deze instellingen controleren?
De twee opties zijn vooral relevant voor complexere routeringsontwerpen. In eenvoudige single WAN-omgevingen zijn ze zelden de eerste hefboom.
Nuttige triggers:
- Eigen verkeer van de firewall gebruikt niet het verwachte pad WAN of VPN.
- Syslog, Central, DNS, NTP of monitoring moeten over een specifieke lijn lopen.
- Routegebaseerde IPsec VPN met XFRM-interfaces wordt gebruikt in combinatie met SD-WAN-routes.
- VoIP of ander gevoelig verkeer werkt slechts in één richting via SD-WAN/VPN.
- Packet Capture toont antwoorden op een andere interface dan verwacht.
- Na een upgrade gedraagt SD-WAN, IPsec of NAT zich anders dan voorheen.
- Een brede SD-WAN-route heeft plotseling invloed op interne netwerken of beheertoegang. Voor IPsec-scenario’s moet u ook Sophos Firewall IPsec VPN Probleemoplossing opnemen. Voor individuele verbindingen is Sophos Firewall-regeltest met Log Viewer en Packet Capture vaak een beter startpunt.
Bekijk de huidige status
De opdrachten worden uitgevoerd in Device Console, niet in Advanced Shell. Als de toegang tot de console nog niet duidelijk is, kan Verbind Sophos Firewall via SSH helpen.
Controleer de status voor Reply Packets:
show routing sd-wan-policy-route reply-packet
Controleer de status van door het systeem gegenereerd verkeer:
show routing sd-wan-policy-route system-generate-traffic
Bovendien toont de WebAdmin onder Routing > SD-WAN routes in de routeringsinformatie-tooltip of SD-WAN-routering actief is voor door het systeem gegenereerd verkeer en Reply Packets.
Voordat u wijzigingen aanbrengt, moet de huidige editie worden gedocumenteerd. Dit is belangrijk omdat een latere terugdraaiing alleen netjes mogelijk is als de vorige toestand bekend is.
Opties inschakelen
SD-WAN Routering voor Reply Packets activeren:
set routing sd-wan-policy-route reply-packet enable
SD-WAN Routering inschakelen voor door het systeem gegenereerd verkeer:
set routing sd-wan-policy-route system-generate-traffic enable
Voer vervolgens de statusopdrachten opnieuw uit en documenteer de uitvoer.
⚠️ Voer niet meerdere routeringswijzigingen tegelijk door. Als Route Precedence, SD-WAN route, NAT regel en deze CLI-opties tegelijkertijd worden gewijzigd, is het moeilijk om achteraf duidelijk een fout toe te schrijven.
Veilige stroom voor wijzigingen
Een pragmatisch proces verkleint het risico:
- Definieer het getroffen verkeer specifiek: Bron, Bestemming, Service, Zone, verwacht Gateway.
- Documenteer bestaande SD-WAN-routes, gateways en Route Precedence.
- Controleer of Bestemming
Anyecht nodig is. - Documenteer de huidige status van
reply-packetensystem-generate-traffic. - Wijzig slechts één optie.
- Voer de test uit met een duidelijk verkeersvoorbeeld.
- Controleer de tellers Log Viewer, Packet Capture en Gateway.
- Documenteer het resultaat en voer daarna pas verdere aanpassingen uit. Als de beheertoegang kan worden beïnvloed, moet er een secundair toegangsmiddel beschikbaar zijn: een lokale console, een ander intern toegangspad of toegang vanaf een niet-getroffen beheernetwerk.
Validatie na wijziging
Na activatie is een groene Gateway status niet voldoende. Je moet controleren of het gewenste verkeer ook daadwerkelijk het verwachte pad volgt.
Log Viewer- en SD-WAN-logboeken
Firewall- en SD-WAN-gerelateerde gebeurtenissen moeten worden gecontroleerd in de Logviewer. Voor relevante firewallregels moet Log firewall traffic actief zijn. Zonder loggen zie je vaak maar een deel van de beslissing.
Om te controleren:
- Welke Firewall Rule ID wordt geraakt?
- Welke NAT Rule ID wordt gebruikt?
- Welke Gateway of welke interface verschijnt in het log?
- Zijn er sprake van wegvallen, beleidsschendingen of onverwachte beslissingen over beveiligingsfuncties?
Packet Capture
De daadwerkelijke pakketstroom kan worden gecontroleerd met Diagnostics > Pakketopname. Voor routeringsvragen moet het filter smal zijn: Bron IP, Bestemming IP, Poort en Protocol.
De vergelijking is belangrijk:
- Komt het pakket op de verwachte interface aan?
- Verlaat het de firewall via de verwachte interface?
- Zal het antwoord terugkomen?
- Wordt NAT gebruikt?
- Is de terugreis plausibel voor Reply Packets?
Gebruik Sophos Firewall Packet Capture in WebAdmin is geschikt voor bediening en interpretatie.
Controleer systeemservices
In het geval van door het systeem gegenereerd verkeer moet u specifiek de betreffende service testen:
- DNS: Voer een DNS-zoekopdracht uit op de firewall en controleer het doelpad.
- NTP: Controleer de tijdstatus en beschikbaarheid van de NTP-server.
- Syslog: Controleer testbericht of huidige log op de collector.
- Sophos Central: Controleer centrale verbinding en rapportage.
- Monitoring: Controle SNMP, sFlow of externe controles op de collector.
Als het door het systeem gegenereerde verkeer niet zichtbaar is, moet u ook controleren of de SD-WAN-route alleen moet overeenkomen met bronnetwerken of inkomende interfaces. Deze criteria zijn niet beschikbaar voor verkeer dat eigendom is van de firewall, maar wel voor clientverkeer.
Typische fouten
- SD-WAN-route met bestemming
Anyvoor interne paden: Intern verkeer of beheertoegang kan worden gerouteerd via WAN. Internetdoelgroepen of specifieke doelnetwerken zijn beter. - Route Precedence stelt SD-WAN in vóór Statisch: Direct verbonden of statische netwerken kunnen onverwachts worden gekoppeld aan SD-WAN. Controleer Route Precedence en stel indien nodig Statisch in vóór SD-WAN.
system-generate-trafficactief zonder bestemmingsbeperking: Firewall-specifieke services kunnen het verkeerde pad gebruiken. Definieer daarom doelnetwerken en Services nauwkeurig.- Reply Packets verward met normale nieuwe verbindingen: Dan wordt de verkeerde oorzaak verwerkt. Packet Capture en controleer de stroomrichting.
- Meerdere routeringswijzigingen tegelijkertijd: De oorzaak van de fout blijft onduidelijk. Verander geleidelijk en documenteer elke test.
- Geen alternatieve beheertoegang: WebAdmin of SSH kunnen verloren gaan uit het getroffen netwerk. Bereid het onderhoudsvenster en het toegangspad voor.
Er ontstaat een bijzonder kritiek risico wanneer verschillende omstandigheden samenkomen: Route Precedence bevindt zich op SD-WAN voordat deze statisch is, een brede SD-WAN-route gebruikt Any, en SD-WAN-routering voor door het systeem gegenereerd verkeer of Reply Packets is actief. In dit geval kan de toegang tot WebAdmin of SSH vanaf bepaalde interne subnetten verloren gaan.
Interactie met NAT, IPsec en VoIP
SD-WAN is zelden alleen betrokken. NAT, IPsec of applicatiespecifiek verkeer spelen bij veel verstoringen een rol. Wat belangrijk is voor SNAT is of dezelfde bron IP wordt onderhouden over verschillende gateways. Als MASQ of verschillende vertaalde bronadressen worden gebruikt, kan failover of herroutering communicatieproblemen veroorzaken. Voor de basis: Begrijp NAT past bij Sophos Firewall.
Voor op routes gebaseerde IPsec VPN’s kunnen XFRM-interfaces worden gebruikt in SD-WAN-routes of SD-WAN-profielen. Vervolgens moeten de IPsec-status, SD-WAN-route, Route Precedence en firewallregels samen worden gecontroleerd. De op routes gebaseerde basisprincipes van VPN zijn gecategoriseerd in IPsec Route op Sophos Firewall. Als u VoIP-problemen heeft, is het ook de moeite waard om naar SIP, RTP, NAT en SD-WAN te kijken. De SFOS-22.0-MR1 release-opmerkingen documenteren een opgelost probleem waarbij VoIP-audio slechts in één richting werkte via routegebaseerde VPN met SD-WAN-routering na het upgraden naar SFOS 22.0 GA. Het praktische proces kunt u vinden in Sophos Firewall VoIP-problemen met SIP en RTP oplossen.
Terugdraaien
Voordat u wijzigingen aanbrengt, moet de oude status worden gedocumenteerd. Als dan de managementtoegang, systeemdiensten of het productieverkeer worden beïnvloed, is improvisatie niet langer nodig. Herstel eerst de vorige toestand.
Praktisch betekent dit:
- Reset gedocumenteerd vóór waarden voor
reply-packetensystem-generate-traffic. - Zet Route Precedence terug naar de vorige volgorde, indien gewijzigd.
- Deactiveer tijdelijk te brede routes SD-WAN of beperk ze tot specifieke bestemmingen.
- Test de beheertoegang vanaf een onaangetast netwerk.
- Beperk vervolgens de werkelijke oorzaak verder.
Als de toegang tot WebAdmin en SSH verloren gaat vanuit een intern subnet, maar nog steeds mogelijk is vanuit een ander subnet, moeten vanaf daar eerst de brede SD-WAN-route, Route Precedence en de twee CLI-opties worden gecontroleerd.
Controlelijst
- Huidige status van de twee CLI-opties gedocumenteerd.
- Getroffen verkeer specifiek gedefinieerd.
- SD-WAN route niet onnodig breed aangelegd met
Any. - Route Precedence gecontroleerd.
- Minstens één WAN-Gateway voor System Traffic beschikbaar als Actief.
- Alternatieve beheerverbinding voorbereid.
- Slechts één wijziging per test aangebracht.
- Log Viewer en Packet Capture gebruikt voor validatie.
- NAT, IPsec en firewallregels gecontroleerd.
- Resultaat en terugdraaiing gedocumenteerd in het operationele journaal.
Veelgestelde vragen
Moet u altijd antwoordpakketten en systeemverkeer activeren?
Waarom kan een SD-WAN-route de toegang tot WebAdmin of SSH verstoren?
Any voorrang heeft op statische routes en er ook rekening wordt gehouden met door het systeem gegenereerd verkeer of Reply Packets van SD-WAN, kan beheerverkeer van een intern subnet over het verkeerde pad gaan.