Does this library STUN bypass cone/port restricted NAT?

[makew0rld]

From the STUN Wikipedia page:

STUN does work with three types of NAT: full cone NAT, restricted cone NAT, and port restricted cone NAT. In the cases of restricted cone or port restricted cone NATs, the client must send out a packet to the endpoint before the NAT will allow packets from the endpoint through to the client.

Does this library handle the case at the end, where clients must send out a packet to the endpoint? I would assume it does, but I'm not sure if this is part of any spec or not. If the library doesn't currently do this I think it should.

Thanks

[Sean-Der]

Yes it does! Those terms aren't what people really use anymore. I have attempted to update this page and the WebRTC one and always get reverted. RFC 4787 is a great read. It breaks it down into Mapping/Filtering and then the behaviors are address independent/dependent.

At least one peer must be behind a address independent NAT. This allows them to distribute their NAT mapping so others can send traffic in. If both Peers are behind Address Dependent NATs they can't use STUN and have to use a TURN Server.

• 2 Address Independent. Both Peers can share their NAT Mappings and it will work.
• 1 Address Independent. The Independent side can share their mapping, the act of the dependent side contacting the independent peer will create a new mapping.
• 2 Address Dependent. No useful NAT Mapping can be created. The STUN server can respond to your request, but no one else can contact you.

[makew0rld]

Great to hear! Thanks for the explanation.