Back
Lesson 5 of 7

SD-WAN IPsec and SD-Routing

Objective

In this lesson you will configure and compare SD‑WAN IPsec overlay behavior using VTI (IPsec Virtual Tunnel Interface) with a traditional hub‑and‑spoke VPN approach, and demonstrate how SD‑Routing (routing over the secure overlay) is performed using BGP. This matters in production because modern branch designs rely on routable VPN interfaces (VTIs) to run routing protocols across encrypted links — enabling rapid convergence and simplified policy distribution. Real-world scenario: a spoke firewall establishes two VTI tunnels to active/backup hubs (10.0.0.253 and 10.0.0.254) and uses BGP to learn remote networks across the encrypted overlay.

Topology

ASCII diagram showing exact interfaces and IPs used in this lesson:

                         Hub1 (Headend)
                  Tunnel IP: 172.16.1.253/32
                  Underlay IP: 10.0.0.253

                     10.0.0.253
                         |
                         |  (IPsec VTI over underlay)
                         |
                      [Internet]
                         |
                         |
           Underlay IP: 10.0.0.254
                  Tunnel IP: 172.16.1.254/32
                         Hub2 (Backup Headend)

                       (Spoke ASA/FTD)
  Tunnel1: 172.16.1.5/255.255.255.254  <--> 172.16.1.253 (Hub1)
  Tunnel destination (underlay): 10.0.0.253

  Tunnel2: 172.16.1.7/255.255.255.254  <--> 172.16.1.254 (Hub2)
  Tunnel destination (underlay): 10.0.0.254

Device Table

DeviceRoleRelevant Interfaces / IPs
Spoke ASA/FTDBranch firewall (this lab)Tunnel1: 172.16.1.5/255.255.255.254 -> dest 10.0.0.253; Tunnel2: 172.16.1.7/255.255.255.254 -> dest 10.0.0.254
Hub1Headend VPN peerUnderlay endpoint 10.0.0.253; Tunnel VTI address 172.16.1.253
Hub2Backup headendUnderlay endpoint 10.0.0.254; Tunnel VTI address 172.16.1.254
BGPRouting protocol between Spoke and HubsAS: 65000; neighbors: 172.16.1.253 and 172.16.1.254

Quick Recap

Refer back to the topology from earlier lessons (hub-and-spoke with VTI support). This lesson adds the VTI tunnel interfaces and BGP configuration on the spoke device using the exact IP addresses and commands shown in the reference material:

  • Tunnel destinations: 10.0.0.253 and 10.0.0.254
  • Tunnel IPs on the spoke: 172.16.1.5 and 172.16.1.7
  • BGP AS: 65000; neighbors 172.16.1.253 and 172.16.1.254
  • IKEv2 pre-shared key: cisco

Key Concepts

  • VTI (IPsec Virtual Tunnel Interface): A VTI provides a routable, point-to-point interface that terminates IPsec. Think of a VTI like a virtual link-layer cable: routing protocols can run over it because it appears as a real interface with an IP address. In production, VTIs are used to carry dynamic routing (BGP/OSPF) across encrypted overlays so that spoke devices learn remote networks dynamically.
  • Underlay vs Overlay: The underlay is the routable public/private network where the IPsec tunnel endpoints (10.0.0.253 / 10.0.0.254) live. The overlay is the encrypted VTI network (172.16.1.x) used for routing and policy. Packet flow: IP packet -> encapsulated in IPsec on underlay -> decapsulated at remote VTI -> forwarded based on overlay routing.
  • IKEv2 and IPsec behavior: IKEv2 establishes the security associations (SAs). With VTI static tunnels the tunnel is always present once SAs are negotiated: no "interesting traffic" ACLs are required. In production, using IKEv2 with consistent pre-shared keys (or certificates) is essential to ensure SAs come up.
  • SD‑Routing via BGP: Running BGP over VTIs lets the spoke advertise and learn prefixes dynamically. BGP establishes TCP sessions (port 179) once the overlay IPs are reachable over the VTI. In a hub-and-spoke SD-WAN design, BGP enables fast failover and policy-based traffic steering when multiple hubs exist.
  • Behavioral note: ASA/FTD VTI implementations do not support multicast over VTI in some code versions; for routing protocols that rely on multicast, you must use unicast neighbor configuration (BGP uses TCP unicast, so it's compatible).

Steps

Step 1: Configure IKEv2 identity and pre-shared keys (tunnel-groups)

What we are doing: Create the IKEv2 authentication parameters and define the per-peer tunnel-group entries used for IPsec. This establishes the shared secret used by both endpoints to authenticate IKEv2 and negotiate SAs.

configure terminal
ikev2 remote-authentication pre-shared-key cisco
ikev2 local-authentication pre-shared-key cisco

tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
exit

What just happened: The ikev2 commands set the local and remote authentication method to use the pre-shared key "cisco". The tunnel-group block defines a peer group for the underlay endpoint 10.0.0.254 and applies the same pre-shared keys under its ipsec attributes. When the spoke initiates or receives an IKEv2 connection from 10.0.0.254, it will use the configured key to authenticate and proceed to SA negotiation.

Real-world note: Pre-shared keys are simple but scale poorly — in production, consider certificate-based authentication for many peers.

Verify:

show running-config tunnel-group

tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco

Step 2: Configure the VTI Tunnel interfaces (Tunnel1 and Tunnel2)

What we are doing: Create two static IPsec tunnel interfaces that map to each hub underlay IP. These VTIs provide routable overlay addresses (172.16.1.5 and 172.16.1.7) to run routing protocols over encrypted links.

configure terminal
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
exit

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
exit

What just happened: Each interface TunnelX block creates a VTI with a unique overlay IP. The tunnel destination points to the hub underlay IP (10.0.0.253 / 10.0.0.254). tunnel mode ipsec ipv4 indicates the tunnel carries IPsec-protected IPv4 traffic. tunnel protection ipsec-profile VTI binds the named IPsec profile (which contains transform sets / crypto maps) to the interface so negotiated SAs are applied to the VTI.

Real-world note: Using a VTI removes the need for crypto ACLs to define interesting traffic — routes determine what is sent over the tunnel.

Verify:

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

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

Step 3: Create VTI route entries for headend overlay addresses

What we are doing: Add host route entries so the system knows how to reach the headend overlay addresses (172.16.1.253 and 172.16.1.254) across the VTI. These host routes are used as next-hops for routing protocol peering and for routing traffic into the overlay.

configure terminal
routeVTI 172.16.1.253 255.255.255.255 172.16.1.253 1
routeVTI2 172.16.1.254 255.255.255.255 172.16.1.254 1
exit

What just happened: The routeVTI statements create specific host routes for the remote overlay addresses, pointing the device to use those addresses as next hops (with metric 1). In practice this ties the overlay reachability into the device's routing table so BGP/TCP can form neighbor relationships with the hub VTIs.

Real-world note: Some platforms use route syntax vs. routeVTI; the important concept is ensuring a host route exists for the remote VTI IP to allow TCP session setup for BGP.

Verify:

show running-config | include routeVTI
routeVTI 172.16.1.253 255.255.255.255 172.16.1.253 1
routeVTI2 172.16.1.254 255.255.255.255 172.16.1.254 1

show ip route

S* 0.0.0.0/0 [1/0] via 172.16.1.253
172.16.1.253/32 is directly connected, Tunnel1
172.16.1.254/32 is directly connected, Tunnel2

Step 4: Configure BGP for SD‑Routing over the overlay

What we are doing: Configure BGP on the spoke to peer with the hub overlay IPs. BGP will advertise connected routes and learn remote prefixes across the IPsec VTIs, providing dynamic route exchange for SD‑Routing.

configure terminal
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
 exit
exit

What just happened: The router bgp 65000 stanza enables BGP in AS 65000 on the spoke. Timers were reduced (5 15 0) to speed convergence in this lab scenario (5s keepalive / 15s hold). Neighbors 172.16.1.253 and 172.16.1.254 are configured as BGP peers in the same AS (iBGP), and redistribute connected tells BGP to advertise directly connected routes (including local networks behind the spoke) into BGP so hubs learn them.

Real-world note: In production, iBGP requires full mesh or route reflector design. For hub-and-spoke overlays, the hub commonly acts as a route reflector or uses a routing topology that ensures distribution without full mesh.

Verify:

show running-config router bgp

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

show ip bgp summary

BGP router identifier 172.16.1.5, local AS number 65000
BGP table version is 3, main routing table version 3

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd
172.16.1.253    4 65000     120     118        3    0    0 00:02:12        5
172.16.1.254    4 65000     118     119        3    0    0 00:02:10        3

(Note: State/PfxRcd shows the number of prefixes received from each neighbor; Up/Down shows session uptime.)

Verification Checklist

  • Check 1: Tunnel interfaces exist and carry the overlay IPs — verify with show running-config interface Tunnel1 and show running-config interface Tunnel2. Expected: Tunnel1 has 172.16.1.5/30 and destination 10.0.0.253; Tunnel2 has 172.16.1.7/30 and destination 10.0.0.254.
  • Check 2: IKEv2/tunnel-groups configured with matching pre-shared-key — verify with show running-config tunnel-group to confirm ikev2 remote-authentication pre-shared-key cisco lines exist.
  • Check 3: BGP neighbors are established and prefixes exchanged — verify with show ip bgp summary showing neighbors 172.16.1.253 and 172.16.1.254 in Established state and non-zero PfxRcd counts.
  • Check 4: Host routes for hub overlay IPs are present — verify with show ip route showing 172.16.1.253/32 and 172.16.1.254/32 reachable via Tunnel1/Tunnel2.

Common Mistakes

SymptomCauseFix
BGP neighbor never transitions to EstablishedTunnel destination (underlay) IP is wrong (e.g., configured 10.0.0.252 instead of 10.0.0.253)Verify tunnel destination values on Tunnel interfaces and fix to 10.0.0.253 / 10.0.0.254
No IPsec SAs / IKEv2 failsMismatched pre-shared-key or missing tunnel-group ipsec-attributesConfirm ikev2 remote-authentication pre-shared-key cisco on both ends and ensure tunnel-group exists for the peer
BGP shows established but no routes learnedMissing routeVTI / no host route to remote overlay IP, or BGP not redistributing connected routesEnsure host routes (172.16.1.253/32 and 172.16.1.254/32) exist and redistribute connected is configured if you expect to advertise connected prefixes
Tunnel interface up but traffic not routedIncorrect IP address/mask on Tunnel interfaces (e.g., wrong /30)Check ip address lines for Tunnel1/2 and ensure masks match (255.255.255.254) and peers use corresponding overlay IPs

Key Takeaways

  • VTIs create a routable overlay interface for IPsec so routing protocols like BGP can run over encrypted tunnels — this is essential for scalable SD‑WAN overlays.
  • Underlay and overlay are distinct: the underlay (10.0.0.253 / 10.0.0.254) carries encrypted packets, while the overlay (172.16.1.x) carries routed traffic and routing protocol adjacencies.
  • IKEv2 authentication (pre-shared key or certificates) must match on both sides; mismatch prevents SA formation and BGP adjacency.
  • SD‑Routing with BGP over VTI provides dynamic route exchange and fast convergence in hub-and-spoke designs; always ensure host reachability of the remote VTI IPs so BGP TCP sessions can form.

Final real-world insight: In production SD‑WAN, this pattern (VTIs + routing protocol) gives you policy-rich overlays with predictable routing behavior. Watch for authentication, underlay reachability, and correct host routes — these are the common failure points when converting traditional VPNs to SD‑WAN overlays.

Practice with Hands-On Labs

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