Sophos Firewall SD-WAN Route einrichten und testen
SD-WAN Routes auf Sophos Firewall steuern, welchen Weg bestimmter Traffic nehmen soll. Das ist hilfreich bei mehreren WAN-Leitungen, MPLS, route-based IPsec VPNs, VoIP, Cloud-Diensten oder Anwendungen, die über einen bestimmten Provider laufen müssen.
In der Praxis entstehen SD-WAN-Probleme selten durch die Schaltfläche selbst. Meist sind Kriterien zu breit, Gateways falsch bewertet, NAT-Regeln nicht passend, Route Precedence unerwartet oder Tests zu ungenau. Der Artikel behandelt deshalb nicht nur den Klickpfad, sondern auch Planung, Abnahme und typische Fehlersuche.
Videoanleitung
Kurzantwort
Eine SD-WAN Route erstellt man unter Routing > SD-WAN routes. Vorher sollte klar sein:
- welcher Traffic gesteuert werden soll
- welche Source, Destination, Services und Benutzer betroffen sind
- welcher Gateway oder welches SD-WAN Profile verwendet wird
- ob statische Routen, VPN-Routen oder Route Precedence konkurrieren
- ob NAT zur Route passt
- wie der Pfad im Log Viewer und Packet Capture geprüft wird
Eine gute SD-WAN Route ist eng genug, um nur den gewünschten Traffic zu steuern. Eine breite Route mit Any kann sonst plötzlich interne Netze, Managementzugriff oder VPN-Traffic beeinflussen.
Wann SD-WAN Routes sinnvoll sind
SD-WAN Routes sind Policy Routing. Man nutzt sie, wenn die normale Routingtabelle allein nicht ausdrückt, welcher Traffic über welchen Pfad laufen soll.
Typische Fälle:
| Situation | Nutzen einer SD-WAN Route |
|---|---|
| zwei oder mehr Internetleitungen | bestimmte Anwendungen über bevorzugte Leitung oder Failover senden |
| VoIP oder Teams | Latenz- oder jitterarme Leitung priorisieren |
| Cloud-Dienste | Microsoft 365, ERP oder Backup-Traffic gezielt führen |
| route-based IPsec VPN | Traffic über XFRM-Interface oder Gateway-Profil steuern |
| MPLS oder Standortleitung | interne Zielnetze über dedizierten Pfad erreichen |
| Provider mit Quell-IP-Bindung | Traffic über genau den WAN-Anschluss senden, der zur erlaubten Public IP passt |
Wenn nur ein statisches Zielnetz über einen klaren Next Hop erreicht werden soll, kann eine statische Route einfacher und robuster sein. SD-WAN lohnt sich, wenn Kriterien, Gateway-Auswahl, Failover oder Performancebewertung gebraucht werden.
Vorab planen
Vor dem Anlegen sollte der gewünschte Datenfluss konkret beschrieben werden. Ein Satz wie “Teams soll über WAN2” ist zu ungenau. Besser ist eine kleine Matrix:
| Feld | Beispiel |
|---|---|
| Source zone | LAN |
| Source network | Client_Net_10.20.0.0_24 |
| Destination | Microsoft-365-Zielgruppe, FQDN-Gruppe oder konkretes Netz |
| Services | HTTPS, UDP 3478-3481 oder definierte Dienste |
| Benutzer/Gruppe | optional, nur wenn User Matching stabil funktioniert |
| Primärer Gateway | WAN2 |
| Fallback | WAN1 |
| NAT | MASQ oder feste SNAT-IP passend zum Gateway |
| Test | Client-IP, Ziel, erwarteter Gateway, erwarteter Logeintrag |
Je klarer diese Matrix ist, desto weniger muss später geraten werden. Besonders bei VoIP, VPN, Cloud-Diensten und mehreren Standorten sollte man nicht mitAnystarten, nur weil es schneller klickbar ist.
Voraussetzungen
- Sophos Firewall im Gateway-Modus.
- Mindestens ein konfigurierter Gateway unter Network > WAN link manager oder ein geeigneter VPN-/XFRM-Pfad.
- Bekannte Source- und Destination-Netze.
- Passende Firewall-Regeln für den Traffic.
- Passende NAT-Regeln, falls der Traffic übersetzt werden muss.
- Logging auf den relevanten Firewall-Regeln.
- Zugriff auf Log viewer und Diagnostics > Packet capture.
Für Zonen, Interfaces und Gateways passt Sophos Firewall Zonen und Interfaces konfigurieren. Wenn die SD-WAN Route ein route-based IPsec VPN betrifft, sollte zusätzlich IPsec Route auf Sophos Firewall erstellen gelesen werden.
SD-WAN Route erstellen
Menüpfad:```text Routing > SD-WAN routes
1. **Add** öffnen.
2. Einen eindeutigen Namen vergeben, zum Beispiel`Clients_M365_WAN2`.
3. **Incoming interface** oder Source-Kontext passend zum Design wählen.
4. Source networks oder Benutzer nur so breit wie nötig setzen.
5. Destination networks, FQDN Hosts oder Internet Services bewusst wählen.
6. Services auf die benötigten Protokolle begrenzen.
7. Gateway oder SD-WAN Profile auswählen.
8. Failover- oder Backup-Pfad prüfen.
9. Regel speichern und in der Reihenfolge passend positionieren.
10. Test mit einem definierten Client durchführen.
Die genaue Oberfläche kann je nach SFOS-Version leicht abweichen. Entscheidend bleibt aber: Die Route muss den gewünschten Flow matchen und darf nicht zufällig mehr Traffic erfassen als geplant.
## Gateway und SD-WAN Profile wählen
SD-WAN Routes können direkt auf Gateways zeigen oder mit SD-WAN Profiles arbeiten. Welcher Ansatz passt, hängt vom Ziel ab.
| Ansatz | Sinnvoll, wenn |
| --- | --- |
| fester Gateway | Traffic bewusst über eine Leitung laufen soll |
| Gateway mit Backup | eine Leitung bevorzugt wird, aber Failover möglich sein soll |
| SD-WAN Profile | mehrere Gateways nach Gewichtung, SLA oder Priorität bewertet werden |
| XFRM-Interface oder VPN-Pfad | route-based IPsec in das Routing einbezogen wird |
Bei mehreren WAN-Leitungen sollte man zusätzlich prüfen, ob Gateway-Monitoring, Failover-Kriterien und Provider-Routing realistisch sind. Ein Gateway kann technisch "up" sein, obwohl eine bestimmte Zielanwendung über diesen Provider nicht sauber funktioniert.
## Reihenfolge und Route Precedence prüfen
SD-WAN Routes stehen nicht allein. Je nach Design konkurrieren sie mit direkt verbundenen Netzen, statischen Routen, VPN-Routen und der globalen Route Precedence.
Wichtige Fragen:
- Gibt es eine spezifischere statische Route zum Ziel?
- Matcht eine breitere SD-WAN Route weiter oben?
- Soll SD-WAN vor oder nach Static ausgewertet werden?
- Ist ein policy-based oder route-based IPsec VPN beteiligt?
- Betrifft die Route nur weitergeleiteten Client-Traffic oder auch Reply Packets und systemgenerierten Traffic?
Die globale Reihenfolge ist in [Sophos Firewall Route Precedence sicher ändern](/kb/sophos-firewall-routing-prioritaet-anpassen/) erklärt. Für die Spezialfälle **Reply Packets** und **System Traffic** passt [Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen](/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/).
## NAT nicht vergessen
Routing entscheidet, wohin ein Paket geht. NAT entscheidet, ob Source- oder Destination-Adresse verändert wird. Beides muss zusammenpassen.
Typische Beispiele:
- Internettraffic über WAN2 braucht eventuell MASQ oder eine feste SNAT-IP auf WAN2.
- Provider oder Cloud-Dienste erlauben nur eine bestimmte Public IP.
- Bei internen Netzen oder VPNs ist NAT oft falsch, weil die echte Source-IP erhalten bleiben soll.
- Nach Failover kann sich die Public Source-IP ändern und Gegenstellen können Sessions verwerfen.
Wenn eine SD-WAN Route korrekt wirkt, die Anwendung aber trotzdem scheitert, sollte NAT früh mitgeprüft werden. Die Grundlagen stehen in [NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT](/kb/sophos-firewall-nat-basics/).
## Test und Validierung
Ein grüner Gateway-Status beweist nicht, dass die SD-WAN Route den erwarteten Traffic trifft. Der Test muss einen echten Flow prüfen.
Sinnvoller Ablauf:
1. Testclient mit bekannter IP verwenden.
2. Ziel und Service exakt festlegen.
3. Firewall-Regel-Logging aktivieren.
4. Verbindung starten.
5. Im **Log viewer** Source, Destination, Service, Rule ID, NAT ID und Gateway prüfen.
6. Usage Counter der SD-WAN Route kontrollieren.
7. Bei Unklarheit **Diagnostics > Packet capture** mit engem Filter verwenden.
8. Primären Gateway testweise ausfallen lassen, wenn Failover validiert werden soll.
9. Nach dem Failback prüfen, ob Sessions und neue Verbindungen erwartbar laufen.
Für die Paketflussanalyse passt [Sophos Firewall Regel testen mit Log Viewer, Policy Test und Packet Capture](/kb/sophos-firewall-rule-testing/). Wichtig: Der Policy Tester ersetzt bei SD-WAN keinen echten Paketfluss-Test.
## Häufige Fehler
| Fehler | Wirkung | Besserer Ansatz |
| --- | --- | --- |
| Destination `Any` aus Bequemlichkeit | zu viel Traffic wird von SD-WAN erfasst | Zielnetze, FQDN Hosts oder Internet Services enger wählen |
| SD-WAN Route steht zu weit oben | spezifischere Anwendung oder Route wird übersteuert | Reihenfolge und Trefferzähler prüfen |
| NAT passt nicht zum Gateway | Anwendung sieht falsche Source-IP oder Rückweg bricht | NAT-Regel und MASQ/SNAT prüfen |
| Gateway-Monitoring ist zu grob | Gateway wirkt aktiv, obwohl Zielanwendung nicht erreichbar ist | SLA-/Monitoring-Ziele passend zum Dienst wählen |
| Route Precedence nicht beachtet | statische Route oder VPN-Route greift anders als erwartet | Route Precedence dokumentieren und testen |
| Reply Traffic falsch eingeordnet | Antworten laufen nicht über erwarteten Pfad | Packet Capture und Reply-Packet-Option prüfen |
| mehrere Änderungen gleichzeitig | Ursache bleibt unklar | eine Änderung, ein Test, dann weiter |
## Troubleshooting
Wenn die SD-WAN Route nicht wie erwartet greift, sollte man den Fehler nicht sofort durch breitere Regeln "lösen". Besser ist eine saubere Eingrenzung.
Prüfen:
1. Kommt das Paket überhaupt auf der Firewall an?
2. Trifft es die erwartete Firewall-Regel?
3. Matcht die SD-WAN Route laut Zähler?
4. Ist eine andere SD-WAN Route weiter oben spezifischer oder breiter?
5. Passt der Service wirklich, zum Beispiel TCP/UDP und Port?
6. Wird NAT angewendet und ist das gewollt?
7. Verlässt das Paket die Firewall über den erwarteten Gateway?
8. Kommt die Antwort zurück?
9. Gibt es eine statische Route, VPN-Route oder Route Precedence, die den Pfad beeinflusst?
Wenn Packet Capture gar kein Paket sieht, liegt das Problem vor der Firewall: Client-Gateway, VLAN, Switch, lokales Routing oder falscher Test. Wenn das Paket ankommt, aber über den falschen Pfad geht, sind SD-WAN-Kriterien, Reihenfolge, NAT und Route Precedence die nächsten Prüfpunkte.
## Betriebscheck
SD-WAN Routes sollten nach der Einführung dokumentiert und regelmässig geprüft werden. Besonders wichtig ist das bei Providerwechseln, neuen VPNs, zusätzlichen WAN-Leitungen oder Änderungen an Cloud-Diensten.
Dokumentieren sollte man:
- Zweck der Route
- Source- und Destination-Kriterien
- Services
- Gateway oder SD-WAN Profile
- NAT-Erwartung
- Failover-Verhalten
- Testclient und Testziel
- Owner und Review-Datum
Bei geschäftskritischen Anwendungen sollte zusätzlich klar sein, wer bei Providerstörungen, Failover-Problemen oder geänderten Public IPs reagieren muss.
## Checkliste
- Traffic-Ziel und Suchintention der Route klar beschrieben.
- Source, Destination und Services nicht unnötig breit gesetzt.
- Gateway oder SD-WAN Profile bewusst gewählt.
- Firewall-Regel und NAT-Regel passen zur Route.
- Route Precedence geprüft.
- Reply Packets und systemgenerierter Traffic nur bei Bedarf einbezogen.
- Log Viewer und Packet Capture für die Abnahme verwendet.
- Failover und Failback getestet, wenn sie Teil des Designs sind.
- Route dokumentiert und mit Owner versehen.
## Häufige Fragen
Wann braucht man eine SD-WAN Route auf Sophos Firewall?
Eine SD-WAN Route ist sinnvoll, wenn bestimmter Traffic abhängig von Quelle, Ziel, Service, Benutzer oder Gateway über einen bestimmten Pfad laufen soll. Für ein einfaches Zielnetz kann eine statische Route oft reichen.
Warum greift meine SD-WAN Route nicht?
Häufig passen Source, Destination, Service, Reihenfolge oder Route Precedence nicht. Zusätzlich kann eine Firewall-Regel, NAT-Regel oder statische Route den tatsächlichen Paketfluss beeinflussen.
Kann man SD-WAN mit route-based IPsec verwenden?
Ja, route-based IPsec kann mit XFRM-Interfaces und passenden Routen in SD-WAN-Designs eingebunden werden. Dann sollten IPsec-Status, SD-WAN Route, Route Precedence, NAT und Firewall-Regeln gemeinsam geprüft werden.
Sollte man Destination immer auf Any setzen?
Nein. Any ist nur sinnvoll, wenn die Route wirklich jeden Zieltraffic dieser Quelle steuern soll. Für Cloud-Dienste, VoIP, interne Netze oder VPNs sind engere Ziele meist sicherer und besser wartbar.
Reicht der Policy Tester für SD-WAN-Tests?
Nein. Der Policy Tester hilft bei Policy-Logik, ersetzt aber keinen echten Paketfluss-Test. Für SD-WAN sollte man Log Viewer, Trefferzähler und Packet Capture verwenden.