Syncthing trying to connect via wrong network route

Support
1

Hello,

I’m trying to add a remote Device running to my Win10 Notebook.

  • Remote Device:
    • Syncthing v1.5.0
    • Debian Linux (64 bit)
    • Reachable via VPN, IP: 10.192.232.111
    • listen address set to “default”, which includes “tcp://0.0.0.0:22000”
  • Notebook:
    • Syncthing v1.8.0
    • Windows 10 (64 bit)
    • I want the notebook to be as “quiet” as possible, therefore I disabled all the fancy functionality, i.e. NAT traversal, Global Discovery, Local Discovery, Relaying.

The Notebook is configured to try and connect to “tcp://10.192.232.111:22000” which is working fine from another Linux machine. The remote device is only reachable via a VPN connection and the routes are all configured correctly. I didn’t have to manually change any routes, but checked them using PowerShell’s Find-NetRoute. 10.192.232.111:22000 is reachable from the notebook, which I verified using telnet.

The Problem is: Syncthing is trying to connect to the remote machine using the wrong route/interface and therefore fails. The error message is:

[6BEVK] 2020/08/13 14:08:03.784082 service.go:889: DEBUG: dialing CNWM7SR tcp://10.192.232.111:22000 error: dial tcp 192.168.0.110:22000->10.192.232.111:22000: i/o timeout
[6BEVK] 2020/08/13 14:08:03.784082 service.go:920: DEBUG: failed to connect to CNWM7SR 10

It tries to connect from 192.168.0.110 which is its IP on my local network instead of going via the VPN-Interface.

Why is syncthing not using the Routes configured in Windows, or am I misunderstanding something here?

2

Which interface is used to connect to certain addresses is controlled by the operating system and not syncthing. On linux I think you can see that using ip route not sure what the equivalent is for windows.

You probably need to setup routing rules.

3

The Windows equivalent is PowerShell’s Find-NetRoute, which I used to verify my routes are correct.

But Syncthing seems to explicitly choose a route different from the one configured in Windows.

Here are two relevant outputs of Find-NetRoute:

PS > Find-NetRoute -RemoteIPAddress 10.192.232.111


IPAddress         : 10.192.229.8
InterfaceIndex    : 10
InterfaceAlias    : Ethernet 2
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Dhcp
SuffixOrigin      : Dhcp
AddressState      : Preferred
ValidLifetime     : 364.19:20:07
PreferredLifetime : 364.19:20:07
SkipAsSource      : False
PolicyStore       : ActiveStore


Caption            :
Description        :
ElementName        :
AdminDistance      :
DestinationAddress :
IsStatic           :
RouteMetric        : 256
TypeOfRoute        : 3
AddressFamily      : IPv4
CompartmentId      : 1
DestinationPrefix  : 10.192.232.0/24
InterfaceAlias     : Ethernet 2
InterfaceIndex     : 10
InterfaceMetric    : 1
NextHop            : 10.192.229.1
PreferredLifetime  : 10675199.02:48:05.4775807
Protocol           : NetMgmt
Publish            : No
State              : Alive
Store              : ActiveStore
ValidLifetime      : 10675199.02:48:05.4775807
PSComputerName     :
ifIndex            : 10



PS > Find-NetRoute -RemoteIPAddress 192.168.0.1


IPAddress         : 192.168.0.110
InterfaceIndex    : 33
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Dhcp
SuffixOrigin      : Dhcp
AddressState      : Preferred
ValidLifetime     : 19:19:04
PreferredLifetime : 19:19:04
SkipAsSource      : False
PolicyStore       : ActiveStore


Caption            :
Description        :
ElementName        :
AdminDistance      :
DestinationAddress :
IsStatic           :
RouteMetric        : 256
TypeOfRoute        : 3
AddressFamily      : IPv4
CompartmentId      : 1
DestinationPrefix  : 192.168.0.0/24
InterfaceAlias     : Ethernet
InterfaceIndex     : 33
InterfaceMetric    : 25
NextHop            : 0.0.0.0
PreferredLifetime  : 10675199.02:48:05.4775807
Protocol           : Local
Publish            : No
State              : Alive
Store              : ActiveStore
ValidLifetime      : 10675199.02:48:05.4775807
PSComputerName     :
ifIndex            : 33
4

Which version are you on? If it’s 1.8.0, try 1.7.1 and see if it makes a difference.

There has been a change that landed in 1.8.0 that tries to dial out from the same address as it’s listening on to improve probability of punching though nats, which I guess is a form of control of which adapter is used for dialing out.

5

Bingo! With 1.7.1 my setup works.

So would you consider this a bug in 1.8.0? If so, can I help debugging by providing any logs or other info?

1 Like
6

I know where the bug is. Please open an issue on github linking to this thread.

1 Like
7

Done:

Thanks for your quick help and for your work on Syncthing!

1 Like
8

Hi there, is there a way to apply a fix on this ? All my QNAP nodes are affected and no longer seeing each other.

Regards,

-Eric

9

You can revert to a previous version (1.7.1), or try building it yourself with the fix applied. There is no way to disable this.

10

Thanks for the quick response.

I will revert to 1.71.

Thanks for your help and work on Syncthing!

11

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