Regarding nat type analysis

Question

I downloaded the stun client from http://www.stunprotocol.org/ and trying to figure out the NAT type by command stunclient --mode full stun.stunprotocol.org --verbosity 9 and I got the below response.

config.fBehaviorTest = true
config.fFilteringTest = true
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 52.86.10.164:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 52.86.10.164:3478
Got response (68 bytes) from 52.86.10.164:3478 on inter
Other address is 52.201.75.212:3479

Sending message to 52.201.75.212:3478
Got response (68 bytes) from 52.201.75.212:3478 on inte
Sending message to 52.201.75.212:3479
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.201.75.212:3479
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Binding test: success
Local address: 10.64.60.58:58841
Mapped address: 125.19.34.60:24604
Behavior test: fail
Filtering test: success
Nat filtering: Address and Port Dependent Filtering

I am working in a corporate and therefore for security reasons, NAT type "Address and Port Dependent Filtering" seems viable.

But as a general phenomenon, it seems to me that for peer to peer connections , most of the the time, NAT Type will be "Address and Port Dependent Filtering" and therefore turn server is required for any media communication.

However, searching on google for webrtc, it shows that 90% of peer to peer communication establishes through stun server itself( by hole punching etc). This means NAT type in that case is fully supported for establishing the connection.

Do experts have any opinions about the NAT type analytics to consider for peer to peer communication?

Answer 1

I imagine, you want to communicate between p2p in all possible scenarios (including symmetry NAT). My suggestion: Try using webRTC and use stun and turn servers in ice server list. this will give you range of ICE candidates and webRTC will take care of connecting to best possible candidates. this should save you from your NAT type concerns.

Answer 2

The stunclient program could use a bit more logging to indicate what it's doing. Since I know a little about the code, here's how I interpret it.

Stunclient does two different sets of tests. The first are the "mapping behavior" tests, which is the most important for understand how your NAT/Firewall will impact P2P connectivity. The other set are the "filtering tests" that are an indicator of how "open" your NAT is with regards to receiving traffic from other IP/port combinations.

Your behavior test "failed". What this likely means, based on your log output is this:

Test 1: Pick a random port, 58841, in this case. From this local port, do a basic binding test to stun.stunprotocol.org:3478. This is where the client receives a response where the server indicates the mapped address (125.19.34.60:24604) and that the stun alternate IP for subsequent behavior and filtering tests is at 52.201.75.212.

Test 2: Same local port, 58851. Send a binding request to the alternate IP and primary port (52.201.75.212:3478). In your case, it appears that the response that came back was likely a different ip or port. And in thist case "test 3" was required.

Test 3: Same local port, 58851. Send a binding request to the alternate ip and alternate port (52.201.75.212:3479) so it can distinguish between between "address dependent" vs "address and port dependent mappings". And this is the interesting part - you never got a response. Despite being able to communicate with both IP addresses on port 3478. This is why the test came back as failed.

Could be one of two things:

a) Your NAT/Firewall actually is open for port 3478, but not 3479. Do this from the command line to detect

 stunclient 52.201.75.212 3479

And if that succeeds in getting a mapped address, then immediately do this:

 stunclient 52.86.10.164 3478

Try other combinations of those two ip address and ports. The resulting behavior could mean the following

b) Your NAT/Firewall declines to port map when both the remove ip and port have changed. That means your network environment is even more restrictive that an "Address and Port dependent mapping" NAT. More commonly known as a symmetric NAT.

As for the filtering tests, just ignore this result. The filtering tests try to detect if you can send to one ip:port, but receive from a different ip or port. 99% of the time NATs disallow this. So the result almost always results in "Address and Port Dependent Filtering". The filtering test result is not very indicative of how your NAT will succeed in P2P connectivity.

And just because your enterprise network is very restrictive, it doesn't mean it's impossible for you to communicate with a peer on another network. If he has a more well behaved NAT with Endpoint Independent Mapping, then there's still a chance P2P connectivity will succeed.

I haven't kept up with NAT trends in recent yearas, but 80-90% of connections succeeding with STUN alone sounds right. The rest will need a relay solution such as TURN.