Hi, I’m still new to this subject and would rather ask the professionals: Is it possible to configure a fallback scenario? The idea is that Syncthing should first try to connect locally, but with fixed IPs. If one of them is unreachable, it should try to connect to a public address. If this address is also unreachable, then only via the relay server. Is that possible?
That’s what it does by default, mostly. It might happen that a connection is established faster over relay, but as soon as a direct connection is established, the relay one is dropped and replaced with the direct one. LAN/WAN connections aren’t replaced, because there shouldn’t be a choice: Either the remote is in WAN or LAN. When establishing a connection/dialing LAN addresses are tried first.
Ok. But if I want to connect without relay but over a static public IP?
What do you actually want to achieve?
If you don’t want relay, disable relay. If you don’t want relay when a direct connection is possible, but otherwise you do, I fail to see how it hurts that a relay connection might be faster than a direct connection, thus being established just to be replaced by the direct connection right after (Syncthing can’t know a priori that the direct connection will work).
You can specify just static IP(s) if you like, and they will all be tried.
Ok. I understand… I only had some security concerns… Thinking about it could be better to connect first only in LAN, then WAN (but with public IP first) and only if nothing else is working it should try to use relay. So relay would be used only in situations where everything is not working. But maybe this isn´t a good thought after all, because I understand that it is not a security issue to use relaying.
The LAN -> WAN -> Relay is pretty much the natural priority of things.
I don’t think there is a big security risk in whichever connection type is used, as it’s all TLS encrypted regardless. Sure, using LAN you minimise the risk of man in the middle attacks, but you’d have to assume that TLS is fundamentally broken for that to be a risk, and if TLS is fundamentaly broken, there are bigger fish to fry (banks etc).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.