Sophos Firewall SD-WAN Route einrichten und testen

29. OKTOBER 2026 Sophos Firewall

Mit einer SD-WAN Route steuert man auf Sophos Firewall, über welchen Gateway ein definierter Datenfluss läuft. Das ist sinnvoll bei mehreren Internetleitungen, MPLS, route-based IPsec VPNs, VoIP oder Cloud-Diensten. Die Route muss eng genug gefasst und mit echtem Traffic geprüft werden, sonst erfasst sie schnell interne Netze oder verwendet beim Failover die falsche Public IP.

Soll Sophos Fusion (ehemals Sophos Central) die route-based Tunnel und Standortpfade für mehrere verwaltete Firewalls erzeugen, passt stattdessen der Ablauf Sophos Fusion SD-WAN Connection Group einrichten und prüfen. Der vorliegende Artikel erklärt die lokale SD-WAN-Route und bleibt auch für die Abnahme zentral verteilter Pfade wichtig.

Kurzantwort

Eine SD-WAN Route erstellt man hier:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Vorher müssen vier Punkte feststehen:

welcher Traffic anhand von Incoming Interface, Source, Destination und Service matchen soll
welcher Primary/Backup Gateway oder welches SD-WAN Profile verwendet wird
ob ausschliesslich diese Gateways erlaubt sind und welches NAT dazu passt
wie Route, Gateway und Rückweg mit Log Viewer und Packet Capture geprüft werden

Für öffentliche IPv4-Ziele sollte man nicht pauschal Any, sondern möglichst die Internet IPv4 group oder konkrete Ziele verwenden. Steht SD-WAN in der Route Precedence vor Static, kann eine breite Any-Route sonst auch internen Traffic zum WAN-Gateway senden.

Das Video ergänzt die Anleitung zur Planung, Einrichtung und Prüfung von SD-WAN Routes auf der Sophos Firewall.

Einsatz und Planung

Wann SD-WAN statt einer statischen Route sinnvoll ist

Eine statische Route reicht, wenn ein Zielnetz immer über einen festen Next Hop erreichbar ist. SD-WAN Routes ergänzen Kriterien wie Source, Service, Benutzer oder Anwendung und können Gateways nach Verfügbarkeit oder Qualität auswählen.

Typische Fälle sind:

bestimmte Clients oder Dienste über WAN2 führen und bei Ausfall auf WAN1 wechseln
VoIP oder Cloud-Anwendungen über einen Pfad mit geringer Latenz und wenig Paketverlust senden
MPLS, LTE/5G oder einen route-based IPsec-Tunnel als Primary- oder Backup-Pfad verwenden
Traffic an einen Provider binden, dessen Public IP bei einer Gegenstelle freigeschaltet ist

Planungsbeispiel und Voraussetzungen

Vor dem Anlegen beschreibt man einen konkreten Datenfluss. Für Microsoft-365-Traffic könnte die Planung so aussehen:

Incoming interface: internes LAN-Interface
Source network: Client_Net_10.20.0.0_24
Destination: selbst gepflegte Microsoft-365-Zielgruppe oder Internet IPv4 group
Services: HTTPS und bei Bedarf eine Servicegruppe für UDP 3478-3481
Primary gateway: WAN2
Backup gateway: WAN1
Fallback: Default Route zulassen oder Route only through specified gateways aktivieren
NAT: MASQ oder feste SNAT-IP passend zum gewählten Gateway
Test: definierte Client-IP, Ziel, erwarteter Gateway und erwarteter Logeintrag

Zusätzlich benötigt man passende Firewall-Regeln, NAT-Regeln für zu übersetzenden Traffic, aktiviertes Firewall-Logging sowie Zugriff auf Log viewer und Diagnostics > Packet capture. WAN-Gateways stehen unter Network > WAN link manager; wie man Custom Gateways für MPLS, RED oder XFRM erstellt und prüft, erklärt der eigene Grundlagenablauf.

Das allgemeine Active/Backup-Verhalten des Default-WAN-Pfads erklärt Sophos Firewall WAN-Failover einrichten; für Interface- und Gateway-Grundlagen hilft Sophos Firewall Zonen und Interfaces konfigurieren.

Bei route-based IPsec ist die Richtung wichtig: Ein XFRM-Interface als Incoming interface matcht Traffic, der aus dem Tunnel eintritt. Für LAN-zu-VPN-Traffic wählt man dagegen den Gateway des XFRM-Interfaces als Primary Gateway oder in einem SD-WAN Profile. Die Tunnel- und Routinggrundlagen stehen unter IPsec Route auf Sophos Firewall erstellen.

Für ein engeres Teams-Beispiel ergänzt man Users or groups um die fiktive Gruppe Sales_Team und Application objects um Teams_VoIP. Beide Namen sind durch die eigene Benutzergruppe und die tatsächlich benötigten Anwendungen zu ersetzen. Zusammen mit dem LAN-Interface, Client_Net_10.20.0.0_24, den vorgesehenen Zielen und Services steuert dies nur den passenden Flow über WAN2/WAN1. Separat prüft man eine enge Allow-Regel von LAN nach WAN für diese Quelle, Ziele und Services, die gewünschte Benutzerberechtigung sowie das NAT auf beiden Pfaden. Die SD-WAN Route erteilt keine Zugriffsberechtigung; im Test müssen Benutzer, Anwendung, Firewall Rule ID und NAT ID zum Plan passen.

Zwei WANs mit entgegengesetzten Prioritäten

Für das LAN 10.20.0.0/24 sollen ausgewählte öffentliche Ziele bevorzugt über WAN1 und die übrigen öffentlichen IPv4-Ziele über WAN2 laufen. Beide Leitungen dienen einander als Backup. Das folgende Planungsbeispiel ergänzt den SFOS-22-Grundablauf; die SFOS-23-EAP-Dokumentation bestätigt die Profilmechanik, ist aber keine Freigabe für beliebige Builds.

⚠️ Neue Routen und ihre Reihenfolge verändern den Datenpfad. Vorher Routenpositionen, On/Off-Zustände, Profilwerte, NAT und aktuelle Route Precedence sichern sowie einen unabhängigen Managementzugang prüfen. Ausfalltests nur im freigegebenen Wartungsfenster; keine gemeinsam genutzten Gateways oder Profile zur Simulation löschen oder verändern.

Unter Routing > SD-WAN profiles > Add zwei getrennte Profile mit Routing strategy: First available gateway erstellen: Ziele_WAN1_WAN2 mit der Reihenfolge WAN1, WAN2 und Internet_WAN2_WAN1 mit WAN2, WAN1. Namen, LAN und Gateways sind anpassbare Beispielwerte. In beiden Profilen Health check aktivieren; SLA bleibt für diese reine Verfügbarkeitsauswahl aus. Probe-Ziele, Protokoll und Zähler nach dem unten beschriebenen Health-Check-Ablauf wählen, nicht blind Defaults übernehmen. Die Ziele müssen auch einen Ausfall hinter dem Provider-Gateway erkennbar machen, nicht nur dessen lokale Erreichbarkeit.
Unter Routing > SD-WAN routes > IPv4 > Add die spezifische Route LAN_Ziele_WAN1 anlegen: Incoming interface ist das tatsächliche LAN-Interface, Source networks das Objekt für 10.20.0.0/24, Destination networks die gepflegte Gruppe der ausgewählten öffentlichen Ziele und Services nur die benötigten Dienste. Das Profil Ziele_WAN1_WAN2 wählen. Bei Domains zuerst die Grenzen von FQDN-Hosts und FQDN-Gruppen beachten; ein Domainname garantiert keinen exklusiven IP-Zielbereich.
Darunter LAN_Internet_WAN2 mit demselben LAN-Interface und Quellnetz, Destination networks: Internet IPv4 group, den freigegebenen Internetdiensten und Internet_WAN2_WAN1 anlegen. Die spezifische Route muss oberhalb der allgemeinen Internetroute stehen. Keine globale Any-Route verwenden; interne und VPN-Ziele gehören nicht in diesen Internetpfad.
Für beide Routen Route only through specified gateways bewusst festlegen: In diesem Beispiel ist die Option an, damit bei Ausfall beider vorgesehenen Pfade kein anderer Weg übernimmt. Passende Firewall-Freigaben und MASQ/SNAT für beide WANs getrennt prüfen. Benötigt die Gegenstelle eine feste Public IP, muss auch die Backup-IP dort zulässig sein.

Zur Abnahme je eine neue Verbindung zu einem spezifischen und einem übrigen öffentlichen Ziel erzeugen: Erwartet werden zunächst WAN1 beziehungsweise WAN2. Danach in einer freigegebenen Testumgebung beide Upstream-Ausfälle getrennt prüfen, auch bei weiterhin aktivem physischem Interface: Fällt WAN1 aus, müssen neue Verbindungen beider Zielklassen über WAN2 funktionieren; fällt nur WAN2 aus, über WAN1. Nach jeder Wiederherstellung neue Verbindungen mit der vorgesehenen Priorität vergleichen, bestehende Sessions dagegen separat beobachten. Dabei Route, Gateway und SNAT/Public-IP im Log beziehungsweise Packet Capture belegen und DNS, HTTPS sowie den internen Managementzugang erneut prüfen. Eine feste Umschaltzeit oder unterbrechungsfreie Übernahme bestehender Sessions folgt daraus nicht.

Bei unerwartetem Pfad keine Kriterien verbreitern: zuerst Routentreffer, Reihenfolge, Health-Status und NAT vergleichen. Als Rückweg die neuen Routen deaktivieren beziehungsweise die zuvor dokumentierten Routen-, Profil- und NAT-Werte samt Reihenfolge wiederherstellen; anschliessend Status und beide Testflows erneut prüfen. Ohne isolierbare Ausfallsimulation bleibt dieser Teil der Abnahme offen. Die detaillierten Session- und SNAT-Grenzen stehen unten unter Failover und Failback sicher testen.

MPLS zwischen Filiale und Hauptsitz

Ein begrenztes Beispiel führt 10.20.0.0/24 in der Filiale zu Webservern im Hauptsitznetz 10.30.0.0/24: Incoming Interface ist das Filial-LAN, Primary Gateway MPLS-1, Backup MPLS-2, Services nur die benötigten TCP 80/TCP 443. Auf der Hauptsitz-Firewall braucht es die passende Rückroute von 10.30.0.0/24 nach 10.20.0.0/24 über die dortigen MPLS-Gateways. Netze, Interfaces, Gateways und Services sind Beispielwerte und werden an die echte Topologie angepasst. Die separate Firewall-Regel erlaubt in der Filiale LAN nach der tatsächlichen MPLS-Zone, hier MPLS_DMZ, nur für diese Netze und Services; die Hauptsitz-Regeln müssen den geplanten Flow ebenfalls zulassen. In diesem gerouteten Design bleiben die ursprünglichen privaten Adressen erhalten, ohne SNAT. Das ist keine allgemeine NAT-Vorgabe für jede MPLS-Installation. Hin- und Rückweg sowie die unveränderte Source-IP prüft man mit echtem Traffic auf beiden Firewalls.

SD-WAN Route einrichten

Match-Kriterien festlegen

Für IPv6 wählt man konkrete Ziel-IP-Hosts statt einer pauschalen Any-Destination. Muss eine allgemeine Any-Route bestehen bleiben, legt man eine Route für die konkreten Ziel-IP-Hosts und den dafür vorgesehenen Gateway oberhalb davon an; Incoming Interface, Source und Services bleiben ebenfalls eng. Vor einer Änderung dokumentiert man mit system route_precedence show die installierte Reihenfolge sowie Routenposition und Einstellungen, prüft einen unabhängigen Managementzugang und plant die Wiederherstellung dieser Werte. Eine spezifischere Route ist kein Anlass, die globale Route Precedence blind zurückzusetzen.

Routing > SD-WAN routes öffnen.
IPv4 oder IPv6 wählen und Add anklicken.
Einen eindeutigen Namen wie Clients_M365_WAN2 eintragen.
Das Incoming interface wählen, auf dem der zu steuernde Traffic eintritt.
Optional einen DSCP-Wert wählen, wenn eingehende Pakete zuverlässig markiert sind.
Source networks festlegen und bei Bedarf Users or groups ergänzen.
Destination networks so eng wie möglich setzen.
Services auf die benötigten Protokolle und Ports begrenzen.
Optional Application objects auswählen.
Unter Link selection settings ein SD-WAN Profile oder Primary/Backup Gateways wählen.
Route only through specified gateways bewusst aktivieren oder deaktivieren.
Die Route speichern und in die richtige Reihenfolge verschieben; die erste passende SD-WAN Route gewinnt.
Mit einem definierten Client und Ziel testen.

Application Objects benötigen eine aktive Web Protection License. Die erste Verbindung wird anhand von Ziel-IP, Port, Protokoll und Incoming Interface über eine andere passende SD-WAN Route oder andernfalls über die Default Route geroutet. Erst nach der Anwendungserkennung greift das Application Object für nachfolgende Verbindungen. Die Klassifikationsdaten haben ab Sessionstart eine TTL von 3600 Sekunden. Bei Micro Apps unterstützt nur der DPI Engine Mode alle Anwendungen, der Web Proxy Mode dagegen nur Pattern Applications und Synchronized Security Applications.

In einem HA-Cluster synchronisiert SFOS diesen Application-Routing-Cache über den dedizierten HA-Link mit Multicast 226.1.1.1 auf Port 4455. Ein Firewall-Neustart leert die Klassifikationsdaten. Nach einem Neustart oder HA-Problem wird deshalb nicht nur der Tunnel- oder Gatewaystatus geprüft, sondern auch erneut eine erste und eine nachfolgende Anwendungsverbindung erzeugt.

Application Object erstellen

Die DPI Engine kann eine Anwendung innerhalb derselben Verbindung neu klassifizieren, etwa beim Wechsel von einer Webseite zu deren Chat. Die neue Entscheidung gilt für nachfolgende Verbindungen, nicht als Zusage einer Umleitung der laufenden Verbindung. Beginnt innerhalb der TTL von 3600 Sekunden ab Sessionstart keine weitere Session, werden die gespeicherten Sessiondetails entfernt.

Application Objects können Webanwendungen, Micro Apps, auf Endpoints entdeckte Synchronized Security Applications, eigene Anwendungen und Anwendungskategorien enthalten. Man wählt den Typ nach der benötigten Erkennung und hält die oben genannten Lizenz- und DPI-/Proxy-Grenzen ein; eine ganze Kategorie ist breiter als eine einzelne benötigte Anwendung.

Ein Application Object fasst nur die Anwendungen zusammen, die über denselben SD-WAN-Pfad laufen sollen. Man öffnet Applications > Application object, wählt Add, vergibt einen Namen und grenzt die Treffer über Category, Risk, Characteristics, Technology, Classification oder die Namenssuche ein. Danach markiert man die tatsächlich benötigten Anwendungen und speichert das Objekt. Sophos ergänzt die verfügbare Anwendungsliste dynamisch über IPS-Updates und Synchronized Application Control; deshalb sollte man die Auswahl nach Pattern- oder App-Änderungen erneut prüfen.

Der Filter Technology unterscheidet browser-based, client-server, network protocol, P2P und synchronized application control. Unter Classification stehen new, sanctioned, unsanctioned und tolerated zur Verfügung. Diese Kriterien erleichtern die Auswahl, beweisen aber noch nicht, dass die spätere Route funktioniert. Dafür braucht es zuerst die Klassifikationsverbindung und danach eine neue Testverbindung.

Für Microsoft 365 ist ein einziges Sammelobjekt oft zu breit. Ein Objekt wie Teams_VoIP kann beispielsweise nur die für Echtzeitkommunikation vorgesehenen Teams-Anwendungen enthalten, während OneDrive oder SharePoint über einen anderen Pfad laufen. Das gespeicherte Objekt wählt man anschliessend im Feld Application objects der SD-WAN Route aus.

Gateway oder SD-WAN Profile wählen

Primary/Backup Gateways reichen für einen bevorzugten Pfad und einen Fallback. Ein SD-WAN Profile trennt dagegen zwei Entscheidungen: Routing strategy bestimmt mit First available gateway oder Load balancing die Pfadauswahl; das optionale Service Level Agreement (SLA) ergänzt diese Strategie um Qualitätsmessungen. Best quality und Custom SLA sind daher keine zwei weiteren Routingstrategien.

Ein SD-WAN Profile richtet man unter Routing > SD-WAN profiles > Add in diesen Schritten ein:

Name und Beschreibung eintragen und unter Routing strategy First available gateway oder Load balancing wählen.
Zwei bis acht Gateways zuweisen und in die gewünschte Reihenfolge ziehen. Nur bei Load Balancing erscheinen Gateway weights; ungleiche Werte bilden unterschiedliche Leitungskapazitäten ab.
Für Load Balancing Round-robin oder eine passende Session persistence type wählen. Die Bindung kann auf Source-IP, Destination-IP, Source und Destination oder einer einzelnen Connection beruhen.
SLA nur aktivieren, wenn Latenz, Jitter oder Paketverlust die Auswahl beeinflussen sollen. Best quality vergleicht genau ein Kriterium. Custom SLA prüft Latenz, Jitter und Paketverlust gegen die festgelegten Grenzwerte.
Health check aktivieren, unter Protocol Ping oder TCP wählen und bis zu zwei Probe targets hinterlegen. Bei TCP zusätzlich einen Port angeben, auf dem das Probe Target zuverlässig antwortet. Sobald SLA aktiv ist, schaltet SFOS den Health Check zwingend ein.
Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after und Sample size for SLA passend zum Dienst festlegen. Die Einstellungen haben unterschiedliche Aufgaben: Interval between checks und Response time-out steuern die Probes; Deactivate gateway after zählt erfolglose Versuche, Activate gateway after erfolgreiche Antworten. Sample size for SLA bestimmt die Stichprobenzahl für die durchschnittliche Gateway-Leistung. Ausfall- und Wiederaktivierungsprüfung werden deshalb getrennt abgestimmt; die fünf Werte sind kein gemeinsamer Failover-Timer.
Speichern, das Profile in der SD-WAN Route auswählen und den Pfad mit echtem Traffic prüfen.

Die beiden Probe Targets bilden einen gemeinsamen Verfügbarkeitstest: SFOS betrachtet den Gateway als aktiv, wenn mindestens eines antwortet. Fällt das erste Ziel aus, wechselt die Prüfung zum zweiten und bleibt dort, solange dieses antwortet. Die blosse Rückkehr des ersten Ziels löst keinen sofortigen Wechsel zurück aus. Probe Targets sollten deshalb hinter dem jeweiligen Gateway liegen und den relevanten Pfad abbilden; ein erfolgreicher Ping beweist nicht, dass DNS, TLS oder die komplette Anwendung funktioniert.

Bei Best quality erfolgt ein Failback erst, wenn der ursprüngliche Gateway bei Latenz um 10 ms oder bei Jitter um 5 ms besser ist; für Paketverlust gibt es keine solche Marge. Unter Routing > SD-WAN profiles bedeutet ein aktives Profile, dass mindestens ein Gateway verfügbar ist. Link status fasst die Konfiguration zusammen, Historical performance öffnet die Messwerte und Object usage zeigt, welche Routen das Profile verwenden. Diese Verwendungen prüft man vor dem Bearbeiten oder Löschen.

Ist Route only through specified gateways aktiv, verwirft die Firewall den Traffic, wenn die angegebenen Pfade nicht verfügbar sind. Ohne diese Option prüft sie weitere SD-WAN Routes und danach die Default Route. Wird ein Backup Gateway gelöscht, setzt Sophos Firewall ihn auf None; beim Löschen des Primary Gateway oder des SD-WAN Profile wird die Route gelöscht und die Default Route kann übernehmen.

Bei Load balancing mit Best quality wird nur dann verteilt, wenn mindestens zwei Gateways gemeinsam die beste Leistung im gewählten Kriterium haben; nicht jeder erreichbare Gateway gehört dazu. Mit Custom SLA wird unter den Gateways verteilt, die die festgelegten SLA-Grenzen erfüllen. Ein erreichbarer Pfad ausserhalb des SLA ist nicht dasselbe wie ein unerreichbarer Gateway; daraus folgt keine pauschale Aussage zum Fallback, wenn kein Gateway das SLA erfüllt.

Gateway weights beschreiben ein Verhältnis der Requests: 3:1 bedeutet im dokumentierten Beispiel drei von vier Requests über den ersten und einen über den zweiten Gateway. Die Gewichte werden nach Leitungskapazität und Ressourcen gewählt; sie garantieren weder denselben Anteil an Bytes noch einen bestimmten Durchsatz oder eine Bündelung der Leitungen.

Bei Custom SLA sind Maximum latency und Maximum jitter in Millisekunden angegeben, Maximum packet loss in Prozentpunkten. Interval between checks bestimmt den Abstand der Probes, Response time-out die zulässige Antwortzeit. Deactivate gateway after zählt aufeinanderfolgende erfolglose Probe-Versuche, Activate gateway after aufeinanderfolgende erfolgreiche Antworten. Sample size for SLA legt die Anzahl der Probe-Stichproben fest, aus denen die durchschnittliche Gateway-Leistung bestimmt wird. Diese Werte werden für den eigenen Dienst gewählt, nicht aus einem einzelnen Zeitbeispiel als allgemeiner Default abgeleitet.

Round-robin verteilt Requests der Reihe nach auf die berücksichtigten Gateways. Bei drei gleich gewichteten, verfügbaren Gateways ohne SLA-Einschränkung läuft das Beispiel über den ersten, zweiten, dritten und wieder ersten Gateway. Session persistence type hält dagegen zusammengehörige Sessions anhand des gewählten Schlüssels auf demselben Gateway, etwa für Banking oder Warenkörbe. Ein einzelner Testflow zeigt deshalb nicht die Verteilung vieler unabhängiger Sessions.

Wenn kein Gateway das Custom SLA erfüllt

Die Sperre bei unerreichbaren Gateways ist kein Nachweis einer harten SLA-Sperre für weiterhin erreichbare Pfade. Ohne buildbezogenen Beleg sollte man für diesen Fall weder die Fortsetzung von Load balancing noch ausschliesslich First available gateway zusichern.

SFOS-Build, Profile, Routing strategy, Gateway-Reihenfolge, Gewichte, Session Persistence, SLA-Grenzen, Probe Targets und Route only through specified gateways dokumentieren.
Mit Link status, Historical performance und SD-WAN-Logs erreichbare Pfade ausserhalb des SLA von tatsächlich unerreichbaren Pfaden unterscheiden.
Nur mit freigegebenem, isoliertem Testflow im Wartungsfenster und unabhängigem Managementzugang prüfen. Keine gemeinsamen produktiven Profile zur Fehlersimulation ändern oder Gateways beziehungsweise Profile löschen. Neue Verbindungen erzeugen und Gateway, SNAT-IP und Anwendungsergebnis mit Log Viewer und Packet Capture belegen; bestehende Sessions separat betrachten.
Geänderte Testwerte auf den dokumentierten Ausgangszustand zurückstellen und Status sowie Echttest wiederholen. Ohne freigegebenen Test bleibt die Auswahl offen; eine buildbezogene Klärung benötigt Konfiguration, Messwerte, Zeitpunkte und Logs zusammen mit dem Build.

Ein Ergebnis für einen Build und ein Profile ist keine allgemeine Failover-Garantie.

Route Precedence und NAT abstimmen

Der dokumentierte Default ist Static → SD-WAN → VPN. Das ist nicht zwingend der Zustand einer bestehenden Installation: Vor Entscheidungen prüft man weiterhin system route_precedence show und übernimmt den Default nicht automatisch.

Route Precedence bestimmt die Reihenfolge zwischen Static, SD-WAN und VPN. Direkt verbundene Netze und SSL VPN gehören zur Kategorie Static. Die aktuelle Reihenfolge sieht man unter Routing > SD-WAN routes oder in der Device Console; Änderungen und Rollback erklärt Sophos Firewall Route Precedence sicher ändern.

Routing wählt den Pfad, NAT verändert Adressen. Internettraffic über WAN2 benötigt deshalb eventuell MASQ oder eine feste SNAT-IP auf diesem Pfad. Für interne Netze und VPNs ist NAT dagegen oft unerwünscht. Die Zusammenhänge erklärt NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

DNAT zu einem Server hinter route-based IPsec

Eine öffentliche DNAT-Freigabe kann auf einen internen Server zeigen, der nicht lokal angeschlossen ist, sondern hinter einer entfernten Firewall über route-based IPsec liegt. In diesem Sonderfall müssen DNAT und SD-WAN Route denselben eingehenden Flow vor der Übersetzung erkennen und der Rückweg muss wieder über die veröffentlichende Firewall führen.

Der belastbare SFOS-22-Ablauf besteht aus fünf zusammengehörenden Teilen:

Für den entfernten Server unter Hosts and services > IP host ein genaues IP-Objekt anlegen.
Unter Routing > Gateways einen Gateway mit der entfernten Gateway-IP und dem passenden XFRM-Interface erstellen. Als Monitoring-Ziel dient ein stabil erreichbarer Host hinter diesem Gateway.
Die DNAT-Regel auf das öffentliche WAN-Interface und den extern angebotenen Service matchen lassen und als Translated destination den entfernten Server wählen. Das Sophos-Beispiel verwendet MASQ, damit der Rückweg wieder zur veröffentlichenden Firewall gelangt; dadurch sieht der Server jedoch nicht mehr die ursprüngliche Client-IP.
In der SD-WAN Route als Destination networks dasselbe öffentliche WAN-Interface und unter Services den extern angesprochenen Port eintragen. Bei PAT ist dies ausdrücklich der externe Port, nicht der intern übersetzte Zielport. Als Primary Gateway wird der Gateway des XFRM-Interfaces gewählt.
Eine enge Firewall-Regel für die Veröffentlichung prüfen und den Ablauf aus einem externen Netz testen. Die erwartete NAT Rule ID, Firewall Rule ID, SD-WAN Route, der gewählte XFRM-Gateway, Hin- und Rückweg sowie die auf dem Server sichtbare Source-IP müssen zum Design passen.

MASQ ist hier keine kosmetische Option. Es löst im dokumentierten Beispiel den Rückweg, nimmt dem Zielserver aber die echte Client-IP. Wenn der entfernte Standort einen nachgewiesenen Rückweg zu den ursprünglichen Clientnetzen hat und die Original-IP erhalten bleiben soll, braucht es ein bewusst geplantes und separat getestetes Routingdesign. Die allgemeine Veröffentlichung und Absicherung erklärt Server per DNAT auf Sophos Firewall veröffentlichen.

Mehrere entfernte Server können dieselbe SD-WAN Route verwenden, wenn sie über denselben Gateway erreichbar sind und sich durch WAN-Adresse oder externen TCP-Port eindeutig matchen lassen. Führen sie über verschiedene Gateways, werden getrennte SD-WAN Routes verwendet. Bei einem Treffer auf den falschen Port, das falsche WAN-Objekt oder den falschen Gateway wird nicht mit Any aufgeweitet, sondern zuerst der Pre-DNAT-Flow mit Log Viewer und Packet Capture belegt.

Route testen und abnehmen

Routenliste und Gatewaystatus prüfen

Unter Routing > SD-WAN routes lässt sich die Liste nach Routenname, Objekt oder Objektwert durchsuchen; 443 findet beispielsweise Routen mit dem HTTPS-Service. Die Reihenfolge wird per Drag-and-drop geändert. Das ist eine Traffic-Änderung, denn SFOS wertet von oben nach unten aus und stoppt beim ersten Treffer.

Über More options kann man eine Route ein- oder ausschalten, bearbeiten, klonen, den Datenzähler zurücksetzen oder löschen. Vor dem Reset sollte man Zählerstand und Zeitpunkt notieren. Eine geklonte Route ist eine eigenständige Route: Name, Match-Kriterien, Position, Gateway und NAT müssen vor dem Speichern beziehungsweise Einschalten geprüft werden; danach kontrolliert man den tatsächlichen On/Off-Status.

Der Tooltip am Symbol in der Spalte Active zeigt bei einem SD-WAN Profile Zustände wie In use, Available, Unavailable, In use, but SLA isn't met oder Available and SLA isn't met. Ein verfügbarer Gateway- beziehungsweise Profilstatus beweist weder, dass diese Route gematcht wurde, noch einen funktionierenden Rückweg.

Bei direkter Primary/Backup-Auswahl unterscheidet das Symbol unter Active drei Zustände: Mindestens ein Gateway ist erreichbar und die Route ist live; die Route ist nicht live und Route only through specified gateways ist aus; oder sie ist nicht live und die Option ist an. Im letzten Fall bleibt der Traffic bei unerreichbaren angegebenen Pfaden verworfen, statt auf andere Gateways auszuweichen. Tooltip und Checkbox werden gemeinsam gelesen, nicht mit einem Profil-SLA-Status gleichgesetzt.

Standardtest mit echtem Traffic

Einen Testclient mit bekannter IP und ein eindeutiges Ziel wählen.
Logging in der passenden Firewall-Regel aktivieren.
Eine echte Verbindung starten.
Im Log viewer Source, Destination, Service, Rule ID, NAT ID und Gateway prüfen.
Den Traffic Count der SD-WAN Route kontrollieren: OUT zählt Requests und IN Replies nur, wenn Source und Destination zur jeweiligen Richtung passen.
Unter System services > Log settings den Typ SD-WAN aktivieren und im Log Viewer das Modul SD-WAN auf Profile-, SLA- und Route-Ereignisse prüfen.
Bei Unklarheit unter Diagnostics > Packet capture einen engen Filter auf Client, Ziel und Port setzen.

Der Policy tester berücksichtigt SD-WAN Routes nicht. Er kann Policy-Matches prüfen, aber weder die gewählte SD-WAN Route noch den tatsächlichen Gateway bestätigen. Für eine vollständige Paketflussanalyse hilft Sophos Firewall Regel testen mit Log Viewer, Policy Test und Packet Capture.

Für Profile- und Route-Logs innerhalb der Firewall-Ansicht wählt man im Log viewer das Modul Firewall, öffnet die erweiterte Auswahl über den Expand-Button neben der Modulliste, markiert die gewünschten SD-WAN-Logs und klickt Apply. Das ergänzt die separate SD-WAN-Modulansicht.

SD-WAN Performance auswerten

Die x-Achse der Qualitätsgraphen zeigt die Zeit; die y-Achse zeigt Latenz und Jitter in Millisekunden und Paketverlust in Prozentpunkten. Assigned weights for load balancing öffnet die zugewiesenen Gateway-Gewichte. Messwerte und Gewichte sind keine Abnahme der Anwendung.

Unter Diagnostics > SD-WAN performance wählt man das verwendete SD-WAN Profile aus. Alternativ öffnet man Routing > SD-WAN profiles, wählt das Profile und klickt unter Status auf Historical performance. Die Ansicht zeigt pro Gateway die Gesamtzahl der Verbindungen, die übertragene Datenmenge, die zugewiesenen Load-Balancing-Gewichte sowie Latenz, Jitter und Paketverlust für Live, 24h, 48h, Week oder Month.

No data to display bedeutet laut Sophos, dass noch keine Route das ausgewählte Profile verwendet oder kein Traffic durch eine solche Route fliesst. Die Meldung beweist deshalb keinen Fehler der Messfunktion. Zuerst wird ein kontrollierter Datenfluss über die erwartete Route erzeugt und mit Log Viewer oder Packet Capture bestätigt.

Reset data transfer and connection count verändert die Zähler. Vor einem Reset werden Werte und Zeitpunkt dokumentiert. Auch ein unauffälliger Graph beweist noch nicht, dass Firewall-Regel, NAT, Anwendung und Rückweg funktionieren; diese Ebenen bleiben Teil des Echttests.

Failover und Failback sicher testen

Vor einer Änderung dokumentiert man die bisherige Routenposition und den On/Off-Status, die Primary/Backup Gateways oder das verwendete Profile, dessen Gateway-Reihenfolge, SLA- und Health-Check-Werte sowie die erwartete NAT-Übersetzung. Der Rückweg besteht darin, genau diese Werte wiederherzustellen und danach Status, Log und echten Traffic erneut zu prüfen.

Ein kontrollierter Ausfalltest erfolgt in einem Wartungsfenster, mit dokumentiertem Rollback und einem unabhängigen Managementpfad zur Firewall. Vorher prüft man in der Device Console die aktuellen, nur lesenden Statuswerte:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Anschliessend startet man echten Anwendungstraffic, lässt den Primary Gateway kontrolliert ausfallen und prüft Pfad, Sessions, Public Source-IP und Rückweg. Primary Gateway oder SD-WAN Profile dürfen für diesen Test nicht gelöscht werden, weil dies die Route entfernt und nur den Fallback auf die Default Route testet. Auch eine Bearbeitung von Route oder Profile sowie eine Änderung der Route Precedence kann bestehende Verbindungen neu routen und gehört nicht in denselben Baseline-Test. Bei direkter Primary/Backup-Auswahl laufen neue Verbindungen nach der Rückkehr des Primary wieder über ihn; bestehende Verbindungen bleiben grundsätzlich auf dem Backup Gateway.

reroute-connection ist standardmässig aktiv und betrifft Verbindungen ohne SNAT. SNAT-Verbindungen werden standardmässig nicht umgeleitet; selbst mit separat aktiviertem reroute-snat-connection funktioniert dies nur, wenn beide Pfade dieselbe übersetzte Source-IP verwenden. Bei MASQ oder unterschiedlichen Override-Source-Translation-Adressen wird die SNAT-Verbindung nicht umgeleitet und die bestehende Session bricht beim Pfadausfall ab.

Rerouting bewusst ändern

Diese Schalter sind Traffic-Änderungen, keine Voraussetzung für den Baseline-Test. Nur im Wartungsfenster mit geprüftem unabhängigem Managementzugang und dokumentiertem Rückweg ändern: Zuerst die beiden oben gezeigten Rerouting-Statuswerte speichern und die SNAT-Bedingung derselben übersetzten Source-IP auf beiden Pfaden prüfen. In der Device Console stehen folgende Alternativen zur Verfügung; man führt nur den für die beabsichtigte Änderung benötigten Befehl aus, nicht alle nacheinander:

Ohne SNAT einschalten: set routing reroute-connection enable; ausschalten: set routing reroute-connection disable.
Für SNAT einschalten: set routing reroute-snat-connection enable; ausschalten: set routing reroute-snat-connection disable.

Danach mit show routing reroute-connection und show routing reroute-snat-connection nachprüfen und Sessions, Source-IP, Hin- und Rückweg separat testen. Für den Rückweg stellt man jeden geänderten Schalter auf seinen zuvor erfassten Enable-/Disable-Zustand zurück und wiederholt Status- und Echttest. Das Einschalten von SNAT-Rerouting hebt die MASQ-/IP-Einschränkungen nicht auf.

Probleme systematisch eingrenzen

Die Route matcht nicht

Incoming Interface, Source Network, Destination und Service mit dem echten Flow vergleichen.
Route-Reihenfolge prüfen; die erste passende SD-WAN Route gewinnt.
Bei Application Objects Lizenz, DPI-Erkennung und eine zweite Verbindung nach der Klassifikation prüfen.
Traffic Count nicht allein als Beweis verwenden, weil Request und Reply nur bei passenden Source-/Destination-Kriterien gezählt werden.
Bei Direct Web Proxy reicht ein Service-Match auf HTTP/HTTPS nicht: Man verwendet Any oder einen Service für den unter Web > General settings > Web proxy listening port konfigurierten Port. Für Reply Packets matchen Source Network und Incoming Interface in diesem Sonderfall nicht; zusätzlich braucht der Proxy-Rückweg einen WAN Default Gateway oder eine passende statische Route.
Bei einer aus SFOS 17.5 oder älter migrierten SD-WAN Route prüfen, ob ihre ursprüngliche Firewall-Regel gelöscht wurde. Solche migrierten Routen bleiben mit der alten Regel verknüpft und werden beim Löschen dieser Regel ebenfalls entfernt.
Bei IPv6 überwacht Dead Gateway Detection in SD-WAN Routes keinen fremden Netzwerktraffic wie SNMP. Ein ausbleibender Drittanbieter-Messwert ist deshalb kein zuverlässiger DGD-Nachweis.

Listener, Clientverteilung, Schutzregel und Echttest beschreibt Direct Web Proxy mit PAC-Datei einrichten.

Für Reply Packets und systemgenerierten Traffic gelten eigene Schalter und Match-Regeln. Diese Spezialfälle erklärt Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen.

Web Admin und SSH sind nach einer neuen Route nicht erreichbar

Ein dokumentiertes Szenario kombiniert vier Einstellungen: SD-WAN steht vor Static, eine neue Route für ein bestimmtes internes Quellnetz hat Destination Any, SD-WAN-Routing für systemgenerierten Traffic ist eingeschaltet und SD-WAN-Routing für Reply Packets ebenfalls. Dann kann der Managementzugang aus dem erfassten internen Netz verloren gehen, während er aus anderen Subnetzen weiterhin möglich ist. Das sind nicht notwendige Bedingungen für jeden Managementausfall.

Über einen zuvor geprüften alternativen Zugang kontrolliert man Routenquelle, Destination und Precedence sowie in der Device Console diese nur lesenden Werte:

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

Zuerst verifiziert man, dass Management aus einem nicht erfassten Subnetz tatsächlich erlaubt und erreichbar ist. Danach kann man die Destination gezielt eingrenzen oder eine der zuvor geänderten Einstellungen bewusst auf den dokumentierten Ausgangswert zurückstellen. Kein blindes globales Reset: Routenposition, Einstellungen und Precedence vorher sichern, Rückweg planen und Web Admin, SSH sowie betroffenen Traffic anschliessend erneut prüfen. Ohne sicheren alternativen Zugang wird die Änderung nicht remote fortgesetzt.

Traffic nimmt den falschen Pfad

Bei öffentlichen IPv4-Zielen Any durch Internet IPv4 group oder konkrete Ziele ersetzen.
Route Precedence prüfen, besonders wenn interne, SSL-VPN- oder policy-based IPsec-Netze betroffen sind.
Gateway- und SLA-Status sowie Health-Check-Ziele kontrollieren.
NAT-Regel und übersetzte Source-IP mit dem tatsächlich verwendeten Gateway vergleichen.
Prüfen, ob ein Primary Gateway oder SD-WAN Profile gelöscht und damit auch die Route entfernt wurde.

Anwendung oder Antwort fällt nach dem Failover aus

Zuerst prüft man mit Packet Capture, ob das Paket über den erwarteten Gateway austritt und die Antwort zurückkommt. Danach folgen NAT, Public-IP-Allowlisten, Session Persistence, MTU/MSS sowie der Status des VPN- oder MPLS-Pfads. Besonders SIP/RTP, Banking-Portale und APIs mit fester Source-IP müssen mit echtem Anwendungstraffic getestet werden.

Begann das Problem unmittelbar nach dem Upgrade auf SFOS 22.0 GA, prüft man zuerst den installierten Build. SFOS 22.0 MR1 Build 490 behebt NC-173667, bei dem eine SD-WAN Route zufällig getrennt wurde, und NC-177603, bei dem VoIP-Audio über ein route-based VPN nach dem Upgrade auf 22.0 GA nur in eine Richtung funktionierte. Läuft bereits MR1 oder ein neuerer Build, wird die Ursache nicht allein dem Firmwarestand zugeschrieben; dann werden Route, Sessions, NAT sowie Hin- und Rückweg mit dem oben beschriebenen Echttest erneut belegt.

XML-API: Objektgrenzen vor einer Automatisierung klären

Die XML-API-Dokumentation für SFOS 22.0 und 23.0 beschreibt getrennte benannte Objekte. Die oben erklärte UI-Konfiguration bleibt der praktische Ablauf; daraus lässt sich aber kein eindeutiger XML-Vertrag ableiten. Die folgenden Hinweise erklären die Widersprüche; sie bilden weder eine sendefertige Anfrage noch ein korrigiertes Schema. Für eine Automatisierung benötigt man eine versionsbezogene Klärung der betroffenen Felder durch Sophos; es wird hier weder ein Zahlenmapping geraten noch ein ausführbarer XML-Request vorgegeben.

Benanntes HealthCheckProfile: Lebenszyklus und Probe-Zähler

HealthCheckProfile ist ein eigenständiges Health-Check-Objekt, nicht das SDWANProfile und nicht die integrierte Gateway-Health-Option. Beim Anlegen und Aktualisieren identifiziert das obligatorische skalare String-Feld Name das Health-Check-Profile; beide Feldtabellen nennen maximal 125 Zeichen. Die 22.0-Tabelle verbietet zusätzlich Kommas und erlaubt UTF-8-Zeichen ausdrücklich, während diese beiden Angaben in der 23.0-Tabelle fehlen. Dieses Fehlen beweist keine geänderte Namensvalidierung.

ProbeTargets ist als Array von monitorDetails-Objekten beschrieben, im Beispiel stehen dagegen ProbeTarget-Elemente. monitormethod nennt TCP oder PING; monitorip nennt die Datentypen IPADDRESS, IPADDRESS6 und DOMAINNAMELOOKUP. Bei operator stehen die Literale & und |, Default |. Daraus wird weder eine andere XML-Struktur noch eine Gleichsetzung mit dem oben beschriebenen UI-Verhalten der beiden Probe Targets abgeleitet. Auch IPFamily bleibt widersprüchlich: Beide Tabellen nennen IPv4 und IPv6, Default IPv4, zugleich aber maximal 1 Zeichen.

Die beiden Zählerzeilen wirken gegenüber ihren Namen vertauscht: ProbesResponseFailure beschreibt wörtlich aufeinanderfolgende Antworten zur Aktivierung des Objekts, mit Default 1; ProbeResponseSuccess beschreibt aufeinanderfolgende Probes ohne Antwort vor dessen Deaktivierung, mit Default 3. Beide Tabellen nennen jeweils den Bereich 1 bis 10. Die widersprüchliche Zuordnung vor einer Verwendung mit Sophos klären. Insbesondere werden die sicheren UI-Erklärungen zu Deactivate gateway after und Activate gateway after nicht automatisch auf diese API-Tags übertragen.

Die separate Löschoperation adressiert ebenfalls das Health-Check-Profile über Name, nicht eine Route oder ein SD-WAN Profile. Vor einer beabsichtigten Löschung prüft man die referenzierenden SD-WAN Profiles und dokumentiert ihre bisherige Health-Zuordnung. Die Quellen belegen keinen sicheren Kaskadenablauf oder das Verhalten beim Löschen eines noch referenzierten Health-Objekts. Das ist nicht mit dem oben beschriebenen Löschen eines SD-WAN Profile gleichzusetzen; eine solche Löschung ist auch kein Ausfalltest.

HealthCheckProfileStatus: administrativer Zustand des Health-Objekts

HealthCheckProfileStatus schaltet das benannte Health-Check-Profile administrativ ein oder aus. Der Selektor ist das obligatorische skalare String-Feld Name; der Beispielplatzhalter HealthCheckProfileStatusName ändert diese Feldidentität nicht. In beiden Versionen steht bei Status im Beispiel ON/OFF, die obligatorische Feldzeile nennt dagegen INTEGER ohne numerische Zuordnung. Eine numerische Form für Ein oder Aus ist dadurch nicht belegt. Diese Administration ist nicht die gemessene Gateway-Verfügbarkeit, der aktive Zustand eines SD-WAN Profile oder das Ein-/Ausschalten einer Route. Eine dokumentierte Erfolgsmeldung allein beweist keine tatsächlich erfolgte Zustandsänderung; zu prüfen wäre der administrative Zustand genau dieses benannten Objekts, getrennt von den Verfügbarkeitsanzeigen.

SDWANPolicyRouteStatus: die richtige Route und den richtigen Zustand prüfen

SDWANPolicyRouteStatus verwendet als obligatorischen skalaren String-Selektor SDWANPolicyRouteName, nicht das Name eines Health-Check-Profile. Beide Versionsbeispiele zeigen für Status wiederum ON/OFF, während die obligatorische Feldzeile INTEGER nennt und kein Zahlenmapping liefert. Der dokumentierte Ergebniscode 200 ist keine unabhängige Bestätigung, dass die gewünschte Route ihren administrativen Zustand geändert hat. Dafür wäre der tatsächliche On/Off-Zustand dieser Route zu prüfen. Der Active-Tooltip, die Gateway-Erreichbarkeit und die Drop-/Fallback-Entscheidung durch Route only through specified gateways beantworten andere Fragen und lösen den widersprüchlichen XML-Statusvertrag nicht auf.

SDWANProfile: Familie, Strategie und separate Health-Referenz

Beim SDWANProfile bezeichnet Name das SD-WAN Profile selbst, mit maximal 60 Zeichen. Das obligatorische skalare String-Feld HealthCheckProfileName ist dagegen die Referenz auf das separate Health-Check-Profile, mit maximal 85 Zeichen. Das ist nicht dieselbe Identität und auch nicht dieselbe dokumentierte Namenslänge wie dessen Name mit 125 Zeichen. Die Objekt- und Zählergrenzen des HealthCheckProfile gelten deshalb auch bei der Vorbereitung dieser Referenz; integrierte Health-Einstellungen ersetzen die erforderliche benannte Referenz nicht.

Beide Profile-Beispiele und Feldbeschreibungen nennen bei IPFamily IPv4/IPv6, die Validierungszeile erlaubt aber nur IPv4 und nennt zugleich maximal 1 Zeichen. Die IPv6-Routen in der UI belegen daher keine IPv6-Unterstützung dieses Profile-XML-Vertrags. Bei SLAStrategy steht im Beispiel und in der Beschreibung BestQuality, in der zulässigen Werteliste hingegen BestQualityv; CustomSLA steht in beiden. Bei LBMethod nennt das Beispiel WRR/SrcSticky/DestSticky/SrcDestSticky/ConnectionSticky, die Tabelle dagegen INTEGER im Bereich 0 bis 5 ohne Zuordnung zu diesen Textwerten. Bei IsLatency steht Default 1 gegenüber den zulässigen Literalen OFF und ON. Keine dieser Differenzen wird durch eine vermutete Schreibkorrektur, Zahlenform oder ein abgeleitetes Boolean-Mapping aufgelöst. Die oben beschriebenen UI-Strategien und Prüfwege bleiben nutzbar, sind aber kein Beweis für einen ausführbaren Profile-Request.

Betrieb und Dokumentation

Für jede produktive SD-WAN Route werden Zweck, Incoming Interface, Source/Destination, Services, Gateway oder Profile, Fallback, NAT-Erwartung, Testclient, Testziel, Owner und Review-Datum dokumentiert. Nach Provider-, VPN-, Interface- oder Cloud-Dienst-Änderungen sollte man Match, Logs und Failover erneut prüfen.

Eine Route gilt erst als abgenommen, wenn:

die Match-Kriterien nur den geplanten Traffic erfassen
Firewall-Regel, NAT und Route Precedence zum Design passen
Log Viewer und Packet Capture den erwarteten Pfad bestätigen
Failover, Failback und Public Source-IP wie dokumentiert reagieren
ein Verantwortlicher und ein nächster Review-Termin feststehen