Support for full TCP NAT behavior test

[zl21st]

I used stunclient to test nat behavior on NAT1,2,3,4 networks, the result is the same:
Nat behavior: Address and Port Dependent Mapping

Is there a plan to support for full TCP NAT behavior test to distinguish different NAT types？

[jselbie]

What is the exact command line are you typing to run stunclient?

Why do you feel the results are inaccurate?

I'm not sure what server you are using, but if the dual ip/port mode of the service is not properly configured or has a firewall issue, then I would suspect that "address and port dependent" mapping will be the result of any client doing behavior or nat classification detection.

Example run from my end:

D:\stunserver\release>stunclient.exe stunserver.stunprotocol.org --verbosity 9 --mode behavior
Resolved stunserver.stunprotocol.org to 3.132.228.249:0
config.fBehaviorTest = true
config.fFilteringTest = false
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 3.132.228.249:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 3.132.228.249:3478
Got response (68 bytes) from 3.132.228.249:3478 on interface 192.168.1.38:49866
Other address is 3.135.212.85:3479

Preparing message for behavior test #2 (destination=AP)
Sending message to 3.135.212.85:3478
Got response (68 bytes) from 3.135.212.85:3478 on interface 192.168.1.38:49866
Binding test: success
Local address: 192.168.1.38:49866
Mapped address: 73.15.16.19:49866
Behavior test: success
Nat behavior: Endpoint Independent Mapping

Do the exact same command from your end using both stunserver.stunprotocol.org as the address as well as your own server and compare the differences.

[jselbie]

Or did you imply that you were using the --protocol tcp flag? Results will be wildly different from UDP depending on ISP and NAT.

[zl21st]

Or did you imply that you were using the --protocol tcp flag? Results will be wildly different from UDP depending on ISP and NAT.

yes, I'm trying to detect the TCP NAT type. Here are the exact commands:
./stunserver --mode full --primaryinterface 222.222.x.x --altinterface 110.242.x.x --primaryport 3478 --altport 3479 --protocol tcp --maxconn 10000 --verbosity 3 --ddp
./stunclient --mode full --protocol tcp --verbosity 3 222.222.x.x 3478

I did not get the expected results on multiple NAT networks, and I'm pretty sure what there exact NAT type are.

I just started a little project to detect TCP NAT type, since there do not have one stun project that can do the exact job.
Here is the link, in case you are interested.
https://github.com/zl21st/tcpstun

[jselbie]

Don't run --mode full with the client (but do use that flag with the server). --mode full on client can generate some incorrect values. Use --mode behavior or --mode filtering to do the individual tests with stunclient

Now do for each NAT

./stunclient --mode behavior --protocol tcp --verbosity 4 222.222.x.x 3478
./stunclient --mode filtering--protocol tcp --verbosity 4 222.222.x.x 3478

./stunclient --mode behavior --protocol tcp --verbosity 4 stunserver.stunprotocol.org
./stunclient --mode filtering--protocol tcp --verbosity 4 stunserver.stunprotocol.org

I'd like you to compare the results and let me know what you see for each.

[zl21st]

same result for 222.222.x.x

The box I used have NAT1 (full cone nat) network, here is the result of the tool I wrote:

[jselbie]

Can your tcpstunc client connect to stunserver.stunprotocol.org? What happens when it does that?

I looked at your code for tcpstunc. Your code actually listens for an incoming TCP connection on the client side. That's not something stunclient.exe attempts to do. But perhaps it should...

[zl21st]

tcpstunc can not connect to stunserver.stunprotocol.org, different protocol.

[ge9]

Maybe an independent issue, but I think stunclient's TCP behavior is broken.
If we use it without specifying --localport, it uses random port for each connection (to multiple addresses/ports, within a single execution), resulting in Address and Port Dependent Mapping in almost all situations.
I confirmed this in tcpdump.
Also, TCP testing fails with --localport in filtering mode. It may be trying to open multiple connection on the same port specified.
UDP is working well.

[Kimapr]

Maybe an independent issue, but I think stunclient's TCP behavior is broken. If we use it without specifying --localport, it uses random port for each connection (to multiple addresses/ports, within a single execution), resulting in Address and Port Dependent Mapping in almost all situations. I confirmed this in tcpdump. Also, TCP testing fails with --localport in filtering mode. It may be trying to open multiple connection on the same port specified. UDP is working well.

I can reproduce this issue, stunclient creates a brand new socket for each connection, but it always blindly uses the local address specified in the config/command-line, of which the port if no --localport is specified will be 0 and OS will allocate a different port each time. I don't think it's independent, since you can see zl21st invoke stunclient without --localport which triggers the bug. The fix is just two lines change as shown in #68

STUN Filtering test is impossible with TCP, because the standards don't allow the STUN server to send a response by connecting back to the client, which would be necessary to implement a proper filtering test. Basically the client would have to make a connection to one server to make a ChangeRequest, then listen on the same port for connection from other server (but as said other server won't connect because it's not allowed by STUN standards. a non-standard extension to the protocol could work though). Currently stunclient --help says Filtering is only for UDP, but still accepts --mode filtering together with --protocol tcp, and does something bogus in that case. Results are incorrect because stunclient would connect to other server on its own instead of waiting for it to reach out which opens up the port mapping and undermines the test; for me TCP filtering says I have "Endpoint Independent Filtering", different from UDP filtering test says "Address and Port Dependent Filtering", however in reality my NAT does what is for sure not Address and Port Dependent Filtering for TCP as i have determined via other means, likely it's the same as for UDP.

[jselbie]

I pulled in the fix from @Kimapr and added SO_REUSEPORT support. I think we can close this issue now. Thanks everyone.

[Kimapr]

@jselbie I took a look at your code for SO_REUSEPORT support and noticed that in 95bd802 you also partially undid the change I made in #68, specifically the part that passes addrLocal (which is set to actual local address and port of tcp client socket after a connection) to TCPInit instead of socketConfig.addrLocal (which is set externally and is never updated). I haven't tested the new changes but i am fairly sure that the change of that line specifically completely negates my fix and reintroduces this issue. The rest of it should be fine though.

I'd also like to point out that SO_REUSEPORT also applies to UDP sockets and it would be useful to enable it for the UDP client as well rather than just TCP client (your changes only enable it for TCP). Because UDP is "connectionless" when SO_REUSEPORT is used to share a bound UDP port between stunclient and a server application, the OS may route packets to the wrong program since it can't possibly know which one they are intended for, however "connecting" the socket as i did in #67 fixes this issue (this basically "validates" the remote address when receiving responses - if it doesn't match expectation, kernel will drop the packet (in usual case of when localport is only used by stunclient) or direct it elsewhere (in SO_REUSEPORT case) instead of passing it to stunclient).

[jselbie]

ok - I reverted my change. Can you explain how having the TCP client socket explicitly set SO_REUSEPORT broke your original change?