iOS client: WireGuard handshake succeeds but no data plane traffic, SSH connections time out

[MaverickMUC]

Environment

• Self-hosted NetBird (netbird-server:latest container, combined Management+Signal+Relay+STUN)
• Server-side client/CLI daemon version: 0.77.1
• iOS app: latest version available from the App Store as of 2026-08-23 (exact version number not visible in the app UI)
• Target: SSH (a non-default SSH port) from iPhone to a self-hosted Linux peer, both via WiFi and cellular

Symptom

SSH connection attempts from the iPhone peer to another peer's NetBird IP consistently time out (Operation timed out / Connection to port <port> on <NetBird IP> timed out), even though:

• netbird status --detail on the target peer shows the iPhone peer as Status: Connected
• Last WireGuard handshake refreshes to a few seconds old on each attempt
• Connection type shown is Relayed via our own self-hosted relay (rels://...)

However, the Transfer status (received/sent) counter for that peer never exceeds a few hundred bytes (roughly 300-500 B each direction) regardless of how many connection attempts are made or how long the peer stays "connected" — consistent with only handshake/keepalive traffic, no actual TCP payload ever passing through the tunnel.

Steps taken / things ruled out

1. Server-side firewall (nftables) ACL — verified the iPhone peer's current NetBird IP is present in the corresponding netbird-acl-input-rules allow-set; traffic from that peer is not being dropped by the host's own NetBird ACL chains.
2. Reverse proxy / WAF (unrelated appliance in front of other HTTP services) — confirmed this only inspects traffic on the physical/public interface via ports 80/443, and has no visibility into or effect on the NetBird overlay interface (wt0) at all.
3. Wrong target/port — confirmed via the SSH client's own connection log that each attempt targets the correct overlay IP and the correct SSH port directly (not a decoy/tarpit port on the public interface).
4. Stale credentials / cached bad peer state — fully deleted the iPhone's peer registration via the Management API and re-enrolled the device from scratch (fresh keypair via SSO login). The exact same symptom (successful handshake, ~300-500 B total transfer, SSH still times out) reproduced immediately after re-enrollment.
5. Server-side relay logs — reviewed netbird-server container logs during multiple connection attempts; no errors or drops specific to this peer, only periodic reconnect/keepalive cycling consistent with normal relay session renewal.
6. Occurs on both WiFi and cellular networks on the iPhone.
7. A separate, unrelated SSH client app on the iPhone also used to connect to the same host over a different, unrelated VPN product (WireGuard-based mesh) has intermittently shown similar sporadic timeout behavior in the past — but that predates this NetBird setup entirely and is being treated as a separate, unconfirmed data point, not a cause.

What would help

• Any pointer on how to get a client-side (iOS) debug bundle to land on our own self-hosted server instead of upload.debug.netbird.io — the app's "Upload debug bundle" feature currently appears to only support NetBird's own cloud endpoint, which isn't usable for a self-hosted-only setup that wants to avoid sending IP/domain/key data to a third party.
• Any known diagnostic step to confirm whether packets are actually being injected into/read from the iOS app's tunnel interface, to narrow down whether this is a control-plane-only vs. data-plane issue on the client side.

Happy to provide more logs/detail if useful.

[linear-code[bot]]

NET-1525

[MaverickMUC]

Update: as a workaround, we tried switching to a self-hosted Headscale server instead (same official Tailscale apps, different control server). SSH connectivity worked flawlessly there — the same symptom described above (successful handshake, no actual data plane traffic) did not occur at all with Headscale, which points fairly strongly at this being specific to NetBird's client/data-plane implementation on iOS rather than an environment issue on our end.

However, we ended up having to revert back to the original, proprietary Tailscale (tailscale.com-hosted) control server anyway, because Headscale currently doesn't support Tailscale Funnel, which we rely on for remote access to a self-hosted service. So for now we're stuck back on standard Tailscale, since neither of the self-hosted alternatives we tried (NetBird due to this issue, Headscale due to missing Funnel support) fully covers our use case yet.

[YSzEthan]

Same symptom here, on NetBird Cloud rather than self-hosted, and reproducing on P2P as well as relayed — so this does not look relay-specific.

I have packet-level captures that I think answer your last question directly:

Any known diagnostic step to confirm whether packets are actually being injected into/read from the iOS app's tunnel interface, to narrow down whether this is a control-plane-only vs. data-plane issue on the client side.

It is client-side, and it is data-plane-only. The iOS client never emits a data packet.

Setup

iOS app	0.3.3
Peer under test	NetBird 0.77.0 (daemon + CLI), macOS 15.7.4, Apple M4
Deployment	NetBird Cloud
Interface type	Userspace

The measurement

A single 30-second capture, taken on both the physical interface and the WireGuard interface simultaneously, while continuously reloading http://<peer-overlay-ip>:3000 from Safari on the iPhone.

During that same window a macOS control peer happened to be transferring. That peer is behind the same NAT and presents the same public IP as the iPhone, differing only in source port — so NAT traversal conditions are identical for both.

tcpdump -i en1 -n 'udp port 51820', split by remote port:

Peer	Remote port	Packets in 30 s	Packet sizes
macOS control peer	1196	8289	4879 x 1312 B, plus a spread of 1040-1296 B
iPhone	3490	86	42 x 184 B, 42 x 136 B, 2 x 32 B — nothing larger than 184 B

tcpdump -i utun100 -n over the same 30 seconds, counted by peer overlay IP:

8204  <this peer's own overlay ip>
8191  <macos control peer>
  13  <third peer>
   0  <iphone>          <-- iPhone

The iPhone's 86 frames arrive at a fixed cadence and are all keepalive/handshake sized. No data-sized frame is ever produced, despite continuous user-driven requests throughout the window. The control peer pushed 4879 full-MTU frames over the same interface, through the same NAT, at the same time, and all of them decrypted and were delivered.

This matches your Transfer status observation of 300-500 B, and localises it: the frames are leaving the phone, but they are only keepalives. Nothing is being injected into the tunnel on the iOS side.

The receiving peer is not dropping anything

netbird debug trace in <iphone-overlay-ip> self -p tcp --dport 3000 --syn:

Routing: Packet destined for local delivery
Peer ACL: Allowed by peer ACL rules (<rule id>)
Final disposition: ALLOWED

The identical trace for the working control peer returns the same verdict under the same rule. Local services are confirmed healthy independently — sshd completes SSH negotiation over LAN, iperf3 -s does 37.6 Gbits/sec on loopback with net.inet6.ip6.v6only: 0, and the macOS application firewall is off.

Reproduced across every combination tested

Variable	Values tried	Result
Connection type	Relayed, P2P	identical
IP version	IPv6 ULA (host/host), IPv4 LAN (host/host), IPv4 public (srflx/prflx)	identical
Network	Home WiFi, 4G cellular	identical
Peer identity	Original peer, fully de-registered and re-registered (new IP, new public key)	identical
Force relay connection	On, Off	identical
Rosenpass	Off on both ends	identical

Two notes that may be useful to whoever picks this up:

• While "Force relay connection" was on (it is on by default, see Default Force Relay to Off #5589), ICE candidate stayed -/- and the connection was permanently Relayed. Turning it off let ICE run and P2P was negotiated successfully, with plausible latency reported. The data plane was dead either way — so the ICE/relay layer is a red herring for this bug.
• "Disable IPv6" in the iOS Advanced settings did not affect ICE candidate selection, consistent with the CLI flag description (Disable IPv6 overlay) — it appears to govern the overlay address only, not ICE transport.

Debug bundle

Since I am on Cloud, I could upload one — this may cover the gap you hit with self-hosting. Generated with trace logs enabled and anonymisation on, immediately after a reproduction:

f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/f2407c42-a483-44a6-9f89-e44bf6ee9cd1

Happy to re-run any capture on request.

[thomashacker]

Thanks for the writeup, we'll look into it as soon as possible 🚀

NetBird has moved to a discussion first model, explained in #6074. Issues are
opened once something has been validated, so I'm closing this and converting it
to a discussion, body and comments carry over.