Global to VRF NAT Issue

[ebng]

TLDR: When I try to NAT from the global routing instance to a VRF using an IP address in the same subnet as the router, the router doesn't reply to ARP requests for the NAT'd IP.

I'm having some issues with one-to-one static NAT entries when going from the global routing instance to a VRF and could use some help.  I originally had this issue with an ISR 44551-X, but have since tried testing it out in the lab using a CSR1000V and have the same issues.  I've tried to keep things pretty simple.  I have a server with an IP address of 100.19.0.52 attached to interface GigabitEthernet2 on my CSR1000V (call it R1).  Interface GigabitEthernet2 is part of the global routing instance and is my inside NAT interface:

interface GigabitEthernet2
ip address 100.19.0.33 255.255.255.224
ip nat inside
negotiation auto
no mop enabled
no mop sysid

Interface GigabitEthernet3 is in the EXTERNAL vrf and is my outside NAT interface:

interface GigabitEthernet3
ip vrf forwarding EXTERNAL
ip address 200.168.1.1 255.255.254.0
ip nat outside
negotiation auto
no mop enabled
no mop sysid

I want my internal server to be able to reach equipment in the same subnet as GigabitEthernet3, so I've created the following static route:

ip route 200.168.0.0 255.255.254.0 GigabitEthernet3

I want that traffic from that server to NAT to an IP address also in the same subnet as GigabitEthernet3 so I have the following statement:

ip nat inside source static 100.19.0.52 200.168.1.190

Now, GigabitEthernet3 is connected to another CSR1000V router (we'll call it R2) with an IP address of 200.168.1.252.  When I try to ping R2 from my server, I can see the ICMP request make it to R2.  R2, in turn, sends an ARP request for 200.168.1.252, but receives no response from R1.  After reading another post, I tried putting in the following on R1 to attempt to resolve the issue:

arp vrf OUTSIDE 200.168.1.190 <MAC address of GigabitEthernet2> arpa alias

When I did this, R1 would respond to ARP requests from R2 for 200.168.1.190, allowing R2 to send ICMP replies.  Unfortunately, those replies did not make it back to the server so I removed the command.  As one final test, I removed the nat command from above and replaced it with the following:

ip route 200.168.0.0 255.255.254.0 GigabitEthernet3

When I do that, my server can now ping R2, but this doesn't exactly solve my problem.  At this point, I'm fairly stuck and could use some assistance.   I'm attaching my complete config in case that sheds light on anything.  I appreciate any help I can get on this.  Thanks in advance.

[ebng]

No change.  I see the traffic getting NAT'd out 200.168.190 as it leaves Gig3.  R2 then ARPs for 200.168.190, but receives no reply.  I think there's a typo (or two) in the lines you wanted me to add, but I'm not 100% certain what you're trying to accomplish.  There's no device with the IP 100.19.0.34.  Did you maybe mean something like this?

ip route 200.168.1.190 255.255.255.255 100.19.0.52
ip route vrf EXTERNAL 100.19.0.32 255.255.255.224 GigabitEthernet2 100.19.0.33 global

[paul driver]

Hello

Yes that was probably towards a type on my part but i used a couple of assumptions ie: nexthop addressing.
What you are missing is a static route pointing towards External interface nexthop for the host that wants to access the natted address and the correct next hop ip of your

ip route x.x.x.x. y.y.y.y GigabitEthernet3 200.168.1.2 (assuming 200.168.1.2 is the next hop ip address )
ip route vrf EXTERNAL 100.19.0.32 255.255.255.224 GigabitEthernet2 100.19.0.52

[ebng]

OK, I tossed this in to my config:

ip route vrf EXTERNAL 100.19.0.32 255.255.255.224 GigabitEthernet2 100.19.0.52

I did not add the default route, though, as that's not actually what I'm trying to accomplish.  I literally just want my global routing instance to be able to reach that 200.168.0.0/23 subnet and nothing else in the EXTERNAL vrf.  Again, this is an extremely simplified version of my config meant to troubleshoot this single issue I'm having. Anyway, with that added route, still no change.

[paul driver]

Hello

---

@ebng wrote:

OK, I tossed this in to my config:

ip route vrf EXTERNAL 100.19.0.32 255.255.255.224 GigabitEthernet2 100.19.0.52

I did not add the default route, though, as that's not actually what I'm trying to accomplish.  I literally just want my global routing instance to be able to reach that 200.168.0.0/23 subnet and nothing else in the EXTERNAL vrf. 

That fine aslong as the external hosts that want reach your internal host will reside on the 200.168.0.0/23 subnet other wise you will require at least a static route((not a default) to allow that communication

Now for the interesting part - I have since been able to test the changes i asked you to perform and i can confirm those suggestions worked accordingly.

So can you post (in an attached file) the present run could config of that router, It could be a simple oversight we have missed

EDITED :
Forgot to mention we do have an alternative to domain nat (ip nat inside/outside) and that is domain-less nat (ip nat enable) which is designed to work with VRF which we can also explore.

[ebng]

Sure.  The only real differences at this point is the new route you had me add and an applied route-map/ACL another user suggested.

[ebng · Accepted solution]

As an update, I found the missing piece of the puzzle.  I simply had to add the following route:

ip route vrf EXTERNAL 200.168.1.190 255.255.255.255 GigabitEthernet2 100.19.0.52

As soon as I added this, the router responded to the arp request and my pings were successful. 

[Georg Pauwen]

Hello,

just one question: is this a 'real' CSR1000v, or the VIRL version ?

[ebng]

Real.  Had similar issues with an ISR4451 and now using the CSR1000V to try to work them out.

[paul driver]

Hello
See attached file..

[ebng]

Odd.  Would you mind posting you entire config?  Also, what version are you on?

[paul driver]

Hello
TBH nothing else to show thats hasn't already been shared, Apart from the the acting host is a rtr with routing disabled and an default-gateway of the nat rtr lan interface, and acting ISP is also a rtr with an ip address the nat rtrs wan interface with no static routes being applied  -- that’s it.

[ebng]

OK, how about the version then?  At this point, that's the only potential difference.

[paul driver]

Yes apologies, Tested on the following
3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T143700 Software <--GNS3
7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.2(4)M11, RELEASE SOFTWARE (fc2 <--GNS3
IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.8(3)M2, RELEASE SOFTWARE (fc2)  <-- CML v2.0

[ebng]

OK, then perhaps this is something broken in IOS XE.  It sounds like I need to get a ticket opened and see if Cisco support can help me further.  Thanks for the assistance.