Unwanted outgoing connect request

Hello,

My son and my are using two independent Syncthing “clusters”. Now I see an incoming connection request by one instance of the other cluster. I’m not sure how this request was actually initiated, but it is coming up again and again.

I would rather like to terminate the request on the initiating instance than to ignore it on the receiving instance, because there might be a time where such a request is finally intended, but I haven’t found a way to do this.

Thanks for your help on this.

Go on that device, remove the device you don’t want it to connect to?

I am not really sure what the question is.

I’m sorry, I should have made this clear: The device that gets the request does not show up on the requesting device.

This is most likely because both devices are behind the same NAT.

If you don’t want for this to happen you’d have to change the port each syncthng device is listening on, so that they would not all assume the default 22000 port mapping.

I confirm they’re both behind the same NAT. However, I still don’t understand why this connect request is showing up on one device while there are a couple of others behind the same NAT as well that do not show any connect attempts. Actually, I don’t even understand why this happens: Why would a device request to connect to another device all by itself? In this case we’re just talking about a private LAN, but in a professional environment I’d consider this a no go…

I just checked both devices again and one of them is listening on the default port (I guess that’s 22000) while the other (requesting one) is listening on port 22001.

Because only one device can get a UPnP mapping for port 22000.

Device A listening on local1:22000 gets UPnP mapping, announces it’s address, discovery server registers external:22000

Device B listening on local2:22000 does not get UPnP mapping, announces it’s address, discovery server registers external:22000 (because that’s the address it’s listening on and announced itself from)

Device C looks up addresses for device B, connects to external:22000, ends up connecting to device A, because device A has the UPnP mapping/port forwarding setup for port 22000.

As far as I can see, UPNP is not activated on my DSL router.

Furthermore, the device sending the connect request is listening on port 22001 while the device receiving the request is listening on default (so 22000 I guess).

It doesn’t matter what port the connecting device is listening on. One of the devices that it’s trying to connect to is listening on 22000.

Even if UPnP is not enabled, we have hole punching which effectively serves the same purpose. Or it could be a simple static port mapping on the router.

No static mapping, either…

So you’re telling me that none of my devices should listen on 22000?

What I still don’t get is why there is such connect request anyway when it was not actively initiated. I have never seen this behavior before.

I’ve just explained why it happens, I am not sure what else you want me to tell you.

If you want to have two completely separate/isolated clusters behind the same NAT, it’s best that you run each device on a different port, or atleast each of the clusters on a different port.

That’s actually the case. One cluster is running on port 22000, the other one on port 22001, but still this unwanted request is coming up.

I don’t have access to your syncthing instances to verify that, but I highly doubt that is the case.

You can see the addresses syncthing sees for each device it’s not connected to. You can probably probe the discovery server manually for each device id to see what has been advertised for other connected devices to figure out where it goes wrong.

Can you describe this in a little more detail, please?

Am I supposed to check this on the device sending the connect request, on the one receiving it or on both?

Where do I see the IPs of remote devices I’m not connected to?

How do I manually probe the discovery server?

I’d like to point out once again that the device receiving the connect request does NOT show up in the list of devices on the requesting device.

It it’s not connected, it usually lists the addresses it has discovered in the UI.

You can query the discovery servers manually via:

https://discovery.syncthing.net/v2/?device=<device id>

It does not have to show up in the device list. It’s equivalent of knocking on the wrong door. It tries to connect, realises that the device it’s connected to is not the one it expected and disconencts. The logs will further confirm this.

Yet again I received that connect request. I checked the logs on both devices, but I’m not able to find the opposite device ID on either of them.

Apparently the original request was created back on October 25., but it keeps nagging on and on.

I have accepted the request now, did not share any Folders and removed the device again. Hope it does not come back (fingers crossed)…

That’s a known limitation: If an unknown device was at one point trying to connect, it is stored as a pending device entry. That entry is only removed if you either accept or ignore it, regardless of whether there are further connection attempts or not.

1 Like

Thanks for pointing that out! So I think this one’s finally settled.

Note that you can ignore a device and later un-ignore it, ignored devices are shown in the settings and can be removed there (same for folders).