BGP and NAT Lab: Real-World Cisco Configs, Static NAT, PAT, and Packet

This lab was designed to simulate what a real-world edge network might look like when connecting internal private IP address space to the internet using BGP and NAT. It covers multi-AS BGP peering, static NAT, PAT, and includes real packet analysis using Wireshark. The lab also documents a few mistakes I made along the way, the troubleshooting steps I took to fix them, and why those problems mattered.

If you're trying to get solid on BGP and NAT fundamentals in a hands-on, practical way—not just memorizing config commands—this lab is for you.

Objective

The goal of this lab was to set up BGP between three autonomous systems and configure NAT at the edge routers to provide internet access to internal VPCs. Specifically, I wanted to demonstrate the difference between static NAT and dynamic NAT (PAT), and visually confirm NAT translations using Wireshark. The internal LANs were intentionally not advertised in BGP, to force NAT to be the mechanism that allows traffic to reach the internet and return correctly.

Lab Environment and Topology

This was done in EVE-NG using Cisco IOSv routers and VPCS hosts. The setup included four routers:

EdgeRouter1 (AS 65005) – connects to internal subnet 172.16.10.0/24
EdgeRouter2 (AS 65010) – connects to internal subnet 172.16.20.0/24
ISPRouter2 (AS 65005) – serves as a BGP core and handles inter-AS communication
ISPRouter1 (AS 65015) – simulates the external internet and handles DHCP on the external interface

The VPCs behind EdgeRouter1 and EdgeRouter2 were:

VPC6 – 172.16.10.2
VPC7 – 172.16.10.3
VPC8 – 172.16.20.2
VPC9 – 172.16.20.3

These were basic simulated endpoints used to generate ICMP traffic for testing NAT.

No configurations were made on the switches—they were just Layer 2 passthroughs. This lab was focused entirely on Layer 3 routing and NAT behavior.

Configuration Summary

BGP Peering with Loopbacks

BGP peering was done between all four routers using Loopback interfaces. This simulated a more stable peering relationship like what you’d expect in production, where physical interfaces may go down but logical peering should persist.

Each router had a Loopback0 interface with a /32 IP address, and static routes were created to make sure those Loopbacks were reachable from their peers. I also used ebgp-multihop and update-source Loopback0 to make sure the sessions could form across multiple hops.

I made a point not to advertise the internal LANs behind EdgeRouter1 and EdgeRouter2. This ensured that the only way for those networks to reach the internet would be through NAT.

Static NAT on EdgeRouter1

I wanted to do a clear, visual demonstration of static NAT using VPC6. I configured a static NAT mapping to translate 172.16.10.2 to a public IP address. That allowed me to show one-to-one translation and confirm that traffic from VPC6 could reach the internet, and that return traffic could find its way back.

ip nat inside source static 172.16.10.2 203.0.113.100

This was then verified using Wireshark, capturing outbound packets from ISPRouter1’s G0/0 interface.

PAT (Dynamic NAT Overload)

Once static NAT was working, I configured PAT on both EdgeRouters so the rest of the VPCs could reach the internet using their respective outside interfaces.

ip access-list extended NAT-LIST
 permit ip 172.16.10.0 0.0.0.255 any

ip nat inside source list NAT-LIST interface GigabitEthernet0/0 overload

The key here was making sure the access list matched the correct internal subnet, the NAT interface roles were set properly (inside vs. outside), and the NAT configuration used the correct overload syntax.

Packet Capture and Verification

To verify that NAT was functioning as expected, I used Wireshark on the G0/0 interface of ISPRouter1. This allowed me to observe ICMP packets as they left the network.

Before configuring NAT, I ran a ping from VPC6 to 8.8.8.8. The packet capture showed that the source IP address was 172.16.10.2—a private address. The ICMP Echo Request went out, but no reply ever came back. That’s expected, because return traffic doesn’t know how to get back to a private RFC 1918 address.

Once static NAT was configured, I repeated the ping. This time, Wireshark showed the source IP had changed to the public NAT address. ICMP Echo Replies came back with no issue.

Same process was repeated after PAT was configured, showing multiple VPCs successfully translating to the router’s public-facing IP.

Troubleshooting Mistakes and Fixes

I don’t edit out mistakes in these labs. They’re part of the process and where the real learning happens. Here’s what I ran into:

Mistake #1: Accidentally Advertised Internal Networks in BGP

Early on, I was deep into BGP config and out of habit, I advertised the internal LANs (172.16.10.0/24 and 172.16.20.0/24) into BGP. I didn’t realize it at first. When I tested NAT by pinging 8.8.8.8 from VPC6, I expected it to fail since NAT hadn’t been configured yet—but it worked.

That stopped me in my tracks.

What I didn’t account for was that BGP had already propagated the internal subnets, so return traffic had a route back. I wasn’t testing NAT—I was just testing basic routing.

To fix it, I went back to the EdgeRouters and removed the BGP advertisements for the internal networks. Then I tested again. This time, the pings failed (as expected), and I could properly demonstrate how NAT was necessary for return traffic. Wireshark confirmed that the packets were going out with the private source IPs and never making it back.

Mistake #2: Used a Subnet Mask Instead of a Wildcard Mask in the ACL

When configuring the NAT ACL for PAT, I mistakenly used a subnet mask (255.255.255.0) instead of a wildcard mask (0.0.0.255). It’s a simple mistake, but it caused a complete failure of NAT.

After applying the configuration, I went back to VPC6 and tried to ping 8.8.8.8 again. Nothing happened. No response, no error—just silence.

At that point, I ran show ip access-list on the router and immediately saw the problem. The ACL wasn’t matching any traffic because the mask was incorrect. Once I corrected it and re-applied the NAT config, everything worked as expected.

These kinds of mistakes are easy to make when you’re in the zone, but catching and fixing them is where the actual learning happens.

Lessons Learned

Don’t advertise internal NAT networks into BGP if your goal is to demonstrate NAT behavior. Doing so undermines the purpose of NAT by allowing routing to take over.
Always double-check NAT ACLs. Wildcard masks, not subnet masks.
Static NAT is useful for fixed one-to-one mappings (e.g., specific servers or hosts that need consistent external access).
PAT is great for general outbound access and simulates how most home routers work in practice.
Wireshark is a powerful way to visually confirm that NAT is working. Seeing the source address change before and after NAT helps reinforce what’s happening under the hood.
Troubleshooting is the best teacher. Making mistakes, recognizing them, and fixing them burns the lesson into memory in a way that reading or watching never could.

Files and Resources

This lab includes full router configurations, a topology screenshot, and the video walkthrough showing everything in action.

EdgeRouter1.txt
EdgeRouter2.txt
ISPRouter1.txt
ISPRouter2.txt
Topology Screenshot
Watch the lab in action on my YouTube channel HERE!
Find the GitHub Repo for this project including Config Files HERE!

Final Thoughts

I didn’t try to make this perfect. The goal wasn’t a polished demo. The goal was to get hands-on, break things, fix them, and understand what was really happening. This is the kind of lab that builds actual confidence, not just theoretical knowledge.

If you're learning networking, especially BGP and NAT, I highly recommend doing this kind of setup yourself. Don’t just read about it—build it, break it, fix it. That’s where the skills come from.

— Patrick Rivers
Bits of Progress

BGP + NAT Lab with Real Troubleshooting: Static NAT, PAT, and Packet Capture