I have started using syncthings a few days back an in general I like the idea and concept. To keep everything private and because my LAN configuration is kind of “complex” (many different ip ranges, broadcasting not possible) I have decided to host my own discovery and relay server. As long as I keep everything in LAN and use my LAN IP:PORT in “-ext-address” of relay server, everything works as expected. Unfortunately this does not work when leaving my LAN as the the client is not able to resolve the LAN ip any more… Here is where my problems and questions start.
To add more context here, I am using a nginx proxy to route discovery and relay traffic to my internal syncthing server. What I would like to achieve:
I have a dynamic public IP address, which resolves via my own domain.
My initial idea was, internal LAN resolves my domain address to the nginx ip address, when I leave LAN, the domain resolves to the external ip. This would work, but unfortunately the relay server requires to specify a “static” ip to be available on in “-ext-address”. As the server is always in the internal network, it is not possible to solve this via DNS. The client seems to always try to connect via the advertised ip instead of using the ip resolved for the relay address (not sure why).
Currently I can either sync via LAN or via WAN (depending on to what IP my domain is resolved). Syncing via WAN when in LAN is a bad idea as there is no need to go via internet.
Question 1: has anybody solved this or a similar problem?
Question 2: why is the advertisement of the relay server necessary at all? Why is the client not simply considering the ip it gets for the relay host domain?
Maybe I am wrong but as far as I understood if the clients cannot discover themselves in LAN because of missing broadcasts, the only solution to this is to use a relay server. Or maybe there is another way of “connecting” the devices on LAN. One device has a fixed ip, the other one does not have a fixed ip.
The second question relates to the fact that the “-ext-address” is the one the client tries to connect to, although the first connection happens via a different ip. Example:
Relay server started with: -ext-address=192.168.0.1:443 -listen=192.168.1.1:22067
Client has the following relay address configured:
relay://relay.example.com:443
Although the client initially connects via 10.11.20.1, the connection between the clients via relay is tried with 192.168.0.1 (the ext-address). Why is this the case? It would work just fine with 10.11.20.1…
Yes, this is a misunderstanding. They will connect without a relay if either can reach the other on any of their addresses, announced via a discovery server (regular global ones or your self-hosted one).
Right, so the -ext-address effectively means “talk to me on this address”. It will need to be an address reachable from both clients for the relay session to establish. Your setup with different IPs on the relay from either client’s perspective will not work. It’s not that it theoretically couldn’t, but that’s the way the relay protocol works. (Effectively the relay protocol is designed for the relay to be available on a stable, public IP.)
@calmh your comment confirmed what I tried after my comment: setting the listen address for the remote device to its local address (tcp4://192.168.x.x) AND the relay server, makes it possible to connect via LAN and WAN. I think this is a suitable configuration for me as of now.