Kontrollera Sophos Firewall SD-WAN-routing för Reply Packets och System Traffic

SD-WAN Routes på Sophos Firewall är inte bara relevanta för klassisk trafik från klienter till internet. Beroende på miljön kan även Reply Packets och systemgenererad trafik beröras. Det är ofta här svårupptäckta routingproblem uppstår: Regeln ser korrekt ut och gatewayen är aktiv, men svaren går via fel väg eller så når brandväggen själv inte en tjänst via den förväntade anslutningen.

Den här guiden förklarar de två CLI-alternativen reply-packet och system-generate-traffic, när de bör kontrolleras och hur ändringar testas säkert. Börja med Konfigurera och testa en Sophos Firewall SD-WAN Route för den vanliga konfigurationen av en SD-WAN-route. För den generella ordningen mellan statiska rutter, SD-WAN Policy Routes och VPN-rutter passar även Ändra Route Precedence säkert på Sophos Firewall.

⚠️ De här inställningarna kan påverka produktiv routing omedelbart. Dokumentera det aktuella läget, välj ett underhållsfönster och planera en tydlig väg tillbaka innan du gör en ändring. Breda SD-WAN Routes med Any, Route Precedence före Static Routes och aktiverad SD-WAN-routing för System Traffic eller Reply Packets är särskilt kritiska.

Grunder och begränsningar

Vad de två alternativen gör

För SD-WAN Routes måste man skilja mellan vanlig vidarebefordrad trafik, svarspaket och trafik som brandväggen själv genererar. De två alternativen avgör inte om en enskild SD-WAN Route är korrekt konfigurerad. De utökar i stället vilka trafiktyper som överhuvudtaget kan omfattas av SD-WAN Policy Routing.

Alternativen har olika uppgifter:

• reply-packet: Gäller svarspaket till befintlig trafik. Med alternativet kan returvägen i vissa scenarier utan WAN påverkas via SD-WAN.
• system-generate-traffic: Gäller trafik som brandväggen själv genererar. Det gör att brandväggens egna anslutningar kan styras via definierade SD-WAN Routes.

Aktivera inte alternativen blint bara för att “SD-WAN inte fungerar”. Kontrollera först om Reply Packets eller systemgenererad trafik faktiskt berörs. För vanliga anslutningar är den verkliga orsaken ofta en Firewall Rule, NAT, Route Precedence, gatewaystatus eller en alltför bred SD-WAN Route.

Reply Packets

Reply Packets är svarspaket till befintlig trafik. Sophos Firewall upprätthåller normalt symmetrisk routing för sådana svar på WAN-interfaces: Svarspaketen ska gå tillbaka via samma WAN-interface som den ursprungliga anslutningen kom in genom.

Alternativet reply-packet är främst relevant när svarspaket i vissa scenarier ska omfattas av SD-WAN Policy Routing. Ett typiskt exempel är asymmetrisk routing på interfaces som inte är WAN, exempelvis mellan LAN och DMZ.

En viktig begränsning är att SD-WAN Routes inte gäller för dessa Reply Packets när den ursprungliga trafiken går via Default Route eller WAN Link Load Balancing. Brandväggen fortsätter då att använda den lämpliga returvägen via interfacet för den ursprungliga anslutningen.

Typiska kontrollfrågor:

• Är det verkligen svarstrafik och inte en ny anslutning?
• Går trafiken via WAN, LAN, DMZ, XFRM eller en annan zon?
• Finns det en SD-WAN Route som avsiktligt ska påverka returvägen?
• Är rutten för bred, exempelvis med Destination Any?
• Har Route Precedence företräde framför en statisk rutt eller VPN-rutt?

Systemgenererad trafik

Systemgenererad trafik är trafik som Sophos Firewall själv skapar. Beroende på miljön kan detta omfatta DNS-frågor, nedladdning av signaturer, autentiseringsfrågor, DHCP, NTP, Syslog eller anslutningar till Sophos Central. Som standard använder trafiken de aktiva WAN-gatewayerna under Network > WAN link manager.

För den här trafiken är Incoming interface och Source networks inte kända och därför olämpliga som urvalskriterier. I en SD-WAN Route som ska omfatta brandväggstrafik bör därför endast Destination networks och Services avgränsas specifikt, medan övriga kriterier förblir breda. En rutt med Destination Any kan annars oväntat styra system- och hanteringstrafik via fel väg.

Det behövs ingen vanlig Firewall Rule för detta. Systemgenererad trafik har därför Firewall Rule ID 0 under Current activities > Live connections. Om en specifik Source IP krävs räcker inte heller en vanlig SNAT-regel: NAT-regler översätter vidarebefordrad trafik, medan brandväggstrafik beroende på scenario kräver sys-traffic-nat i Device Console.

Två praktiska begränsningar gäller dessutom:

• Om alla konfigurerade gateways under Network > WAN link manager endast är markerade som Backup vidarebefordrar brandväggen inte systemgenererad trafik via dem. Minst en gateway måste vara Active.
• Systemgenererad RED-trafik på UDP 3410 är Layer 2-trafik. SD-WAN Routes gäller inte för den.

Förberedelser

När inställningarna bör kontrolleras

De två alternativen är främst relevanta i mer komplexa routingdesigner. I enkla Single-WAN-miljöer är de sällan den första åtgärden.

Rimliga utlösande faktorer:

• Brandväggens egen trafik använder inte den förväntade WAN- eller VPN-vägen.
• Syslog, Central, DNS, NTP eller Monitoring ska gå via en bestämd anslutning.
• Route-based IPsec VPN med XFRM-interfaces används tillsammans med SD-WAN Routes.
• VoIP eller annan känslig trafik fungerar endast i en riktning via SD-WAN/VPN.
• Packet Capture visar svar på ett annat interface än förväntat.
• SD-WAN, IPsec eller NAT beter sig annorlunda efter en uppgradering.
• En bred SD-WAN Route påverkar plötsligt interna nätverk eller hanteringsåtkomst.

Vid IPsec-scenarier bör även Felsökning av Sophos Firewall IPsec VPN tas med. För enskilda anslutningar är Testa en Sophos Firewall-regel med Log Viewer och Packet Capture ofta en bättre utgångspunkt.

Visa aktuell status

Kommandona körs i Device Console, inte i Advanced Shell. Om konsolåtkomsten ännu inte är klar hjälper Anslut till Sophos Firewall via SSH.

Kontrollera status för Reply Packets:

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

Kontrollera status för systemgenererad trafik:

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

WebAdmin visar dessutom under Routing > SD-WAN routes, i verktygstipset för routinginformationen, om SD-WAN-routing är aktiv för systemgenererad trafik och Reply Packets.

Dokumentera även aktuell Route Precedence:

system route_precedence show

Dokumentera den aktuella utdata före varje ändring. En senare återställning kan bara göras korrekt om det tidigare läget är känt.

Ändra konfigurationen

Aktivera eller inaktivera alternativ

Aktivera SD-WAN-routing för Reply Packets:

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

Aktivera SD-WAN-routing för systemgenererad trafik:

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

Kör därefter statuskommandona igen och dokumentera utdata.

Använd motsvarande kommandon för att inaktivera alternativen specifikt:

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

⚠️ Gör inte flera routingändringar samtidigt. Om Route Precedence, SD-WAN Route, NAT-regel och dessa CLI-alternativ ändras samtidigt blir det mycket svårt att därefter koppla ett fel till rätt orsak.

Säkert arbetsflöde för ändringar

Ett pragmatiskt arbetsflöde minskar risken:

1. Definiera den berörda trafiken exakt: Source, Destination, Service, Zone och förväntad gateway.
2. Dokumentera befintliga SD-WAN Routes, gateways och Route Precedence.
3. Kontrollera om Destination Any verkligen behövs.
4. Dokumentera aktuell status för reply-packet och system-generate-traffic.
5. Ändra endast ett alternativ.
6. Testa med ett tydligt trafikexempel.
7. Kontrollera Log Viewer, Packet Capture och gatewayräknare.
8. Dokumentera resultatet innan ytterligare ändringar görs.

Om hanteringsåtkomsten kan påverkas bör en andra åtkomstväg finnas: lokal konsol, en annan intern åtkomstväg eller åtkomst från ett hanteringsnätverk som inte berörs.

Validering efter ändringen

En grön gatewaystatus räcker inte efter aktiveringen. Kontrollera att den önskade trafiken verkligen tar den förväntade vägen.

Live Connections, Log Viewer och SD-WAN-räknare

För vidarebefordrad trafik bör Firewall- och SD-WAN-relaterade händelser kontrolleras i Log viewer. Log firewall traffic måste vara aktivt för relevanta Firewall Rules. Systemgenererad trafik styrs däremot inte av en Firewall Rule. Under Current activities > Live connections känns den igen på Firewall Rule ID 0 samt på Inbound- och Outbound-interfaces.

Kontrollera följande:

• Är det vidarebefordrad trafik med ett Firewall Rule ID eller systemtrafik med ID 0?
• Vilket NAT Rule ID används för vidarebefordrad trafik?
• Vilken gateway eller vilket interface visas i loggen?
• Finns det Drops, policyöverträdelser eller oväntade beslut från Security Features?
• Visar SD-WAN Route endast OUT för Requests eller även IN för Replies? Räknarna visas bara när Source- och Destination-kriterierna matchar respektive riktning.

Packet Capture

Det faktiska paketflödet kan kontrolleras med Diagnostics > Packet capture. Vid routingfrågor bör filtret vara snävt: Source IP, Destination IP, Port och Protocol.

Jämför följande:

• Kommer paketet in på förväntat interface?
• Lämnar det brandväggen via förväntat interface?
• Kommer svaret tillbaka?
• Tillämpas NAT?
• Är returvägen rimlig för Reply Packets?

För användning och tolkning passar Använd Packet Capture i Sophos Firewall WebAdmin.

Kontrollera systemtjänster

Vid systemgenererad trafik bör den berörda tjänsten testas specifikt:

• DNS: Kör en DNS-lookup på brandväggen och kontrollera målvägen.
• NTP: Kontrollera tidsstatus och åtkomst till NTP-servern.
• Syslog: Kontrollera ett testmeddelande eller en aktuell logg på collectorn.
• Sophos Central: Kontrollera Central-anslutningen och rapporteringen.
• Monitoring: Kontrollera SNMP, sFlow eller externa kontroller på collectorn.

Om systemgenererad trafik inte syns bör du kontrollera om rutten ställer onödiga krav på Source networks, Incoming interface, användare eller applikation. För brandväggens egen trafik bör framför allt Destination networks och Services avgöra. Om motparten förväntar sig en viss källadress ska även Source IP och en möjlig sys-traffic-nat-konfiguration kontrolleras.

Fel och beroenden

Vanliga fel

• SD-WAN Route med Destination Any för interna vägar: Intern trafik eller hanteringsåtkomst kan routas via WAN. Använd hellre internetmålgrupper eller specifika målnätverk.
• Route Precedence placerar SD-WAN före Static: Direktanslutna eller statiska nätverk kan oväntat matchas av SD-WAN. Kontrollera Route Precedence och placera vid behov Static före SD-WAN.
• system-generate-traffic är aktiv utan avgränsning av mål: Brandväggens egna tjänster kan använda fel väg. Definiera därför målnätverk och Services snävt.
• Reply Packets förväxlas med vanliga nya anslutningar: Då bearbetas fel orsak. Kontrollera Packet Capture och flödesriktningen.
• En Firewall Rule söks för systemgenererad trafik: Trafiken har Firewall Rule ID 0 och styrs inte av vanliga Firewall Rules. Kontrollera route, service, Live Connection och vid behov sys-traffic-nat.
• Direct Web Proxy behandlas som vanlig HTTP/HTTPS-trafik: För Direct Web Proxy måste SD-WAN Route omfatta porten som är konfigurerad under Web > General settings > Web proxy listening port. Alternativt kan Services vara Any. Source Network och Incoming Interface matchar inte Reply Packets för proxytrafiken. Returvägen kräver minst en WAN-gateway eller en lämplig statisk route.
• Flera routingändringar görs samtidigt: Felorsaken förblir oklar. Ändra stegvis och dokumentera varje test.
• Ingen alternativ hanteringsåtkomst finns: WebAdmin eller SSH kan gå förlorad från det berörda nätverket. Förbered ett underhållsfönster och en åtkomstväg.

En särskilt kritisk risk uppstår när flera villkor sammanfaller: Route Precedence placerar SD-WAN före Static, en bred SD-WAN Route använder Any och SD-WAN-routing för systemgenererad trafik eller Reply Packets är aktiv. Då kan åtkomsten till WebAdmin eller SSH gå förlorad från vissa interna subnät.

Samspel med NAT, IPsec och VoIP

SD-WAN är sällan den enda inblandade komponenten. Vid många störningar spelar även NAT, IPsec eller applikationsspecifik trafik en roll.

För SNAT är det viktigt om samma Source IP behålls via olika gateways. Om MASQ eller olika översatta källadresser används kan Failover eller Rerouting orsaka kommunikationsproblem. Grunderna finns i Förstå NAT på Sophos Firewall.

För route-based IPsec VPN kan XFRM-interfaces användas i SD-WAN Routes eller SD-WAN Profiles. Då bör IPsec-status, SD-WAN Route, Route Precedence och Firewall Rules kontrolleras tillsammans. Grunderna för route-based VPN beskrivs i IPsec Route på Sophos Firewall.

Vid VoIP-problem bör även SIP, RTP, NAT och SD-WAN kontrolleras. Release Notes för SFOS 22.0 MR1 dokumenterar ett åtgärdat problem där VoIP-ljud efter en uppgradering till SFOS 22.0 GA bara fungerade i en riktning via route-based VPN med SD-WAN-routing. Det praktiska arbetsflödet finns i Åtgärda VoIP-problem med SIP och RTP på Sophos Firewall.

Återställning och avslutning

Återställning

Dokumentera det gamla läget före ändringen. Om hanteringsåtkomst, systemtjänster eller produktiv trafik påverkas efteråt ska du inte fortsätta improvisera. Återställ först det tidigare läget.

I praktiken innebär det:

1. Återställ de dokumenterade tidigare värdena för reply-packet och system-generate-traffic med motsvarande enable- eller disable-kommandon.
2. Återställ Route Precedence till den tidigare ordningen om den ändrades.
3. Inaktivera tillfälligt alltför breda SD-WAN Routes eller begränsa dem till specifika mål.
4. Testa hanteringsåtkomst från ett nätverk som inte berörs.
5. Fortsätt först därefter att avgränsa den egentliga orsaken.

Om åtkomsten till WebAdmin och SSH går förlorad från ett internt subnät men fortfarande fungerar från ett annat, ska du därifrån först kontrollera den breda SD-WAN Route, Route Precedence och de två CLI-alternativen.

Checklista

• Aktuell status för de två CLI-alternativen har dokumenterats.
• Route Precedence har dokumenterats med system route_precedence show.
• Den berörda trafiken har definierats exakt.
• För systemtrafik används endast Destination och Service som avgörande matchningskriterier.
• SD-WAN Route har inte gjorts onödigt bred med Any.
• Route Precedence har kontrollerats.
• Minst en WAN-gateway för System Traffic är Active.
• En alternativ hanteringsanslutning har förberetts.
• Endast en ändring har gjorts per test.
• Log Viewer och Packet Capture har använts för validering.
• NAT, IPsec och Firewall Rules har kontrollerats samtidigt.
• Resultat och återställning har dokumenterats i driftjournalen.

FAQ