IPsec VPNs and Secure Connectivity
IPsec VPNs and Secure Connectivity tests your ability to build working site-to-site and hub-and-spoke tunnels: IKE proposals and policies, gateways, traffic selectors, st0 interfaces, routing, and liveness detection.
Building blocks
A proposal defines encryption, authentication, DH group, and lifetime. An IKE policy references proposals and sets PSK or certificate authentication and IKE version. A gateway defines local/remote addresses and identities. A VPN binds a gateway to an IPsec proposal and one or more traffic selectors. The st0 interface is the tunnel endpoint and must be in a security zone with a policy that permits the protected traffic.
Traffic selectors and routing
Traffic selectors, also called proxy IDs, must match on both peers. IKEv1 usually needs one selector per subnet pair unless multi-proxy-id is configured; IKEv2 supports multiple selectors more cleanly. Route the remote subnet through st0.0, or use next-hop tunnel binding to tie a route to a specific tunnel. DPD detects dead peers; set it on both sides.
Worked example
Site A is 10.1.0.0/16 and site B is 10.2.0.0/16, both behind SRX devices using IKEv2 and PSK. On A, configure traffic selector local-ip 10.1.0.0/16 remote-ip 10.2.0.0/16, bind st0.0, and add a static route to 10.2.0.0/16 next-hop st0.0. On B, mirror the selectors. Reasoning: if A's selector is 10.1.0.0/16 and B expects 0.0.0.0/0, phase 2 fails with a proxy-ID mismatch even though phase 1 is up.
Traps
- Mismatched traffic selectors: the most common phase 2 failure.
- Forgetting the security policy that permits traffic from the trust zone to the VPN zone with action tunnel.
- Source NAT accidentally translating VPN traffic; ensure NAT rules exclude it.
- Using aggressive mode with PSK in designs that expose the identity.