5

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.

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
Sopalajo de Arrierez
  • 641
  • 2
  • 7
  • 16

2 Answers2

7

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.

David Hoelzer
  • 615
  • 4
  • 9
  • 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 – cremefraiche Dec 10 '14 at 04: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? – Sopalajo de Arrierez Dec 11 '14 at 01: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 – David Hoelzer Dec 11 '14 at 01:54
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.

Vahid
  • 301
  • 1
  • 8
  • So all the intermediate devices that route the connection through internet when doing a classic `traceroute` command, could then be defined as routers without NAT? – Sopalajo de Arrierez Dec 09 '14 at 21:59
  • 1
    @SopalajodeArrierez They *are* routers without NAT. – Philipp Dec 09 '14 at 22:02
  • 1
    Yes, that is correct. You should read how traceroute works, it will help clear up some confusion. – Vahid Dec 09 '14 at 22:07
  • @SopalajodeArrierez You will also have to read up on how NAT is implemented (esp. port forwarding). – schroeder Dec 09 '14 at 23:36
  • 1
    I must disagree with @Vahid on this one. I've posted an alternate answer to explain. – David Hoelzer Dec 10 '14 at 02: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 – cremefraiche Dec 10 '14 at 04:50
  • @DavidHoelzer Thanks for the response. You make a really great point, but the question is asking whether or not the IP of the endpoint host can be obtained. As you've stated, crafting the SYN packet with the NAT+1 TTL will give you the IP address of the router in front of the endpoint (if there happens to be one), not the endpoint itself. – Vahid Dec 10 '14 at 17:52
  • 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. – David Hoelzer Dec 10 '14 at 21:22
  • @DavidHoelzer You are correct. Thanks for the clarification! – Vahid Dec 11 '14 at 14:56