Route-Based vs Policy-Based Site-to-Site VPN: What Differs
Policy-based IPsec picks traffic by selector; route-based sends it through a tunnel interface. Both still need firewall rules and a reply route.
Both designs protect the same traffic with the same IPsec machinery, and they differ in what decides which packet enters the tunnel. In a policy-based connection the negotiated traffic selectors do that job; in a route-based one, a route pointing at a tunnel interface does. Confusing the two produces a familiar support thread in which the tunnel reports established while the application reaches nothing. The distinction matters most when you add a network, run a routing protocol, or debug a path that quietly leaves through the wrong exit.
Two Ways to Decide What Enters the Tunnel
A policy-based VPN builds a security policy that matches source and destination prefixes, then encrypts whatever fits. The peer has to negotiate compatible selectors, so the effective scope ends up as the intersection of what both sides proposed. Nothing outside that intersection is protected, whatever the routing table says.
A route-based VPN creates an interface that stands for the tunnel and lets the routing table send traffic into it. The IKE daemon still installs the state and the per-interface policy, which is the detail people skip when they decide that routes have replaced encryption. Both designs encrypt with IPsec; only the selection mechanism differs.
Read the comparison below as a set of failure signatures rather than a scorecard, because neither column wins in the abstract.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
Policy-Based: The Selector Is the Contract
Selectors are negotiated, not merely configured. Propose 10.10.0.0/16 on one side and 10.10.1.0/24 on the other, and the association covers whatever the negotiation settled on while every other host stays outside it.
Read the installed state instead of the configuration file. On a Linux peer the kernel's own tables are the ground truth, and they show what survived the negotiation. A policy that names the right prefixes with no matching state means the association never came up. State paired with a policy for the wrong prefix is the opposite problem, and it produces the tunnel that looks healthy while one subnet cannot reach anything.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasCompare both outputs against the prefixes you believe you are protecting. That single comparison resolves most reports of a working tunnel with an unreachable server. It also points at which peer to change, since the mismatch is usually visible in one direction only.
Route-Based: The Interface Is the Contract
An XFRM interface gives the tunnel a name and an identity, and traffic reaches it because the routing table says so. Several remote prefixes then become a routing problem rather than a selector problem, and a routing protocol can advertise them. That is the real gain, not encryption.
The interface does not remove the need for policy. The daemon installs per-interface rules bound to the interface identity, so a packet arriving on the wrong interface still fails. A source address the peer will not accept fails as well, even with a perfect route. Route-based means the route decides entry, not that policy disappeared.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10Watch the interface counters once the route is in place. A route that exists while the counters stay at zero means nothing is being matched into the tunnel, which usually points at a missing state rather than a missing route.
Where the Two Designs Actually Diverge
Adding a network is the cleanest test of which model suits you. A route-based design adds a route and at most widens the selector once, while a policy-based design edits prefix pairs on both peers and renegotiates. Two stable subnets make that edit trivial, and twenty make it a project.
Neither model replaces a firewall, and comparisons usually stop before this point. A wide selector or a broad route decides what is encrypted, not what is permitted.
MTU behaviour differs in practice as well. Encapsulation reduces the usable payload, and a route-based interface carries its own MTU, so clamping MSS at both gateways avoids the black-hole symptom where small replies arrive and large ones vanish. Policy-based tunnels meet the same wall from the other side, because a selector says nothing about packet size. Set the clamp deliberately rather than blaming the peer.
Migrating Without Losing the Return Path
Record the existing prefix pairs before changing anything, then move one application path and watch it end to end. A tunnel that establishes is not a tunnel that forwards, and the difference appears in the reply direction.
When the peers connect but LAN hosts cannot, inspect the reply route and the source address the far host will use. A host with two interfaces may answer from the wrong one, and no selector change repairs that. Capture traffic at both ends before editing algorithms.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsKeep a management path that does not depend on the tunnel while you work. Rolling back is easier when the gateway's own access does not ride on the connection you are debugging.