Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen

SD-WAN Routes auf Sophos Firewall sind nicht nur für klassischen Client-zu-Internet-Traffic relevant. Je nach Umgebung können auch Reply Packets und systemgenerierter Traffic betroffen sein. Genau dort entstehen oft schwer erkennbare Routing-Probleme: Die Regel sieht korrekt aus, der Gateway ist aktiv, aber Antworten laufen über den falschen Pfad oder die Firewall selbst erreicht einen Dienst nicht über die erwartete Leitung.

Diese Anleitung erklärt die beiden CLI-Optionen reply-packet und system-generate-traffic, wann man sie prüfen sollte und wie man Änderungen sicher testet. Für den normalen SD-WAN-Route-Aufbau passt zuerst Sophos Firewall SD-WAN Route einrichten und testen. Für die generelle Reihenfolge zwischen statischen Routen, SD-WAN Policy Routes und VPN-Routen passt zusätzlich Sophos Firewall Route Precedence sicher ändern.

⚠️ Diese Einstellungen können produktives Routing sofort beeinflussen. Vor einer Änderung sollte man den aktuellen Zustand dokumentieren, ein Wartungsfenster wählen und einen klaren Rückweg kennen. Besonders kritisch sind breite SD-WAN Routes mit Any, Route Precedence vor Static Routes und aktiviertes SD-WAN Routing für System Traffic oder Reply Packets.

Grundlagen und Grenzen

Worum es bei den beiden Optionen geht

Bei SD-WAN Routes muss man zwischen normalem weitergeleitetem Traffic, Antwortpaketen und Traffic unterscheiden, den die Firewall selbst erzeugt. Die beiden Optionen entscheiden nicht, ob eine einzelne SD-WAN Route korrekt gebaut ist. Stattdessen erweitern sie, welcher Traffic-Typ überhaupt von SD-WAN Policy Routing berücksichtigt werden kann.

Die beiden Optionen haben unterschiedliche Aufgaben:

• reply-packet: Betrifft Antwortpakete zu bestehendem Traffic. Damit lässt sich der Rückweg in bestimmten Nicht-WAN-Szenarien über SD-WAN beeinflussen.
• system-generate-traffic: Betrifft Traffic, den die Firewall selbst erzeugt. Damit können firewall-eigene Verbindungen über definierte SD-WAN Routes geführt werden.

Beide Optionen sollten nicht blind aktiviert werden, nur weil “SD-WAN nicht greift”. Zuerst muss klar sein, ob wirklich Reply Packets oder systemgenerierter Traffic betroffen sind. Für normale Verbindungen sind oft Firewall-Regel, NAT, Route Precedence, Gateway-Status oder eine zu breite SD-WAN Route die eigentliche Ursache.

Reply Packets

Reply Packets sind Antwortpakete zu bestehendem Traffic. Sophos Firewall erzwingt auf WAN-Interfaces grundsätzlich symmetrisches Routing für solche Antworten: Antwortpakete sollen über dasselbe WAN-Interface zurückgehen, über das die ursprüngliche Verbindung hereingekommen ist.

Die Option reply-packet ist vor allem dann relevant, wenn Antwortpakete in bestimmten Szenarien von SD-WAN Policy Routing berücksichtigt werden sollen. Ein typisches Beispiel ist asymmetrisches Routing auf Nicht-WAN-Interfaces, etwa zwischen LAN und DMZ.

Wichtig ist die Einschränkung: Wenn der ursprüngliche Traffic über die Default Route beziehungsweise WAN Link Load Balancing läuft, gelten SD-WAN Routes nicht für diese Reply Packets. Dann verwendet die Firewall weiterhin den passenden Rückweg über das Interface der ursprünglichen Verbindung.

Typische Prüffragen:

• Handelt es sich wirklich um Antworttraffic und nicht um eine neue Verbindung?
• Läuft der Traffic über WAN, LAN, DMZ, XFRM oder eine andere Zone?
• Gibt es eine SD-WAN Route, die den Rückweg absichtlich beeinflussen soll?
• Ist die Route zu breit, zum Beispiel Destination Any?
• Greift Route Precedence vor einer statischen Route oder VPN-Route?

Systemgenerierter Traffic

Systemgenerierter Traffic ist Traffic, den die Sophos Firewall selbst erzeugt. Dazu können je nach Umgebung DNS-Anfragen, Signaturdownloads, Authentifizierungsanfragen, DHCP, NTP, Syslog oder Verbindungen zu Sophos Central gehören. Standardmässig verwendet dieser Traffic die aktiven WAN-Gateways aus Network > WAN link manager.

Bei diesem Traffic sind Incoming interface und Source networks nicht bekannt und daher keine geeigneten Selektoren. Für eine SD-WAN Route, die Firewall-Traffic erfassen soll, werden deshalb nur Destination networks und Services gezielt eingeschränkt; die übrigen Kriterien bleiben breit. Eine Route mit Destination Any kann sonst System- und Managementtraffic unerwartet auf einen falschen Pfad ziehen.

Eine normale Firewall-Regel ist dafür nicht erforderlich. In Current activities > Live connections trägt systemgenerierter Traffic deshalb die Firewall Rule ID 0. Wenn eine bestimmte Source-IP nötig ist, reicht eine normale SNAT-Regel ebenfalls nicht: NAT-Regeln übersetzen weitergeleiteten Traffic, für Firewall-Traffic ist je nach Szenario sys-traffic-nat auf der Device Console erforderlich.

Zusätzlich gelten zwei praktische Grenzen:

• Wenn alle konfigurierten Gateways unter Network > WAN link manager nur als Backup markiert sind, leitet die Firewall systemgenerierten Traffic nicht darüber weiter. Mindestens ein Gateway muss Active sein.
• Systemgenerierter RED-Traffic auf UDP 3410 ist Layer-2-Traffic. SD-WAN Routes gelten dafür nicht.

Vorbereitung

Wann man diese Einstellungen prüfen sollte

Die beiden Optionen sind vor allem bei komplexeren Routing-Designs relevant. In einfachen Single-WAN-Umgebungen sind sie selten der erste Hebel.

Sinnvolle Auslöser:

• Firewall-eigener Traffic nutzt nicht den erwarteten WAN- oder VPN-Pfad.
• Syslog, Central, DNS, NTP oder Monitoring soll über eine bestimmte Leitung laufen.
• Route-based IPsec VPN mit XFRM-Interfaces wird zusammen mit SD-WAN Routes verwendet.
• VoIP oder anderer sensibler Traffic funktioniert über SD-WAN/VPN nur in eine Richtung.
• Packet Capture zeigt Antworten auf einem anderen Interface als erwartet.
• Nach einem Upgrade verhalten sich SD-WAN, IPsec oder NAT anders als zuvor.
• Eine breite SD-WAN Route beeinflusst plötzlich interne Netze oder Management-Zugriff.

Bei IPsec-Szenarien sollte man zusätzlich Sophos Firewall IPsec VPN Troubleshooting einbeziehen. Bei einzelnen Verbindungen ist Sophos Firewall Regel testen mit Log Viewer und Packet Capture oft der bessere Startpunkt.

Aktuellen Status anzeigen

Die Befehle werden in der Device Console ausgeführt, nicht in der Advanced Shell. Wenn der Konsolenzugriff noch nicht klar ist, hilft Sophos Firewall per SSH verbinden.

Status für Reply Packets prüfen:

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

Status für systemgenerierten Traffic prüfen:

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

Zusätzlich zeigt der WebAdmin unter Routing > SD-WAN routes im Tooltip zur Routing-Information, ob SD-WAN Routing für systemgenerierten Traffic und Reply Packets aktiv ist.

Die aktuelle Route Precedence sollte ebenfalls dokumentiert werden:

system route_precedence show

Vor jeder Änderung sollte die aktuelle Ausgabe dokumentiert werden. Das ist wichtig, weil ein späterer Rollback nur sauber möglich ist, wenn der vorherige Zustand bekannt ist.

Konfiguration ändern

Optionen aktivieren oder deaktivieren

SD-WAN Routing für Reply Packets aktivieren:

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

SD-WAN Routing für systemgenerierten Traffic aktivieren:

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

Danach die Statusbefehle erneut ausführen und die Ausgabe dokumentieren.

Zum gezielten Deaktivieren dienen die Gegenbefehle:

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

⚠️ Nicht mehrere Routing-Änderungen gleichzeitig durchführen. Wenn Route Precedence, SD-WAN Route, NAT-Regel und diese CLI-Optionen gleichzeitig geändert werden, lässt sich ein Fehler danach kaum sauber zuordnen.

Sicherer Ablauf für Änderungen

Ein pragmatischer Ablauf reduziert das Risiko:

1. Betroffenen Traffic konkret definieren: Source, Destination, Service, Zone, erwarteter Gateway.
2. Bestehende SD-WAN Routes, Gateways und Route Precedence dokumentieren.
3. Prüfen, ob Destination Any wirklich nötig ist.
4. Aktuellen Status von reply-packet und system-generate-traffic dokumentieren.
5. Nur eine Option ändern.
6. Test mit einem klaren Traffic-Beispiel durchführen.
7. Log Viewer, Packet Capture und Gateway-Zähler prüfen.
8. Ergebnis dokumentieren und erst danach weitere Anpassungen vornehmen.

Wenn Management-Zugriff betroffen sein könnte, sollte eine zweite Zugriffsmöglichkeit vorhanden sein: lokale Konsole, anderer interner Zugriffspfad oder Zugriff aus einem nicht betroffenen Managementnetz.

Validierung nach der Änderung

Nach dem Aktivieren reicht ein grüner Gateway-Status nicht aus. Man muss prüfen, ob der gewünschte Traffic wirklich den erwarteten Pfad nimmt.

Live Connections, Log Viewer und SD-WAN-Zähler

Für weitergeleiteten Traffic sollten im Log viewer Firewall- und SD-WAN-bezogene Events geprüft werden. Bei relevanten Firewall Rules muss Log firewall traffic aktiv sein. Systemgenerierter Traffic wird dagegen nicht durch eine Firewall-Regel gesteuert. Er lässt sich unter Current activities > Live connections anhand der Firewall Rule ID 0 sowie der Inbound- und Outbound-Interfaces erkennen.

Zu prüfen:

• Handelt es sich um weitergeleiteten Traffic mit Firewall Rule ID oder um Systemtraffic mit ID 0?
• Welche NAT Rule ID wird bei weitergeleitetem Traffic verwendet?
• Welcher Gateway oder welches Interface erscheint im Log?
• Gibt es Drops, Policy-Verletzungen oder unerwartete Security-Feature-Entscheidungen?
• Zeigt die SD-WAN Route nur OUT für Requests oder auch IN für Replies? Die Zähler erscheinen nur, wenn Source- und Destination-Kriterien zur jeweiligen Richtung passen.

Packet Capture

Mit Diagnostics > Packet capture lässt sich der tatsächliche Paketfluss prüfen. Für Routing-Fragen sollte der Filter eng sein: Source IP, Destination IP, Port und Protokoll.

Wichtig ist der Vergleich:

• Kommt das Paket auf dem erwarteten Interface an?
• Verlässt es die Firewall auf dem erwarteten Interface?
• Kommt die Antwort zurück?
• Wird NAT angewendet?
• Ist bei Reply Packets der Rückweg plausibel?

Für die Bedienung und Interpretation passt Sophos Firewall Packet Capture im WebAdmin verwenden.

Systemdienste prüfen

Bei systemgeneriertem Traffic sollte man den betroffenen Dienst gezielt testen:

• DNS: DNS-Lookup auf der Firewall ausführen und Zielpfad prüfen.
• NTP: Zeitstatus und Erreichbarkeit des NTP-Servers prüfen.
• Syslog: Testmeldung oder aktuelles Log am Collector kontrollieren.
• Sophos Central: Central-Verbindung und Reporting prüfen.
• Monitoring: SNMP, sFlow oder externe Checks am Collector prüfen.

Wenn systemgenerierter Traffic nicht sichtbar wird, sollte man prüfen, ob die Route mit Source networks, Incoming interface, Benutzer oder Anwendung unnötige Kriterien voraussetzt. Für Firewall-eigenen Traffic sollten vor allem Destination networks und Services entscheiden. Falls die Gegenstelle eine bestimmte Quelladresse erwartet, zusätzlich die Source-IP und eine mögliche sys-traffic-nat-Konfiguration prüfen.

Fehler und Abhängigkeiten

Typische Fehler

• SD-WAN Route mit Destination Any für interne Pfade: Interner Traffic oder Managementzugriff kann über WAN geroutet werden. Besser sind Internet-Zielgruppen oder konkrete Zielnetze.
• Route Precedence setzt SD-WAN vor Static: Direkt verbundene oder statische Netze können unerwartet von SD-WAN gematcht werden. Route Precedence prüfen und bei Bedarf Static vor SD-WAN setzen.
• system-generate-traffic ohne Zielbegrenzung aktiv: Firewall-eigene Dienste können den falschen Pfad nutzen. Zielnetze und Services deshalb eng definieren.
• Reply Packets mit normalen neuen Verbindungen verwechselt: Dann wird die falsche Ursache bearbeitet. Packet Capture und Flow-Richtung prüfen.
• Firewall-Regel für systemgenerierten Traffic gesucht: Dieser Traffic hat Firewall Rule ID 0; normale Firewall-Regeln steuern ihn nicht. Route, Dienst, Live Connection und gegebenenfalls sys-traffic-nat prüfen.
• Direct Web Proxy wie normalen HTTP/HTTPS-Traffic behandelt: Beim direkten Proxy muss die SD-WAN Route den unter Web > General settings > Web proxy listening port konfigurierten Port abdecken. Alternativ kann Services auf Any stehen. Source Network und Incoming Interface matchen Reply Packets des Proxy-Traffics nicht; für den Rückweg braucht es mindestens ein WAN-Gateway oder eine passende statische Route.
• Mehrere Routing-Änderungen gleichzeitig: Die Fehlerursache bleibt unklar. Schrittweise ändern und jeden Test dokumentieren.
• Kein alternativer Managementzugang: WebAdmin oder SSH kann aus dem betroffenen Netz verloren gehen. Wartungsfenster und Zugriffspfad vorbereiten.

Ein besonders kritisches Risiko entsteht, wenn mehrere Bedingungen zusammenkommen: Route Precedence steht auf SD-WAN vor Static, eine breite SD-WAN Route nutzt Any, und SD-WAN Routing für systemgenerierten Traffic oder Reply Packets ist aktiv. In diesem Fall kann der Zugriff auf WebAdmin oder SSH aus bestimmten internen Subnetzen verloren gehen.

Zusammenspiel mit NAT, IPsec und VoIP

SD-WAN ist selten allein beteiligt. Bei vielen Störungen spielen NAT, IPsec oder anwendungsspezifischer Traffic mit.

Bei SNAT ist wichtig, ob dieselbe Quell-IP über verschiedene Gateways erhalten bleibt. Wenn MASQ oder unterschiedliche übersetzte Source-Adressen verwendet werden, kann Failover oder Rerouting zu Kommunikationsproblemen führen. Für die Grundlagen passt NAT auf Sophos Firewall verstehen.

Bei route-based IPsec VPNs können XFRM-Interfaces in SD-WAN Routes oder SD-WAN Profiles verwendet werden. Dann sollten IPsec-Status, SD-WAN Route, Route Precedence und Firewall-Regeln zusammen geprüft werden. Die Route-based-VPN-Grundlagen sind in IPsec Route auf Sophos Firewall eingeordnet.

Bei VoIP-Problemen lohnt sich zusätzlich der Blick auf SIP, RTP, NAT und SD-WAN. In den SFOS-22.0-MR1-Release-Notes ist ein behobenes Problem dokumentiert, bei dem VoIP-Audio nach einem Upgrade auf SFOS 22.0 GA nur einseitig über route-based VPN mit SD-WAN Routing funktionierte. Der praktische Ablauf steht in Sophos Firewall VoIP-Probleme mit SIP und RTP beheben.

Rollback und Abschluss

Rollback

Vor der Änderung sollte der alte Zustand dokumentiert werden. Wenn danach Managementzugriff, Systemdienste oder produktiver Traffic betroffen sind, wird nicht weiter improvisiert. Zuerst den vorherigen Zustand wiederherstellen.

Praktisch bedeutet das:

1. Dokumentierte Vorher-Werte für reply-packet und system-generate-traffic mit den passenden enable- oder disable-Kommandos wieder setzen.
2. Route Precedence auf die vorherige Reihenfolge zurückstellen, falls sie geändert wurde.
3. Zu breite SD-WAN Routes temporär deaktivieren oder auf konkrete Ziele begrenzen.
4. Managementzugriff aus einem nicht betroffenen Netz testen.
5. Danach erst die eigentliche Ursache weiter eingrenzen.

Wenn der Zugriff auf WebAdmin und SSH aus einem internen Subnetz verloren geht, aber aus einem anderen Subnetz noch möglich ist, sollte von dort zuerst die breite SD-WAN Route, Route Precedence und die beiden CLI-Optionen geprüft werden.

Checkliste

• Aktuellen Status der beiden CLI-Optionen dokumentiert.
• Route Precedence mit system route_precedence show dokumentiert.
• Betroffenen Traffic konkret definiert.
• Bei Systemtraffic nur Destination und Service als entscheidende Match-Kriterien verwendet.
• SD-WAN Route nicht unnötig breit mit Any gebaut.
• Route Precedence geprüft.
• Mindestens ein WAN-Gateway für System Traffic als Active vorhanden.
• Alternative Management-Verbindung vorbereitet.
• Nur eine Änderung pro Test durchgeführt.
• Log Viewer und Packet Capture zur Validierung verwendet.
• NAT, IPsec und Firewall-Regeln mitgeprüft.
• Ergebnis und Rollback im Betriebsjournal dokumentiert.

FAQ