Understanding Stun working

Question

I went through the Programming P2P application SO post. but I think I'm still unclear as to how the STUN work under the hood.

So, I would like to post my understanding and hope to get them corrected.

as per the example

assuming that machine (A) IP is 192.168.1.2 running on (TCP client request on STUN server) 4900(TCP client request STUN server over TCP running at 4900) and Stun server returned the Public IP of the Nat device i.e 128.11.12.13 8888

Now I want the Machine B(assuming now B knows by public IP 128.11.12.13) to connect to machine A over port 3000 (TCP)

What happened after this -

B tried to connect A with IP on 128.11.12.13

Question 1: But which port? (It cant connect to port 3000 directly )

I guess the answer to that would I port forwarding the 4900 request to 3000.

But here a thing

Question-2: what about to the TCP client connected to STUN server on 4900 (sending indication etc). If the port forwarding is applied all traffic from Stun server to TCP client will now be redirected to port 3000. Right?

Am I correct on this?

What way around for this or am I thinking out loud over here? :)

Answer 1

Indeed you cannot connect to port 3000 directly. You have to connect to the port that is opened at the NAT and it is the address:port that is received in the STUN response

client A                 NAT                  STUN server        client B   
   |---- STUN request --->|                       |                   |
   | src:192.168.1.2:3000 |                       |                   |
   |                      |---- STUN request ---->|                   |
   |                      | src:128.11.12.13:8888 |                   |
   |                      |                       |                   |
   |                      |<----STUN response-----|                   |
   |                      | ext:128.11.12.13:8888 |                   |
   |<----STUN response----|                       |                   |
   | ext:128.11.12.13:8888|                       |                   |
   |                                                                  |
   |======= APP protocol over rendezvous server =====================>|
   |        my address is 128.11.12.13:8888                           |
   |                                                                  |
   |<======= APP protocol over rendezvous server =====================|
   |          my address is 1.2.3.4:9999                              |
   |                                                                  |
   |-- direct protocol -->|                                           |
   | src:192.168.1.2:3000 |                                           |
   | dst:1.2.3.4:9999     |<--------- direct protocol ----------------|
   |                      |           dst:128.11.12.13:8888           |
   |<-- direct protocol --|                                           |
   | dst:192.168.1.2:3000 |                                           |
   |                      |                                           |

STUN only provides the client the external IP address and port which is perhaps opened at the NAT device. The client B be must try to connect to this IP and port (128.11.12.13:8888) and client A must listen at the same IP:port (192.168.1.2:3000) which was used in source address:port in the STUN request.

If you are lucky then the scenario above works well. But you can be out of luck because there are a lot of NAT types and something wrong may happen especially for TCP.

EDIT (answer to additional question in the comment):

It is better to keep the connection to STUN server opened. A NAT device might close the pinhole when it detects connection close. But it depends on the NAT device internal handling which is not standardized as far as I know.

The listening socket for the direct protocol at client-A must have SO_REUSEADDR option set. If the option is set then it is possible to establish connection to STUN server and then create a listening socket at the same port.