Local bound address does not effect all connections (important for hosts with multiple outbound paths)

(This could conceivably be seen as a feature, but considering you provide a setting to change the local bind address for listen, it is possible that this is just incomplete support.)


The issue is as follows. On hosts where you have multiple outgoing routes, setting the bind address in the settings is not sufficient to guarantee the route (first hop) that syncthing will use. When a local bind address is not given to a socket at creation time, the local OS will use standard destination based routing. This means the ffirst (highest priority) network device that is capable of routing the packet will be chosen, and the interface’s IP is chosen as the “local address”.

In low level posix calls, to avoid this you call bind() on the socket to choose the local address, and then you call connect(). In go terms, you call DialTCP() with the optional local port filled out (or create a dialer with LocalAddr set.)


  1. Setup a network where you have two routes to a server possible (each has a different interface IP.)
  2. Set the Sync Protocol Listen Address to the second interface’s IP.
  3. Restart Syncthing
  4. Use netstat or some similar tool, you will see local addresses on the connections that are for the first interface’s IP.


I had managed to make a local patch for 11.x, a friend had offered to submit it etc to you folks, but by that time so much effort had switched to 12.x that there was little interest. I am not supper proficient in go, and so much changed, I’ve been unable to make a sufficient patch in 12.x. I’d be happy to provide the details around 11.x if they would be helpful.

1 Like

This is specifically only the listening socket. It doesn’t affect outgoing connections one way or the other, as you’ve discovered. I’m not at all convinced we should conflate the two (what does setting the listening socket to do to outgoing connections?), but I could see the point of adding an option for the local bind address of outgoing connections.

Totally understood. Would there be any chance of this making it as a feature request then?

1 Like

Sure. From my point of view it goes straight into the “unplanned” bin as this is the first I’ve heard of it, but that does mean that contributions are likely to be merged :slight_smile:

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