Discovery Failures: connection refused for v4 and v6

Support
1

Hi, I am facing an issue with Global Discovery on one of the computers I setup Syncthing on. I have 3 devices on a Home 1 network: Android Phone, Windows Laptop, Linux Headless PC. 1 device on Home 2 which is directly connected to internet. syncthing

Now, All except for Arch Linux:

  1. Devices are able to connect with each other out of the box (local and global)
  2. Each of the device has “Listeners 3/3” and “Discovery 4/5”
  3. For Global Discovery ipv6 is failing because my ISP does not support it.

Now, Arch Linux:

  1. Device is able to connect with each other out of the box for LOCAL but NOT for GLOBAL
  2. The device has “Listeners 2/3” and “Discovery 3/5”
  3. For Global Discovery ipv6 is failing because my ISP does not support it.

For “Listeners 2/3” the error is:

dynamic+https://relays.syncthing.net/endpoint: Get "https://relays.syncthing.net/endpoint": dial tcp: lookup relays.syncthing.net on [::1]:53: read udp [::1]:36305->[::1]:53: read: connection refused

For “Discovery 3/5” the error is:

  • global@https://discovery-v4.syncthing.net/v2/: Post "https://discovery-v4.syncthing.net/v2/": dial tcp: lookup discovery-v4.syncthing.net on [::1]:53: read udp [::1]:36772->[::1]:53: read: connection refused
  • global@https://discovery-v6.syncthing.net/v2/: Post "https://discovery-v6.syncthing.net/v2/": dial tcp: lookup discovery-v6.syncthing.net on [::1]:53: read udp [::1]:44185->[::1]:53: read: connection refused

for Home 1 this is port forwarding: image

When I SSH to Arch Linux and run:

resolvectl query discovery-v4.syncthing.net
discovery-v4.syncthing.net: 198.211.120.59     -- link: enp1s0
                            139.59.84.212      -- link: enp1s0

-- Information acquired via protocol DNS in 1.3ms.
-- Data is authenticated: no

resolvectl query discovery-v6.syncthing.net
discovery-v6.syncthing.net: 2a03:b0c0:0:1010::bb:4001 -- link: enp1s0
                            2400:6180:100:d0::741:a001 -- link: enp1s0

-- Information acquired via protocol DNS in 1.6ms.
-- Data is authenticated: no

I can confirm DNS is working correctly. All devices are running version v1.8.0

At this point I am stuck and don’t really know how to troubleshoot the issue. Any help? :slight_smile:

Thanks

2

Since you seem to have working UPnP, you do not need to manually setup port forwards. Right now you have duplicate forwarding for host Arch Linux, which is unnecessary. Additionally, local discovery is port 21027 and is meant to be local, so no reason to forward this across routers.

This seems like a local system policy (firewall) is blocking DNS access for syncthing. This may not be an issue to other applications on the system (like systemd), because those may do lookups differently than syncthing (using host API vs doing DNS directly from the application).

3

Thanks for pointing out port forwarding, I removed both records and left only upnp. I just setup the Arch Linux and at this point there is no firewall installed on the system.

I tried connecting with different program like curl and it was able to resolve ipv4 hosts:

curl -X GET --insecure https://discovery.syncthing.net/v2/

Not Found

curl -X GET --insecure https://discovery-v4.syncthing.net/v2/

Not Found

curl -X GET --insecure https://discovery-v6.syncthing.net/v2/

curl: (7) Couldn’t connect to server

curl -X GET https://relays.syncthing.net/endpoint

{“relays”:[{“url”:"relay://209.141.48.72:443/?id=MN4WDSC-KHDUWFA-…`

Perhaps someone here uses Arch Linux with Syncthing and faced similar issues :slight_smile: What else I could check?

4

Are you actually running dns server on the local machine? Why is it configured to talk to localhost for dns?

5

“Not found” is the correct answer to those queries by the way, so indicates things are working.

Syncthing is still trying to talk DNS to localhost, which might be wrong? It’s likely trusting your /etc/resolv.conf.

6

Got it working! thanks @AudriusButkevicius ! so I was running systemd-resolved and systemd-networkd however, in https://wiki.archlinux.org/index.php/Systemd-resolved and https://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved.8#/ETC/RESOLV_&.CONF documentation there is info that you need to link ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf :grin: OOTB /etc/resolv.conf is empty and /run/systemd/resolve/stub-resolv.conf has:

nameserver 127.0.0.53
options edns0 trust-ad

Once I symlink these two files together and restarted the server everything started working :slight_smile: So no surprise, reading the documentation solved the issue :heavy_check_mark:

Thanks @Nummer378 @AudriusButkevicius for your help!

1 Like
7

yep, the /etc/resolv.conf is empty in Arch Linux out of the box. linking to /run/systemd/resolve/stub-resolv.conf resolved the issue :slight_smile:

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.