SFOS 22: redistribute kernel verteilt IPsec-Routen nicht mehr

Nach einem Upgrade auf SFOS 22 kann der IPsec-Tunnel weiterhin aktiv sein und auch der OSPF- oder BGP-Nachbar gesund aussehen. Trotzdem fehlen auf den Nachbarroutern plötzlich die Netze hinter einem policy-based IPsec-Tunnel.

Der typische Auslöser ist redistribute kernel: Bis SFOS 21.5 konnten die für diesen Workflow verwendeten policy-based VPN-Routen aus der Kernel-Routingtabelle übernommen werden. Mit SFOS 22.0 GA verarbeitet die Firewall diese Routen intern im VPN-Backend. redistribute kernel findet sie deshalb nicht mehr.

⚠️ Keine statische Dummy-, Null- oder Blackhole-Route anlegen, nur damit das Präfix wieder in OSPF oder BGP erscheint. Eine solche Route kann abhängig von Route Precedence selbst den Datenpfad übernehmen und produktiven Traffic am Tunnel vorbeileiten oder verwerfen.

Kurzantwort: Was jetzt zu tun ist

Wenn ein zuvor angekündigtes VPN-Netz nach dem Upgrade fehlt, wird zuerst geprüft, ob alle folgenden Punkte zutreffen:

1. Die Firewall wurde von SFOS 21.5 oder älter auf SFOS 22 aktualisiert.
2. Der betroffene Tunnel ist policy-based.
3. OSPF oder BGP hat die VPN-Netze bisher über redistribute kernel übernommen.
4. Der Neighbor bleibt Full beziehungsweise Established, aber das erwartete Präfix fehlt auf der empfangenden Seite.

Trifft das zu, ist ein neuer ipsec_route-Eintrag keine Lösung: Auch dieser erzeugt unter SFOS 22 keine normale Kernel-Route. Für ein dauerhaft nachvollziehbares Design empfiehlt sich route-based Any-to-Any-IPsec mit adressierten XFRM-Interfaces und einer expliziten OSPF- oder BGP-Konfiguration.

Der SFOS 22 Upgrade-Check hilft bei der Vorbereitung. Die eigentliche Tunnelkonfiguration steht unter Site-to-Site IPsec VPN einrichten.

Warum die Route nach dem Upgrade fehlt

Eine Kernel-Route ist ein Eintrag in der normalen Routingtabelle des Betriebssystems. Routingdienste können solche Einträge als Quelle übernehmen und beispielsweise mit redistribute kernel an Nachbarn weitergeben.

SFOS 22 behandelt policy-based IPsec anders: Der Paketpfad wird über einen internen Backend-Lookup mit Markierungen, Zonen und Flags bestimmt. Der Tunnel kann dadurch korrekt weiterleiten, obwohl das zugehörige VPN-Netz nicht als gewöhnliche Kernel-Route erscheint.

Das erklärt das scheinbar widersprüchliche Fehlerbild:

• Der IPsec-Tunnel ist aktiv.
• OSPF steht auf Full oder BGP auf Established.
• Direkter Traffic durch den Tunnel kann weiterhin funktionieren.
• Das entfernte VPN-Präfix wird aber nicht mehr aus der Kernel-Routingtabelle in OSPF oder BGP übernommen.

Die Änderung betrifft nicht OSPF oder BGP allgemein. Sie betrifft nur einen Aufbau, der policy-based IPsec-Routen als Kernel-Routen vorausgesetzt hat.

Vor dem Upgrade die Abhängigkeit erkennen

Eine bestehende Umgebung sollte vor dem Upgrade nicht nur auf einen grünen Tunnel geprüft werden. Entscheidend ist, woher OSPF oder BGP das anzukündigende Präfix erhält.

Als Beispiel dient das entfernte VPN-Netz 10.60.0.0/16. Es ist ein Umgebungswert und wird durch das tatsächlich angekündigte Netz ersetzt.

Firewall- und VPN-Zustand sichern

In 4. Device Console werden zuerst Route Precedence und manuelle IPsec-Routen dokumentiert:

system route_precedence show
system ipsec_route show

Die Ausgabe beantwortet zwei unterschiedliche Fragen: Route Precedence zeigt die globale Reihenfolge der Routingklassen. system ipsec_route show zeigt manuelle Zuordnungen zu policy-based Tunneln. Keiner der beiden Befehle beweist allein, dass OSPF oder BGP das Präfix tatsächlich ankündigt.

Auf SFOS 21.5 kann in der Advanced Shell zusätzlich festgehalten werden, ob das Beispielnetz in der für policy-based IPsec verwendeten Routingtabelle erscheint:

ip route show table 220 | grep '10.60.0.0/16'

Der Befehl ist lesend; das Suchpräfix wird an das echte Netz angepasst. Unter SFOS 22 ist ein fehlender Treffer für policy-based IPsec erwartbar und kein Beweis dafür, dass der Tunnel selbst defekt ist.

OSPF oder BGP getrennt dokumentieren

Im jeweiligen Routing-CLI wird die laufende Konfiguration gesichert. Für OSPF helfen zusätzlich diese lesenden Befehle:

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

Für BGP wird die Konfiguration zusammen mit den bekannten BGP-Präfixen dokumentiert:

show running-config
show ip bgp

Am empfangenden Router wird ebenfalls festgehalten, ob 10.60.0.0/16 gelernt wird und welcher Next Hop verwendet wird. Nur so lässt sich nach dem Upgrade erkennen, ob der Tunnel, die Routingnachbarschaft oder die Präfixankündigung betroffen ist.

Die vollständigen Prüfpfade erklären OSPF konfigurieren und prüfen und BGP konfigurieren und prüfen.

Das sichere Zieldesign wählen

Dynamisches Routing über ein XFRM-Interface

Wenn entfernte Netze dynamisch gelernt oder weiterverteilt werden sollen, ist route-based Any-to-Any-IPsec das nachvollziehbare Zieldesign:

1. Beide Tunnelenden verwenden Route-based (Tunnel interface) mit Any-to-Any-Subnetzen.
2. Die automatisch erzeugten XFRM-Interfaces erhalten eindeutige IP-Adressen aus einem eigenen Transitnetz.
3. OSPF oder BGP baut die Nachbarschaft über diese Transitadressen auf.
4. Die vorgesehenen Netze werden im Routingprotokoll explizit angekündigt oder über eine eng gefilterte, tatsächlich vorhandene Route redistribuiert.
5. Firewall-Regeln erlauben den Nutzdatenverkehr zwischen LAN- und VPN-Zone.

Damit ist die Route nicht mehr ein Nebenprodukt des policy-based Tunnels. XFRM, Routingprotokoll und angekündigte Präfixe lassen sich getrennt prüfen und ändern.

Die Umstellung wird in einem Wartungsfenster vorbereitet. Policy-based und route-based Verbindungen mit denselben Präfixen dürfen nicht unkontrolliert gleichzeitig aktiv sein, weil überlappende Selektoren und Routen den Test verfälschen können.

Policy-based IPsec vorerst behalten

Nicht jede bestehende Verbindung muss sofort migriert werden. Bleibt der Tunnel policy-based, benötigt die Präfixankündigung jedoch ein bewusst geplantes, topologiespezifisches Design. Die öffentlich dokumentierten SFOS-22-Verfahren enthalten keinen allgemeinen Ersatzbefehl, der Backend-VPN-Routen wieder als Kernel-Routen für OSPF oder BGP bereitstellt.

redistribute static ist nur dann sinnvoll, wenn die statische Route selbst der echte gewünschte Datenpfad ist und mit ACL beziehungsweise Route Map auf die vorgesehenen Präfixe begrenzt wird. Eine zusätzliche Route, die nur als Quelle für die Redistribution dient, ist kein sicherer Standardweg.

Auch eine Änderung von system route_precedence behebt die fehlende Kernel-Route nicht. Die Reihenfolge gilt global und kann andere statische, SD-WAN- und VPN-Pfade verändern. Falls sie wegen eines konkreten Routingkonflikts angepasst werden muss, erklärt Route Precedence sicher ändern die Prüfung und den Rückweg.

Umstellung und Betrieb abnehmen

Ein erfolgreicher Test besteht aus mehreren getrennten Ebenen:

1. Das XFRM-Interface ist aktiv und mit der vorgesehenen Transit-IP adressiert.
2. OSPF erreicht Full oder BGP Established.
3. Nur die vorgesehenen Präfixe werden angekündigt und auf der Gegenstelle gelernt.
4. Route Lookup und Routing Information zeigen für ein konkretes Ziel den geplanten Pfad.
5. Log Viewer und Packet Capture zeigen die erwartete Firewall-Regel sowie Ein- und Ausgangsinterface.
6. Ein echter Dienst funktioniert in beide Richtungen und verwendet den richtigen Rückweg.
7. Bei redundanten WAN-Verbindungen oder HA wird ein kontrollierter Failover separat getestet.

Route Lookup prüft den lokalen Weiterleitungspfad, aber nicht die Präfixankündigung an einen OSPF- oder BGP-Nachbarn. Ausschlaggebend sind deshalb Route Lookup, empfangenes Präfix, Routingnachbar, Paketfluss und realer Anwendungstest gemeinsam.

Fehler systematisch eingrenzen

Neighbor ist aufgebaut, aber das VPN-Präfix fehlt

Zuerst im show running-config prüfen, ob das Netz bisher nur über redistribute kernel in OSPF oder BGP gelangt ist. Danach Tunneltyp und SFOS-Build feststellen. Trifft policy-based IPsec unter SFOS 22 zu, ist der fehlende Kernel-Eingang die naheliegende Erklärung; der Neighbor muss dafür nicht ausfallen.

Das Präfix wird angekündigt, aber der Traffic funktioniert nicht

Dann ist die fehlende Kernel-Redistribution nicht mehr die unmittelbare Ursache. Route Lookup, Firewall-Regeln, NAT, Rückweg, XFRM-Adresse und Traffic Selector getrennt prüfen. Ein angekündigtes Präfix beweist nicht, dass der Forward- und Return-Pfad korrekt sind.

ipsec_route ist vorhanden, aber OSPF oder BGP übernimmt das Netz nicht

Das ist unter SFOS 22 erwartbar. system ipsec_route show zeigt die konfigurierte manuelle Tunnelzuordnung, bestätigt aber weder eine normale Kernel-Route noch einen funktionierenden Datenpfad. Eine weitere ipsec_route für dasselbe Netz stellt redistribute kernel deshalb nicht wieder her. Die genaue Einordnung und sichere Add-/Delete-Syntax stehen unter IPsec Route auf Sophos Firewall erstellen.

Nach einer statischen Ersatzroute fällt Traffic aus

Die neu angelegte Route kann den echten VPN-Pfad übersteuern. Die Änderung anhand des zuvor dokumentierten Befehls und Wartungsplans zurücknehmen, Route Precedence kontrollieren und den letzten funktionierenden Test wiederholen. Nicht gleichzeitig weitere Routing-, NAT- und VPN-Einstellungen ändern.

Sicher zurückrollen

Vor der Migration werden policy-based Verbindung, Routingkonfiguration, Route Precedence, Regeln und empfangene Präfixe gesichert. Beim Rollback wird nur der zuvor geänderte Pfad zurückgenommen:

• neue OSPF-/BGP-Ankündigungen und Filter kontrolliert entfernen,
• XFRM-Routen nur entfernen, wenn der alte Datenpfad wieder aktiv und geprüft ist,
• die ursprüngliche Route Precedence exakt wiederherstellen, falls sie geändert wurde,
• künstliche Hilfsrouten vollständig entfernen,
• Tunnel, Nachbarstatus, Präfixe und echten Traffic erneut prüfen.

Ein Rollback ist erst abgeschlossen, wenn der Managementzugang und die produktiven Verbindungen wieder über den dokumentierten Ausgangspfad funktionieren.

FAQ