Looks like someone pointed their client base at our STUN server, average usage went up from about 10 Mbps on average to about 100 Mbps on average over the last couple of weeks.
If you’re reading this, can you please not? 
5 Likes
Do we know what region the clients are connecting from? This may help to trace the origin.
1 Like
Here’s the packet count by first three octets of the source addresses of clients for about 30 seconds of traffic, sorted:
https://cdn.kastelo.net/tfi/30-sek-ips.txt
There’s a lot of Chinese networks at the bottom.
Would it make sense to drop or tarpit STUN connections that don’t coincide with an IP visible in the Global Discovery servers list? I’m no expert on STUN or Syncthing’s public infrastructure, so if this is a bad idea for some reason, it won’t hurt my feelings.
1 Like
That was one of my thoughts as well. Apart from it being a big and churning list of addresses, STUN will predate the announcement to discovery, since that address is supposed to be in the discovery, so there’s a chicken and egg problem.
That said, I think we mainly use STUN for port discovery? The source address seen by the discovery server should be the same as for the STUN packets presumably, even before STUN is completed… Maybe this would in fact be a workable mechanism, even though it’s a bit heavy handed…
There’s an authentication field we could use in STUN, and we could set a client ID and filter on that, but that’s only effective for new clients…
(There are quite a few packets with a client ID that’s not Syncthing though, StunClient which is the default for at least the Go STUN library, but most seem to be using blank client ID like Syncthing currently does…)
2 Likes
Adding a drop rule for Chinese sources skips about 65 % of the traffic.
root@stun:~# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
4840K 288M DROP all -- any any anywhere anywhere match-set china src
2646K 156M ACCEPT all -- any any anywhere anywhere
1 Like
Doing a github code search shows quite a few projects and libraries using the syncthing servers. Because there are libraries using it, there may be projects using those servers without even realizing.
1 Like
Yeah. I don’t mind the ones having it as one entry in a big list of STUN servers, we kind of do that as well, but the ones using just stun.syncthing.net is a bit 
2 Likes
Dropping incoming from China has brought our outgoing traffic down to under 20 Mbps which is a significant improvement. Unfortunately this leaves Chinese Syncthing users without access to our STUN server, but there are others they can use… Clearly I realise the hypocrisy of this, nonetheless we do need to keep the infrastructure running in a reasonable way.
1 Like
Should we add some china based STUN servers to our list? I fear that most of our default servers are blocked by the Great Firewall.
e.g:
- stun.qq.com:3478 (Tencent)
- stun.miwifi.com:3478 (Xiaomi)
2 Likes
Sure, why not.
1 Like
I tested a few services for Add China-based STUN servers · Issue #9842 · syncthing/syncthing · GitHub and came across this one:
stun.cdnbye.com:3478
It came up pretty often when looking for STUN servers in China. Now comes the fun part:
https://dns.google/query?name=stun.cdnbye.com
They’re pointing to stun.syncthing.net using a CNAME 
8 Likes
fucks sake
4 Likes
A “could you fucking not?” mail might or might not help.
2 Likes
Wonder if they’re actually using Syncthing under the hood? 
1 Like
I know what you’re thinking and you really should.
1 Like
According to them, “[SwarmCloud is] Powered by WebRTC”.
Sorry for the n00b question, but are you sure these connections are coming from Syncthing, and that they’re just not some misconfigured program/system doing regular HTTP(S) requests?
Neither.
STUN is a protocol that allows something behind a NAT device (typically a firewall) to discover its public IP address.
The nice people (not me, I don’t know who they are) who host the Syncthing infrastructure host some STUN server architecture, but without using any authentication at this time.
In other words, this big increase in traffic and load is coming from freeloaders who are using Synchthing’s infrastructure to do something else.
1 Like