IOS-XE NAT w/ IPSec - Translation after decryption?

[Ian Underwood]

Here is an interesting scenario for consideration:

I have an enterprise, "A", which intends to form a VPN to share data with remote partner, "B".  Both A and B are using network space that overlaps, and for reasons beyond my control, the partner is not able to perform any translation.

A is using an ASR-1001-HX at its headend and is terminating a number of VPNs today through different providers successfully.  This, however, is the first link which requires any kind of translation.

The network which overlaps is 172.30.0.0 /24.  The intent is to use some CGN space to perform double translation.  100.96.2.0/28 is what the remote partner should see.  100.96.1.4/30 is what the enterprise will see.

Here's what has been done that is about 3/4 working:

• Interface VASILeft800 is created on the global table.
• Interface VASIRight800 is created on a dedicated IVRF for this customer (TEST-IVRF).
• The exterior interface, Te0/1/0 is configured for "ip nat inside"
• The interior interface, VASI800 is configured for "ip nat outside"
• The NAT positions are deliberately reversed, because it makes it possible for me to overload on the NAT outbound if necessary.
• The encryption domain is 100.96.2.0/28 to 172.30.0.0 /34.
• Loopback800 in TEST-IVRF is configured for 100.96.2.0/32.  This loopback is pingable by the remote site.
• NAT:
  ip nat outside source static 10.40.100.56 100.96.2.1 vrf TEST-IVRF
  ip nat inside source static 172.30.0.100 100.96.1.4 vrf TEST-IVRF
• TEST-IVRF has a default route to VASILeft.
• 100.96.1.4/30 has a static route to VASIRight.

Here is where it gets weird.  From the host at 10.40.100.56, I can start pings to 10.96.1.4.

PING 100.96.1.4 (100.96.1.4) 56(84) bytes of data.
^C
--- 100.96.1.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

The remote host shows the pings come in:

16:18:50.185517 IP 100.96.2.1 > 172.30.0.100: ICMP echo request, id 31911, seq 1, length 64
16:18:50.185543 IP 172.30.0.100 > 100.96.2.1: ICMP echo reply, id 31911, seq 1, length 64
16:18:51.185195 IP 100.96.2.1 > 172.30.0.100: ICMP echo request, id 31911, seq 2, length 64
16:18:51.185213 IP 172.30.0.100 > 100.96.2.1: ICMP echo reply, id 31911, seq 2, length 64
16:18:52.185425 IP 100.96.2.1 > 172.30.0.100: ICMP echo request, id 31911, seq 3, length 64
16:18:52.185450 IP 172.30.0.100 > 100.96.2.1: ICMP echo reply, id 31911, seq 3, length 64

But, in netflow, it shows the return traffic never gets translated back:

IPV4 SRC ADDR    IPV4 DST ADDR    INTF INPUT            IP TOS  IP PROT  intf output          
===============  ===============  ====================  ======  =======  ==================== 
172.30.0.100     100.96.2.1       Te0/1/0.85            0x00          1  vr899                
172.30.0.100     100.96.2.1       vl899                 0x00          1  Null                 
10.40.100.56     100.96.1.4       Te0/1/2.51            0x00          1  vl899                
10.40.100.56     100.96.1.4       vr899                 0x00          1  Te0/1/0.85           

But the table is good and the logs show the translations being created / destroyed:

Apr 20 16:20:30.488 EDT: %IOSXE-6-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:072 TS:00001226747561746586 %NAT-6-LOG_TRANSLATION: Created Translation ICMP 172.30.0.100:1021 100.96.1.4:1021 100.96.2.1:1021 10.40.100.56:1021 9
...
Apr 20 16:25:49.984 EDT: %IOSXE-6-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:141 TS:00001227067073551404 %NAT-6-LOG_TRANSLATION: Deleted Translation ICMP 172.30.0.100:1021 100.96.1.4:1021 100.96.2.1:1021 10.40.100.56:1021 9

I have no idea why the traffic that comes in does not get translated after it's decrypted.  Once this is figured out, then I have a solution where I can handle translation for any given chaos on the IVRF all by itself.

Does anyone have any ideas?

[Ian Underwood · Accepted solution]

After some rethinking, I managed to get this routing scenario working.  My suspicion why this was not working is due to the VRF only having one actual interface present in its routing table.

As such, I moved the translation into the global table and changed NAT to the following:

• All interior interfaces on the global table to "ip nat inside"
• VASILeft800 as "ip nat outside"
• Removed NAT from VASIRight800 and the exterior interface

ip nat inside source static 10.40.100.56 100.96.2.2
ip nat outside source static 172.30.0.100 100.96.1.4 add-route

Since these translations are done in and with interfaces in the global table, I could run into a pickle if I get two peers with colliding space.

It does work:

RT1#sh ip nat trans
Pro  Inside global         Inside local          Outside local         Outside global
---  ---                   ---                   100.96.1.4            172.30.0.100          
---  100.96.2.2            10.40.100.56          ---                   ---
icmp 100.96.2.2:10105      10.40.100.56:10105    100.96.1.4:10105      172.30.0.100:10105
Total number of translations: 3

The flows look good:

IPV4 SRC ADDR    IPV4 DST ADDR    INTF INPUT            IP TOS  IP PROT  intf output         
===============  ===============  ====================  ======  =======  ====================
10.40.100.56     100.96.1.4       Te0/1/2               0x00          1  vl899                                
100.96.2.2       172.30.0.100     Te0/1/2               0x00          1  vl899                        
100.96.2.2       172.30.0.100     vr899                 0x00          1  Te0/1/0.85          
   

This part at least works.  The next test is to see if I dedicate a VRF for a NAT containing a pair of VASI interfaces if something similar can be done.