discovery of local network instances from outside

Support
1

Hi!

This is my first post on the forum, so let’s start with saying “thanks” for the very useful software that you created for the community!

I’m playing a bit with Syncthing. Currently I’m syncing a few files and also my Firefox and Thunderbird profiles across Windows and Linux clients, and syncing photo’s taken by my Android phone to my home server. Works just great. Firefox (and TB) needed a few ignore lines, would be great if the ignore settings would be synced as well, but I saw that is still on the radar for the future.

I have installed a discovery server and a relay, and I’m running them on a server behind NAT (on different KVM virtual machines). They are constricted to my “island”, no joining of other (default) discovery servers and relay pools. So far so good. Also set up port forwards on the router and matching internal and external DNS names.

Now my current issue. When using my laptop outside my local network, it connects to the discovery server, but not to the other syncthing instances running om my local network. Which makes sense, because the local instances announce themselves to the discovery server with their local IP address. My relay did not help much (it does connect to the relay from outside, after a while, but did not use it to connect to the client behind the NAT).

I “solve” this by specifying the device URL using the full DNS name and port, but that defeats the whole idea of running a discovery server.

Is there anything I can do to make this automagically work? I did not find a solution by reading the documentation.

If there is no real solution, maybe for the future these options might be considered:

  • Add an option for the local syncthing instance to add something similar to “listenAddress”, like “discoAddress”, to announce to the discovery server.
  • Add an option to the discovery server to try to reverse lookup the hostname for the connecting clients, and to announce that hostname (if found) to other clients. (Assume no port number change.)

The above would work if there is an internal DNS configured that matches external DNS. I especially would like the second option, as it just works if there is an internal DNS and different port numbers are configured for different syncthing instances and forwarded on the NAT router. Even if all instances would use the same port number, then it could work as TLS https connections contain host information (?) to a reverse proxy like squid or sslh could maybe do the trick.

Regards, Evert Mouw

2

I tested a local discovery server a while back, and entered my external dyndns name in the local nodes.

The local discovery server (which was running on the same machine as the syncthing node) saw my external IP for the incoming connection and the discovery worked, even one of the two node and the discovery server were in the same LAN.

My router is my DNS “server” and it is smart enough to keep the connection inside but it seems as if it is outside. So full local speed but connection work only as the port forwards are configured.

3

You have the #include directive, which can point to a file that is synced.

Run it outside of local network, like it was designed.

Yeah, that would work in some specific cases, but probably 99% of the time it wouldn’t make any difference, as people very rarely have internal DNS, even less likely configured in a way that it resolves to the gateway IP externally.

4

AudriusButkevicius,

Thanks for the #include hint :slightly_smiling:

And yes, running outside the network would solve the problem, but I now have syncthing instances running on all my servers / networks… Would just be nice to have a few extra options for the discovery server. I know, I know, not a priority, and should code it myself if I really want it, but running a discovery server behind NAT is not that unlikely. If clients can find their external URL somehow, they could then communicate that info to the discovery server.

wweich,

How did you enter the external name in the local nodes? Using the listenAddress?

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.