SFOS 22: policy-based IPsec-routes in OSPF en BGP

Na een upgrade naar SFOS 22 kan een policy-based IPsec-tunnel blijven werken terwijl een VPN-prefix ontbreekt dat eerder via OSPF of BGP werd aangekondigd. Ook de routingadjacency kan Full of Established blijven.

Sophos documenteert dat SFOS 22 de voormalige VPN-routes voor policy-based IPsec niet meer aanmaakt en ipsec0 niet meer in het verzendpad gebruikt. Als tegelijk een OSPF- of BGP-prefix verdwijnt, behandel het verband met redistributie dan als een waargenomen operationele gevolgtrekking: de KBA beschrijft redistribute kernel, OSPF en BGP niet. Een ontbrekend prefix betekent daarom niet automatisch dat de tunnel is uitgevallen.

⚠️ Maak geen dummy-, null-, blackhole- of andere hulproute aan die uitsluitend voor de aankondiging dient. Die kan het datapad wijzigen. Stem vóór een productiewijziging het concrete ontwerp af met Sophos Support of in een gepland ontwerp- en onderhoudsvenster.

Snelle diagnose

Onderzoek dit SFOS 22-upgradepatroon wanneer alle punten van toepassing zijn:

1. Het probleem begon met de upgrade naar SFOS 22.
2. De tunnel is policy-based.
3. OSPF of BGP gebruikte eerder redistribute kernel voor het VPN-prefix.
4. Tunnel en neighbor zijn actief, maar het prefix ontbreekt op de ontvangende router.

Onderzoek bij een route-based tunnel of een uitgevallen adjacency in plaats daarvan de betreffende tunnel- of routingstoring.

Waarom gewone routingweergaven niet voldoende zijn

De KBA stelt dat SFOS 22 de voormalige policy-based VPN-routes niet meer aanmaakt. Daarnaast beschrijft ze ipsec_route-routes als onderdeel van de precedence-klasse vpn in SFOS 22 en als afwezig in de routingtabel. Ze vermeldt niet hoe OSPF- of BGP-redistributie een van beide gevallen verwerkt.

Beoordeel drie toestanden afzonderlijk:

• VPN: Is de IPsec-verbinding actief en stroomt er verkeer?
• Routingprotocol: Is de OSPF- of BGP-neighbor actief?
• Aankondiging: Leert de externe router exact het verwachte prefix?

Een groene VPN bewijst geen routeaankondiging. Omgekeerd bewijst een ontbrekende route in de gewone routingweergave onder SFOS 22 niet dat een policy-based tunnel defect is.

De VPN-verkeersstroom in conntrack-uitvoer herkennen

SFOS 22 gebruikt ipsec0 niet meer in het verzendpad en maakt de vroegere VPN-routes niet meer aan. Gebruik voor de specifiek geteste verbinding in plaats daarvan de conntrack-waarden: verkeer naar de VPN heeft mark=0x0, outzone=5 en flag 74; verkeer vanuit de VPN heeft mark=0x0, inzone=5 en flag 75. Zone 5 is de VPN-zone en de flag kan tussen andere waarden in flagvalues staan.

Deze waarden identificeren de richting van een waargenomen VPN-verbinding, maar bewijzen geen OSPF- of BGP-aankondiging. In SFOS 22 is het ook normaal dat Packet Capture geen ipsec0 in het verzendpad toont en dat Route Lookup onder Diagnostics > Tools de WAN-interface kan tonen. Correleer een nauw afgebakende teststroom in conntrack en Packet Capture in plaats van één weergave op zichzelf als storing te beschouwen.

Veilig en alleen-lezen controleren

Firewall- en VPN-gegevens vastleggen

1. Leg de SFOS-versie en build vast.
2. Leg onder Site-to-site VPN > IPsec de verbindingsstatus, het tunneltype en de geconfigureerde lokale en externe subnetten vast.
3. Voer onder Routing > Routing information Route Lookup uit voor een concrete bestemming en houd rekening met de weergavebeperking voor policy-based VPN- en ipsec_route-routes.
4. Toon in 4. Device Console de gedocumenteerde configuratie:

system route_precedence show
system ipsec_route show

Deze opdrachten brengen geen wijzigingen aan. Route Precedence toont de globale volgorde van routeklassen; system ipsec_route show toont handmatige IPsec-routes. Geen van beide opdrachten bewijst op zichzelf dat OSPF of BGP een prefix aankondigt.

Leg met alleen-lezen toegang tot de Advanced Shell ook de route- en verbindingsweergaven vast die de KBA gebruikt:

route -n
ip route show
conntrack -L

Beperk de conntrack-controle tot de test-eindpunten en het tijdvenster. Deze uitvoer kan bevestigen dat de oude route of ipsec0 ontbreekt en de geteste VPN-flow identificeren; ze bewijst geen redistributie of aankondiging.

De prioriteit van ipsec_route vóór een wijziging controleren

In SFOS 21.5 behoorde een met ipsec_route toegevoegde route tot de klasse static; in SFOS 22 behoort deze tot de klasse vpn. Met static sdwan_policyroute vpn kan een SD-WAN-policyroute die overeenkomt met de VPN-selectors het verkeer na de upgrade daarom overnemen. Als het beoordeelde ontwerp vereist dat VPN voorrang krijgt, documenteert Sophos static vpn sdwan_policyroute als doelvolgorde en system route_precedence set static vpn sdwan_policyroute als de wijzigingsopdracht.

Voer die opdracht niet alleen op basis van deze diagnose uit: Route Precedence is globaal en kan ander verkeer beïnvloeden. Leg eerst system route_precedence show, overeenkomende SD-WAN-policies, heen- en retourpaden en een rollbackpunt vast. Gebruik vervolgens Route Precedence veilig wijzigen voor de voorafgaande controles, gecontroleerde wijziging, validatie en rollback.

OSPF of BGP afzonderlijk controleren

Gebruik de door Sophos gedocumenteerde weergaveopdrachten in de juiste routing-CLI:

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

Voer alleen de opdrachten uit voor het gebruikte protocol. Leg ook het prefix en de Next Hop op de ontvangende router vast. Zie OSPF configureren en controleren en BGP configureren en controleren voor de volledige controles.

De ontwerpbeslissing nemen

Dynamische routing is vereist

Voor dynamische routing documenteert Sophos route-based Any-to-Any-IPsec. Hierbij ontstaan XFRM-interfaces die kunnen worden geadresseerd en voor OSPF of BGP kunnen worden gebruikt. De adjacency en aangekondigde prefixen zijn dan expliciete ontwerpelementen in plaats van neveneffecten van een policy-based VPN-route.

Dit is een ontwerprichting, geen universele migratieprocedure. Adressering, routingfilters, firewallregels, NAT, retourpad, redundantie en de peer zijn afhankelijk van de topologie. Plan de wijziging met Sophos Support of in een ontwerp- en onderhoudsvenster voordat productie wordt aangepast. De basisbeginselen van de tunnel staan in Site-to-Site IPsec VPN instellen.

Policy-based IPsec moet behouden blijven

De KBA documenteert geen OSPF- of BGP-redistributie en evenmin een opdracht die de voormalige VPN-route voor een van beide protocollen beschikbaar maakt. Een extra ipsec_route, een wijziging van Route Precedence of een kunstmatige statische route vervangt geen beoordeeld routingontwerp.

Als policy-based IPsec moet blijven, ontwerp dan samen met Sophos Support het topologiespecifieke aankondigingspad. De SFOS 22-upgradecheck en IPsec-route aanmaken op Sophos Firewall bieden nuttige context.

Vóór een productiewijziging

Lever voor een support- of ontwerpsessie ten minste deze gegevens aan:

• SFOS-versie en build, tunneltype en HA-status;
• geanonimiseerde lokale en externe prefixen;
• eerdere OSPF- of BGP-configuratie en neighborstatus;
• verwachte en ontvangen prefixen met hun Next Hops;
• relevante resultaten van Route Lookup, Log Viewer en Packet Capture;
• eisen voor retourpad, NAT, failover en onderhoudsvenster.

Wijzig VPN, routing, NAT en firewallregels niet tegelijk zonder vastgelegde test- en herstelpunten. Controleer na goedkeuring van het ontwerp elke geplande laag afzonderlijk: tunnel/XFRM, neighbor, aangekondigde prefixen, heen- en retourpad en een echte dienst.

Symptomen onderscheiden

Neighbor actief, prefix ontbreekt

Vergelijk tunneltype, SFOS-build en show running-config. De ontbrekende voormalige VPN-route, een actieve adjacency en een niet ontvangen prefix zijn afzonderlijke waarnemingen. Controleer in de routingconfiguratie en op de ontvangende router of de redistributie van die route afhankelijk was.

Prefix aanwezig, verkeer verstoord

De ontbrekende redistributie is dan niet de directe oorzaak. Onderzoek Route Lookup, regels, NAT en het retourpad afzonderlijk.

ipsec_route aanwezig, prefix ontbreekt

system ipsec_route show bevestigt alleen de handmatige toewijzing. Het bevestigt noch een gewone kernelroute, noch een OSPF- of BGP-aankondiging.

Geen universele rollbackvolgorde

Zonder de concrete topologie bestaat geen veilige volgorde voor co-existentie, omschakeling, intrekking of failover. Die stappen horen in het met Sophos Support afgestemde wijzigingsplan; dit artikel geeft bewust geen opdrachtenreeks.

FAQ