VPN routing failures — when the tunnel is up but traffic does not reach the remote subnet · OPNsense

A VPN tunnel that is established but does not carry traffic is, by volume, the most common VPN failure mode. Phase 1 is up. Phase 2 SAs are ESTABLISHED. The byte counters in swanctl --list-sas are at zero. Or they tick upward on one side and never on the other. The cause sits in routing — the firewall’s table does not send traffic through the tunnel, or sends it the wrong way. This lesson covers the recurring routing failures for IPsec (route-based and policy-based) and WireGuard, the asymmetric-routing cases that arise in multi-WAN estates, and the diagnostic workflow that walks from the routing table to the live packet stream.

The routing failure landscape

Three routing failure modes dominate:

Failure	IPsec route-based	IPsec policy-based	WireGuard
Tunnel is up, but traffic does not leave	Route through the VTI is missing	Phase 2 traffic selector misses the subnet	AllowedIPs on the peer does not include the subnet
Tunnel is up, traffic leaves but never returns	Remote side has no return route	Remote side has no Phase 2 selector for our subnet	Remote side’s AllowedIPs on the local peer is wrong
Tunnel is up, traffic flows both ways but only for some subnets	A second route is missing for additional subnets	A second Phase 2 selector is missing	AllowedIPs on the right peer covers the subnet

The pattern in each case is “the tunnel is right but the routing is wrong”. The diagnostic finds the missing or misconfigured routing entry.

IPsec route-based: VTI not in the route lookup

A VTI is enabled, Phase 2 is ESTABLISHED, byte counters are zero. The diagnostic:

Read-only / Saferoute lookup via WAN— The route to the remote subnet (10.1.0.0/24) returns the WAN interface (igb1) and the WAN gateway. The remote subnet is being routed through the WAN, not the VTI — the encapsulated packets are not being generated. The fix is to add a static route under System → Routes → Configuration pointing 10.1.0.0/24 at the VTI's gateway.

$ route -n get 10.1.0.50

route to: 10.1.0.50
destination: 10.1.0.0/24
interface: igb1
gateway: 198.51.100.1
     fib: 0
flags: <UP,DONE>
recvpipe  sendpipe  ssthresh  rtt,msec  mtu  1500

Illustrative output

route -n get 10.1.0.50 showing interface: igb1 (the WAN) instead of interface: ipsec0 (the VTI) is the failure pattern. The remote subnet is being routed through the WAN, so packets leave unencrypted, hit the peer’s WAN IP, the peer’s strongSwan does not understand them as ESP, the peer drops them silently.

The fix: under System → Routes → Configuration, add a static route for 10.1.0.0/24 with the gateway being the peer IP on the VTI (typically 10.10.10.2). After the route is added, route -n get 10.1.0.50 should return interface: ipsec0. Once this is in place, packets from the LAN destined for the remote subnet are routed through the VTI, encapsulated as ESP, and tunnel through.

IPsec route-based: VTI not assigned to an interface

A subtler failure mode: the Phase 2 entry has “Install Virtual Tunnel Interface” enabled, but the VTI has not been assigned to an interface under Interfaces → Assignments. The VTI exists in the kernel (ifconfig ipsec0 shows it) but it has no IP configuration and is not a routeable interface as far as PF is concerned.

The diagnostic:

ifconfig ipsec0
> ipsec0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1400

The UP flag is missing; the interface is administratively down. Either Phase 2 is not ESTABLISHED (Layer 1 problem — go back to negotiation), or the VTI was enabled but not brought up. The fix: assign the VTI under Interfaces → Assignments, configure an IP, and ensure the corresponding ifconfig ipsec0 shows UP,RUNNING.

IPsec route-based: traffic leaves but doesn’t return

A VTI route exists on the local side. Packets from the LAN leave, get encapsulated, arrive at the remote side. But the remote side’s response never arrives back on the local side. The symmetric-routing signature:

swanctl --list-sas --no-headers shows byte counters increasing on the local outbound side and at zero on the local inbound side.
tcpdump -ni wan0 shows ESP packets leaving the local firewall (matching the outbound byte counter).
tcpdump -ni wan0 shows no ESP packets arriving at the local firewall.

The cause: the remote side does not know to send traffic back through the tunnel. The remote’s routing table does not include a route to the local LAN subnet via the VTI on the remote. Packets leaving the remote have a destination address in the local subnet, but the remote’s routing table routes them through its WAN (unencrypted, sent to the local firewall’s WAN IP), the local firewall’s IPsec daemon does not know what to do with them, PF drops them as no-state.

The fix is on the remote side: add a static route for the local subnet (10.0.0.0/24) with the VTI as gateway.

IPsec policy-based: Phase 2 selector misses

A policy-based tunnel does not use routes — it uses Phase 2 traffic selectors. A common failure pattern: traffic from 10.0.50.0/24 (a LAN subnet) should cross a policy-based tunnel to 10.1.0.0/24, but the Phase 2 selector only covers 10.0.0.0/24 (the LAN). The packets do not match any Phase 2 SA, and they fall through to whatever the firewall does with non-matching traffic (typically send through the WAN, where the remote does not understand them).

The diagnostic:

swanctl --list-sas --list-conns
> home-edge: ...
>   child home-edge-1, rekey_time: ...
>     local-ts: 10.0.0.0/24
>     remote-ts: 10.1.0.0/24

The local-ts is 10.0.0.0/24. Traffic from 10.0.50.10 does not match (the source 10.0.50.10 is in 10.0.50.0/24, not 10.0.0.0/24). The selector has to be widened to 10.0.0.0/16, or a second Phase 2 entry has to be added for 10.0.50.0/24.

The fix: edit the Phase 2 entry’s Local subnet, or add an additional Phase 2 entry for the missing subnet. Either way, re-trigger the negotiation (configctl ipsec reload) and confirm the SA’s traffic selector covers the new subnet.

WireGuard: AllowedIPs is the routing

WireGuard’s AllowedIPs is the routing table. A peer with allowed ips: 10.1.0.0/24 only carries traffic to 10.1.0.0/24. An operator who adds a new subnet 10.2.0.0/24 and expects it to flow through the existing tunnel gets zero transfer bytes and zero routing.

Read-only / Safewg show missing subnet— The peer's AllowedIPs lists only 10.1.0.0/24. A new subnet 10.2.0.0/24 cannot cross this tunnel. The fix: edit the peer configuration to add 10.2.0.0/24 to AllowedIPs (both ends — local and remote), then `wg sync` or restart the WireGuard service for the change to take effect.

$ wg show wg0

interface: wg0
public key: <local-server-public-key>
listening port: 51820

peer: <remote-peer-public-key>
endpoint: 198.51.100.2:51820
allowed ips: 10.1.0.0/24
latest handshake: 1 minute, 23 seconds ago
transfer: 1.2 MiB received, 4.8 MiB sent
persistent keepalive: every 25 seconds

Illustrative output

The fix: update AllowedIPs on both ends. WireGuard’s AllowedIPs is a routing-table-like structure; both ends have to include the subnet for the routing to be symmetric.

Multi-WAN: route order and gateway groups

A multi-WAN deployment adds a routing twist: the firewall has a default route through one WAN and policy-based rules that send IPsec traffic through another. The IPsec tunnel may be bound to the wrong WAN, or the return traffic may not match the policy.

The diagnostic:

route -n get 10.1.0.50 returns the wrong interface.
pfctl -s rules | grep rtable shows the policy-routing assignments.

The fix:

For route-based IPsec: ensure the route to 10.1.0.0/24 has the VTI as next hop, regardless of WAN. Add the static route with the VTI as gateway; the WAN-specific routing is irrelevant for traffic that traverses the VTI.
For policy-based IPsec: the Phase 2 selectors do not interact with policy routing directly; the SA is invisible to the routing table. The operator who needs policy-routed policy-based IPsec has to convert to route-based first.

Asymmetric routing across the tunnel

A subtle failure: traffic from A to B crosses the tunnel; traffic from B to A takes a different path. The state is broken because the firewall expects a return packet through the tunnel and gets nothing.

The diagnostic:

tcpdump -ni ipsec0 -c 4 host 10.1.0.50
> 12:34:56.789012 10.0.0.50 > 10.1.0.50: ICMP echo request
> (no response)

tcpdump -ni igb1 -c 4 host 10.1.0.50
> 12:34:56.789013 10.1.0.50 > 10.0.0.50: ICMP echo reply

The echo reply arrives on the WAN (igb1), not the VTI. The remote side is routing the reply through its WAN to the operator’s WAN, where it arrives un-ESP-wrapped. The local firewall has no state for an ESP packet from the WAN to that destination, so it drops.

The cause: the remote side’s return route is not through the tunnel. The fix is on the remote side’s routing table.

The routing diagnostic workflow

For a tunnel up but no traffic flowing:

1. swanctl --list-sas
   → ESTABLISHED with byte counters rising: Layer 3 / Layer 4 problem
   → ESTABLISHED with byte counters at zero: routing problem on local or remote

2. route -n get <remote-host>
   → Egress interface is VTI (ipsec0 or wg0): routing is correct on local
   → Egress interface is WAN (igb1): local routing is missing the remote subnet

3. tcpdump -ni <vti_or_wg0> -c 4
   → Packets leave: routing local is correct; remote side is failing
   → No packets: local routing is the problem

4. tcpdump -ni <wan> 'esp or udp port 4500'
   → ESP packets leaving: encapsulation is happening
   → No ESP packets: encapsulation is failing (check Phase 2 entry, VTI binding)

5. Confirm remote side's routing table
   → The remote operator must check their route to <local-subnet> through their VTI

Why route-based IPsec is much easier to debug than policy-based

Route-based IPsec puts the tunnel into the routing table as a virtual interface. Every standard tool the operator uses for IP routing — route, netstat, tcpdump, mtr, traceroute, the OPNsense web UI’s routing page — works on the tunnel. The failure modes are predictable: missing route, wrong gateway, asymmetric return path. Each has a specific diagnostic.

Policy-based IPsec, in contrast, hides the tunnel from the routing table. The operator cannot route -n get and see the tunnel as the egress interface. They have to look at Phase 2 selectors, traffic selectors, and ESP traffic on the WAN to confirm the tunnel is being used. The failures are harder to find because the routing-table mental model does not apply.

This is why route-based VPN with a VTI is recommended for production deployments.

Summary

For route-based IPsec, route -n get <remote> must show the VTI as egress.
For policy-based IPsec, Phase 2 selectors must cover the protected subnets on both sides.
For WireGuard, AllowedIPs is the routing table; both ends have to include the new subnet.
Asymmetric routing (traffic takes one path there, a different path back) produces state-table misses and silent failures.
When traffic leaves but does not return, the cause is the remote side’s routing, not the local side’s.
The diagnostic workflow: confirm SAs up, check route lookup, capture on tunnel interface, capture on WAN for ESP, ask the remote operator to confirm their routing.