SFOS 22: Policy-based IPsec-Routen in OSPF und BGP

Nach einem Upgrade auf SFOS 22 kann ein policy-based IPsec-Tunnel weiterhin funktionieren, während ein zuvor über OSPF oder BGP angekündigtes VPN-Präfix fehlt. Auch die Routing-Nachbarschaft kann dabei Full oder Established bleiben.

Sophos dokumentiert, dass SFOS 22 die früheren VPN-Routen für policy-based IPsec nicht mehr erzeugt und ipsec0 im Sendeweg nicht mehr verwendet. Verschwindet gleichzeitig ein OSPF- oder BGP-Präfix, ist der Zusammenhang mit der Redistribution als betriebliche Beobachtung zu behandeln: Die KBA beschreibt weder redistribute kernel noch OSPF oder BGP. Ein fehlendes Präfix ist deshalb nicht automatisch ein Tunnel-Ausfall.

⚠️ Keine Dummy-, Null-, Blackhole- oder andere Hilfsroute nur für die Ankündigung anlegen. Sie kann den Datenpfad verändern. Vor Änderungen in Produktion das konkrete Design mit Sophos Support oder in einem geplanten Design- und Wartungsfenster klären.

Kurzdiagnose

Dieses Upgrade-Muster unter SFOS 22 untersuchen, wenn alle Punkte zutreffen:

1. Das Problem begann mit dem Upgrade auf SFOS 22.
2. Der Tunnel ist policy-based.
3. OSPF oder BGP verwendete bisher redistribute kernel für das VPN-Präfix.
4. Tunnel und Neighbor sind aktiv, aber das Präfix fehlt auf dem empfangenden Router.

Bei einem route-based Tunnel oder einer ausgefallenen Nachbarschaft muss dagegen der jeweilige Tunnel- beziehungsweise Routingfehler untersucht werden.

Warum die normalen Routing-Ansichten nicht ausreichen

Die KBA hält fest, dass SFOS 22 die früheren policy-based VPN-Routen nicht mehr erzeugt. Unabhängig davon beschreibt sie ipsec_route-Routen unter SFOS 22 als Teil der Precedence-Klasse vpn, die nicht in der Routing-Tabelle erscheinen. Wie OSPF oder BGP beide Fälle bei der Redistribution behandelt, sagt die KBA nicht.

Damit sind drei Zustände getrennt zu bewerten:

• VPN: Ist die IPsec-Verbindung aktiv und fliesst Traffic?
• Routingprotokoll: Ist der OSPF- oder BGP-Neighbor aufgebaut?
• Ankündigung: Lernt der entfernte Router genau das erwartete Präfix?

Eine grüne VPN-Verbindung beweist keine Routenankündigung. Umgekehrt beweist die fehlende Route in der gewöhnlichen Routing-Anzeige bei policy-based IPsec unter SFOS 22 keinen defekten Tunnel.

Den VPN-Datenstrom in der Conntrack-Ausgabe erkennen

SFOS 22 verwendet ipsec0 nicht mehr im Sendeweg und erzeugt die früheren VPN-Routen nicht mehr. Für die konkret getestete Verbindung sind stattdessen die Conntrack-Werte massgeblich: Traffic zum VPN hat mark=0x0, outzone=5 und Flag 74; Traffic aus dem VPN hat mark=0x0, inzone=5 und Flag 75. Zone 5 ist die VPN-Zone; das Flag kann zusammen mit weiteren Werten in flagvalues erscheinen.

Diese Werte bestimmen die Richtung einer beobachteten VPN-Verbindung, belegen aber keine OSPF- oder BGP-Ankündigung. Unter SFOS 22 ist es ebenfalls erwartbar, dass Packet Capture im Sendeweg kein ipsec0 zeigt und Route Lookup unter Diagnostics > Tools das WAN-Interface anzeigen kann. Einen eng eingegrenzten Testdatenstrom deshalb in Conntrack und Packet Capture korrelieren, statt eine der Anzeigen allein als Fehler zu werten.

Sicher und lesend prüfen

Firewall und VPN erfassen

1. SFOS-Version und Build dokumentieren.
2. Unter Site-to-site VPN > IPsec Verbindungsstatus, Tunneltyp und konfigurierte lokale sowie entfernte Subnetze erfassen.
3. Unter Routing > Routing information Route Lookup für ein konkretes Ziel ausführen. Die Einschränkung für policy-based VPN- und ipsec_route-Routen bei der Auswertung berücksichtigen.
4. In 4. Device Console die dokumentierte Konfiguration anzeigen:

system route_precedence show
system ipsec_route show

Diese Befehle ändern nichts. Route Precedence zeigt die globale Reihenfolge der Routenklassen; system ipsec_route show zeigt manuelle IPsec-Routen. Keiner der Befehle belegt für sich, dass OSPF oder BGP ein Präfix ankündigt.

Bei lesendem Zugriff auf die Advanced Shell zusätzlich die in der KBA verwendeten Routen- und Verbindungsansichten erfassen:

route -n
ip route show
conntrack -L

Die Conntrack-Auswertung auf Test-Endpunkte und Zeitfenster eingrenzen. Diese Ausgaben können das Fehlen der früheren Route beziehungsweise von ipsec0 und den getesteten VPN-Datenstrom bestätigen; sie belegen keine Redistribution oder Ankündigung.

ipsec_route-Priorität vor einer Änderung prüfen

Unter SFOS 21.5 gehörte eine mit ipsec_route hinzugefügte Route zur Klasse static; unter SFOS 22 gehört sie zur Klasse vpn. Bei static sdwan_policyroute vpn kann daher nach dem Upgrade eine zu den VPN-Selektoren passende SD-WAN-Policy-Route den Traffic übernehmen. Wenn das geprüfte Design den VPN-Vorrang verlangt, dokumentiert Sophos static vpn sdwan_policyroute als Zielreihenfolge und system route_precedence set static vpn sdwan_policyroute als ändernden Befehl.

Diesen Befehl nicht allein aufgrund dieser Diagnose ausführen: Route Precedence gilt global und kann anderen Traffic beeinflussen. Zuerst system route_precedence show, passende SD-WAN-Regeln, Hin- und Rückweg sowie einen Rückkehrpunkt erfassen. Danach die Route Precedence sicher ändern mit Vorprüfungen, kontrollierter Änderung, Validierung und Rollback verwenden.

OSPF oder BGP getrennt prüfen

Im passenden Routing-CLI können die von Sophos dokumentierten Anzeigebefehle verwendet werden:

show running-config
show ip ospf neighbor
show ip ospf route
show ip bgp

Nur die zum eingesetzten Protokoll gehörenden Befehle ausführen. Zusätzlich auf dem empfangenden Router Präfix und Next Hop erfassen. Die vollständigen Prüfpfade zeigen OSPF konfigurieren und prüfen und BGP konfigurieren und prüfen.

Die Designentscheidung treffen

Dynamisches Routing ist erforderlich

Für dynamisches Routing dokumentiert Sophos route-based Any-to-Any-IPsec. Dabei entstehen XFRM-Interfaces, die adressiert und für OSPF oder BGP verwendet werden können. Routing-Nachbarschaft und Präfixe sind dann explizite Bestandteile des Designs und kein Nebeneffekt einer policy-based VPN-Route.

Das ist eine Designrichtung, keine allgemeine Migrationsanleitung. Adressierung, Routingfilter, Firewall-Regeln, NAT, Rückweg, Redundanz und die Gegenstelle hängen von der jeweiligen Topologie ab. Die Umstellung daher vor einer Produktionsänderung mit Sophos Support beziehungsweise in einem Design- und Wartungsfenster planen. Die Tunnelgrundlagen stehen unter Site-to-Site IPsec VPN einrichten.

Policy-based IPsec soll bestehen bleiben

Die KBA dokumentiert weder die Redistribution über OSPF oder BGP noch einen Befehl, der die frühere VPN-Route für eines der Protokolle verfügbar macht. Eine weitere ipsec_route, eine Änderung der Route Precedence oder eine künstliche statische Route ersetzt kein geprüftes Routingdesign.

Wenn policy-based IPsec beibehalten werden muss, den Ankündigungsweg topologiespezifisch mit Sophos Support entwerfen. Vorab helfen der SFOS 22 Upgrade-Check und die Einordnung unter IPsec Route auf Sophos Firewall erstellen.

Vor einer Produktionsänderung

Für einen Support- oder Design-Termin mindestens diese Daten bereitstellen:

• SFOS-Version und Build, Tunneltyp und HA-Status,
• anonymisierte lokale und entfernte Präfixe,
• bisherige OSPF- oder BGP-Konfiguration und Neighbor-Status,
• erwartete und tatsächlich empfangene Präfixe samt Next Hop,
• relevante Route-Lookup-, Log-Viewer- und Packet-Capture-Ergebnisse,
• Anforderungen an Rückweg, NAT, Failover und Wartungsfenster.

Keine gleichzeitigen Änderungen an VPN, Routing, NAT und Firewall-Regeln ohne festgelegten Prüf- und Rückkehrpunkt vornehmen. Erst nach freigegebenem Design die geplanten Ebenen einzeln prüfen: Tunnel/XFRM, Neighbor, angekündigte Präfixe, Hin- und Rückweg sowie einen echten Dienst.

Fehlerbilder unterscheiden

Neighbor aktiv, Präfix fehlt

Tunneltyp, SFOS-Build und show running-config vergleichen. Die fehlende frühere VPN-Route, eine aktive Nachbarschaft und ein fehlendes empfangenes Präfix sind getrennte Beobachtungen. Ob die Redistribution von dieser Route abhing, muss anhand der Routingkonfiguration und des empfangenden Routers geprüft werden.

Präfix vorhanden, Traffic gestört

Dann ist die fehlende Redistribution nicht die unmittelbare Ursache. Route Lookup, Regeln, NAT und Rückweg getrennt untersuchen.

ipsec_route vorhanden, Präfix fehlt

system ipsec_route show bestätigt nur die manuelle Zuordnung. Es bestätigt weder eine gewöhnliche Kernel-Route noch eine OSPF- oder BGP-Ankündigung.

Kein allgemeiner Rollback-Ablauf

Ohne die konkrete Topologie gibt es keine sichere Reihenfolge für Koexistenz, Umschaltung, Rücknahme oder Failover. Diese Schritte gehören in den mit Sophos Support abgestimmten Änderungsplan; dieser Artikel gibt dafür bewusst keine Befehlsfolge vor.

FAQ