SFOS 22: Policy-based IPsec routes in OSPF and BGP

After an upgrade to SFOS 22, a policy-based IPsec tunnel can continue to work while a VPN prefix previously advertised through OSPF or BGP is missing. The routing adjacency may also remain Full or Established.

Sophos documents that SFOS 22 no longer creates the former VPN routes for policy-based IPsec and no longer uses ipsec0 in the transmit path. If an OSPF or BGP prefix disappears at the same time, treat the connection to redistribution as an observed operational inference: the KBA does not describe redistribute kernel, OSPF, or BGP. A missing prefix therefore does not automatically mean that the tunnel has failed.

⚠️ Do not create a dummy, null, blackhole, or other helper route solely for advertisement. It can alter the data path. Before changing production, clarify the specific design with Sophos Support or in a planned design and maintenance window.

Quick diagnosis

Investigate this SFOS 22 upgrade pattern when all points apply:

1. The problem began with the upgrade to SFOS 22.
2. The tunnel is policy-based.
3. OSPF or BGP previously used redistribute kernel for the VPN prefix.
4. Tunnel and neighbor are up, but the receiving router lacks the prefix.

For a route-based tunnel or a failed adjacency, investigate the corresponding tunnel or routing fault instead.

Why ordinary routing views are not enough

The KBA states that SFOS 22 no longer creates the former policy-based VPN routes. It separately describes ipsec_route routes as belonging to the vpn precedence class in SFOS 22 and not appearing in the routing table. It does not state how OSPF or BGP redistribution handles either case.

Assess three states separately:

• VPN: Is the IPsec connection active, and does traffic flow?
• Routing protocol: Is the OSPF or BGP neighbor up?
• Advertisement: Does the remote router learn the exact expected prefix?

A green VPN does not prove route advertisement. Conversely, a missing route in the ordinary routing view does not prove a broken policy-based tunnel in SFOS 22.

Identify the VPN flow in conntrack output

SFOS 22 no longer uses ipsec0 in the transmit path and does not create the former VPN routes. For the specific connection being tested, use the conntrack values instead: traffic towards the VPN has mark=0x0, outzone=5, and flag 74; traffic from the VPN has mark=0x0, inzone=5, and flag 75. Zone 5 is the VPN zone, and the flag can appear among other values in flagvalues.

These values identify the direction of an observed VPN connection; they do not prove OSPF or BGP advertisement. In SFOS 22, it is also expected that Packet Capture does not show ipsec0 on the transmit path and that Diagnostics > Tools Route Lookup can show the WAN interface. Correlate a narrowly scoped test flow in conntrack and Packet Capture rather than treating either display alone as a fault.

Check safely and read-only

Record firewall and VPN details

1. Record the SFOS version and build.
2. Under Site-to-site VPN > IPsec, record connection status, tunnel type, and configured local and remote subnets.
3. Under Routing > Routing information, run Route Lookup for a specific destination while accounting for the display limitation for policy-based VPN and ipsec_route routes.
4. In 4. Device Console, display the documented configuration:

system route_precedence show
system ipsec_route show

These commands make no changes. Route Precedence shows the global order of route classes; system ipsec_route show lists manual IPsec routes. Neither command alone proves that OSPF or BGP advertises a prefix.

With read-only access to Advanced Shell, capture the route and connection views used by the KBA:

route -n
ip route show
conntrack -L

Scope the conntrack review to the test endpoints and time window. These outputs can confirm that the old route or ipsec0 is absent and identify the tested VPN flow; they do not prove redistribution or advertisement.

Check ipsec_route precedence before changing it

In SFOS 21.5, a route added with ipsec_route belonged to the static class; in SFOS 22 it belongs to the vpn class. With static sdwan_policyroute vpn, an SD-WAN policy route that matches the VPN selectors can therefore capture the traffic after the upgrade. If the reviewed design requires VPN to win, Sophos documents static vpn sdwan_policyroute as the target order and system route_precedence set static vpn sdwan_policyroute as the changing command.

Do not apply that command from this diagnosis alone: Route Precedence is global and can affect unrelated traffic. Record system route_precedence show, matching SD-WAN policies, forward and return paths, and a rollback point first. Then use Change Route Precedence safely for the prechecks, controlled change, validation, and rollback.

Check OSPF or BGP separately

Use the Sophos-documented display commands in the appropriate routing CLI:

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

Run only the commands for the protocol in use. Also record the prefix and next hop on the receiving router. See Configure and verify OSPF and Configure and verify BGP for the complete checks.

Make the design decision

Dynamic routing is required

For dynamic routing, Sophos documents route-based Any-to-Any IPsec. It creates XFRM interfaces that can be addressed and used for OSPF or BGP. The adjacency and advertised prefixes then become explicit design elements rather than side effects of a policy-based VPN route.

This is a design direction, not a universal migration procedure. Addressing, routing filters, firewall rules, NAT, return path, redundancy, and the peer depend on the topology. Plan the change with Sophos Support or in a design and maintenance window before touching production. Tunnel fundamentals are covered in Set up Site-to-Site IPsec VPN.

Policy-based IPsec must remain

The KBA does not document OSPF or BGP redistribution, nor a command that makes the former VPN route available to either protocol. Another ipsec_route, a Route Precedence change, or an artificial static route is not a substitute for a reviewed routing design.

If policy-based IPsec must remain, design the advertisement path for the topology with Sophos Support. The SFOS 22 Upgrade Check and Create an IPsec Route on Sophos Firewall provide useful context.

Before a production change

Provide at least this information for a support or design session:

• SFOS version and build, tunnel type, and HA status;
• anonymized local and remote prefixes;
• previous OSPF or BGP configuration and neighbor state;
• expected and received prefixes with their next hops;
• relevant Route Lookup, Log Viewer, and Packet Capture results;
• return-path, NAT, failover, and maintenance-window requirements.

Do not change VPN, routing, NAT, and firewall rules simultaneously without defined test and restore points. After design approval, verify each planned layer separately: tunnel/XFRM, neighbor, advertised prefixes, forward and return paths, and a real service.

Distinguish the symptoms

Neighbor up, prefix missing

Compare tunnel type, SFOS build, and show running-config. The missing former VPN route, an active adjacency, and a missing received prefix are separate observations. Whether redistribution depended on that route must be verified from the routing configuration and the receiving router.

Prefix present, traffic impaired

Missing redistribution is then not the immediate cause. Investigate Route Lookup, rules, NAT, and the return path separately.

ipsec_route present, prefix missing

system ipsec_route show confirms only the manual assignment. It confirms neither an ordinary kernel route nor an OSPF or BGP advertisement.

No universal rollback sequence

Without the specific topology, there is no safe sequence for coexistence, cutover, withdrawal, or failover. Those steps belong in the change plan agreed with Sophos Support; this article deliberately provides no command sequence for them.

FAQ