Hello! New user here. This is a great piece of software! Just had a question about global discovery.
We have an existing service that uses a port range that overlaps port 22000, so we redefined the listening port via Sync Protocol Listen Addresses on all our devices.
Everything reconnected and sync’d again.
However we were still seeing frequent connection attempts to port 22000 in our firewall logs. These go away if we disable Global Discovery on all devices, but then we lose contact with devices that are not on the local LAN.
So we’re guessing that Global Discovery always uses port 22000…is that correct?
Thank you–we are really looking forward to using Syncthing.
They wrote that they already changed the listening port
No, global discovery should consider the configured listening address including port. You could enable discover debug facility, which will print all the announced addresses to make sure. Other than that no idea about those connections attempts at the moment.
Then we tried various combinations of those parameters, thinking maybe the “dynamic+…” parameter was the problem. We ended up specifying just tcp://:13666 but it made no difference.
Until we disabled Global Discovery we still saw iptables SYN blocks on destination port 22000. The source address is always one of our two WAN addresses so the packets are originating on one of our two LANs and probably looping back to the other. Perhaps the discover debug facility will provide more clarity on this.
@Andy we were only noticing the port 22000 SYN packets. We’ll keep an eye out for any on port 21027. Thanks for that suggestion.
If an address to dial lacks a port Syncthing will default to 22000, but I don’t think addresses from global discovery ever lack a port… One scenario which might be a possibility (but that I can’t be bothered to track down fully right now) is if the NAT mapping or STUN stuff fails / does something odd. Syncthing tries to announce the detected external port for UPnP/PMP port mappings, and the STUN discovered addresses for NAT punchthrough, and could possibly default to 22000 somewhere along the way if we don’t get any port mappings, as a best guess. Similarly I remember something about announcing with port zero which gets mapped to the source port on the discovery server, but that’s probably just for QUIC…
@calmh thanks for that idea Jakob. We were wondering about possibly unchecking NAT but thought it would cause problems since both our WAN addresses use NAT.
We got some good data from discovery debugging. We obfuscated the ID and WAN address (let me know if you need to see those) and I also added line breaks for readability. (I couldn’t find a way to enter a code block; if there’s a way to do that please let me know.)
You can see port 22000 listed for both quic and TCP:
2021-01-07 09:18:20 lookup results for [obfuscated]
relay://136.37.167.177:22067/?id=2WMVG42-HU6BFMT-3J3R7SY-U7NLEPV-23T42AH-HLK365A-BVK2BLA-6QPXKQY&pingInterval=1m0s&networkTimeout=2m0s&sessionLimitBps=0&globalLimitBps=0&statusAddr=:22070&providedBy=luglufa Public Services
So it’s clearly part of the result set returned from the discovery servers. Does discovery tracing show the set of addresses actually announced to the servers? (I’d hope it does.)
I guess this is good news but we’re trying to understand what changed: the packets stopped at 1037 this morning.
The last packet received on port 22000 and blocked by iptables on our server was a 1260 byte UDP packet. All prior packets were TCP SYN packets from the same address.
The only thing we had been doing was trying various combinations of Sync Protocol Listen Addresses (per the suggestions in this thread) and toggling on and off discovery logging.
(Per your question, we don’t see any announced addresses in the logs unfortunately. Just what we included above.)
We did apply the 1.12.1 Syncthing update via aptitude today, as well as a kernel update (which required reboots on all our systems) but that was in the afternoon.
We’ll watch this over the next few days to see if the packets start again.
After a couple of days this hasn’t recurred, so it must have been due to a flawed copy/paste of the Sync Protocol Listen Address information into the machine with the 6.101 LAN address.
Thank you @imsodin for the tip about discovery debugging and thank you to everyone that offered suggestions.
We are looking forward to using Syncthing and we made a donation per the home page via Stripe today.
