NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will configure service chaining on a Secure Firewall hub so that all inter-spoke traffic is forced through the central firewall for inspection. This creates a centralized security inspection point in an SD-WAN hub-and-spoke design using IPSec Virtual Tunnel Interfaces (VTI / DVTI) and eBGP for route exchange. In production, centralized inspection is used when compliance, deep packet inspection, DLP, or advanced threat detection must be applied to all east-west traffic between remote sites.

Topology

(Reference topology from Lesson 1 — no new physical devices; this lesson uses the same IPs.)

ASCII topology (logical view — exact IPs on interfaces):

Hub Secure Firewall (Hub1)

Loopback1: 10.254.1.1/24
inside Gi0/1: 10.250.0.1/24
Virtual-Template1 (DVTI): ipunnumbered Loopback1 (VTI addresses learned from spokes)

Spoke1 Secure Firewall (Spoke1)

VTI address: 10.254.1.2 (connected over IPsec)
LAN: 192.168.101.0/24

Spoke2 Secure Firewall (Spoke2)

VTI address: 10.254.1.3 (connected over IPsec)
LAN: 192.168.102.0/24

Topology ASCII diagram:

Hub1 (Secure Firewall) Loopback1 10.254.1.1/24 Gi0/1 inside 10.250.0.1/24 | | DVTI / IPsec (VTI addresses shown) | +------+------+ | | Spoke1 Spoke2 VTI:10.254.1.2 VTI:10.254.1.3 LAN:192.168.101.0/24 LAN:192.168.102.0/24

Note: This lab uses the exact IPs and interface names from the reference configuration. No additional addresses are introduced.

Device Table

Device	Key Interfaces / IPs
Hub (Secure Firewall)	Loopback1 10.254.1.1/24; Gi0/1 inside 10.250.0.1/24; Virtual-Template1 ipunnumbered loopback1
Spoke1 (Secure Firewall)	VTI 10.254.1.2; LAN 192.168.101.0/24
Spoke2 (Secure Firewall)	VTI 10.254.1.3; LAN 192.168.102.0/24

Quick Recap

Lesson 1 established DVTI-based IPSec tunnels between spokes and the hub and used eBGP to exchange LAN prefixes. The hub uses a Loopback1 (10.254.1.1/24) that is ipunnumbered on the virtual-template to represent the VTI network. Spokes present individual VTI addresses (10.254.1.2, 10.254.1.3) and advertise their LANs (192.168.101.0/24, 192.168.102.0/24) into eBGP. In this lesson we will leverage that DVTI + BGP structure to implement centralized inspection — i.e., service chaining so that spoke-to-spoke traffic transits the hub firewall for inspection before reaching the remote LAN.

Key Concepts

IPSec Virtual Tunnel Interface (DVTI): a per-spoke tunneled interface that creates routing adjacencies. Think of a VTI as a virtual point-to-point link for routing — like an Ethernet cable that is encrypted across the Internet. When you add the hub virtual-template ipunnumbered loopback, each dynamic VTI instance borrows the loopback address space for addressing and advertisement.
- Protocol behavior: IKEv2 exchanges include the peer’s virtual IP (via route set interface) so the hub can establish per-spoke BGP neighbors using those VTI addresses.
eBGP between hub and spokes: Each spoke forms an eBGP session with the hub (hub in AS 65000, spokes in distinct ASes such as 65001 and 65002 in the reference). eBGP semantics matter: the next-hop will be changed to the IP used for the eBGP session and the spoke’s AS is inserted into AS_PATH. In practice this means the hub sees spoke networks as reachable through the VTI source IP (10.254.1.x).
Centralized service chaining via routing: By making the hub the routing hop between spokes — i.e., spokes send traffic toward spoke prefixes via the hub — the hub firewall is placed inline logically. The firewall inspects the traffic as it arrives on the hub VTI and before it is forwarded out the appropriate VTI to the destination spoke.
Why route-set interface matters: The IKE exchange can advertise the per-spoke VTI address to the hub, enabling dynamic BGP neighbor peering to form to that VTI address. This is how the hub learns the exact remote VTI IP for each spoke and becomes the default forwarder for inter-spoke traffic.
Inspection considerations: When traffic is decrypted on the VTI, the firewall can apply full security stack. In production, ensure MTU, fragmentation, and inspection engine capacity are sized correctly — high-throughput environments require dedicated inspection hardware or appropriate throughput licensing.

Step-by-step configuration

Each step follows: purpose, commands (full config mode entry/exit), explanation, real-world note, and verification with expected output.

Step 1: Configure the Hub loopback and Virtual-Template (DVTI)

What we are doing: Create the hub loopback used for DVTI ipunnumbered, and create a Virtual-Template interface so spokes dynamically receive VTI instances. This is the foundation that lets each spoke establish a VTI and be addressable at 10.254.1.x.

configure terminal
interface Loopback1
 nameif loopback1
 ip address 10.254.1.1 255.255.255.0
 exit
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
 exit
exit
write memory

What just happened:

Loopback1 creates a stable IP (10.254.1.1/24) that DTIs can borrow via ipunnumbered.
Virtual-Template1 defines the template for dynamic VTIs. ip unnumbered loopback1 causes dynamic VTIs to reuse the Loopback1 IP space; tunnel protection ipsec profile PROFILE binds the IPsec profile (IKEv2+IPsec settings) to the DVTI so that incoming spokes will create protected tunnel instances.

Real-world note: Using a loopback for VTI addressing gives a stable aggregation prefix for BGP and simplifies firewall policies and monitoring.

Verify:

show running-config interface Loopback1
! Expected output
interface Loopback1
 nameif loopback1
 ip address 10.254.1.1 255.255.255.0
!

show running-config interface Virtual-Template1
! Expected output
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
!

Step 2: Configure IPsec/IKEv2 proposals and the IPSEC profile on the hub

What we are doing: Define IKEv2/IPsec transforms and bind them to a profile that the virtual-template will use. These must align with spoke settings to successfully form SAs.

configure terminal
crypto ipsec ikev2 ipsec-proposal AES-256
 protocol esp encryption aes-256
 protocol esp integrity sha-256
exit
crypto ipsecprofile IPSEC_PROFILE
 set ikev2 ipsec-proposal AES-256
 set ikev2 local-identity address
 exit
write memory

What just happened:

The ipsec-proposal named AES-256 specifies ESP encryption and integrity algorithms that will be used for IPsec SAs.
The crypto ipsecprofile IPSEC_PROFILE ties the proposal to an IPsec profile and configures the local identity for IKEv2. The virtual-template referenced earlier uses this profile to protect tunnel instances.

Real-world note: Crypto proposals must match exactly on both peers; algorithm mismatches are the most common reason for tunnel failures.

Verify:

show running-config crypto ipsec ikev2
! Expected output (snippet)
crypto ipsec ikev2 ipsec-proposal AES-256
 protocol esp encryption aes-256
 protocol esp integrity sha-256
!

show running-config crypto ipsecprofile
! Expected output
crypto ipsecprofile IPSEC_PROFILE
 set ikev2 ipsec-proposal AES-256
 set ikev2 local-identity address
!

Step 3: Configure the Hub BGP to peer to the spokes (eBGP)

What we are doing: Configure router BGP on the hub (AS 65000), add neighbor entries for dynamic VTI neighbors at 10.254.1.2 and 10.254.1.3 (spokes). BGP will advertise hub LAN networks and receive spoke LANs so traffic can be forwarded via the VTIs, ensuring all inter-spoke traffic passes the hub.

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

What just happened:

router bgp 65000 begins BGP configuration for the hub AS.
Under address-family ipv4, the hub redistributes connected networks (for example, the inside network 10.250.0.0/16) and activates eBGP neighbours at the spokes' VTI IPs (10.254.1.2 and 10.254.1.3). This forms eBGP sessions over the VTIs so spoke prefixes are advertised to the hub and vice versa.

Real-world note: Using distinct AS numbers on spokes creates eBGP sessions and ensures AS_PATH information is propagated — useful for path control and loop prevention in multi-hub designs.

Verify:

show bgp summary
! Expected output
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

show ip route
! Expected output (relevant routes)
B 10.250.0.0/16 [200/0] -> 10.254.1.1
B 192.168.101.0/24 [200/0] -> 10.254.1.2
B 192.168.102.0/24 [200/0] -> 10.254.1.3
V 10.254.1.2 255.255.255.255 connected by VPN (advertised), outside_dynamic_vti_1_va2
V 10.254.1.3 255.255.255.255 connected by VPN (advertised), outside_dynamic_vti_1_va3

Step 4: Configure IKEv2/IPsec on each Spoke and bind to the hub

What we are doing: On each spoke firewall, configure an IKEv2 policy, enable IKEv2 on the outside interface, create an IPsec proposal and profile, and add a tunnel-group for the hub peer. This creates the dynamic VTI instances to the hub.

(Example commands for Spoke2 — Spoke1 uses the same pattern with its own pre-shared key and AS.)

configure terminal
crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
 exit
crypto ikev2 enable outside
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1
 exit
crypto ipsecprofile VTI
 set ikev2 ipsec-proposal IPSEC_PROP
 exit
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 exit
write memory

What just happened:

The spoke defines an IKEv2 policy and an IPsec proposal that must match the hub’s configuration (note algorithm choices must be compatible).
crypto ipsecprofile VTI associates the proposal to be used on the spoke side.
tunnel-group 10.0.0.253 type ipsec-l2l sets up a generic L2L tunnel-group (the reference uses 10.0.0.253 as an example peer identity). The spoke will use the tunnel-group identity in IKEv2 exchanges and instantiate a VTI to the hub.

Real-world note: Firewalls that use DHCP or dynamic outside IPs may use a default L2L tunnel-group in the management console; the referenced behavior is that dynamic spokes will be configured to connect to a default L2L peer.

Verify:

show running-config crypto ikev2
! Expected output (snippet)
crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
!
crypto ikev2 enable outside

show running-config crypto ipsec ikev2
! Expected output (snippet)
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1
!
crypto ipsecprofile VTI
 set ikev2 ipsec-proposal IPSEC_PROP
!

Step 5: Validate centralized inspection path (service chaining)

What we are doing: Confirm that traffic from Spoke1 to Spoke2 is routed via the hub VTI addresses so the hub becomes the in-path inspection device. We will verify the BGP-learned routes and the VTI connectivity.

! On Hub:
show ip route 192.168.102.0
! Expected output
B 192.168.102.0/24 [200/0] -> 10.254.1.3

show bgp summary
! Expected output (as in Step 3)
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

What just happened:

The hub’s routing table shows the spoke networks installed as BGP-learned routes with next-hops equal to the spoke VTI addresses. This proves that when Spoke1 sends traffic to 192.168.102.0, the packet is forwarded to the hub (VTI), where the firewall can inspect and then forward it to the VTI for Spoke2.

Real-world note: To avoid hairpinning in very latency-sensitive applications, consider whether centralized inspection is strictly required for all east-west flows. If not, selectively steer only high-risk traffic through the hub policies.

Verification Checklist

Check 1: DVTI template exists and is ipunnumbered to Loopback1 — verify with show running-config interface Virtual-Template1.
Check 2: Hub has active eBGP neighbors for each spoke VTI (10.254.1.2, 10.254.1.3) — verify with show bgp summary.
Check 3: Hub routing table contains spoke LANs with next-hop equal to the spoke VTI address — verify with show ip route 192.168.101.0 and show ip route 192.168.102.0.

Common Mistakes

Symptom	Cause	Fix
BGP neighbor never comes up	Spoke VTI never instantiated (mismatched IPsec/IKE settings)	Verify IKEv2/ipsec-proposal names and algorithms match exactly on both sides; check `show crypto ikev2 sa`
Spoke routes not in hub RIB	Hub not receiving route announcements	Confirm `router bgp` address-family configuration and that `neighbor X activate` is present; verify `redistribute connected` if necessary
Traffic not inspected at hub	Hub forwarding bypasses inspection or policy not applied	Ensure traffic decrypts on the hub VTI (VTI addresses present) and policy/inspection/ACLs are applied to the correct interfaces (outside_dynamic_vti_1 / inside)
VTI IPs differ from expected 10.254.1.x	IKEv2 route set interface not configured or peer provided different identity	Use `ikev2 route set interface` on hub tunnel-group and ensure IKE identity matches expectations

Key Takeaways

DVTI (virtual-template) + Loopback ipunnumbered creates deterministic per-spoke IPs (10.254.1.x) which are ideal for forming eBGP sessions and placing the hub in-path for inspection.
eBGP between hub and spokes ensures spoke prefixes are advertised to the hub; the hub’s routing table next-hop will be the spoke VTI IP, enabling centralized forwarding and inspection.
Exact matching of IKEv2/IPsec proposals and proper binding of the ipsec profile to the virtual-template are the most common configuration pitfalls.
In production, consider capacity, MTU, and policy scope when centralizing inspection: the firewall becomes a critical path for east-west traffic, so monitor BGP, SA status, and inspection engine statistics closely.

Tip: Use the show bgp summary and show ip route outputs frequently after each change — they quickly reveal whether the VTI/BGP-based service chain is functioning.

This completes Lesson 2: Firewall Service Chaining. In the next lesson we will cover policy-based routing and selective steering of flows through additional security services while preserving the DVTI/BGP topology.