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

SD-WAN Rutter på Sophos Firewall är inte bara relevanta för klassisk klient-till-internet-trafik. Beroende på miljön kan Reply Packets och systemgenererad trafik också påverkas. Det är precis där routingproblem som är svåra att upptäcka ofta uppstår: regeln ser korrekt ut, Gateway är aktiv, men svar går via fel väg eller så når inte brandväggen själv en tjänst via den förväntade linjen.

Den här guiden förklarar de två CLI-alternativen reply-packet och system-generate-traffic, när du ska kontrollera dem och hur du säkert testar ändringar. För den normala SD-WAN-ruttkonfigurationen passar Set up and test Sophos Firewall SD-WAN route and test först. För den allmänna ordningen mellan statiska rutter, SD-WAN policyrutter och VPN rutter, passar Sophos Firewall säkert ändra Route Precedence också.

⚠️ Dessa inställningar kan omedelbart påverka produktiv routing. Innan du gör en ändring bör du dokumentera aktuell status, välja ett underhållsfönster och veta en tydlig väg tillbaka. Särskilt kritiska är breda SD-WAN-rutter med Any, Route Precedence framför statiska rutter och aktiverad SD-WAN-routing för System Traffic eller Reply Packets.

Vad de två alternativen handlar om

Med SD-WAN Routes måste du skilja på normal vidarebefordrad trafik, svarspaket och trafik som brandväggen själv genererar. De två alternativen avgör inte om en enda SD-WAN-rutt är korrekt byggd. Istället utökar de vilken trafiktyp som kan beaktas av SD-WAN Policy Routing.

De två alternativen har olika uppgifter:

• reply-packet: Påverkar svarspaket på befintlig trafik. Detta gör att returvägen kan påverkas via SD-WAN i vissa scenarier som inte är WAN.
• system-generate-traffic: Påverkar trafik som genereras av själva brandväggen. Detta gör att brandväggsspecifika anslutningar kan dirigeras via definierade SD-WAN-rutter.

Båda alternativen ska inte aktiveras blint bara för att “SD-WAN inte fungerar”. Först måste det vara klart om Reply Packets eller systemgenererad trafik verkligen påverkas. För normala anslutningar är den faktiska orsaken ofta brandväggsregeln, NAT, Route Precedence, Gateway status eller en SD-WAN-rutt som är för bred.

Reply Packets

Reply Packets är svarspaket till befintlig trafik. Sophos Firewall upprätthåller i allmänhet symmetrisk routing för sådana svar på WAN-gränssnitt: svarspaket bör återvända över samma WAN-gränssnitt som den ursprungliga anslutningen kom in genom. Alternativet reply-packet är särskilt relevant om svarspaket ska beaktas i vissa SD-WAN Policy Routing-scenarier. Ett typiskt exempel är asymmetrisk routing på icke-WAN-gränssnitt, såsom mellan LAN och DMZ.

Den viktiga begränsningen är: Om den ursprungliga trafiken går via standardrutten eller WAN länkbelastningsbalansering, gäller inte SD-WAN-rutter för denna Reply Packets. Brandväggen fortsätter sedan att använda lämplig returväg via gränssnittet för den ursprungliga anslutningen.

Typiska testfrågor:

• Är det verkligen svarstrafik och inte en ny anslutning?
• Går trafiken genom WAN, LAN, DMZ, XFRM eller någon annan zon?
• Finns det en SD-WAN-rutt som är avsedd att påverka returvägen?
• Är rutten för bred, till exempel destination Any?
• Gäller Route Precedence före en statisk rutt eller VPN rutt?

Systemgenererad trafik

Systemgenererad trafik är trafik som Sophos Firewall genererar själv. Beroende på miljön kan detta inkludera DNS, NTP, Sophos Central, Syslog, uppdateringar, övervakning, autentiseringstjänster eller diagnostiska anslutningar.

Med denna trafik känner inte brandväggen igen ett normalt inkommande gränssnitt och ett normalt källnätverk som med vidarebefordrad klienttrafik. Det är därför du bör planera SD-WAN-rutter särskilt noga för systemgenererad trafik: målnätverk och Services måste väljas med förnuft. En mycket bred rutt kan annars oväntat dra lednings- eller systemtrafik på fel väg.

Dessutom gäller två praktiska begränsningar:

• Om alla konfigurerade gateways under Network > WAN link manager endast är markerade som Backup, kommer brandväggen inte att vidarebefordra systemgenererad trafik genom dem. Minst en Gateway måste vara aktiv.
• Systemgenererad RED-trafik på UDP 3410 är lager 2-trafik. SD-WAN Rutter gäller inte för detta.

När ska dessa inställningar kontrolleras

De två alternativen är särskilt relevanta för mer komplexa routingdesigner. I enkla enkla WAN-miljöer är de sällan den första spaken.

Användbara triggers:

• Inbyggd brandväggstrafik använder inte den förväntade sökvägen WAN eller VPN.
• Syslog, Central, DNS, NTP eller övervakning ska köras över en specifik linje.
• Ruttbaserad IPsec VPN med XFRM-gränssnitt används tillsammans med SD-WAN Routes.
• VoIP eller annan känslig trafik fungerar bara i en riktning via SD-WAN/VPN.
• Packet Capture visar svar på ett annat gränssnitt än förväntat.
• Efter en uppgradering beter sig SD-WAN, IPsec eller NAT annorlunda än tidigare.
• En bred SD-WAN-rutt påverkar plötsligt interna nätverk eller ledningsåtkomst. För IPsec-scenarier bör du också inkludera Sophos Firewall IPsec VPN Felsökning. För individuella anslutningar är Sophos Firewall regeltest med Log Viewer och Packet Capture ofta en bättre utgångspunkt.

Visa aktuell status

Kommandona exekveras i Device Console, inte i Advanced Shell. Om konsolåtkomsten ännu inte är klar, hjälper Anslut 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

Dessutom visar WebAdmin under Routing > SD-WAN routes i routinginformationens verktygstips om SD-WAN routing är aktiv för systemgenererad trafik och Reply Packets.

Innan du gör några ändringar bör den aktuella utgåvan dokumenteras. Detta är viktigt eftersom en senare återställning endast är möjlig om det tidigare tillståndet är känt.

Aktivera alternativ

SD-WAN Aktivera routing för Reply Packets:

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

SD-WAN Aktivera routing för systemgenererad trafik:

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

Utför sedan statuskommandona igen och dokumentera resultatet.

⚠️ Gör inte flera ruttändringar samtidigt. Om Route Precedence, SD-WAN-rutten, NAT-regeln och dessa CLI-alternativ ändras samtidigt, är det svårt att tydligt tillskriva ett fel efteråt.

Säkert flöde för ändringar

En pragmatisk process minskar risken:

1. Definiera påverkad trafik specifikt: Källa, Destination, Service, Zon, förväntad Gateway.
2. Dokumentera befintliga SD-WAN-rutter, gateways och Route Precedence.
3. Kontrollera om Destination Any verkligen är nödvändig.
4. Dokumentera aktuell status för reply-packet och system-generate-traffic.
5. Ändra endast ett alternativ.
6. Kör testet med ett tydligt trafikexempel.
7. Kontrollera räknarna för Log Viewer, Packet Capture och Gateway.
8. Dokumentera resultatet och gör först därefter ytterligare justeringar. Om hanteringsåtkomst kan påverkas bör ett sekundärt åtkomstsätt vara tillgängligt: ​​lokal konsol, annan intern åtkomstväg eller åtkomst från ett opåverkat hanteringsnätverk.

Validering efter ändring

Efter aktivering räcker inte en grön Gateway-status. Du måste kontrollera om den önskade trafiken verkligen tar den förväntade vägen.

Log Viewer och SD-WAN loggar

Brandvägg och SD-WAN relaterade händelser bör kontrolleras i Logg viewer. För relevanta brandväggsregler måste Log firewall traffic vara aktiv. Utan loggning ser man ofta bara en del av beslutet.

För att kontrollera:

• Vilken Firewall Rule ID träffas?
• Vilken NAT Rule ID används?
• Vilken Gateway eller vilket gränssnitt visas i loggen?
• Finns det några fall, policyöverträdelser eller oväntade beslut om säkerhetsfunktioner?

Packet Capture

Det faktiska paketflödet kan kontrolleras med Diagnostics > Packet capture. För routingfrågor bör filtret vara smalt: Källa IP, Destination IP, Port och Protocol.

Jämförelsen är viktig:

• Kommer paketet till det förväntade gränssnittet?
• Stänger den brandväggen på det förväntade gränssnittet? – Kommer svaret tillbaka?
• Används NAT?
• Är returvägen rimlig för Reply Packets?

Använd Sophos Firewall Packet Capture i WebAdmin är lämplig för drift och tolkning.

Kontrollera systemtjänster

I fallet med systemgenererad trafik bör du specifikt testa den berörda tjänsten:

• DNS: Kör DNS-sökning på brandväggen och kontrollera målsökvägen.
• NTP: Kontrollera tidsstatus och tillgänglighet för NTP-servern.
• Syslog: Kontrollera testmeddelandet eller aktuell logg på uppsamlaren.
• Sophos Central: Kontrollera central anslutning och rapportering.
• Övervakning: Kontrollera SNMP, sFlow eller externa kontroller på uppsamlaren.

Om systemgenererad trafik inte är synlig bör du också kontrollera om SD-WAN-rutten endast ska matcha källnätverk eller inkommande gränssnitt. Dessa kriterier är inte tillgängliga för brandväggsägd trafik som de är för klienttrafik.

Typiska fel

• SD-WAN-rutt med destination Any för interna vägar: Intern trafik eller hanteringsåtkomst kan dirigeras via WAN. Internetmålgrupper eller specifika målnätverk är bättre.
• Route Precedence ställer in SD-WAN före Static: Direktanslutna eller statiska nätverk kan oväntat matchas av SD-WAN. Kontrollera Route Precedence och ställ in Statisk framför SD-WAN vid behov.
• system-generate-traffic aktiv utan destinationsbegränsning: Brandväggsspecifika tjänster kan använda fel sökväg. Definiera därför målnätverk och Services noggrant.
• Reply Packets förväxlas med normala nya anslutningar: Då behandlas fel orsak. Packet Capture och kontrollera flödesriktningen.
• Flera ruttändringar samtidigt: Orsaken till felet är fortfarande oklar. Ändra gradvis och dokumentera varje test.
• Ingen alternativ hanteringsåtkomst: WebAdmin eller SSH kan gå förlorad från det berörda nätverket. Förbered underhållsfönster och åtkomstväg.

En särskilt kritisk risk uppstår när flera tillstånd möts: Route Precedence är på SD-WAN före statisk, en bred SD-WAN-rutt använder Any och SD-WAN-routing för systemgenererad trafik eller Reply Packets är aktiv. I det här fallet kan åtkomst till WebAdmin eller SSH från vissa interna subnät försvinna.

Interaktion med NAT, IPsec och VoIP

SD-WAN är sällan inblandad ensam. NAT, IPsec eller applikationsspecifik trafik spelar en roll i många störningar. Det som är viktigt för SNAT är om samma källa IP upprätthålls över olika gateways. Om MASQ eller andra översatta källadresser används kan failover eller omdirigering orsaka kommunikationsproblem. För grunderna, Förstå NAT passar Sophos Firewall.

För ruttbaserade IPsec VPN:er kan XFRM-gränssnitt användas i SD-WAN-rutter eller SD-WAN-profiler. Sedan bör IPsec-status, SD-WAN-rutt, Route Precedence och brandväggsregler kontrolleras tillsammans. De ruttbaserade VPN grunderna är kategoriserade i IPsec Route på Sophos Firewall. Om du har VoIP-problem är det också värt att titta på SIP, RTP, NAT och SD-WAN. Releasenoterna SFOS-22.0-MR1 dokumenterar ett fixat problem där VoIP-ljud endast fungerade envägs via ruttbaserad VPN med SD-WAN-routing efter uppgradering till SFOS 22.0 GA. Den praktiska processen finns i Sophos Firewall Fix VoIP-problem med SIP och RTP.

Återställ

Innan du gör ändringar bör den gamla statusen dokumenteras. Om ledningsåtkomst, systemtjänster eller produktiv trafik sedan påverkas är improvisation inte längre nödvändig. Återställ först det tidigare tillståndet.

I praktiken betyder detta:

1. Återställ dokumenterade före värden för reply-packet och system-generate-traffic.
2. Återställ Route Precedence till föregående beställning om den ändras.
3. Inaktivera tillfälligt SD-WAN-rutter som är för breda eller begränsa dem till specifika destinationer.
4. Testa hanteringsåtkomst från ett opåverkat nätverk.
5. Begränsa sedan den faktiska orsaken ytterligare.

Om åtkomst till WebAdmin och SSH förloras från ett internt subnät men fortfarande är möjligt från ett annat subnät, bör den breda SD-WAN-rutten, Route Precedence och de två CLI-alternativen kontrolleras därifrån först.

Checklista

• Aktuell status för de två dokumenterade CLI-alternativen.
• Berörd trafik specifikt definierad.
• Rutten SD-WAN är inte byggd onödigt bred med Any.
• Route Precedence kontrolleras.
• Minst en WAN-Gateway för System Traffic tillgänglig som Aktiv.
• Alternativ ledningsanslutning förberedd.
• Gjorde bara en ändring per test.
• Log Viewer och Packet Capture används för validering.
• NAT, IPsec och brandväggsregler kontrollerade.
• Resultat och rollback dokumenteras i driftjournalen.

Vanliga frågor