6

How can I detect if NAT is used in network or not?

I know if you have a private address and you are able to connect to a public network or the Internet, then there must be NAT.

But how can I detect that NAT is used in an internal network (which is not connected to Internet but uses NAT) or not?

Is there any way that we can check from IP packet or via some other method?

I say Reinstate Monica
  • 662
  • 1
  • 7
  • 16
Johan Gelp
  • 577
  • 3
  • 7
  • 10

2 Answers2

7

This question brought back some memories of when I created (with the help of a friend) a small tool to detect the presence of NAT in networks.

The idea is quite simple (inspired/stolen from the NAT traversal technique in IPSec):

  • You have network segment A and network segment B, and you want to detect the presence of a NAT between them.

  • Send a TCP packet containing, in its payload, an MD5 digest of your IP address and the source port from a host in segment A to a host in segment B.

  • Listen to the packet on the host in segment B. Once received, run the source IP and the source port through MD5 and compare the result with the hash in the payload.

  • Hashes match -> No NAT.

The tool consisted of two small A.exe and B.exe written in C++.

Note: As all NAT detection techniques out there, this solution works by crosschecking IP-port pairs. There's no other way that guarantees NAT detection.

Community
  • 1
Adi
  • 43,808
  • 16
  • 135
  • 167
  • This solution requires you to have access to a computer on either side of the suspected NAT router, in which case you can just check the IP address, then send a regular ping and use `tcpdump` on the other end to see what source address it reports, then repeat in the other direction, and you don't need extraneous software. – Shadur Dec 01 '13 at 12:21
  • 1
    @Shadur Of course it does. This is how this thing works in all of NAT detection implementations. You _need_ to crosscheck IP-port pairs. Otherwise, there's no guaranteed way to do it. Also, I never claimed you need "extraneous software". I clearly outlined the method in the 4 steps. You're free to use whatever tools you want to achieve this. In my case, I opted to write my own. – Adi Dec 01 '13 at 12:35
  • 1
    @Adnan If I don't have access on other side of network then how I detect it ? – Johan Gelp Dec 01 '13 at 18:28
  • @JohanGelp You can't. That's how networks work. – Adi Dec 01 '13 at 19:04
  • This experiment requires the other side to be directly connected to public internet. – HungryFoolish Jun 13 '17 at 14:51
6

Much depends on your scenario.

If the two hosts collaborate, just have one of the two send its IP to the other. Optionally hash/encrypt it in order to keep protocol rewriting filters (such as ftp-masq) from rewriting not only the header packet IP but the payload too. Then, if the two addresses don't match, NAT must have been at work.

If you only have one host, that for example connects to your host, and want to know whether it's a 'true IP' or a natted IP, you probably won't be able to -- if the connecting machine is expected to have some service available, you can try connecting to its corresponding address and port; unless the NATting machine is also doing reverse masquerading / "virtual server" translation, you should be able to see whether the service is open on the requesting machine (no NAT) or not (NAT).

With several hosts, you could be able to count packets and exit ports of incoming connections. NAT boxes and "ordinary" boxes have different port assignment schemes. Traffic asymmetries from different source ports may also be symptomatic of NAT (or someone keeping several web pages open onto a proxy; how likely that is, depends on the scenario. Two port pairs having both usually-interactive traffic of a wildly different kind are likely due to there being two users behind a NAT. And so on).

Another approach could be to inspect packet timing and TTL. Usually NAT implementations do not reset TTL counter, so it will be decreased by one when NATting. NAT takes a little time too, and this can be statistically investigated.

Finally you could try being sneaky and reply with forged packets, again playing with TTL. If the NAT box is regenerating TTL to hide its NAT, chances are that it will do so only for outbound packets, and rely on normal code for inbound traffic. If you send a packet with TTL crafted to "expire upon impact", a non-NATted machine will still receive it. The NAT box will receive it, decrement TTL counter, and the packet will die in transit without reaching the originating machine. You will either get a drop or a TTL-Exceeded ICMP reply.

Sometimes, similar strategies may be employed with packet fragmentation schemes, but this requires the remarkable luck of having an asymmetrically favourable MTU configuration in the "legs" from your machine to the supposed NAT box, and from this to the real machine.

LSerni
  • 22,521
  • 4
  • 51
  • 60