Secure Firewall as VPN Hub

Objective

In this lesson you will deploy a Secure Firewall (ASA/FTD) as a VPN Hub for an SD‑WAN hub‑and‑spoke topology using IPsec Virtual Tunnel Interfaces (VTI). You will create the hub-side VTI, bind it to the outside interface, and verify the IPsec and routing behavior. In production, Secure Firewalls acting as hubs provide a scalable, centrally managed termination point for large numbers of branch spokes — useful for centralizing services (authentication, inspection, internet egress) and for keeping policy consistent across many remote locations.

Quick Recap

Refer to the topology shown in Lesson 1. This lesson adds the Secure Firewall Hub configuration (Loopback1, GigabitEthernet2, and Tunnel1). Exact addresses and interface names used in this lesson are taken from the reference material.

ASCII topology (Hub + one example spoke)

               Internet / Underlay
  Branch NAT GW (example)            Hub Outside
  (NAT IP 2.2.2.2)  ----------  [GigabitEthernet2] SecureFirewall-Hub
                                IP: 172.17.1.1/24
                                      |
                                   Tunnel1 (VTI)
                                   IP: 10.0.0.1  (ip unnumbered Loopback1)
                                       |
                                   Spoke VTI
                                   IP: 10.0.0.2

Notes:

• Tunnel destination used in this lesson: 10.0.0.2
• Tunnel local VTI IP (hub): 10.0.0.1 (ip unnumbered Loopback1)
• Physical outside interface used as tunnel source: GigabitEthernet2 (172.17.1.1)

Key Concepts

• Virtual Tunnel Interface (VTI): A VTI provides a routable virtual interface for an IPsec tunnel. Unlike crypto maps, a VTI behaves like a regular interface in the routing table: routes can point into it and routing protocols can peer over it. On ASA/FTD, a VTI is always up (no “interesting traffic” requirement) and supports native IPsec IPv4/IPv6; multicast support is not available on ASA/FTD VTIs.

  Think of a VTI like a virtual Ethernet port that is backed by an encrypted IPsec pipe — you route into it just like any other interface.

• ip unnumbered Loopback: Using ip unnumbered on the tunnel lets the tunnel inherit the Loopback1 address, which provides a stable, routable address for tunnel endpoints and simplifies addressing across many tunnels.

• Static vs Dynamic VTI: Static VTIs are configured with an explicit tunnel destination. Dynamic VTIs (DVTI/virtual-template + virtual-access) allow spokes to dynamically create sessions. This lesson demonstrates a static tunnel (hub configuration), which is commonly used when tunnel endpoints are known.

• IKEv2/IPsec exchange and identity: IKEv2 negotiates the SAs first, then IPsec SAs carry data. On hubs, per-peer identity attributes matter when spokes use DHCP-assigned interfaces or NAT; explicit IKE identities avoid ambiguity when multiple spokes originate from changing addresses.

• Routing and the VTI: When the VTI instantiates, the hub will show a route entry for the remote VTI endpoint (commonly with a route code such as "V" to indicate a virtual/VTI route). Routing protocols (e.g., BGP) can then use the VTI to exchange routes between hub and spoke.

Step-by-step configuration

Each step below gives the commands, why they matter, and verification with expected output.

Step 1: Configure Loopback and Outside Interface

What we are doing: Create a stable loopback address that will be used for the VTI IP (via ip unnumbered) and assign the outside physical interface an IP to be used as the tunnel source. This provides a fixed, routable identity for the firewall and a known source for tunnel traffic.

configure terminal
interface Loopback1
 ip address 10.0.0.1 255.255.255.255
exit

interface GigabitEthernet2
 ip address 172.17.1.1 255.255.255.0
 no shutdown
exit
write memory

What just happened: The Loopback1 interface now holds the stable address 10.0.0.1/32. The GigabitEthernet2 interface was given 172.17.1.1/24 and brought up; this will be the IP visible to spokes as the hub’s outside address and used as the VTI tunnel source. A stable loopback prevents tunnel endpoint addresses from changing if physical interfaces adjust.

Real-world note: In production, loopbacks are used as router IDs and stable endpoints for tunnels and routing protocols; using a /32 avoids accidental subnet overlap.

Verify:

show interface ip brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet2           172.17.1.1      YES manual up                    up
Loopback1                  10.0.0.1        YES manual up                    up

Step 2: Configure the Static VTI Tunnel Interface

What we are doing: Configure a static VTI (Tunnel1) that uses the hub’s Loopback1 IP, uses GigabitEthernet2 as the tunnel source, and points to the remote spoke VTI IP 10.0.0.2. We attach IPsec profile protection so that the tunnel encrypts traffic.

configure terminal
interface Tunnel1
 nameif tunnel-to-dc
 ip unnumbered Loopback1
 tunnel source GigabitEthernet2
 tunnel mode ipsec ipv4
 tunnel destination 10.0.0.2
 tunnel protection ipsecprofile default
exit
write memory

What just happened: The Tunnel1 VTI was created and configured to borrow the Loopback1 address (so the tunnel’s logical IP is 10.0.0.1). The tunnel source is the physical GigabitEthernet2 interface. The destination is the spoke’s VTI IP (10.0.0.2) — this makes it a static VTI. The tunnel is bound to an IPsec profile named "default", which tells the firewall to protect traffic over this interface using the profile’s parameters.

Real-world note: Static VTIs are simple and reliable when both endpoints are known and static. For large hub deployments, dynamic VTIs at the hub can scale better for many spokes, but static VTIs are deterministic and easy to troubleshoot.

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 ipsecprofile default

Step 3: Initiate IKE/IPsec and confirm SA state

What we are doing: After tunnel configuration, we verify that IKEv2 and the resulting IPsec SAs are established with the spoke. This validates both IKE negotiation and that the IPsec profile applied to the tunnel is functioning.

! (No configuration required here; we query state)
show crypto ikev2 sa

What just happened: The command returns the current IKEv2 Security Association(s), showing whether an IKEv2 SA is established with the peer. If an SA exists, it means IKEv2 completed the key exchange and authenticated the peer; subsequent IPsec SAs will be created for data traffic.

Real-world note: If spokes are behind NAT, per-peer IKE identities and NAT traversal considerations must be addressed so the hub can uniquely identify and accept spokes.

Verify (expected output):

IKEv2 SAs:
Session-id: 1, Status: READY
Local address: 172.17.1.1, Remote address: 2.2.2.2
IKEv2 SA State: ACTIVE
Child SAs: 1, IPsec SAs: ESTABLISHED
Remote identity: 10.0.0.2
IKEv2 SA lifetime: 3600 seconds

(Notes: Remote address 2.2.2.2 in this output is the example NAT gateway the spoke might use; the remote identity shows the spoke VTI IP 10.0.0.2.)

Step 4: Verify routing and the VTI appears in the route table

What we are doing: Confirm the hub’s routing table contains a route for the remote VTI endpoint and that it is attached to Tunnel1. This proves the VTI is the next-hop for spoke networks and that routing can carry traffic into the encrypted tunnel.

show route

What just happened: The route table includes a virtual/VTI route to the spoke VTI address (10.0.0.2). On Secure Firewall devices, VTI-derived routes typically show a route code (for example "V") indicating a virtual routing entry. The route pointing to Tunnel1 confirms the firewall will forward matching traffic into the tunnel.

Real-world note: You will see "V" (virtual) entries for VTI routes; routing protocols like BGP can peer over these interfaces to exchange prefixes with spokes.

Verify (expected output):

Codes: S - static, C - connected, V - vpn

S* 0.0.0.0/0 [1/0] via 172.17.1.254
C 172.17.1.0/24 is directly connected, GigabitEthernet2
C 10.0.0.1/32 is directly connected, Loopback1
V 10.0.0.2/32 is directly connected, Tunnel1

Step 5: (Optional) Show tunnel interface operational details

What we are doing: Inspect Tunnel1 operational status (if the command is supported) to confirm the interface is up and to see any counters or status fields that confirm the interface is carrying traffic.

show interface Tunnel1

What just happened: This command reveals Tunnel1 operational state and counters (packets in/out, MTU, etc.). If the interface shows "up/up" and counters increment when you generate traffic, the tunnel is operational end-to-end.

Real-world note: Look at counters when testing. If IKE says SA is established but counters remain zero, routing or ACLs may be dropping traffic before it reaches the tunnel.

Verify (expected output):

Interface Tunnel1 "tunnel-to-dc", is up
  Hardware is Tunnel
  Internet address is 10.0.0.1/32
  MTU 1500 bytes, BW 10000 Kbit
  5 packets input, 5 packets output
  Encapsulation IPV4/IPSEC

Verification Checklist

• Check 1: Tunnel VTI created and bound to Loopback1 — verify with show running-config interface Tunnel1 and show interface ip brief.
• Check 2: IKEv2 SA established to the spoke — verify with show crypto ikev2 sa and confirm status READY/ACTIVE.
• Check 3: Route to spoke VTI exists and points to Tunnel1 — verify with show route and confirm a "V 10.0.0.2/32" entry.

Common Mistakes

Symptom	Cause	Fix
Tunnel interface stays down or no route appears	Tunnel configured with wrong tunnel source interface (e.g., using a different Gi than the physical IP)	Correct the tunnel source to the actual outside interface (GigabitEthernet2) and ensure that interface IP is configured (172.17.1.1)
IKEv2 SA never establishes	Peer identity mismatch or NAT on path without proper identity handling	Verify IKE identity settings on both ends or ensure NAT traversal is accounted for; use explicit per-peer identity where spokes use DHCP/NAT.
Traffic sent into tunnel but counters remain zero	Routing not pointing at the VTI or access policy blocking traffic	Confirm show route shows the remote VTI route and that firewall policies permit traffic into the tunnel interface.
Tunnel up intermittently when spoke IP changes	Using static peer match based on remote IP when spoke IP is dynamic	Use dynamic VTI (DVTI) on hub or configure per-peer IKE identity attributes so tunnels can authenticate when source IP changes

Key Takeaways

• A VTI on Secure Firewall provides a routable interface for IPsec tunnels; it simplifies routing and allows routing protocols to operate over encrypted paths.
• Use ip unnumbered Loopback1 for a stable VTI address; a stable endpoint is critical in production for routing and peering.
• Static VTIs are simple and deterministic when endpoints are fixed; for dynamic spoke addresses or large-scale deployments, consider dynamic VTIs on the hub.
• Always verify both IKEv2 SA state and the routing table entries (V routes) when troubleshooting VPN hub behavior — one confirms cryptographic establishment, the other confirms traffic flow into the tunnel.

Tip: In a hub deployment with many spokes, keep track of per-spoke identity/addressing requirements; misconfigured identities are a common cause of intermittent tunnel failures when spokes sit behind NAT or use DHCP-assigned outside addresses.

This completes Lesson 6: deploying Secure Firewall as a VPN Hub using VTI.