So I have a question about STUN servers and holepunching. I generally understand how it works. Devices on each end have different types of NAT firewalls, But neither has symmetric NAT (the holepunching kiss-of-death).
I find occasionally VERY long periods (hours) where two devices that should be able to reach each other through QUIC don’t connect. And sometimes they connect and disconnect right away… And sometimes they stay connected for days.
Just trying to diagnose a few things. My primary question now is about the STUN server. I understand what they are, and how they fit in to the holepunching. My question is Syncthing has a “default” list of a number of STUN servers. When a syncthing instance is announcing itself to a STUN server, is it announcing itself to all of them? or only one of them? (a random one?) If it’s a random one, a second syncthing instance has to announce itself to the same one within a few minutes in order that the first instance can get the port number and actually have the firewall route that port to the destination.
Is this correct?
Does syncthing announce its presence to ALL of the STUN servers in the default list every time?
Any other explanations for connects and disconnects when using QUIC? TCP connections are more solid when we can make them, but in this case we prefer QUIC anyway because these are the high latency around the world links again…
STUN servers don’t store anything. They are just used by the client to obtain its own public IP. Syncthing uses the global discovery servers for the clients to exchange this information.
Holepunching can be a bit tedious, as the dial attempts from both sides have to match. Depending on the firewalls, the time between outgoing and incoming dial packets may need to be quite short in order for them to be treated as related.
I thought stun servers can return the source port for another ipaddrees/destination port combination which can be used to make the connection.
Can’t the source port be different than the destination port? Maybe I’m misunderstanding that bit. The stun server doesn’t have to store anything for long, but I presume the source ports are stored for 120-200 seconds or so.
STUN more or less just answers the question “what IP and port am I coming from”. It’s then up to the client to do something with that information, like publish it to our discovery servers.
Ok thanks. There’s definitely something I’m missing in my understanding of how this works.
I thought the NAT changes the source port and stores it in the NAT table, and to make a connection the other side needs to know what that source port number is.
Unless you’re saying that source port number is communicated to the discovery server and you’re not using the capability of the STUN server to get the other device’s source port.
The STUN server tells us our outside port. We announce that to the discovery server. The other side gets our port from the discovery server and tries to connect to us there.