VPN and Secure Tunneling
IPsec building blocks
Site-to-site IPsec uses IKE to negotiate security associations. Phase 1 (IKE SA) authenticates peers using a pre-shared key or certificates, agrees encryption and integrity algorithms, and performs a Diffie-Hellman exchange. Phase 2 (IPsec SA) defines the traffic selectors, encapsulation mode (tunnel or transport), PFS, and SA lifetimes. Mismatched proposals, mismatched pre-shared keys, a wrong peer ID, or different selectors all cause failures at specific stages - read the logs to see whether phase 1 or phase 2 fails.
Routing and traffic handling
A tunnel is useless without routing: traffic must be steered into the tunnel, either by a static route to the remote subnet or by policy-based selectors. The firewall also needs a policy permitting the tunnel traffic and, on many platforms, a policy permitting the decrypted traffic between zones. NAT exemption is frequently required so that VPN-bound traffic is not translated by an outbound SNAT rule.
Remote access and edge cases
SSL/TLS remote-access VPNs provide client-based or clientless access and often support split tunnelling, where only selected subnets traverse the tunnel. Watch for overlapping subnets between sites, which are hard to solve without re-addressing or double NAT, and for MTU/MSS issues that break large transfers while ping succeeds.
Worked example
If phase 1 establishes but phase 2 never comes up, compare the traffic selectors (proxy IDs), PFS settings, and phase 2 proposals on both peers before touching routing. If both phases are up but no traffic passes, check the route into the tunnel, the policy for decrypted traffic, and NAT exemption.