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.
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.
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.
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.
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.
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.