Mental model
Two offices, one in Connecticut, one in Pakistan. Both have private 10.x.x.x networks. The CT office needs to reach the PK office’s file server.
Options:
- Dedicated leased line — works, expensive (thousands per month), takes weeks to provision.
- VPN over the public internet — works, cheap (internet bandwidth you already pay for), provisioning is hours.
A VPN does what the leased line does, except the bits ride through the public internet inside an encrypted tunnel. To the public, the packets look like opaque garbage between two specific public IPs. To the office routers, the inner traffic is private and looks like a directly connected network.
That’s the entire concept. The rest is protocol mechanics.
Two flavors of VPN
| Site-to-Site IPsec | Remote-Access SSL/TLS | |
|---|---|---|
| What’s connected | LAN ↔ LAN | One user → LAN |
| Always-on? | Yes — persistent tunnel | No — user dials in on demand |
| Encryption | IPsec (IKE + ESP) | TLS (same as HTTPS) |
| Client software | Just the router, no per-user client | VPN client app or browser portal |
| Authentication | Pre-shared key or certificates | Username/password, MFA, certs |
| Typical use | Connect branch offices, AWS to on-prem | Work-from-home, contractor access |
| Standard ports | UDP 500 (IKE), UDP 4500 (NAT-T), proto 50 (ESP) | TCP 443 (looks like HTTPS) |
For CCNA, focus on the conceptual difference and the high-level IPsec phases. Deep IPsec config is a CCNP / Security topic.
Site-to-site IPsec — high-level flow
Phase 1 (IKE Phase 1): peers authenticate to each other and build a secure control channel
Phase 2 (IKE Phase 2): peers negotiate the parameters of the actual data tunnel
Data: user packets ride the tunnel, encapsulated in ESP
Phase 1 — establish trust
Two routers want to build a VPN tunnel between them. First they prove they are who they say. Two methods:
- Pre-shared key (PSK) — both routers configured with the same secret string. Simple, works for small deployments.
- Certificates — each router has a cert signed by a trusted CA. Scales to thousands of peers.
PSK is fine for 2 sites. For 50+ sites, use certs.
Phase 2 — negotiate the data tunnel
Peers agree on:
- Encryption algorithm (AES-256 is the default in 2026)
- Integrity / hashing (SHA-256+)
- Lifetime (how long before keys rotate, often 1 hour)
- Interesting traffic (which subnets get tunneled — defined by ACL)
Once Phase 2 completes, the tunnel is up. Packets matching the “interesting traffic” ACL get encrypted with ESP and sent across.
Data — ESP
ESP (Encapsulating Security Payload, IP protocol 50) wraps each packet:
Original packet: [ IP hdr (10.1.0.5 → 10.2.0.10) ][ TCP payload ]
After ESP encapsulation: [ outer IP (R-A pub → R-B pub) ][ ESP ][ encrypted payload ]
The outer IPs are the routers’ public IPs. The inner private IPs are invisible to anyone watching the public internet. ESP also includes a HMAC so any tampering is detected.
Remote-access SSL/TLS — the simpler cousin
User opens a VPN client (AnyConnect, OpenVPN, WireGuard, Tailscale). Authenticates with username + password (+ MFA). Gets a virtual IP on the corporate LAN. From the OS’s perspective, there’s a new network interface that routes selected traffic over an encrypted TLS connection to the VPN concentrator.
Because TLS rides over TCP/443, SSL VPNs work through almost any firewall — they look identical to HTTPS browsing. That’s their main advantage over IPsec, which is often blocked.
WireGuard and Tailscale (modern entrants) are technically not “SSL VPNs” but architecturally serve the same use case: per-user, on-demand VPN access.
Commands — minimal IPsec site-to-site (Cisco IOS)
! Phase 1 policy
R1(config)# crypto isakmp policy 10
R1(config-isakmp)# encr aes
R1(config-isakmp)# hash sha256
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 14
R1(config-isakmp)# lifetime 86400
R1(config)# crypto isakmp key supersecret123 address 203.0.113.50
! Phase 2 transform-set
R1(config)# crypto ipsec transform-set TS-AES esp-aes 256 esp-sha256-hmac
R1(cfg-crypto-trans)# mode tunnel
! Interesting traffic
R1(config)# access-list 110 permit ip 10.1.0.0 0.0.0.255 10.2.0.0 0.0.0.255
! Crypto map ties it all together
R1(config)# crypto map MYMAP 10 ipsec-isakmp
R1(config-crypto-map)# set peer 203.0.113.50
R1(config-crypto-map)# set transform-set TS-AES
R1(config-crypto-map)# match address 110
! Apply to the WAN interface
R1(config)# interface GigabitEthernet0/1
R1(config-if)# crypto map MYMAP
Mirror the config on R2 (swap subnets and peer IP).
Verification
R1# show crypto isakmp sa ! Phase 1 state
R1# show crypto ipsec sa ! Phase 2 state + packet counters
R1# show crypto session
Healthy tunnel: ISAKMP shows QM_IDLE (Phase 1 complete, idle waiting for traffic). IPsec SA shows packet/byte counters incrementing when traffic flows.
Common mistakes
-
Mismatched parameters between peers. Phase 1 and Phase 2 parameters must match exactly — encryption, hash, DH group, lifetime, transform-set. One mismatch and the tunnel fails to form, often with vague error messages.
debug crypto isakmpreveals the exact mismatch. -
Asymmetric interesting traffic ACLs. R1’s ACL says permit
10.1/24 → 10.2/24. R2’s ACL should mirror: permit10.2/24 → 10.1/24. If they don’t mirror, Phase 2 negotiation fails. -
NAT between peers without NAT-T. IPsec ESP can’t survive NAT (the integrity check fails). NAT Traversal (NAT-T) auto-detects NAT and switches to UDP 4500 encapsulation. Modern IOS does this automatically; older configs may need explicit enable.
-
Routing inside the tunnel. A site-to-site tunnel passes packets but doesn’t route them — you might still need static or dynamic routes pointing to the tunnel destinations.
-
Using DES or 3DES in 2026. Both are broken. Use AES-256 + SHA-256+ + DH group 14+.
-
Forgetting MTU. ESP adds ~60 bytes per packet. If your underlying MTU is 1500, the inner packet can only be ~1440. Misconfigured systems fragment, drop, or just stop working with no clear error. Set the inner MTU appropriately or enable PMTUD.
Lab to try tonight
Use two Cisco routers in CML or any IPsec-capable simulator.
- Configure both routers with public-IP-style interfaces (use 198.51.100.x and 203.0.113.x).
- Configure private LANs behind each (10.1.0.0/24 and 10.2.0.0/24).
- Without a VPN, the LANs can’t ping each other across the public internet.
- Configure the IPsec site-to-site tunnel using the commands above (mirror on the other side).
- Ping from LAN-A to LAN-B. Should work.
show crypto ipsec sa— packets should be increasing in encrypted/decrypted counts.- Wireshark on the WAN side: confirm packets between the public IPs are ESP (proto 50), no inner addressing visible.
- Bonus: configure GRE-over-IPsec instead — supports multicast, so OSPF can run inside the tunnel.
Cheat strip
| Concept | Plain English |
|---|---|
| VPN | Encrypted tunnel for private traffic over public network |
| Site-to-site | LAN ↔ LAN, persistent. IPsec. |
| Remote-access | One user → LAN, on-demand. SSL/TLS. |
| IKE Phase 1 | Establish trust + secure control channel |
| IKE Phase 2 | Negotiate the actual data tunnel |
| ESP (proto 50) | Encapsulated, encrypted user data |
| NAT-T | UDP 4500 — IPsec across NAT |
| PSK | Pre-shared key. Simple. Use for 2 sites. |
| Certs | Scales to many sites |
| AES-256 + SHA-256 | Sane modern defaults |
| MTU | Tunnel adds ~60 bytes — plan inner MTU accordingly |