I’ve noticed I now see
kcp://0.0.0.0:22020 resolved external address kcp://x.x.x.x:22020 (via stun.callwithus.com
I do not want syncthing making any internet connections , I use it only on my local LAN , how can I turn this off? I never saw this before this latest version
Thanks
Uncheck “NAT Enabled” in Advanced -> Options.
@calmh what is the default for this setting? checked?
I’m just asking because I had already unchecked “Enable NAT traversal”, “Local Discovery”, “Global Discovery”, “Enable Relaying” in the normal options (before upgrading to v0.14.40) and in advanced options “NAT Enabled” was already unchecked.
It was already unchecked
Erh, then STUN Keepalive Seconds to 0.
We default to helpful things enabled.
This seems like a bug if NAT is disabled , and it now (new to .40) does this anyway…?
I see someone else opened a ticket for this but it was closed: https://github.com/syncthing/syncthing/issues/4495
Yes > STUN Keepalive Seconds to 0. seems to have fixed back to the old behavior Thanks
No, it’s not a bug, just me not remembering what settings are what and it not being super clear to begin with.
NAT support (in our code) is about using NAT traversal protocols to set up port mappings in routers.
STUN is about figuring out the NAT type and external address when lacking port mappings, so explicitly for the situation where NAT port mappings don’t work or aren’t enabled.
Setting the listen address to something specific (like tcp://0.0.0.0:22000) will also disable KCP and therefore STUN.
I think due to popular demand and consistency with existing options, it would make sense to have a checkbox to disable STUN/kcp similar to global discovery. I assume there is no meaningful information “given” to the external STUN server, but the fact it comes up is probably enough for some people to dislike it. And at lest to me it is not obvious that you need to modify the listen address to disable STUN. Or go full crowd pleasing by having a checkbox expressing the “I don’t want Syncthing to talk to anything unless I agreed to” sentiment, which disables relays, global discovery and STUN 
That’s a fair argument, yet this would make an odd number of checkboxes in settings 
If we’re trying to make settings more user friendly we should also take a long hard look at the magic “default” listen address that is completely inscrutable.
We could divide things into sections, maybe.
TCP Connections:
[X] Outgoing connections
[X] Incoming listen addresses: [:22000 ]
[X] Attempt NAT (UPnP/PMP) Port Mappings
...
KCP Connections:
[X] Outgoing connections
[X] Incoming listen addresses: [:220whatever]
[X] Use STUN Port Detection
...
Relay connections:
[X] Outgoing connections
[X] Listen on public relays
[ ] Listen on custom relays: [ ]
...
This would make it easier to, for example, not listen on or announce relays and KCP, but still use it for outgoing connections for others who do, and so on. Or make devices that don’t listen on anything but only connect outwards, or vice versa.
Looks good, go for it 
Sorry but i still don’t get it.
If i don’t use syncthing in wan why that name resolution is happening? When that ip will ever be used if i use syncthing only in lan?
That’s nice but is not intuitive at all. I don’t believe this is an advanced feature, we should have a check in settings since most people that disable wan discovery and things like that are not expecting that nat traversal with an ip resolution. It’s kinda an hidden feature right now and there is no way it should be.
We have an option “NAT Traversal” right? Isn’t that feature about NAT traversing? Then why if i disable this i still get that? If it’s not a bug is a weird behaviour.
I think your questions have been answered above as well as I can.
I’m sorry but i can not see the answer
On the Settings we have a switch for NAT Traversal
STUN by Wikipedia is Session Traversal Utilities for NAT
Why if we uncheck NAT Traversal we keep STUN on?
It helps to traverse NAT but i uncked traversing NAT.
If we disable NAT Traversal on the Settings we want STUN disabled since:
NAT Traversal is traverse the NAT
STUN traverse the NAT
STUN is NAT Traversal
You are entitled to your opinion of course, but Jakob’s explanation above is why NAT traversal is separate for Syncthing - arguing about that is moot. If you care to actually read what was written before, you have seen that I proposed a simpler way to deactivate STUN, Audrius agreed (mostly 
) and finallly Jakob proposed an even simpler and better scheme. So both lead devs (one of which is the author of the KCP feature) already agree with you, that this could/should be optimized - no need to antagonize people with being argumentative. This is open source, so if you want that badly right now, your best bet is to contribute - otherwise you can just wait and hope someone else will do it.
So I agree that we should make it easier to disable, yet I disagree that STUN counts as NAT traversal therefore it should fall under the same option. STUN is just a way to figure out your external address and port. STUN by itself does not traverse anything. It’s like saying discovery is NAT traversal.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.