Relays / discovery blocked by ISP firewall (fortinet)

Many public WiFi (and some ISPs) use FortiNet as their firewall. They classified SyncThing as a P2P application (which is fair), and blocked all access to it (which isn’t fiar IMO). They blocked all relays, discovery, and access to syncthing.net (documentation, forums, etc).

They do not block ports! So if you have a static IP on one of your nodes, you can still use syncthing. I edited the device properties and set the address to the static IP (instead of “dynamic”), and syncthing is usable.

I’m not sure if SyncThing devs can do anything to combat this. One possibility is to have clients try previously known IPs of the remote devices in the event that discovery servers aren’t reachable.

HTH

1 Like

I haven’t yet seen an ISP blocking Syncthing infrastructure – if mine did, I would certainly complain and consider changing providers. As for public wifi, blocking P2P makes a lot of sense in the general case. I would expect that most wouldn’t be interested in how Syncthing isn’t like other P2P apps.

This sounds like a use case for a VPN service. Proton’s free tier could be a good choice. NordVPN’s Meshnet is free (you don’t need to be a NordVPN subscriber) and was super easy for me to set up – my Syncthing Devices work very well this way.

With that said, follow the rules of the network you’re using, especially if it belongs to your employer.

EDITED to correct a grammar error that was bothering me.

2 Likes

As @chaos mentioned:

Meshnet from Nord is an option that you can use to give yourself a private peer-to-peer tcpip Network. I have used it and it works well. There is another company that has a free product that works equally well and you can compare the two and see which one works better for you.

Its called tailscale. It basically functions the same way as meshnet giving you a free peer-to-peer private tcpip Network for your servers.

3 Likes

Yes, they’re not interested in the nuances about Syncthing. They outsourced the firewall to FortiNet, and don’t even know the workings of it as far as I can tell.

Unfortunately I was SOL. I have openvpn setup listening on Port 443, and FortiNet does deep packet inspection and blocks it :frowning:

Thanks, I’ll try this out. Also maybe I can change the ports of my OpenVPN server and see if there is a standard VPN port that FortiNet leaves open.

I’m on holidays in Austria and just hit this problem with the hotels WiFi. I even have to browse this forum via a socks proxy..

I wanted to try define a static ip:port here but it won’t accept “udp://” as scheme and it seems my syncthing “server” doesn’t listen to tcp on ipv4?

# netstat -tulpn | grep sync
tcp        0      0 127.0.0.1:8384          0.0.0.0:*               LISTEN      2568931/syncthing   
tcp6       0      0 :::22000                :::*                    LISTEN      2568931/syncthing   
udp        0      0 0.0.0.0:45269           0.0.0.0:*                           2568931/syncthing   
udp        0      0 0.0.0.0:21027           0.0.0.0:*                           2568931/syncthing   
udp6       0      0 :::22000                :::*                                2568931/syncthing   
udp6       0      0 :::37158                :::*                                2568931/syncthing   
udp6       0      0 :::21027                :::*                                2568931/syncthing

Tcp6 sockets are dual stack, i.e., ipv4 and ipv6. The scheme for quic is quic://.

1 Like

Hmmm,

Not sure if the hotel blocks them or not but do you have access to the VPN? Either tail scale or any VPN that can make your IP address appear as though it’s in your home country.?

Vpns like tailscale and meshnet create an encrypted tunnel for your data so the port numbers don’t even come into play so long as the VPN works.

I don’t know anything about the country you’re in in terms of what they allow and don’t allow and also the hotel.

If you’re behind a restrictive network (like a corporate firewall):

Tailscale may fallback to TCP (port 443) if UDP is blocked.

Tailscale cannot run via proxy server it requires direct internet access. If tcp Port 443 is open which it should be that’s all it needs.

1 Like

thank you for your reply!

I tried both quic://my-server-ipv4:22000 and tcp://my-server-ipv4:22000 and both give me timeouts. Connecting to the same ip to 80, 443 & 22 works fine via this hotels wifi (port 22 ssh + socks5 is how I access this forum)

But I also tried to connect to the syncthing port 22000 from a different host at my home which also doesn’t seem to work via ipv4, only ipv6.. (it’s not blocked, it seems like it’s filtered - waits for timeout..)

UPDATE: no sorry that seems to work. So I must have some port forwarding issues.

Cool,

Btw, what is your client OS that you’re using? There are a couple of different ways to use a proxy server and SSH together I’m guessing you’ve already figured that out but if not you can use open SSH even on Windows and putty .

Do you have SSH server running on your home machine on Port 22? Actually never mind because your home machine is probably not directly connected to the internet hence the need for a VPN that can Traverse your router at home.

If you have or the next time you have access to your router you can set up a port forward from your external IP address to your server and then tunnel through SSH.

If you can do an SSH tunnel with a proxy you should be able to Tunnel into your server and then connect the software and in the SSH command you can specify the port number that you want to talk to through the tunnel.

1 Like

Hey there @Wank, thank you for your reply!

Most of my Syncthing peers are Linux boxes. The one I most urgently want to upload new stuff during my holiday here is an Android phone - and the easiest workaround I found for that now was to setup an IPSec VPN tunnel from it to my home network, which made Synctihng on it and on the Linux box at home find each other again automagically again as I am used to by now with Syncthing.

For the Linux based laptop I have with me the easiest quick+dirty workaround I came up with was to add -L 22001:127.0.0.1:22000 to my ssh connection I already have connected whenever the laptop is not at home and turned on - and manually point the target Syncthing peer to tcp://127.0.0.1:22001

Yes I can configure my router remotely, but somehow the ipv4 syncthing forwards don’t seem to work the way they should. It’s a FritzBox I got from my internet provider and sometimes it doesn’t do what I tell it to..

Hey @calmh ! thank you for that. Can you tell me what the quic protocol gives me that “pure” tcp doesn’t?

Hi @bitey29 , Welcome.

Hi,

I found this website with a matching app on Android. With it you can create for free an SSH tunnel on your Android phone just like you’re using on your computer and an even supports proxies so this might give you some consistency between how you’re connecting on your Linux machine and how you connect on your Android phone perhaps it’ll be easier. Here is the website and the software for Android.

I included the open Tunnel website but I don’t think that you actually need that although I’m not certain because you have the ability to create your own tunnel you don’t need to use a public tunnel. The app on the Google Play app store supports proxy servers and can create an SSH tunnel for your phone and perhaps that will work easier than what you’re doing now on Android. Give it a look and let me know.

quic might be faster for Syncthing in your environment. See The Road to QUIC for an introduction.

1 Like

It gives you UDP, which has different and sometimes better hole-punching capabilities. Nothing else.

1 Like