iOS client (self-hosted): shows Connected via relay, inbound traffic works, but the iPhone's own outbound traffic never enters the tunnel

[goofball0687]

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

Mobile app

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

iOS

NetBird version and upgrade status

Management / Dashboard / Signal / Relay: self-hosted docker-compose, images track latest (Watchtower auto-update) — current release line v0.80.0 (published 2026-10-01). macOS client: 0.80.0 (works fine). VPS client: 0.75.1 as of Oct 1. iOS client: 0.4.1 (core ci-cb7ca8ef) on iOS 26.5

Did this work before?

Yes, this worked before

Regression details

Worked until ~2026-10-01. Around that window the server picked up v0.79.0 (2026-09-18) / v0.80.0 (2026-10-01) via Watchtower and the iOS app updated via the App Store, so I can't pin the exact breaking change. Around Oct 2 even the Mac↔VPS leg briefly degraded (relayed → disconnected, then recovered on its own).

Summary

On my self-hosted setup the iOS client displays Connected (via relay) and other peers see it as Connected, but none of the phone's own traffic reaches the mesh. Traffic initiated toward the phone flows fine in both directions at the WireGuard level; the phone's own outbound traffic is never injected into the tunnel. All non-iOS clients are healthy at the same moment, so control plane, signal, and relay are working.

Current behavior

• iPhone peer shows Connected / Relayed on other clients, with fresh WireGuard handshakes but only keepalive-scale transfer counters (KiB).
• Inbound-initiated traffic works: ping Mac → iPhone mesh IP succeeds 5/5, 0% loss, 58–89 ms over relay (measured 2026-10-05). On 2026-10-01 a tcpdump on the server peer's tunnel interface captured ICMP echo request/reply pairs for server-initiated pings (avg RTT 111 ms) — the tunnel is bidirectional for inbound flows.
• The phone's own outbound traffic never enters the tunnel. Loading https://100.108.164.93/ (a peer's mesh IP typed directly into Safari — no DNS involved) times out. In a 240 s tcpdump on the server peer's tunnel interface during that test (2026-10-01), zero packets sourced from the phone's mesh IP were captured.
• The phone never gets a P2P/ICE path — always relay-only, ICE candidate (Local/Remote): -/-, even on home Wi-Fi. Relay latency was ~3 s avg on Oct 1 and ~72 ms on Oct 5.
• DNS is ruled out (raw-IP test), the server is ruled out (Mac↔VPS is a healthy P2P connection, 41 ms, at the same moment the phone is broken).

This looks like the iOS client stops injecting its own outbound traffic into the tunnel after establishing it — consistent with the Network Extension not applying routes/selectors for the phone's own traffic.

Expected behavior

The phone's own traffic (Safari, apps) routes into the NetBird tunnel, and I can reach peers and self-hosted services over the mesh the same way the macOS client can.

Steps to reproduce

1. Self-hosted server (management, signal, dashboard, relay, STUN) behind a single domain; enroll an iOS client.
2. From any other peer, netbird status -d → the iPhone peer shows Status: Connected, Connection type: Relayed, ICE candidate (Local/Remote): -/-.
3. From another peer, ping <iphone mesh IP> → replies (tunnel works inbound).
4. On the iPhone, open https://<server-peer mesh IP>/ directly in Safari → times out.
5. On the server peer, tcpdump the tunnel interface (wt0) filtered on the phone's mesh IP while the phone tries to load → only server-initiated pings appear; nothing from the phone's own browsing.

Environment and topology

Three peers in one self-hosted network:

• iPhone — iOS 26.5, NetBird app 0.4.1 (core ci-cb7ca8ef); the broken client. Relay-only.
• Mac (macOS, client 0.80.0, userspace interface) — healthy; P2P to the VPS peer (41 ms) at the same time the phone is relay-only.
• VPS (Ubuntu) — runs the server stack and a regular client peer; healthy.

Status output from the Mac (2026-10-05, public keys and public IPs redacted):

Peers detail:
 iphone-<redacted>.netbird.selfhosted:
  NetBird IP: 100.108.119.219
  Status: Connected
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  Relay server address: rels://nb.example.com:443
  Last WireGuard handshake: 1 minute, 41 seconds ago
  Transfer status (received/sent) 6.9 KiB/18.8 KiB
  Latency: 0s

 <vps-hostname>.netbird.selfhosted:
  NetBird IP: 100.108.164.93
  Status: Connected
  Connection type: P2P
  ICE candidate (Local/Remote): srflx/host
  Last WireGuard handshake: 45 seconds ago
  Transfer status (received/sent) 32.2 MiB/7.5 MiB
  Latency: 41.266625ms

Daemon version: 0.80.0
CLI version: 0.80.0
Management: Connected to https://nb.example.com:443
Signal: Connected to https://nb.example.com:443
Relays:
  [stun:nb.example.com:3478] is Available
  [rels://nb.example.com:443] is Available via ws
Lazy connection: false
Peers count: 2/2 Connected

(Mesh IPs are 100.108.0.0/16 CGNAT addresses internal to the mesh; I kept them because the raw-IP repro depends on them.)

Self-hosted details, if available

• Management, signal, dashboard, relay (rels://…:443 via WebSocket), and STUN (stun:…:3478) all on one domain behind TLS.
• All server images track latest with Watchtower; exact container versions are not readable from my clients — happy to pull them from the host on request.

Logs, status output, or debug evidence

`netbird status -dA` from the Mac client (2026-10-06). The CLI's `-A` flag anonymizes public IPs, MAC addresses, and non-netbird.io domains on its own; peer FQDNs, WireGuard public keys, and the domain spelling are additionally redacted here. Repetitive INFO events and unrelated footer fields omitted.


Peers detail:
 iphone-<redacted>.netbird.selfhosted:
  NetBird IP: 100.108.119.219
  NetBird IPv6: 2001:db8:ffff::
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://nb.example.com:443
  Last connection update: 52 minutes, 4 seconds ago
  Last WireGuard handshake: 1 minute, 31 seconds ago
  Transfer status (received/sent) 8.1 KiB/5.8 KiB
  Quantum resistance: false
  Networks: -
  Latency: 0s

 <vps-hostname>.netbird.selfhosted:
  NetBird IP: 100.108.164.93
  NetBird IPv6: 2001:db8:ffff::1
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): host/srflx
  ICE candidate endpoints (Local/Remote): 172.20.10.2:51820/198.51.100.0:51820
  Relay server address: rels://nb.example.com:443
  Last connection update: 47 minutes, 10 seconds ago
  Last WireGuard handshake: 37 seconds ago
  Transfer status (received/sent) 8.8 MiB/1.1 MiB
  Quantum resistance: false
  Networks: -
  Latency: 174.209375ms

OS: darwin/arm64
Daemon version: 0.80.0
CLI version: 0.80.0
Management: Connected to https://nb.example.com:443
Signal: Connected to https://nb.example.com:443
Relays:
  [stun:nb.example.com:3478] is Available
  [rels://nb.example.com:443] is Available via ws
NetBird IP: 100.108.93.125/16
NetBird IPv6: 2001:db8:ffff::2/64
Interface type: Userspace
Wireguard port: 51820
Lazy connection: false
Peers count: 2/2 Connected

Packet-level evidence (2026-10-01, tcpdump on the server peer's wt0): server-initiated pings to the phone appear as request/reply pairs (avg RTT 111 ms); during a 240 s window in which the phone tried to load the server peer's raw mesh IP in Safari, zero packets sourced from the phone's mesh IP were captured. Details under Current behavior.

Debug bundle: created with netbird debug for 1m -AS -U on the Mac (2026-10-06, anonymized by the -A flag) and uploaded — upload file key:

ae643d015d986eed4241de65bb627df839d9f58d3ff399eac1d7ea57f0cd34de/18d030b9-32a0-4c40-b6c0-9878a35c775a

The trace window includes a 20-ping Mac→iPhone sequence over the relayed connection (0% loss, avg 111 ms). iOS app logs can be exported from the app if needed.

(Mesh IPs are 100.108.0.0/16 CGNAT addresses internal to the mesh; kept because the raw-IP repro depends on them. The ICE endpoint IPs above are already anonymized by the CLI.

Related issues or discussions

• iOS client remains connected but DNS and all tunnel traffic stop until reconnect #7299 — iOS client remains connected but DNS and all tunnel traffic stop until reconnect
• iOS client: WireGuard handshake succeeds but no data plane traffic, SSH connections time out #7666 — iOS client: WireGuard handshake succeeds but no data plane traffic
• Unable to connect to self hosted netbird with iOS client after the update - 0.3.2 #6889 — Unable to connect to self hosted netbird with iOS client after the update (a commenter on Oct 4 reports the same version pair — iOS client 0.4.1, management v0.80.0 — failing on self-hosted)
• iOS app: Connection fails in restrictive networks after latest app update #6088 — iOS app: connection fails in restrictive networks after latest app update
• Can't connect to my self hosted NetBird with iOS client ios-client#22 — Can't connect to my self hosted NetBird with iOS client

This report adds packet-capture evidence that the failure is one-directional: inbound-initiated traffic traverses the tunnel fine, the phone's own outbound is never injected.

Impact

The iPhone is unusable as a NetBird client — no self-hosted service is reachable from it — while the same network works for macOS/Linux. Currently reproducible on demand.

Additional context

Happy to run further captures or export iOS client logs if useful.

[idrivehtbusiness]

The packet captures are the most useful part of this report. Since Mac → iPhone traffic works and the phone replies, I wouldn't start by troubleshooting STUN or the relay. That path is clearly doing at least some work.

I'd try to isolate where a connection initiated on iOS disappears.

First, use a known working service for the outbound test. The Safari test against https://100.108.164.93/ is useful, but I'd confirm that the VPS is actually listening on port 443 and that the same mesh-IP endpoint is reachable from the Mac. Otherwise, an HTTPS or service-level failure could complicate the diagnosis.

Then I'd run three tests:

1. Connect the iPhone to NetBird and initiate a connection to that verified service while capturing traffic on the VPS tunnel interface.
2. Repeat after disconnecting and reconnecting the iOS VPN, without changing the server configuration.
3. Repeat once on Wi-Fi and once on cellular data, ideally with other VPN or network-filtering configurations temporarily disabled.

If fresh iPhone-originated packets are still absent, I'd look at the iOS Network Extension configuration next: specifically whether the active packet tunnel has a route covering 100.108.164.93, and whether any excluded routes or another VPN configuration are taking precedence.

There's also an important distinction between accepting return traffic and allowing new outbound connections. A stateful access policy could allow replies to Mac-initiated traffic while blocking new sessions from the phone. So I'd verify the direction of the applicable NetBird policies before concluding it's definitely an iOS routing bug.

Given the regression window, I'd also pin the exact server image versions rather than latest, then compare the iOS extension logs from a working inbound test and a failing outbound test. I wouldn't downgrade anything until the evidence points to a specific version.

The two results I'd be most interested in are:

• Does the iOS tunnel configuration include the peer's mesh IP?
• During the outbound attempt, do the phone's WireGuard transfer counters increase beyond normal keepalive traffic?

Those should help separate route installation, policy enforcement, and packet processing without rebuilding the entire self-hosted setup.

[goofball0687]

Thanks @idrivehtbusiness. I ran the check from the Mac side, with the Mac as the receiving peer.

With phone on wifi, I ran netbird status -d | grep -A12 iphone-koen on the Mac while trying to reach the Mac and the VPS from the phone by mesh IP for about 20 s. Safari and a ping app both gave nothing.

Status: Connected
Connection type: Relayed
Last WireGuard handshake: 45 seconds ago
Transfer status (received/sent) 212 B/156 B

The counters had just reset because the connection was re-established. The totals are exactly one handshake plus two keepalives in each direction:

• received 212 B = 148 (initiation) + 2 × 32 (keepalive)
• sent 156 B = 92 (response) + 2 × 32 (keepalive)

So the tunnel is up, but no payload from the phone reaches the Mac while it tries to connect. A policy drop would still show in these counters, because the Mac counts the packets before the firewall acts. That makes access policy unlikely.

What works: the Mac's and VPS's own clients work normally (the VPS is P2P, 33 MiB transferred). Peers and mesh IPs show up correctly in the iOS app. Inbound pings to the phone work over the relay (58–89 ms) and the phone replies.

What I tried:

• Toggling the VPN off and on
• Removing the VPN profile in iOS settings and re-adding it
• Wi-Fi vs cellular, other VPNs off
• Reinstalling the app

This looks like the iOS client not sending app traffic into the tunnel, rather than a server problem.

[idrivehtbusiness]

Thanks for checking all of that. The handshake and keepalive-only counters are useful, especially alongside the successful inbound ping tests.

I agree that this shifts the investigation away from the relay and server-side policy configuration.

At this point, I’d focus on the iOS packet tunnel itself. The remaining question is whether iOS is routing locally initiated traffic into the Network Extension, or whether the extension receives those packets but fails to process them.

Could you export the NetBird iOS app logs immediately after reproducing the failure? It would be particularly useful to look for route installation errors, tunnel configuration updates, or packet-processing failures.

I wouldn’t change the server configuration or downgrade anything yet. The next useful step is to establish where the outbound packets disappear, ideally with input from the iOS client maintainers.

[goofball0687]

How would I do that?

I have uploaded a debug bundle: ae643d015d986eed4241de65bb627df839d9f58d3ff399eac1d7ea57f0cd34de/2abe10aa-9d4e-4464-8a3c-1d66d2f42675.

Console logs don't show much useful things.

[idrivehtbusiness]

Thanks for the update. Since you've already uploaded a debug bundle, there's no need to repeat that step yet.

The next useful check would be the iOS Network Extension logs.

If you have access to a Mac, you can connect your iPhone, open Console.app, select the device, and start capturing logs while reproducing the issue. Try filtering for NetBird, PacketTunnel, and NetworkExtension.

It would also help to know whether the debug bundle contains any tunnel configuration or routing errors around the time of the failed outbound connection.

If the logs still show nothing useful, I think the NetBird iOS maintainers would be best placed to inspect the debug bundle and determine whether packets are reaching the tunnel extension.

Please remove any sensitive information before sharing additional logs.

[lisarconnect-admin]

@goofball0687 NetBird’s iOS guide says to open the app and use Settings → Troubleshoot to collect a debug bundle: https://docs.netbird.io/help/troubleshooting-client/ios

If the bundle you already uploaded came from that screen on the affected iPhone, you have already completed that collection step; clarify that for the maintainers. If it came from another device, collect the iPhone bundle after reproducing the failure. Keep the bundle in NetBird’s support workflow rather than pasting its contents publicly.

AI-assisted reply; I work on Lisar Connect.

[goofball0687]

As I said: I have uploaded a debug bundle

[lisarconnect-admin]

Understood—sorry for asking you to clarify a step you'd already completed. No need to upload another bundle on my account; I don't have access to inspect the one you submitted.