SFOS 22: redistribute kernel no longer advertises IPsec routes

After an upgrade to SFOS 22, the IPsec tunnel may remain active and the OSPF or BGP neighbor may still appear healthy. Nevertheless, the networks behind a policy-based IPsec tunnel can suddenly disappear from the neighboring routers.

The usual trigger is redistribute kernel: Up to SFOS 21.5, the policy-based VPN routes used for this workflow could be imported from the kernel routing table. With SFOS 22.0 GA, the firewall processes these routes internally in the VPN backend. As a result, redistribute kernel can no longer find them.

⚠️ Do not create a static dummy, null, or blackhole route merely to make the prefix appear in OSPF or BGP again. Depending on Route Precedence, such a route can take over the data path itself and divert production traffic away from the tunnel or discard it.

Quick answer: What to do now

When a previously advertised VPN network is missing after the upgrade, first check whether all of the following apply:

1. The firewall was upgraded from SFOS 21.5 or earlier to SFOS 22.
2. The affected tunnel is policy-based.
3. OSPF or BGP previously imported the VPN networks through redistribute kernel.
4. The neighbor remains Full or Established, but the expected prefix is missing on the receiving side.

If so, a new ipsec_route entry is not the solution: Under SFOS 22, it does not create an ordinary kernel route either. For a design that remains easy to understand, use route-based Any-to-Any IPsec with addressed XFRM interfaces and an explicit OSPF or BGP configuration.

The SFOS 22 Upgrade Check helps with preparation. The actual tunnel configuration is described in Set up Site-to-Site IPsec VPN.

Why the route disappears after the upgrade

A kernel route is an entry in the operating system’s normal routing table. Routing services can import such entries as a source and, for example, advertise them to neighbors with redistribute kernel.

SFOS 22 handles policy-based IPsec differently: The packet path is determined by an internal backend lookup using marks, zones, and flags. The tunnel can therefore forward traffic correctly even though the associated VPN network does not appear as an ordinary kernel route.

This explains the seemingly contradictory symptoms:

• The IPsec tunnel is active.
• OSPF is Full or BGP is Established.
• Direct traffic through the tunnel may continue to work.
• However, the remote VPN prefix is no longer imported from the kernel routing table into OSPF or BGP.

The change does not affect OSPF or BGP in general. It only affects designs that relied on policy-based IPsec routes being available as kernel routes.

Identify the dependency before the upgrade

Before an upgrade, an existing environment should not be assessed solely by whether the tunnel is green. The decisive question is where OSPF or BGP obtains the prefix it advertises.

The remote VPN network 10.60.0.0/16 is used as an example. It is an environment-specific value and must be replaced with the network that is actually advertised.

Record the firewall and VPN state

First record Route Precedence and manual IPsec routes in 4. Device Console:

system route_precedence show
system ipsec_route show

The output answers two different questions: Route Precedence shows the global order of the routing classes. system ipsec_route show displays manual assignments to policy-based tunnels. Neither command alone proves that OSPF or BGP is actually advertising the prefix.

On SFOS 21.5, the Advanced Shell can additionally show whether the example network appears in the routing table used for policy-based IPsec:

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

The command is read-only; replace the search prefix with the actual network. Under SFOS 22, no match for policy-based IPsec is expected and does not prove that the tunnel itself is broken.

Record OSPF or BGP separately

Save the running configuration in the relevant routing CLI. For OSPF, these additional read-only commands are useful:

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

For BGP, record the configuration together with the known BGP prefixes:

show running-config
show ip bgp

On the receiving router, also record whether 10.60.0.0/16 is learned and which next hop is used. Only then can a post-upgrade comparison distinguish between the tunnel, the routing adjacency, and the prefix advertisement.

Configure and verify OSPF and Configure and verify BGP explain the complete validation paths.

Choose a safe target design

Dynamic routing through an XFRM interface

When remote networks must be learned or redistributed dynamically, route-based Any-to-Any IPsec is the transparent target design:

1. Both tunnel endpoints use Route-based (Tunnel interface) with Any-to-Any subnets.
2. The automatically created XFRM interfaces receive unique IP addresses from a dedicated transit network.
3. OSPF or BGP establishes the adjacency through these transit addresses.
4. The intended networks are advertised explicitly in the routing protocol or redistributed from a tightly filtered route that actually exists.
5. Firewall rules allow payload traffic between the LAN and VPN zones.

The route is then no longer a side effect of the policy-based tunnel. XFRM, the routing protocol, and the advertised prefixes can be checked and changed separately.

Prepare the migration in a maintenance window. Do not leave policy-based and route-based connections with the same prefixes active in an uncontrolled manner, because overlapping selectors and routes can distort the test.

Keep policy-based IPsec for now

Not every existing connection must be migrated immediately. If the tunnel remains policy-based, however, prefix advertisement requires a deliberately planned, topology-specific design. The publicly documented SFOS 22 procedures do not provide a general replacement command that exposes backend VPN routes as kernel routes to OSPF or BGP again.

redistribute static is appropriate only when the static route itself is the intended data path and an ACL or Route Map restricts the redistribution to the intended prefixes. An additional route that exists only as a redistribution source is not a safe standard approach.

Changing system route_precedence does not restore the missing kernel route either. The order is global and can change other static, SD-WAN, and VPN paths. If a specific routing conflict requires a change, Change Route Precedence safely explains the checks and rollback.

Validate the migration and operation

A successful test covers several separate layers:

1. The XFRM interface is active and addressed with the intended transit IP.
2. OSPF reaches Full or BGP reaches Established.
3. Only the intended prefixes are advertised and learned on the remote side.
4. Route Lookup and Routing Information show the planned path for a specific destination.
5. Log Viewer and Packet Capture show the expected firewall rule as well as the incoming and outgoing interfaces.
6. A real service works in both directions and uses the correct return path.
7. With redundant WAN connections or HA, test a controlled failover separately.

Route Lookup checks the local forwarding path, but not the prefix advertisement to an OSPF or BGP neighbor. Route Lookup, the received prefix, routing neighbor, packet flow, and a real application test must therefore be evaluated together.

Narrow down errors systematically

The neighbor is up, but the VPN prefix is missing

First check in show running-config whether the network previously reached OSPF or BGP only through redistribute kernel. Then identify the tunnel type and SFOS build. If policy-based IPsec under SFOS 22 applies, the missing kernel input is the likely explanation; the neighbor can remain up.

The prefix is advertised, but traffic does not work

In this case, missing kernel redistribution is no longer the immediate cause. Check Route Lookup, firewall rules, NAT, the return path, the XFRM address, and Traffic Selectors separately. An advertised prefix does not prove that the forward and return paths are correct.

ipsec_route exists, but OSPF or BGP does not import the network

This is expected under SFOS 22. system ipsec_route show displays the configured manual tunnel assignment, but confirms neither an ordinary kernel route nor a working data path. Another ipsec_route for the same network therefore does not restore redistribute kernel. Create an IPsec Route on Sophos Firewall explains the exact classification and safe add/delete syntax.

Traffic fails after adding a static replacement route

The newly added route may override the actual VPN path. Revert the change using the previously recorded command and maintenance plan, check Route Precedence, and repeat the last successful test. Do not change further routing, NAT, and VPN settings at the same time.

Roll back safely

Before migration, save the policy-based connection, routing configuration, Route Precedence, rules, and received prefixes. During rollback, revert only the path that was changed:

• remove new OSPF or BGP advertisements and filters in a controlled manner,
• remove XFRM routes only after the old data path is active and verified again,
• restore the original Route Precedence exactly if it was changed,
• remove artificial helper routes completely,
• recheck the tunnel, neighbor status, prefixes, and real traffic.

A rollback is complete only when management access and production connections work again through the documented original path.

FAQ