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

Objective

In this lesson you will integrate a branch Secure Firewall (FTD-style spoke) with a cloud Secure Service Edge (SSE) offering to enable cloud-delivered security: Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), and Zero Trust Network Access (ZTNA). You will build the secure branch-to-SSE connectivity using VTI-based IPsec tunnels, peer with the Secure Access control plane using BGP, and optionally steer Internet-bound traffic into the SSE. This matters in production because steering branch Internet through a cloud SSE centralizes web controls (DLP, CASB, SWG), reduces lateral exposure, and enables ZTNA for private app access from branches. Real-world scenario: a retail branch sends Internet and private app traffic into SSE PoPs for content control and for Zero Trust access to corporate SaaS and private data-center apps.

Quick Recap

Reference topology (from Lesson 1) is reused here. No new devices are added in this lesson; we will configure the Branch FTD (FTD-Spoke) to peer with Secure Access data-centers using the VTI addresses shown in the reference material.

ASCII Topology (exact IPs shown on each link)

[Branch FTD - FTD-Spoke]
   outside(if to ISP) --- 64.x.14.188/30 --- [ISP Gateway 64.x.14.254]
   Tunnel(VTI) Primary: 169.254.0.6/30 <------> 169.254.0.5 (Secure Access DC Primary)
   Tunnel(VTI) Secondary: 169.254.0.10/30 <--> 169.254.0.9 (Secure Access DC Secondary)
   Branch Network: 100.73.x.0/20 (advertised)

Device Table

Device	Role	Management/Relevant IP
FTD-Spoke	Branch Secure Firewall / VTI endpoint	outside -> e.g., 64.x.14.188 (local ISP IP)
Secure Access DC (Primary)	SSE PoP VPN endpoint	169.254.0.5 (VTI peer)
Secure Access DC (Secondary)	SSE PoP VPN endpoint	169.254.0.9 (VTI peer)
ISP Gateway	Upstream Internet Provider	64.x.14.254

IP Addressing Table (exact addresses used in this lesson)

Interface	IP Address
Branch VTI Primary	169.254.0.6/30
Secure Access Primary	169.254.0.5/30
Branch VTI Secondary	169.254.0.10/30
Secure Access Secondary	169.254.0.9/30
Branch LAN	100.73.x.0/20
ISP Gateway	64.x.14.254

Important: Use lab.nhprep.com as the domain in any example FQDNs. Use Lab@123 for passwords when required.

Key Concepts

Virtual Tunnel Interface (VTI) — A VTI provides a routable virtual interface for IPsec tunnels. Think of VTIs as a network cable that hands you a local IP on one end and the peer IP on the other; you run routing protocols (BGP) or static routes over that interface rather than manually mapping interesting traffic ACLs. In production, VTIs simplify routing and allow dynamic routing (BGP) to exchange prefixes with SSE PoPs.
BGP over VTI — When you run BGP over a VTI, the routers exchange route prefixes (including an optional default route). In our environment the Secure Access PoP advertises a default route (0.0.0.0/0) and RAVPN subnets. When BGP installs 0.0.0.0/0 as best, the FTD may forward Internet-bound traffic to the SSE for inspection (SWG/CASB enforcement).
Tunnel addressing best practices — Use link-local / private tunnel IPs to avoid colliding with customer subnets. The reference recommends: 169.254.0.6/30 for Primary and 169.254.0.10/30 for Secondary. These addresses are for the VTI endpoints only; they are not loopbacks.
IPsec & Identity — Use IKEv2 with a stable identity (for example, “Email ID”) as recommended by SSE. Use a common pre-shared key for Hub & Spoke topologies if specified by your Secure Access design. In production, an identity that matches the controller configuration prevents tunnel mismatch and simplifies automation.
Traffic steering to SSE — You can steer branch Internet traffic into SSE either by receiving a BGP default from Secure Access or by installing a local default route pointing to the VTI peer (static). In production, receiving the default via BGP is cleaner because it allows PoPs to load-balance and change forwarding without reconfiguring branches.

Step-by-step configuration

Step 1: Create VTI interfaces (Primary and Secondary)

What we are doing: Build two VTI tunnel interfaces on the branch firewall. These VTIs will terminate IPsec tunnels to the Secure Access PoPs. VTIs provide a simple, routable next-hop for routing and BGP peering.

configure terminal
!
! Create primary VTI
interface Tunnel1
 description outside_static_vti_1 to SecureAccess-Primary
 ip address 169.254.0.6 255.255.255.252
 ip mtu 1400
 no shutdown
!
! Create secondary VTI
interface Tunnel2
 description outside_static_vti_2 to SecureAccess-Secondary
 ip address 169.254.0.10 255.255.255.252
 ip mtu 1400
 no shutdown
exit

What just happened: Each interface Tunnel command instantiated a logical tunnel interface. Assigning the 169.254.x.x addresses provides each VTI with a unique /30 point-to-point address. ip mtu reduces the MTU to allow IPsec encapsulation without fragmentation problems. no shutdown ensures the interface is administratively up; physical IPsec negotiation must complete for the interfaces to be operational.

Real-world note: In production, monitor MTU carefully—IPsec overhead often requires reducing MTU on the VTI to avoid fragmentation of user traffic.

Verify:

show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Tunnel1                    169.254.0.6     YES manual up                    up
Tunnel2                    169.254.0.10    YES manual up                    up
GigabitEthernet0/0         64.x.14.188     YES dhcp   up                    up

Step 2: Configure BGP peering to Secure Access PoPs

What we are doing: Establish BGP sessions to the Secure Access primary and secondary peers on their tunnel IPs. BGP will carry the branch prefixes to the SSE and may provide a default route back into the branch.

configure terminal
router bgp 64512
 bgp log-neighbor-changes
 neighbor 169.254.0.5 remote-as 64512
 neighbor 169.254.0.9 remote-as 64512
!
! Advertise the branch LAN to Secure Access
network 100.73.0.0 mask 255.255.240.0
exit

What just happened: router bgp 64512 enters BGP configuration for the branch ASN. The neighbor statements configure peering with the Secure Access PoP tunnel IPs; in this reference the PoPs use ASN 64512 as well (common in Hub & Spoke designs). The network statement advertises the branch LAN (100.73.x.0/20) into BGP so the SSE PoPs (and any connected hubs) know how to reach branch hosts. BGP will use the VTI to establish TCP sessions (port 179) to the peers.

Real-world note: In many deployments Secure Access PoPs use the same ASN as the branch for iBGP-style designs, or a different ASN for eBGP. Always confirm the required ASN with your SSE design.

Verify:

show bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 530
Paths: (2 available, best #2, table default)
Advertised to update-groups:
64512 64512 169.254.0.9 from 169.254.0.9 (169.254.0.9)
  Origin IGP, localpref 100, valid, external
64512 169.254.0.5 from 169.254.0.5 (169.254.0.5)
  Origin IGP, localpref 100, valid, external, best

Explain: The show bgp output demonstrates that BGP has learned a default route (0.0.0.0/0) from both peers. The best path selection shows the path via 169.254.0.5 as best.

Step 3: Accept & install default route (optional steering of Internet traffic to SSE)

What we are doing: When SSE advertises a default route, the branch can rely on that BGP route to forward Internet-destined traffic to the SSE PoP. Alternatively, a local static default may be used to prefer one path. Here we show the branch using the BGP-learned default (no additional static required) and verify that the routing table points the default at the VTI peer.

! No extra commands if using BGP-learned default.
! Verify routing table to confirm default via Secure Access
show route
B* 0.0.0.0/0 [20/0] via 169.254.0.5
B 100.73.x.0 255.255.240.0 [20/0] via 169.254.0.5
S 35.171.x.188 255.255.255.255 [1/0] via 64.x.14.254, outside
S 217.195.x.188 255.255.255.255 [1/0] via 64.x.14.254, outside
V 1.0.1.1 255.255.255.255 connected by VPN (advertised), outside_static_vti_1
V 1.0.2.1 255.255.255.255 connected by VPN (advertised), outside_static_vti_2

What just happened: The show route output demonstrates the BGP-installed default route (B* 0.0.0.0/0) pointing to the primary Secure Access peer 169.254.0.5. Branch networks are also installed pointing toward the same peer. Static routes to specific cloud IPs (examples shown) remain pointed at the ISP interface to avoid tunnel flapping during control-plane or path changes.

Real-world note: Many designs add static host routes to SSE endpoint IPs via the ISP next-hop to ensure the IPsec control-plane stays reachable even if the default is pointed into the SSE.

Verify:

show ip route 0.0.0.0
Routing entry for 0.0.0.0/0
  Known via "bgp", distance 20, metric 0
  * 169.254.0.5, via Tunnel1, 00:02:45

Step 4: Ensure private application prefixes and ZTNA services are advertised (RAVPN subnets)

What we are doing: Advertise any private subnets or RAVPN ranges that should be reachable through Secure Access for ZTNA access. This allows SSE to enforce application-level policies (ZTNA) for those subnets from the PoP.

configure terminal
router bgp 64512
 network 1.0.1.1 mask 255.255.255.255
 network 1.0.2.1 mask 255.255.255.255
exit

What just happened: The network statements cause the BGP process to originate route entries for the RAVPN-managed IPs (examples 1.0.1.1 and 1.0.2.1). The SSE PoP will receive and advertise these subnets into its environment so that specific private apps or ZTNA services are reachable and subject to SSE policy enforcement.

Real-world note: In deployments that use ZTNA, the cloud PoP must know the private application endpoints so it can broker authenticated, least-privilege connections (often via connector or reverse proxy components).

Verify:

show route | include 1.0.1.1
V 1.0.1.1 255.255.255.255 connected by VPN (advertised), outside_static_vti_1
show route | include 1.0.2.1
V 1.0.2.1 255.255.255.255 connected by VPN (advertised), outside_static_vti_2

Step 5: Operational checks and basic troubleshooting

What we are doing: Confirm BGP adjacency state, that the VTIs are carrying traffic, and ensure selective static routes for SSE endpoint IPs are present via ISP to prevent IPsec flapping.

! Check BGP neighbors
show ip bgp neighbors 169.254.0.5
show ip bgp neighbors 169.254.0.9

! Check tunnel interface counters
show interface Tunnel1
show interface Tunnel2

What just happened: show ip bgp neighbors reveals the adjacency state (Established) and counters for BGP FSM. The show interface TunnelX commands give you packet and byte counters, errors, and whether the tunnels are up. This helps detect issues such as neighbor flapping, MTU-induced fragmentation, or traffic being blackholed.

Real-world note: If a control-plane route (like a Secure Access endpoint) is advertised and then lost because the default route was pointed into the SSE, you can lock the endpoint reachability by configuring a static route to the endpoint via the ISP next-hop.

Verify (example expected outputs):

! Expected neighbor output summary - example
BGP neighbor is 169.254.0.5, remote AS 64512, local AS 64512, external link
State: Established, up for 00:15:32
  Last read 00:00:10, last write 00:00:02
  Received 12 messages, 0 notifications, 0 updates
  Sent 8 messages, 0 notifications, 3 updates

! Expected interface summary - example
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 169.254.0.6/30
  MTU 1400 bytes, BW 100000 Kbit/sec, DLY 50000 usec
  RX packets 12345, TX packets 9876, RX errors 0, TX errors 0

Tunnel2 is up, line protocol is up
  Internet address is 169.254.0.10/30
  MTU 1400 bytes, BW 100000 Kbit/sec, DLY 50000 usec
  RX packets 2345, TX packets 1987, RX errors 0, TX errors 0

Verification Checklist

Check 1: BGP adjacency with Secure Access Primary (169.254.0.5) is in Established state. Verify with show ip bgp neighbors 169.254.0.5.
Check 2: Branch LAN (100.73.x.0/20) is advertised and present on the Secure Access routing table. Verify locally with show bgp and confirm the network 100.73.0.0 is present.
Check 3: Default route (0.0.0.0/0) is installed and points via 169.254.0.5 (if steering Internet to SSE). Verify with show route and show ip route 0.0.0.0.
Check 4: RAVPN/application prefixes (1.0.1.1, 1.0.2.1) are advertised and show as connected by VPN entries. Verify with show route | include 1.0.1.1.

Common Mistakes

Symptom	Cause	Fix
BGP neighbor stuck in Idle/Active	VTI not up or IPsec not established; MTU/fragmentation preventing TCP session	Verify VTI interfaces are up (`show ip interface brief`), verify IPsec (if available), reduce MTU on VTI, ensure ISP permits ESP/TCP179; add static route to PoP via ISP if default points into tunnel
Default route installed but Internet unreachable	PoP advertises default but no forwarding policy or proxy configured on SSE	Confirm SSE PoP is configured to accept/forward Internet for branch; fall back to local ISP for Internet if needed or request PoP policy change
RAVPN prefixes missing on PoP	network statements not advertised or wrong mask	Check `router bgp` network statements and masks; ensure local prefix exists in routing table or is redistributed so BGP can advertise it
Tunnel flapping when default points into SSE	Control-plane reachability to PoP lost because default routes packets into the tunnel	Add specific static routes to PoP IPs pointing via ISP next-hop to stabilize IPsec control plane

Key Takeaways

VTI-based IPsec tunnels give you a routable interface to run BGP and steer traffic to cloud SSE PoPs; use the recommended tunnel addresses 169.254.0.6/30 (primary) and 169.254.0.10/30 (secondary).
BGP over VTI enables the SSE to advertise a default route and RAVPN subnets; in production this centralizes SWG/CASB/DLP and ZTNA enforcement.
Always protect IPsec control-plane reachability (for example, static routes to SSE endpoint IPs via ISP) when you install a BGP default that sends Internet traffic into the SSE — otherwise the tunnel can become a black hole.
Monitor MTU and interface counters on VTIs; IPsec overhead frequently requires MTU tuning to avoid fragmentation that impacts user traffic.

Tip: Think of the SSE PoP as an upstream secure Internet gateway — by advertising routes and using VTIs you plug your branch into a secure filter and Zero Trust broker. In production, align BGP/route preferences and endpoint reachability rules before steering user traffic into the cloud to avoid outages.

End of Lesson 4: Secure Service Edge (SSE)