Troubleshooting: Site-to-site VPN between different vendors always has quirks.

Caroline M. · 2026-08-01T18:11:11Z

While multi-vendor site-to-site VPNs are a practical necessity in heterogeneous environments, their implementation frequently deviates from the idealized models presented in interoperability matrices. The core issue is that standards like IKEv1/v2 and IPSec provide a framework, but leave ample room for vendor-specific interpretations and default behaviors. This post aims to catalog the most common points of failure and the methodological approach to resolving them. Based on a review of deployment logs and vendor-specific RFC implementations, the failure points typically cluster in these areas: * **Phase 1 (IKE SA) Parameter Mismatch:** * **Encryption/Authentication/DH Group:** While often matching, issues arise with certain non-standard combinations one vendor may accept and another may reject. * **Aggressive vs. Main Mode:** Legacy IKEv1 Aggressive Mode is often problematic; forcing Main Mode is a primary troubleshooting step. * **Local/Peer Identification:** Especially critical with IKEv2. One vendor may use an IP address (`ID_IPV4_ADDR`) while another expects a FQDN (`ID_FQDN`) even when the peer address is an IP. Mismatches here silently fail. * **Phase 2 (IPSec SA) Parameter Mismatch:** * **Proxy IDs (IKEv2) / Phase 2 Selectors:** The single most common culprit. Vendor A might define the local subnet as `10.1.0.0/24` and remote as `192.168.1.0/24`. Vendor B's configuration might implicitly or explicitly require these to be mirrored (`local=192.168.1.0/24`, `remote=10.1.0.0/24`) for the SA to establish. Some vendors require explicit configuration; others auto-populate based on routing. * **PFS (Perfect Forward Secrecy) Group:** A mismatch here will allow Phase 1 to complete but Phase 2 to fail. One side having PFS enabled (e.g., DH Group 14) while the other has it disabled is a typical scenario. * **Lifetime Discrepancies:** Significant differences in IPSec SA lifetime may cause one side to attempt rekeying before the other, leading to intermittent drops. **Methodological Debugging Approach:** 1. **Enable Verbose Logging:** Set IKE/IPSec debugging to the highest level on both ends. The goal is to see which side is sending a proposal and which side is rejecting it, and for what reason. 2. **Isolate Phase 1:** Ensure the IKE SA establishes. If not, systematically compare every parameter: mode, IDs, algorithms, NAT-T status (UDP 4500). Packet captures between the public IPs are invaluable here. 3. **Isolate Phase 2:** If Phase 1 is up but Phase 2 fails, examine the proxy IDs/selectors first, then PFS and lifetimes. A common diagnostic is to simplify the proposal to a single, universally supported transform (e.g., `ESP-3DES-SHA`) to rule out algorithm support. **Example of a Proxy ID Mismatch in Config Snippets:** ``` # Vendor A (e.g., Cisco ASA-like syntax) crypto map MYMAP 10 match address VPN-TRAFFIC crypto map MYMAP 10 set peer 203.0.113.2 crypto map MYMAP 10 set transform-set STRONG crypto map MYMAP 10 set security-association lifetime seconds 28800 # The local traffic selector 'VPN-TRAFFIC' is an ACL defining source=10.1.0.0/24, dest=192.168.1.0/24. ``` ``` # Vendor B (e.g., a generic IKEv2 config) ikev2 proposal MY-PROPOSAL encryption aes-gcm-256 integrity sha512 group 19 ipsec policy MY-POLICY ikev2 proposal MY-PROPOSAL local-address 203.0.113.2 peer-address 198.51.100.1 local-subnet 192.168.1.0/24 # Note: This is Vendor B's *local* subnet. remote-subnet 10.1.0.0/24 # This is Vendor B's *remote* subnet. ``` In this case, the proxy IDs align (`local` and `remote` are from each endpoint's perspective), and it should succeed. If Vendor B had reversed these subnets, the Phase 2 negotiation would fail despite the traffic selectors logically representing the same networks. The solution often involves a meticulous, parameter-by-parameter comparison of the *effective* settings on both ends, not just the configured ones, as defaults can vary widely. Sharing sanitized debug logs between teams is the fastest path to resolution. - Dr. C

Page 3 / 3 Prev

Firewalls

Last Post by brianw 2 hours ago

31 Posts

30 Users

0 Reactions

2 Views

RSS

brianw

(@brianw5)

Estimable Member

Joined: 3 weeks ago

Posts: 119

02/08/2026 8:21 pm

> The packet is the only source of truth

This right here is the core principle. I keep a portable tcpdump container image ready to go on my jump host for this exact scenario - run it on both endpoints, sync the timestamps, and compare.

That said, even the packet capture can have a blind spot if there's a middlebox doing its own translation, like a WAN optimizer or some "security" appliance stripping fields. I've seen captures match perfectly on both ends, yet the tunnel still wouldn't come up until we bypassed a transparent device we didn't know was there. So the packet is gospel, but only if you're certain you're capturing the actual wire traffic.

Automate all the things.

ReplyQuote

Page 3 / 3 Prev