I have a Windows PC running Syncthing out in a rather rural area, so I have two Internet connections at the location. One is stable but data-capped, the other has no data cap but can drop or cut-out at times (sometimes for short periods, sometimes long ones). I have the PC connected to both networks by having it connect to the more stable network via wired Ethernet, and to the other (less stable) network via WiFi.
With Syncthing left at default settings, it will happily start using the stable Internet connection if the unstable one goes down, and then quickly uses up my data cap. So, I’d like to be able to restrict traffic to and from Syncthing to using only the one network interface (in this case, the WiFi interface) and not even attempt to use the other interface if the unstable Internet connection goes down. (I am OK with no synchronization happening while the more unstable Internet connection is down.)
I believe I have to do this by going into the settings from the Actions menu, then clicking the “Connections” tab and changing the “Sync Protocol Listen Addresses” field to something other than “default” (I’m assuming the local IP address used by the desired network interface).
Can someone provide the correct method to make this happen? Thanks in advance.
just put tcp://<your ip>:22000 into “Sync Protocol Listen Addresses”.
22000 being the default syncthing data port. there is also quic:// protocol, but syncthing will prioritize tcp if it can, by default.
I got that from the help page, but needed to know specifically if the IP address to put in that field is the local IP address used by the desired interface, or something else?
If you have relaying enabled, that might not be enough to fully restrict it from using the wired interface though. As long as there is a default route to reach hosts on the Internet, a relay connection will probably still be used until a direct connection to the other end is established.
Unfortunately, I do have to rely on relaying for data transfer. There’s double-NAT-ing going on at both ends (both locations where I have PCs with SyncThing installed) and I don’t have access to one of the routers (piggy-backing on a neighbor’s Starlink, with their permission) to be able to open ports or anything. And neither location has static outside IP addresses, so I have to rely on Global Discovery to establish the connections.
But, it sounds like you’re telling me that putting the local IP address of the desired interface into the “Sync Protocol Listen Addresses” field is NOT going to stop it from using the other interface if it finds a path via the other interface. Correct?
Yes. Syncthing tries really hard to establish a connection by any means. And if there is a possibility to connect via the internet, through whatever local interface, Syncthing will probably find a way to utilize that.
You might have better chances limiting the interface access using the local firewall.
Not to be “that guy” but it does seem a bit counter-intuitive to have a setting to specify what address the app should use, only to have it essentially ignore it. Understandable if you leave the field as “default” for it to use whatever means it can find, but seems weird for it to have such a field to potentially impose a restriction on it, but it gets to ignore what you’re trying to tell it to do.
OK, what rules or port-blocking would you recommend? I do have access to the near-side router for the connection to the Internet that I don’t want it to use, so tell me what to block, please (and thank you).
It does what it says. It sets the addresses it listens (receives incoming connections) on, not the interfaces it dials (makes outgoing connections) on.
OK, then, let me make sure I’m understanding. For simplicity, let’s call the desired interface the “good” one and the one we don’t want it to use to be the “bad” one.
So if Syncthing can attempt to “dial-out” (so to speak) on either interface, but can only listen for incoming connections on the “good” interface (with the IP address restriction added), will it actually MAKE a data connection to an interface where it’s not listening for one? In other words, I can envision where the program would send out a bunch of “Here I Am” messages over both interfaces, and the Global Discovery servers would likely attempt to respond back to messages from both interfaces, but if Syncthing is only able to LISTEN for the responses on the “good” interface, it should never even “hear” the responses sent back to the “bad” interface, right? Or does it work differently than I’m imagining and could still somehow establish a data connection to the relay servers over the “bad” interface (even though it’s not “listening” for connections on the “bad” one)?
No. Listen addresses only affect incoming connections, not all incoming packets. It will happily receive responses on the bad interface as long as it initiated the connection (i.e. it is an outgoing connection).
Alright, some networking basics. When Syncthing tries to contact the relay server, it’s up to the local operating system to decide which interface will be used to send out the packets. That one will also receive any and all response packets. The decision is based on the routing table, which also defines a “metric” which usually prefers links with higher bit rates over slower ones, or possibly wired over wireless. If one interface fails to establish a connection, the OS might even try sending the same initiating packets over another interface. That’s all completely transparent to the application layer, any logic on these lower layers is up to the OS.
I think the socket API might provide a way to specify the outgoing IP address for TCP connections, but that’s definitely not standard application behavior. And the OS could still just ignore that hint.
The firewall solution involves your local computer’s firewall, not the router. What operating system are you using Syncthing on?
All PCs running Syncthing are on Windows. The specific PC that has the two interfaces, I think I had to set the metric to prefer the “bad” interface to ensure that my remote-access traffic will reach it (so I can still access the computer even if the “good” interface goes down). Thanks for the reminder of how a network stack works within the OS.
But to return to your earlier recommendation to utilize the router to achieve my goals here, if I’m using the default ports (i.e. 22000) is it just a matter of having the router block traffic over port 22000 to the local IP address of the computer’s “bad” interface?
On Windows, the built-in firewall has the ability to define rules for matching a specific executable. I’d simply use that to block any traffic for syncthing.exe on the bad interface, incoming or outgoing. Or even better, re-route outgoing connections through the good interface.
Sorry I can’t help you much more with the specifics though. It’s been many years since I configured firewalls, and that was always in Linux environments. But I guess the Internet and chat bots are full of information about how to achieve such a configuration.
Ah, yes. The often overlooked built-in Windows firewall. I absolutely overlooked it, myself. I will try that, and I thank you for the suggestion.
But, for my own curiosity, is there a particular port number or numbers (TCP and/or UDP) that Syncthing uses to communicate over (either for Global Discovery or for the actual data transfer packets back-and-forth with the Relay Servers)? Is the default port of 22000 used for everything (other than the port used by the local browser to display the webpages from the app’s internal web server)?
The port for outgoing connections is usually randomized. And for example different relay servers could use different ports. So I think filtering traffic by ports is not going to be very reliable. Better block the whole interface, with maybe an exception to allow HTTPS access to the GUI on port 8384.