syntching cannot connect to private strelaysrv

I got the point yes, the reason for avoiding public relays is simply the response time, I am aware that traffic is encrypted so I am not really worried about the security in this case. I have 1gb symetric speed over the fiber optical connection and I was thinking to avoid any slow respnse cases because of using external relays that may not respond quick enough each time… Correct me if I am wrong…

Yeah, but that usually is the case :upside_down_face:. Of course, it is certainly possible to write documentation with assumption that the user has zero previous knowledge, however this requires a) a lot of time and effort, and b) actual experience with teaching people from the ground up, which most developers simply have none.

Please consider improving this particular part of the Docs yourself too, especially if you do manage to run the relay server, so that you would then be able to add the missing parts that were confusing to you!

1 Like

agree :slight_smile: will sit down when I am done with my setup and write some examples so new users can understand it more quickly and easier as well… Thank you :slight_smile:

One more detail I missed from your previous message.

Do you mean that you have Global Discovery disabled? Why?

1 Like

hm isn’t global discovery part of the global relay server usage ? Or I am missing something ?

to my understanding global discovery is not needed if you are hosting your own relay for example and you point the syncthing clients towards it. Correct me if I am wrong…

No, they’re two distinct concepts. You can use either one on its own, but relays without global discovery only works by entering the relay address directly.

Relays are relaying actual data (encrypted). A device connects to one, as one of its listeners. Which one is used can then be published to the global discovery server, so other devices can use that relay to connect.

Global Discovery only collects and provides addresses. They might be relays or any IP address published by the device (its listening addresses). This helps two devices to find each other if NOT on the same LAN (where usually local discovery works), or if local discovery does not work for some reason.

1 Like

so in general, say we have two scenarios

  1. scenario (usage of the private relay server not public) this is the only needed configuration on all Syncthing clients

  1. sceanrio (no relay servers at all in the picture, just direct connection between Syncthing LOCAL PC and REMOTE out in the internet

Now I think I will go for the direct connection to eliminate relay server completely to avoid any kind of latency in response…

Just checking my understanding here…

thank you for your patience man :slight_smile: !

You don’t even need to avoid relaying, trust me. If a direct connection is possible, Syncthing will always choose that over the relay connection.

There is no need to disable Global Discovery in either case. Or do you have a specific reason?

Also in either case, I’d leave the Sync Protocol Listen Address field to contain , default at the end. And the same for the remote device address. Otherwise you will definitely only get relay connections or none at all, even if a local connection would be available.

If your goal is to avoid latency from relaying, then yes, not using a private relay but direct connections is definitely better.

1 Like

yes I am aware that Syncthing always prefer the direct connection but such a connection is not possible between the pc-s that are not on the same network unless you use direct connection and direct ip addresses and opening the FW ports for it (tcp/udp 22000) so those pc`s needs to use relay server either own ones or a public ones…

My main goal is to tune the Syncthing as much as possible as well as avoid any connection that may cause any kind of latency as I am planning to sync larger files and it will be many of them. My own relay server will not make any noticeable latency as it is located on 1gb network and is reachable by all pc`s both LAN and those on WAN… those on WAN location also have 1gb connections so it all will be pretty fast and stable so that is the reason I will avoid any extra connections that I can live fine without.

So is my understanding in the previous post correct so far or I misunderstood something ?

In general, a relay server will definitely add latency. What it likely does not affect is throughput, in theory. However, with Syncthing’s protocol, higher latency also results in overall lower throughput, because many back-and-forth exchanges happen to acknowledge stuff and coordinate actual data transfer. So no, any relay server will not give you “better performance” than using no relay server.

Your misunderstanding lies probably in the meaning of a “direct connection”. We talk about a direct connection when only routers are involved, but no actors on higher level protocols (such as a relay server or a proxy). Such a connection can be local, if the devices are on the same LAN without routers in between. That will display as “TCP LAN” in the GUI.

A direct connection can however also be made through routers, if there are no firewalls blocking traffic in both directions. It is sufficient to open (and, in IPv4 NAT, forward) ports on one end of the connection. If a device is reachable on an IP address:port 123.45.67.89:12345 from the Internet, Syncthing can make a direct connection to it, displayed as “TCP WAN”. In your firewall you’d configure that port to be forwarded to the device’s 192.168.123.45:22000 internal LAN address:port. Both of these addresses will be published to the Global Discovery server, so local devices and those from somewhere on the Internet will have a chance to connect.

That’s one of the great advantages of Syncthing, it tries very hard to make a direct connection under most circumstances if at all possible. Opening firewall ports manually is just one way, it also tries UPnP, NAT-PMP, UDP hole punching, etc… to get through all kinds of NAT and firewall combinations.

Just set all options to default, with Global Discovery and Relaying enabled. Open the firewall ports from the Internet to the 22000 ports. Watch how each device will connect to the others and display “TCP LAN” for its local peers, and “TCP WAN” for the others. No further configuration needed, especially not running your own relay.

2 Likes

ok I think I understand it better now. Most of the PCs out in the internet are sitting behind some firewall so in general if we will “by pass” the relay and use “direct connections” trough router as well as firewalls both sides needs then open the port 22000 I assume or it is enough for only one side to open it ?

If we do not open 22000 syncthing needs to relay on the relay server itself to be able to reach the remote pc. On LAN itself there is usually no need to do anything if the two pc are on the same LAN subnet in this case LAN connection if automatically formed.

In one of your previous posts you mentioned leave all at default and open the ports this means first time when setting things up and when PCs are forming the connections with each other this first process goes then via relay server (if all default if left as is) and afterwards when syncthing discovers that both PC actually can be reached via 22000 it uses “direct connections” and relay want be used anymore… ?

Also there is no need in this case to type listening addresses manually just leave it default but open ports 22000 …?

Open port 22000 on one side. I’d suggest on the network where you were trying to install the custom relay. Yes, one side is usually enough.

Leaving Listen Addresses at default means it will open up IPv4 and IPv6, with TCP and QUIC each. And in addition, register with a relay server from the public pool. All addresses from those 5 listeners are then published to global discovery.

The other side (if it has the device ID configured as a remote of course) will look those up and try them in turn. Might also be in parallel, not quite sure. Whichever connection is established first, is used. Meanwhile all other addresses are tried as well. If a better connection is established, the previous one gets replaced. So it’s usually a matter of seconds to minutes until the direct connection is established. All without specifying any addresses manually.

1 Like

ok will test it and see how it goes, have opened 22000 for entire LAN subnet so whichever ip address PCs got it will work so I do not need to open one by one…

But this field Listen Addresses, I will leave this as default as you already suggested BUT if I should type the ip manually for some reason on one PC this would be the remote ip of the another PC right ?

Thank you so much man for taking time for such a detailed explanations, really appreciated!!

1 Like

No, the Listen Addresses field must have an IP address (actually also a scheme like tcp://, looks like a URL) of the host where Syncthing is running on. It won’t really do any good to change it in your case, as by default Syncthing listens on all local interfaces. The only reason to change it would be to specify a custom relay server in addition, but the public relay pool is also already included in the default setting (as a fallback).

If you want to test your firewall settings, entering the public IP (as seen from the Internet) with the corresponding port on the remote device GUI is possible. But then in the Edit Device > Advanced > Addresses field in the device configuration for the device behind the firewall, on the remote device GUI. You see it can easily get complicated, so best to leave everything at default values unless you really understand what you’re doing.

As for firewall ports, I don’t know your specific network configuration, but “opening 22000 for the whole LAN” sounds strange. Do your internal LAN devices all have valid Internet-facing IP addresses? Are you using IPv6 or IPv4? If it’s IPv4 and they have private, internal addresses, your router is doing NAT. In that case, you will need port forwarding and seen from the outside, at most one device can use the 22000 port externally. Internally they will all use 22000, but need different mapped ports on the router. If your router does UPnP and it’s allowed for the internal devices, Syncthing will create these mappings automatically.

1 Like

ok so Listening address is actually the ip address of that particular Syncthing client we are on and if we leave it default it will listen to all available IPv4 as well as IPv6 addresses, and that field is also use to specify the Relay server if one is used either as an edition to default by using coma (,) or only relay and remove default, I think my understanding on this one is correct.

Regarding the firewall and testing, I think I did a mistake opening port towards entire subnet it is wrong it should only be opened towards one ip address one particular PC. I am using btw both IPv4 as well as IPv6 addresses. IPv4 is NAT-ed from WAN to LAN and Ipv6 does not have any NAT of course it goes straight out to the internet.

So in general IF I have multiple PC on LAN that needs to sync with one PC out in the internet I need to map port 22000 to one PC and for another I need to use 22000 as public that translates to say 22001 and change default syncthing port to this one on that pc client ?

Can we btw modify the (default) list somehow in syncthing ? just curious in this case one can make own list call it whatever one like for easier remembering later on… again just curious not that I need to to it now.

And yes I am aware the easiest way is to keep it all default but doing so one is not learning how the application works in general that is the reason why I am experimenting in addition to avoiding external relays because of the latency etc…

thank you again!!

If you have IPv6 available, just open the ports in the firewall for incoming connections, and you’re done. For IPv4 with NAT, yes it is advisable to adjust the internal ports as well to match the external ports. Otherwise the address announced to the global discovery server will have a port that doesn’t actually work from the outside. This point is handled automatically if you’re working with automatic UPnP port mappings.

No, the “default” list is hard-coded and you’d need to recompile Syncthing to change it. For adjusting the ports, simply copy the default value stated at Syncthing Configuration — Syncthing documentation and adjust as needed.

1 Like

I have in general 4 different locations, one of those is my main home location where I have fiber optical connection 1gb as well as IPv4 and IPv6 but other locations are still only using IPv4 as some ISP are not in hurry to implement IPv6 yet so dumb but that is the case. So in this case I will not benefit that much from IPv6 at least not yet, and also on the other hand my current ISP at my home location does not allow us to have static IPv4 another very dumb case without any common sense reason so when the router changes my IPv4 I need to adjust the ports, so this can probably be fixed with some scripting if Mikrotik router do support API so that script can log on to it and update the rule once it discovers that there is new IPv4 renewed. When I say update the rule I mean update the IPv4 WAN LIST becaus eI am using LIST as name in all of my NAT FW rules so I only need to updat ethe WAN_IP_LIST as this is its real name in my case and I have then updated all the rules at the same time because all are inheriting this ACL list.

But ok, now I understand what Listening Address is used as well as which ports are used and when also for Relay when to use and how to set it up.

The only one more thing, Global Discovery Servers field where we see the default as default IF one should change this field what is typed here also which ip address is used here ? I was thinking that IF one is using Relay that it should be typed here but now I know that Relay server is to be added in Listening address not here but what is added here if not using default ?

Strange thing that you need to update any rules on your router when its external IPv4 changes. I’ve never heard of such a thing. Usually it has port forwarding rules specified by internal IP, internal port, and external port. The external IPv4 is naturally the IP of the WAN-facing interface. Are you sure you’re not over-complicating things?

The Global Discovery Servers config points to those servers where your Syncthing instance will publish its own listen addresses (incl. relays), associated with its device ID. And it is used to look up other device IDs and find out their possible addresses. So for the mechanism to work, they need to pointed at the same discovery server. You can run your own syncthing-discosrv if you don’t want to use the public ones, but it really isn’t worth the effort usually. Especially when your home location has dynamic IPs, which makes it harder to consistently reach your own server. I had one case where I needed a custom discovery server, but that was a local network without direct Internet access and with client isolation, thus local discovery between clients didn’t work.

And yes, I completely agree, people, companies and ISPs not embracing IPv6 are really missing out. Absolutely not understandable how they still fail to catch up with basic Internet standards that are now almost 30 years old IIRC.

1 Like

updating those rules may sound strange and I understand it this is because I used to have an ISP before which allowed me to have static WAN ip address and also route additional subnet towards that static ip address they locked via DHCP and then I had plenty of servers behind where each one of them had its own WAN ip address assigned, no NAT were used at all… And since I have to many of those rules I need to take some time to fiks this and remove this way of opening and add only WAN interface “as a destination” and not add any WAN ip in it as I only have one now which is dynamic so I will fix it I am aware of that part, that is why it looks strange.

Ok so the Global Discovery Servers are the ones that gets the listening addresses for the syncthing itself as well as its relay server IF any is used in Listening address such as: default, relay://relay_ip_addr:22067/etc… and those infos are send to the global discovery servers and this is then how the global discovery servers are generating ID for each syncthing application that is running ??