I want to obtain internal IP of a remote computer behind a NAT that I can reach by using some port, say myhost.farfar.away port 11122TCP:

C:\>telnet myhost.farfar.away 11122
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2

As you see, there is a SSH server on it, but I don't have connections user data.

If I try to trace the route (fake IPs, of course):

C:\>tracert -d myhost.farfar.away

Trace route to address myhost.farfar.away []
maximum 30 hops:

  1    <1 ms    <1 ms    <1 ms
  2    <1 ms    <1 ms    <1 ms
  3    47 ms    47 ms    47 ms
  4    81 ms    86 ms    80 ms

Trace route complete.

I know that myhost.farfar.away has IP, but is it possible to keep hoping through this NAT, now that I know 11122TCP port is redirected to this machine, in order to obtain its internal IP (bypassing the NAT)?

NOTE: I know its internal IP is, so theorically I would like to reach something like:

  3    47 ms    47 ms    47 ms
  4    81 ms    86 ms    80 ms
  5   101 ms    106 ms  100 ms

Same results for netstat, of course.

I have tested tcpdump, but I think it can only give info about connections entering into my computer, so executing this line on the remote machine would do the trick:

tcpdump -i any port 11122

But can it be done on the local "scanning" computer? I can use both Windows or Linux.

2 Answers 2


I must disagree with @vahid. If there are multiple hops between the NAT and the host to which the connection is being port-forwarded, you may actually be able to elicit an ICMP TIMEX message.

As you may know, every IPv4 packet has a 1 byte TTL field. If you determine the distance to the NAT (say 10 hops) and the actual concealed host is actually 12 hops (or more) away, you could send a SYN to the port-forwarded port on the NAT with a TTL value of 11. If it is simply rewriting the address (rather than acting as a reverse proxy) then the TTL will be unmolested. This means that the TTL when leaving the NAT headed inbound will be 1. The next router will decrement to zero, causing an ICMP Time To Live Exceeded (TIMEX) message back to the sender.

Even though the outbound packet will be NATted, every ICMP error message (of which this is one) will contain the embedded protocol header within it. What this means is that the original de-NATted destination host will now be visible in the ICMP payload as an embedded IP header being returned in the error.

While it is certainly true that this technique has some very specific requirements to be successful (ICMP permitted outbound, the actual port-forwarded host not on the local LAN of the NAT, etc.) it will certainly work, meaning that this is -not- impossible by any means.

  • From my current understanding, I would have to agree with @David. To refute this, I am including link [1] which gives a working understanding of traceroute, and link [2], RFC 5508: NAT Behavioral Requirements for ICMP. Section 3.1: ICMP Query Mapping, which covers behavior of NAT devices when handling ICMP error messages. [1]tek-tips.com/faqs.cfm?fid=381 [2]tools.ietf.org/html/rfc5508 – cremefraiche Dec 10, 2014 at 4:51
  • A really interesting point. In terms of preparing some example scenario, could something like packetforge-ng (from AirCrack-NG suite) be used to make some empirical test? Dec 11, 2014 at 1:49
  • I'm not familiar with Packetforge-ng but it sounds as though it's a library that can be leveraged rather than a tool.. This is just a guess, though. :) Scapy, hping, nemesis... There are many tools that you could use for this purpose Dec 11, 2014 at 1:54

What you are trying to achieve is not possible, by design. The only way of achieving this is by having access to either the gateway or the host machine. A NAT device serves the dual purpose of sharing an internet connection with an internal network and protecting the internal network much like a traditional firewall would.

[edit] I stand corrected. The IETF does in fact enable this to be possible, given the assumptions outlined in David's response above.

  • 1
    @SopalajodeArrierez They are routers without NAT.
    – Philipp
    Dec 9, 2014 at 22:02
  • 1
    Yes, that is correct. You should read how traceroute works, it will help clear up some confusion.
    – Vahid
    Dec 9, 2014 at 22:07
  • 1
    I must disagree with @Vahid on this one. I've posted an alternate answer to explain. Dec 10, 2014 at 2:49
  • 1
    I believe a review of Section 3.1 of RFC 5508 combined with knowledge of ICMP error message headers shows this answer to be incorrect. tools.ietf.org/html/rfc5508 Dec 10, 2014 at 4:50
  • 1
    No, you've missed it. This does not give me the address of the router behind the NAT, it gives me the address of the ACTUAL host. When the ICMP response is sent back, the source address is, of course, the router, which is what you are thinking of. Read my answer again. The EMBEDDED TCP/IP header contains the de-NATted original destination address, not the address of the router. So, again, you absolutely can do this actively. You'll notice that I'm not the only one pointing this out. :) Take a look at the reference from @cremefraiche. Dec 10, 2014 at 21:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .