IPsec Route auf Sophos Firewall erstellen

Eine manuelle IPsec Route ist kein Standard für jeden Tunnel. Sie kommt vor allem bei policy-based IPsec infrage, wenn weitergeleiteter und übersetzter Traffic einem bestimmten Tunnel zugeordnet werden muss.

Route-based IPsec: Keine ipsec_route anlegen. Der Traffic läuft über XFRM-Interfaces und statische, SD-WAN- oder dynamische Routen. Policy-based IPsec ohne NAT-Sonderfall: Zuerst Tunnel, Firewall-Regeln, NAT und Rückweg prüfen. Policy-based IPsec mit weitergeleitetem DNAT- oder SNAT-Traffic: Die folgenden Schritte helfen bei Prüfung und Konfiguration.

⚠️ Eine falsche IPsec Route kann produktiven Traffic in den falschen Tunnel lenken. Vor jeder Änderung den Ausgangszustand sichern und einen exakten Rückweg vorbereiten.

IPsec Route prüfen, erstellen und entfernen

Die Befehle zum Anzeigen, Erstellen und Entfernen werden in der Device Console ausgeführt. Falls der Zugriff noch fehlt, zeigt Sophos Firewall per SSH verbinden den Weg zur Device Console.

Ausgangszustand sichern

Vor einem Add-Befehl muss der konkrete Pfad feststehen:

• Es handelt sich um einen aktiven policy-based Tunnel, nicht um route-based IPsec.
• Zielhost oder Zielnetz passen zu den Tunnel-Selectoren und zur geplanten Übersetzung.
• Firewall- und NAT-Regel treffen den definierten Testtraffic; bei SNAT steht Outbound interface auf Any.
• Route Precedence und konkurrierende Routen wurden geprüft.
• Die Gegenstelle erwartet die sichtbare Quelladresse und besitzt eine Rückroute.

Zuerst alle manuellen IPsec Routes dokumentieren:

system ipsec_route show

Bei Routing- oder NAT-Problemen zusätzlich Route Precedence und System-Traffic-NAT sichern:

system route_precedence show
show advanced-firewall

In der Advanced Shell kann auch diese ältere Troubleshooting-Ansicht nützlich sein:

ip route show table 220

Unter SFOS 22 sind policy-based IPsec Routes und ipsec_route-Einträge dort laut Sophos nicht sichtbar. Ein fehlender Eintrag beweist deshalb nicht, dass keine IPsec Route vorhanden ist. Massgebend bleiben system ipsec_route show, die Konfiguration und ein Traffic-Test.

Route für einen Host erstellen

Syntax:

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

Beispiel für den Host 10.33.46.69 über den Tunnel Azure_CH:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Route für ein Netzwerk erstellen

Syntax:

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

Beispiel für das Netz 10.33.46.0/24:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Die Netzmaske muss exakt zum gewünschten Ziel passen. Eine zu breite Route kann unbeabsichtigt weiteren Traffic in den Tunnel ziehen.

Route sicher entfernen

⚠️ Die Löschbefehle enthalten keinen Tunnelnamen. Vor dem Löschen mit system ipsec_route show prüfen, dass Host oder Netz eindeutig sind, und den vollständigen Add-Befehl für den Rollback bereithalten. Bei mehrdeutigen Einträgen nicht auf Verdacht löschen.

Host-Route entfernen:

system ipsec_route del host <host-ip>

Netz-Route entfernen:

system ipsec_route del net <network>/<netmask>

Danach die Liste erneut prüfen:

system ipsec_route show

Fällt der Test schlechter aus, die Route mit dem zuvor gesicherten Add-Befehl wiederherstellen.

Wann ipsec_route passt

Policy-based und route-based IPsec

Bei policy-based IPsec definieren die lokalen und entfernten Netze die Tunnel-Selectoren. Eine manuelle ipsec_route kann zusätzliche Hosts oder Netze einem vorhandenen Tunnel zuordnen, ersetzt aber weder passende Selector noch Firewall-Regeln und Rückroute.

Bei route-based IPsec wird der Traffic zur XFRM-Schnittstelle geroutet. Dafür verwendet man je nach Design eine statische Route, eine SD-WAN Route oder dynamisches Routing. Eine ipsec_route ist hier das falsche Werkzeug. Grundlagen zu beiden Varianten stehen unter Sophos Firewall Site-to-Site IPsec VPN einrichten und Sophos Firewall Zonen und Interfaces konfigurieren.

Unterschied zwischen SFOS 21.5 und 22

Die Einordnung in der Route Precedence hat sich geändert:

• Unter SFOS 21.5 zählen automatisch erzeugte policy-based IPsec Routes zur Kategorie vpn, manuelle ipsec_route-Einträge dagegen zu static.
• Unter SFOS 22 zählen automatische und manuelle policy-based IPsec Routes zur Kategorie vpn. Sie erscheinen nicht wie gewöhnliche Kernel-Routen und werden intern anhand von Markierungen, Zonen und Flags verarbeitet.

Wer von SFOS 21.5 aktualisiert, sollte deshalb Route Precedence und bestehende Sonderfälle erneut testen. Der SFOS 22 Upgrade Check enthält die übergreifenden Prüfungen. Die globale Reihenfolge erklärt Sophos Firewall Route Precedence sicher ändern.

Wurden policy-based VPN-Netze bisher mit redistribute kernel an OSPF oder BGP weitergegeben, reicht diese Kontrolle nicht: Ab SFOS 22 sind die VPN-Routen keine normalen Kernel-Routen mehr. Warum redistribute kernel nach dem SFOS-22-Upgrade keine IPsec-Routen mehr verteilt erklärt das Fehlerbild und das route-based XFRM-Zieldesign.

Eine manuelle Route ist erst sinnvoll, wenn Tunnel, Traffic Selector, Firewall-Regel, NAT-Regel und Rückweg stimmen. Sie behebt keine falsche Netzmaske, fehlende Gegenstellenroute oder blockierende Regel.

NAT bei weitergeleitetem Traffic

NAT verändert die Adressen, aber nicht automatisch die Routing-Entscheidung. Nutzt ein policy-based Tunnel zusätzlichen, per DNAT oder SNAT übersetzten Traffic, kann deshalb eine passende IPsec Route zum entfernten Host oder Netz nötig sein.

Bei SNAT für policy-based IPsec muss die passende NAT-Regel mit Outbound interface Any arbeiten. Ist sie auf ein bestimmtes WAN-Interface eingeschränkt, trifft sie den IPsec-Traffic nicht. NAT auf Sophos Firewall verstehen erklärt Reihenfolge, Matching und Rückweg ausführlicher.

Die Änderung sollte in einem Wartungsfenster oder mit einem kontrollierten Testfall erfolgen. Vorher müssen diese Werte feststehen:

• ursprüngliche und übersetzte Quell- und Zieladresse,
• lokales und entferntes Netz der IPsec-Verbindung,
• Tunnelname und erwartete Firewall-Regel,
• Rückroute und erlaubte Adressen auf der Gegenstelle.

Systemgenerierten Traffic separat behandeln

DNS-, Authentifizierungs- oder andere Anfragen der Firewall selbst folgen nicht automatisch derselben Logik wie weitergeleiteter Client-Traffic. Unter SFOS 22 ist dafür im Normalfall keine ipsec_route nötig. Nur die spezielle Sophos-Anleitung für Authentifizierungsanfragen nennt sie als bedingte Ausweichlösung, wenn die Anfrage wegen der konkreten Route Precedence nachweislich nicht in den policy-based Tunnel gelangt.

Die Quelladresse für solchen Traffic lässt sich bei Bedarf mit sys-traffic-nat festlegen. Beispiel: Die Firewall soll den Server 10.10.2.15 mit der definierten SNAT-/Interface-Adresse 10.10.1.1 erreichen. Diese Adresse muss zu den IPsec-Subnetzen passen und auf der Gegenstelle zurückgeroutet werden.

Die folgenden Befehle werden in der Device Console ausgeführt:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1
show advanced-firewall

Rollback:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Wenn beim Hinzufügen auch interface oder netmask verwendet wurden, müssen beim Löschen dieselben Selektoren angegeben werden. Weitere Beispiele enthält SD-WAN Routing für Reply Packets und System Traffic.

DHCP benötigt eine eigene Einordnung:

• Bei policy-based IPsec braucht das Relay die Option Relay through IPsec, passende lokale und entfernte IPsec-Subnetze, sys-traffic-nat sowie die erforderlichen Regeln und Rückwege auf der Gegenstelle. Gehen die Anfragen wegen der konkreten Routingkonfiguration trotzdem nicht in den Tunnel, kann eine ipsec_route als geprüfter Fallback nötig sein.
• Bei route-based IPsec wird Relay through IPsec nicht aktiviert. Unterstützt ist ein Relay zur DHCP-Server-Seite über ein XFRM-Interface mit Any-to-any-Subnetzen, statischen, SD-WAN- oder dynamischen Routen und passenden Regeln auf beiden Firewalls. Eine ipsec_route gehört nicht in diesen Pfad.
• Arbeitet die Firewall am Hauptstandort bei einem policy-based IPsec-Aufbau selbst als DHCP-Server für entfernte Netze, muss Lease over IPsec aktiviert sein. Firewall-Interfaces als DHCP-Server werden laut Sophos für diesen route-based Aufbau nicht unterstützt.

Auch dieser Befehl wird in der Device Console ausgeführt:

system dhcp lease-over-IPSec enable

Ältere SFOS-21.5-Abläufe nannten ipsec_route bei Authentifizierung und DHCP häufiger ausdrücklich. Solche Konfigurationen sollten bei einem Upgrade geprüft und nicht ungeprüft nachgebaut werden.

Änderung testen und abnehmen

Ein grüner Tunnel oder ein erfolgreicher Ping reicht nicht als Nachweis. Ein ICMP-Test kann funktionieren, obwohl TCP, NAT oder Rückweg weiterhin falsch sind.

1. Source, Destination, Service, Richtung und erwarteten Tunnel festlegen.
2. Logging der betroffenen Firewall-Regel aktivieren.
3. system ipsec_route show vor dem Test sichern.
4. Den echten Anwendungsverkehr gezielt einmal erzeugen.
5. Log Viewer nach Source, Destination und Regel filtern.
6. Packet Capture mit engem Filter auf beiden Seiten des Pfads durchführen.
7. Auf der Gegenstelle Quelladresse, Rückroute und lokale Firewall prüfen.
8. Ergebnis, Änderung und Rollback-Befehl dokumentieren.

In der Advanced Shell zeigen diese Befehle ausgehandelte SAs, Byte-Zähler und XFRM-Policies:

ipsec statusall
ip xfrm policy

Sie belegen allein jedoch nicht, dass NAT, Firewall-Regel und Rückweg stimmen. Für die systematische Analyse hilft Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Bleiben nur grössere Übertragungen hängen, sollte man zusätzlich MTU und MSS bei VPN-Problemen prüfen.

Fehler eingrenzen und zurückrollen

Tunnel ist aktiv, aber kein Traffic fliesst

Firewall-Regel, NAT, Traffic Selector und Rückroute prüfen. Danach Log Viewer, Packet Capture und die Zähler aus ipsec statusall vergleichen. Der vollständige Ablauf steht unter Sophos Firewall IPsec VPN Troubleshooting.

Traffic geht Richtung WAN

Route Precedence, SD-WAN Routes und system ipsec_route show prüfen. Unter SFOS 22 darf ein fehlender Eintrag in Tabelle 220 nicht als Beweis gegen eine IPsec Route verwendet werden.

SNAT greift nicht

Bei policy-based IPsec kontrollieren, ob Outbound interface auf Any steht und ob Original- sowie übersetzte Adressen zu Tunnel und Gegenstelle passen.

Ein Host funktioniert, ein Netz nicht

Netzmaske, Host-/Netzobjekt und Traffic Selector auf beiden Seiten vergleichen. Keine breitere Route anlegen, bevor die Abweichung verstanden ist.

Nach dem SFOS-22-Upgrade ändert sich der Pfad

Route Precedence und alle policy-based Sonderfälle mit NAT, SD-WAN oder MPLS erneut prüfen. Nicht automatisch alte Routen löschen oder neu anlegen.

Firewall-eigener Traffic erreicht das Ziel nicht

Zuerst unterscheiden, ob es um Authentifizierung, DNS, DHCP oder einen anderen Dienst geht. Danach Route Precedence, SD-WAN, sys-traffic-nat und den jeweiligen SFOS-22-Workflow prüfen.

Wenn ein Fehler direkt nach der Änderung beginnt, die neue Route entfernen, mit system ipsec_route show kontrollieren und den vorherigen Test wiederholen. Bleibt das Problem bestehen, den dokumentierten Ausgangszustand vollständig wiederherstellen.

FAQ