Possible to change the global discovery port?

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.

Sam

You can set any port you want, this won’t affect discovery. How to do that is explained in the docs

They wrote that they already changed the listening port :wink:

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.

1 Like

I could be wrong, is such discussion not more related to Local Announce Port, standard port 21027, since port 22000 is the standard listen adress?

Thank you to everyone that replied.

@imsodin I will see how to enable the discover debug facility and will report back. Thanks for that tip Simon.

@AudriusButkevicius we definitely changed the listening port on all devices. We first tried this way in order to match the three “default” methods:

tcp://:13666, quic://:13666, dynamic+https://relays.syncthing.net/endpoint

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.

BTW this is really nice forum software.

Sam

Maybe try to use only that part.

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…

Disabling NAT support might get rid of it.

Removing the relay stuff shouldn’t matter.

2 Likes

@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]

2021-01-07 09:18:20 addresses: [quic://192.168.6.101:13666 quic://192.168.6.101:22000 quic://[WAN IP]:13666 quic://[WAN IP]:22000 quic://[WAN IP]:49791 quic://[WAN IP]:50177 quic://[WAN IP]:51207 quic://[WAN IP]:52195 quic://[WAN IP]:52624 quic://[WAN IP]:53134 quic://[WAN IP]:61460 quic://[WAN IP]:62151 quic://[WAN IP]:62899 quic://[WAN IP]:63809 quic://[WAN IP]:64482 quic://[WAN IP]:65260

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

relay://184.105.151.164:22067/?id=UCLAW7A-X7VNZU3-O5TJBB7-ASN4MYY-KVZZLII-RQ2XBFW-TWFKTSG-JRR65Q2&pingInterval=1m0s&networkTimeout=2m0s&sessionLimitBps=0&globalLimitBps=0&statusAddr=:22070&providedBy=explodie.org

relay://65.19.142.180:22067/?id=XLLZWPP-A3X2N6W-75UKPKF-YAYSDC2-DGKHYSQ-LFQCZKR-BA22LXJ-EDXK5AO&pingInterval=4m0s&networkTimeout=10m0s&sessionLimitBps=0&globalLimitBps=0&statusAddr=:22070&providedBy=Satya Vaswani

relay://66.198.127.125:443/?id=43A3E25-BCMBIX4-H2ICF5P-U2IW3GD-NTL5BBO-O4AEW6O-RWMIVGE-AML7FQG&pingInterval=1m0s&networkTimeout=2m0s&sessionLimitBps=0&globalLimitBps=0&statusAddr=:22070&providedBy=

tcp://192.168.6.101:13666 tcp://192.168.6.101:22000 tcp://[WAN IP]:13666 tcp://[WAN IP]:22000 tcp://[WAN IP]:49385 tcp://[WAN IP]:49564 tcp://[WAN IP]:49793 tcp://[WAN IP]:50244 tcp://[WAN IP]:51224 tcp://[WAN IP]:51724 tcp://[WAN IP]:52202 tcp://[WAN IP]:52688 tcp://[WAN IP]:53136 tcp://[WAN IP]:61499 tcp://[WAN IP]:62162 tcp://[WAN IP]:62968 tcp://[WAN IP]:63867 tcp://[WAN IP]:64548 tcp://[WAN IP]:65275]

Thanks very much for your help with this.

Sam

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.)

@calmh Hi Jakob

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.

3 Likes