Add a Second Subnet to a Site-to-Site VPN: Two Paths
Policy-based tunnels need matching selectors on both peers; route-based ones need a route. Pick the right path and fix the return route first.
Adding a second subnet to a working site-to-site tunnel takes five minutes on one design and most of an afternoon on the other. When the tunnel installs routes for the prefixes you name, you add a route and traffic follows it. When it negotiates one fixed selector pair, the new prefix stays unprotected until both peers agree on a matching pair. Three things decide which case you are in: what each peer's configuration actually describes, whether the negotiated traffic is narrowed to the smallest matching pair, and who owns the return path for the new range.
Read the kernel, not the status label
A tunnel that reports connected has installed at least one child association, not necessarily the one you think. On Linux the kernel shows what gets applied: ip xfrm policy lists the selector pairs, and swanctl --list-sas (or the older ipsec statusall) shows what the peers negotiated, including the traffic selectors in each direction. If the new prefix appears in neither, it is unprotected no matter what the configuration file says.
Compare that with the route table. On a route-based setup the tunnel device is the next hop for the protected prefixes. A policy-based setup often has no specific route for the remote subnet, only the default route, because the policy selects traffic rather than the table.
Policy-based tunnels: both peers must list the new prefix
In strongSwan terms the selector lives in local_ts and remote_ts under the child configuration, the successors to leftsubnet and rightsubnet. A new prefix has to appear on both peers, mirrored: what site A calls local, site B calls remote. A mismatch rarely produces a clean error. The peers narrow to the intersection, so the old prefix keeps working and only the new one silently fails.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyOn pfSense or OPNsense, that means a second Phase 2 entry pairing the new local subnet with the new remote subnet, then an apply. Keep the old entry; replacing it moves the original subnet instead of adding to it. If an existing Phase 2 already covers a supernet such as 0.0.0.0/0 or a summarized range, do not add a narrower entry beside it: overlapping selectors install competing policies, and evaluation order decides which one wins.
IKEv1 makes each subnet pair its own Phase 2, and a peer that takes one pair per exchange drops the rest. IKEv2 can carry several selector pairs in one child, but only if both implementations accept them. The list from swanctl --list-sas is the ground truth; what you typed is a request.
Route-based tunnels: the route is the policy
An XFRM interface or a VTI device carries traffic according to the routing table. You point the new prefix at the device on both sites, and the state bound to the interface's transform applies. There is no selector pair to keep in sync, which is why this design scales better as subnets multiply. The strongSwan forwarding guide goes through the kernel side of that in more detail.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard takes the same idea further. AllowedIPs is simultaneously the crypto allowlist and, through wg-quick, the route table entry. Add the prefix on one peer only and you get a handshake, outbound packets, and silence, because the far side drops packets whose source is not in its allowlist. The wg set form replaces the whole list, so restate the prefixes that already worked or you will cut them off:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0That second command is not optional when you used wg set instead of wg-quick. The kernel accepts the new allowlist immediately, but nothing adds a route for it, so locally generated traffic still leaves through the default gateway. It is the most common reason a new WireGuard subnet works from the tunnel host and not from a laptop.
The return path fails more often than the tunnel
Hosts on the new remote subnet have to send replies back through the VPN gateway. When that gateway is not their default router, the reply goes to the LAN router, which either drops it or forwards it to the internet with a private source address. Test from a host on the far side rather than from the gateway: ip route get 10.30.20.15 on Linux or Find-NetRoute -RemoteIPAddress 10.30.20.15 in PowerShell shows the next hop the host will really use. If the answer is not the tunnel endpoint, add a static route for the new prefix there.
Source NAT on the site that lacks the return route is a legitimate alternative and how many hub-and-spoke deployments avoid touching every server. Apply it to the new prefix on the destination-side gateway as well:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEThe cost is real. Remote logs stop showing individual source addresses, and firewall rules keyed on the original subnet collapse into one rule for the gateway. Choose that deliberately rather than because a route was missing.
Firewalls are the other half of the return path. Zone-based devices do not extend an existing tunnel interface's zone to a new subnet automatically, and a rule written against the old prefix will not match. Add the new subnet to the zone or the rule pair in both directions before you blame IPsec.
Decide in three questions, then verify with traffic
The quick version: does the peer configuration name prefixes (policy-based), or does traffic route into an interface (route-based)? Do both ends list the new prefix? Is there a path back from the new subnet to the original source range?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Verification is where most changes get closed too early. A ping from the gateway proves little, because the gateway sources from itself and often matches a different policy than a host does. Ping from a host on the new subnet, then run the application that motivated the change, and watch counters rather than a status icon.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showOn a policy-based tunnel the ip xfrm state counters should rise in both directions; flat counters mean the packet is routed but not selected. On WireGuard, wg show reports transfer per peer, and a handshake with zero received bytes points at the far side's allowlist or its return route.
Finish by recording the prefix, the peer-side selector or route, the return-path decision, and the firewall entry with the rest of the tunnel inventory. Then reboot one gateway and test again: a route added by hand disappears, and the next person should not have to rediscover that.