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

Objective

In this lesson you will configure On-Box Unified Threat Defense (UTD) placement for WAN-edge Secure Firewalls by building the IPSec Virtual Tunnel Interface (VTI) and routing/BGP necessary to steer spoke traffic through a hub that enforces IPS, URL filtering, and AMP. This matters because in production networks you often want the branch-to-internet or branch-to-data-center flows to be inspected by an on-box firewall/U TD engine at the hub without breaking routing or BGP peering. Real-world scenario: a set of remote spokes terminate VTIs to a Secure Firewall hub that applies IPS signatures, URL categorization, and AMP file reputation to all traffic flowing between spokes and central resources (and the Internet).

Quick Recap

This lab continues from Lesson 1 topology. We assume the same spoke and hub Secure Firewall devices exist. This lesson adds no new physical devices — it configures the spoke VTI and BGP so traffic flows via the hub where on-box UTD policies (IPS, URL filtering, AMP) are applied.

ASCII topology (exact IPs on every interface):

[Spoke-SFW]
outside: 10.0.0.254
Tunnel1: 172.16.1.5/255.255.255.254
  -> tunnel destination 10.0.0.253

                                   VTI IPSec
                                  +---------+
10.0.0.254        <----IPSec----> |  Hub    | 10.0.0.253
(Spoke outside)                   |  SFW    |
172.16.1.5/31     <----VTI---->   |172.16.1.253 (VTI)
(Tunnel1)

Notes:
- Use the exact IP addresses above when entering configs.
- Domain examples: lab.nhprep.com
- Passwords in examples: Lab@123

Device Table

Device	Role	Outside IP	VTI IP
Spoke-SFW	Spoke firewall (FTD/ASA style CLI)	10.0.0.254	172.16.1.5/255.255.255.254
Hub-SFW	Hub firewall (FTD/ASA style CLI)	10.0.0.253	172.16.1.253 (hub VTI)

Key Concepts

VTI (Virtual Tunnel Interface) — a routable logical interface that terminates IPsec. Unlike crypto-map tunnels, VTIs present an IP interface so routing protocols (BGP) can peer over the tunnel. In production this simplifies policy distribution because routing controls path selection.
- Protocol behavior: when the VTI is configured, the device creates a tunnel interface and establishes IKEv2/IPsec SAs to the peer; the tunnel becomes effectively "up" (no interesting-traffic ACL dependency).
IKEv2 / Tunnel-group — IKEv2 pre-shared keys and tunnel-groups authenticate peers and bind IPsec parameters. Mismatched PSKs or wrong peer IPs are the most common causes of tunnel failures.
- Protocol behavior: the IKEv2 exchange negotiates SA lifetimes and cryptographic suites; on success, child IPsec SAs are installed and the tunnel interface begins to carry encrypted packets.
Routing / BGP over VTI — Use BGP to advertise spoke networks into the hub and vice-versa. BGP on top of VTI gives scale and control: hub can redistribute/advertise networks and apply UTD policies accordingly.
- Packet flow: spoke traffic destined to hub-protected destinations is routed into the VTI, encrypted, and delivered to the hub; the hub then decrypts and processes traffic with IPS/URL/AMP engines before forwarding.
On-box UTD Placement — When UTD runs on the hub, the hub inspects decrypted traffic and applies signatures, URL categories, and AMP verdicts. In production, this centralizes advanced security controls and reduces management overhead on spokes.
- Why this matters: centralization simplifies policy consistency and updates (signature/URL lists/AMP updates are applied once at hub).

Tip: Think of the VTI as a private wire between two routers (a virtual point-to-point cable). All routing protocols and security policies apply to that wire; on the hub you attach your UTD policies to the traffic arriving on that wire.

Step-by-step configuration

Step 1: Configure IKEv2 PSK and tunnel-group for the hub peer

What we are doing: We create IKEv2 pre-shared keys and a tunnel-group entry for the hub IP (10.0.0.253). This establishes mutual authentication parameters so the spoke and hub can form IKEv2 SAs. Correct PSKs and a matching tunnel-group type are required for a successful IPsec VTI.

configure terminal
ikev2 remote-authentication pre-shared-key Lab@123
ikev2 local-authentication pre-shared-key Lab@123
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
exit

What just happened: The ikev2 lines set the default IKEv2 authentication using the PSK Lab@123. The tunnel-group creates a peer-specific profile for 10.0.0.253 and associates IPsec/ikev2 attributes (also setting PSK there). This ensures the IKEv2 negotiation with 10.0.0.253 uses the configured PSK and IPsec parameters.

Real-world note: In production, use unique PSKs per peer or certificates; shared generic PSKs increase risk. Use centralized management (FMC/management plane) to rotate keys.

Verify:

show running-config tunnel-group 10.0.0.253
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key ****
 ikev2 local-authentication pre-shared-key ****

Expected output explanation: The PSK appears masked in typical output; presence of the tunnel-group confirms configuration and the type ipsec-l2l confirms a site-to-site style profile suitable for VTI establishment.

Step 2: Create the Tunnel Interface (VTI) on the spoke

What we are doing: Configure Tunnel1 as a VTI that uses the outside interface as source and points to the hub IP 10.0.0.253. Assign the tunnel IP 172.16.1.5/255.255.255.254 to create a routable interface over which BGP can peer and traffic will be directed for inspection at the hub.

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

What just happened: The interface Tunnel1 stanza created a VTI named VTI with IP 172.16.1.5/31 (255.255.255.254). tunnel source interface outside instructs the device to use the outside interface IP (10.0.0.254) as the source for IKE/IPsec exchanges. tunnel destination 10.0.0.253 defines the remote peer IP. tunnel protection ipsec profile VTI binds the IPsec profile that will protect traffic on this interface.

Real-world note: Using an interface as tunnel source enables NAT traversal and keeps public addressing separated from tunnel addressing; ensure MTU adjustments if you see fragmentation.

Verify:

show interface Tunnel1
Interface Tunnel1 "VTI", is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.1.5/31
  MTU 1500 bytes, BW 100000 Kbit/sec
  Tunnel source: interface outside (10.0.0.254)
  Tunnel destination: 10.0.0.253
  Tunnel mode: ipsec ipv4
  Tunnel protection: ipsec profile VTI

Expected output explanation: Interface shows IP and that it is administratively up and protocol up once IPsec SAs establish. If the line protocol is down, IKE/IPsec negotiation did not complete.

Step 3: Add VTI route entries to ensure proper next-hop for tunnel endpoints

What we are doing: Add route entries that make the tunnel endpoints reachable and define the next-hops for VTI-related traffic. These help the device place specific tunnel endpoints in the routing table so traffic destined for the hub VTI is forwarded properly.

configure terminal
route VTI 172.16.1.253 255.255.255.255 172.16.1.253 1
route VTI 172.16.1.254 255.255.255.255 172.16.1.254 1
exit

What just happened: The route VTI commands install host routes for the remote VTI endpoint(s). In practice, these entries ensure the firewall knows how to forward traffic to the peer VTI addresses through the tunnel layer and to populate an active route for BGP peering.

Real-world note: Platform routing syntax can vary; the intent here is to ensure per-tunnel host routes exist so control-plane protocols (like BGP) can use the link.

Verify:

show route 172.16.1.253
S   172.16.1.253/32 [1/0] via 172.16.1.253, Tunnel1

show route 172.16.1.254
S   172.16.1.254/32 [1/0] via 172.16.1.254, Tunnel1

Expected output explanation: Static (S) host routes point to the tunnel interface; these routes indicate that traffic to the remote tunnel IP will traverse Tunnel1 and that the VTI is integrated in the forwarding table.

Step 4: Configure BGP to peer with the hub over the VTI

What we are doing: Configure BGP using AS 65000 and establish neighbors with the hub VTI IPs (172.16.1.253 and 172.16.1.254). BGP is required in this design to distribute spoke networks to the hub so the hub's UTD policies inspect the proper traffic and so that redundancy is achievable.

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-address-family
exit

What just happened: This creates an iBGP configuration with neighbors at the VTI IPs. timers bgp 5 15 0 tunes the BGP keepalive to 5s and hold to 15s, aligning with the design goal for fast convergence. redistribute connected advertises directly connected networks (including the VTI subnets or other spoke networks) into BGP so the hub sees spoke prefixes.

Real-world note: Fast BGP timers can increase control-plane load; use them when rapid convergence is required and hardware can handle frequent TCP/BGP timers.

Verify:

show ip bgp summary
BGP router identifier 172.16.1.5, local AS number 65000
BGP table version is 1, main routing table version 1
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.1.253    4 65000      120     118       1    0    0 00:05:23        5
172.16.1.254    4 65000      118     119       1    0    0 00:05:21        4

Expected output explanation: The BGP neighbors are in Established state with prefixes received counted (PfxRcd). If the neighbors are not up, check Tunnel1 interface state, PSKs, and route reachability to 10.0.0.253/254.

Step 5: How the hub applies On-Box UTD (theory & verification approach)

What we are doing: We are not changing hub UTD policies in this CLI lesson (hub UTD is typically managed centrally), but we will verify that traffic is routed to the hub for inspection. This step explains how on-box UTD ties into the setup and how to confirm the hub will see and inspect traffic (IPS, URL filtering, AMP verdicts).

show ip route
show interface Tunnel1
show ip bgp

What just happened: The above show commands confirm L3 forwarding and control-plane peering so you can validate whether traffic will flow into the hub for inspection. Once BGP and the VTI are up, all traffic that the spoke routes sends to hub-protected prefixes will be encrypted into the VTI and received by the hub. The hub then decrypts and passes traffic through UTD engines (IPS/URL/AMP) before forwarding.

Real-world note: On-box UTD policies (signatures, URL categories, AMP retrospection) are often controlled via a management plane or GUI; ensure those policies are active on the hub and that license updates for signatures/AMP are current.

Verify (example outputs showing forwarding and BGP table):

show ip route
Codes: C - connected, S - static, B - BGP
C    10.0.0.0/24 is directly connected, outside
S    172.16.1.253/32 [1/0] via 172.16.1.253, Tunnel1
C    172.16.1.5/31 is directly connected, Tunnel1

show interface Tunnel1
Interface Tunnel1 "VTI", is up, line protocol is up
  Internet address is 172.16.1.5/31
  Tunnel source: interface outside (10.0.0.254)
  Tunnel destination: 10.0.0.253
  Tunnel protection: ipsec profile VTI

show ip bgp
BGP table version is 5, local router ID 172.16.1.5
   Network          Next Hop            Path
*  10.10.10.0/24     172.16.1.253        i
*  10.10.20.0/24     172.16.1.253        i

Expected output explanation: Routes learned via BGP show next-hop as the hub VTI IP (172.16.1.253), indicating traffic will traverse the hub and therefore be inspected by the hub's UTD policies.

Verification Checklist

Check 1: Tunnel interface is up — verify with show interface Tunnel1 and confirm "is up, line protocol is up".
Check 2: BGP neighbor Established — verify with show ip bgp summary and confirm prefixes received and Up/Down times.
Check 3: Traffic to protected destinations uses hub as next hop — verify with show ip route and show ip bgp that learned prefixes list 172.16.1.253 as next-hop.
Check 4: Hub UTD policies are active (hub-side step, management GUI) — verify logs or alerts on the hub that show IPS hits, URL category blocks, or AMP verdicts when test traffic is generated.

Common Mistakes

Symptom	Cause	Fix
Tunnel interface stays down or line protocol down	Mismatched IKEv2 PSKs or missing tunnel-group entry on peer	Verify PSK (use Lab@123 here), verify tunnel-group exists on peer 10.0.0.253, and re-run IKE negotiation
BGP neighbor stays Idle/Active	VTI not up or route to peer VTI missing	Confirm `show interface Tunnel1` is up and that `show route` contains host route to 172.16.1.253
Routes not reaching hub for inspection	`redistribute connected` missing or advertisement blocked	Ensure `router bgp 65000` includes `redistribute connected` or proper networks are advertised
Traffic passes around hub (not inspected)	Wrong next-hop or policy-based route sending traffic elsewhere	Check `show ip route` and `show ip bgp` to confirm next-hop is 172.16.1.253; correct routing/route-maps as required

Key Takeaways

VTI provides a routable interface for IPsec and is the recommended way to carry routing protocols (BGP) to hubs that will apply on-box UTD policies.
IKEv2 authentication, accurate tunnel destination IPs, and host-level VTI routes are the most common failure points — verify these first.
In production, the hub inspects decrypted traffic with IPS, URL filtering, and AMP; ensuring BGP and VTI are stable is essential so inspection applies to all intended flows.
Use consistent, secure authentication (unique PSKs or certificates) and central management for UTD signatures, URL databases, and AMP updates to maintain scale and consistency across the environment.

Warning: Fast BGP timers improve convergence but increase control-plane CPU load — only use them after validating device capacity and during scheduled tests or when required by SLAs.

This completes Lesson 3 — On-Box UTD Security. In the next lesson we'll demonstrate centralized policy validation and a test traffic simulation that triggers IPS signature hits and AMP file verdicts at the hub.