What to record for a site-to-site VPN: selectors and scope

Six months after a tunnel went in, a new subnet stops matching the policy and the only document on the share says office VPN. That is the failure a selector record prevents, and it is specific: an address set changed while the paperwork did not. Writing the record correctly means knowing which of several address sets you are describing, and recording the one the peer actually enforces rather than the one you configured.

Configured is not negotiated

In a policy-based IPsec tunnel, each side proposes traffic selectors: source and destination ranges for the child association. The responder is allowed to narrow that proposal, so the installed association may cover less than the configuration lists. A record that copies the configuration therefore describes an intention, not the current protection scope. The two diverge quietly, and nothing in the tunnel status page points it out.

Keep both columns, with the date you observed them. The configured selector is what you meant; the negotiated one is what the kernel is enforcing right now. When they differ, that difference explains a surprising failure far more often than a routing bug does.

One association also does not represent every configured pair. A tunnel with several selector combinations can end up with several child associations, and a record that lists one of them is a partial inventory. Enumerate them instead of summarising them.

Route-based tunnels select differently

With a route-based interface, the routing table decides what enters the tunnel and the selectors can be deliberately broad. That is a legitimate design rather than sloppiness, and the record has to describe it as such. Write down the route, the interface it points at, and the firewall policy that limits which services are reachable. The protection scope is wide on purpose, and the service scope does the narrowing.

Copying a policy-based template onto a route-based tunnel produces a document that describes a mechanism the deployment does not use. The next engineer then looks for selectors that were never meant to be there, and concludes the tunnel is misconfigured when it is only documented badly.

Translation belongs in the same table

When NAT presents a different range to the peer, record the original and the translated prefixes together. Note the stage at which selectors and access rules match them, because the order decides whether the far side ever sees the address you wrote down. A table with only one of the two ranges is worse than no table, since it looks complete.

This is the detail that breaks a working tunnel after a NAT change: the selector still matches the original prefix, the peer now receives a translated one, and its return route points at an address that no longer exists. Nothing logs an error at the moment the two stop agreeing.

Private DNS belongs in the same place. A name that resolves to an address unusable from the relevant site is a documentation error with a support ticket attached, and it will be blamed on the tunnel.

Attach the service requirement

A protected range is not a permission list. Write down which services are supposed to be reachable from which source, and who owns the application behind them. Those two fields answer different questions, and conflating them is how a security review ends up arguing about routing instead of access.

Then name the network administrator who maintains the rule. A selector inventory without an owner goes stale silently, and stale is indistinguishable from wrong when the tunnel breaks at two in the morning. The owner is also the person who can confirm a change was deliberate.

Turn the record into a test plan

For each required path, choose a representative source and destination host and note the expected route, service and reply gateway. That turns the document into a test plan rather than a description. Read the live association back with the command below, and compare it with the negotiated row you wrote down.

swanctl --list-sas

A five-line skeleton is usually enough to keep the record honest. The version below fits in a change ticket without truncation:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

A gateway-only ping is not the acceptance test. It never exercises the transit path, so it can pass while every forwarded flow fails. Test from a host on one side to a service on the other and confirm the reply arrives through the tunnel. If only the ping passes, the record has just found the forwarding problem it was written to prevent. The strongSwan forwarding documentation explains how selectors, routes and forwarding interact on a Linux peer.