I have successfully set up custom discovery and custom relay servers. We used IPs originally and everyone node can see eachother and sync stuff without issue. Then I went ahead and swap the IPs with a domain name (naturally points to the server’s IP that we have originally used) in each node. Now no nodes can see eachother or connect to eachother. I have tested this numerous times with same failures. Reverting to IP works %100.
https://XX.XX.XX.XX:8443/?id=XXX (It works)
relay://XX.XX.XX.XX:22067/?id=XXX (It works)
https://SUBD.name.org:8443/?id=XXX (It does not work)
relay://SUBD.name.org:22067/?id=XXX (It does not work)
I am not running both servers behind reverse proxies, so they are connected to internet directly, and I used the Syncthing documentation’s pages to set them up.
Here in one node. As you can see the node connects and finds both servers but there are no successfull connections between these nodes, although each node shows similar state like the one in the image
(Url is used, but no successfull connections, all nodes look offline)
[XJWYX] 13:31:52 INFO: Using discovery server https://SUBD.name.org:8443/?id=XXX
[XJWYX] 13:31:52 INFO: Relay listener (relay://SUBD.name.org:22067/?id=XXX&pingInterval=1m0s&networkTimeout=2m0s&sessionLimitBps=0&globalLimitBps=0&statusAddr=:22070&providedBy=) starting
[XJWYX] 13:31:52 INFO: Ready to synchronize "folder" (ID) (sendreceive)
[XJWYX] 13:31:52 INFO: TCP listener ([::]:36203) starting
[XJWYX] 13:31:52 INFO: QUIC listener ([::]:36203) starting
[XJWYX] 13:31:52 WARNING: Insecure admin access is enabled.
[XJWYX] 13:31:52 INFO: GUI and API listening on 127.0.0.1:44767
[XJWYX] 13:31:52 INFO: Access the GUI via the following URL: http://127.0.0.1:44767/
[XJWYX] 13:31:52 INFO: My name is "ZZ"
[XJWYX] 13:31:52 INFO: Device A is "X" at [dynamic]
[XJWYX] 13:31:52 INFO: Device Device A is "A" at [dynamic]
[XJWYX] 13:31:52 INFO: Device Device B is "B" at [dynamic]
[XJWYX] 13:31:52 INFO: Device Device C is "C" at [dynamic]
[XJWYX] 13:31:52 INFO: Joined relay relay://SUBD.name.org:22067
[XJWYX] 13:31:52 INFO: Completed initial scan of sendreceive folder "folder" (ID)
[XJWYX] 13:31:55 INFO: API call returned HTTP error: 404 Not Found
[XJWYX] 13:32:02 INFO: Detected 0 NAT services
[XJWYX] 13:34:06 INFO: Listen (BEP/relay): joining session: dial tcp: lookup <nil>: no such host
[XJWYX] 13:36:51 INFO: API call returned HTTP error: 404 Not Found
[XJWYX] 13:36:51 INFO: Automatic upgrade: no version to select
[XJWYX] 13:38:17 INFO: Listen (BEP/relay): joining session: dial tcp: lookup <nil>: no such host
Is there a limitation with using a domain name for these servers?
The regular Syncthing-provided discovery servers are used by hostname, and I can’t imagine why there would be a problem with it specifically in your setup either. Maybe use debug tracing on the discovery to see details, but I suspect it might be a server side issue.
It is interesting because the disco server actually gets connections from all the nodes, except an error like this seems to be peculiar in teh disco log. The log is filled with mostly benign connection lines with IDs
http: TLS handshake error from XX.XX.XX.XX:38648: EOF
Or
http: TLS handshake error from ZZ.ZZ.ZZ.ZZ:36160: tls: client offered only unsupported versions: [302 301 300]
http: TLS handshake error from ZZ.ZZ.ZZ.ZZ:36383: tls: client offered only unsupported versions: [301 300]
http: TLS handshake error from ZZ.ZZ.ZZ.ZZ:36898: tls: client offered only unsupported versions: [300]
http: TLS handshake error from ZZ.ZZ.ZZ.ZZ:48183: tls: unsupported SSLv2 handshake received
http: TLS handshake error from ZZ.ZZ.ZZ.ZZ:37394: tls: no cipher suite supported by both client and server
```
How though? I mean I am not running it behind a reverse proxy, if there is a TLS error would not that be purely a Syncthing originated? I do not mean to blame just trying to understand this.
One of the nodes is behind socks proxy (via SSH socks).
I don’t know, but the error says a client is trying to negotiate an SSL version that was deprecated before the first Syncthing version was released in 2014. We’ve never tried to negotiate something as old as that, ergo it’s not Syncthing on the other end.
Just chiming in to report that I am using custom discovery servers via user-defined domain names and this works 100%. Syncthing is definetly able to do this, something else is broken in your setup.
My guesses would be DNS is wrong, there’s a proxy that acts differently with a hostname than an IP (maybe because DNS is wrong or split horizon), or there is a reverse proxy that acts differently when the client sends a hostname instead of an IP.
Then again, a green light on the discovery counter as in the screenshot should indicate it managed to announce itself to the server and got some sort of valid response, I think.
there is a reverse proxy that acts differently when the client sends a hostname instead of an IP.
None of the servers are behind reverse proxy, they are connected directly. We are not definetely handling any of the certificates, here are the lines that are running them.
I am running them behind an (nginx) reverse proxy.
Additonally, the proxy has a valid HTTPS certificate, so I’m not using the ?id=X certificate pinning method and the discovery server runs in -http mode.
