prefer direct connection over configured relay

(Michael) #1

Oh hi !

I’ve seen topics on this before but haven’t found a complete answer yet…

We run a (public, FreeBSD) relay server in our organization’s network and configured our firewalled clients to use it with relay://..... Everything seems to work fine but what I don’t understand is why two firewalled clients always use the detour through the relay when in fact they could connect directly to each other.

We used pf to set a somewhat sane bandwidth limit for internal and external traffic on top of the unlimited strelay setting but this seems very unnecessary to me. It’d be much faster and simpler for our clients to not go through the relay at all and only use it to connect to external firewalled clients.

Any help? Is this behavior intended?

Cheers and thanks so much for this great piece of software

(Audrius Butkevicius) #2

What’s the end goal of what you want to achieve? You should give a more detailed description of what configuration changes you’ve made.

If you told clients to connect via relay:// addresses they will only connect via relays. If you told syncthing only listen on a relay:// it will only listen on relays, means others will only be able connect via relays.

Also, have you verified that your firewall rules actually work the way you expect using netcat or something?

(Michael) #3

Hi Audrius! Okay I’ll try to explain better :slight_smile:

The end goal is to save while also offer (a little) bandwidth:

  • all our clients (external and internal) should directly connect to os (our relay) and not hog other relays
  • still, our relay should be public to help out
  • our relay should not use unlimited bandwidth though
  • we configure all clients’ Sync Protocol Listen Addresses to use our relay with relay://<IP>:443/?id=<KEY>
  • but our local clients should still be able to use their 1/10 GigE connections by connecting directly to each other if possible

And right now it looks like as if all clients always connect to each other via relay (the address is relay-client). Your remarks suggests that I can tell clients to listen on relays and their local interface? I think that would solve my problem. How do I do that?

(Audrius Butkevicius) #4

No, because all clients are listening on the relay and relay only, because you removed default where default translats to tcp:// dynamic+relay://

You probably want tcp:// relay://yourrelay

(Michael) #5

That makes total sense :slight_smile:

I’ll experiment a little with default relay:// and tcp:// relay:// to see if everything checks out. Thank you so much.

(Audrius Butkevicius) #6

default + relay will result in connecting to two relays plus listen locally

(Michael) #7

And then it’s round robin with these two relays? I’m a little reluctant to use hard coded ports in the default setting to be honest.

(Audrius Butkevicius) #8

I think the order of which relay will be used is undefined, probably the one it can connect to faster.


My own configuration is this: relay://<my_relay>, tcp://:22000. This is basically the same thing as the default config, just with a fixed relay instead of a “random” one.

This configuration enables direct connections over internet and relay connections. If local discovery is enabled, local connections are also possible. Syncthing will always prefer the direct connections, sometimes it connects first over relay and half a second later the log reads something like “replaced connection X with Y” when it switches to a direct connection instead of the relay.

tcp://:22000 makes Syncthing listen on both IPv4 and IPv6 on port 22000. From my knowledge, this is effectively the default behavior, syncthing will by default always bind to 22000 for the server-socket. If you want to randomize this, try if port 0 works.

PS: If you haven’t already, have a look at this: