IPsec VPNs
IPsec VPNs
This domain covers Junos IPsec building blocks: IKE phase 1, IPsec phase 2, gateway and VPN configuration, and route-based vs policy-based tunnels. Expect questions on which parameter mismatch breaks which phase.
Core rules
- Phase 1 negotiates the IKE SA using an IKE proposal, IKE policy, and IKE gateway. It authenticates peers with a pre-shared key or certificate.
- Phase 2 negotiates the IPsec SA using an IPsec proposal and IPsec policy; PFS can add a new Diffie-Hellman exchange.
- A route-based VPN binds the IPsec VPN to a tunnel interface such as st0.0. You then put st0.0 in a zone, route remote subnets to it, and permit traffic in policy.
- Proxy IDs identify the traffic selectors. They are required when the peer expects them or when multiple subnets share one tunnel.
- DPD detects a dead peer; without it, a stale SA can black-hole traffic until rekey.
Worked example
Site A uses 192.168.1.0/24 and Site B uses 192.168.2.0/24. On A, configure an IKE gateway to B public IP with a matching proposal and PSK, bind the IPsec VPN to st0.0, assign st0.0 to a VPN zone, add a static route for 192.168.2.0/24 next-hop st0.0, and permit trust-to-vpn traffic. If phase 1 comes up but phase 2 fails, compare IPsec proposals and proxy IDs first; if phase 1 fails, compare PSK, peer address, and IKE proposals.
Traps
A perfect policy cannot fix a missing route or an st0 interface outside a zone. Mismatched proposals, PSK, or proxy IDs are the usual culprits. Do not assume policy-based and route-based configurations are interchangeable.