IPsec VPNs and Traffic Inspection
IPsec VPNs and traffic inspection tests your ability to build a tunnel from proposals through gateways, VPN traffic selectors, and routing, then verify that traffic is actually inspected and encrypted. JNCIS-SEC questions often fail candidates on mismatched phase 2 selectors or a missing route/policy.
IPsec building blocks
- Phase 1 (IKE) uses an IKE proposal, IKE policy, and gateway. The proposal defines encryption, hash, DH group, and authentication method; the gateway defines local/remote addresses and pre-shared key or certificate.
- Phase 2 uses an IPsec proposal and VPN. The VPN defines traffic selectors (local and remote subnets) and binds to a tunnel interface such as st0.0.
- Route-based VPNs route the remote subnet through st0.0 and use a security policy for the st0 zone. Policy-based VPNs use a policy action to tunnel matching traffic.
Inspection and verification
- Traffic entering the tunnel is still subject to security policy; IPsec does not replace policy.
- Verify IKE and IPsec SAs, traffic selector alignment, DPD, and counters. Mismatched proxy IDs, IKE versions, PSK, or PFS settings prevent phase 2 from establishing.
Worked example: Site A uses 10.1.0.0/24; Site B uses 10.2.0.0/24. Configure an IKE gateway to 203.0.113.2 with a proposal using AES-256, SHA-256, and DH group 14. Configure an IPsec proposal with ESP AES-256/SHA-256 and PFS group 14. Create a VPN with local traffic selector 10.1.0.0/24 and remote 10.2.0.0/24, bind st0.0, and route 10.2.0.0/24 via st0.0. Add a trust-to-vpn policy permitting the required applications. Reasoning: phase 1 must match, phase 2 selectors must mirror each other, and the route plus policy must steer and permit the traffic.
Traps: mismatched traffic selectors; forgetting the st0 route or policy; wrong pre-shared key; IKEv1 versus IKEv2 mismatch; and assuming a tunnel bypasses security policy.