> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # VRF-Aware NAT on Cisco IOS XE - URL: https://www.pinglabz.com/vrf-aware-nat-ios-xe/ - Published: 2026-07-12T09:34:23.000Z - Updated: 2026-08-24T09:42:20.000Z - Description: Two customers with identical 10.5.5.0/24 subnets reach one shared exit through a single router. VRF-aware NAT on IOS XE keeps them separate, and this CML lab build shows two translation tables holding identical inside-local addresses. - Author: Jaime - Tags: IP Services, Network Security, Labs, CCIE, #Import 2026-08-01 19:54 Two customers connect to your router. Both, entirely by coincidence, use 10.5.5.0/24 internally. Both have a host at 10.5.5.50\. Both need to reach the same shared service out one exit interface. In a normal routing table this is impossible - you cannot have two 10.5.5.50s. VRF-aware NAT makes it not just possible but clean: each customer lives in its own VRF, and NAT translates each to a distinct public address, keeping the two identical private hosts completely separate. This article builds exactly that in a CML lab and shows the two translation tables holding identical inside-local addresses. It closes the services domain for the IP-services cluster. For the fundamentals, see the [IP services pillar](https://www.pinglabz.com/ip-services/). ## The problem: overlapping address space Overlapping addresses are the norm, not the exception, the moment you aggregate multiple independent networks: - A managed-services provider onboards customers who all use RFC1918 space and inevitably collide - everyone has a 10.0.0.0/8 or a 192.168.1.0/24. - A merger brings two companies together, both of which built their networks assuming they owned 10.0.0.0/8. - A multi-tenant environment where tenants must be isolated but reach shared services. VRFs solve the isolation - each tenant gets its own routing table, and two 10.5.5.0/24s in two VRFs never see each other. But the moment they need to reach a *shared* destination out a common interface, you have a problem: the shared side has one routing table, and it cannot distinguish two identical source addresses. That is where NAT comes in, and it has to be VRF-aware. ## The lab R1 is the shared gateway. It has two VRFs - RED (RD 65000:1) and BLUE (RD 65000:2) - each connected to a customer whose network is **10.5.5.0/24, with a host at 10.5.5.50 in both**. The exit interface toward the shared service (192.168.99.100) is in the global table. Each VRF NATs to its own public address. ``` ! Distinct global pools, one per VRF ip nat pool RED-POOL-NAT 192.168.99.201 192.168.99.201 prefix-length 24 ip nat pool BLUE-POOL-NAT 192.168.99.202 192.168.99.202 prefix-length 24 ! The VRF keyword is what makes NAT VRF-aware ip nat inside source list RED-ACL pool RED-POOL-NAT vrf RED overload ip nat inside source list BLUE-ACL pool BLUE-POOL-NAT vrf BLUE overload ! Interfaces interface Ethernet0/1 vrf forwarding RED ip nat inside interface Ethernet0/2 vrf forwarding BLUE ip nat inside interface Ethernet0/0 ip nat outside ``` **The `vrf RED` / `vrf BLUE` keyword on the NAT statement is the whole feature.** It tells NAT which VRF each translation belongs to, so the two identical inside-local addresses land in two separate translation tables and get two separate public addresses. Without it, the second 10.5.5.50 would collide with the first. ## Both customers, simultaneously, with identical hosts Both customer hosts source from 10.5.5.50 and reach the same shared service: ``` RED-CE#ping 192.168.99.100 source Loopback5 repeat 3 Packet sent with a source address of 10.5.5.50 !!! Success rate is 100 percent (3/3) BLUE-CE#ping 192.168.99.100 source Loopback5 repeat 3 Packet sent with a source address of 10.5.5.50 !!! Success rate is 100 percent (3/3) ``` Two hosts with the same IP, both working. And here is the proof - the two VRF translation tables, holding identical inside-local addresses translated to distinct global addresses: ``` R1#show ip nat translations vrf RED Pro Inside global Inside local Outside local Outside global icmp 192.168.99.201:1024 10.5.5.50:0 192.168.99.100:0 192.168.99.100:1024 R1#show ip nat translations vrf BLUE Pro Inside global Inside local Outside local Outside global icmp 192.168.99.202:1024 10.5.5.50:0 192.168.99.100:0 192.168.99.100:1024 ``` Read those two blocks side by side. The **inside local** is 10.5.5.50 in both - the same host address in each customer. The **inside global** is 192.168.99.201 for RED and 192.168.99.202 for BLUE - distinct public addresses. The shared service sees two different sources and can reply to each correctly. The VRF is what keeps the two 10.5.5.50 translations from colliding. That is VRF-aware NAT in one screen. ## The house quirk: ICMP translations expire fast When you verify VRF-aware NAT with a ping, you have a small window. ICMP translations time out in about a minute, and if you ping, wait, then run `show ip nat translations`, the entry may already be gone and you will think it failed. The fix is to check the table *promptly* after generating traffic - or, in a lab, run the ping and the show command in quick succession. For a persistent view, use a longer-lived protocol (TCP) or a sustained ping. ## Direction of translation: which side is which The mental model people get wrong: with VRF-aware NAT for overlapping customers, the **inside** interfaces are the customer VRF links (the overlapping addresses), and the **outside** interface is the shared exit. You are translating the customers' overlapping addresses *into* distinct addresses the shared side can use. So `ip nat inside` goes on the VRF interfaces, `ip nat outside` on the shared interface, and `ip nat inside source` translates on the way out. If the shared service needs to *initiate* to a customer host, that is a different NAT (a static `ip nat outside source static ... vrf` or a destination NAT), because now you are translating the shared side's view of a customer address on the way in. Most designs only need the outbound direction, which is what the lab shows. ## Where VRF-aware NAT fits Shared services access Multiple tenants with overlapping space all need to reach a shared DNS, NTP, or monitoring service. Each NATs to a distinct address at the shared boundary. Merger integration Two companies with colliding 10.0.0.0/8 estates put each in a VRF and NAT at the interconnect, buying time to renumber (or never renumbering). MPLS L3VPN extranet A provider offering shared-services access to customers whose VPNs overlap, doing the translation on the PE at the extranet boundary. ## Troubleshooting 1. **Overlapping hosts colliding?** The `vrf` keyword is missing on the `ip nat inside source` statement, or wrong. Without it, NAT treats both as the same and they collide. `show ip nat translations vrf X` for each VRF. 2. **Translation table empty right after a ping?** ICMP timeout - check promptly, or use TCP for a persistent entry. 3. **One VRF works, the other does not?** Check that both interfaces have `ip nat inside` in the right VRF, and that each has its own pool and ACL. Reusing one pool across two VRFs defeats the isolation. 4. **Return traffic failing?** The shared side needs a route back to the NAT pool addresses (192.168.99.201/202), and R1 needs routes in each VRF toward the customer prefixes. ## Key takeaways - VRF-aware NAT lets multiple tenants with **overlapping address space** reach a shared destination, by translating each VRF to a distinct global address at the boundary. - The `vrf RED` / `vrf BLUE` keyword on `ip nat inside source` is the entire feature - it keeps the two identical inside-local addresses in separate translation tables. - Verified: two hosts both at 10.5.5.50, in RED and BLUE, translated to 192.168.99.201 and 192.168.99.202, both reaching the same shared service simultaneously. - Inside = the overlapping customer VRF interfaces; outside = the shared exit. Translate on the way out. - ICMP translations expire fast - check the table promptly after generating traffic, or use TCP. - The classic use cases are shared-services access, merger integration, and MPLS L3VPN extranet with overlapping VPNs. Next: [the IOS DHCP server in depth - options, classes, and manual bindings](https://www.pinglabz.com/ios-dhcp-server-in-depth/). The full cluster index lives on the [IP services pillar](https://www.pinglabz.com/ip-services/).