IPsec Route auf Sophos Firewall erstellen

Eine manuelle ipsec_route gehört zu policy-based IPsec. Sie ordnet einen Zielhost oder ein Zielnetz einem vorhandenen policy-based Tunnel zu. Sie erweitert aber keine Traffic Selector und ersetzt weder Firewall- und NAT-Regeln noch den Rückweg auf der Gegenstelle.

Für route-based IPsec ist dieser Befehl falsch. Bei einem Any-to-any-Tunnel erhält das XFRM-Interface eine IP-Adresse; statische, SD-WAN- oder dynamische Routen bestimmen danach den Pfad. Bei einem route-based Tunnel mit Traffic Selectors erzeugt SFOS die Route automatisch. Dem zugehörigen XFRM-Interface kann man weder eine IP-Adresse noch eigene Routen zuweisen.

⚠️ Eine zu breite oder dem falschen Tunnel zugeordnete Route kann produktiven Traffic umleiten. Sichere vor der Änderung den Ausgangszustand und halte den exakten Löschbefehl bereit.

Wann eine manuelle IPsec Route passt

Der typische Fall ist weitergeleiteter Traffic, dessen Adresse durch DNAT oder SNAT verändert wird. NAT ändert die Adresse, aber nicht die Routingentscheidung. Deshalb kann zusätzlich eine Route zum entfernten Netz nötig sein.

Prüfe vor dem Befehl:

• Die Verbindung unter Site-to-site VPN > IPsec > IPsec connections ist policy-based.
• Lokale und entfernte Traffic Selector umfassen die Adressen, die der IPsec-Verarbeitung nach NAT tatsächlich präsentiert werden.
• Firewall- und NAT-Regeln treffen den definierten Testverkehr. Bei SNAT für policy-based IPsec steht Outbound interface auf Any.
• Die Gegenstelle erwartet die sichtbare Quelladresse und besitzt eine Rückroute durch denselben Tunnel.
• Eine vorhandene statische oder SD-WAN Route und die globale Route Precedence ziehen das Ziel nicht auf einen anderen Pfad.

Eine manuelle Route repariert keine falsche Netzmaske, keinen unpassenden Selector und keine blockierende Regel. Grundlagen zu den Tunneltypen erklärt Sophos Firewall Site-to-Site IPsec VPN einrichten.

Ausgangszustand in der Device Console sichern

Öffne im WebAdmin admin > Console und wähle 4. Device console. Über SSH führt Sophos Firewall per SSH verbinden zum selben Menü.

Zeige zuerst die vorhandenen manuellen IPsec Routes und die globale Reihenfolge an:

system ipsec_route show
system route_precedence show

Speichere die Ausgabe zusammen mit Tunnelname, Traffic Selectors, Firewall Rule ID, NAT Rule ID und dem geplanten Testfluss. Unter SFOS 22 gehören automatisch erzeugte policy-based VPN-Routen und manuelle ipsec_route-Einträge zur Kategorie vpn. In der WebAdmin-Routingtabelle sind diese Routen nicht sichtbar; ip route show table 220 ist deshalb kein verlässlicher Gegenbeweis.

Ändere die Route Precedence nicht als Nebenarbeit. Sie ist global und beeinflusst weitere Verbindungen. Falls sie tatsächlich geändert werden muss, zeigt Sophos Firewall Route Precedence sicher ändern den getrennten Ablauf mit wertbasiertem Rollback.

Route mit einem kontrollierten NAT-Beispiel erstellen

Sophos dokumentiert diesen engen Anwendungsfall:

• Ein policy-based Tunnel HO_to_Branch verbindet lokal 192.168.2.0/24 mit remote 192.168.3.0/24.
• Der reale lokale Server 172.16.16.10 liegt ausserhalb des lokalen Selectors.
• Die Gegenstelle spricht ihn als 192.168.2.1 an. Diese Ersatzadresse gehört zum lokalen Selector und ist im Beispiel die LAN-Interface-Adresse der Firewall.

Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Ersetze Netz, Adressen und Tunnelname durch die eigenen Werte. Die Ersatzadresse muss zur lokalen Phase-2-Auswahl passen; das entfernte Zielnetz muss vom bestehenden Tunnel umfasst sein.

1. Entferntes Netz dem Tunnel zuordnen

Führe in der Device Console aus:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

SFOS erwartet bei net die vollständige Dezimalmaske. Verwende den engsten Zielbereich, den die Anwendung benötigt. Der zugehörige Rückbau lautet:

system ipsec_route del net 192.168.3.0/255.255.255.0

Der Löschbefehl enthält keinen Tunnelnamen. Prüfe deshalb vor dem Löschen mit system ipsec_route show, dass das Ziel eindeutig ist. Bei mehrdeutigen Einträgen darf nicht auf Verdacht gelöscht werden.

Für einen einzelnen Zielhost unterstützt die Konsole entsprechend diese Form:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

Eine Host-Route ist enger, aber nur richtig, wenn genau dieser Host das Ziel ist und die Traffic Selector dazu passen.

2. DNAT und reflexive SNAT konfigurieren

1. Erstelle unter Rules and policies > NAT rules > Add NAT rule > New NAT rule eine DNAT-Regel. Original source ist 192.168.3.0/24, Translated source bleibt Original, Original destination ist 192.168.2.1 und Translated destination ist 172.16.16.10.
2. Aktiviere Create reflexive rule.
3. Öffne die erzeugte Regel Reflexive_NAT#_<DNAT_rule_name>. Wähle für Translated source ein IP-Hostobjekt mit 192.168.2.1. Das Objekt wird unter Hosts and services > IP host > Add angelegt. Sophos kann in dieser reflexiven Regel nicht direkt auf ein Interface übersetzen.
4. Kontrolliere Reihenfolge, Status und Logging beider NAT-Regeln sowie die zugehörige Firewall-Regel.

Keine breite MASQ-Regel ergänzen und den realen Server nicht zusätzlich als unübersetzte Adresse durch den Tunnel freigeben. NAT auf Sophos Firewall verstehen erklärt Matching und Regelreihenfolge.

Den Datenpfad abnehmen

Ein grüner Tunnel und ein Ping belegen weder die NAT-Übersetzung noch den Rückweg. Definiere für die Abnahme einen realen Anwendungsfluss, beispielsweise TCP vom Remote-Client zum veröffentlichten Serverdienst.

1. Führe erneut system ipsec_route show aus. Das Zielnetz muss genau einmal dem geplanten Tunnel zugeordnet sein.
2. Erzeuge eine einzelne kontrollierte Verbindung von 192.168.3.0/24 zu 192.168.2.1 auf dem erlaubten Dienst.
3. Filtere Log viewer nach Source, Destination und Firewall Rule ID. In der Detailansicht zeigt src_trans_ip die tatsächliche übersetzte Quelladresse zuverlässiger als die Kurzansicht.
4. Öffne Monitor & analyze > Diagnostics > Packet capture und filtere auf Client, Ersatzadresse und realen Server. Rule ID und NAT ID müssen zu den dokumentierten Regeln gehören; Ein- und Ausgangsinterface müssen den geplanten Pfad zeigen.
5. Prüfe auf der Gegenstelle, dass Antworten von 192.168.2.1 erwartet und über denselben Tunnel zurückgeführt werden.
6. Teste einen benachbarten, nicht freigegebenen Host oder Dienst. Dieser Negativtest muss weiterhin scheitern und zeigt, dass Route und Regeln nicht zu breit sind.

Eine aktive SA oder steigende Byte-Zähler allein genügen nicht. Für eine vollständige Fehleranalyse hilft Sophos Firewall IPsec VPN Troubleshooting; für Regel- und Capture-Auswertung Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Änderung vollständig zurückrollen

Beende zuerst neue Testsitzungen. Stelle DNAT und reflexive SNAT einzeln auf ihren dokumentierten Vorzustand zurück; eine nachträgliche Änderung der DNAT-Regel entfernt die reflexive Regel nicht automatisch.

Lösche danach nur die neu angelegte Route:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Entferne das neue IP-Hostobjekt erst, wenn Object usage keine Referenz mehr zeigt. Wiederhole anschliessend den ursprünglichen Kontrollfluss und den Negativtest. Die zuvor gesicherte Route Precedence muss unverändert sein.

Falls nur die Route irrtümlich gelöscht wurde, stellt der gesicherte Add-Befehl den exakten Eintrag wieder her:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Variante: Remote-Clients erreichen eine virtuelle Adresse

Eine virtuelle Zieladresse kann interne Serveradressen vor der Gegenstelle verbergen. Dieses Szenario ist nicht mit dem policy-based NAT-Beispiel oben zu verwechseln: Die dokumentierte Variante nutzt route-based IPsec mit Any-to-any-Subnets, adressierte XFRM-Interfaces und normale Routen. Dafür wird keine manuelle ipsec_route angelegt.

Im Beispiel liegt hinter Firewall 1 das Netz 192.168.2.0/24; Remote-Clients hinter Firewall 2 kommen aus 192.168.3.0/24. Sie erreichen die Server 172.16.16.2 und 172.16.16.3 über die virtuelle Adresse 10.10.10.1. Diese Adresse ist eine DNAT-Zieladresse, nicht die XFRM-Gateway-Adresse. Alle Werte sind durch zur eigenen Umgebung passende Objekte zu ersetzen.

1. In den IPsec connections auf beiden Firewalls Connection type auf Route-based (Tunnel interface) sowie Local subnet und Remote subnets auf Any setzen. Firewall 1 verwendet im Beispiel Respond only, Firewall 2 Initiate the connection. Unter Network > Interfaces die blaue Leiste am jeweiligen Listening interface öffnen, das XFRM-Interface wählen, seine geplante IP-Adresse eintragen und speichern. Die Tunnel-Grundkonfiguration erklärt der Site-to-Site-IPsec-Ablauf.
2. Die Firewall-Regeln auf den tatsächlichen Anwendungsdienst begrenzen: auf Firewall 2 von LAN nach VPN mit Quelle 192.168.3.0/24 und den benötigten Zielen 192.168.2.0/24 beziehungsweise 10.10.10.1; auf Firewall 1 von VPN zur tatsächlichen Serverzone mit derselben Remote-Quelle und den benötigten Zielobjekten 192.168.2.0/24 beziehungsweise 10.10.10.1. Das Zielzonen-Beispiel Any ist keine Empfehlung für eine dauerhafte Freigabe.
3. Unter Routing > SD-WAN routes > IPv4 > Add auf Firewall 2 die Quelle 192.168.3.0/24 und die benötigten Ziele 192.168.2.0/24 beziehungsweise 10.10.10.1 über ein Gateway am lokalen XFRM-Interface routen. Unter Link selection settings > Primary and backup gateways das passende Primary gateway wählen oder anlegen. Auf Firewall 1 den Rückweg mit Quellen 192.168.2.0/24 beziehungsweise 10.10.10.1 und Ziel 192.168.3.0/24 über ihr XFRM-Gateway ergänzen. Statische oder dynamische Routen sind ebenfalls möglich.
4. Route only through specified gateways verhindert einen Ausweichpfad, indem bei nicht verfügbarem Tunnel verworfen wird. Das Beispiel aktiviert dies auf Firewall 2 und bietet es auf Firewall 1 optional an; die gewünschte Ausfallwirkung muss auf beiden Seiten bewusst festgelegt werden. Administration > Device access > Ping/Ping6 > VPN betrifft Ping zu lokalen Firewall-Diensten, nicht die Freigabe eines weitergeleiteten Serverdienstes.
5. Auf Firewall 1 unter Rules and policies > NAT rules > Add NAT rule > New NAT rule die DNAT-Regel anlegen: Original source 192.168.3.0/24, Translated source Original, Original destination 10.10.10.1, Translated destination ein Serverlistenobjekt mit 172.16.16.2 und 172.16.16.3, Load balancing method Round-robin. Nur den benötigten Dienst zulassen; die Liste ist für mehrere geeignete Backend-Server gedacht, nicht für beliebige Hosts.

Zur Abnahme mehrere neue Anwendungsverbindungen zur virtuellen Adresse erzeugen und im Packet Capture sowie anhand von Rule ID und NAT ID die gewählten Backends, den XFRM-Pfad und Antworten prüfen. Ein Ping allein bestätigt weder DNAT noch die Anwendung oder die Verteilung. Vorher Routen, Regeln und Objekte sichern; beim Rückbau nur die für diese Variante neu erstellten Elemente nach Abhängigkeitsprüfung entfernen beziehungsweise Vorwerte wiederherstellen. Es gibt hier keine ipsec_route zu löschen. Die folgenden Fehlerprüfungen unterscheiden deshalb weiterhin zwischen beiden Tunneltypen.

Typische Fehler gezielt eingrenzen

Die Route ist angelegt, Traffic geht aber zum WAN

Prüfe system ipsec_route show, Route Precedence und konkurrierende SD-WAN Routes. Unter SFOS 22 darf ein fehlender Eintrag in der WebAdmin-Routingtabelle oder in Tabelle 220 nicht als Beweis gegen die IPsec Route dienen. Bei der Route Precedence gewinnt vpn vor static nur für Traffic zur WAN-Zone; Zonen und tatsächlicher Zielpfad müssen deshalb mitgeprüft werden.

Der Tunnel ist aktiv, NAT greift aber nicht

Vergleiche Original- und übersetzte Adressen mit den Traffic Selectors. Bei policy-based SNAT muss Outbound interface Any sein. Prüfe danach Firewall Rule ID, NAT ID und src_trans_ip statt nur den Tunnelstatus.

Mit Any verwendet die Firewall die Translated source der passenden SNAT-Regel, auch wenn Override source translation (SNAT) für bestimmte Ausgangsinterfaces aktiviert ist. Eine Regel, die nur bestimmte WAN-Ports als Outbound interface aufführt, einschliesslich der üblichen Default-SNAT-Regel, trifft diesen policy-based IPsec-Traffic nicht. Die NAT-Erklärung im Site-to-Site-IPsec-Artikel ordnet dieses Zusammenspiel ein; daraus folgt keine pauschale Änderung der Overrides. Erzeuge nach einer gezielten Regelkorrektur einen neuen kontrollierten Anwendungsfluss und prüfe erneut NAT ID, src_trans_ip, Selector und Rückweg wie bei der Datenpfad-Abnahme oben.

Der Hinweg funktioniert, die Antwort fehlt

Die Gegenstelle muss die übersetzte Adresse kennen und über denselben Tunnel zurückführen. Kontrolliere dort Selector, Firewall-Regel und Rückroute. Ein abweichender Rückweg lässt sich nicht mit einer breiteren lokalen ipsec_route reparieren.

Systemgenerierter Traffic oder DHCP ist betroffen

Firewall-eigene Authentifizierungs-, DNS- und DHCP-Anfragen folgen einem eigenen Ablauf. Eine pauschale Aussage, dass Systemtraffic keine manuelle IPsec Route benötigt, wäre jedoch falsch: Bei policy-based IPsec sieht die Authentifizierungsanleitung für SFOS 22.0 und 23.0 ausdrücklich eine IPsec Route vor, wenn die Anfrage wegen der gewählten Route Precedence nicht in den Tunnel gelangt. Zuerst müssen Quelladresse, sys-traffic-nat, Traffic Selectors und Rückweg stimmen; erst dann wird nur das erforderliche Ziel dem vorhandenen policy-based Tunnel zugeordnet. Die Abnahme erfolgt mit einer echten Authentifizierungsanfrage und Packet Capture, der Rückbau separat mit dem passenden system ipsec_route del host- oder del net-Befehl nach Kontrolle des Eintrags.

Der vollständige Ablauf für policy-based und route-based Authentifizierung steht unter SD-WAN Routing für Reply Packets und System Traffic. Dort sind auch die Widersprüche zwischen den beschriebenen NAT-Adressrollen und den Befehlsbeispielen eingeordnet. Bei ungeklärter Quelladresse nicht produktiv ändern und insbesondere nicht die AD-Serveradresse als übersetzte Quelle übernehmen. Für route-based IPsec gelten XFRM-Routen, nicht ipsec_route; DHCP-Relay bleibt ein separater Ablauf. Daraus folgt weder eine pauschale Änderung der globalen Route Precedence noch eine Funktionsgarantie.

Nach dem SFOS-22-Upgrade fehlt eine dynamische Ankündigung

Policy-based VPN-Routen sind unter SFOS 22 keine gewöhnlichen Kernel-Routen. Wenn OSPF oder BGP sie zuvor über redistribute kernel angekündigt hat, erklärt Warum redistribute kernel nach dem SFOS-22-Upgrade keine IPsec-Routen mehr verteilt das eigenständige Migrationsproblem.