How to discover the type of the NAT a given interface is behind

Question

I would like to discover the type of the NAT (FullCone, Restricted Cone, Port Restricted cone, Symmetric) a given network interface is behind.

I've tested different tools (http://freshmeat.net/projects/jstun/, http://code.google.com/p/boogu/) but they report different results for the same interface.

I'm looking for a definitive answer in Python (or other languages, 2nd choice being Java, if nothing else is available).

Apprehension

Answer 1

I second the answer from @S.Lott: It is not possible to use STUN (or any other protocol) to determine with 100% certainty what type of NAT you're behind.

The problem is (as I witnessed recently) that the NAT may sometimes act as Address-Dependent (Symmetric) and sometimes as Endpoint-Independent (Full, Restricted or Port Restricted cone).

When you think about it, being Address-Dependent means that when you send packets from one socket on a client behind the NAT to two distinct servers, then the NAT will create two custom public address:port tuples for each of the servers. In my case, these bindings seemed completely random, but if the range is small, it sometimes happened that these tuples were actually equal! Which confused the test.

I was using this library at the time and sometimes it told me the NAT's behavior was Address-Dependent and other times it was Endpoint-Independent (the switch between the two also seemed completely random, sometimes it happened after I restarted the device, sometimes after a time period,...).

This happened to me on a mobile device with Slovak Telekom, a company mostly owned by Deutsche Telekom so I think the problem will be at least Europe-wide.

I would say that the rule here is this: If STUN test tells you that you're behind a Symmetric NAT than that is the case, but if it tells you otherwise, then you can not be 100% sure.

One last note, an easy way to check your NAT's behavior with respect to TCP is to type "what is my IP address" into google and then open first (say) five pages. If the pages are not consistent about your IP address, your NAT's behavior is Address-Dependent or Address-and-Port-Dependent (Symmetric). But again, if they do correspond, you just can't be sure.

Devland

Worth mentioning: datatracker.ietf.org/doc/html/rfc4787#section-8 – Jurisprudent

Answer 2

http://en.wikipedia.org/wiki/STUN

NAT devices are implemented in a number of different types of address and port mapping schemes. STUN does not work correctly with all of them.

Is that definitive enough? It's only a wikipedia quote, but from this it looks like your request is physically impossible.

Imperfection

Answer 3

As @S.Lott 's say, STUN is your first choice protocol .

And then, STUN is just a protocol.Here is my advice:

1 STUN now has two version : the old version is RFC3489 - this is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet (so it's mainly and only for detecting NAT type ); and the new version is RFC5389 - this is a tool for other protocols in dealing with NAT traversal .

2 Also there is a relay extension to STUN named TURN RFC5766. TURN allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.

The tools:

• STUN server (RFC3489) : stund By c++

• STUN client (RFC3489) : pystun By python

• TURN server (RFC5766) : turnserver By c

• TURN client (RFC5766) : turn-client By c and python

Note: Because TURN is the extension of new version STUN, the TURN server also support new STUN request by RFC5389 .

Lustre