Hole punching using STUN

问题

I'm currently trying to send UDP messages over the internet and have to set up the firewalls for both endpoints A and B (which are both behind a NAT). To do this, I want to use hole punching using a STUN server.

When A creates a request to the STUN server (say, private: 85.1.1.12:6000 and public: 173.194.78.127:19302) I get 85.1.1.12:6000 as a response. If I were to send a packet from the same origin configuration (same origin ip and port that were used for the STUN-request) to any other destination address (the destination port stays the same) then my NAT would change the public port again (from 6000 to anything else). I found out by using the same address-port configuration for two different STUN server requests (using port 19302 for both requests).

Like this, I have no possibility of knowing what port my NAT does the translation when sending a packet to B (B can't receive anything because its firewall is not set up).

Is this because my NAT type is not compatible for hole punching or did I get the concept wrong?

Thanks!

回答1:

85.1.1.12:6000 is not your private IP address. Its your NAT's public/external IP:Port. Private IP is your PC/Device's interface address.

From your scenario I am guessing you have a symmetric NAT. In Symmetric NAT, your NAT's public port changes every time you send some packets to a different destination. If your destination remains same then the NAT's public IP:Port also remains same.

For other types of NAT if your private IP doesn't change then it doesn't matter where you send your packets, your NATs public IP:port (in your case 85.1.1.12:6000) will remain same.

Hole punching is not possible if one side has **Symmetric NAT and other side has Symmetric/PRC NAT.

**By Symmetric NAT I mean Symmetric NAT which gives random port allocation.

回答2:

Hole punching is technically not impossible if both sides have symmetric NAT (although the traversal process may be too unreliable to be worth the hassle). Please read my paper:

https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing

Or one of the papers that it references: