Sophos Site-to-Site VPN Up but No Traffic: License or Route?

Establishing an IPsec association, seeing the route in the table, and still timing out from the branch is a familiar Sophos Firewall combination. On Sophos Firewall that combination has at least two ordinary explanations: a forwarding gap, or a Base license condition that leaves the tunnel up while data stops passing. They produce nearly identical symptoms, so the only way through is to collect independent evidence for each. Both are common enough that neither can be assumed.

A tunnel can be up with no data

An IPsec association is a security relationship, not a promise to forward packets. Phase 1 and phase 2 can complete while the policy that selects traffic, the route to the remote prefix, or the data path itself is wrong. The tunnel display answers one question and leaves the others open.

Start by naming which prefixes should cross and in which direction. A tunnel with no interesting traffic looks the same as a broken tunnel on a status page.

What the Base license covers

Sophos lists VPN under the Base License, separate from Network Protection and Central Orchestration. An expired optional module is therefore its own problem and not automatically evidence that site-to-site IPsec needs a new paid bundle. Record the appliance model, release, registration identity and Base Firewall status. Then reconcile that with the account owner's records through the supported licensing process, and keep serial numbers out of public notes.

The platform changes the rule too. Cloud, virtual and software appliances get a Base license with no expiry date, whereas a hardware unit's Base license runs out at end of life. A suspended registration is a third state between valid and expired, and it deserves the same evidence rather than a guess.

Prove the route before blaming the license

Prove the forwarding path independently. Ask the appliance which route it would use for the remote prefix, then confirm the security policy selects that traffic and the reply path exists on the other side. A missing remote-prefix route stays a routing problem no matter how healthy the license is.

ip route get 10.80.20.10

The reverse direction matters as much as the forward one. A branch that can reach headquarters but not the reverse has a return route or policy gap, not a data-path failure. Capture one permitted flow in both directions before drawing conclusions.

Keep two records so the next fix is honest

Keep two separate records and date them. The first covers entitlement: what the licensing page showed, which subscription applied and when it was synchronized. The second covers forwarding: prefixes, routes, security associations and directional counters for one flow. When the symptom changes after a fix, the records show which explanation was actually correct.

ipsec status

That discipline matters because a license repair and a route repair look identical from a successful ping. If both were changed at once, you have learned that the service works and nothing about why it did not. Change one thing, then re-measure that same flow, and the expiry guide settles what the entitlement alone can explain.