NAT - ip nat outside source


I came upon some interesting results when I was configuring NAT on my home router to allow Internet access for a Raspberry Pi.

 

I configured the interface connected to the Pi as an ip nat outside interface as my LAN interface was configured with ip nat inside and I created the following translation to allow the Pi to access the Internet which works:

 

interface FastEthernet0/0

 desc *** connected to Pi ***

 ip address 10.50.255.225 255.255.255.252

 ip nat outside

 

interface FastEthernet0/1

 ip address 192.168.254.101 255.255.255.0

 ip nat inside

 

ip route 0.0.0.0 0.0.0.0 192.168.254.1

ip nat outside source static 10.50.255.226 192.168.254.250 add-route

 

The odd thing is that a trace out to the internet reports the destination address for every hop and it appears to do a double tranlation as the traffic comes back to the Pi, once for the destination (expected) and another for the source (unexpected).

 

R1#traceroute 8.8.8.8 probe 1

 

Type escape sequence to abort.

Tracing the route to 8.8.8.8

 

  1 10.50.255.225 0 msec

  2 8.8.8.8 4 msec 

  3 8.8.8.8 4 msec

  4 8.8.8.8 4 msec

R1#

*May 22 16:25:42.128: ICMP: time exceeded rcvd from 10.50.255.225

*May 22 16:25:42.132: ICMP: time exceeded rcvd from 8.8.8.8

*May 22 16:25:42.140: ICMP: time exceeded rcvd from 8.8.8.8

*May 22 16:25:42.144: ICMP: dst (10.50.255.226) port unreachable rcv from 8.8.8.8

 

When I debug ip nat detail I see the following which shows the double translation:

 

*May 22 16:25:40.736: NAT: Processing out-2-in packet in after_routing2

*May 22 16:25:40.740: NAT: s=10.50.255.226->192.168.254.250, d=8.8.8.8 [901]

*May 22 16:25:40.740: NAT: i: icmp (192.168.254.1, 33435) -> (192.168.254.250, 49180) [43613]     

*May 22 16:25:40.740: NAT: s=192.168.254.1->8.8.8.8, d=192.168.254.250 [43613]

*May 22 16:25:40.740: NAT: s=8.8.8.8, d=192.168.254.250->10.50.255.226 [43613]

 

*May 22 16:25:40.744: NAT: Processing out-2-in packet in after_routing2

*May 22 16:25:40.744: NAT: s=10.50.255.226->192.168.254.250, d=8.8.8.8 [902]

*May 22 16:25:40.744: NAT: i: icmp (10.115.1.1, 33436) -> (192.168.254.250, 49181) [12588]     

*May 22 16:25:40.744: NAT: s=10.115.1.1->8.8.8.8, d=192.168.254.250 [12588]

*May 22 16:25:40.744: NAT: s=8.8.8.8, d=192.168.254.250->10.50.255.226 [12588]

 

*May 22 16:25:40.748: NAT: Processing out-2-in packet in after_routing2

*May 22 16:25:40.748: NAT: s=10.50.255.226->192.168.254.250, d=8.8.8.8 [903]

*May 22 16:25:40.752: NAT: i: icmp (10.115.2.1, 33437) -> (192.168.254.250, 49182) [12485]     

*May 22 16:25:40.752: NAT: s=10.115.2.1->8.8.8.8, d=192.168.254.250 [12485]

*May 22 16:25:40.752: NAT: s=8.8.8.8, d=192.168.254.250->10.50.255.226 [12485]

 

192.168.254.250 is translated to 10.50.255.226 as I expect but each hop in the trace has the source translated to the detsination of the trace (8.8.8.8 in this example) - I ihghlighted those in bold above.

 

When I look at the translation table I can see the holes that were opened in NAT and they are all 8.8.8.8 which is correct but I don't understand why the source of the trace timeouts are translated?

 

Thanks in advance.

Nick

 

Comments


  • When you send traceroute packet from 10.50.255.226 to
    8.8.8.8 with ttl=1

    It reaches ouside interface 10.50.255.250

    Ttl expires

    Icmp is sent from 10.50.255.250->8.8.8.8

    Default route is hit

    Packet is sent to 192.168.254.1 through inside interface

    Destination is changed from 8.8.8.8 to something like
    192.168.254.0/24 [depending on ip nat inside source statement]

    Nat entry is made for 192.168.254.??<>8.8.8.8    ------(X)

     

    traceroute packet from 10.50.255.226 to 8.8.8.8 with
    ttl=2

    It reaches outside interface 10.50.255.250

    Default route is hit

    Packet becomes 192.168.254.250->8.8.8.8

    Packet is sent to 192.168.254.1 through inside interface

    8.8.8.8 is changed according to (X) i.e. 192.168.254.??

    Ttl expires at 192.168.254.1

    Icmp goes from 192.168.254.1 to (X) i.e. 192.168.254.??

    It hits inside interface

    Source is changed from 192.168.254.1 to 8.8.8.8 according
    to (X)

     

    This is my understanding. correct me if wrong.

  • Hi Nick,

    When you kick off your tracerout from R1, the source address would be 192.168.254.101 as thats the nearest interface to the destination address of 8.8.8.8. This will not trigger your NAT as the source must be 10.50.255.226 (raspberry pi PC) or the destination must be 192.168.254.250. Neither apply for your trace to 8.8.8.8.

    I can see some legit traffic coming from your Pi server in the debugs but I dont think the traceroute should be natted.


    Can you try the traceroute from the Raspberry Pi PC and post the debug? It should work OK.

     

  • I see the same behavior as you. I labbed it up. The interesting thing is that I also tried to reverse the scenario. I had a topology like this:

     

    R1-R2-R3-R4 where R3 is doing NAT. Interface towards R2 is inside and towards R4 is outside. If I do a traceroute from R4 to the global outside the second and third hop is the same. NAT translates the source to match the destination in the traceroute.


    R4#trace 100.100.100.100 num prob 1

     

    Type escape sequence to abort.

    Tracing the route to 100.100.100.100

     

      1 34.34.34.3 0 msec

      2 100.100.100.100 0 msec

      3 100.100.100.100 0 msec

    From debug on R3:

    NAT: s=192.168.254.101->100.100.100.100, d=34.34.34.4 [62]

     

    Why it is behaving like this? Not sure. I discussed it with Cristian Matei and it might be some kind of core hiding feature. It will prevent people from finding out your internal address structure when doing a traceroute. Maybe this was a feature requested by customer?

    Nice find!

  • Thanks Daniel

     

    I would be interested to know if you find anything more.

     

     

    *May 22 16:25:40.740: NAT: i: icmp (192.168.254.1, 33435) -> (192.168.254.250, 49180) [43613]     

    *May 22 16:25:40.740: NAT: s=192.168.254.1->8.8.8.8, d=192.168.254.250 [43613]

    *May 22 16:25:40.740: NAT: s=8.8.8.8, d=192.168.254.250->10.50.255.226 [43613]

     

     

    The interesting aspect is the number in brackets [43613].  As you can see it is the same for the above 3 lines of debug which start with the icmp ttl expired coming in from the first hop Post NAT.  Like you say it could be some kind of security "hide" mechanism as it seems to use the NAT hole to modify the source to be the orginal destination of the packet hiding the hops behind the device doing the outside NAT.

     

    dineshg - icmp ttl expired would not be forwarded on towards the destination unless it was an MPLS environment where the P routers do not know how to get back to the Customer devices.

    rmcewin - I labbed this up.  Sorry for the confusion but R1 is the Pi in this scenario.

     

    Regards

    Nick

     

  • Hi Nick,

    I did a blog post on this because I found it interesting: http://lostintransit.se/2013/05/29/nat-translation-what-happened-to-my-traceroute/

    I hope that will explain it for you.

  • Very nice Daniel.

    Thanks for digging and finding out about the Cisco request to make NAT more secure. 

     

    Nick

  • Hi Nick,

    I did a blog post on this because I found it interesting: http://lostintransit.se/2013/05/29/nat-translation-what-happened-to-my-traceroute/

    I hope that will explain it for you.


     

    Cool stuff:)

Sign In or Register to comment.