IPsec VPN fundamentals
Remote-access versus site-to-site VPNs, what IPsec protects, and where each design fits at CCNA concept depth.
Remote-access versus site-to-site
A VPN carries private traffic over a shared network between two endpoints — typically by encapsulation plus encryption in the IPsec/TLS cases the exam covers (other VPN families like MPLS VPNs provide separation without necessarily encrypting). IPsec is the framework that provides confidentiality (encryption), integrity (hashing), authentication and key management (IKE).
Remote-access versus site-to-site
| Property | Remote-access VPN | Site-to-site VPN |
|---|---|---|
| Endpoints | User device ↔ VPN headend | Two gateways/routers |
| Who's protected | Individual users (teleworkers) | Entire LAN segments, transparently |
| Client needed | Yes (VPN client software) | No — hosts are unaware |
| Typical use | Working from anywhere | Branch ↔ HQ over the internet |
Remote-access VPNs commonly use TLS-based clients (what people call 'SSL VPN') as an alternative to IPsec clients — the CCNA scope is recognizing the two deployment shapes and that IPsec is the site-to-site standard.
- Scenario
- A branch office's 30 devices must reach HQ resources over broadband
- Installing/maintaining a client on all 30 devices is impractical — including printers and phones.
- A site-to-site IPsec tunnel between the branch router and HQ headend makes the whole LAN reachable transparently.
- Remote-access VPN would be right for the same office's five traveling users instead.
Site-to-site protects networks; remote-access protects people.
IPsec components
IPsec components (concept level)
| Component | Role |
|---|---|
| IKE (ISAKMP) | Negotiates security associations and keys — UDP 500 |
| ESP | Confidentiality + integrity for the payload (IP protocol 50) |
| AH | Integrity/authentication only (IP protocol 51) — rare in practice |
| Tunnel vs transport mode | Tunnel encrypts+encapsulates the whole packet (VPNs); transport protects payload only |
Verification and mistakes
Verification cues
- Tunnel 'up' shows in SA counters, but a counter increasing alone does not prove the tested flow is protected — verify the interesting-traffic map covers it.
- Plaintext leaks are the silent failure — verify the interesting-traffic ACL actually covers the flows.
- IKE/UDP 500 and ESP/IP-50 must pass every middle device — filtering either breaks the tunnel differently.
Common mistakes
- Assuming VPNs require client software everywhere — site-to-site needs none on hosts.
- Treating IPsec as 'the VPN protocol' — it's a framework; the exam cares about concepts not cipher suites.
- Forgetting that NAT breaks plain ESP — NAT-T encapsulates in UDP 4500 to cross it.
- Believing the tunnel hides everything — metadata (endpoints, timing, sizes) still leaks.
Observation: Site-to-site tunnel 'up', but a capture shows plaintext crossing the WAN.
- Interesting-traffic (crypto) ACL doesn't cover this flow
- With a policy-based crypto map there is no tunnel interface to route through — the interesting-traffic ACL, not a route, decides what gets encrypted (routed VTI tunnels are the alternative)
- Asymmetric policy — one side encrypts, the other doesn't
| Check | Indicates |
|---|---|
| Crypto ACL on both ends (mirror images) | Mismatched interesting traffic leaves flows unprotected. |
| Routing table for the remote subnet | If the route doesn't point at the tunnel, the packet never enters it. |
| Encrypted vs decrypted packet counters | Zero encrypted = traffic isn't entering the SA. |
Correction: Align the crypto ACLs and routing so the flows are captured by the tunnel.
Capture shows ESP, not plaintext; counters increment on both ends.
Related resources
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
- RFC 4301 — Security Architecture for the Internet Protocol — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.