Device behind NAT is sometimes connected without relays!

I turned on Transverse NAT and global discovery, but turn off relaying, on both machines. One device is behind NAT (at my work place, as an always-on server) and the other is a mobile device.

When the mobile device is outside NAT, it gets disconnected. However, after 10–30 minutes, it somehow connects to the device behind NAT and firewall!

How does that happen without relaying?

I read that Transerves NAT enables a bunch of settings, such as UDP hole punching etc that somehow creates a connection.

Can someone explain the steps?

Also, would it be a security problem? If not, how can I speed it up?

Thanks!

All syncthing traffic is always encrypted, regardless of what transport it uses, udp relay or whatever.

I can’t really say how it connects, but the UI shows the connection type used, and from the port numbers you can infer who managed to connect to who to answer that.

Syncthing already pretty eagerly tries to reconnect, so I can’t say why it took 10 minutes, but it might be that it takes 10 minutes to realize the other side has moved to a different network.

I think going through the logs from both sides would explain the story in full.

Thanks!

Yes, I had already looked into the log file. The external device connects to the server inside a private LAN network, using UDP.

With no relaying, I have no idea how this could be achieved. My company network is certainly not open to public. Somehow a port is opened. Is it with the help of an intermediate server?

The expected behavior is never connect, when relaying is off and there is a firewall with “deny all incoming” (but it’s company’s LAN and I am not sure of how it’s set up).

What are all methods that synchting uses for passing NATs, other than using relays?

You can read about STUN as to how it works.

Same like webrtc works, there is a third party for the initial handshake, but its direct connection after that.

It uses TURN (relays), STUN which is just hole punching, on both UDP and TCP.

2 Likes

First of all, I feel the need to state that a NAT itself is not a firewall (or a firewall-replacement), even though it’s commonly mistaken as one.

As far as I’m aware, syncthing currently has three NAT/Firewall traversal mechanisms:

  • Automatic port forwarding (UPnP, maybe NAT-PMP(?))
  • TCP hole-punching
  • UDP hole-punching

The first mechanism simply asks the router to forward one port to the computer, to allow inbound connections. The router needs to accept these forwards.

The hole-punching mechanisms can work without approval by the router. Those work on the assumption, that a NAT/firewall is configured to allow outbound connections, but not inbound. In this setting, when both devices are behind similar firewalls/NATs, you can simultaneously make outbound connection attempts from both devices to each other. This causes the firewall on both sides to detect an (approved) outgoing connection which will then unblock the flow of data, enabling an actual connection handshake.

The technical juice is a bit more complicated, as you need someone to coordinate the whole thing - both sides need to know the IP addresses (and ports) of the other peer first, which is usually exchanged through a third intermediate server. In case of NAT, knowledge about the topology and NAT-type is also useful for the application, for example to predict port mappings used by the NAT. These things are handled by protocols such as STUN.

2 Likes

That’s it, it must be UDP hole punching using the STUN protocol. We get rid of those relays/intermediaries, and establish direct peer to peer connection.

It’s very good, no need for any set up and deal with firewall or routing problems. I only hope that the STUN protocol itself is secure.

It takes sometimes tens of minutes, and is not immediate, but it seems to be working.