I’d just like to make a comment regarding documentation if that is helpful. I’m only a low level pretend geek. I have been using Syncthing for a while and decided to look more into direct connection vs relaying which I didn’t understand (possibly don’t even now). I’m using computers in two different locations behind NAT routers.
As I understand it if you don’t have a port open you are using relaying (although I don’t altogether see why - is it because you can’t rely on addresses being static?). So transfers would be much slower as it uses an intermediate server. I had some problems because I didn’t read the Firewall setup part before trying to modify config.xml - and failing to get it to work. It turns out it’s much easier to let Syncthing work out the config as you only need to set up port forwards and then everything happens automagically.
I think it would be helpful in the Getting Started section at the end to mention that Syncthing will handle communication wherever your devices are but you can speed up transfers over the internet by configuring direct connection rather than using the default of relaying via a third party server. For users behind a NAT router this would require port forwarding. Further details are in Firewall Setup (link).
Of course I may be missing something or glossing over ifs and buts.
Not necessarily. Syncthing will by default attempt methods such as NAT hole punching to establish direct connections, even with no explicit port forwardings being set up.
The details really depend on the user’s exact network setup, there is “one size fits all” answer here. Some networks may require explicit port forwardings to avoid relays, others don’t. In general port forwardings make things a lot easier.
Syncthing uses discovery servers to find other peer’s addresses. Finding addresses is generally not an issue for syncthing and not the primary cause of relaying. Rather it is firewalls/NAT. A port-restricted NAT basically behaves like an outbound-only firewall: It won’t allow incoming connections.
For enviroments where only one side is behind a NAT and the other is not (i.e. any client-server setup, such as your browser and this forum) this is not a problem: The client behind NAT establishes an outbound connection through the NAT and all is fine.
If both parties are behind NAT however, that’s a conflict: If Alice sends data to Bob, the NAT of Bob blocks the data. If Bob sends data to Alice, Alice’s NAT blocks the data → No direct communication possible.
There are methods to work around this dual-sided NAT issue (i.e. hole punching), but they don’t work reliably in all network setups.
Thanks for the explanation. I was thinking that a remote server could introduce Bob to Alice and vice versa but I suppose that even if Alice wants to give Bob permission to talk to her, Alice’s NAT will prevent it.
I’ve had good luck using Tailscale for remote connections. When you set it up, you get an IP address for each device, then connect using that. Pretty painless.
What I understood : suppose peer A is behind a restrictive NAT (no dedicated syncthing portforward and UPnP disabled) and he hasn’t control over this router. To prevent relaying you only need to portforward (or enable UPnP) on peer B side … (and of course have the firewall in ST machine B allow ST inbound/outbound connections ).
).