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 skapas av Sophos Firewall själv. Exempel är DNS-frågor, signaturnedladdningar och autentiseringsförfrågningar. För tjänster som DHCP, SNMP och Syslog beror klassificeringen på rollen och trafikriktningen; all trafik till en brandväggstjänst är inte en utgående, systemgenererad anslutning. Som standard skickar brandväggen sin egen trafik via 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.

En vanlig brandväggsregel krävs inte för den här trafiken. Under Current activities > Live connections har systemgenererad trafik därför Firewall Rule ID 0. Local service ACL under Administration > Device access är en separat funktion: den styr åtkomsten till brandväggens lokala tjänster, inte valet av utgående SD-WAN-väg. Om en specifik käll-IP-adress krävs räcker inte heller en vanlig SNAT-regel: NAT-regler översätter vidarebefordrad trafik, medan brandväggstrafik beroende på scenario kan kräva 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.

Nå en autentiseringsserver via route-based IPsec

Ett viktigt specialfall är en AD- eller LDAP-server på huvudkontoret som en filialbrandvägg själv måste nå via en route-based IPsec-tunnel. En vanlig regel från LAN till VPN styr inte denna begäran eftersom brandväggen genererar trafiken. Med en any-to-any-tunnel och adresserade XFRM-gränssnitt måste därför både fram- och returvägen planeras medvetet.

Följande exempel använder 10.10.1.1 som filialbrandväggens synliga källadress, 10.10.2.15 som AD-server och TCP 636 för LDAPS. Dessa värden är inte produktstandarder. De ska ersättas med en filialadress som tillåts i tunneln och har en returrutt på huvudkontoret, den faktiska servern och den autentiseringstjänst som verkligen är konfigurerad.

1. Skapa en avgränsad SD-WAN Route på filialbrandväggen med Source networks inställt på Any, AD-värden som Destination networks och den autentiseringstjänst som behövs. TCP 636 passar endast om servern faktiskt använder LDAPS. Använd den fjärranslutna XFRM-adressen via det lokala XFRM-gränssnittet som Primary Gateway.
2. Aktivera Route only through specified gateways endast om begäran avsiktligt ska avvisas när tunneln inte är tillgänglig. Kontrollera reglaget för systemgenererad trafik enligt beskrivningen ovan och aktivera det kontrollerat för detta förfarande.
3. Använd först show advanced-firewall i Device Console för att dokumentera befintliga sys-traffic-nat-poster och deras ordning. Använd sedan käll-NAT för att mappa brandväggens egen adress till den planerade filialadressen. Adressen måste stämma överens med reglerna för tunneln och returvägen:

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

4. Skapa en SD-WAN Route för returvägen på huvudkontorets brandvägg, från AD-värden till den översatta filialadressen via den fjärranslutna XFRM-adressen. Håll Source, Destination och Service lika avgränsade som på filialsidan.
5. Skapa loggade regler på huvudkontoret från VPN till servernätverket och från servernätverket tillbaka till VPN, med de konkreta värdarna och tjänsterna. Breda exempel med Any i produktanvisningar är inte lämpliga som permanent konfiguration.
6. Ping/Ping6 under Administration > Device access för zonen VPN behövs endast om Probe target är en lokal brandväggs- eller XFRM-adress. För en vidarebefordrad värd bakom tunneln krävs i stället rätt tunnel, rutt och vid behov en Firewall Rule. Återställ en tillfällig behörighet under Device access till det tidigare läget efter testet.

Vid verifieringen ska ett verkligt anslutningstest mot servern och en användarinloggning genomföras. På filialbrandväggen visas systemgenererad trafik under Current activities > Live connections med Firewall Rule ID 0; på huvudkontoret måste de förväntade loggade reglerna matcha. Packet Capture måste visa begäran och svaret på de planerade XFRM-gränssnitten. En lyckad ping bekräftar inte i sig LDAPS, autentisering eller returvägen.

Vid återställningen kontrollerar du först om de två SD-WAN-rutterna, reglerna, gatewayobjekten och en tillfällig Ping/Ping6-behörighet har andra beroenden. Ta bort NAT-posten med exakt samma urvalsvillkor. Om även netmask eller interface användes när posten skapades ska de också ingå i raderingskommandot:

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

Kontrollera sedan med show advanced-firewall att endast den avsedda posten har försvunnit. Ta därefter endast bort rutter, regler och objekt som skapades för det här arbetsflödet, återställ de båda globala SD-WAN-inställningarna och Route Precedence till de dokumenterade tidigare värdena och testa den ursprungliga datavägen igen.

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.

Under Routing > SD-WAN routes ska det också vara tydligt hur varje berörd rutt reagerar om en gateway slutar fungera. Med Route only through specified gateways kasserar brandväggen trafiken om de angivna gatewayarna inte är tillgängliga. Utan alternativet kontrollerar den efterföljande SD-WAN Routes och därefter WAN Link Load Balancing. Om vald Primary Gateway eller valt SD-WAN Profile tas bort, tar SFOS även bort rutten. Om endast Backup Gateway tas bort blir rutten kvar med None som backup.

Ä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 SD-WAN-ruttens OUT-/IN-rä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

Kontrollera före testet under System services > Log settings om SD-WAN loggas. Posterna visas i modulen SD-WAN i Log viewer. För vidarebefordrad trafik måste dessutom Log firewall traffic vara aktivt på relevant Firewall Rule. Dokumentera det tidigare loggningsläget och återställ det efter testet om loggningen bara aktiverades tillfälligt.

Systemgenererad trafik styrs inte av en brandväggsregel. Under Current activities > Live connections kan den identifieras med Firewall Rule ID 0 samt dess inkommande och utgående gränssnitt. Local service ACL är fortfarande den separata kontrollen för åtkomst till brandväggens lokala tjänster.

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?
• Visar Status Generated för förfrågningar från brandväggen själv och, i förekommande fall, Consumed för svar som levereras till brandväggen?
• Stämmer Gateway ID, NAT ID samt Inbound- och Outbound-interface med den planerade vägen?

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

Kontrollera den berörda systemtjänsten

Enbart en ruttträff visar inte att tjänsten fungerar. Dokumentera mål-IP-adress, port, förväntad käll-IP-adress och förväntat utgående gränssnitt före testet. Utlös sedan exakt den berörda funktionen, till exempel en autentiseringsförfrågan eller ett DNS-uppslag från brandväggen, och kontrollera både Packet Capture och verifieringen hos motparten. Använd ett mål som inte matchar eller en annan tjänst som negativt test; den snäva rutten får inte matcha denna trafik.

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 att kontrollera om samma käll-IP-adress behålls via olika gateways. Läs av det aktuella tillståndet i Device Console med show routing reroute-connection och show routing reroute-snat-connection. SFOS kan dirigera om anslutningar efter ett gatewayfel, men SNAT-anslutningar måste behålla samma översatta käll-IP-adress på båda vägarna. MASQ eller olika översatta adresser kan avbryta en aktiv anslutning vid omdirigering. De här två värdena läses endast av i artikeln; de ändras inte. Grunderna beskrivs 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. Återställ ändrade SD-WAN-rutter till deras dokumenterade tidigare värden. Ta endast bort rutter som skapades för testet efter att beroendena har kontrollerats.
4. Ta bort tillfälliga sys-traffic-nat-poster med exakt samma urvalsvillkor och kontrollera resultatet med show advanced-firewall.
5. Återställ brandväggsregler, gatewayobjekt, behörigheter under Device access och loggningsinställningar som endast ändrades för testet.
6. Testa hanteringsåtkomsten och den ursprungliga datavägen från ett nätverk som inte berörs.
7. 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