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

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.

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. Unter SFOS 22 benötigen sie normalerweise keine manuelle IPsec Route. Nutze dafür SD-WAN Routing für Reply Packets und System Traffic beziehungsweise das separate DHCP-Relay-Runbook, statt diesen Forwarding-Ablauf zu übertragen.

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.