How can I obtain the internal IP of a computer behind NAT but reachable via certain TCP port?

Question

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 [103.56.5.30]
maximum 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.11.1
  2    <1 ms    <1 ms    <1 ms  192.168.10.1
  3    47 ms    47 ms    47 ms  80.58.67.85
  4    81 ms    86 ms    80 ms  103.56.5.30

Trace route complete.

I know that myhost.farfar.away has IP 103.56.5.30, 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 172.26.5.5, so theorically I would like to reach something like:

  3    47 ms    47 ms    47 ms  80.58.67.85
  4    81 ms    86 ms    80 ms  103.56.5.30
  5   101 ms    106 ms  100 ms  172.26.5.5

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.

Answer 1

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.

Answer 2

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.