Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 5.5 — Explain IPsec VPN models

An IPsec virtual private network protects IP traffic while it crosses an untrusted network. It can provide confidentiality, integrity, origin authentication, and anti-replay protection for traffic within its negotiated scope. It does not make endpoints trustworthy, decide application authorization, or guarantee that every packet uses the tunnel.

Compare the two common models

A remote-access VPN connects an individual user or managed endpoint to an organization. Client identity, device posture, address assignment, and user authorization often matter. A site-to-site VPN connects networks through gateway devices. Hosts usually send traffic normally while the gateways select and protect the traffic that crosses between sites.

Both models have tunnel endpoints and a definition of interesting or protected traffic. The design must specify routes, selectors, identities, and policies on both peers. A tunnel can be established while the desired application subnet is still excluded by a selector or missing a return route.

Separate negotiation from data protection

IKE authenticates peers and negotiates security associations and cryptographic parameters. ESP commonly protects the data plane. The peers must agree on compatible algorithms, identities, lifetimes, and protected traffic. Avoid memorizing a tunnel as one permanent object; it is a set of negotiated state that can expire and be replaced.

NAT, overlapping addresses, and path MTU can complicate operation. Encryption hides payload information from intermediate devices and adds overhead. Logging should provide enough metadata to diagnose negotiation without exposing keys or sensitive payloads.

Worked scenario

Two branches show an active site-to-site security association. Users at Branch A can reach one server at Branch B but not a newly added subnet. Because existing traffic succeeds, basic peer authentication and data protection probably work. Compare the new subnet's routes and traffic selectors on both gateways, verify return reachability, then inspect counters while generating controlled test traffic. Rebuilding the entire tunnel first discards useful evidence.

Define the protection boundary

Ask what traffic enters the tunnel, what remains outside it, where decryption occurs, and which policy applies afterward. Split tunneling may send some remote-access traffic directly to the internet; full tunneling may carry more traffic through organizational controls. Neither choice is universally correct. Endpoint security, segmentation, ACLs, DNS policy, and monitoring continue to matter after decryption.

Verification evidence

Check peer identity, negotiation status, active security associations, selectors, routes, encapsulation and decapsulation counters, errors, and lifetimes. Test traffic in both directions and confirm the path and source addressing. Validate that unapproved subnets are not unintentionally protected or reachable.

Common traps

• Treating an active tunnel as proof every application can pass.
• Confusing remote-access users with site-to-site gateways.
• Saying encryption provides endpoint health or authorization.
• Checking only one peer's selectors and routes.
• Ignoring overhead, return paths, or overlapping networks.

Readiness checklist

• I can compare remote-access and site-to-site VPNs.
• I distinguish IKE negotiation from protected data transfer.
• I can describe selectors, routes, peers, and security associations.
• I verify the intended traffic scope in both directions.