Failure to reach discovery-announce-v4 from university network

Support
1

Hi everyone!

I encountered this strange behavior where reaching the discovery server fails from clients inside my university network. The exact error shown in the GUI under Discovery is:

This is really strange since I am not aware of any outgoing limitations of my network. I can also reach syncthing.net just fine. If I enter the link in wget, it looks up the ip just fine and says connected, however the request never returns. Outside of the university network, a wget request instantly returns.

Does anyone have an idea what might be going on? I’ve had issues with other websites that complain about too many requests from my network, so could it be possible that the discovery servers are actively blocking the request as a measure against DDOS or something? I can hardly believe that my university’s firewall might be involved in this.

Also, this is only about discovery. If I enter my other device’s address as fixed, syncing works just fine. Would still be nice to find out what’s going on, though.

Thanks!

2

Sounds similar to a TLS-SNI based firewall blocking the connection. It isn’t unheard of institutions blocking syncthing, as it’s listed in several P2P application lists. And since P2P is often labelled as “harmful”, applications in those lists tend to get blocked a lot by commercial firewalls.

You can try to test for the presence of a TLS-SNI firewall by playing around with the server name a bit. If your machine has openssl, you could try the following:

openssl s_client -connect discovery-announce-v4.syncthing.net:443

→ should not complete the TLS handshake and error out (reproduces the error your described)

openssl s_client -connect check-tls.akamaized.net:443

→ should succesfully connect in any case

openssl s_client -connect check-tls.akamaized.net:443 -servername discovery-announce-v4.syncthing.net

→ should not complete the TLS handshake if a TLS-SNI based firewall is present, or complete the handshake normally if no such firewall is present.

(If it’s not a TLS-SNI based firewall it may still be a firewall, i.e. IP-based but still allowing TCP connections through for whatever reason)

3 Likes
3

It looks like you hit the nail on the head! Your commands produce exactly the anticipated results.

Specifically, providing any subdomain before syncthing.net as servername leads to the “blocking” behavior. Annoyingly, no error is ever thrown, the connection is just stalled indefinitely.

Thanks a lot for shedding light on this issue! I did not know such a thing as a TLS-SNI firewall existed. Seems like a dubious form of protection to me, but I guess I have to accept it (or use a proxy, which would not be worth the hassle).

Edit: It gets even weirder. While the servername relays.syncthing.net is blocked with the openssl command, I can access it from the browser.

1 Like
4

I’ve run into this before, triggering me to install my own Syncthing Discovery server. Works fine on a $10/yr VPS from RackNerd. (I use Caddy as a reverse proxy to handle the TLS Certificate as suggested in the notes on the docs page above.)

Note that you have to include your discovery server as an additional entry in the Settings → Connections → Global Discovery Servers, for every device you want to link together e.g.

default, https://stdiscovery.example.net

You don’t have to use the default servers if all your devices are connected to your personal Discovery Server, but I leave it there.

4 Likes