I really tried to find this, but could not.
What “Connection Types” do exist in Syncthing?
Right now, my connection is “Relay WAN” for my remote site. I suppose, this is not a direct connection but over some relay host.
For my iPad with “MoebiusSync”, it shows “TCP LAN”.
What other Connection Types are possible and how would a direct connection to my remote side show up, as “TCP WAN”?
I vaguely recall that there were docs for this, but I can’t find them. There are:
Syncthing will always attempt to establish the best possible connection. This includes prioritizing local/direct connections over relay connections. However, firewalls and network conditions may hinder this.
A direct connection over internet shows up as either TCP WAN or QUIC WAN. Syncthing will usually prefer TCP if possible, but QUIC is fine as well.
If syncthing is unable to establish a direct connection, it means that neither side accepts an incoming connection (from the internet). This is usually due to both sides having a restricting firewall (on device or routers) or other network restrictions.
Great many thanks!
Yes, I also tried to find some documentation, but couldn’t find anything.
For the background:
I am trying to first disable any such hole-punching and NAT traversal methods used by Syncthing, TailScale and others!
When currently only Relay TCP is possible, I am already a bit closed to that goal.
I hope to finally be able to completely block those techniques.
And of course, after that, find a way to re-enable it for my own systems.
But I don’t like that any installed App could use such methods to allow remote connections into my network! Horrible.
Blocking syncthing holepunching doesn’t stop any other app from holepunching.
Just disable QUIC if you want syncthing not to holepunch.
If you want to block it at the network level you have to look at the firewall settings, and enable symmetric NAT or some other similar strategy.
Google the details about how holepunching works and figure out what the best strategy to block it on your network.
As I said, blocking holepunching in syncthing doesn’t affect any other tool’s attempt to holepunch.
Yes, I slowly come to the acceptance, that it is not really possible to block SyncThing and other NAT traversal techniques with a network firewall.
This is only possible when running a firewall on a system and stop network access for all but a few Applications.
That also means, it is not possible to stop such things for iPhones and iPads and the like, as you cannot control what they are doing.
Whatever I tried in OPNsense, I still see “Relay WAN”, but cannot break the connection completely!
On the other hand, I also tried to enable “TCP WAN” or “QUIC WAN” but could not accomplish this either! Enabling Static Ports, allowing TCP/UDP Ports 22000 and UDP Port 21027 did not help in getting a TCP or QUIC WAN connection.
Any idea?
I’m not sure I’m completely clear what you’re attempting to accomplish but you should be able to forward UDP and TCP port 22000 to the machine running syncthing and the devices outside your network should use the discovery service to find the IP address and then initiate a connection which would be forwarded to the machine behind the firewall.
If you have more than 1 machine behind the firewall you want to be reachable move one of them from 22000 to some other port and setup forwards for both ports to the respective machine.
I thought to have written that already:
I got a firewall to block any NAT Traversal and Hole Punching from Apps like Syncthing and TailScale!
But as it seems, this is not possible with a network firewall, but requires a on-device firewall, which means devices like iPhone and iPads cannot be controlled.
And then, I wanted to allow only the connections I need and have configured.
And here, I am stuck again, not getting QIUC WAN or TCP WAN anymore. But maybe I did something wrong when allowing the connections, will check again.
Check the local machine’s firewall rules and check the port forwarding is setup correctly.
There is no firewall installed on the systems.
I had “QUIC WAN” when behind my FritzBox router and now I only get “Relay WAN” behind the OPNsense firewall.
I had no Port Forwarding enabled - then or now.
Why not? I presume your devices are behind a NAT router…
Sorry I can’t help you further. Good luck.
As I said, I was before on a NAT firewall, my FritzBox. And now I am behind a OPNsense firewall.
The OPNsense firewall is only different to the FritzBox in that is has non-static ports by default. But I enabled static ports for NAT of the ports used by SyncThing! So this should be the same situation now - but sadly, it isn’t.
Or to say that different: On the FritzBox, nothing special was needed to get a “QIUC WAN” connection! And I would like to reach this again - Port Forwarding clearly is NOT required!
Perhaps because syncthing was holepunching. And now we have come full circle…
Did you Google how holepunching works? And you fully understand the mechanism?
I don’t understand why you refuse to setup the port forward.
Yes, I read the Syncthing and TailScale descriptions for NAT Traversal and Hole-Punching!
Again I am not “refusing” anything 
I am just saying that I was behind a NAT firewall before and did get “QUIC WAN” without doing anything special.
And I am wondering what firewall feature may have changed that, after I migrated behind a OPNsense firewall.
I already use a NAT rule to have the regular Syncthing ports configured with Static-Ports - exactly like with the FritzBox. But that did not help.
And of course I will open ports, if required - but right now, I don’t understand why this was NOT needed with the FritzBox.
I’m thoroughly confused. You have a setup that is now not permitting the holepunch which seemed like it’s what you wanted.
And now you’re trying to reenable holepunching so you don’t have to setup a port forward?
Port forwarding is simpler and more reliable. Just forward the port if you trust syncthing. If you don’t trust syncthing don’t use it.
I don’t know enough about the details of the firewalls you’re using but as I highlighted in my previous message I think the clue is in the static port bit. And as I said you should google UDP holepunching and read an understand the fine details of how it works and perhaps it will give you the clue you need.
All that being said, I think you don’t understand the security implications clearly enough to know that this “static port” business you’re trying to configure is more or less safe than the port forward.
Seriously I suggest you undo the firewall customization you did trying to get the holepunching working. Put the static port business back to the defaults, and forward the port. Problem solved. And secure if you trust syncthing.
It seems, I was not able to explain what I did and why and what I want to reach.
Just the basics:
I did get “QUIC WAN” when using a FritzBox as router over VDSL. Nothing special was needed for this, esp. not Port Forwarding!
And now I exchanged the FritzBox with a OPNsense firewall that should do exactly the same! But it doesn’t. It only get’s me a “Relay WAN” connection.
And I want to understand WHY and what to change to get “QUIC WAN” again.
I thought that the non-static port NATing was the explanation, but I re-enabled static port NATing and it did not fix the connection type.
That is currently my central problem.
And again, I have nothing against Port Forwarding, but it was NOT required for the pure NAT FritzBox! So there should be a similar configuration for the firewall to reach the same - also without Port Forwarding.
More clear?
You need to dig into the fine details of how the two firewalls do their routing and UDP stateful connection tracking and port hashing to figure out why. And understand precisely how UDP holepunching works and in what circumstances it works and doesn’t. (Do you understand why “Symmetric NAT” is called that and how it’s different? Did you check you Syncthing logs to see if it’s detecting Synmetric NAT?)
Or forward UDP port 22000 to your Syncthing machine and call it a day.
If you want to figure out what’s different between the firewalls there is no shortcut to doing the research yourself.
And if you want to just get back to QUIC wan, forward the port.
Thanks, I will try to understand first, why it does not work as before.
If the logs had shown anything helpful, but they don’t:
2025-06-10 22:17:06 My ID: XXX
2025-06-10 22:17:06 Hashing performance is 539.71 MB/s
2025-06-10 22:17:06 Overall send rate is unlimited, receive rate is unlimited
2025-06-10 22:17:06 Using discovery mechanism: global discovery server https://discovery-lookup.syncthing.net/v2/?noannounce
2025-06-10 22:17:06 Using discovery mechanism: global discovery server https://discovery-announce-v4.syncthing.net/v2/?nolookup
2025-06-10 22:17:06 Using discovery mechanism: global discovery server https://discovery-announce-v6.syncthing.net/v2/?nolookup
2025-06-10 22:17:06 Using discovery mechanism: IPv4 local broadcast discovery on port 21027
2025-06-10 22:17:06 Using discovery mechanism: IPv6 local multicast discovery on address XXX
2025-06-10 22:17:06 Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
2025-06-10 22:17:06 TCP listener ([::]:22000) starting
2025-06-10 22:17:06 ...
2025-06-10 22:17:06 QUIC listener ([::]:22000) starting
2025-06-10 22:17:06 GUI and API listening on 127.0.0.1:8384
2025-06-10 22:17:06 Access the GUI via the following URL: https://127.0.0.1:8384/
2025-06-10 22:17:06 My name is "XXX"
2025-06-10 22:17:06 Device XXX is "XXX" at [dynamic]
2025-06-10 22:17:06 Ready to synchronize "XXX" (XXX) (sendonly)
2025-06-10 22:17:16 Joined relay relay://92.118.170.22:XXX
2025-06-10 22:17:16 quic://0.0.0.0:22000 detected NAT type: Symmetric NAT
2025-06-10 22:17:26 Detected 0 NAT services
2025-06-10 22:18:05 Completed initial scan of sendonly folder "XXX" (XXX)
Yet, “DISCONNECTED” is displayed.
I think I understand hole punching good enough, but yes I need to dig deeper.
TailScale works fine, BTW!
They do show something useful.
There is no shortcut to doing the research. We can tell you how to set it up. We already did…
But you want to understand why it doesn’t work.
But you didn’t do the reading.
I appreciate that you try to help me, but sadly it doesn’t.
I understand very well what Symmetric NAT is - I wrote above that I modified NAT for the Syncthing ports 22000 and 21027 to use static NAT ports and tried also with “static” disabled.
But the above logs explain nothing, sorry.
It says that Symmetric NAT was found and that a relay server could be connected!
But still, Syncthing shows “Disconnected”.
So neither Symmetric NAT nor access to the relay server did help.
Any idea?
I am going to re-enable non-static NAT ports again, to check if this shows somehow in the Syncthing logs.
I am somewhat happy that my current configuration can block Syncthing - but this was only an intermediate goal: To know HOW to block it.
But then, of course, I want to enable it again 
Sorry, you say you understand but I think you don’t.
Symmetric NAT is what’s blocking the holepunching. Your old router, if you were to check the logs would have reported a different NAT type. (Full cone, restricted cone etc.)
Anyway holepunching is not possible with your current router configuration.
Unless you can completely change the firewall type or NAT type, you will fail to make an incoming connection without port forwarding.
Congratulations. Even though you don’t understand you lucked into what you want. Holepunching is disabled. The “horrible” is gone. Forward the port.
I can’t help you anymore. This will be my last reply.