Site-to-Site IPsec VPN — IKEv1 & IKEv2
A site-to-site IPsec VPN creates a cryptographically secure tunnel between two routers across an untrusted network — typically the internet. Traffic from the headquarters LAN destined for the branch LAN is encrypted by the HQ router, traverses the public internet as ciphertext, and is decrypted by the branch router before delivery. To an eavesdropper on the internet, the traffic is unreadable. This is the foundation of every enterprise WAN security model and a core topic in both the CCNA and CCNP Security exams.
IPsec is not a single protocol — it is a framework of three layered negotiation stages. First, the two peers must authenticate each other and agree on how to protect their negotiation channel — this is IKE Phase 1 (ISAKMP). Second, they negotiate the encryption and integrity algorithms for the actual data tunnel — this is IKE Phase 2 (IPsec SA). Finally, data flows through the encrypted tunnel using either ESP (Encapsulating Security Payload — provides encryption and integrity) or AH (Authentication Header — integrity only, no encryption). In practice, ESP in tunnel mode is almost always used.
This lab covers both IKEv1 (the classic method using ISAKMP and crypto maps, widely deployed and still on the CCNA exam) and IKEv2 (the modern standard — simpler, faster, more resilient, required for many modern devices). For VPN security concepts including ESP vs AH and tunnel vs transport mode, see IPsec Basics. For routing traffic into the VPN tunnel, review Static Route Configuration and show ip route. For protecting the router's management plane alongside VPN configuration, see SSH Configuration, AAA & TACACS+ Configuration, and Extended ACL Configuration.
1. IPsec VPN Framework — Core Concepts
IPsec Negotiation — The Three Stages
Stage 1 — IKE Phase 1 (ISAKMP SA)
══════════════════════════════════════════════════════════════════
Purpose: Authenticate the peers. Create a secure, encrypted channel
for Phase 2 negotiation. NOT the data tunnel.
Negotiated: Encryption (AES/3DES), Hash/HMAC (SHA/MD5),
Authentication method (pre-shared key / RSA),
Diffie-Hellman group (key exchange),
SA Lifetime (default 86400 seconds / 24 hours)
Modes: Main Mode — 6 messages, identity protected, standard
Aggressive — 3 messages, faster, identity exposed, less secure
Result: One bidirectional ISAKMP SA between the peers
IKEv1 SA state in IOS: show crypto isakmp sa → QM_IDLE (success)
──────────────────────────────────────────────────────────────────
Stage 2 — IKE Phase 2 (IPsec SA)
══════════════════════════════════════════════════════════════════
Purpose: Negotiate the parameters for the actual DATA tunnel.
Uses the secure channel created in Phase 1.
Negotiated: IPsec protocol (ESP or AH),
Encryption algorithm (AES-256, AES-128, 3DES),
Integrity/HMAC (SHA-256, SHA-1, MD5),
Encapsulation mode (tunnel or transport),
SA Lifetime (default 3600 seconds / 1 hour),
Traffic selectors (which traffic to encrypt — ACL)
Mode: Quick Mode (always — Phase 2 always uses Quick Mode)
Result: TWO unidirectional IPsec SAs (one inbound, one outbound)
IOS verification: show crypto ipsec sa → pkts encaps/decaps counters
──────────────────────────────────────────────────────────────────
Stage 3 — Data Transfer (ESP Tunnel)
══════════════════════════════════════════════════════════════════
Purpose: Encrypt and forward the actual user traffic.
ESP Tunnel Mode packet structure:
┌────────────┬────────────┬──────────┬─────────────────┬─────────┐
│ New IP Hdr │ ESP Header │ Original │ Original │ ESP │
│ (public) │ │ IP Hdr │ Payload │ Trailer │
│ src: R1_WAN│ │(10.1.1.x)│ (user data) │ + Auth │
└────────────┴────────────┴──────────┴─────────────────┴─────────┘
◄──────────── Encrypted ──────────────────────────────────────────►
◄────── Integrity Protected ─────────────►
The original IP packet (private src/dst) is fully encrypted.
The outer IP header (public WAN IPs) routes the packet across internet.
IKEv1 vs IKEv2 — Key Differences
| Aspect | IKEv1 | IKEv2 |
|---|---|---|
| RFC | RFC 2409 (1998) | RFC 7296 (2014) |
| Phase 1 messages | 6 (Main Mode) or 3 (Aggressive) | 4 (always — IKE_SA_INIT + IKE_AUTH) |
| Asymmetric auth | No — both peers use same auth method | Yes — each peer can authenticate differently (e.g., one uses PSK, other uses cert) |
| EAP support | No | Yes — supports EAP for remote access |
| MOBIKE | No — tunnel breaks on IP change | Yes — tunnel survives IP address change (mobile devices) |
| Built-in NAT-T | Extension (RFC 3947) — added later | Native — NAT traversal built in |
| Dead Peer Detection | Extension (RFC 3706) | Native — built into the protocol |
| IOS config approach | crypto isakmp policy + crypto map |
crypto ikev2 proposal + crypto ikev2 profile |
| Cisco IOS support | All versions — universally supported | IOS 15.x+ required on both ends |
ESP vs AH — Which to Use
| Protocol | IP Protocol | Encryption | Integrity | NAT Compatible | Use Case |
|---|---|---|---|---|---|
| ESP | 50 | Yes | Yes | Yes (with NAT-T) | Standard — use for all deployments requiring confidentiality |
| AH | 51 | No | Yes (covers outer IP header too) | No — AH covers the outer IP header so NAT breaks it | Rare — only when encryption is not needed but outer header integrity is required |
Note — Tunnel Mode vs Transport Mode:
Tunnel mode (default and almost always used for site-to-site) encapsulates the entire original IP packet — a new outer IP header is added with the VPN gateway IPs. Transport mode only encrypts the payload and is used between two hosts (not gateways) for end-to-end encryption. Site-to-site VPNs always use tunnel mode.
IOS IPsec Configuration Building Blocks — IKEv1
IKEv1 Configuration Objects and Their Relationships:
crypto isakmp policy [priority] ← Phase 1 parameters
encryption aes 256
hash sha
authentication pre-share
group 14
lifetime 86400
crypto isakmp key [password] address [peer-IP] ← Pre-shared key
crypto ipsec transform-set [name] esp-aes 256 esp-sha-hmac ← Phase 2 algo
ip access-list extended [name] ← "Interesting traffic" — what to encrypt
permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
crypto map [name] [seq] ipsec-isakmp ← Ties everything together
set peer [remote-WAN-IP]
set transform-set [name]
match address [acl-name]
interface [WAN-int] ← Apply the crypto map to the WAN interface
crypto map [name]
2. Lab Topology & Scenario
This lab connects two sites — HQ (using NetsTuts_R1) and Branch (using NetsTuts_R2) — across a simulated internet. Part A configures the tunnel using IKEv1 with pre-shared keys. Part B replaces it with IKEv2 configuration on the same topology. The ISP router (NetsTuts_R3) simulates the public internet and requires no VPN configuration — it simply routes between the two WAN addresses.
HQ Site Internet (R3) Branch Site
───────── ───────────── ────────────
NetsTuts_R1 NetsTuts_R3 NetsTuts_R2
Gi0/0: 10.1.1.1/24 Gi0/0: 203.0.113.1/30 Gi0/0: 10.2.2.1/24
Gi0/1: 203.0.113.2/30 ───┤ ├──── Gi0/1: 198.51.100.2/30
Gi0/1: 198.51.100.1/30
LAN: 10.1.1.0/24 LAN: 10.2.2.0/24
[HQ-Host]──R1═══════════════IPsec Tunnel═══════════════R2──[Branch-Host]
203.0.113.2 ←─── encrypted ───→ 198.51.100.2
VPN Peers:
R1 (HQ) WAN IP: 203.0.113.2
R2 (Branch) WAN IP: 198.51.100.2
Pre-shared Key: NetsTuts@VPN#2026 (same on both peers for IKEv1 PSK)
IKE Phase 1 (ISAKMP):
Encryption: AES-256
Hash: SHA-256
Authentication: Pre-shared key
DH Group: 14 (2048-bit)
Lifetime: 86400 seconds
IKE Phase 2 (IPsec):
Protocol: ESP
Encryption: AES-256
Integrity: SHA-256 HMAC
Mode: Tunnel
Lifetime: 3600 seconds
| Device | Interface | IP Address | Role |
|---|---|---|---|
| NetsTuts_R1 (HQ) | Gi0/0 | 10.1.1.1/24 | HQ LAN gateway |
| NetsTuts_R1 (HQ) | Gi0/1 | 203.0.113.2/30 | HQ WAN / VPN peer address |
| NetsTuts_R2 (Branch) | Gi0/0 | 10.2.2.1/24 | Branch LAN gateway |
| NetsTuts_R2 (Branch) | Gi0/1 | 198.51.100.2/30 | Branch WAN / VPN peer address |
| NetsTuts_R3 (ISP) | Gi0/0 | 203.0.113.1/30 | Simulated internet — routes between WAN IPs |
| NetsTuts_R3 (ISP) | Gi0/1 | 198.51.100.1/30 | Simulated internet — routes between WAN IPs |
3. Step 1 — Configure Interfaces and Baseline Routing
All interfaces and basic routing must be working before any VPN configuration begins. The VPN peers must be able to reach each other's WAN IP via the internet — the IPsec negotiation packets travel this path. If the WAN-to-WAN ping fails, the VPN tunnel will never establish:
NetsTuts_R1 — HQ Router
NetsTuts_R1>en NetsTuts_R1#conf t NetsTuts_R1(config)#interface GigabitEthernet0/0 NetsTuts_R1(config-if)#description HQ-LAN NetsTuts_R1(config-if)#ip address 10.1.1.1 255.255.255.0 NetsTuts_R1(config-if)#no shutdown NetsTuts_R1(config-if)#exit NetsTuts_R1(config)#interface GigabitEthernet0/1 NetsTuts_R1(config-if)#description HQ-WAN-to-Internet NetsTuts_R1(config-if)#ip address 203.0.113.2 255.255.255.252 NetsTuts_R1(config-if)#no shutdown NetsTuts_R1(config-if)#exit ! ── Default route via ISP (simulated internet) ─────────── NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.1 NetsTuts_R1(config)#end
NetsTuts_R2 — Branch Router
NetsTuts_R2>en NetsTuts_R2#conf t NetsTuts_R2(config)#interface GigabitEthernet0/0 NetsTuts_R2(config-if)#description Branch-LAN NetsTuts_R2(config-if)#ip address 10.2.2.1 255.255.255.0 NetsTuts_R2(config-if)#no shutdown NetsTuts_R2(config-if)#exit NetsTuts_R2(config)#interface GigabitEthernet0/1 NetsTuts_R2(config-if)#description Branch-WAN-to-Internet NetsTuts_R2(config-if)#ip address 198.51.100.2 255.255.255.252 NetsTuts_R2(config-if)#no shutdown NetsTuts_R2(config-if)#exit NetsTuts_R2(config)#ip route 0.0.0.0 0.0.0.0 198.51.100.1 NetsTuts_R2(config)#end
NetsTuts_R3 — ISP / Internet Router (no VPN config)
NetsTuts_R3(config)#interface GigabitEthernet0/0 NetsTuts_R3(config-if)#ip address 203.0.113.1 255.255.255.252 NetsTuts_R3(config-if)#no shutdown NetsTuts_R3(config-if)#exit NetsTuts_R3(config)#interface GigabitEthernet0/1 NetsTuts_R3(config-if)#ip address 198.51.100.1 255.255.255.252 NetsTuts_R3(config-if)#no shutdown NetsTuts_R3(config-if)#exit ! ── R3 has directly connected routes to both WAN subnets ─ ! ── No additional routing needed on R3 ───────────────────
Verify WAN Reachability Before VPN Config
! ── From R1 — ping R2's WAN IP ─────────────────────────── NetsTuts_R1#ping 198.51.100.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.51.100.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms ! ── Confirm LAN-to-LAN fails before VPN (no route) ─────── NetsTuts_R1#ping 10.2.2.1 source 10.1.1.1 Sending 5, 100-byte ICMP Echos to 10.2.2.1, timeout is 2 seconds: ..... Success rate is 0 percent (5/5)
The WAN-to-WAN ping confirms IPsec negotiation packets will reach
the remote peer — this is the prerequisite. The LAN-to-LAN failure
is expected — no route exists for the remote LAN, and the VPN tunnel
does not yet exist. After VPN configuration, the LAN-to-LAN ping
will succeed and the traffic will be encrypted in transit.
4. Part A — IKEv1 Site-to-Site VPN Configuration
IKEv1 configuration on Cisco IOS follows a strict four-object sequence: ISAKMP policy (Phase 1), pre-shared key, transform-set (Phase 2), crypto ACL (traffic selector), and crypto map (binds everything together). The crypto map is then applied to the WAN interface to activate the VPN.
Step A1 — Configure IKEv1 on R1 (HQ)
NetsTuts_R1#conf t ! ══ STEP 1: ISAKMP Policy (IKE Phase 1 Parameters) ══════ ! Priority 10 — lower number = higher priority when ! multiple policies exist. Peers negotiate to match one. NetsTuts_R1(config)#crypto isakmp policy 10 NetsTuts_R1(config-isakmp)#encryption aes 256 NetsTuts_R1(config-isakmp)#hash sha256 NetsTuts_R1(config-isakmp)#authentication pre-share NetsTuts_R1(config-isakmp)#group 14 NetsTuts_R1(config-isakmp)#lifetime 86400 NetsTuts_R1(config-isakmp)#exit ! ══ STEP 2: Pre-Shared Key — tied to peer's WAN IP ══════ NetsTuts_R1(config)#crypto isakmp key NetsTuts@VPN#2026 address 198.51.100.2 ! ══ STEP 3: Transform Set (IKE Phase 2 Parameters) ══════ ! Name: TS-AES256 — ESP with AES-256 encryption + SHA-256 HMAC ! Tunnel mode is the default — included for clarity NetsTuts_R1(config)#crypto ipsec transform-set TS-AES256 esp-aes 256 esp-sha256-hmac NetsTuts_R1(cfg-crypto-trans)#mode tunnel NetsTuts_R1(cfg-crypto-trans)#exit ! ══ STEP 4: Crypto ACL — defines "interesting traffic" ══ ! This ACL defines what traffic gets encrypted. ! Mirror image of this ACL must exist on R2. ! Note: This ACL is NOT used for filtering — only for ! identifying traffic to pass through the VPN tunnel. NetsTuts_R1(config)#ip access-list extended VPN-TRAFFIC NetsTuts_R1(config-ext-nacl)#permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 NetsTuts_R1(config-ext-nacl)#exit ! ══ STEP 5: Crypto Map — binds all VPN objects together ═ NetsTuts_R1(config)#crypto map CMAP-SITE2SITE 10 ipsec-isakmp NetsTuts_R1(config-crypto-map)#set peer 198.51.100.2 NetsTuts_R1(config-crypto-map)#set transform-set TS-AES256 NetsTuts_R1(config-crypto-map)#match address VPN-TRAFFIC NetsTuts_R1(config-crypto-map)#set security-association lifetime seconds 3600 NetsTuts_R1(config-crypto-map)#exit ! ══ STEP 6: Apply Crypto Map to WAN Interface ════════════ NetsTuts_R1(config)#interface GigabitEthernet0/1 NetsTuts_R1(config-if)#crypto map CMAP-SITE2SITE NetsTuts_R1(config-if)#exit NetsTuts_R1(config)#end NetsTuts_R1#wr
Each configuration step serves a precise role:
ISAKMP policy — defines Phase 1 parameters. The
priority number (10) determines which policy is preferred when
multiple policies exist — the router with the lower priority number
policy wins if both peers have multiple. Both peers must have at
least one matching policy (same encryption, hash, auth, DH group)
or Phase 1 fails.
Pre-shared key — the authentication secret tied
to the peer's IP address. Must be identical on both peers.
Transform-set — Phase 2 parameters.
esp-aes 256
selects AES-256 for encryption; esp-sha256-hmac selects
SHA-256 for integrity.
Crypto ACL — defines which traffic is "interesting"
(gets encrypted). Must be a mirror image on both peers — R1's source
(10.1.1.0) becomes R2's destination and vice versa.
Crypto map — the central VPN policy object that
references the peer IP, transform-set, and crypto ACL.
Interface application — the crypto map only
activates when applied to a specific interface. Only traffic
entering or leaving that interface is subject to VPN processing.
Step A2 — Configure IKEv1 on R2 (Branch)
NetsTuts_R2#conf t ! ── ISAKMP Policy — identical to R1 ───────────────────── NetsTuts_R2(config)#crypto isakmp policy 10 NetsTuts_R2(config-isakmp)#encryption aes 256 NetsTuts_R2(config-isakmp)#hash sha256 NetsTuts_R2(config-isakmp)#authentication pre-share NetsTuts_R2(config-isakmp)#group 14 NetsTuts_R2(config-isakmp)#lifetime 86400 NetsTuts_R2(config-isakmp)#exit ! ── Pre-shared key — peer is R1's WAN IP ───────────────── NetsTuts_R2(config)#crypto isakmp key NetsTuts@VPN#2026 address 203.0.113.2 ! ── Transform Set — identical to R1 ────────────────────── NetsTuts_R2(config)#crypto ipsec transform-set TS-AES256 esp-aes 256 esp-sha256-hmac NetsTuts_R2(cfg-crypto-trans)#mode tunnel NetsTuts_R2(cfg-crypto-trans)#exit ! ── Crypto ACL — MIRROR IMAGE of R1's ACL ──────────────── ! Source and destination are REVERSED compared to R1 NetsTuts_R2(config)#ip access-list extended VPN-TRAFFIC NetsTuts_R2(config-ext-nacl)#permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 NetsTuts_R2(config-ext-nacl)#exit ! ── Crypto Map ──────────────────────────────────────────── NetsTuts_R2(config)#crypto map CMAP-SITE2SITE 10 ipsec-isakmp NetsTuts_R2(config-crypto-map)#set peer 203.0.113.2 NetsTuts_R2(config-crypto-map)#set transform-set TS-AES256 NetsTuts_R2(config-crypto-map)#match address VPN-TRAFFIC NetsTuts_R2(config-crypto-map)#set security-association lifetime seconds 3600 NetsTuts_R2(config-crypto-map)#exit ! ── Apply to WAN Interface ──────────────────────────────── NetsTuts_R2(config)#interface GigabitEthernet0/1 NetsTuts_R2(config-if)#crypto map CMAP-SITE2SITE NetsTuts_R2(config-if)#exit NetsTuts_R2(config)#end NetsTuts_R2#wr
Two critical mirror-image requirements between R1 and R2:
(1) The pre-shared key is identical (
NetsTuts@VPN#2026)
but the peer address is the other router's WAN IP —
R1 references 198.51.100.2 and R2 references 203.0.113.2.
(2) The crypto ACL is a mirror — R1 permits
traffic FROM 10.1.1.0/24 TO 10.2.2.0/24; R2 permits FROM
10.2.2.0/24 TO 10.1.1.0/24. This mirror requirement is one of the
most common IPsec misconfiguration points — a mismatch causes
Phase 2 to fail even when Phase 1 succeeds.
5. Part B — IKEv2 Site-to-Site VPN Configuration
IKEv2 replaces the ISAKMP policy and crypto map approach with a cleaner object model: IKEv2 Proposal (algorithms), IKEv2 Policy (matches traffic and links to proposal), IKEv2 Keyring (peer keys), and IKEv2 Profile (ties keyring and authentication to an identity). The IPsec transform-set and crypto map are still used for Phase 2 and interface application. To use IKEv2, first remove the IKEv1 configuration:
Remove IKEv1 Config First (on Both Routers)
! ── On R1 — remove IKEv1 objects ───────────────────────── NetsTuts_R1(config)#interface GigabitEthernet0/1 NetsTuts_R1(config-if)#no crypto map CMAP-SITE2SITE NetsTuts_R1(config-if)#exit NetsTuts_R1(config)#no crypto map CMAP-SITE2SITE NetsTuts_R1(config)#no crypto ipsec transform-set TS-AES256 NetsTuts_R1(config)#no crypto isakmp policy 10 NetsTuts_R1(config)#no crypto isakmp key NetsTuts@VPN#2026 address 198.51.100.2 NetsTuts_R1(config)#no ip access-list extended VPN-TRAFFIC
Step B1 — Configure IKEv2 on R1 (HQ)
NetsTuts_R1#conf t ! ══ IKEv2 PROPOSAL — Phase 1 algorithms ═════════════════ NetsTuts_R1(config)#crypto ikev2 proposal IKEv2-PROP NetsTuts_R1(config-ikev2-proposal)#encryption aes-cbc-256 NetsTuts_R1(config-ikev2-proposal)#integrity sha256 NetsTuts_R1(config-ikev2-proposal)#group 14 NetsTuts_R1(config-ikev2-proposal)#exit ! ══ IKEv2 POLICY — matches all traffic, uses proposal ════ NetsTuts_R1(config)#crypto ikev2 policy IKEv2-POL NetsTuts_R1(config-ikev2-policy)#proposal IKEv2-PROP NetsTuts_R1(config-ikev2-policy)#exit ! ══ IKEv2 KEYRING — pre-shared keys per peer ════════════ NetsTuts_R1(config)#crypto ikev2 keyring IKEv2-KEYS NetsTuts_R1(config-ikev2-keyring)#peer BRANCH NetsTuts_R1(config-ikev2-keyring-peer)#address 198.51.100.2 NetsTuts_R1(config-ikev2-keyring-peer)#pre-shared-key NetsTuts@VPN#2026 NetsTuts_R1(config-ikev2-keyring-peer)#exit NetsTuts_R1(config-ikev2-keyring)#exit ! ══ IKEv2 PROFILE — ties identity, auth, and keyring ════ NetsTuts_R1(config)#crypto ikev2 profile IKEv2-PROFILE NetsTuts_R1(config-ikev2-profile)#match identity remote address 198.51.100.2 255.255.255.255 NetsTuts_R1(config-ikev2-profile)#authentication remote pre-share NetsTuts_R1(config-ikev2-profile)#authentication local pre-share NetsTuts_R1(config-ikev2-profile)#keyring local IKEv2-KEYS NetsTuts_R1(config-ikev2-profile)#lifetime 86400 NetsTuts_R1(config-ikev2-profile)#dpd 30 5 periodic NetsTuts_R1(config-ikev2-profile)#exit ! ══ TRANSFORM SET — Phase 2 (same as IKEv1) ════════════ NetsTuts_R1(config)#crypto ipsec transform-set TS-AES256 esp-aes 256 esp-sha256-hmac NetsTuts_R1(cfg-crypto-trans)#mode tunnel NetsTuts_R1(cfg-crypto-trans)#exit ! ══ CRYPTO ACL — same as IKEv1 ══════════════════════════ NetsTuts_R1(config)#ip access-list extended VPN-TRAFFIC NetsTuts_R1(config-ext-nacl)#permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 NetsTuts_R1(config-ext-nacl)#exit ! ══ CRYPTO MAP — reference IKEv2 profile ════════════════ NetsTuts_R1(config)#crypto map CMAP-SITE2SITE 10 ipsec-isakmp NetsTuts_R1(config-crypto-map)#set peer 198.51.100.2 NetsTuts_R1(config-crypto-map)#set transform-set TS-AES256 NetsTuts_R1(config-crypto-map)#set ikev2-profile IKEv2-PROFILE NetsTuts_R1(config-crypto-map)#match address VPN-TRAFFIC NetsTuts_R1(config-crypto-map)#exit ! ══ Apply to WAN Interface ════════════════════════════════ NetsTuts_R1(config)#interface GigabitEthernet0/1 NetsTuts_R1(config-if)#crypto map CMAP-SITE2SITE NetsTuts_R1(config-if)#exit NetsTuts_R1(config)#end NetsTuts_R1#wr
Key IKEv2-specific elements:
IKEv2 Proposal — replaces the ISAKMP policy.
Defines the cryptographic algorithms. Multiple proposals can be
listed in one policy for algorithm flexibility.
IKEv2 Keyring — a named container for one or more
peer pre-shared keys. Each peer gets its own entry within the keyring,
making multi-peer management cleaner than IKEv1's per-address key
commands.
IKEv2 Profile — the central IKEv2 object. The
match identity remote address command defines which
peer this profile applies to. authentication remote pre-share
and authentication local pre-share — IKEv2 uniquely
specifies authentication for each direction independently.
dpd 30 5 periodic — Dead Peer Detection:
send a DPD keepalive every 30 seconds, retry 5 times before declaring
the peer dead. This is native to IKEv2 (no extension needed).
The crypto map gains a set ikev2-profile line — this
is what tells IOS to use IKEv2 instead of IKEv1 for this tunnel.
Step B2 — Configure IKEv2 on R2 (Branch)
NetsTuts_R2#conf t NetsTuts_R2(config)#crypto ikev2 proposal IKEv2-PROP NetsTuts_R2(config-ikev2-proposal)#encryption aes-cbc-256 NetsTuts_R2(config-ikev2-proposal)#integrity sha256 NetsTuts_R2(config-ikev2-proposal)#group 14 NetsTuts_R2(config-ikev2-proposal)#exit NetsTuts_R2(config)#crypto ikev2 policy IKEv2-POL NetsTuts_R2(config-ikev2-policy)#proposal IKEv2-PROP NetsTuts_R2(config-ikev2-policy)#exit NetsTuts_R2(config)#crypto ikev2 keyring IKEv2-KEYS NetsTuts_R2(config-ikev2-keyring)#peer HQ NetsTuts_R2(config-ikev2-keyring-peer)#address 203.0.113.2 NetsTuts_R2(config-ikev2-keyring-peer)#pre-shared-key NetsTuts@VPN#2026 NetsTuts_R2(config-ikev2-keyring-peer)#exit NetsTuts_R2(config-ikev2-keyring)#exit NetsTuts_R2(config)#crypto ikev2 profile IKEv2-PROFILE NetsTuts_R2(config-ikev2-profile)#match identity remote address 203.0.113.2 255.255.255.255 NetsTuts_R2(config-ikev2-profile)#authentication remote pre-share NetsTuts_R2(config-ikev2-profile)#authentication local pre-share NetsTuts_R2(config-ikev2-profile)#keyring local IKEv2-KEYS NetsTuts_R2(config-ikev2-profile)#lifetime 86400 NetsTuts_R2(config-ikev2-profile)#dpd 30 5 periodic NetsTuts_R2(config-ikev2-profile)#exit NetsTuts_R2(config)#crypto ipsec transform-set TS-AES256 esp-aes 256 esp-sha256-hmac NetsTuts_R2(cfg-crypto-trans)#mode tunnel NetsTuts_R2(cfg-crypto-trans)#exit ! ── Mirror image ACL ────────────────────────────────────── NetsTuts_R2(config)#ip access-list extended VPN-TRAFFIC NetsTuts_R2(config-ext-nacl)#permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 NetsTuts_R2(config-ext-nacl)#exit NetsTuts_R2(config)#crypto map CMAP-SITE2SITE 10 ipsec-isakmp NetsTuts_R2(config-crypto-map)#set peer 203.0.113.2 NetsTuts_R2(config-crypto-map)#set transform-set TS-AES256 NetsTuts_R2(config-crypto-map)#set ikev2-profile IKEv2-PROFILE NetsTuts_R2(config-crypto-map)#match address VPN-TRAFFIC NetsTuts_R2(config-crypto-map)#exit NetsTuts_R2(config)#interface GigabitEthernet0/1 NetsTuts_R2(config-if)#crypto map CMAP-SITE2SITE NetsTuts_R2(config-if)#exit NetsTuts_R2(config)#end NetsTuts_R2#wr
6. Step C — Trigger the VPN Tunnel
IPsec tunnels on Cisco IOS are demand-triggered by default — they are not established until interesting traffic actually hits the crypto map. A ping from one LAN to the other is the standard method to initiate the tunnel. The first few pings may fail as the IKE negotiation completes:
! ── Trigger tunnel from R1 LAN to R2 LAN ───────────────── ! ── Source the ping from the LAN interface so it matches ! ── the crypto ACL (10.1.1.0 → 10.2.2.0) ──────────────── NetsTuts_R1#ping 10.2.2.1 source GigabitEthernet0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.2.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 3/4/6 ms
The first ping (shown as ".") failed — this is expected and normal.
The IKE Phase 1 and Phase 2 negotiation takes 1–2 seconds to
complete. During that time, the triggering packet is dropped (it
cannot be buffered while waiting for the SA). The subsequent four
pings ("!!!!") succeed through the established tunnel. If all five
pings fail, the tunnel negotiation is also failing — proceed to
verification and troubleshooting. Always source the ping from the
LAN interface — if sourced from the WAN interface (203.0.113.2),
the traffic does not match the crypto ACL and the tunnel is not
triggered.
Note — Tunnel Establishment Direction: By default,
the router that sends "interesting traffic" first initiates the IKE
negotiation (the initiator). The other peer
responds (the responder). Either side can initiate.
To force a tunnel to establish without waiting for traffic, use
crypto map CMAP-SITE2SITE local-address GigabitEthernet0/1
or manually clear and reinitiate with clear crypto session.
7. Step D — Verification
show crypto isakmp sa — Phase 1 Status (IKEv1)
NetsTuts_R1#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 198.51.100.2 203.0.113.2 QM_IDLE 1001 ACTIVE IPv6 Crypto ISAKMP SA
QM_IDLE is the healthy Phase 1 state — it means
the ISAKMP SA is fully established (both peers authenticated and
agreed on Phase 1 parameters) and is currently idle (not mid-negotiation).
The "QM" stands for Quick Mode — which is Phase 2. The SA is ready
for Phase 2 negotiation whenever interesting traffic arrives.
dst / src = the WAN IPs of the VPN peers.
Status ACTIVE = the SA is in use.
Common failure states: MM_NO_STATE (Phase 1 never
completed — policy mismatch or peer unreachable),
MM_KEY_EXCH (stuck during DH key exchange),
AM_ACTIVE (aggressive mode).
show crypto ikev2 sa — Phase 1 Status (IKEv2)
NetsTuts_R1#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 203.0.113.2/500 198.51.100.2/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: HMAC-SHA256, Hash: SHA256,
DH Grp: 14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/423 sec
Status: READY is the IKEv2 equivalent of
QM_IDLE — the IKEv2 SA is established and ready.
The detailed line confirms the negotiated parameters:
AES-CBC keysize 256 (encryption),
HMAC-SHA256 (PRF and integrity),
DH Grp 14 (key exchange),
Auth PSK (pre-shared key authentication for both
directions).
Life/Active Time: 86400/423 sec — the SA lifetime
is 86400 seconds (24 hours) and it has been active for 423 seconds.
show crypto ipsec sa — Phase 2 Status and Traffic Counters
NetsTuts_R1#show crypto ipsec sa
interface: GigabitEthernet0/1
Crypto map tag: CMAP-SITE2SITE, local addr 203.0.113.2
protected vrf: (none)
local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
current_peer 198.51.100.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 87, #pkts encrypt: 87, #pkts digest: 87
#pkts decaps: 84, #pkts decrypt: 84, #pkts verify: 84
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 203.0.113.2, remote crypto endpt.: 198.51.100.2
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0xAB34CD12(2872237330)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x12CD34AB(315014315)
transform: esp-aes-256 esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: 1, sibling_flags 80000046, crypto map: CMAP-SITE2SITE
sa timing: remaining key lifetime (k/sec): (4607997/3177)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound esp sas:
spi: 0xAB34CD12(2872237330)
transform: esp-aes-256 esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: 2, sibling_flags 80000046, crypto map: CMAP-SITE2SITE
sa timing: remaining key lifetime (k/sec): (4607997/3177)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
This is the most detailed VPN verification command — every field
tells a story.
local ident / remote ident — the traffic selectors
(from the crypto ACL). Confirm these match what was configured.
#pkts encaps / encrypt — packets that were
encrypted and sent through the tunnel. If this counter is not
incrementing, traffic from the HQ LAN is not being matched by the
crypto ACL or the tunnel is not established.
#pkts decaps / decrypt — packets received from the
remote peer and decrypted. If encaps is incrementing but decaps is
not, the remote side is not sending traffic back.
inbound / outbound esp sas — two separate
unidirectional SAs (one for each direction). Each has its own
SPI (Security Parameter Index — a 32-bit value that identifies
which SA should decrypt an incoming packet).
remaining key lifetime (k/sec) — remaining
lifetime in kilobytes and seconds. The SA will be renegotiated
before either limit expires.
transform: esp-aes-256 esp-sha256-hmac — confirms
the negotiated Phase 2 algorithms.
show crypto ipsec sa — After Additional Traffic
! ── Generate more traffic, then re-check packet counters ─
NetsTuts_R1#ping 10.2.2.1 source 10.1.1.1 repeat 100
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/3/7 ms
NetsTuts_R1#show crypto ipsec sa | include pkts
#pkts encaps: 187, #pkts encrypt: 187, #pkts digest: 187
#pkts decaps: 184, #pkts decrypt: 184, #pkts verify: 184
Incrementing
pkts encaps and pkts decaps
counters confirm active two-way encrypted traffic through the tunnel.
This is the definitive proof the VPN is working — not just
established, but actively encrypting and decrypting real traffic.
100 pings with 0% loss confirms stable tunnel operation.
show crypto map — Review Full Crypto Map Config
NetsTuts_R1#show crypto map
Crypto Map IPv4 "CMAP-SITE2SITE" 10 ipsec-isakmp
Peer = 198.51.100.2
IKEv2 Profile: IKEv2-PROFILE
Extended IP access list VPN-TRAFFIC
access-list VPN-TRAFFIC permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
Current peer: 198.51.100.2
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Mixed-mode : Disabled
Transform sets={
TS-AES256: { esp-aes 256 esp-sha256-hmac } ,
}
Interfaces using crypto map CMAP-SITE2SITE:
GigabitEthernet0/1
Verification Command Reference
| Command | What It Shows | Healthy Indicator |
|---|---|---|
show crypto isakmp sa |
IKEv1 Phase 1 SA — peer IPs, state, connection ID, status | State = QM_IDLE, Status = ACTIVE |
show crypto ikev2 sa |
IKEv2 Phase 1 SA — peer IPs, negotiated algorithms, SA lifetime/age | Status = READY |
show crypto ipsec sa |
Phase 2 SA — traffic selectors, encaps/decaps counters, SPI values, algorithm, SA lifetime | Incrementing pkts encaps and pkts decaps, Status = ACTIVE |
show crypto ipsec sa | include pkts |
Filtered view — just the packet counters from all Phase 2 SAs | Counters incrementing on both encaps and decaps |
show crypto map |
Full crypto map configuration — peer, transform-set, ACL, IKEv2 profile, applied interfaces | Correct peer IP, correct ACL, correct transform-set, correct interface listed |
show crypto isakmp policy |
All configured ISAKMP policies — encryption, hash, auth, DH group, lifetime | Policy with matching parameters exists for the peer |
show crypto ikev2 proposal |
IKEv2 proposals — encryption, integrity, DH group | Proposal with parameters matching the remote peer exists |
show crypto session |
High-level summary — all active crypto sessions, peer, status, uptime | Status = UP-ACTIVE |
show crypto engine connections active |
Hardware/software crypto engine — all active connections and packet counters | Two entries per tunnel (inbound + outbound) with incrementing packet counts |
debug crypto isakmp |
Live IKE Phase 1 negotiation messages — shows exactly where negotiation fails | Look for "ISAKMP (0): SA is doing pre-shared key authen" then "ISAKMP: Sending NOTIFY" or success messages. Always undebug all after |
8. Troubleshooting Site-to-Site IPsec VPN
| Problem | Symptom | Cause | Fix |
|---|---|---|---|
| Phase 1 never establishes | show crypto isakmp sa shows no entries or state stays MM_NO_STATE. LAN-to-LAN pings fail completely |
Most common: (1) peer WAN IPs not reachable — no route between peers, (2) ISAKMP policy mismatch — one or more Phase 1 parameters differ between peers (encryption, hash, DH group), (3) pre-shared key mismatch — keys are different on the two peers (including case sensitivity), (4) firewall blocking UDP 500 (IKE) between peers | Verify WAN reachability first: ping [peer-WAN-IP]. Compare ISAKMP policies: show crypto isakmp policy on both peers — all parameters must match. Verify keys match (note: keys are case-sensitive and whitespace-sensitive). Use debug crypto isakmp to see the exact failure point in negotiation |
| Phase 1 up but Phase 2 fails | show crypto isakmp sa shows QM_IDLE (Phase 1 OK) but show crypto ipsec sa shows zero encaps/decaps with no inbound/outbound SAs listed |
Phase 2 mismatch — the transform-set parameters differ between peers (different encryption or integrity algorithm), or the crypto ACLs are not mirror images (traffic selectors do not match). Phase 2 uses the Phase 1 channel to negotiate, so Phase 1 can succeed while Phase 2 fails | Compare transform-sets: show crypto ipsec transform-set on both peers. Compare crypto ACLs: show ip access-list VPN-TRAFFIC on both peers — R1's source must be R2's destination and vice versa. Use debug crypto ipsec to see the Phase 2 failure message |
| Tunnel established but one-way traffic only | show crypto ipsec sa shows pkts encaps incrementing but pkts decaps stays at zero (or vice versa). Pings from one side succeed but not the other |
Asymmetric routing issue — the return traffic from the remote LAN is not being routed back through the same VPN tunnel, or the remote router's crypto ACL or transform-set has an error causing it to fail to decrypt | On the remote peer, check show crypto ipsec sa — if its pkts encaps is zero, it is not encrypting return traffic. Check the remote crypto ACL to confirm it matches return traffic. Also check that the remote router has a route back to the initiating LAN (through the tunnel or via the VPN) |
| Traffic not being encrypted (bypasses tunnel) | The LAN-to-LAN ping works but packets are not encrypted — Wireshark on the WAN shows plaintext. show crypto ipsec sa shows zero encaps despite successful pings |
The ping is not sourced from an address that matches the crypto ACL — traffic is routing around the VPN. Most common when pinging from the WAN interface address instead of the LAN address, or when the crypto map is not applied to the correct interface | Always source test pings from the LAN interface: ping [target] source [LAN-int]. Verify the crypto map is applied to the WAN interface: show crypto map — check "Interfaces using crypto map". Verify the crypto ACL matches the actual source and destination of the traffic |
| Tunnel drops after SA lifetime expires | VPN works initially then drops after ~1 hour. show crypto ipsec sa shows the SA has been removed. Re-triggers after new traffic but with downtime |
SA lifetime mismatch — one peer is configured with a shorter lifetime. When the shorter lifetime expires, that peer tears down the SA. If interesting traffic is not present to trigger renegotiation before expiry, the tunnel drops. Also occurs if PFS is enabled on one side but not the other | Configure identical SA lifetimes on both peers in the crypto map: set security-association lifetime seconds 3600. Ensure PFS configuration matches — if one peer has set pfs group14, the other must too. Consider using set security-association idle-time to keep tunnels alive between traffic bursts |
| IKEv2 tunnel not establishing (IKEv1 worked) | After migrating to IKEv2, show crypto ikev2 sa shows no entries. The tunnel never comes up |
Common IKEv2-specific issues: (1) set ikev2-profile missing from the crypto map — IOS reverts to IKEv1, (2) IKEv2 profile's match identity remote address does not match the peer's actual source IP, (3) keyring not referenced in the profile (keyring local missing), (4) one peer is still using IKEv1 — both must use IKEv2 |
Verify the crypto map has set ikev2-profile [name]: show crypto map. Confirm the IKEv2 profile matches the peer IP: show crypto ikev2 profile. Confirm the keyring is associated: show crypto ikev2 keyring. Use debug crypto ikev2 to trace the IKEv2 exchange and identify the exact failure point |
Key Points & Exam Tips
- IPsec VPN negotiation has two phases: IKE Phase 1 (ISAKMP SA — authenticates peers, creates secure channel for negotiation, produces one bidirectional SA) and IKE Phase 2 (IPsec SA — negotiates data encryption parameters, produces two unidirectional SAs — one inbound, one outbound). Phase 1 must succeed before Phase 2 begins.
- The IKEv1 ISAKMP policy defines Phase 1 parameters: encryption (AES-256), hash (SHA-256), authentication (pre-share), DH group (14), and lifetime. Both peers must have at least one policy with matching parameters — if no policy matches, Phase 1 fails with MM_NO_STATE.
- The transform-set defines Phase 2 parameters: IPsec protocol (ESP or AH) and encryption/integrity algorithms. The
mode tunnelcommand specifies tunnel mode (default for site-to-site). Transform-set names are local — they do not need to match between peers, only the algorithms must match. - The crypto ACL (interesting traffic ACL) defines what traffic gets encrypted. It must be a mirror image on both peers — R1's source becomes R2's destination. A mismatch here causes Phase 2 to fail even when Phase 1 is QM_IDLE. This is the most common Phase 2 failure cause. See ACL Overview for the ACL syntax that underpins crypto ACLs.
- The crypto map binds peer IP, transform-set, and crypto ACL into one policy. It must be applied to the WAN interface (
crypto map [name]under the interface) — only traffic passing through that interface is subject to VPN processing. Forgetting the interface application is a common mistake. - IPsec tunnels are demand-triggered — they do not establish until interesting traffic hits the crypto map. The first packet that triggers the tunnel is dropped during negotiation. Always source test pings from the LAN interface (
ping [target] source [LAN-int]) so the traffic matches the crypto ACL. show crypto isakmp sa— Phase 1 health. Healthy state = QM_IDLE.show crypto ipsec sa— Phase 2 health. Look for incrementing pkts encaps and pkts decaps counters. Zero counters mean the tunnel is established but no traffic is flowing through it.- IKEv2 uses a cleaner object model: proposal (algorithms), policy (matches traffic to proposal), keyring (per-peer keys), and profile (ties authentication and keyring to a peer identity). The crypto map gains a
set ikev2-profilecommand — without it, IOS uses IKEv1. - Always use ESP in tunnel mode for site-to-site VPNs. AH provides no encryption and is incompatible with NAT. Transport mode is for host-to-host encryption and should not be used between gateways. ESP + tunnel mode + AES-256 + SHA-256 is the recommended modern configuration.
- On the CCNA exam: know the IKEv1 four-object sequence (ISAKMP policy → pre-shared key → transform-set → crypto map → interface application), the difference between Phase 1 (ISAKMP, QM_IDLE) and Phase 2 (IPsec, pkts encaps/decaps), why the crypto ACL must be a mirror image, and how to read
show crypto isakmp saandshow crypto ipsec saoutput.
Next Steps: With a working site-to-site IPsec VPN,
the natural extensions are adding redundancy and scalability.
For WAN failover — automatically switching between primary and backup
VPN paths — combine IP SLA probing with tracked static routes as
covered in
IP SLA Configuration & Tracking.
For hub-and-spoke VPN topologies that scale to many branch sites
without full-mesh tunnels, see
DMVPN Configuration.
For understanding the IPsec protocol fundamentals (ESP vs AH, tunnel
vs transport, Security Associations in depth) see
IPsec Basics.
For securing the router management plane — essential on any
internet-connected router — see
SSH Configuration,
Login Security & Brute-Force Protection,
and Extended ACL Configuration.
For monitoring VPN events and alerting on tunnel failures, see
Syslog Configuration and
SNMP Configuration.