IPsec VPN Taxonomy

Objective

In this lesson you will classify Cisco IPsec VPN types — tunnel-less, site-to-site, any-to-any (GETVPN), remote access, and overlay — and see representative configurations for the two common legacy styles (crypto map) and the tunnel-interface styles (static VTI and dynamic VTI / virtual-template). This matters in production because choosing the correct VPN type determines scalability, routing behavior, NAT/DHCP compatibility, and how you integrate security and routing in a WAN or data-center deployment. Real-world scenario: a branch office (Spoke) with network 10.20.10.0/24 must securely reach multiple DC networks (10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24) through a Hub firewall/router while supporting DHCP/WAN redundancy and future migration to tunnel interfaces.

Tip: Think of the VPN taxonomy as “how you package encrypted traffic.” Like choosing a shipping container — do you pack individual boxes (crypto ACLs), use a virtual tunnel (VTI), or adopt a freight-truck fleet with central key management (GETVPN)? Each choice affects flexibility and operational complexity.

Topology & Device Table

ASCII topology (showing exact IPs on each interface)

Device Table

Device	Interface	IP Address	Subnet Mask	Role
Hub	GigabitEthernet0/0	172.17.1.1	255.255.255.0	Outside (peer for crypto map)
Hub	Loopback1	10.0.0.1	255.255.255.255	Tunnel/VTI source (ip unnumbered)
Hub	Tunnel1	10.0.0.1	(ip unnumbered Loopback1)	Static VTI endpoint
Spoke	GigabitEthernet0/0	172.16.1.1	255.255.255.0	Outside (peer for crypto map)
Spoke	LAN	10.20.10.0/24	255.255.255.0	Branch network protected by VPN
DC	Loopback1	10.0.0.2	255.255.255.255	Tunnel/VTI destination
DC	DC LANs	10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24	255.255.255.0	Datacenter networks

Key Concepts (theory + practical implications)

• Tunnel-less (IPsec without tunnel interfaces): uses a crypto map bound to a physical interface and a crypto ACL (traffic selector) to determine what traffic is encrypted. Practical implication: simple for point-to-point encryption of specific subnets, but fragile when ACLs must be synchronized and when dynamic IPs/NAT/DHCP are in use. In production this is common for small site-to-site links where topology is static.

• Site-to-site (crypto map or VTI): site-to-site can be implemented with crypto maps (per-interface policies) or with Virtual Tunnel Interfaces (VTI). VTIs present an interface with an IP address so routing protocols and multicast can be handled differently (note: on ASA/FTD VTI historically had limitations including no GRE for some platforms). In production, VTIs simplify route-based VPN designs and integrate cleanly with dynamic routing.

• Any-to-any (GETVPN / any-to-any encryption): referred to in the taxonomy as any-to-any or GETVPN-style — this is a different approach supporting many-to-many encrypted connectivity with centralized key management. Use case: large campuses or data center clusters where tunnels must be established between many sites without pairwise configuration. (Reference: GETVPN is listed under "any-to-any" in the materials.)

• Remote access: supports individual user devices (road warriors) connecting into the network. Uses different authentication and distribution mechanisms. Remote access often requires additional client components and different keying/identity handling.

• Overlay (Tunnel Interface / SD-WAN overlay): uses encapsulation (tunnel interfaces) to interconnect an overlay network on top of an underlay. The Tunnel Interface is the bridge between overlay and underlay and is commonly used for SD-WAN and FTD/ASA deployments. In production overlays are used when you want a separate logical topology for routing/policy, decoupled from the physical underlay.

Protocol behavior notes:

• Crypto map (classic) is ACL-driven: traffic must match the crypto ACL to be "interesting" and initiate negotiation.
• Dynamic crypto map accepts any traffic selectors from an authenticated peer (less restrictive) but can be operationally risky.
• VTIs are "up" independent of interesting traffic; they allow route-based encryption and typically simplify routing and failover behavior.
• IKE identity is essential: using device or per-tunnel local identities (IP, hostname, cert DN) improves behavior when interfaces are DHCP-assigned or behind NAT.

Analogy: Think of crypto maps as a keyed door that only opens for a specific list (ACL) of boxes; VTIs are a tunnel road where any approved traffic can be routed without checking a per-packet list.

Step-by-step configuration

We will demonstrate representative configurations from the reference to illustrate how each VPN type is expressed on Cisco devices. Every step includes commands, what they do, why they matter, and verification.

Step 1: Configure a legacy crypto map site-to-site (IKEv1 example)

What we are doing: Create a classical crypto-map site-to-site VPN using a crypto ACL to define the traffic selectors. This demonstrates the tunnel-less (crypto-map) style that is ACL-driven and common in older deployments.

hostname Hub
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
!
crypto isakmp key Lab123 address 172.16.1.1
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac mode tunnel
!
access-list 110 permit ip 10.20.10.0 255.255.255.0 10.10.10.0 255.255.255.0
access-list 110 permit ip 10.20.10.0 255.255.255.0 10.10.20.0 255.255.255.0
access-list 110 permit ip 10.20.10.0 255.255.255.0 10.10.30.0 255.255.255.0
!
crypto map outside_map 10 ipsec-isakmp
 set peer 172.16.1.1
 set transform-set TS
 match address 110
!
interface GigabitEthernet0/0
 ip address 172.17.1.1 255.255.255.0
 crypto map outside_map
!

What just happened:

• crypto isakmp policy 10 establishes an IKE policy (encryption, auth, DH group) — this defines how phase-1 is negotiated. IKE uses these to match a peer.
• crypto isakmp key Lab123 address 172.16.1.1 configures a pre-shared key associated with the peer IP. This makes the Hub accept IPsec with only that peer.
• crypto ipsec transform-set TS ... defines the IPsec transform (ESP, cipher, integrity).
• The access-list 110 entries are the crypto ACL: they select the interesting traffic (10.20.10.0/24 ↔ DC subnets).
• crypto map outside_map ties the peer, transform and ACL together and is applied to the outside interface (Gi0/0). With this, traffic that matches ACL 110 triggers IKE/IPsec negotiation.

Real-world note: Crypto maps require careful ACL management; adding or changing protected networks requires ACL updates on both sides.

Verify:

show crypto isakmp sa

Expected output:

Hub# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state         conn-id status
172.16.1.1      172.17.1.1      MM_ACTIVE     10      QM_IDLE

show crypto ipsec sa

Expected output:

Hub# show crypto ipsec sa
interface: GigabitEthernet0/0
    Crypto map tag: outside_map, local addr 172.17.1.1

   protected vrf: (none)
   local 172.17.1.1/32 remote 172.16.1.1/32
     current_peer 172.16.1.1
     #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
     #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts comp failed: 0

Step 2: Configure a dynamic crypto map (accept dynamic peers)

What we are doing: Convert the crypto map entry into a dynamic crypto map so the hub will accept dynamically sourced peers and their proposed traffic selectors. Useful when spokes have dynamic addresses or multiple spokes may initiate.

crypto ipsec transform-set TS esp-aes esp-sha-hmac mode tunnel
!
crypto dynamic-map dynamic_map 10
 set transform-set TS
 reverse-route
!
crypto map outside_map 10 ipsec-isakmp
 set peer 172.16.1.1
 set transform-set TS
 ipsec-isakmp dynamic dynamic_map
!
interface GigabitEthernet0/0
 ip address 172.17.1.1 255.255.255.0
 crypto map outside_map
!

What just happened:

• crypto dynamic-map dynamic_map 10 creates a dynamic-map that accepts negotiatons from peers that initiate with varying traffic selectors. reverse-route is often used to install route entries for the remote networks based on the crypto ACLs learned.
• The crypto map now references ipsec-isakmp dynamic dynamic_map allowing on-demand dynamic peers to be accepted.
• This reduces the need to predefine every peer address in peer lists, easing management of many spokes.

Real-world note: Dynamic crypto-maps can simplify many-to-one hub deployments, but they also can be permissive — ensure authentication and identity controls are robust.

Verify:

show crypto map

Expected output:

Hub# show crypto map
Crypto Map outside_map 10 ipsec-isakmp
  set peer 172.16.1.1
  set transform-set TS
  ipsec-isakmp dynamic dynamic_map

show crypto dynamic-map

Expected output:

Hub# show crypto dynamic-map
Name: dynamic_map
  Sequence 10
    Transform-set: TS
    reverse-route: enabled

Step 3: Configure a static VTI (Tunnel Interface) — route-based IPsec

What we are doing: Create a static tunnel interface (VTI) and bind IPsec protection to it. This demonstrates an overlay or route-based approach: the tunnel has an IP (ip unnumbered Loopback1) so routing protocols or route entries can reference the tunnel network.

interface Loopback1
 ip address 10.0.0.1 255.255.255.255
!
interface Tunnel1
 nameif tunnel-to-dc
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel mode ipsec ipv4
 tunnel destination 10.0.0.2
 tunnel protection ipsec profile default
!

What just happened:

• Loopback1 provides an IP (10.0.0.1) that is used with ip unnumbered for the Tunnel1 interface. This gives the tunnel an IP without consuming a separate subnet.
• tunnel source GigabitEthernet2 and tunnel destination 10.0.0.2 specify the underlay endpoints — the tunnel will encapsulate traffic between the local source interface and the remote destination.
• tunnel mode ipsec ipv4 designates native IPsec on the tunnel interface; tunnel protection ipsec profile default ties the tunnel to an IPsec profile (IKE/IPsec policies) so all traffic routed via Tunnel1 is protected.
• With a VTI, routing is simplified: you place routes pointing at Tunnel1 and the device will encrypt/decrypt based on the interface, not per-ACL. The VTI remains administratively up (route-based).

Real-world note: On ASA/FTD, VTIs are the preferred building block for SD-WAN and overlay VPNs because they separate underlay/NAT from overlay routing.

Verify:

show interface Tunnel1

Expected output:

Hub# show interface Tunnel1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.0.0.1/32
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 50000 usec,
  tunnel source  GigabitEthernet2, destination 10.0.0.2
  Tunnel protection: ipsec profile default

show ip interface brief

Expected output:

Hub# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     172.17.1.1      YES manual up                    up
GigabitEthernet2       unassigned      YES unset  up                    up
Loopback1              10.0.0.1        YES manual up                    up
Tunnel1                10.0.0.1        YES manual up                    up

Step 4: Configure a dynamic VTI (Virtual-Template / Virtual-Access)

What we are doing: Create a dynamic tunnel template (Virtual-Template) which spawns Virtual-Access interfaces for on-demand tunnels. This represents the dynamic-VTI approach where multiple spokes can establish tunnels and each negotiation generates a virtual interface.

interface Virtual-Template1 type tunnel
 nameif tunnel-to-dc
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel protection ipsec profile default
!
interface Virtual-Access1
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel destination 10.0.0.1
 tunnel protection ipsec profile default
!

What just happened:

• Virtual-Template1 defines the parameters for dynamic access interfaces. When a peer initiates, the system creates a Virtual-AccessX interface instance based on the template.
• ip unnumbered Loopback1 reuses Loopback1 for the interface IP, preserving address plan simplicity.
• Dynamic VTIs are useful when you have many spokes (each spawns a virtual access), or when spokes have dynamic IPs — the templates allow per-connection virtual interfaces and per-connection routing state.

Real-world note: Dynamic VTIs allow per-spoke interfaces so route policies and monitoring can be applied per-connection — important for multi-spoke hubs.

Verify:

show interface virtual-access1

Expected output:

Hub# show interface virtual-access1
Virtual-Access1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.0.0.1/32
  tunnel source GigabitEthernet2, destination 172.16.1.1
  Tunnel protection: ipsec profile default

show crypto ipsec sa

Expected output:

Hub# show crypto ipsec sa
interface: Virtual-Access1
    Crypto map tag: (none), local addr 172.17.1.1

   local 10.0.0.1/32 remote 10.0.0.2/32
     current_peer 172.16.1.1
     #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
     #pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2

Verification Checklist

• Check 1: Site-to-site crypto map is installed on Gi0/0. Verify with show crypto map and expect the map outside_map applied with the peer 172.16.1.1.
• Check 2: ISAKMP (IKE) SA exists for the peer. Verify with show crypto isakmp sa and expect an entry showing 172.16.1.1 vs 172.17.1.1 and a state such as MM_ACTIVE/QM_IDLE.
• Check 3: Tunnel1 (static VTI) is up and has IP 10.0.0.1 (ip unnumbered Loopback1). Verify with show interface Tunnel1 and show ip interface brief.

Common Mistakes

Symptom	Cause	Fix
Tunnel negotiation never completes	Peer pre-shared key mismatch or wrong peer IP in crypto isakmp key	Verify PSK and peer IP; ensure crypto isakmp key Lab123 address 172.16.1.1 matches remote config
Traffic not encrypted even though SA is up	Crypto ACL does not match traffic (crypto-map)	Update access-list 110 to include the correct source/destination networks (use exact net/mask)
Tunnel interface shows down	tunnel destination unreachable or underlay routing/NAT issue	Verify underlay reachability to tunnel destination 10.0.0.2 and ensure NAT is not interfering with termination
Multiple spokes cannot establish when DHCP/NAT is used	Using global device IKE identity only — hub cannot distinguish spokes	Use per-tunnel local identity (IKEv2 local identity) or dynamic maps/templates to allow multiple spokes from dynamic addresses

Key Takeaways

• Crypto maps (tunnel-less) are ACL-driven and straightforward for small static site-to-site links, but require careful ACL management and are less flexible with NAT/DHCP.
• VTIs (static or dynamic) provide a route-based overlay: they simplify routing, support per-tunnel interfaces, and are preferred for SD-WAN/overlay use cases on modern Cisco devices.
• Dynamic crypto-maps and virtual-template/dynamic-VTI approaches allow hubs to accept connections from dynamically addressed spokes — critical in hub-and-spoke topologies and when spokes are behind NAT or use DHCP.
• Always verify IKE identity behavior (IKEv2 local identity options listed in theory) when designing hubs that must accept multiple dynamic spokes; using a per-tunnel identity avoids collisions and NAT/DHCP issues.

Important: In production, choose the VPN type to match your operational needs — if you need scalable many-to-many encryption and centralized key distribution consider the appropriate any-to-any technique; if you prefer simple subnet-to-subnet protection with minimal routing changes use crypto maps; for modern route-based architectures and SD-WAN overlays prefer VTIs.

If you want, the next lesson will walk through converting an existing crypto-map site-to-site into a route-based VTI deployment step-by-step and show how routing changes are handled in NHPREP lab topologies.