Getting IPsec working on OPNsense without pulling your hair out
I spent three days last month debugging an IPsec tunnel that refused to tear down and rebuild on its own. The remote peer would respond to ISAKMP phase 1, negotiate P1 just fine, then drop dead on P2 setup every single time. Turned out it was a MTU mismatch on the intermediate link. The local subnet had been configured with a 1500 MTU policy when the actual path MTU was 1480. Packet drops were silent and consistent. Fix was trivial once I found it, but tracking it down ate half my week. This is what usually separates a working IPsec setup from one that works until it doesn't.
Secure Your Network A Stepbystep Guide To Opnsense Ipsec VPN Configuration
Start by confirming your interfaces are assigned correctly. OPNsense relies on correct interface binding for Phase 1 selections, and mixing up WAN and LAN or forgetting that a second WAN might be active will cause immediate confusion during tunnel creation. Check System -> Routing -> Interfaces if you're unsure what's actually up. Navigate to VPN -> IPsec and click Add P2. This is the second phase entry where most people get stuck. The UI presents a lot of options and OPNsense defaults to values that look correct but aren't always right for your use case. The key fields are Local Network, Remote Network, Pre-Shared Key, and the Phase 1 selector. For Phase 1, pick something reasonable. DH group 14 with AES-256-CBC and SHA-256 is widely compatible. If you're talking to hardware appliances like FortiGate or Palo Alto, avoid choosing ECDH curves unless you know those devices support them in their current firmware. I once selected curve 384 on a tunnel to a legacy SonicWall running an outdated build and spent forty minutes wondering why the other side never responded to anything.
The Pre-Shared Key field accepts a plain text string. OPNsense stores it hashed, so nobody with admin access can read it back, but the key still needs to match exactly on both ends including any special characters. A single extra space at the end is enough to break things and the logs won't tell you that. They'll just show rejected proposals instead of an authentication failure, which is annoying. Under Interface select the external-facing network. If you have dual WANs and want failover, this is where you configure it, but dual-WAN IPsec adds complexity that isn't worth it unless you actually need the redundancy. Single-WAN setups are significantly easier to troubleshoot.
Get the Full Details
Phase 2 configuration details
Phase 2 entries define what traffic flows through the tunnel. Each P2 represents a specific network-to-network mapping. The Local Network and Remote Network fields are where you enter the actual subnets you want to encrypt. Be precise here. Using 10.0.0.0/8 when your local subnet is actually 10.0.1.0/24 will work but routes traffic unnecessarily and creates confusion later when you need to filter or debug something. Set the proposal to match or exceed Phase 1. Common choices are AES-256-GCM or AES-256-CBC with SHA-256 or SHA-384 depending on your peers. GCM is faster on hardware that supports it. If your remote side is a consumer-grade router or an older firewall, GCM might not be supported at all and you'll need to fall back to CBC. I've seen people spend an hour switching proposals back and forth before realizing the remote device simply doesn't implement GCM in IPsec mode. Enable the tunnel. There's a checkbox for that. Then save and apply. OPNsense will generate the necessary entries in strongSwan and restart the IKE service for that particular connection. The status page under VPN -> IPsec -> Status shows negotiation progress in near real time. Watch it after applying. You should see Phase 1 go established, then Phase 2 follow within seconds.
Common pitfalls and what the logs actually say
When IPsec fails to come up, the first place to look is System -> Log Files -> IPsec. The log format is verbose but readable once you know what to scan for. Look for the strings failed, rejected, or no proposal chosen. Those three lines usually contain the entire answer. Everything else is noise. A very common failure mode is a DPD setting mismatch. Dead Peer Detection keeps tunnels alive by sending periodic keepalives. If one side has DPD enabled and the other doesn't, the tunnel will appear up on the non-DPD side while the DPD side silently marks it as down. Traffic then either stalls or takes an unexpected fallback route. Set DPD to the same value on both ends or disable it on both ends. Don't mix them. Another issue that bites people regularly is NAT traversal. If either endpoint sits behind a NAT device, you must enable NAT-T on OPNsense. Go to the Phase 1 settings and check the Enable NAT-T box. Without it, the ESP protocol gets blocked by the intermediate router and the tunnel never establishes. UDP port 4500 is used for NAT-T encapsulation, so verify your upstream firewall allows UDP 4500 in addition to UDP 500 for ISAKMP.
OPNsense also has a feature called aggressive mode for Phase 1. It reduces negotiation round trips but sends the initiator's identity unencrypted in the initial exchange. That makes it vulnerable to identity-based probing attacks. I recommend sticking to main mode unless you have a specific reason not to. Aggressive mode is rarely the right default choice and I've seen it cause confusion when remote peers reject the ID payload for policy reasons.
Routing and policy setup
Once the tunnel is established, make sure your internal routing knows about the remote subnet. If you're using a site-to-site VPN between two OPNsense boxes, each side needs a static route pointing to the tunnel interface. This is usually automatic in OPNsense when you use the built-in IPsec wizard, but manual configurations sometimes skip it. Check System -> Routing -> Routes to confirm the route exists. If it doesn't, add it manually with the appropriate gateway. Firewall rules on the interface side control what traffic is actually allowed through the tunnel. Go to Firewall -> Rules and add a rule on the IPsec interface permitting the traffic you want. Default OPNsense policy blocks all traffic on new interfaces, so forgetting this step means the tunnel will come up and stay up while carrying zero usable traffic. That silence is misleading. The status page will look healthy. I learned this the hard way on a client engagement. The tunnel showed established for two hours before anyone noticed nothing was flowing. A single missing rule on the IPsec interface was the entire problem. Three hours of troubleshooting later.
Testing and validation
Use the diagnose command line if the GUI isn't showing what you expect. From Shell, run ipsec statusall to see live SA counters and negotiated parameters. The output includes byte counts, packet counts, and rekey triggers. If byte counts aren't increasing on an established tunnel, traffic isn't actually being routed through it. Check your firewall rules and static routes again. From a host on the local subnet, ping the remote subnet. If pings succeed but certain ports fail, you're looking at a firewall rule issue or a MTU problem. Try a TCP handshake test with telnet or nc to the specific service on the remote side. ICMP works on almost everything but HTTP and SSH will fail at different points depending on your ruleset. Bandwidth testing over IPsec tunnels is rarely meaningful over short distances because most home and small business links bottleneck on the ISP side long before the encryption layer becomes relevant. If you need performance numbers, test across a known good link first, then compare. The difference is usually negligible for typical office use.
What OPNsense IPsec can't do well
The biggest limitation is scalability. OPNsense handles point-to-point and star-topology IPsec tunnels fine for dozens of connections. Beyond that, the management overhead increases and performance starts degrading because each tunnel carries its own SA table entries and DPD timers. If you're managing more than fifty tunnels, consider a dedicated VPN concentrator or a cloud-based service instead. OPNsense isn't built for that scale. Another constraint is authentication method flexibility. OPNsense supports certificate-based and pre-shared key authentication natively. It does not support RADIUS-based IPsec authentication out of the box without additional plugins or external radius server integration, and even then the integration is clunky. If your organization requires RADIUS-backed VPN auth, plan for a more involved setup or look at alternative solutions like openFortiVPN or a commercial appliance designed around that workflow. Traffic selector limitations are worth noting. Each Phase 2 entry is a single network object or alias. You can't create overlapping or conditional selectors that evaluate based on source port or application type. If you need granular per-application policies through the VPN, you'll need to combine IPsec with a proxy or split-tunnel configuration using firewall rules instead of relying on the IPsec layer alone.
Maintenance habits that prevent headaches
Keep your OPNsense version current. Security patches for strongSwan and the IKE stack are released regularly and many of them fix edge cases that cause intermittent tunnel drops. I've seen three separate incidents where upgrading from an older stable release to the latest patch fixed tunnels that had been flagged as broken for weeks. The issue wasn't configuration. It was a library bug. Export your configuration after every change. System -> Backup -> Restore Configuration has an export button. Save a dated file. When something breaks after a UI update or a config edit, you can revert in minutes instead of spending hours reconstructing settings from memory. I've lost count of how many times this has saved an afternoon. Document your Phase 1 and Phase 2 proposals somewhere outside the firewall. When you're rotating keys or rebuilding after a failure, remembering whether you used DH group 14 or 5, SHA-256 or SHA-384, GCM or CBC, and what the exact pre-shared key string was becomes difficult fast. A simple text file with dates and values prevents unnecessary troubleshooting.
When to look elsewhere
If your use case involves mobile clients connecting with iOS or Android devices, WireGuard is generally the better choice. OPNsense supports WireGuard natively now and it handles roaming, low-latency rekeys, and mobile OS compatibility far more cleanly than IPsec does. IPsec on mobile devices is notoriously fragile. Background app switches, cellular handoffs, and DOCSIS modem resets all tend to break IPsec tunnels in ways that WireGuard handles gracefully. For internal segmentation between trusted zones where you don't need to cross untrusted networks, OPNsense's existing firewall rules and VLANs may be sufficient. IPsec adds overhead and operational complexity that isn't justified for every internal connection. Reserve VPN encryption for traffic that actually needs to traverse untrusted infrastructure. Start simple. Get one tunnel working. Verify it with pings and a TCP test. Document the settings. Then expand. Rushing into multiple tunnels before the first one is stable is how you end up with three broken configs and no idea which one caused the symptom you're chasing.
