VRF-Aware NAT on Cisco IOS XE

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.

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

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. The full cluster index lives on the IP services pillar.