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

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

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

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.

[torup302 0]

Hi, just adding another data point here. I’m experiencing very similar behaviour to what the OP describes, starting within the last 24–48 hours.

WireGuard tunnel comes up normally
Handshake appears to succeed
transfer: X B sent, 0 B received
No DNS, ICMP, or TCP traffic ever returns through the tunnel

This is consistent across multiple AirVPN WireGuard endpoints (UK/London and others) and ports (including 1637).

Environment:

Headless Linux server
WireGuard via Gluetun / wg-quick
IPv4 only
Same network where OpenVPN (TCP 443) connects and passes traffic immediately

I’ve tried to eliminate local causes as thoroughly as possible:

Multiple AirVPN servers and ports -> same result
Local firewall disabled -> no change
MTU adjustments ->no change
Hard-coded endpoint IPs -> no change
Explicit DNS (1.1.1.1) -> no change
OpenVPN TCP works immediately on the same host and network

I captured traffic on both LAN/VLAN and WAN (PPPoE) interfaces:

Outbound UDP packets do leave my network
Source IP is correctly NAT’d to my public IP
Packets are sent to the AirVPN WireGuard endpoint
No inbound UDP replies are ever observed on WAN

This suggests the packets are leaving correctly but no return traffic is making it back, ruling out local NAT/firewall issues on my side.

What stood out to me in this thread is the report that Eddie only works once “Check DNS” is disabled. While I understand WireGuard itself is not DNS-dependent, the overall failure mode (handshake established but no usable traffic) matches my setup almost exactly.

At this point the behavior feels consistent with either:

a WireGuard backend routing issue, or
something affecting the return path for WireGuard traffic on certain networks

Happy to provide redacted packet captures or server names if that would help narrow it down.
 

[Staff 10482]

12 hours ago, torup302 said:

a WireGuard backend routing issue, or ... This is consistent across multiple AirVPN WireGuard endpoints (UK/London and others) and ports (including 1637)

 

12 hours ago, torup302 said:

I captured traffic on both LAN/VLAN and WAN (PPPoE) interfaces:

Hello!

We can't reproduce the problem on London servers, entry-IP address 1 and 3, port 1637. Since you have PPPoE please force WireGuard interface MTU to 1280 bytes and test again: the problem seems consistent with a too large MTU. Note that currently about 1200 active and working connection slots are operational and working through WireGuard on UK servers (most of them to port 1637, entry-IP address 3).

Is anybody else experiencing this specific problem?

Kind regards