This is gonna be a weird one. I see a bunch of people trying to make local connections work but I have the opposite problem. I have my main server in a CoLo and my home office server at my house. Everything works perfectly. My issue is because I have to manage servers at the colo so often I have a permanent WireGuard VPN setup between the 2 routers. Syncthing finds the CoLo server as local and sends all the traffic over the VPN. This uses about 20% of the processing power on the routers and limits me to around 350MBps. I need to force them to talk over WAN. I don’t want to completely kill local connections at least at the CoLo, that server syncs to another backup server for quick failover in case of hardware issues and uses local 100gig connections.
You can use the advanced configuration option allowedNetworks to disallow the WireGuard network for the affected devices. That is, assuming your WAN network has static IP addresses, but I assume this is the case here.
https://docs.syncthing.net/advanced/device-allowednetworks.html#allowednetworks
I had read this but it doesnt seem to do what I want it to do. I want to disallow an IP or range. I kow I could specify the allowed addresses but that complicates things if say I want another server at an employees house. normaly it would work out of the box but in this scienrio addresses have to be added manualy and if they dont have static publics then we have an issue.
For now I have fixed it with firewall rules but this seems like a thing that is going to come up more and more as moble workforces are adoping wireguard.
the firewall rule are the least disruptiv nd should work for most people but it is anoying on our CoLo routers as we already have thousands of rules.
I was just about to ask what firewall you sre using. You need to QoS that badboy. Or there might be a way to limit wihtin Syncthing these days.
You need to use pipes
Everything we do these days is on Mikrotik. I built a filter rule to drop packets between the 2 local addresses so they had to use WAN connections. This was the cleanest setup I could think of, but I would still like to see a disallowed addresses section in synching.
If the colo server has a public static IP, set allowedNetworks on the home office server. Another employee with a server at their home could do the same or leave it as-is depending on their needs.
They all have static publics, but my worry was not for this situation but the one that comes later, if employees want local servers but don’t have statics. Would setting this on one side stop the local connection on both?
I’m not trying to be difficult, but my job is all about a solution that lasts years rather than a quick fix. Right now, with the firewall being used, it’s not a huge deal, but someone has to know where to look since it’s not in synching anymore, which is not intuitive. If the mesh gets bigger, it will get more complicated. The fewer humans involved, the better.
Yes.
Only one side of a Syncthing link needs to be open to receiving initial connections – i.e. you could firewall port 22000 (or stop port forwarding) on your home office server and it’ll still be able to connect to the colo server that has a public IP.
The colo server doesn’t even have to have a static IP if global discovery is enabled in Syncthing on your office server.
No, you’re not being difficult. You’ve got a very valid use case.
My setup isn’t exactly the same as yours, but it also involves colo + WireGuard + Syncthing, so I’ve had to work thru the same question(s).
Although I can see a use for an ignoreNetworks in Syncthing, long-term I think it’s better handled in a firewall. Having to update the ignore list across multiple Syncthing nodes – even with Ansible or other change management tools – would get messy as the Syncthing mesh expands.