The opposite of alwaysLocalNet, maybe "alwaysWanNet"

Feature
1

I have some nodes with a public ipv4 and ipv6 address, but also a zerotier interface configured.

Since the zerotier interface has a private ip range, syncthing thinks it’s local and uses it preferentially. I would like the opposite, since this interface is usually slower than normal WAN. However, if a wan connection is not possible and zerotier is available, zerotier is usually better than relaying, so I would like to keep it as an option.

So, in summary, I would like to mark the zerotier interface as a WAN interface to decrease it’s priority.

2

Actually, now that I think about it… this won’t completely solve the problem, what I really need is to manually set priority for each interface. Or if anyone has a better idea…

3

I don’t know much about Zerotier. But we’re treating point-to-point interfaces as WAN since a few releases. Maybe you need to use a TUN interface?

1 Like
4

zerotier is a TAP interface, so not point-to-point. I have 2 services in 2 different machines that I need it for, so it was easier to just use zerotier instead of making 2 tunnels for each node.

However, like I said in my own reply, this wouldn’t fix it completely. Even if I had 2 interfaces, WAN and Tailscale, for example, there is no guarantee that syncthing would try to use wan first and only after tailscale, correct? From my understanding there is no “interface priority” except “Local first, WAN second”, and in my example both would be trerated as wan.

5

Correct. And in any case rather tricky to implement, as connections are equally likely to come from the outside and routing is typically per destination rather than tied to the local address :person_shrugging:

6

My suggestion would be:

  • Each client has a configurable table of interface priority. The default priority could be the metric or, if available, the network speed for that interface.
  • The table would only be used for outgoing connections. If an incoming connection is received, it’s always accepted.
  • Periodically try to connect with a higher priority interface, even if a connection to the node is already established. If successful, close the least priority and use the higher.

What do you think?

7

You’re welcome to try to implement something like that, I see no principal blockers against including it. However it can be nontrivial to determine which interface a connection to a given address would go out over. (The easy cases are easy, but will a connection to google.com go over my fixed ethernet, my WiFi, or my corp VPN (which goes over which physical interface)? There are a lot of factors that decide that, from routing tables to firewall policies.)

8

You’re right, hadn’t thought about that. Still, I’ll check the code and see if I can do this.

9

This sounds like a use case for Policy Based Routing, which is supported on a number of routers, at least some Linux distros, and even Windows (although it looks super ugly to do on Windows).