KCP and firewalls / port forwards (v0.14.40 release)

General
1

Hi there brief question about firewall config (and documentation of syncthing on its doc site) regarding kcp: do we need to forward/open another additonal udp port 22020 as during a fresh startup/restart of 0.14.40 i see these kind of log lines:

[XXXA] 20:04:52 INFO: kcp://0.0.0.0:22020 detected NAT type: Port restricted NAT [XXXA] 20:04:52 INFO: kcp://0.0.0.0:22020 resolved external address kcp://44.111.33.222:22020 (via stun.counterpath.com:3478)

I have forwarded for a long time on the nat gateway device some 22000 port or things like that according to what I found back then in the syncthing doc pages https://docs.syncthing.net/users/firewall.html

can anyone update those or be more precise in these technical details? thank for your software and the efforts. cheers.

p.s. My router even supports and does feature upnp, so I wonder if I need manual forward at all to begin with, but I added the 22000 back then manually. But the kcp a.k.a. udp port didnt become handled via upnp mechanism by the syncthing code. is this a bug?

2

No, there’s no need to add any port forwards or make firewall openings.

KCP is designed to work without them, and if you can fix your NAT gateway / firewall to add port forwards you should do so to get TCP working instead - it’s faster and more efficient.

If your router supports UPnP you should not have to do anything, TCP should connect fine, and you shouldn’t see KCP in action. KCP is intended for less fortunate setups.

1 Like
3

Yeah I did so too. I think i did forward tcp and udp 22000 both, I wonder if I am still a layman or overinterpreting or misinterpreting your firewall documentation. I would like to read more precise stuff on why and what component speak on what ports and protocols exactly and so on. I think I even once found a real confusion contradiction somewhere on the doc pages in combination with some other subpages there which also speak about networking, proxy/relay and such stuff. maybe the docs can be enhanced? or I need to apprehend more? my router can properly set udp forwarding as well, not just tcp forwarding. thanks.

4

Hey there - how can I disable this new KCP/UDP stuff? I am happy with the performance of relays for my computer at work, and with forwarding a port to my home computer. However even though I have set the protocol listen addresses to “tcp://:22000, dynamic+https://relays.syncthing.net/endpoint” manually on all of my systems, I’m still seeing a lot of DEBUG log entries relating to KCP connections and (worse) firewall logs full of failed incoming UDP connections.

Hopefully there is a way of disabling all this new UDP stuff altogether? Otherwise my limited firewall logging capacity is just going to fill up with Syncthing connections that I don’t need…

Thanks!

5

You need to set that list of addresses on all your devices and give it an hour or two for discovery entries to expire.

6

Hmm. Is there no way to force that expiry? I’m up to several thousand blocked entries so far - no way to “flush” the global discovery cache?

7

No, as anyone could cause DoS by flushing.

Also, if you are hopping between AP’s (which is not the case now), flushing would be detrimental. If you removed the listen address and you are connected to the other device via TCP, it should stop trying KCP.

8

Logging every incoming UDP packet is probably not productive, KCP or not.

9

I thought this could be protected by the same authentication that protects the rest of the traffic such that a node could only flush its own discovery data. I guess not though, no problem.

This didn’t seem to happen originally, I was still seeing DEBUG messages concerning UDP connections for hosts that were connected. After a few hours though (or rather a UK overnight) it all seems OK now.

I’m not logging every packet, however the firewall logs every new blocked connection. You’re right, it’s probably unnecessary and I’ll review whether we need to log stuff that was blocked, I just wasn’t expecting an upgrade of Syncthing to suddenly cause the log to fill up with these repeated connection attempts on random ports, and particularly when I couldn’t work out whether I’d done the right thing to make it stop.

Either way, now I’ve been to sleep for a few hours with most of the machines turned off, everything seems to have gone back to the pre-UDP behaviour which works well for me. Thanks for the tips, both of you :slight_smile:

10

Cool. As an aside, please don’t ascribe too much meaning to DEBUG level log messages without actually comparing with the code that generates them. It’s entirely possible that you might see debug info for things that are in fact disabled.

11

This would only be the case if you are connected using TCP. Stun will happen regardless what protocol you are connected via.

12

You should add newly needed ports to the ufw application file and the docs. I got a ton of entries in my ufw.log and it took me a while to figure out that syncthing needed a new port.