IPsec Route auf Sophos Firewall erstellen

Normalerweise erkennt die Sophos Firewall selbst, durch welchen IPsec-Tunnel ein Zielnetz erreichbar ist. Bei einem klassischen policy-based IPsec Tunnel sind lokale und entfernte Netze Teil der Tunnelkonfiguration. Bei route-based IPsec wird Traffic dagegen über XFRM-Interfaces, statische Routen, SD-WAN Routes oder dynamisches Routing in den Tunnel geführt.

Eine manuelle IPsec Route ist deshalb kein Standard für jeden Tunnel. Dabei handelt es sich um ein Werkzeug für bestimmte policy-based Szenarien, vor allem wenn weitergeleiteter Traffic mit NAT oder einer besonderen Zuordnung zum Tunnel arbeiten muss. Wenn man eine solche Route falsch setzt, kann Traffic in den falschen Tunnel laufen oder eine bestehende Verbindung schwerer nachvollziehbar werden.

Für neue Standorttunnel passt zuerst Sophos Firewall Site-to-Site IPsec VPN einrichten. Für allgemeines IPsec-Troubleshooting passt Sophos Firewall IPsec VPN Troubleshooting. Wenn es um route-based VPNs, XFRM und Interface-Planung geht, hilft Sophos Firewall Zonen und Interfaces konfigurieren.

Wann eine IPsec Route sinnvoll ist

Eine IPsec Route ist vor allem dann relevant, wenn ein policy-based IPsec-Tunnel zwar existiert, der erwartete Traffic aber nicht sauber dem Tunnel zugeordnet wird.

Typische Fälle:

• Ein Host oder Netz soll gezielt über einen bestimmten policy-based Tunnel laufen.
• Es gibt mehrere Tunnel, überlappende Zielnetze oder historisch gewachsene VPN-Konfigurationen.
• Traffic wird per DNAT oder SNAT übersetzt und muss danach einem bestehenden IPsec-Tunnel zugeordnet werden.
• Nach einem Upgrade auf SFOS 22 soll geprüft werden, ob alte policy-based Sonderfälle noch wie erwartet funktionieren.
• Route Lookup, Log Viewer oder Packet Capture zeigen, dass Traffic Richtung WAN oder falschen Pfad geht.

Nicht jeder dieser Fälle wird durch ipsec_route gelöst. Zuerst müssen Firewall-Regeln, NAT-Regeln, Route Precedence, lokale Gateways und Rückrouten geprüft werden.

Policy-based, route-based und SFOS 22

Der wichtigste Unterschied:

• Policy-based IPsec: Sophos Firewall führt IPsec-Lookups im Hintergrund aus. Gesteuert wird der Tunnel vor allem über lokale und entfernte Netze in der IPsec-Verbindung, Firewall-Regeln und bei Bedarf ipsec_route.
• Route-based IPsec: Traffic wird zur Tunnel-Schnittstelle geroutet. Die Steuerung erfolgt über XFRM-Interface, statische Route, SD-WAN Route oder dynamisches Routing.

Für neue oder grössere Standortverbindungen ist route-based IPsec oft übersichtlicher, weil Routing-Änderungen nicht jedes Mal die Tunnel-Selectoren verändern. Für einfache Site-to-Site-Verbindungen oder bestehende Umgebungen bleibt policy-based IPsec aber weiterhin relevant.

SFOS 22 hat an mehreren Stellen am IPsec-Verhalten gearbeitet. In den SFOS-22.0-MR1-Release-Notes sind mehrere behobene Probleme rund um policy-based IPsec, ipsec_route, SD-WAN, SNAT und Route Lookup dokumentiert. Für Admins heisst das: Nach einem Upgrade sollte man policy-based Sonderfälle gezielt testen, besonders wenn NAT, MPLS, SD-WAN oder manuelle IPsec Routes beteiligt sind.

Voraussetzungen

Vor einer Änderung sollten diese Punkte klar sein:

• Zugriff auf die Device Console, zum Beispiel per SSH.
• Name des IPsec-Tunnels.
• Zielhost oder Zielnetz, das über den Tunnel erreicht werden soll.
• Aktive oder korrekt konfigurierte IPsec-Verbindung.
• Passende Firewall-Regeln für die erwartete Richtung.
• Klarheit, ob NAT beteiligt ist.
• Aktueller Zustand der bestehenden IPsec Routes ist dokumentiert.

Falls der Konsolenzugriff noch nicht eingerichtet ist, erklärt Sophos Firewall per SSH verbinden, wie man eine SSH-Verbindung zur Firewall herstellt und die Device Console öffnet.

⚠️ Eine falsche IPsec Route kann produktiven Traffic stören. Vor der Änderung sollten Tunnelname, Zielnetz, NAT, Rückweg und vorhandene Routen dokumentiert sein.

Vor der Änderung prüfen

Man sollte eine IPsec Route nicht als ersten Schritt setzen. Sinnvoll ist diese Reihenfolge:

1. Tunnelstatus prüfen: IPsec-Verbindung ist aktiv und die erwarteten Netze sind ausgehandelt.
2. Firewall-Regeln prüfen: Source zone, Destination zone, Source, Destination, Service und Logging passen.
3. NAT prüfen: Es ist klar, ob Original-IP-Adressen oder übersetzte Adressen durch den Tunnel gehen sollen.
4. Route Precedence prüfen: Static, SD-WAN und VPN Routes werden in der erwarteten Reihenfolge ausgewertet. Wenn mehrere Routingarten konkurrieren, hilft Sophos Firewall Route Precedence sicher ändern.
5. Gegenstelle prüfen: Die Gegenstelle kennt Rückweg und erwartete Quelladresse.
6. Packet Capture verwenden: Belegen, ob Traffic ankommt, wohin er weitergeleitet wird und ob Antworten zurückkommen.

Für die allgemeine Regelprüfung passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Für NAT-Grundlagen passt NAT auf Sophos Firewall verstehen.

Bestehende IPsec Routes anzeigen

Die Befehle werden in der Device Console ausgeführt, nicht in der Advanced Shell.

system ipsec_route show

Die Ausgabe sollte vor jeder Änderung dokumentiert werden. So sieht man später, ob eine Route neu hinzugekommen ist und ob sie wieder entfernt werden muss.

Zusätzlich kann bei der Analyse die IPsec-Routing-Tabelle relevant sein:

ip route show table 220

Diese Prüfung erfolgt in der Advanced Shell und ist eher für Troubleshooting gedacht. Für normale Änderungen an ipsec_route bleibt die Device Console der richtige Ort.

IPsec Route für einen Host erstellen

Wenn nur ein einzelner Host über einen bestimmten Tunnel erreichbar sein soll, verwendet man host.

Syntax:

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Beispiel:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Danach sollte man nicht nur Ping testen, sondern den tatsächlichen Anwendungsverkehr prüfen. Ein ICMP-Test kann funktionieren, während TCP, NAT oder Rückweg weiterhin falsch sind.

IPsec Route für ein Netzwerk erstellen

Wenn ein komplettes Netzwerk über den Tunnel erreichbar sein soll, verwendet man net.

Syntax:

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Beispiel:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Bei Netzrouten ist besondere Vorsicht nötig. Ein zu grosses Netz kann mehr Traffic in den Tunnel ziehen als geplant. Bei überlappenden Netzen muss vorab klar sein, welche Seite welche Adressen sieht und ob NAT verwendet wird.

IPsec Route entfernen

Wenn die Route nicht mehr benötigt wird oder falsch gesetzt wurde, kann sie wieder gelöscht werden.

Host-Route entfernen:

system ipsec_route del host <host-ip> tunnelname <tunnelname>

Netz-Route entfernen:

system ipsec_route del net <network>/<netmask> tunnelname <tunnelname>

Danach die Liste erneut prüfen:

system ipsec_route show

Wenn die Route produktiven Traffic beeinflusst hat, sollte man die betroffene Verbindung nach dem Entfernen erneut testen und die Log Viewer Einträge vergleichen.

NAT und policy-based IPsec

NAT ist bei IPsec nicht grundsätzlich falsch. Es muss aber sauber geplant sein, weil NAT die Adresse verändert, die die Gegenstelle sieht.

Sophos unterscheidet bei IPsec unter anderem diese Fälle:

• NAT direkt in der IPsec-Konfiguration, zum Beispiel bei überlappenden Netzen.
• Eigenständige NAT-Regeln unter Rules and policies > NAT rules.
• ipsec_route für weitergeleiteten Traffic, wenn übersetzter Traffic einem policy-based Tunnel zugeordnet werden muss.
• sys-traffic-nat für systemgenerierten Traffic der Firewall selbst.

Wichtig ist die Richtung: Wenn policy-based IPsec-Traffic per SNAT übersetzt werden soll, muss die passende SNAT-Regel mit Outbound interface auf Any arbeiten. Wenn die Regel stattdessen auf bestimmte WAN-Interfaces zeigt, wird sie für policy-based IPsec-Traffic nicht angewendet. Genau solche Details führen in der Praxis zu Tunneln, die grün sind, aber keinen erwarteten Nutztraffic transportieren.

Systemgenerierter Traffic ist ein Sonderfall

ipsec_route ist nicht für jeden Traffic gedacht. Der Befehl gehört zu forwarded traffic. Systemgenerierter Traffic der Firewall selbst, etwa Authentifizierungsanfragen oder DHCP-bezogene Fälle, wird anders behandelt.

Praktisch bedeutet das:

• Client- oder Servertraffic durch die Firewall kann ein ipsec_route-Thema sein.
• Firewall-eigene Anfragen brauchen je nach Szenario SD-WAN-Routen, Route Precedence oder sys-traffic-nat.
• Man sollte nicht versuchen, jedes System-Traffic-Problem pauschal mit ipsec_route zu lösen.

Für systemgenerierten Traffic und SD-WAN-Kontext passt SD-WAN Routing für Reply Packets und System Traffic.

Änderung testen

Nach dem Erstellen oder Entfernen einer IPsec Route sollte der betroffene Traffic gezielt getestet werden.

Praktischer Ablauf:

1. Testfall definieren: Source, Destination, Service, Richtung und erwarteter Tunnel.
2. Firewall-Regel-Logging für die betroffene Regel aktivieren.
3. system ipsec_route show dokumentieren.
4. Testtraffic genau einmal erzeugen.
5. Log Viewer auf Source, Destination und Firewall-Regel filtern.
6. Packet Capture mit engem Filter ausführen.
7. Prüfen, ob Bytes in ipsec statusall in beide Richtungen steigen.
8. Gegenstelle auf Rückroute, NAT und lokale Firewall prüfen.

Wenn grössere Übertragungen hängen bleiben, obwohl Routing und NAT korrekt wirken, sollte zusätzlich MTU und MSS bei VPN-Problemen geprüft werden.

Typische Fehler

Typische Fehlerbilder:

• Tunnel grün, kein Traffic: Häufig fehlen Regel, NAT, Rückroute oder IPsec-Zuordnung. Log Viewer, Packet Capture und ipsec statusall prüfen.
• Traffic geht Richtung WAN: Route Precedence oder IPsec-Zuordnung passt nicht. Route Lookup, SD-WAN Routes und ipsec_route show prüfen.
• SNAT greift nicht bei policy-based IPsec: Die SNAT-Regel hat vermutlich ein falsches Outbound Interface. SNAT-Regel auf Any prüfen.
• Ein Host funktioniert, ein Netz nicht: Netzmaske, Objekt oder Traffic Selector passt nicht. Lokale und entfernte Netze vergleichen.
• Nach SFOS-22-Upgrade anderes Verhalten: Ein alter Sonderfall mit policy-based IPsec, NAT oder SD-WAN kann beteiligt sein. Release Notes, Testfall und Gegenstelle prüfen.
• Firewall-eigener Traffic geht nicht durch den Tunnel: System Traffic wird anders geroutet. SD-WAN, Route Precedence und sys-traffic-nat prüfen.

Checkliste

Vor der Änderung:

• Tunnelname und Gegenstelle dokumentiert.
• Zielhost oder Zielnetz eindeutig.
• Firewall-Regeln und NAT-Regeln geprüft.
• Route Precedence und SD-WAN-Kontext geprüft.
• Bestehende IPsec Routes gesichert.
• Wartungsfenster oder kontrollierter Testzeitpunkt geplant.

Nach der Änderung:

• system ipsec_route show erneut geprüft.
• Log Viewer zeigt die erwartete Regel.
• Packet Capture zeigt den erwarteten Pfad.
• Gegenstelle sieht die erwartete Quelladresse.
• Rückweg funktioniert.
• Änderung und Begründung dokumentiert.

FAQ