SD-WAN with Secure Firewall and VPN Integration

Introduction

Every enterprise network faces a fundamental challenge: how do you connect dozens or hundreds of branch offices securely while maintaining visibility and control over traffic flows? The answer increasingly involves combining SD-WAN firewall capabilities with robust VPN technologies. When Cisco Secure Firewall is integrated into an SD-WAN architecture, organizations gain cryptographically protected tunnels, dynamic routing intelligence, and centralized security policy enforcement all within a single, cohesive design.

This article provides a deep technical walkthrough of how to build an SD-WAN VPN infrastructure using Cisco Secure Firewall (ASA and FTD platforms). You will learn the differences between legacy crypto map VPNs and modern Virtual Tunnel Interface (VTI) designs, how to configure both static and dynamic VTI tunnels, and how BGP routing ties the entire overlay together. Whether you are studying for your CCNP or CCIE certification or deploying these technologies in production, this guide covers the essential building blocks of Catalyst SD-WAN security with Secure Firewall integration.

We will walk through scalable hub-and-spoke topologies, examine real configuration examples for both hub and spoke firewalls, compare eBGP versus iBGP in SD-WAN overlays, and discuss the design considerations that determine convergence time and redundancy. By the end of this article, you will have a clear understanding of how SD-WAN VPN tunnels, routing protocols, and firewall security come together in modern enterprise networks.

If you are looking to build hands-on skills, the SD-WAN Deployment Lab on NHPREP is an excellent companion resource.

What Is the Relationship Between Underlay, Overlay, and SD-WAN Firewall VPN?

Before diving into configuration, it is critical to understand two foundational concepts that underpin every SD-WAN VPN deployment: the underlay network and the overlay network.

The Underlay Network

The underlay network is the physical or logical transport infrastructure that carries your encrypted traffic. This could be MPLS circuits, broadband internet links, LTE connections, or any combination of these. The underlay provides IP reachability between sites, but it does not inherently provide encryption, segmentation, or policy-based routing.

The Overlay Network

The overlay network is the logical topology built on top of the underlay using VPN tunnels. In an SD-WAN integration context, the overlay provides:

Cryptographic protection through IPSec encryption
Logical adjacency between sites regardless of underlay topology
Routing intelligence via protocols like BGP running over the tunnel interfaces
Policy enforcement through the firewall platform terminating the tunnels

The tunnel interface is the key component that bridges underlay and overlay. It provides a routable virtual interface that terminates IPSec tunnels, making the overlay network behave like a directly connected set of links from the perspective of the routing protocol.

Pro Tip: Think of the underlay as the physical highway system, the overlay as the secure express lanes built on top, and the tunnel interface as the on-ramp connecting the two. Without tunnel interfaces, your encrypted traffic has no clean integration point with your routing infrastructure.

How Do IPSec VPN Technologies Compare for SD-WAN Firewall Deployments?

Not all IPSec VPN implementations are created equal. Cisco platforms support multiple VPN technologies, and understanding their differences is essential for choosing the right approach in an SD-WAN firewall design.

VPN Technology Support by Platform

The following table summarizes which IPSec VPN technologies are supported on each major Cisco platform:

VPN Technology	IOS / IOS-XE	ASA	FTD
Crypto Map	Yes	Yes	Yes
GRE over IPSec w/ Crypto Map	Yes	No	No
EZVPN	Yes	Yes	Yes
VTI (Static)	Yes	Yes	Yes
DMVPN	Yes	No	No
FlexVPN	Yes	No	No

Several important observations emerge from this comparison:

Crypto Map is the legacy approach and is supported across all platforms, but it comes with significant operational overhead.
VTI is supported on ASA and FTD and is the recommended approach for SD-WAN VPN deployments with Secure Firewall.
DMVPN and FlexVPN are IOS/IOS-XE only technologies. They are not available on ASA or FTD platforms.
ASA and FTD do not support GRE encapsulation over VTI. They support only native IPSec IPv4/IPv6 tunnel mode.
There is no multicast support on ASA or FTD over VTI tunnels.

VPN Categories

These VPN technologies fall into two broad categories:

Category	Description	Technologies
Tunnel-less Encryption	Traffic is encrypted without creating a logical tunnel interface; uses ACLs to define interesting traffic	Crypto Map
Overlay IPSec VPNs	A virtual tunnel interface is created, providing a routable overlay	VTI, DMVPN, FlexVPN

For modern SD-WAN integration designs, overlay IPSec VPNs using VTI are strongly preferred because they provide a clean routing adjacency and eliminate the ACL management burden inherent in crypto map configurations.

Why Crypto Maps Are Not Suitable for SD-WAN VPN at Scale

The crypto map was the first implementation of IPSec VPNs used on Cisco devices. While it is still supported, it has significant limitations that make it unsuitable for scaled SD-WAN firewall deployments.

How Crypto Maps Work

With crypto maps, the traffic to be encrypted is defined by an access control list (commonly called a crypto ACL). The crypto map binds together the peer address, the IPSec transform set, and the matching ACL, then is applied to an interface.

Here is an example of a basic crypto map configuration:

crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2

crypto isakmp key Lab@123 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

The Operational Nightmare

Crypto maps create a configuration management nightmare for several reasons:

Mismatched ACLs: Both sides of the tunnel must have mirror-image ACLs. A single line mismatch causes traffic to fail silently.
ACL update requirements: Every time a new subnet is added at either site, both sides need ACL updates. In a 100-branch deployment, adding one subnet means touching 100 devices.
No routing integration: Because there is no tunnel interface, routing protocols cannot run over the encrypted path. Static routes or policy-based routing must be used instead.
No dynamic peer discovery: Each peer relationship requires explicit configuration.

Dynamic Crypto Maps

Dynamic crypto maps were introduced to address some of these limitations by dynamically accepting the remote peer's IP address and traffic selectors:

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 dynamic dynamic_map

interface GigabitEthernet0/0
 ip address 172.17.1.1 255.255.255.0
 crypto map outside_map

While dynamic crypto maps offer more flexibility, they still lack a tunnel interface for routing integration. The Dynamic VTI (DVTI) technology replaces dynamic crypto maps as the preferred dynamic hub-and-spoke method for establishing tunnels.

Pro Tip: If you are migrating from a legacy crypto map VPN to an SD-WAN design, plan the migration in phases. Convert to VTI-based tunnels first, then integrate BGP routing, and finally add policy-based routing or SASE integration as a later phase.

Understanding IPSec Virtual Tunnel Interfaces for SD-WAN Integration

The IPSec Virtual Tunnel Interface (VTI) is the cornerstone of modern SD-WAN firewall VPN designs. It provides a virtual routable interface for terminating IPSec tunnels and fundamentally changes how VPN traffic is handled compared to crypto maps.

Key Advantages of VTI

Simplifies configuration: No crypto ACLs needed. All traffic routed to the tunnel interface is automatically encrypted.
Always-up tunnel: The VTI tunnel is always up and does not require "interesting traffic" to initiate the IPSec session.
Routing protocol support: Because VTI creates a real interface, BGP, OSPF, EIGRP, or any other routing protocol can run directly over the tunnel.
Clean underlay/overlay separation: The tunnel interface sits logically between the underlay and overlay, providing a clear demarcation.

Static VTI Configuration

A Static VTI (SVTI) is used when you know the remote peer's IP address in advance. This is the simplest form of tunnel interface.

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

Key configuration elements:

nameif: Assigns a logical name to the tunnel interface (ASA/FTD only).
ip unnumbered: Borrows the IP address from a loopback interface. Supported on ASA 9.19+ and FTD 7.3+.
tunnel source: Specifies the physical interface used for the underlay.
tunnel mode ipsec ipv4: Sets the tunnel to native IPSec mode (no GRE encapsulation on ASA/FTD).
tunnel destination: Defines the remote peer's underlay IP address.
tunnel protection ipsec profile: Links the tunnel to an IPSec profile containing the encryption and integrity algorithms.

Dynamic VTI Configuration

A Dynamic VTI (DVTI) is used on the hub side of a hub-and-spoke topology when the hub needs to accept connections from many spokes without pre-configuring a static tunnel for each one. DVTI support was introduced in ASA 9.19 and FTD 7.3.

The hub is configured with a Virtual-Template interface:

interface Virtual-Template1 type tunnel
 nameif outside_dynamic_vti_1
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel protection ipsec profile default

When a spoke connects, the hub dynamically creates a Virtual-Access interface cloned from the Virtual-Template:

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

The Virtual-Access interface inherits all properties from the Virtual-Template but adds the specific tunnel destination learned from the incoming IKEv2 negotiation. The no tunnel protection ipsec initiate command indicates that this is a dynamically created responder-side tunnel that does not initiate connections.

Pro Tip: On the hub, the Virtual-Template acts as a blueprint. Every time a spoke connects, a new Virtual-Access interface is spawned. This is what allows a single hub to support up to 1000 spoke connections without individual static tunnel configurations.

How to Design a Scalable Hub-and-Spoke SD-WAN VPN Topology

Designing a scalable SD-WAN VPN topology requires careful planning around hub redundancy, spoke capacity, and routing protocol selection. The hub-and-spoke model is the most common topology for Catalyst SD-WAN security deployments using Secure Firewall.

Design Requirements

A well-designed SD-WAN firewall hub-and-spoke topology should meet these requirements:

Scalable deployment supporting hub-and-spoke topology
Cryptographic protection through IPSec tunnels
Headend redundancy with approximately 15 seconds convergence time
Mixed platform support at branches (ASA, FTD, or IOS devices)

Single and Dual Hub Design

Hubs can be IOS routers, ASA 9.19+, or FTD 7.3+ devices. When using Secure Firewall as hubs, the following design rules apply:

Design Parameter	Specification
Hub platforms supported	IOS, ASA 9.19+, FTD 7.3+
VPN topology per hub	Separate VPN topology for each VPN hub
Backup hub	Can be configured for each topology
Maximum spokes per hub	1000
Routing protocol	Required (BGP recommended)

For dual hub redundancy, two separate hub-spoke topologies are created:

Hub-Spoke Topology 1: Hub1 serves as primary, Hub2 as backup
Hub-Spoke Topology 2: Hub2 serves as primary, Hub1 as backup

Each spoke connects to both hubs, providing redundancy. If one hub fails, BGP reconverges and traffic shifts to the surviving hub within approximately 15 seconds when BGP timers are tuned appropriately.

Why a Routing Protocol Is Required

Unlike crypto map VPNs where static routes or policy-based routing might suffice, VTI-based SD-WAN integration designs require a dynamic routing protocol. The routing protocol serves several critical functions:

Advertises spoke subnets to the hub and other spokes
Enables spoke-to-spoke communication through the hub (transit routing)
Provides automatic failover when a hub or link fails
Supports route summarization to keep routing tables manageable at scale

How Does BGP Power SD-WAN Firewall Routing?

Border Gateway Protocol (BGP) is the recommended routing protocol for SD-WAN firewall VPN topologies. Its characteristics make it particularly well suited for large-scale overlay networks.

Why BGP for SD-WAN?

BGP brings several advantages to SD-WAN deployments:

Large scale: BGP is designed to operate between autonomous systems, making it inherently suitable for large topologies
TCP-based: BGP runs over TCP port 179, providing reliable transport
Attribute-based routing: Rather than simple metrics, BGP uses multiple attributes for granular path control
Route filtering: BGP allows strong control over advertised routes and their attributes
Stability: BGP is fundamentally designed for stability and does not flood updates like link-state protocols

BGP assumes that routing within each autonomous system is handled by an Interior Gateway Protocol (IGP) such as EIGRP, OSPF, or IS-IS. The BGP overlay handles inter-site routing across the SD-WAN tunnels.

eBGP vs. iBGP in SD-WAN Designs

In SD-WAN VPN topologies, the choice between eBGP (External BGP) and iBGP (Internal BGP) has significant implications:

Attribute	iBGP (Internal)	eBGP (External)
Scope	Within a single AS	Between different AS numbers
NEXT_HOP behavior	Unchanged (default)	Changed to local address used to establish the eBGP session
AS_PATH handling	Unchanged	Local AS inserted at the beginning of the AS_PATH list
Update forwarding	Updates from iBGP not sent to iBGP peers (default)	Updates from any peer sent to eBGP peers; from eBGP sent to iBGP
Spoke AS requirement	All spokes share same AS	All spokes must have unique BGP AS numbers

For Secure Firewall DVTI VPN topologies, eBGP is the recommended choice. With eBGP:

Each spoke has a unique AS number (e.g., AS 65001, AS 65002, etc.)
The hub uses its own AS number (e.g., AS 65000)
NEXT_HOP is automatically updated at each eBGP hop, which simplifies reachability
The AS_PATH attribute naturally provides loop prevention

Pro Tip: When using eBGP with many spokes, consider using a private AS number range (64512-65534 for 2-byte, or 4200000000-4294967294 for 4-byte) and assign each spoke a unique AS number systematically. This avoids routing loops and simplifies troubleshooting.

iBGP Consideration

With iBGP, the default behavior of not forwarding routes learned from one iBGP peer to another iBGP peer means you would need route reflectors or full mesh peering. In a hub-and-spoke topology, the hub naturally serves as a route reflector, but eBGP is still preferred for DVTI VPN topologies because of its simpler NEXT_HOP handling and automatic AS_PATH loop prevention.

Complete Hub Configuration for SD-WAN Firewall VPN

Let us walk through a complete hub configuration for an SD-WAN firewall deployment using ASA 9.19+ or FTD 7.3+. This configuration creates a dynamic VTI hub that accepts spoke connections and peers with them using eBGP.

Loopback and Virtual-Template Interfaces

The loopback interface provides the overlay IP address, while the Virtual-Template defines the DVTI blueprint:

interface Loopback1
 nameif loopback1
 ip address 10.254.1.1 255.255.255.0

interface Virtual-Template1 type tunnel
 nameif outside_dynamic_vti_1
 ip unnumbered loopback1
 tunnel source interface outside
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROFILE

The loopback interface at 10.254.1.1/24 serves as the overlay address space. All spoke connections will borrow this address through the ip unnumbered command on the Virtual-Template.

Inside Interface

The hub's LAN-facing interface connects to the internal network:

interface GigabitEthernet0/1
 nameif inside
 security-level 0
 ip address 10.250.0.1 255.255.255.0

IPSec Crypto Configuration

The IKEv2 and IPSec settings must match between hub and spokes:

crypto ipsec ikev2 ipsec-proposal AES-256
 protocol esp encryption aes-256
 protocol esp integrity sha-256

crypto ipsec profile IPSEC_PROFILE
 set ikev2 ipsec-proposal AES-256
 set ikev2 local-identity address

Tunnel Group for Spoke Peers

Each spoke requires a tunnel-group entry that maps the spoke identity to the Virtual-Template:

tunnel-group spoke1 type ipsec-l2l
tunnel-group spoke1 ipsec-attributes
 virtual-template 101
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

The peer spoke tunnel-group name must match what the peer provides via its IKEv2 identity. This is how the hub associates an incoming IKE negotiation with the correct tunnel-group and subsequently the correct Virtual-Template.

BGP Routing Configuration

The BGP configuration on the hub peers with each spoke using eBGP:

router bgp 65000
 bgp log-neighbor-changes
 timers bgp 5 15 0

 address-family ipv4
  redistribute connected
  neighbor 10.254.1.2 remote-as 65001
  neighbor 10.254.1.2 activate
  neighbor 10.254.1.3 remote-as 65002
  neighbor 10.254.1.3 activate
  no auto-summary
  no synchronization
 exit-address-family

Key BGP configuration notes:

BGP AS 65000 is used for the hub
Timers bgp 5 15 0: Keepalive every 5 seconds, hold timer of 15 seconds, min hold of 0. These aggressive timers enable the approximately 15-second convergence target.
redistribute connected: Advertises all connected networks (including the inside interface subnet 10.250.0.0/16) to BGP peers.
Each spoke neighbor is configured with its unique remote AS (65001, 65002, etc.)
no auto-summary and no synchronization are standard BGP best practices

Pro Tip: The route set interface feature in the IPSec profile enables the hub to learn spoke interface IP addresses via IKEv2 config exchange. This is critical for establishing BGP peering over DVTI because the hub needs to know the spoke's overlay IP address before the BGP session can be established.

Verifying the Hub

Once spokes connect, you can verify BGP peering with the show bgp summary command on the hub:

show bgp summary

Neighbor     V    AS   MsgRcvd  MsgSent  Up/Down
10.254.1.2   4    65001  3166     3167     2d10h
10.254.1.3   4    65002  2427     2436     1d20h

This output shows two spokes connected: one in AS 65001 (up for over 2 days) and another in AS 65002 (up for almost 2 days). The routing table on the hub would show:

V routes (VPN-connected): The spoke overlay addresses learned via IKEv2 config exchange, visible as entries on the outside_dynamic_vti_1_va interfaces
B routes (BGP-learned): The spoke LAN subnets learned via eBGP

Complete Spoke Configuration for SD-WAN VPN Connectivity

Spoke configuration differs depending on the ASA/FTD software version. Let us examine both the legacy approach and the modern approach.

Spoke Configuration: Pre-ASA 9.19.1 / Pre-FTD 7.3

Before the introduction of loopback and DVTI support on ASA/FTD, spokes used static VTI tunnels with explicit IP addressing. Here is a complete spoke configuration for this older approach:

IKEv2 and IPSec Setup

hostname Spoke2
domain-name lab.nhprep.com

crypto isakmp identity hostname

crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
crypto ikev2 enable outside

crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1

crypto ipsec profile VTI
 set ikev2 ipsec-proposal IPSEC_PROP

The crypto isakmp identity hostname command sets the IKE identity to the hostname rather than the IP address. This is important because the hub's tunnel-group name must match the identity the spoke presents during IKE negotiation.

Tunnel Group and Pre-Shared Keys

Two tunnel groups are configured, one for each hub, providing redundancy:

tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key Lab@123
 ikev2 local-authentication pre-shared-key Lab@123

tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key Lab@123
 ikev2 local-authentication pre-shared-key Lab@123

Static VTI Tunnels to Both Hubs

interface Tunnel1
 nameif VTI
 ip address 172.16.1.5 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

interface Tunnel2
 nameif VTI2
 ip address 172.16.1.7 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.254
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

Notice that in the pre-9.19 configuration, each tunnel has an explicit IP address rather than using ip unnumbered. Two tunnels provide redundancy to two separate hubs.

Static Routes and BGP

route VTI 172.16.1.253 255.255.255.255 172.16.1.253 1
route VTI2 172.16.1.254 255.255.255.255 172.16.1.254 1

router bgp 65000
 timers bgp 5 15 0
 address-family ipv4 unicast
  neighbor 172.16.1.253 remote-as 65000
  neighbor 172.16.1.253 activate
  neighbor 172.16.1.254 remote-as 65000
  neighbor 172.16.1.254 activate
  redistribute connected

In this pre-9.19 configuration, notice that BGP uses iBGP (same AS 65000 for both hub and spoke) rather than eBGP. The static routes are required to reach the BGP next-hop addresses because IKEv2 config-exchange routing is not available in this older software version.

Spoke Configuration: ASA 9.19.1+ / FTD 7.3+

The modern spoke configuration is significantly simpler thanks to loopback interfaces and IKEv2 config-exchange for peer interface sharing over the tunnel:

crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
crypto ikev2 enable outside

crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1

crypto ipsec profile VTI
 set ikev2 ipsec-proposal IPSEC_PROP

With ASA 9.19+ and FTD 7.3+, the spoke can use ip unnumbered with a loopback interface, and IKEv2 config-exchange handles the advertisement of interface addresses. The learned routes show up as "V" routes in the routing table, indicating they were learned via VPN config-exchange rather than a routing protocol.

SD-WAN Firewall Routing Behavior in Hub-and-Spoke Topologies

Understanding how routes propagate through the SD-WAN firewall VPN topology is essential for troubleshooting and capacity planning.

Hub Routing Table

On the hub (10.254.1.1/24), the routing table shows a combination of VPN-connected and BGP-learned routes:

Route Type	Prefix	Next-Hop	Interface
V (VPN)	10.254.1.2/32	connected by VPN	outside_dynamic_vti_1_va2
V (VPN)	10.254.1.3/32	connected by VPN	outside_dynamic_vti_1_va3
B (BGP)	192.168.101.0/24	10.254.1.2	via VA2
B (BGP)	192.168.102.0/24	10.254.1.3	via VA3

The V routes are the spoke overlay IP addresses learned through IKEv2 config-exchange. These appear on the dynamically created Virtual-Access interfaces. The B routes are the spoke LAN subnets learned through eBGP.

Spoke Routing Table

On each spoke, the routing table includes:

Route Type	Prefix	Next-Hop
V (VPN)	10.254.1.1/24	via Tunnel1
B (BGP)	10.250.0.0/16	10.254.1.1
B (BGP)	192.168.102.0/24	10.254.1.1

Each spoke learns the hub's LAN network (10.250.0.0/16) and other spokes' LAN networks (192.168.102.0/24) via BGP through the hub. This enables full spoke-to-spoke communication transiting through the hub.

Traffic Flow: Spoke to Spoke

When Spoke 1 (LAN 192.168.101.0/24) needs to reach Spoke 2 (LAN 192.168.102.0/24):

Spoke 1 looks up 192.168.102.0/24 in its routing table
BGP says the next-hop is 10.254.1.1 (the hub)
Traffic is sent through the IPSec tunnel to the hub
The hub receives the traffic, looks up 192.168.102.0/24
BGP says the next-hop is 10.254.1.3 (Spoke 2)
The hub forwards traffic through the IPSec tunnel to Spoke 2

This transit routing through the hub is automatic once BGP peering is established. The hub's firewall policy can inspect this spoke-to-spoke traffic, providing security visibility that is not possible with direct spoke-to-spoke tunnels.

Key Features Introduced in ASA 9.19+ and FTD 7.3+ for SD-WAN VPN

The ASA 9.19 and FTD 7.3 releases introduced several features that are critical for modern SD-WAN integration designs. Understanding what these releases bring helps you plan your deployment and determine whether a software upgrade is needed.

Feature Summary

Feature	Pre-9.19/7.3	ASA 9.19+ / FTD 7.3+
Static VTI	Yes	Yes
Dynamic VTI (DVTI)	No	Yes
Loopback interfaces	No	Yes
ip unnumbered	No	Yes
IKEv2 config-exchange for peer interface sharing	No	Yes
V routes in routing table	No	Yes
BGP routing support	Yes	Yes
Per-peer IKEv2 custom identity attributes	Yes	Yes

Loopback Interfaces

Loopback interfaces provide a stable, always-up interface that can be used for BGP peering and tunnel addressing. Before ASA 9.19, tunnel interfaces required explicit IP addressing, which consumed additional address space and added configuration complexity.

IKEv2 Config-Exchange

The IKEv2 config-exchange feature allows peers to share interface information over the tunnel during the IKEv2 negotiation. This eliminates the need for static routes to the remote peer's overlay IP address and enables the automatic creation of V routes in the routing table. This feature significantly simplifies the spoke configuration because the spoke no longer needs manual routes to reach the hub's overlay address for BGP peering.

Dynamic VTI as a Hub

Before ASA 9.19, only IOS routers could serve as DVTI hubs. The introduction of DVTI on ASA and FTD means that the Secure Firewall can now serve as a full SD-WAN firewall hub, supporting up to 1000 spokes per hub with dynamic tunnel creation and tear-down.

Pro Tip: If you are running ASA or FTD software older than 9.19 or 7.3 respectively, you can still participate in the VPN topology as a spoke using static VTI tunnels. However, you will miss out on the simplified configuration that loopback interfaces and IKEv2 config-exchange provide. Plan your upgrade path to take advantage of these features.

IKEv2 and IPSec Configuration Best Practices for SD-WAN Firewall

Getting the IKEv2 and IPSec configuration right is critical for a functioning SD-WAN VPN deployment. Mismatched parameters between hub and spoke are the most common source of tunnel failures.

IKEv2 Policy Configuration

The IKEv2 policy defines the Phase 1 parameters used during the IKE negotiation:

crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
crypto ikev2 enable outside

encryption aes-256: 256-bit AES encryption for IKE
integrity sha384: SHA-384 for IKE integrity verification
group 19: Diffie-Hellman group 19 (256-bit elliptic curve)
prf sha384: Pseudo-random function using SHA-384
crypto ikev2 enable outside: Enables IKEv2 on the outside interface

IPSec Proposal Configuration

The IPSec proposal defines the Phase 2 parameters for the data plane encryption:

crypto ipsec ikev2 ipsec-proposal AES-256
 protocol esp encryption aes-256
 protocol esp integrity sha-256

IPSec Profile

The IPSec profile binds the proposal to the tunnel interface:

crypto ipsec profile IPSEC_PROFILE
 set ikev2 ipsec-proposal AES-256
 set ikev2 local-identity address

The set ikev2 local-identity address tells the device to use its IP address as the IKEv2 identity. On the spoke side, the crypto isakmp identity hostname command sets the identity to the hostname instead.

Critical Matching Requirements

The following parameters must match between hub and spoke for the tunnel to establish:

IKEv2 policy: encryption, integrity, DH group, and PRF must all match
IPSec proposal: ESP encryption and integrity algorithms must match
Pre-shared keys: Both sides must use the same key
IKE identity: The hub's tunnel-group name must match the spoke's IKE identity (hostname or IP address)

Pro Tip: When troubleshooting tunnel failures, always verify the crypto proposals match on both sides first. A mismatch in any single parameter, even the PRF algorithm, will cause the IKE negotiation to fail. Use strong, modern algorithms like AES-256 with SHA-384 and DH group 19 for production deployments.

Frequently Asked Questions

What is the maximum number of spokes supported per SD-WAN firewall hub?

Each Secure Firewall hub (ASA 9.19+ or FTD 7.3+) supports a maximum of 1000 spokes per DVTI hub. For deployments exceeding this limit, you can deploy multiple hubs with separate VPN topologies. Each topology has its own primary and backup hub, providing both scalability and redundancy.

Can ASA and FTD support DMVPN or FlexVPN for SD-WAN?

No. DMVPN and FlexVPN are IOS/IOS-XE only technologies and are not supported on ASA or FTD platforms. For SD-WAN VPN on Secure Firewall, use VTI (static or dynamic) with BGP routing. The VTI approach provides similar scalability benefits to DMVPN while leveraging the security inspection capabilities of the firewall platform.

Why is eBGP preferred over iBGP for SD-WAN firewall DVTI topologies?

eBGP is preferred for DVTI VPN topologies because it handles the NEXT_HOP attribute more cleanly. With eBGP, the NEXT_HOP is automatically changed to the local address used to establish the session, ensuring reachability. With iBGP, the NEXT_HOP is unchanged by default, which can cause reachability issues in hub-and-spoke topologies. Additionally, eBGP automatically inserts the local AS into the AS_PATH, providing natural loop prevention.

What is the minimum ASA/FTD software version needed for DVTI hub support?

Dynamic VTI support requires ASA 9.19 or later and FTD 7.3 or later. These releases also introduced loopback interfaces, ip unnumbered support, and IKEv2 config-exchange for peer interface sharing. Older versions can still participate as spokes using static VTI tunnels but cannot serve as DVTI hubs.

Do ASA and FTD support multicast over VTI tunnels?

No. There is no multicast support on ASA or FTD over VTI IPSec tunnels. If your SD-WAN design requires multicast transport over encrypted tunnels, you would need to use IOS/IOS-XE devices with GRE over IPSec, which supports multicast encapsulation. This is one of the key differences between ASA/FTD VTI (native IPSec only, no GRE) and IOS VTI (supports GRE encapsulation).

What BGP timers are recommended for fast convergence in SD-WAN VPN?

The recommended BGP timers for SD-WAN firewall deployments are keepalive 5 seconds, hold time 15 seconds (configured as timers bgp 5 15 0). This provides approximately 15-second convergence when a hub or link failure occurs, meeting most enterprise requirements for headend redundancy failover. The default BGP timers of 60/180 seconds would result in unacceptably slow failover.

Conclusion

Integrating Cisco Secure Firewall with SD-WAN VPN technologies provides enterprises with a powerful combination of encrypted connectivity and security inspection. The evolution from legacy crypto maps to modern VTI-based designs has dramatically simplified configuration while improving scalability and routing intelligence.

The key takeaways from this guide are:

VTI is the foundation: Static and Dynamic VTI replace crypto maps as the building block for SD-WAN firewall VPN deployments. They provide always-up tunnels with native routing protocol support.
DVTI enables scale: With ASA 9.19+ and FTD 7.3+, a single Secure Firewall hub can support up to 1000 spoke connections using Dynamic VTI, with automatic Virtual-Access interface creation.
eBGP is the preferred routing protocol: Using eBGP with unique AS numbers per spoke provides clean NEXT_HOP handling, automatic loop prevention, and straightforward troubleshooting.
Aggressive BGP timers matter: Configuring keepalive at 5 seconds and hold time at 15 seconds delivers the fast convergence needed for hub redundancy failover.
Platform capabilities differ: ASA and FTD support VTI but not DMVPN, FlexVPN, or GRE encapsulation. Understanding these platform boundaries is essential for design decisions.
Software version is critical: The ASA 9.19 and FTD 7.3 releases are watershed moments that introduced DVTI, loopback interfaces, and IKEv2 config-exchange, transforming the Secure Firewall into a full SD-WAN hub platform.

To build hands-on skills with these technologies, explore the SD-WAN Deployment Lab on NHPREP, which provides practical experience with SD-WAN architecture, tunnel configuration, and routing protocol integration. Mastering these concepts is essential for anyone pursuing Cisco security or enterprise networking certifications.