IPsec Traffic Selectors: What They Cover and What They Do Not

Traffic selectors name the inner traffic an IPsec agreement protects, and the pair is negotiated rather than assumed. Two endpoints can authenticate each other perfectly and still disagree about which packets belong inside the tunnel. That disagreement is invisible in the connection status, which usually reports a healthy tunnel. Reading the selectors from both ends, then chasing one destination, finds it faster than any amount of policy editing.

Read Them From Both Ends

Each endpoint describes its own side as local and the other side as remote. The same pair of prefixes therefore appears swapped in the two configurations, and that is correct rather than contradictory. Reversing the perspective is the first thing to do when a working agreement looks wrong on paper. Comparing two files side by side without swapping them produces a mismatch that does not exist.

The values are not always single subnets. IKEv2 selectors can carry address ranges, protocol numbers and port ranges, which is how a policy protects one service instead of a whole network. A selector narrower than the intended traffic produces a tunnel that carries some destinations and silently excludes others.

Write both sides into one table before changing anything. The exercise usually settles the question without touching a configuration file.

Narrowing Is the Responder's Call

An initiator proposes, and the responder may accept only a subset. IKEv2 allows the responder to narrow the offered traffic selectors, and the narrowed result is what actually gets installed. Reading the initiating configuration therefore describes an offer, not the agreement.

That is why a subnet added to the client can produce a working tunnel that still refuses the new destination. The server narrowed the offer back to what its policy allows, while the client's file still lists the wider range. Only the negotiated state shows the truth: on Linux, ip xfrm policy and the child SA listing in strongSwan's IKEv2 documentation report what was installed rather than what was requested. When the two disagree, the responder's policy is the one to change.

A rejected proposal is a different symptom from a narrowed one. Rejection appears in the negotiation log and leaves no child association at all.

Follow One Destination End to End

Pick a real destination plus the source address the client would use for it, then follow that pair through three independent decisions. The route chooses a path, the selector decides whether that path is protected, and the firewall decides whether the packet is allowed. Each can fail on its own, and a broad selector repairs none of the others.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

The route query names the interface and source address that would carry the packet. The policy listing shows whether a matching tunnel policy exists for that pair, including its direction and level. The SA listing shows the negotiated child selectors along with counters, so a child association with zero packets after traffic was attempted is the signature of selectors that exclude what is being sent. Three commands, three different answers, and only one of them explains a silent drop.

If the child counters move while the application still fails, the problem sits beyond the tunnel. That moves the investigation to the far host's listener or firewall rather than to the selectors.

Keep the Two Goals Separate

Protecting an office subnet and sending all browsing through a remote exit are different requirements with different selectors. A profile built for one rarely suits the other, and mixing them produces either a leak or a broken split. Broadening the protected range means changing both endpoints and their forwarding policy, because a one-sided change becomes a rejected proposal. That is the most common way a working tunnel stops working after a small edit.

Selectors describe cryptographic coverage, routes choose paths, and applications enforce their own permissions. A tunnel that covers everything still cannot reach a service bound to loopback, and a route into the tunnel still needs a selector including the destination. Check all three against the same test request, and the disagreement names itself.