[GH-ISSUE #5635] AWS Peer Connection Issues #11567

Open
opened 2026-08-05 01:30:03 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @stuartsevastos on GitHub (Mar 19, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5635

Hi guys,

We have been rolling out the self-hosted version of NetBird, and so far, it has been going well. When trying to deploy the NetBird agent on AWS servers with the Plesk control panel installed, we had to do a workaround, and I have summarised the findings in the report below:

Environment:
• OS: Ubuntu (AWS EC2)
• NetBird version: 0.66.4
• Co-existing DNS: BIND9 (named) managed by Plesk control panel

Problem Description:

On servers where BIND (named) is already running as the system DNS server, NetBird's DNS interception fails to initialise, leaving STUN unavailable and preventing direct peer-to-peer connections (peers remain stuck in Connecting state).

Root Cause:

When the NetBird agent starts, it registers its internal DNS server (127.0.0.153) against the wt0 WireGuard interface via D-Bus to systemd-resolved, scoped to the NetBird peer domain (e.g. netbird.example.com). This causes systemd-resolved to bind outgoing DNS sockets to the wt0 interface when resolving that domain — including when resolving the NetBird management/STUN server hostname itself.

The problem is that 127.0.0.153 is a loopback address and is unreachable via the wt0 WireGuard interface. When systemd-resolved creates a UDP socket bound to wt0 and connects it to 127.0.0.153:53, the kernel cannot determine a valid path MTU (the connection initially returns ENOTCONN, then loops, returning the WireGuard MTU of 1280). systemd-resolved enters a tight getsockopt(IP_MTU) loop and never sends the DNS query.

This was confirmed via strace on the systemd-resolved process:

SO_BINDTOIFINDEX → wt0 (interface 3)
connect → 127.0.0.153:53  (loopback addr, but bound to wt0!)
getsockopt(IP_MTU) → ENOTCONN
getsockopt(IP_MTU) → 1280  ← loops indefinitely, query never sent

On non-Plesk/non-BIND systems, this is handled transparently by NetBird's XDP/eBPF program (nb_xdp_prog) attached to the loopback interface. However, on this system, the XDP DNS maps (nb_map_dns_ip, nb_map_dns_port) were all zeroes, indicating the XDP interception failed to initialise — likely because BIND is already occupying the DNS stack when NetBird starts.

Symptoms:
• netbird status -d shows stun:... as Checking... indefinitely
• Peers stuck in Connecting with RemoteCandidate: 0
• dig netbird.example.com via 127.0.0.53 times out
• dig netbird.example.com @127.0.0.153 works fine (direct query bypasses the broken path)
• dig netbird.example.com @8.8.8.8 works fine

Workaround:

We had to add a static /etc/hosts entry for the NetBird management server, bypassing systemd-resolved entirely for that hostname:

echo "$(dig +short netbird.example.com @8.8.8.8) netbird.example.com" | sudo tee -a /etc/hosts
netbird down && netbird up

After this, STUN shows as Available, and peer connections establish correctly.

Originally created by @stuartsevastos on GitHub (Mar 19, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5635 Hi guys, We have been rolling out the self-hosted version of NetBird, and so far, it has been going well. When trying to deploy the NetBird agent on AWS servers with the Plesk control panel installed, we had to do a workaround, and I have summarised the findings in the report below: **Environment:** • OS: Ubuntu (AWS EC2) • NetBird version: 0.66.4 • Co-existing DNS: BIND9 (named) managed by Plesk control panel **Problem Description:** On servers where BIND (named) is already running as the system DNS server, NetBird's DNS interception fails to initialise, leaving STUN unavailable and preventing direct peer-to-peer connections (peers remain stuck in Connecting state). **Root Cause:** When the NetBird agent starts, it registers its internal DNS server (127.0.0.153) against the wt0 WireGuard interface via D-Bus to systemd-resolved, scoped to the NetBird peer domain (e.g. netbird.example.com). This causes systemd-resolved to bind outgoing DNS sockets to the wt0 interface when resolving that domain — including when resolving the NetBird management/STUN server hostname itself. The problem is that 127.0.0.153 is a loopback address and is unreachable via the wt0 WireGuard interface. When systemd-resolved creates a UDP socket bound to wt0 and connects it to 127.0.0.153:53, the kernel cannot determine a valid path MTU (the connection initially returns ENOTCONN, then loops, returning the WireGuard MTU of 1280). systemd-resolved enters a tight getsockopt(IP_MTU) loop and never sends the DNS query. This was confirmed via strace on the systemd-resolved process: ``` SO_BINDTOIFINDEX → wt0 (interface 3) connect → 127.0.0.153:53 (loopback addr, but bound to wt0!) getsockopt(IP_MTU) → ENOTCONN getsockopt(IP_MTU) → 1280 ← loops indefinitely, query never sent ``` On non-Plesk/non-BIND systems, this is handled transparently by NetBird's XDP/eBPF program (nb_xdp_prog) attached to the loopback interface. However, on this system, the XDP DNS maps (nb_map_dns_ip, nb_map_dns_port) were all zeroes, indicating the XDP interception failed to initialise — likely because BIND is already occupying the DNS stack when NetBird starts. **Symptoms:** • netbird status -d shows stun:... as Checking... indefinitely • Peers stuck in Connecting with RemoteCandidate: 0 • dig netbird.example.com via 127.0.0.53 times out • dig netbird.example.com @127.0.0.153 works fine (direct query bypasses the broken path) • dig netbird.example.com @8.8.8.8 works fine **Workaround:** We had to add a static /etc/hosts entry for the NetBird management server, bypassing systemd-resolved entirely for that hostname: ``` echo "$(dig +short netbird.example.com @8.8.8.8) netbird.example.com" | sudo tee -a /etc/hosts netbird down && netbird up ``` After this, STUN shows as Available, and peer connections establish correctly.
saavagebueno added the triage-needed label 2026-08-05 01:30:03 -04:00
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11567