IPsec policy is swallowing your local traffic: how to tell

The printer on the desk stops answering the moment the tunnel comes up, and nothing in the tunnel configuration mentions the printer. What usually happened is that a protected range was written wide enough to include it, so the machine now tries to encrypt traffic that was supposed to stay on the local segment. Reading the installed policy explains the capture; narrowing it in the right place keeps the remote traffic protected. The walk from failing request to matching policy takes a few minutes.

Walk the flow before you change a selector

Start from the failing request and write down four values: the source address the machine uses, the exact destination, the route the kernel picks, and the policy that matches that pair.

Those four facts decide whether the capture is deliberate or accidental. A destination that falls inside the remote traffic selector is being protected by design, even if the design was wrong. A destination outside it that still gets captured means something else is matching, and changing the selector will not help. Both cases are common, and they are distinguished by one command.

Do this before editing anything, because the interesting case is the local subnet that overlaps a private range the connection protects. Familiar prefixes like 192.168.0.0/16 appear in many networks, and a selector written for one of them can quietly cover your own.

Three kinds of local that behave differently

A destination assigned to this host, a destination on the same link, and a destination behind another interface are three different cases. The kernel treats each one differently when it decides whether traffic needs protection.

Traffic generated by the gateway itself is not the same as traffic forwarded from a client, either. A policy that looks correct for forwarded traffic can capture the gateway's own management session, which is how an administrator loses access while fixing the tunnel.

The useful habit is to name the case out loud: is this packet from me, to my link, or through me? Each answer points at a different place to narrow. Writing the case down also stops the next person from redoing the same work.

When the protected range is an entire private space, all three cases can fall inside it at once, and the symptom becomes a machine that can reach nothing except the tunnel endpoint.

Read the installed policy, not the file

Configuration files describe intent; the kernel holds the policies that actually match. Print both, and treat a mismatch as the first finding.

These commands show the route chosen for the destination and the installed policies in each direction:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

The route tells you which interface the packet would use. The policy list tells you whether that packet then gets a template applied, and the connection listing shows which selectors the daemon believes it installed. If the destination appears in a remote selector, you have found the capture without guessing.

Narrow the selector or bypass the destination

There are two supported repairs and they answer different questions. Narrowing the selector says this connection only protects a smaller range, which is correct when the wider range was a mistake. Adding a bypass says this specific destination must never be protected, which is correct when the protected range genuinely is wide and one destination is an exception.

Choose the first when you can, because a smaller selector is easier to reason about and shows up in the connection definition. Choose the second when the wide range is intentional and the exception is a single host or subnet you can name.

Both belong in the configuration that owns the connection. A runtime rule added by hand disappears at the next reconnect, and the failure returns at a moment when nobody remembers the workaround.

Reinstall-safe exceptions

After the change, repeat the same harmless request and look at the same counters. The local destination should answer, and the intended remote destination should still show encrypted traffic.

These two checks confirm the exception survived and the protection did not:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Then disconnect and reconnect the tunnel deliberately, and repeat both. An exception that works before the reconnect and fails after it was applied to the wrong layer, which is the most common way this problem comes back.