I tried using my own global announce server.
I have multiple windows PCs plus one android device connecting.
One of the Windows machines is a “server” and is running the global announce server.
This machine is on a LAN behind a normal router/firewall. The ports for the global announce server are forwarded to the machine and my devices can connect to the announce server fine via IPv4 (no IPv6 I think) both from within the LAN and from elsewhere (ie the general internet).
The connection status for Global Discovery always shows 1/2.
BUT:
All devices work fine when connecting to the announce server via LAN, ie they show as connected and can sync.
None of the devices can connect/sync when not on that same LAN, even though they DO see the global announce server (they all connect to it via the servers public IP).
I assume NAT is screwing something up with the global announce server where it only registers their local LAN address?
Strangely enough, I cannot even get Syncthing to work when connecting to my LAN via VPN (which should emulate those machines being on the local LAN).
The announce server uses the ip of the announcer when recording your announcement, which most likely ends up being a lan address which makes no sense when connecting from the outside.
VPN’s sometimes use a separate subnet too, so it’s specific to the subnet configuration.
The best thing I can suggest is to enable STTRACE=discovery to see what IP addresses you get back for your devices on LAN, and see if you can actually reach them over that address.
Not sure what that command does … I use Synctrayzor so I can easily see all the IPs for connected devices. They all show the local LAN IP address (192.168.1.x:yyyy).
So how can I fix it so that SyncThing works outside the LAN?
You are correct that the subnet for the VPN is different (255.255.255.255 vs 255.255.255.0) though the IP range (192.168.1.x) is the same … never noticed a difference though and everything else works fine.
If your discovery server is within LAN, I don’t think you can make it work outside of LAN, as it will always report LAN ips which will be invalid from the outside.
The VPN option should work, but you need to figure out why it doesn’t as it probably tries to route to LAN through the internet (given the subnet mask)
Sorry to say but that is not a very good design.
Global discovery should “just work” whether on a LAN or on the public internet.
What’s the point of the global announce server if it doesn’t do anything?
Maybe the Global Announce Server should facilitate traffic to LAN machines?
It should mostly just work if you use the standard announce server and have an UPnP NAT gateway. For setting it up with VPNs, corporate firewalls and private announce servers there’s not much we can do to make it work out of the box in every scenario. I’m not sure what you expect here to be honest.
Yes. But this whole thread is about using your OWN global announce server.
The VPN and all of that doesn’t matter - it was just a way to get around the inherent problem with the global announce server.
If you ask me the announce server should always ask for/get 2 IP addresses for each device:
A local LAN address (for devices on the same LAN) and a public IP.
Then the server can provide the LAN address to devices that are on the same LAN and the public IP to devices that aren’t.
<= Problem solved.
Sadly, I don’t know anything about programming, otherwise I would implement this change. I am very grateful to the great minds that CAN program and are able and willing to help out with this project.
Seems to me that this solution shouldn’t be that difficult though and would fix a lot of issues.
As a side note, please don’t tell me that my problem is an isolated issue:
Everyone running the Global Announce server on a LAN has this problem.
I thought the whole point of SyncThing was that we are not reliant on some person/individual that can (a) do harm and (b) may vanish without any kind of warning. If we are all reliant on your global announce server for this to work as advertised, then the project really is not much better than BTSync.
Every Business (or security minded individual) running SyncThing will run into this issue as they are unlikely to trust (or legally unable) to trust some third party announce server that is no part of a company that can be held accountable.
Your machine itself doesn’t know it’s own public address, neither does it know what external port (and if any at all) the router has mapped for it.
Yes, everyone running a discovery server behind a NAT has this problem, for machines within the NAT.
Nobody can harm you by providing you an announce server, and the code for you running you own is there, so even if it vanishes, no big deal.
Same way any business (or security minded individual) has a machine or a 2$/month vps which is available on the public internet which circumvents problems at point 1.
You think the problem is an easy problem, but in reality, once you know how basic networking works, it’s not such simple, due to the first sentence I wrote.
Yes, it’s sort of fixable, but giving this “everything is shit, you don’t deliver” attitude in the multiple posts that you’ve produced here, I doubt will yield anything.
Thing is, running a discovery server of your own kind of does require you to understand the underlying mechanisms and a bit about networking in general. It is not the “out of the box, just works” configuration.
There are several ways devices can find and connect to each other:
Local discovery works for devices on the same LAN, without any external support.
DNS works as always, which is a totally workable solution in an enterprise with for example AD and dynamic DNS. Also perfectly fine for the case where there’s a central server on a known name or IP address that things can connect to.
Finally, there’s global discovery.
The global discovery server uses the source address of the announcement as the device address. It doesn’t get to know your internal (LAN) IP. This is by design, as that is something that some people consider confidential and that we shouldn’t leak. It’s also information that’s usually not relevant as it can’t be used to connect to the device from the outside anyway.
If you run an internal discovery server on a network with several routed LANs, this will all work perfectly fine. If you have intervening NAT or firewall devices that block traffic, you need to handle that situation according to whatever policy is in place. That’s your responsibility as an enterprise network person and not something we can or should get to work out of the box.
If you run a discovery server on the internet for just you and your circle of friends, and you each have a common NAT setup at home, then things will work out of the box.
Sorry but it does NOT work.
I assume my usage scenario is common for 99.9% of users, ie I have a NAT in front of my LAN.
I don’t follow why you don’t implement at least one of several solutions:
Announce BOTH the WAN ip and LAN ip to the announce server.
Fix the announce server so that if a local device announces to the server (which is on the same LAN) via the public WAN ip, it actually uses the public WAN ip for both. Based on your description this should work but it does NOT.
Why don’t you make a pull request fixing this? Given it’s such a serious flaw for you.
Yes, and I cannot be nice to people who turn up randomly, start producing multiple posts telling people that their work is shit, and what they need to do.
And no, you are not pointing out a serious flaw, you are pointing out your usecase which you are very dissatisfied that it’s not covered by the general implementation.
I did not say your work is shit.
But I can tell you one thing: your manners are fucking shit and you must have the reading comprehension of a 2 year old.
Unless, your getting your panties all up in a bunch, because I dared to point out that the current global announce system is flawed, is evidence that maybe your work is indeed shit?
And don’t tell me my usecase is unique: 99.99999% of users sit behind a NAT.
I tried to be nice, even tried to come up with solutions, but you apparently cannot handle it if somebody points out a flaw.
If you cannot contribute to the discussion like an adult, maybe just bug out.
but 99.9 of them probably don’t want to set up a announce server behind that NAT
Can’t you just set “some.url:12345, dynamic” where some.url:12345 is your address for all your devices behind your NAT? The discovery server will be useless in that case but you should be able to connect.
Like mentioned above your devices behind the NAT don’t know your WAN ip, so they can’t announce it, it’s not that easy to make that possible.
You’re not running a discovery server on the internet. You’re running a discovery server on your local network. “Yes, but it’s accessibly from the internet” you might say? That doesn’t matter, because your devices aren’t talking to it over the internet: they’re talking to it over your LAN.
If you were actually running a discovery server on the internet, it would “just work”.
Your use-case is (likely) unique, in that you’re running a discovery server on your LAN, then expecting it to work over the internet. This isn’t the 99.99999% use-case, this is the 0.001% use-case (and that number’s actually pretty accurate).
I haven’t tested this, but as another solution, you should be able to set up all of your devices so that they know the public IP of your discovery server (i.e. not its internal IP). Each device on your LAN will set itself up with a different external port through UPnP, then connect to the discovery server using its external address. The discovery server will then create records for all of your devices having the same IP, but different ports. All device-device connections will then use the same external IP, but your router should be smart enough to not send the traffic out onto the WAN. This should continue to work as devices leave your LAN.
As with any open source project, remember: if you are not satisfied with the level of support you have received from the devs, you’re entitled to a full refund.
