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

Objective

In this lesson you will configure routing and NAT on an FTD-based firewall: add static routes, enable BGP peering for dynamic routing, and create both automatic (object-based) and manual NAT rules. These are essential for making the firewall participate in enterprise routing domains and for translating internal addresses to routable public addresses. In production networks, correct routing plus NAT ensures remote users and internet services are reachable while preserving address hygiene and inspection policies — for example, connecting branch firewalls to an ISP via BGP while NATing internal server addresses for internet access.

Topology (recap from Lesson 1)

The topology used throughout this lab includes two firewalls (FW-1, FW-2), two route-reflectors (CR-1, CR-2), an ISP peer, and internal networks. This lesson adds/uses the BGP neighbors and internal network prefixes shown below.

ASCII topology (interfaces show exact IPs used in this lesson):

FW-1 (FTD) ISP Router Gig0/0: 169.254.10.254 ---- Internet ---- 85.232.240.179 LAN: 10.16.24.1/24 (eBGP/iBGP peering)

Server Network: 10.16.24.0/24 — connected behind FW-1

Notes:

BGP router-id used: 169.254.10.254
Local AS for FTD: 65055
IPv6 BGP neighbor present: 2001:1A68:2C:2::179

Device Table

Device	Role	Relevant IPs
FW-1	FTD firewall (this lab device)	Router-id 169.254.10.254, local AS 65055
ISP	Upstream BGP peer	85.232.240.179 (IPv4), 2001:1A68:2C:2::179 (IPv6)
Servers	Internal hosts	10.16.24.0/24

Tip: Use the emergency/local CLI if central management is unavailable to apply static routes or BGP temporarily — this is provided for FMC-down recovery scenarios.

Quick Recap

You already have the base firewall deployed and interfaces configured.
This lesson focuses on:
- Adding static routes for specific prefixes (internal or remote).
- Enabling BGP peering with the ISP using AS 65055 and the listed neighbors.
- Creating NAT rules: automatic/object NAT for common host translation, and manual NAT for more granular control.

Key Concepts

Static routing: Manually configured routes that send traffic for a prefix to a specified next-hop. Use static routes for simple, predictable paths or temporary fixes when dynamic routing is unavailable.
- Packet flow: FTD checks its routing table; if a static route matches, packets are forwarded to the configured next-hop on that interface.
BGP (Border Gateway Protocol): A path-vector dynamic routing protocol that advertises prefixes between ASes. BGP maintains a table of network prefixes and path attributes and uses TCP (port 179) for neighbor sessions.
- When a BGP neighbor session is established, full routing updates are exchanged; thereafter incremental updates propagate route changes.
NAT (Network Address Translation): Translates IP addresses/ports between inside and outside realms. Object (auto) NAT is commonly used to translate a host or network to an interface or public IP. Manual NAT gives full control over order and matching.
- In production, NAT affects how routes are selected and firewall inspection behaves — translated addresses must be routable and reachable by peers.
Router ID and Address Families: BGP uses a router-id (an IPv4 address) to uniquely identify a speaker. BGP can run IPv4 and IPv6 address families independently; both require peering and advertise prefixes in their own AF.

Step-by-step configuration

Step 1: Configure a static route to the server network

What we are doing: Add a static route so the FTD knows where to send traffic destined for the 10.16.24.0/24 server network. Static routes are essential when a directly connected interface is missing or to provide a simple deterministic path.

configure terminal
ip route 10.16.24.0 255.255.255.0 169.254.10.253
end
write memory

What just happened:

ip route 10.16.24.0 255.255.255.0 169.254.10.253 creates a persistent routing table entry sending traffic for 10.16.24.0/24 to next-hop 169.254.10.253.
This tells the FTD to forward matching traffic toward that next hop; if the next hop is reachable, packets will be forwarded at Layer 2 toward it.
write memory saves the configuration so it survives reboots.

Real-world note: Static routes are commonly used for simple branch-to-hub tunnels or when a next-hop is a non-routing device. Prefer dynamic routing for larger or changing topologies.

Verify:

show ip route

Expected output (excerpt showing the static route):

Gateway of last resort is not set

S    10.16.24.0/24 [1/0] via 169.254.10.253
      169.254.10.253 is directly connected, GigabitEthernet0/0

Step 2: Configure BGP and peer with the ISP (IPv4 neighbor)

What we are doing: Enable BGP with local AS 65055, set router-id 169.254.10.254, and configure the IPv4 neighbor 85.232.240.179. BGP allows the firewall to exchange routes with the ISP so remote prefixes are learnable and local prefixes can be advertised.

configure terminal
router bgp 65055
 bgp router-id 169.254.10.254
 neighbor 85.232.240.179 remote-as 65055
 address-family ipv4 unicast
  neighbor 85.232.240.179 activate
 exit-address-family
exit
end
write memory

What just happened:

router bgp 65055 enters BGP configuration for AS 65055.
bgp router-id 169.254.10.254 sets the BGP router-id, which uniquely identifies this BGP speaker in the session establishment and route selection process.
neighbor 85.232.240.179 remote-as 65055 configures the peer; here the neighbor AS equals local AS (iBGP or route-reflector scenario as in many lab topologies).
Enabling the IPv4 address-family activates IPv4 peering with that neighbor; BGP will form a TCP session on port 179 and exchange full routing information initially, followed by incremental updates.

Real-world note: Ensure TTL, MD5, and route policies are correctly set for production BGP; misconfigured AS numbers or neighbor IPs prevent session establishment.

Verify:

show bgp ipv4 unicast summary

Expected output (this lab uses representative output):

BGP router identifier 169.254.10.254, local AS number 65055
BGP table version is 984072, main routing table version 984072
983198 network entries using 196639600 bytes of memory
983198 path entries using 78655840 bytes of memory
155154/155133 BGP path/bestpath attribute entries using 32272032 bytes of memory
173187 BGP AS-PATH entries using 9067894 bytes of memory
15389 BGP community entries using 1229164 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 317864530 total bytes of memory
BGP activity 3584448/2388995 prefixes, 3584909/2389459 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent TblVer  InQ OutQ Up/Down State/PfxRcd
85.232.240.179  4 65055 155728 155733 984072  0   0 00:03:16 983198

Step 3: Enable BGP IPv6 neighbor

What we are doing: Activate the IPv6 address-family and peer with the IPv6 neighbor 2001:1A68:2C:2::179. This enables exchange of IPv6 routes over BGP.

configure terminal
router bgp 65055
 address-family ipv6
  neighbor 2001:1A68:2C:2::179 remote-as 65055
  neighbor 2001:1A68:2C:2::179 activate
 exit-address-family
exit
end
write memory

What just happened:

The IPv6 address-family section configures BGP to carry IPv6 prefixes for the specified neighbor.
Neighbor activation establishes a BGP TCP session over IPv6, and after the session forms, IPv6 routes will be exchanged.
BGP maintains separate tables for IPv4 and IPv6; both must be configured independently.

Real-world note: In dual-stack environments, remember to configure both AFs and ensure IPv6 reachability to the neighbor before expecting BGP session establishment.

Verify:

show bgp ipv6 unicast summary

Expected output (representative excerpt):

BGP router identifier 169.254.10.254, local AS number 65055
BGP table version is 212960, main routing table version 212960
212252 network entries using 50091472 bytes of memory
212252 path entries using 22074208 bytes of memory
54970/54970 BGP path/bestpath attribute entries using 11433760 bytes of memory
173187 BGP AS-PATH entries using 9067894 bytes of memory
15389 BGP community entries using 1229164 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 93896498 total bytes of memory
BGP activity 3584448/2388995 prefixes, 3584909/2389459 paths, scan interval 60 secs
Neighbor                   V    AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:1A68:2C:2::179        4 65055 55611 55617  212960 0   0 00:05:30 200000

Step 4: Configure an automatic/object NAT for an internal host

What we are doing: Create an automatic NAT (object-based) that translates an internal server address to a public address (PAT/SNAT) when leaving to the internet. Object NAT is simple and usually applied when you want traffic from an internal object to be translated to an interface or public IP with minimal rule ordering complexity.

configure terminal
object network OBJ_SERVER
 host 10.16.24.10
 nat (inside,outside) dynamic interface
end
write memory

What just happened:

object network OBJ_SERVER creates a network object for the internal host 10.16.24.10.
nat (inside,outside) dynamic interface tells the device to translate source addresses from inside to the firewall's outside interface address when traffic leaves to the outside. This is an automatic NAT entry tied to the object.
Object NATs are preferred for ease of management and are evaluated according to the device NAT order (object NATs are applied before manual NAT in many deployments).

Real-world note: Auto NAT with dynamic interface is convenient for small networks or per-host translations, but for public-facing services you may require static/manual NAT to map a public IP to an internal server.

Verify:

show nat

Expected output (representative output showing an auto/object NAT entry):

Auto NAT (object) entries:
Object: OBJ_SERVER
 Type: network
 Host: 10.16.24.10
 NAT: inside -> outside dynamic interface (translated to outside interface IP 203.0.113.10)

Step 5: Create a manual NAT rule for a DMZ service

What we are doing: Add a manual static NAT to map a public IP to an internal DMZ server for inbound services (e.g., HTTP). Manual NAT gives explicit control over source/destination and ordering, useful for public-facing resources.

configure terminal
object network OBJ_DMZ_WEB
 host 10.16.24.20
 nat (outside,inside) static 198.51.100.20
end
write memory

What just happened:

object network OBJ_DMZ_WEB defines the internal web server IP.
nat (outside,inside) static 198.51.100.20 creates a static destination translation: traffic to 198.51.100.20 on the outside will be DNATed to 10.16.24.20 on the inside. This enables inbound reachability.
Manual/static NAT ensures a predictable public-to-private mapping for services.

Real-world note: When exposing services to the internet, combine NAT with access policies and inspection rules; otherwise services may be left unprotected.

Verify:

show nat

Expected output (representative output showing manual/static NAT entry):

Manual NAT entries:
Object: OBJ_DMZ_WEB
 Type: network
 Host: 10.16.24.20
 NAT: outside -> inside static 198.51.100.20

Verification Checklist

Check 1: BGP IPv4 session is established — verify with show bgp ipv4 unicast summary and confirm neighbor 85.232.240.179 shows Up and a non-zero PfxRcd.
Check 2: Static route to 10.16.24.0/24 present — verify with show ip route and confirm the S-entry for 10.16.24.0/24.
Check 3: NAT translations in effect — use show nat and confirm both the auto/object NAT for OBJ_SERVER and the manual NAT for OBJ_DMZ_WEB.

Common Mistakes

Symptom	Cause	Fix
BGP neighbor stuck in Idle or Active	Remote reachability or wrong neighbor IP/AS	Verify IP connectivity to neighbor; check remote-as value and ensure TCP/179 is not blocked
Routes not forwarded even though static route exists	Next-hop is unreachable or interface down	Ping next-hop; ensure interface to next-hop is up and ARP resolves; fix link or next-hop
Inbound traffic not reaching internal server after static NAT	Access policy or NAT order blocks translation	Confirm NAT order and that manual NAT is active; ensure firewall access rules permit the inbound service
Translated traffic not returning	Asymmetric routing or no return path from peer	Ensure return path exists and source addresses are routable; use route maps or static return routes if necessary

Key Takeaways

Static routes provide deterministic forwarding and are useful for small or temporary configurations; dynamic routing (BGP) scales for large, multi-AS environments.
BGP requires correct AS numbers, router-id, and reachability; IPv4 and IPv6 address-families are configured separately.
Object (auto) NAT is quick and manageable for common source translations; manual/static NAT is necessary for published services and precise translation control.
Always verify both routing and NAT with show commands — routing table entries, BGP neighbor summaries, and NAT translation lists are your primary troubleshooting tools.

Warning: In production, avoid applying NAT changes without considering existing policies and failover behavior. NAT and dynamic routing interact — translated addresses must be routable and consistent across HA pairs.

This completes Lesson 6: "FTD Routing and NAT". In the next lesson we will cover advanced inspection and ACL integration with NAT and BGP policies.