Thursday, March 11, 2021

UDP Hole punching with ephemeral ports - Is it even possible?

Hello,

I am trying to establish a P2P connection for a P2P UDP networking engine using the STUN protocol.

Both Peers are behind different non-symmetric NAT's.

I am writing all of this in C# and i am using one socket on each peer to communicate to the server and to each other.

The principal is quite simple:
Peer A and peer B use rendezvous server S to share their public endpoints with each other and once they recieve the endpoint of the other peer they start sending datagrams to it; thus punching a hole into their NAT's.
See https://tools.ietf.org/html/rfc5128#section-3.3 for a more detailed description.

My problem:
While peer A was sending datagrams to server S the public port may have been 7435 but when he sends data to client B the port changes to some other random number.
Now, client B is expecting client A's port to be 7435 but since that is not the port that A is using to connect to B - the NAT is not letting A's connection attempts through.

I have two solutions but i don't know if they are feasible:

Solution 1:
I need to make the public port for communication static so that the public port doesn't change whether i am sending data to the server or a peer. Can i make ports static?
How would i even bind a socket to a public port? Seems like the socket gets a different ephemeral port assigned every time it initiaites a session with an endpoint. HOW DO I STOP THIS FROM HAPPENING??

Solution 2:
I somehow have to get the new public port from peer A when he sends data to peer B so i can send this information to peer B and establish a connection.

Any help would be greatly appreciated, i have been banging my head against the wall for a couple of days now.



No comments:

Post a Comment