1

I've been working on connecting two devices that are each behind a symmetric NAT and managed to make it work quite consistently. However, it takes quite some time for the connection to happen (sometimes more than a minute) and it will not work on certain types of symmetric NATs. I believe this is why STUN doesn't support symmetric NATs and that TURN has to be used.

But, when I was doing some tests I first started by trying to connect a device behind a symmetric NAT to a device behind a port-restricted cone NAT and managed to make it work very consistently in a short amount of time and on multiple types of NAT. So I'm wondering, do modern implementations of STUN support this feature? If not, why?

1 Answer 1

1

STUN not supporting symmetric NAT is not a question of modern vs. not modern but how NAT and STUN is working. STUN is about predicting which port will be used for a connection to IP address X (out of control of STUN server) from looking at previous connections to IP addresses in control of the STUN server. The very description of what symmetric NAT is means, that such a prediction is not possible.

Because of this it is likely that your interpretation of what is happening is wrong. Either you are not actually dealing with a fully symmetric NAT on one side and a port restricted cone NAT on the other or you are not dealing with STUN only. Unfortunately it cannot be seen from the details of your question what is actually happening, but one can only rely on your interpretation of the things.

4
  • I'm working with 4G networks that use symmetric NATs, the port allocation is indeed random but when dealing with only one symmetric NAT on one side it's very easy to brute force all the possible ports and establish a connection. Especially because the port allocation is not actually totally random but always in a certain range of few hundred or thousands ports. What I'm wondering is if some implementations of STUN support these kind of techniques.
    – Reveles
    Feb 28, 2021 at 18:30
  • @Reveles: What you describe in your comment is different from what you describe in the question. You don't say that you try lots of possible ports but only that you "managed to make it work very consistently in a short amount of time and on multiple types of NAT". STUN is basically a way for a client to determine what its externally visible IP and port is and determine what type of NAT could be in use. How these information are then actually used is not part of STUN, i.e. something succeeding after trying a port range could be called a NAT traversal solution but not STUN. Feb 28, 2021 at 18:59
  • Oh I see, I misunderstood what exactly STUN was meant to do. But then is there a general protocol used to traverse the NAT? Is it SIP? Basically what I’m asking is if I make a FaceTime call to a friend who’s using 4G (symmetric NAT) and I’m behind my home router (port-restricted cone NAT) is it likely that we will manage to connect directly to each other? Or will the connection go through a TURN server?
    – Reveles
    Feb 28, 2021 at 20:06
  • @Reveles: SIP is not a protocol for NAT traversal either. But SIP and also WebRTC rely on ICE. Feb 28, 2021 at 21:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .