In article , Joachim Schipper wrote: :Walter Roberson wrote: :> NAT'ing router with the real host being "inside".
:> The TTL expires on one packet when it reaches the router, and :> the next round with a TTL one higher expire when they hit the host. :> The host is NAT'd to the public IP, though, so the icmp comes back :> from the same IP address as before.
:Hmm, that would work, but why would the router forward it when it's sent :to it's own IP? Or, if it does not consider .78 to be it's own IP, why :does it accept packets and decrease TTL for that address?
In this scenario, the host itself is likely using a private IP address. The first bunch of packets expire at the router itself and the icmp unreachable get sent back normally, from the router's IP.
The second bunch of packets are forwarded to the private IP, a process that changes the destination IP address but not the source IP addresses. The host replies with icmp port-unreachable, with the private IP as the source and the probing host's IP as the destination (read off of the incoming packet). The private source IP of the host is nat'd as it heads out the router, and the embedded IP address of the icmp port-unreachable is probably nat'd to the public IP too. The port-unreachable makes it back to the probing host and the host knows to stop the traceroute.
This is slightly different than I was indicating before, in that before I was indicating ttl-exceeded for the inside host, but that didn't take into account that the traceroute stopped at that point, which only happens with port-unreachable.
For this scenario to work, it has to be a -router- that is doing the NAT. If it is a firewall such as the Cisco PIX, then the firewall is not supposed to examine the TTL -- a firewall is supposed to be transparent that way.