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.

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, NTP, Sophos Central, Syslog, Updates, Monitoring, Authentifizierungsdienste oder Diagnoseverbindungen gehören.

Bei diesem Traffic kennt die Firewall keine normale eingehende Schnittstelle und kein normales Source-Netz wie bei weitergeleitetem Client-Traffic. Deshalb sollte man SD-WAN Routes für systemgenerierten Traffic besonders eng planen: Zielnetzwerke und Services müssen sinnvoll gewählt werden. Eine sehr breite Route kann sonst Management- oder Systemtraffic unerwartet auf einen falschen Pfad ziehen.

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.

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.

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.

Optionen aktivieren

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.

⚠️ 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.

Log Viewer und SD-WAN Logs

Im Log viewer sollten Firewall- und SD-WAN-bezogene Events geprüft werden. Bei relevanten Firewall Regeln muss Log firewall traffic aktiv sein. Ohne Logging sieht man oft nur einen Teil der Entscheidung.

Zu prüfen:

• Welche Firewall Rule ID wird getroffen?
• Welche NAT Rule ID wird verwendet?
• Welcher Gateway oder welches Interface erscheint im Log?
• Gibt es Drops, Policy-Verletzungen oder unerwartete Security-Feature-Entscheidungen?

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 zusätzlich prüfen, ob die SD-WAN Route nur Source-Netze oder Incoming Interface matchen soll. Für Firewall-eigenen Traffic sind diese Kriterien nicht wie bei Client-Traffic verfügbar.

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.
• 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

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 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.
• Betroffenen Traffic konkret definiert.
• 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