IPsec site-to-site on OPNsense — building, configuring and verifying a tunnel

A site-to-site IPsec tunnel on OPNsense is the operational pattern most firewall operators need to master. The pieces — Phase 1 negotiation, Phase 2 ESP SAs, a Virtual Tunnel Interface, routing, firewall rules — interact in ways that produce silent failures when one of them is wrong. This lesson walks through the full deployment: prerequisites, the configuration of each component, the certificate or PSK setup, the VTI wiring, and the end-to-end verification that confirms the tunnel is carrying real traffic.

The prerequisites

Before the operator configures anything, verify:

1. Both endpoints are reachable from each other. A ping from each firewall’s WAN IP to the other one’s WAN IP succeeds. IPsec cannot traverse an unreachable path.
2. UDP 500 and 4500 are allowed inbound on both WANs. UDP 500 carries IKE, UDP 4500 carries NAT-traversal ESP. A firewall or ISP blocking either produces a silent negotiation failure.
3. The ESP protocol (IP protocol 50) is allowed inbound on both WANs. ESP is IP protocol 50, not TCP or UDP — stateful firewalls have to explicitly allow it.
4. The protected subnets are routable on both sides. The Phase 2 traffic selectors reference local subnets; those subnets must exist on the firewall (assigned to an interface, served by a routing protocol, or statically routed) for the SA to be installed.
5. Time is correct on both peers. IKEv2 certificates and some PSK derivations depend on time-of-day matching; skew beyond a few minutes can break a Phase 1 negotiation.

When any of these are wrong, the IPsec configuration is fine but the tunnel cannot come up. Most “IPsec is broken” tickets turn out to be one of these prerequisites, not a proposal or PSK mismatch.

Choosing PSK or certificates

For a single tunnel between two known endpoints, PSK is the simpler choice. For an estate with more than a handful of tunnels or any expectation of credential rotation, certificates are the right answer.

PSK setup. Under VPN → IPsec → Pre-Shared Keys, add an entry with the PSK (a base64-encoded random string of at least 32 bytes) and the remote peer’s identity — typically its WAN IP. Save. The Phase 1 entry’s Authentication Method = “Mutual PSK” references this entry.

Certificate setup. Three ingredients:

1. A Certificate Authority (CA) under System → Trust → Authorities. Generate an internal CA if no external CA is in scope.
2. A server certificate for the OPNsense node. Under System → Trust → Certificates, generate a CSR, sign it with the CA, install it. The certificate has the firewall’s WAN IP or hostname as a Subject Alternative Name.
3. A copy of the remote peer’s CA certificate installed under System → Trust → Authorities, and the remote peer’s certificate (or its fingerprint) referenced in the Phase 1 entry’s Authentication = “Certificates” field.

The certificate approach scales: adding a new tunnel that trusts the same CA requires no PSK change. The PSK approach requires the operator to coordinate a new secret on both sides.

Configuring Phase 1

The Phase 1 entry under VPN → IPsec → Tunnel Configuration → Add Phase 1 exposes:

Common mistakes that produce silent failures:

• My identifier vs peer identifier mismatch. The My identifier and Peer identifier strings have to be what the peer expects. A DN in one place and an IP address in another is a mismatch.
• IKEv1 phase 1 main mode typo. With IKEv1, the only difference between “main mode” and “aggressive mode” is a single dropdown; pick the wrong one and the negotiation either leaks the PSK (aggressive) or fails outright (main with a proposal mismatch).
• Interface mismatch. A Phase 1 entry tied to the wrong interface (e.g., the LAN interface instead of WAN) tries to negotiate from a private IP and fails.

Configuring Phase 2

The Phase 2 entry under the same tunnel:

The 0.0.0.0/0 selector with a VTI is the standard site-to-site pattern. It does not “send all traffic through the tunnel” by itself — the tunnel only encapsulates traffic the routing table sends through the VTI. Wildcard selectors combined with a VTI give the operator full control via routing and firewall rules; this is the most flexible configuration.

The VTI, the route, and the firewall rules

Three steps wire the tunnel into the firewall:

Step 1 — assign the VTI. When the Phase 2 entry is saved with VTI enabled, a new interface (ipsec0 by default) appears under Interfaces → Assignments. Assign it to a custom name (OPT_VPN is a common choice).

Step 2 — configure the VTI. Under Interfaces → OPT_VPN, set an IP address. A /30 between two unused points-to-point addresses works:

• IP address: 10.10.10.1/30
• Peer (gateway in OPNsense terminology): 10.10.10.2

The peer IP does not have to be reachable — it is the identifier for the far side of the tunnel. Disable all inbound services (no DHCP, no Unbound on this interface), keep the MTU at 1400 or lower if the operator expects MTU issues downstream.

Step 3 — add the route. Under System → Routes → Configuration, add a static route to the remote subnet (e.g., 10.1.0.0/24) with the gateway set to the peer IP on the VTI (10.10.10.2).

Step 4 — add firewall rules. Under Firewall → Rules → OPT_VPN, add rules that allow the traffic:

Action: Pass
Interface: OPT_VPN
Protocol: any
Source: LAN net (or specific subnets)
Destination: 10.1.0.0/24 (the remote subnet)
Description: "Allow LAN to remote site"

Without the firewall rule, a default-deny policy on the VTI drops every packet. This is the most common silent failure for a brand-new tunnel.

The verification chain

The verification has six steps, each producing evidence the next step consumes:

Step 1 — confirm the IKE SA is up. swanctl --list-sas shows an entry with state ESTABLISHED, the negotiated algorithms, and the child SAs.

Step 2 — confirm the ESP SA is up. The same output shows the child SA with its traffic selector and lifetime remaining.

Step 3 — confirm the VTI has an IP and is up. ifconfig ipsec0 shows the configured IP and the interface flags include UP and RUNNING.

Step 4 — confirm the route exists. route -n get 10.1.0.50 (for any address in the remote subnet) shows the egress interface is the VTI.

Step 5 — confirm the firewall allows the traffic. pfctl -s rules | grep OPT_VPN shows the explicit pass rule.

Step 6 — end-to-end test. From a host on the LAN, ping a host on the remote subnet. The ping succeeds. tcpdump -ni ipsec0 on the OPNsense shows the encapsulated traffic as decrypted packets between the LAN and remote subnets. tcpdump -ni WAN shows only ESP traffic (encrypted, looking like random bytes) between the two firewalls.

$ swanctl --list-sas --no-headers

home-edge: #1, ESTABLISHED 5 minutes ago, 198.51.100.1[edson@example.com] ... 203.0.113.1[gateway@partner.example]
AES-256-GCM/PRF-HMAC-SHA2-384/ECP_384
child: home-edge-1, reqid 1, ESTABLISHED 5 minutes ago
  0.0.0.0/0 === 0.0.0.0/24
  ESP spi:0xc1d2e3f4 (0xc1d2e3f4) spi:0xa1b2c3d4 (0xa1b2c3d4)
  AES-256-GCM-16/ESN
  bytes_i (42 MiB) bytes_o (138 MiB)

The certificate management cases

A certificate-based deployment has three lifecycle events that the operator has to plan for:

Certificate expiry. Each tunnel’s certificate has a NotAfter field. A tunnel using an expired certificate fails IKEv2 authentication in IKE_AUTH. The fix is to renew the certificate, install it on the firewall, and update the Phase 1 entry’s certificate reference. OPNsense’s System → Trust → Certificates page lists each certificate with its expiry date; the operator who monitors this page annually avoids the surprise of tunnels going down at expiry.

CA rotation. When the issuing CA needs to be replaced (the current CA’s key approaches end of life, or the CA was compromised), every tunnel referencing that CA needs to be re-keyed. The disciplined approach: generate a new CA, sign new certificates, install them on both peers in parallel with the old CA still valid, then once both peers are using new certificates, retire the old CA. A mid-rotation failure has the operator facing a working-tunnel list and a migration plan.

Cross-CA trust. A typical estate has one CA per partner (for site-to-site tunnels to third parties). The OPNsense Trust store has to import each partner’s CA, and each Phase 1 entry has to reference the correct CA. A common mistake is to import the wrong CA or to forget to import a partner’s CA after their CA rolled — the tunnel fails authentication with NO_CERTIFICATE_FOUND or with a certificate mismatch.

The end-to-end test

The verification chain only proves that every component is in the right state. The end-to-end test proves the tunnel is actually carrying real traffic for real applications. The pattern:

1. From a LAN host, ping a remote host. Use a destination on the protected subnet; not the peer’s WAN IP.
2. Confirm the ping arrives. Use a packet capture on the remote side (if accessible) or check that the host responds.
3. Verify byte counters increased. swanctl --list-sas --no-headers before and after the test; the bytes_i and bytes_o fields should rise.
4. Run a real application. SSH to the remote host, transfer a file, browse an internal web service. Every application should work as if the remote host were on the local LAN.

Summary

• Verify prerequisites: peer reachability, UDP 500 and 4500 open, ESP allowed, subnets routable, clocks in sync.
• Choose PSK for a single tunnel; choose certificates for an estate with multiple tunnels or credential rotation needs.
• Configure Phase 1 (IKEv2, AES-256-GCM, DH group 14 or 31, 24h lifetime) and Phase 2 (ESP, AES-256-GCM, PFS, 1h lifetime) with VTI enabled.
• Wire the VTI: assign interface, configure IP, add route, add firewall rule.
• Verify with swanctl —list-sas, ifconfig ipsec0, route lookup, pfctl rules, and an end-to-end test.