Zum Inhalt springen
Avanet

Sophos Firewall SD-WAN Route einrichten und testen

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.

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; Custom Gateways für MPLS, RED oder XFRM erstellt man unter Routing > Gateways. Für die Grundlagen zu Interfaces und Gateways 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.

SD-WAN Route einrichten

Match-Kriterien festlegen

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

Gateway oder SD-WAN Profile wählen

Primary/Backup Gateways reichen für einen bevorzugten Pfad und einen Fallback. Für ein SD-WAN Profile erstellt man mindestens zwei Gateways, legt danach das Profile unter Routing > SD-WAN profiles an und wählt es anschliessend in der Route aus. Ein Profile ist sinnvoll, wenn mehrere Pfade, Load Balancing oder SLA-Kriterien benötigt werden:

  • First available gateway nimmt den ersten verfügbaren Gateway in der definierten Reihenfolge.
  • Load balancing verteilt Verbindungen; Session Persistence und Gateway Weights steuern Bindung und Verteilung.
  • Best quality vergleicht genau ein Kriterium: Latenz, Jitter oder Paketverlust.
  • Custom SLA verlangt Grenzwerte für alle drei Kriterien und verwendet bei Nichterfüllung die gewählte Routingstrategie.

Health Checks prüfen per Ping oder TCP bis zu zwei Probe Targets. Diese Ziele sollten den relevanten Pfad abbilden, beweisen aber nicht, dass eine komplette Anwendung funktioniert. Bei Best Quality erfolgt ein Failback zudem 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.

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.

Route Precedence und NAT abstimmen

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.

Route testen und abnehmen

Standardtest mit echtem Traffic

  1. Einen Testclient mit bekannter IP und ein eindeutiges Ziel wählen.
  2. Logging in der passenden Firewall-Regel aktivieren.
  3. Eine echte Verbindung starten.
  4. Im Log viewer Source, Destination, Service, Rule ID, NAT ID und Gateway prüfen.
  5. Den Traffic Count der SD-WAN Route kontrollieren: OUT zählt Requests und IN Replies nur, wenn Source und Destination zur jeweiligen Richtung passen.
  6. 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.
  7. 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.

Failover und Failback sicher testen

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

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.

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.

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 nach einem Firmwareupdate, sollte man vor umfangreichen Regeländerungen die aktuellen SFOS-22.0-Release-Notes prüfen. SFOS 22.0 MR1 behebt unter anderem zufällige SD-WAN-Unterbrechungen und Einweg-Audio über route-based VPN mit SD-WAN Routing.

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