Can't sync between two VLANs behind a NAT.

Support
1

Hi all,

I’m working with Synching a bit as an alternative to BTSync, since I don’t like the direction that BTSync is heading. However, I have run in to some issues. Since I get a little long winded, I’m going to create a post for each issue. (Let me know if this is bad behavior, and I won’t do it again. :wink:

My configuration is probably far from typical in a home environment, so let me see if I can explain the situation. I spent a bit over a decade doing IT for a major research University in the US, grew up around electrical stuff, and have been writing code since I was little. So, it isn’t a surprise to most people that know me that I have a pretty extensive network in my own house.

Since I work from home, I have two main VLANs in the house that I use. One is for my home network, the other is for my work network. Both VLANs are routed through a Cisco ASA 5520, which is then connected to a Comcrapst business cable modem.

For my initial test, I loaded Syncthing on my Nexus 5 running Android 5.0.2 (which has since been updated to 5.1), and on a Mac Mini running OS X 10.10. The Nexus usually connects to my home network, which has an IP range of 10.1.1.0/24, and the Mac Mini is a work machine on an IP range of 172.16.1.0/24. Each IP range is on a different VLAN, routed by the ASA.

One other important detail is that on the “outside” interface of the ASA, I am NATting. So, to the outside world, all of these machines appear to be coming from the same address.

So, here is the problem. I set the two devices up per the documentation, and waited for a while for them to sync. (“A while” being several hours.) And they never did. According to the web page for the app, the two devices never even connected to each other.

I didn’t see anything on the console that would make me believe that Syncthing wasn’t working properly. The only thing that I noticed that seemed a little odd is that the “Global Discovery” said “1/2”. However, I read a post on here about supporting IPv6, so I am wondering if the 1/2 means that I have an IPv4 connection, but not a v6 connection. (Which would make sense, as I don’t currently route v6 out of my network.)

I wanted to be fairly sure that the issue wasn’t likely to be Syncthing, so I tried putting the address of the Mac directly in to Syncthing on Android. As soon as I did that, the two connected and started to sync. (Although the sync didn’t work quite right… I’ll get to that in a second.)

Since I have considered writing an app like Syncthing (and done some research on the issues that need to be overcome), I am assuming that “Global Discovery” is referring to the server on the Internet that manages the NAT traversal issues related to building a TCP session between devices behind a NAT. I’ve also noticed that Syncthing has a method for finding other devices on a local network. So, my current working theory is that the Global Discovery server is seeing a request from my Android (or OS X) device to find the OS X (or Android) device, and is ignoring it because it appears to be coming from the same IP address on the Internet. Or, put a different way, the Global Discovery server assumes that all NAT connections have a single network behind them.

For fun, I just tried connecting my Android device to the wireless network I use for my work VLAN, and sure enough, the two devices saw each other (after a minute or two) and are now claiming to be up to date.

So, does my theory seem valid? If so, is there a setting that I can twiddle to fix the problem? Or can I run some kind of a proxy discovery server that would help me resolve the issue? I need to be able to sync data between these two VLANs.

2

Local discovery does multicasts which requires both devices to be on the same subnet (which they are not in your case).

Global discovery only performs announcements and discovery, it doesn’t do NAT punch through, hence you should forward one of the devices port to the outside world for the other one to be able to connect, because they are in different networks, effectively both being NAT’ed even though it’s the same NAT.

If 10.1.1.0/24 knows how to route to 172.16.1.0/24, you could run a discovery server within the network to resolve this.

3

Do the multicasts that are sent have a hop limit? (i.e. Are they scoped to stay on the LAN, or are they allowed to cross a router?) And, if there is a hop limit, would it be possible to request that it be an advanced configuration setting in future versions? It has been forever since I did multicast routing, but I expect that I could set this up internally.

In the mean time, if I set up a local discovery server, will it prevent me from using the global discovery server for when I am out and about? The documentation at https://github.com/syncthing/syncthing/wiki/Config-File-and-Directory doesn’t seem to have an option to point to a local discovery server. Is there a setting that isn’t documented?

Also, is there any documentation on how to set up a local discovery server? (If not, I will volunteer to write some if you guys don’t mind doing a little hand holding as I work through the process.)

As I originally said, I expect that my configuration is pretty unusual for a home network. However, the companies that I have worked for in the last decade have almost all used NAT to hide the corporate network, and almost all have had their wireless network on a different VLAN than their wired network. (Which is a good idea to avoid foolish users creating loops while playing with settings on their machines. :wink: So, I would think this might be an issue that will be increasingly interesting as Syncthing strives for world domination.

Thanks again!

4

Actually I think for v4 we do broadcast, for v6 we use multicast. I think broadcast works only within the same subnet (I might be wrong), and it seems you don’t have v6 support.

The code is all here: https://github.com/syncthing/syncthing/tree/master/internal/beacon

The discovery server is at:

And --help has sufficient information for people with basic technical knowledge to get it up and running.

You can have multiple discovery servers configured (just like it does now for v4 and v6), and the wiki is an old snapshot back when there was only a single discovery server.