I am running 1.20.2. on Linux, and I have Global Discovery disabled on all clients. Yet, the clients are making connections to discovery-3.syncthing.net and others following the naming pattern.
Why, and how can I stop these connections? I don’t see any need for them, and would rather not leak data.
Thanks, -m
Possibly STUN, as they are also STUN servers. Disable NAT traversal. Otherwise, be more specific about what kind of traffic it is.
Seems like you hit the nail on the head. I don’t know why I didn’t notice this! Great example of why reverse DNS is quite dangerous in security analysis…
Thanks, and sorry for the noise!
Actually, I need to come back to this, because I found out two things:
Syncthing should not be using discovery-3.syncthing.net for STUN, while config-option-options.stunservers is set to the default set of STUN servers
There is also non-STUN stuff going on:
14 81.160241177 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TCP 94 59910 → 443 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3084796323 TSecr=0 WS=128
15 81.367650763 2400:6180:100:d0::741:a001 → 2001:470:5023:0:f87e:87db:44e8:42a6 TCP 94 443 → 59910 [SYN, ACK] Seq=0 Ack=1 Win=28560 Len=0 MSS=1440 SACK_PERM=1 TSval=2007967127 TSecr=3084796323 WS=128
16 81.367972032 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TCP 86 59910 → 443 [ACK] Seq=1 Ack=1 Win=64896 Len=0 TSval=3084796531 TSecr=2007967127
17 81.368610937 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TLSv1 357 Client Hello
18 81.574431221 2400:6180:100:d0::741:a001 → 2001:470:5023:0:f87e:87db:44e8:42a6 TCP 86 443 → 59910 [ACK] Seq=1 Ack=272 Win=25472 Len=0 TSval=2007967190 TSecr=3084796531
19 81.576607536 2400:6180:100:d0::741:a001 → 2001:470:5023:0:f87e:87db:44e8:42a6 TLSv1.2 846 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
20 81.577151668 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TCP 86 59910 → 443 [ACK] Seq=272 Ack=761 Win=64256 Len=0 TSval=3084796740 TSecr=2007967191
21 81.584759307 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TLSv1.2 224 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
22 81.795196639 2400:6180:100:d0::741:a001 → 2001:470:5023:0:f87e:87db:44e8:42a6 TLSv1.2 137 Change Cipher Spec, Encrypted Handshake Message
23 81.795699495 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TCP 86 59910 → 443 [ACK] Seq=410 Ack=812 Win=64256 Len=0 TSval=3084796958 TSecr=2007967245
24 81.795882478 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TLSv1.2 293 Application Data
25 82.007287527 2400:6180:100:d0::741:a001 → 2001:470:5023:0:f87e:87db:44e8:42a6 TLSv1.2 356 Application Data
26 82.007851074 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TCP 86 59910 → 443 [ACK] Seq=617 Ack=1082 Win=64128 Len=0 TSval=3084797170 TSecr=2007967298
27 82.007852471 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TLSv1.2 117 Encrypted Alert
28 82.007853798 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TCP 86 59910 → 443 [FIN, ACK] Seq=648 Ack=1082 Win=64128 Len=0 TSval=3084797171 TSecr=2007967298
29 82.214126232 2400:6180:100:d0::741:a001 → 2001:470:5023:0:f87e:87db:44e8:42a6 TCP 86 443 → 59910 [FIN, ACK] Seq=1082 Ack=649 Win=27648 Len=0 TSval=2007967350 TSecr=3084797171
30 82.214385133 2001:470:5023:0:f87e:87db:44e8:42a6 → 2400:6180:100:d0::741:a001 TCP 86 59910 → 443 [ACK] Seq=649 Ack=1083 Win=64128 Len=0 TSval=3084797377 TSecr=2007967350
So, what’s going on? Why is my Syncthing talking to discovery-3.syncthing.net?
I don’t know, mine doesn’t when I’ve disabled global discovery.
(It is also part of the default set of stun servers, that doc entry is slightly out of date, but the traffic you show isn’t STUN so that doesn’t matter here.)
This really doesn’t make me happy or instill confidence in the software.
Who runs these servers? If there is no obvious client-side place to look for why these servers may be contacted (I’ve changed the STUN set to my own STUN server now too), then maybe we could peak into the web server logs at a given point in time to find out what is being tried?
We do. They do not keep access logs, for a multitude of reasons. I suspect you simply haven’t disabled discovery lookups as much as you think you have.
What more is required to disable discovery lookups?
I sure hope that “local discovery” doesn’t mean syncthing servers are contacted, right?
You have NAT traversal turned on. Nat traversal usually means stun NAT discovery will be performed, except maybe if you have QUIC disabled.
As for other traffic to discovery, I have no idea.
Yeah, and I want/need STUN, but we’ve established that this isn’t STUN traffic. Apart, I am using my own STUN server.
I’m quite confident that Syncthing does not make global discovery requests when configured like that. I don’t know the source of the traffic you’re seeing.
I just tested it using the same config as posted above and I can concur: I do not see any (TLS) traffic to discovery when global discovery is set to different servers, or turned off. The STUN server contacted also appears to resolve differently to discovery.s.n, and yes its traffic patterns are quite different.
Unsure why my post suddenly disappeared, so here I go again: thanks to your patience and knowledge, I ended up correlating tcpdump with ss output, and found that there was another user running Syncthing, with global discovery turned on. Doh! 
Hugs all around!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
