Headless Linux - unable to connect via wireguard

[mefflecakes 0]

I’m wondering if others are experiencing persistent WireGuard handshake issues over the last 24–48 hours. I am seeing symptoms very similar to those described in this recent thread: https://www.reddit.com/r/AirVPN/s/FsrrAQglfa (packet loss and "authoritative nameserver" errors).

 

I am running a headless Arch Linux server using wg-quick. Despite using a variety of ports (including 53 and 443) and hardcoded IP endpoints, I am stuck at:

transfer: 0 B received, [X] B sent

 

Interestingly, I was able to get a connection established on a separate pc using the Eddie client, but only after going into Preferences and unchecking 'check dns'. When that box is checked, Eddie hangs on checking dns. Once unchecked, data flows perfectly in both directions on the pc. However, this "fix" isn't directly applicable to my primary headless setup, where I'm using native WireGuard tools and manual policy routing.

 

My setup:

• OS: Arch Linux (Headless)

• Protocol: WireGuard (via wg-quick)

• Handshake Status: 0 B received (Sent packets are never acknowledged).

• DNS: I have tried bypassing internal DNS by setting 1.1.1.1 in the config, but the handshake still refuses to complete on the Linux side.

• ISP/Network: Same network where Eddie (with "Check DNS" off) works.

 

Is there currently an issue with the backend DNS validation or the internal API that WireGuard handshakes rely on? It seems that if the "DNS check" fails, the handshake or the routing associated with the tunnel is being stalled.

I'd like to know if this is a widespread issue and if so, is it being worked on?

Edited ... by mefflecakes
Typo, edited to be more concise

[Staff 10481]

1 hour ago, mefflecakes said:

I’m wondering if others are experiencing persistent WireGuard handshake issues over the last 24–48 hours. I am seeing symptoms very similar to those described in this recent thread: https://www.reddit.com/r/AirVPN/s/FsrrAQglfa (packet loss and "authoritative nameserver" errors).

Hello!

That's a totally separate issue which involved authoritative nameservers of airvpn.org more than two days ago and was completely resolved in a very short time, as the users writing in that thread correctly reported. Moreover it did not have any impact on VPN infrastructure.
 

1 hour ago, mefflecakes said:

Is there currently an issue with the backend DNS validation or the internal API that WireGuard handshakes rely on? It seems that if the "DNS check" fails, the handshake or the routing associated with the tunnel is being stalled.

We can't reproduce this issue and by examining tickets on the last 24 hours there's not even one complaint about it. Can you list the specific servers you experience this problem on? 

Please note that DNS is set locally by WireGuard related script according to the DNS address(es) included in the profile (wg-quick on Linux tries to call resolvconf). DNS is not pushed by the VPN server, because WireGuard does not have any DHCP function.

However, WireGuard handshake is not related to DNS, keep in mind.

Kind regards
 

[mefflecakes 0]

Hello,

Thank you for the quick response.

To clarify, I am experiencing this specifically on the Netherlands cluster (specifically Alphecca and Alkaid), but the behavior persists across several other EU nodes.

Per your request, I have attached the Eddie System Report from my macOS machine captured immediately after a failed DNS check. As requested, I confirmed that if I disable "Check DNS" in Eddie, the connection establishes and data flows normally.

However, my primary concern remains my headless Arch Linux server using native wg-quick. On this machine:

1. I am using a generated WireGuard configuration with hardcoded IP endpoints to bypass any potential airdns.org resolution issues.

2. The handshake consistently fails (0 B received) despite the server being reachable via ICMP ping.

3. I have verified that systemd-resolved is active, and I am manually specifying DNS = 1.1.1.1 in the interface config to ensure I am not relying on internal VPN DNS for the handshake/initialization.

If the DNS is strictly local, it is unclear why the Eddie "Check DNS" toggle acts as a "kill-switch" for the entire tunnel establishment on the same network where a native WireGuard handshake is failing.

Attached are the Eddie reports you requested, I'm happy to focus on just ensuring we get Eddie connecting, because if this is an issue relating to my network configuration in some way then everything else should fall in place.
 

Arch Linux - Eddie_20260301_170720.txt ArchLinux Sysreport.txt MacBook Pro SysReport macOS - Eddie_20260301_170301.txt

[Staff 10481]

25 minutes ago, mefflecakes said:

If the DNS is strictly local, it is unclear why the Eddie "Check DNS" toggle acts as a "kill-switch" for the entire tunnel establishment on the same network where a native WireGuard handshake is failing.

Hello!

On the contrary. This means that Eddie could not resolve names on the specific DNS set on the system after the connection was established. If the handshake failed there was no communication between your system WireGuard and the VPN server. If the DNS check is disabled and the connection works, then the handshake is successful and the previous DNS check failure was a false positive.

On your Arch Linux machine: the handshake is successful. DNS check fails on IPv6 while it is successful over IPv4. However, on Alphecca IPv6 and DNS6 work fine (just tested). Alkaid was decommissioned in 2019, so it must not appear on Eddie and you should discard Alkaid-specific profiles. Maybe you meant a different server?

Try to disable Eddie's DNS check just in case it's a false positive or it is related to IPv6 problems in your machine.
On your macOS machine: the handshake fails, so DNS is not (and can not) be checked. WireGuard does not communicate with the servers at all. Any anti-malware tool that might block communications?

Kind regards
 

[mefflecakes 0]

Well I've disabled IPv6, might that do it? :D

[Staff 10481]

3 minutes ago, mefflecakes said:

Well I've disabled IPv6, might that do it?

Hello!

Holy moly...  If you have disabled IPv6 on your system but you kept IPv6 layer on Eddie then the IPv6 DNS and route check correctly fail.

Kind regards
 

[mefflecakes 0]

Just re-enabled ipv6 on my router, PC and Eddie but still no luck 😕

I've got nothing set on the router that should block traffic. Very strange.