Back
Lesson 6 of 7

VPN Platform Support Matrix

Objective

Explain which VPN technologies are supported on IOS‑XE, ASA (9.19+), and FTD (7.3+), demonstrate example configurations from each platform using only the reference commands and IPs, and provide guidance for migration planning. This lesson helps you choose the correct VPN type for a given platform in production and shows the exact CLI constructs you will use.

Topology

ASCII topology (exact interface names and IPs from the reference):

Hub (IOS‑XE) GigabitEthernet0/0: 172.17.1.1/24 VTI endpoint: 10.0.0.2

                Internet
                  |
                  |
 Hub (IOS‑XE) ---+--- ASA / FTD (Spoke)
 Gi0/0 172.17.1.1       Gi2 172.16.1.1
 VTI  10.0.0.2         VTI 10.0.0.1

Tip: The Hub can be IOS/IOS‑XE (supports many VPN styles) while ASA/FTD (9.19+/7.3+) support VTI and dynamic VTI (DVTI). Use the Hub to terminate many spokes or to interoperate with legacy crypto maps.

Device Table

DeviceRoleNotable Interfaces / IPs
Hub (IOS‑XE)VPN Hub (example)GigabitEthernet0/0 — 172.17.1.1/24 ; VTI endpoint 10.0.0.2
ASA / FTD (9.19+/7.3+)VPN Spoke / HubGigabitEthernet2 — 172.16.1.1/24 ; Tunnel endpoint 10.0.0.1

Introduction

In this lesson you will compare VPN platform support and configure representative examples using the exact commands and IPs from the reference: an IOS crypto‑map example and ASA VTI / DVTI examples. Knowing which VPN technologies each platform supports matters in production because it drives design decisions (for example: use VTI for routeable IPsec tunnels and dynamic VTI for scalable hub‑and‑spoke deployments). Real-world scenario: migrating a branch fleet from legacy crypto‑maps to VTI-based overlay routing on ASA/FTD hubs to simplify policy and enable BGP peering over the tunnel.

Quick Recap

Reference topology from Lesson 1 is used here. No new devices are added. We will use:

  • Hub (IOS‑XE) public: 172.17.1.1 on GigabitEthernet0/0
  • ASA / FTD public: 172.16.1.1 on GigabitEthernet2
  • Tunnel addresses: 10.0.0.1 (ASA/FTD), 10.0.0.2 (Hub)

These exact IPs and interface names are used in all configuration examples below.

Key Concepts

  • VTI (Virtual Tunnel Interface): a routeable interface that terminates IPsec. Think of a VTI as a “virtual wire” that behaves like a real interface — it gets its own routing and can be used with dynamic routing protocols. On ASA/FTD, VTI is supported (static and dynamic/DVTI) starting ASA 9.19 / FTD 7.3.
    • Production note: use VTI when you need per‑peer routing (BGP/OSPF) over IPsec.
  • Crypto Map / Legacy IPsec: crypto maps bind policy to a physical interface and use ACLs to define interesting traffic. They are widely supported on IOS, and also supported on ASA/FTD (but are legacy for complex overlay designs).
    • Packet flow: an ACL match triggers IKE/IPsec negotiation; traffic selectors are based on the ACL.
  • Dynamic VTI (DVTI) and Virtual‑Template / Virtual‑Access: DVTI on ASA/FTD provides hub behavior where multiple spokes dynamically create VTI tunnels to the hub. This replaces older dynamic crypto maps for scalable hub‑and‑spoke.
    • Behavior: each spoke that authenticates gets a Virtual‑Access interface, appearing in routing as a separate VTI (often shown as “V” routes).
  • Platform matrix constraints: Not all VPN types are supported on every platform (for example, GRE over IPsec is an IOS feature; ASA/FTD support native VTI/IPSec but not GRE over IPsec in many cases).
    • Why this matters: choosing unsupported features causes migration pain — you must translate GRE-based designs into VTI+routing or run a different hub OS.

Steps

Step 1: Configure a legacy dynamic crypto map on the IOS Hub

What we are doing: Configure a crypto map (dynamic crypto map example from the reference) on the IOS hub, bind it to the outside interface, and create the IPsec policy and ACLs. This demonstrates the legacy crypto‑map approach that many older branches still use.

crypto isakmp policy 10
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 0.0.0.255 10.10.10.0 0.0.0.255
access-list 110 permit ip 10.20.10.0 0.0.0.255 10.10.20.0 0.0.0.255
access-list 110 permit ip 10.20.10.0 0.0.0.255 10.10.30.0 0.0.0.255
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 creates an IKE policy that defines phase‑1 behavior (priority 10).
  • crypto isakmp key Lab123 address 172.16.1.1 configures the pre‑shared key for the peer at 172.16.1.1.
  • crypto ipsec transform-set TS ... defines the IPsec encryption/integrity transforms for phase‑2.
  • access-list 110 ... defines the traffic selectors (interesting traffic) used by this crypto map.
  • crypto map outside_map 10 ipsec-isakmp defines the crypto map entry (peer, transform, ACL).
  • interface GigabitEthernet0/0 and crypto map outside_map binds the crypto map to the physical interface so packets matching ACL 110 are encrypted and sent to 172.16.1.1.

Real-world note: Crypto maps are supported broadly on IOS and ASA, but they create more operational complexity when many spokes or many ACLs are required.

Verify:

show running-config interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 172.17.1.1 255.255.255.0
 crypto map outside_map

Step 2: Configure a Static VTI on the ASA / FTD

What we are doing: Create a static VTI tunnel interface on ASA/FTD that terminates IPsec and is routeable — the example uses the exact Tunnel1 configuration from the reference. This is the modern way to carry routing protocols like BGP over IPsec on ASA/FTD.

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:

  • interface Tunnel1 nameif tunnel-to-dc creates a VTI named Tunnel1 and assigns a logical name for ASA/FTD. This makes the tunnel visible as an interface for routing.
  • ip unnumbered Loopback1 borrows the IP of Loopback1 for this tunnel (enables routing without assigning a unique IP). On ASA/FTD, VTI is supported starting from ASA 9.19 / FTD 7.3+.
  • tunnel source GigabitEthernet2 defines the local physical interface used as the tunnel source (public interface).
  • tunnel mode ipsec ipv4 sets the tunnel to be native IPsec VTI (no GRE).
  • tunnel destination 10.0.0.2 sets the remote tunnel endpoint.
  • tunnel protection ipsec profile default ties an IPsec profile to the interface so that traffic is encrypted.

Real-world note: VTIs are always “up” once configured and protected (no need for “interesting traffic” ACLs). This simplifies routing and failover behavior in production.

Verify:

show running-config interface Tunnel1
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

Step 3: Configure a Dynamic VTI (Virtual‑Template) on ASA / FTD (hub role)

What we are doing: Configure a Virtual‑Template type tunnel for DVTI use on an ASA/FTD hub. This allows multiple spokes to dynamically create virtual access tunnels (Virtual‑Access interfaces) for each authenticated peer.

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
 no tunnel protection ipsec initiate

What just happened:

  • interface Virtual-Template1 type tunnel defines a template for dynamically created VTIs. When a spoke authenticates, the ASA will spawn a Virtual-Access interface based on this template.
  • The template includes ip unnumbered Loopback1 and tunnel source GigabitEthernet2 so all spawned VTIs inherit the correct source and addressing behavior.
  • interface Virtual-Access1 shows the per‑peer interface behavior; the no tunnel protection ipsec initiate is used to control initiation behavior for spokes/hub (reference shows this line in dynamic examples).

Real-world note: DVTI on ASA/FTD provides a scalable hub for up to many spokes (the reference mentions hubs can support up to 1000 spokes). Use DVTI for large-scale branch deployments.

Verify:

show running-config interface Virtual-Template1
interface Virtual-Template1 type tunnel
 nameif tunnel-to-dc
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel protection ipsec profile default

show running-config interface Virtual-Access1
interface Virtual-Access1
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel destination 10.0.0.1
 tunnel protection ipsec profile default
 no tunnel protection ipsec initiate

Step 4: Observe differences and capture platform support decisions

What we are doing: Summarize behavior differences and verify config bindings that determine which technologies you can run on each platform. We will verify the crypto map on IOS and the tunnel config on ASA/FTD to compare.

show running-config | include crypto map
show running-config interface Tunnel1
show running-config interface Virtual-Template1
show running-config interface GigabitEthernet0/0

What just happened:

  • show running-config | include crypto map quickly shows whether a crypto map is active and bound.
  • The other show running-config interface ... commands display the exact tunnel and interface configuration for VTI and DVTI, helping you compare how each platform configures IPsec termination.

Real-world note: When migrating, inventory both the IOS crypto maps and any ASA/FTD VTIs — you will translate ACL-based selectors into routeable VTIs and ipsec profiles. Pay attention to multicast or dynamic routing support: ASA/FTD VTI (native IPsec) does not support multicast over VTI in older code; in the reference ASA/FTD VTI has "No multicast support" — plan accordingly.

Verify (example consolidated output):

show running-config | include crypto map
crypto map outside_map 10 ipsec-isakmp

show running-config interface Tunnel1
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

show running-config interface Virtual-Template1
interface Virtual-Template1 type tunnel
 nameif tunnel-to-dc
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel protection ipsec profile default

show running-config interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 172.17.1.1 255.255.255.0
 crypto map outside_map

Verification Checklist

  • Check 1: Crypto map present on IOS hub — verify with show running-config interface GigabitEthernet0/0 and confirm crypto map outside_map is bound.
  • Check 2: Static VTI present on ASA/FTD — verify with show running-config interface Tunnel1 and confirm tunnel destination 10.0.0.2 and tunnel protection ipsec profile default.
  • Check 3: DVTI template exists on ASA/FTD — verify with show running-config interface Virtual-Template1 and confirm type tunnel and tunnel protection ipsec profile default.

Common Mistakes

SymptomCauseFix
Tunnel never establishes from ASA to IOS hubCrypto map peer IP or IKE key mismatch (e.g., wrong peer IP 172.16.1.1 vs actual)Verify crypto isakmp key and crypto map ... set peer on IOS; confirm peer IP 172.16.1.1 is reachable from GigabitEthernet0/0
VTI comes up but routing is missingTunnel created but no IP/routing assigned (ip unnumbered Loopback1 requires Loopback to exist)Ensure Loopback1 exists and has the correct address (ASA uses ip unnumbered Loopback1 in examples); configure routing (static or dynamic) over Tunnel interface
Expecting multicast / dynamic routing over ASA VTI and it failsReference notes: ASA/FTD VTI has No multicast support on some versions for overlayUse unicast routing (BGP/OSPF on VTI where supported) or ensure code supports multicast; verify platform capability (ASA 9.19+/FTD 7.3+ support BGP)
Trying GRE over IPsec on ASA/FTDGRE over IPSec is supported on IOS but not on ASA/FTD according to the reference matrixRe-architect to use native VTI on ASA/FTD or terminate GRE on an IOS hub; move GRE endpoints to IOS devices if GRE is required

Key Takeaways

  • Choose VTI on ASA/FTD (9.19+/7.3+) when you need routeable, always‑up IPsec tunnels and native routing protocol support (e.g., BGP). VTIs simplify routing and are the recommended modern approach for overlay WANs.
  • Legacy crypto maps remain supported on IOS and can interoperate with ASA/FTD, but they rely on ACLs as traffic selectors and are operationally more complex at scale.
  • DVTI (Virtual‑Template / Virtual‑Access) is the scalable hub model on ASA/FTD for many spokes — use it for large branch deployments, but validate peer limits and routing behavior for your code level.
  • Migration planning matters: inventory existing crypto maps and GRE dependencies, then map those to VTIs and ipsec profiles (or plan for IOS hubs if GRE must remain). Verify multicast/dynamic routing support per platform and code release before converting designs.

Final tip: When performing migrations in production, stage changes in a lab with exact versions (ASA 9.19 / FTD 7.3 or your target release) to validate VTI behavior (routing, failover, BGP peering) before cutover.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security