VPN without using Relay Server

I was reading the documentation and this forum but could not figure out how to run two Syncthing devices on different locations each behind a Mullvad VPN and have them connect with each other without using a public Relay Server?

You can configure static addresses for the devices assigned by the VPN.

What part of the configuration files do I change? Did I oversee the instructions in the Documentation?


You can edit it through the Web GUI as well. Under Edit Device in the Advanced tab.

So I have one machine with a fixed IP and port:* and a dynamic machine how would I fill out the field on both sides?

(example IP changed for privacy)

Let’s call the devices FIX and DYN.

On FIX, you edit the remote device DYN and enter dynamic in the address field (which is the default).

On DYN, you edit the remote device FIX and enter tcp4://,dynamic in the address field. You can leave out the ,dynamic suffix if you never want to try any other addresses for reaching FIX. Including it will make Syncthing search for possible additional addresses through the enabled discovery methods.

server selected unsupported protocol version 303 (17:54:08)

After a while it did connect again but through a relay. I assume if one of the two machines is dynamic they will use a relay server in any case.

The error indicates that one side is running an older version which does not yet support TLS 1.3. Support for older TLS versions was disabled by default since v1.17.0 IIRC. You should upgrade if possible, or re-enable the less secure protocol version here: Syncthing Configuration — Syncthing v1 documentation

You can disable relaying if not desired: Syncthing Configuration — Syncthing v1 documentation

1 Like

v1.18.6, Linux (64-bit Intel/AMD) is the last version that comes with the Fedora 34 repository. I update and Fedora does not update to the last version.


But it seems my version was released two weeks ago: https://bodhi.fedoraproject.org/updates/?packages=syncthing and not that old.

1.18.6 is very recent. The TLS issue mentioned above is known to occur when trying to connect using very old versions, e.g. 1.0 and such, so if both of your systems are on v1.18.6, then the culprit is probably something else.

Are you sure it’s the correct port and that nothing else is intercepting the connection in between?

I can ping the remote IP and get a reply. The port is open as well.

But it gives the error: server selected unsupported protocol version 303

This is what I see in the log file:

2022-02-24 20:49:04 Enabled debug data for "discover"
2022-02-24 20:49:08 Enabled debug data for "connections"
2022-02-24 20:49:12 Enabled debug data for "dialer"
2022-02-24 20:49:22 Connection loop
2022-02-24 20:49:22 Resolved device XXXXXXXXXX addresses: [tcp4://XXXXX.44:5XXXXX]
2022-02-24 20:49:22 dialing XXXXXXXXXX addresses: [tcp4://XXXXX.44:5XXXXX] prio 10
2022-02-24 20:49:22 Dialing reuse result tcp4 IP=port: <nil> dial tcp4 [::]:22xxx->IP+port: address ::: non-IPv4 address
2022-02-24 20:49:22 Dialing non-reuse result tcp4 IP+port: &{{0xc0xxxxx0}} <nil>
2022-02-24 20:49:22 Dial (BEP/tcp): setting traffic class: setsockopt: protocol not available
2022-02-24 20:49:23 dialing xxxxxxxx ip+port error: tls: server selected unsupported protocol version 303
2022-02-24 20:49:23 failed to connect to xxxxxxxxxxxxxxxxx 10
2022-02-24 20:49:23 Next connection loop in 1m0s
2022-02-24 20:49:30 discover: Received local announcement from IP+different_port for xxxxxxxxxxxxxxx
2022-02-24 20:50:00 discover: Received local announcement from IP+differen_port for xxxxxxxxxxxxxxx

When I turn accept older versions of TLS I get a different error:

unexpected device id, expected XXXX, got YYYYY

I’d say there is definitely something else listening on that port you are connecting to. You could investigate using the openssl s_client tool, maybe that brings some insights about the presented certificate and running service.

1 Like

Or as someone suggested, the other side is an old version.

I can see that TLS 1.3 is not running but TLS 1.2 is.

The port given by Mullvad VPN is also used by Windows Remote Desktop but I understand you can reuse the same port by different connections. Or you think when connecting to this part make Windows Remote Desktop respond with the TLS1.2 and does not allow for Syncthing to use the port?

It’s still not clear what version of Syncthing is running on the other side.

If its a recent version, then I’d say that Syncthing is not connecting to Syncthing, but to something else.

AFAIK two applications cannot use the same port on the same network interface. I guess you will need to investigate with that VPN software how to configure arbitrary ports to be forwarded through the tunnel.

Have you checked what the log says on the remote end? Syncthing prints both its version and the listening addresses during startup. And in the Web GUI, you can check the listener status as well. Assuming you can connect to the machine at all with Remote Desktop.

I found the solution.

The use of openssl client command was useful here to see when it did not work.

openssl s_client -connect

See for more detailed instructions here: How To Use OpenSSL s_client To Check and Verify SSL/TLS Of HTTPS Webserver? – POFTUT

For other users I will include the instructions here:

  1. Follow the instructions on port forwarding with Mullvad VPN here: Port forwarding with Mullvad VPN - Guides | Mullvad VPN

I do not believe that all VPN providers offer this kind of port forwarding but this one does.

My first mistake here was that I was using the same port for Windows Remote Desktop and then also for Syncthing. So when I used the here suggested openssl s_client I could see Windows Remote Desktop was responding and not Syncthing.

  1. After I completed step 1 I had to create a new Inbound Firewall Rule in Windows for the specific by Mullvad assigned port.

  2. Then I rebooted the windows machine just to be sure where after I tested the port on the Mullvad website on the machine ‘A’ with the opened port and it worked.

  3. Then in Syncthing config screen I turned off enable relaying checkbox and entered the listen to address: tcp4:// and closing the screen in the console log at the bottom I could see that the TCP listener was starting and that the handshake was successful etc.

  4. Then on machine ‘B’ I made a test using openssl s_client -connect towards machine ‘A’ and it successfully CONNECTED.

  5. Then on machine ‘B’ on the Syncthing home screen I clicked edit of the specific ‘remote machine’ and on the Advanced tab entered the address and port of machine ‘A’, for example: tcp4://*

Now at both machine ‘A’ and machine ‘B’ I use VPN and Syncthing between the machines without the need of a 3rd party relay server.


I love Syncthing and a made a donation a while back.

Thank you community for guiding me in the right direction.

*for privacy reasons the IPs and port numbers are changed

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.