IPsec route-based vs policy-based — how OPNsense wires the tunnel into the firewall

An IPsec tunnel on OPNsense can be wired into the firewall in two fundamentally different ways. The classic model — policy-based VPN — encapsulates traffic based on traffic selectors that match the source and destination subnets: any packet matching the selector gets put into the tunnel. The modern model — route-based VPN — creates a virtual tunnel interface (VTI) that the routing table treats as a next hop: the operator pushes a route to the remote subnet through the VTI, and packets that follow the route get encapsulated. Both models produce working IPsec tunnels. The difference is in what the operator can do with the tunnel once it exists — fire wall rules, NAT exceptions, multi-WAN integration, monitoring all look very different on the two models. This lesson covers the two models, how OPNsense implements each, and how to choose.

The two models

Policy-based VPN. The Phase 2 entry carries a traffic selector (local subnet, remote subnet, protocol, port range). When a packet matches the selector, strongSwan encapsulates it and sends it through the IPsec SA. The matching happens in the IPsec layer, before the firewall or routing table sees the packet as a tunnel packet. From the operating system’s perspective, the encapsulated traffic just disappears into the SA; the only way to know what’s encapsulated is to read the SA’s selectors.

Route-based VPN. The IPsec SA is associated with a virtual tunnel interface (a ipsecX interface on FreeBSD, or a tunX if using the TUN device model). The operator assigns an IP address to the VTI, adds a route to the remote subnet through the VTI as next hop, and writes firewall rules on the VTI just like on any other interface. From the operating system’s perspective, the tunnel is a wire — packets routed through it get encapsulated, packets not routed through it do not.

Why route-based VPN is usually the right choice

Five reasons route-based VPN beats policy-based in production:

Firewall rules on the tunnel. With a VTI, the operator writes firewall rules that match source/destination tuples from the LAN to the remote subnet across the VTI — exactly the same shape as rules for any other interface. With policy-based, the only “rules” are the traffic selectors in the Phase 2 entry, which are far less expressive.

NAT exceptions per remote network. A typical estate has some traffic that should cross the IPsec tunnel without NAT (so the remote end sees the original source IP) and other traffic that should be NAT-translated. On a VTI, the operator writes the NAT rule with the VTI as the egress interface. On a policy-based tunnel, the same effect requires careful Phase 2 selector management.

Multi-WAN integration. If the firewall has two WANs and the operator wants IPsec traffic to use the primary WAN but everything else to use the default route, the VTI makes this trivial — add a route to the tunnel with the primary WAN as the gateway. Policy-based VPNs cannot be paired with gateway groups because the SA is invisible to the routing table.

Monitoring. A VTI appears in ifconfig output, systat -ifstat, and OPNsense’s interface statistics pages. The operator can see packet counts, error counts, and byte counters on the tunnel just like on any other interface. Policy-based tunnels show up only in strongSwan’s status output, not in any system-wide interface view.

Multiple subnets without selector multiplication. A route-based tunnel can carry traffic to many remote subnets by adding more routes through the VTI. A policy-based tunnel needs a new Phase 2 entry per subnet pair, each with its own SA, each with its own lifetime, each with its own negotiation. Route-based with one Phase 2 + many routes is operationally simpler.

Configuring route-based VPN on OPNsense

The configuration workflow for a route-based tunnel:

1. Phase 1 entry under VPN → IPsec → Tunnel Configuration → Add Phase 1. IKEv2, certificate or PSK, AES-256-GCM, DH group 14 or 31, 24h lifetime. Standard.
2. Phase 2 entry under the same tunnel. Set both Local subnet and Remote subnet to 0.0.0.0/0 (a wildcard), set Protocol to ESP, set Encryption to AES-256-GCM, enable PFS, 1h lifetime.
3. Enable VTI under the Phase 2 entry’s “Tunnel Settings” or in the Phase 1 entry’s advanced settings. The OPNsense UI exposes VTI as the “Install Virtual Tunnel Interface” toggle.
4. Assign the VTI as an interface. Once Phase 2 is saved, a new ipsec0 (or similar) interface appears under Interfaces → Assignments. Assign it a name (e.g., OPT_VPN).
5. Configure the VTI under Interfaces → OPT_VPN. Set a private IP address — typically a /30 between two fictional endpoint addresses like 10.10.10.1/30 peer 10.10.10.2. The peer IP does not need to be reachable; it just identifies the far side of the tunnel.
6. Add a route under System → Routes → Configuration for the remote subnet with the VTI as the gateway, or rely on dynamic routing if the operator is running OSPF/BGP.
7. Add firewall rules for the VTI: allow the LAN subnets to talk to the remote subnets, block anything that should not enter the tunnel.

$ ifconfig ipsec0

ipsec0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
inet 10.10.10.1 --> 10.10.10.2 netmask 0xfffffffc
inet6 fe80::a8b1:c2d3:e4f5:6789%ipsec0 prefixlen 64 scopeid 0x8
nd6 options=21<PERFORMNUD,NO_RADR>
groups: ipsec
phase 2
reqid 1

The VTI is a point-to-point interface with a relatively small MTU (typically 1400; the operator can lower it to 1380 or even 1360 for safety). The operator writes firewall rules on the VTI and treats it as an internal interface that happens to encapsulate through IPsec.

When policy-based VPN still wins

Two scenarios where policy-based is the right answer:

Hub-and-spoke with very different subnet shapes per spoke. A central hub with 10 spoke sites, each protecting a different subnet (192.168.1.0/24, 192.168.2.0/24, etc.), can use one Phase 1 entry on the hub per spoke, each with a Phase 2 entry whose selector matches that specific spoke’s subnet. Route-based would work too, but the policy-based shape is sometimes easier to audit (“the tunnel to spoke 7 carries only 192.168.7.0/24”).

Strict payload containment. If the deployment has a compliance requirement that no traffic beyond a specific subnet pair can cross the tunnel, the policy-based traffic selector enforces that at the SA level. The operator cannot accidentally route additional traffic through the SA without modifying the Phase 2 entry.

These scenarios are real but rare. For the majority of deployments, route-based VPN with a VTI is simpler, more flexible, and easier to integrate with the rest of the firewall.

Verifying route-based VPN

The verification workflow for a route-based tunnel:

1. Confirm the VTI exists. ifconfig ipsec0 shows the interface with its IP address and point-to-point peer. swanctl --list-sas shows the active IKE and ESP SAs.
2. Confirm the route. netstat -rn | grep ipsec0 shows the route to the remote subnet through the VTI.
3. Confirm the firewall allows the traffic. pfctl -s rules | grep ipsec0 shows any firewall rules on the VTI. A missing rule on a VTI with a default-deny policy is the most common silent failure.
4. Confirm traffic flows. A ping from the LAN to a host on the remote subnet appears in tcpdump -ni ipsec0 as clear-text encapsulated packets, and in tcpdump -ni WAN as the encrypted ESP traffic.
5. Confirm state. pfctl -s state | grep ipsec0 shows the PF states on the VTI.

$ route -n get 10.1.0.50

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

Summary

• Policy-based VPN matches traffic to traffic selectors at the SA level; the tunnel is invisible to the rest of the firewall.
• Route-based VPN creates a VTI (virtual tunnel interface) that the routing table treats as a next hop; the tunnel is a first-class interface.
• Route-based VPN is the production default because it integrates with firewall rules, NAT, multi-WAN, and monitoring.
• Configure route-based VPN on OPNsense by enabling VTI on Phase 2, assigning the VTI as an interface, and adding routes.
• Wildcard selectors in policy-based VPN are a footgun — switch to route-based instead.