Kernel WireGuard: after a relay → direct IPv6 handover, a handshake response leaves with source ::1 and the remote peer drops it (wgproxy loopback, 0.82.0)

[teddashh]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Peer connectivity, Relay / Signal / NAT traversal, Client / Agent

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

Linux, Docker

NetBird version and upgrade status

• Client: 0.82.0 on both peers, kernel WireGuard (netbirdio/netbird:0.82.0@sha256:eca5b274c635bfbb04ec6724a0712d1146190dd450eea199eeb83916fdd94965)
• Management / Signal / Relay: 0.82.0 (netbirdio/netbird-server:0.82.0@sha256:7b5b53b2dc8bc25639f791cf72d47cf86911894ff3f8a97cb79bab9be958109c)
• Dashboard: not involved
• Upgrade status: 0.82.0 is the newest stable release as of 2026-11-03. The code involved is unchanged on main (ad8c1cc9).

Did this work before?

Not sure

Regression details

• Last known working version: unknown. We have not tested anything before 0.82.0.
• First known broken version: observed on 0.82.0. The code path comes from [client] Replace the eBPF WireGuard proxy with loopback endpoint addressing #7316 (merged 2026-09-30), which replaced the eBPF proxy with loopback endpoint addressing. We have not checked whether the earlier proxy behaved differently.
• Recent changes: none. Every run used the same images, pinned by digest.

Summary

On Linux with kernel WireGuard, a peer connection can hand over from the relay to a direct IPv6 path. After that handover, peer B can send a WireGuard handshake response with IPv6 source address ::1 out of its real interface. Peer A's kernel discards that packet as a header error: a loopback source on a non-loopback interface (RFC 4291 §2.5.3). So the response never reaches WireGuard.

Our reading of the code:

• After the handover, RedirectAs(ep) keeps injecting packets that still arrive over the relay into the local WireGuard. Each one has the direct endpoint as its source and ::1 as its destination.
• Kernel WireGuard takes a received packet's destination as the source of its replies to that endpoint. So its reply to the direct endpoint carries source ::1.

Current behavior

This comes from one fully captured run (attempt cacad79c, 2026-11-01, 09:33 UTC). Packet numbers are positions in each peer's capture. Peer A is the "member" and peer B the "node" in the linked analysis.

1. The initiation. Peer A's handshake initiation (A#35) arrives over the retained relay. On peer B it is injected as B#186, with peer A's IPv6 endpoint as source and ::1 as destination. The WireGuard message bytes match.
2. The response. Peer B's handshake response B#187 has source ::1, and leaves peer B's underlay interface (eth2).
   • Peer A receives the identical datagram (A#219) on its underlay interface (eth1).
   • It is a type 2 message: WireGuard length 92, UDP length 100, ports 51820.
3. Peer A's nftables trace sees the packet at netdev ingress and accepts it. There is no later inet prerouting or input event for it. Normal IPv6 UDP packets in the same trace do reach those hooks.
4. Peer A's counters (from both /proc/net/snmp6 and nstat -asz):
   • Ip6InHdrErrors goes from 0 to 1 over the request.
   • Ip6InAddrErrors, Udp6InErrors and Udp6InCsumErrors stay at 0.
   • Ip6InDiscards is unchanged.
5. The request itself still succeeded (one SYN, 9 ms), because data was already flowing over the session the relay had established. Neither peer's WireGuard endpoint was seen to become ::1. Peer B's endpoint for peer A became peer A's IPv6 address, port 51820.

The visible signs are the ::1-sourced packet on the wire and the remote peer's IPv6 header-error counter.

Expected behavior

No packet with a loopback source address leaves a non-loopback interface. WireGuard's replies to a peer on the direct path carry a source address that is valid for the outgoing interface, so the remote peer accepts them.

Steps to reproduce

1. Run two Linux peers with kernel WireGuard and NetBird client 0.82.0, each in its own Docker network namespace, against a self-hosted 0.82.0 management/signal/relay.
2. Let the underlay offer the direct path over IPv6 only. The peers then connect through the relay first, and hand over to a direct IPv6 connection. We forced the address family with test filters; this is a diagnostic setup, not a production setting.
3. Start from fresh state, and send traffic during the handover so that a handshake initiation is still arriving over the relay after the direct endpoint is configured.
4. Capture the underlay and loopback interfaces on both peers. Read nstat -az Ip6InHdrErrors on the receiving peer before and after.

For intermittent issues:

• Trigger: a WireGuard handshake initiation arrives over the retained relay after the relay → direct IPv6 handover.
• Frequency:
  • Seen in 1 of 2 traced, IPv6-constrained fresh starts. The other run had no ::1 response within its capture window.
  • Seen once more in a separate run where the peer was removed and re-added (af718646).
  • Our instrumentation affects scheduling, so these counts are not a natural rate.
• Timing: in cacad79c, the ::1 response came 200 ms after data was already flowing over the relay session (09:33:52.903737Z against 09:33:52.703797Z).

Environment and topology

• Peer A: NetBird 0.82.0 client, kernel WireGuard, in a Docker network namespace.
• Peer B: the same, plus our own nftables forwarding rules.
• Both peers run on one Linux host, kernel 7.0.0-38-generic, in separate network namespaces with IPv4 and IPv6 underlay addresses. The direct path was constrained to IPv6 for this diagnostic.
• Other VPN software: none.
• Firewall: peer A had a test-only nftables observation table (trace and counters only), and it accepted the packet. The drop happens after netdev ingress and before IPv6 prerouting.
• Routes, DNS, policies, posture checks, SSH: not involved in the dropped packet.

Self-hosted details, if available

• Deployment method: Docker Compose (a custom test lab).
• Management/signal/relay: 0.82.0, the combined netbird-server image (digest above).
• Reverse proxy and IdP: not involved in the observed packet path.

Logs, status output, or debug evidence

# cacad79c — 2026-11-01, kernel 7.0.0-38-generic, NetBird 0.82.0
peer B #186  src=<peer A IPv6 endpoint>  dst=::1              WireGuard initiation, injected from the relay
peer B #187  src=::1:51820  dst=<peer A IPv6>:51820  out eth2  WireGuard response, WG len 92, UDP len 100
peer A #219  same datagram, received on eth1
             sha256(response) = 8724b1944161f7c962221397e5a8d26534359941b81594157d1289b6f692658d
peer A nft trace: netdev ingress_eth1 -> accept; no inet prerouting/input event follows
peer A nstat: Ip6InHdrErrors 0 -> 1; Ip6InAddrErrors 0, Udp6InErrors 0, Udp6InCsumErrors 0; Ip6InDiscards unchanged
client debug log order on peer B: configure the direct WireGuard endpoint, then redirect packets from the relayed conn

Raw pcaps, nftables traces and debug logs are kept private. The linked analysis has the header-level facts, counters and hashes.

Related issues or discussions

• [client] Replace the eBPF WireGuard proxy with loopback endpoint addressing #7316 introduced loopback endpoint addressing (client/iface/wgproxy/loopback), including the ::1 destination for injected IPv6 packets.
• eBPF WG proxy: injected packets dropped after ICE handover on Kubernetes nodes (EPERM) #7489 is about packets injected around an ICE handover too. But its failure is different: EPERM on injection, with the earlier eBPF proxy, on 0.76–0.78. It is probably not the same bug.

Impact

• Who is affected: Linux peers with kernel WireGuard whose direct path is IPv6, when a handshake arrives over the relay during or after the relay → direct handover.
• What we measured: the response sent on the direct path is lost.
  • In cacad79c the request still succeeded, because an earlier session was carrying traffic.
  • In af718646, the ::1-sourced response (12:50:50.714 UTC) was lost the same way, and both kernel handshakes stayed at 0. A later direct IPv6 exchange with a normal source (12:50:56.181) completed the handshake. The request, with a 5 s deadline, timed out: its first packet reached peer B at 5.671 s. This fits WireGuard's handshake retry after 5 s, but we have not proven that link.
• Workarounds: none verified.
  • NB_DISABLE_KERNEL_WG_PROXY=true selects the UDP proxy. Its raw IPv6 headers also use destination ::1 (client/iface/wgproxy/udp/rawsocket.go), so it probably does not help.
  • NB_WG_KERNEL_DISABLED=true (userspace WireGuard with the bind proxy) should avoid this injection path. We have not tested it.
  • We did not examine the IPv4 path (127.0.0.1).

Additional context

NetBird code (v0.82.0 at 3c00a978; the same lines are unchanged on main at ad8c1cc9):

• loopback/wrapper.go#L27 defines localHostNetIPv6 = net.ParseIP("::1"). NewPacketHeaders uses it as the IPv6 destination, with the redirect endpoint as the source.
• peer/conn.go#L472-L486: when ICE is ready, ConfigureWGEndpoint(ep) runs, then wgProxyRelay.RedirectAs(ep).
• udp/rawsocket.go#L119-L121: the UDP proxy builds the same IPv6 header shape.

Linux code (v7.0 at 028ef9c9):

• wireguard/socket.c#L251: WireGuard stores a received packet's destination as the endpoint's reply source (src6).
• #L133-L135: send6 clears that source only when ipv6_chk_addr() fails. ::1 normally passes, because it is assigned to lo.
• net/ipv6/ip6_input.c#L209-L219: the receiver drops loopback-source packets on non-loopback interfaces before NF_INET_PRE_ROUTING, and counts them in Ip6InHdrErrors (#L295-L296).

This is a reading of the source that is consistent with our counters and traces. We did not capture a kernel drop tracepoint.

A possible direction, for you to judge: once the redirect source is a real remote address, inject relayed IPv6 traffic with a destination WireGuard can validly reply from, instead of ::1. Or otherwise keep ::1 from becoming the reply source.

Our public write-up, with the per-step evidence and hashes:

• the cacad79c analysis;
• the af718646 re-grant run.

[teddashh]

Adding an independent sample of the same symptom from our 2026-11-04 AT01 run (3eb3960d-c411-4648-8d77-bba40b436ae3), examined retrospectively in follow-up 23.

The retained captures show a WireGuard type-2 response with an IPv6 loopback (::1) source:

• Node packet 158 leaves eth2 at 08:22:37.385050Z.
• Member packet 161 arrives on eth1 at 08:22:37.385059Z, with the same IP-packet SHA-256.
• Both decoded packets have 92 bytes of WireGuard payload, UDP length 100, IP length 140, and UDP ports 51820 → 51820. Public records use an anonymized source label identified as IPv6 loopback.
• Over the enclosing counter-read interval, the member's Ip6InHdrErrors increases from 0 to 1, while its WireGuard receive accounting remains zero.

This corrects our earlier inference from the zero WireGuard counter: the response did reach the member's underlay ingress. The evidence locates the remaining gap after member underlay ingress and before WireGuard receive accounting. We have no packet-specific kernel drop trace for this sample; the counter increment does not prove which packet caused it, and these records do not prove the source-selection mechanism.

The retrospective extraction was checked against the original capture byte counts and SHA-256 receipts. The original uncounted outcome is unchanged. Successful initial transfers in a later run do not establish that this issue is fixed.

Evidence, pinned to commit 52b93845b5cfeac1dd63e04c700857fcd098a7f6:

• Decoded packet headers, original capture receipts, counter readbacks, and limits
• Follow-up 23 analysis
• Recorded blocker and limits