OPNSense Site-to-Site VPN Not Working Properly: Troubleshooting Steps

Site-to-site VPN failures in OPNsense typically stem from mismatched IKE proposals, incorrect tunnel interfaces, or firewall rules blocking ESP traffic. This guide walks through verifying certificate validity, checking phase one and two settings, and ensuring NAT exemptions are correctly applied to restore secure connectivity between remote networks.

Verifying Certificate Validity and Trust

Since the configuration assumes the use of certificates as per the official documentation, the first step is to ensure both sides trust the same Certificate Authority (CA). Navigate to System > Certificates > Certificates on both OPNsense firewalls. Verify that the local certificate used for the peer is signed by a CA present in the trusted list on the remote device. If the certificates were recently rotated, you must update the peer configuration to reference the new certificate fingerprint. An expired certificate will cause immediate authentication failures during Phase One negotiation. Check the expiration dates carefully, as even a one-day difference can prevent the tunnel from establishing.

Checking Phase One and Two Settings

Navigate to Vpn > Ipsec > Connections and review the global settings. Ensure that the encryption algorithm matches on both ends. Common mismatches occur when one side uses AES-256-GCM while the other expects AES-128-CBC. Similarly, verify the hash algorithm (SHA256 vs SHA1) and the Diffie-Hellman group. Mismatched DH groups result in silent failures where no error message appears, but the tunnel never comes up. In Phase Two, check the proposal settings again. The lifetime values do not need to match exactly, but they should be within a reasonable range. If one side sets a lifetime of 3600 seconds and the other 7200, the connection may drop unexpectedly due to rekeying issues.

Configuring Firewall Rules and NAT Exemptions

Firewall rules often block IPsec traffic because it uses protocol 50 (ESP) rather than TCP or UDP ports. Go to Firewall > Rules > Lan (or your internal interface) and ensure there is a rule allowing ESP traffic from the remote subnet. Additionally, you must create a NAT exemption rule. Navigate to Nat > Rules > Outbound. If using manual outbound mode, add a rule to exempt traffic between the local LAN and the remote VPN subnet from source NAT. Without this exemption, packets leaving the local network will have their source IP translated to the WAN IP, causing the remote site to reject them as they appear to come from an unauthorized source.

Diagnosing with Packet Capture

If the above steps do not resolve the issue, use Wireshark or the built-in packet capture tool in OPNsense. Attach the capture to the WAN interface of both devices simultaneously. Look for ISAKMP packets on UDP port 500. If you see requests but no responses, the problem lies in routing or firewall blocking. If you see responses but no further handshake, the issue is likely cryptographic. Compare the captured packets against the expected parameters. For more details on general VPN troubleshooting techniques, see our guide on Troubleshooting OpenVPN Connection on Raspberry Pi for Specific Device Subnet.

Reviewing Routing Tables

Ensure that each OPNsense instance has a static route pointing to the remote subnet via the VPN tunnel interface. Go to System > Routing > Routes. Add a new route if missing, specifying the destination network and the gateway as the virtual IP of the remote end. Without these routes, traffic will attempt to go out the default gateway instead of entering the encrypted tunnel. Also, verify that the "Use Gateway" option is selected for the tunnel interface itself. Incorrect routing is a common cause of partial connectivity where ping works but applications fail.

Testing Connectivity and Logs

After applying changes, clear the existing sessions in Status > States to force a fresh negotiation. Check the system logs under System > Log > IPsec. Look for entries indicating successful authentication and key exchange. If errors persist, enable verbose logging temporarily. Remember to disable it afterward to avoid performance impacts. For advanced scenarios involving asymmetric routing or complex topologies, refer to Wireguard Peer Not Accessible by Other Peers for similar diagnostic approaches applicable to different protocols.

Frequently Asked Questions

Why does my VPN connect but I cannot ping across?

This usually indicates a missing NAT exemption rule or incorrect firewall permissions. Ensure that ESP traffic is allowed and that source NAT is disabled for traffic between the two subnets. Check your outbound NAT rules to confirm the exemption exists.

How do I reset IPsec settings in OPNsense?

You can delete all connections under Vpn > Ipsec > Connections and recreate them from scratch. Alternatively, export the configuration, remove the ipsec section manually, and import it back. Always backup your config before making drastic changes.

What causes "Phase 1 Failed: No Proposal Chosen"?

This error means the encryption algorithms or DH groups do not match between peers. Review the Phase One settings on both firewalls and ensure they use identical proposals. Adjust one side to match the other, preferably using strong defaults like AES-256-GCM and SHA256.

Can I use pre-shared keys instead of certificates?

Yes, OPNsense supports pre-shared keys (PSK) for simpler setups. Select "Pre-Shared Key" in the Phase One type dropdown. However, certificates are recommended for larger deployments due to better scalability and security management.

How do I check if the tunnel is active?

Go to Vpn > Ipsec > Status. Active tunnels will show up here with uptime statistics. You can also run a ping from the shell to the remote subnet's virtual IP to test basic connectivity.