iOS app: Connection fails in restrictive networks after latest app update

[kallegruebner-a11y]

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

NetBird Cloud

Operating system or environment

iOS

NetBird version and upgrade status

Client (iOS): 0.70.4
• Management: NetBird Cloud (api.netbird.io)

Did this work before?

Yes, this worked before

Regression details

•	Last known working version: previous iOS app version (before latest update)
•	First known broken version: 0.70.4
•	Recent changes: Updated the Netbird iOS app

Summary

After updating the iOS app to 0.70.4, connection fails in restrictive WiFi networks. The app cycles through Connecting → Connected → Disconnected with no error message. A friend using the previous version of the app can still connect on the same network, confirming this is a regression.

Current behavior

App shows Connecting → Connected → Disconnected repeatedly. 0 of 0 peers shown. No error message displayed. Force Relay is enabled but does not help.

Expected behavior

Successful connection via relay, as it worked before the update

Steps to reproduce

1. Update Netbird iOS app to 0.70.4
   2. Connect to restrictive WiFi (UDP blocked, only HTTPS allowed)
   3. Open Netbird app and try to connect
   4. Observe: cycles Connecting → Connected → Disconnected, no peers shown

Environment and topology

• Peer A: iPad (iPadOS 26.3.1, Netbird 0.70.4)
• Peer B: Ubuntu 24.04 LXC (Netbird 0.67.1)
• Different networks
• Restrictive school WiFi: UDP blocked, HTTPS (443) reachable (api.netbird.io returns 404 as expected)
• Force Relay: enabled

Self-hosted details, if available

N/A

Logs, status output, or debug evidence

N/A

Related issues or discussions

N/A

Impact

Multiple users affected (confirmed by friend on old version still connecting on same network)
• Workaround: mobile hotspot

Additional context

N/A

[jnfrati]

Hey @kallegruebner-a11y could you provide some debug logs into this? From Settings > Advanced > Trace logs
If you can enable that option, disconnect / connect again the client and try to join the wifi network that's causing issues it would give us visibility over the issue. Thanks!

Just make sure to anonymize the logs before posting them 💪

[kallegruebner-a11y]

netbird-engine.log
netbird-app.log

[jnfrati]

Thanks! Going to take a look

[kallegruebner-a11y]

I tried setting up a self-hosted Netbird server with a custom relay on port 8443 to work around my school network restrictions (only ports 443 and 8443 outbound are open). My school network blocks UDP and most ports.
The self-hosted management server runs behind a Caddy reverse proxy on port 443. The relay is configured on port 8443. However, the connection still doesn’t work in the school network — it’s unclear whether port 8443 is also blocked, or whether the app first needs to reach the management server on port 443 which may be blocked for unknown domains in my school network.
The original bug: Netbird iOS app 0.70.4 broke connectivity in restrictive networks that only allow ports 443 and 8443.​​​​​​​​​​​​​​​​

[siam-niam]

Android v0.70.4 — Same relay instability on restrictive WiFi (self-hosted)

Adding Android data points to this discussion. I'm seeing the same behaviour described in the iOS report — relay connections fail on restrictive networks but work fine on mobile data.

Environment

Component	Version
Android client	v0.70.4 (custom build from source)
Management/Signal/Relay	v0.70.4 combined container (self-hosted)
pfSense peer	v0.70.5
Relay transport	WebSocket via rels://<SERVER>:443 (HAProxy TLS termination)
Rosenpass	Enabled (quantum resistance confirmed working)

Symptoms

• WiFi (restrictive network): Relay WebSocket connects successfully but gets forcibly terminated. WireGuard handshake times out repeatedly. Out of ~60+ handshake attempts over 1.5 hours, only 1 succeeded briefly (0.21s) before being killed again.
• Mobile data (3G hotspot): Same device, same app, same server — relay connects and WireGuard handshake completes in ~3 seconds. Connection stays stable.

Timeline (from ADB logcat)

WiFi (10.71.x.x network):
11:23:39 — All connections aborted: "read tcp <LOCAL>:45068-><SERVER>:443: software caused connection abort"
11:23:39 — Relay read loop exit, failed to read frame header
11:23:41 — Relay guard attempts reconnect
11:23:42 — Successfully dialed via WS (race dialer)
11:23:43 — "relay connection established" ← TCP connects fine!
11:23:43 — WireGuard proxy setup, waiting for handshake...
11:25:13 — WireGuard handshake timed out (relay was alive but WG packets didn't traverse)
         ... cycle repeats for ~90 minutes ...
12:01:01 — ONE brief WG handshake success (0.21s) then immediately lost
12:14:42 — Relay disconnect (EOF)
12:49:20 — Still cycling connect/timeout/disconnect

3G hotspot (same device, switched network):
12:55:21 — Relay connection established, peer available
12:55:21 — "Relay connection has been established, setup the WireGuard"
12:55:21 — Rosenpass key exchange initiated
12:55:24 — "first wg handshake detected within: 2.95sec" ← SUCCESS
12:55:24 — Both peers connected, stable from this point

Key log excerpts

WiFi — Relay aborted by network (the initial kill):

[DEBG] shared/management/client/grpc.go:475 disconnected from Management Service
  sync stream: rpc error: code = Unavailable desc = error reading from server:
  read tcp <LOCAL>:45068-><SERVER>:443: read: software caused connection abort

[INFO] shared/relay/client/client.go:407 start to Relay read loop exit
[ERRO] shared/relay/client/client.go:410 failed to read message from relay server:
  failed to get reader: failed to read frame header:
  read tcp <LOCAL>:45072-><SERVER>:443: read: software caused connection abort

[INFO] shared/relay/client/client.go:647 closing all peer connections
[INFO] shared/relay/client/client.go:657 relay connection closed

WiFi — Relay reconnects but WG handshake never completes:

[INFO] shared/relay/client/guard.go:88 try to reconnect to Relay server: rels://<SERVER>:443
[INFO] shared/relay/client/dialer/race_dialer.go:66 dialing Relay server via quic
[INFO] shared/relay/client/dialer/race_dialer.go:66 dialing Relay server via WS
[INFO] shared/relay/client/dialer/race_dialer.go:91 successfully dialed via: WS
[INFO] shared/relay/client/client.go:222 relay connection established
[INFO] client/internal/peer/guard/sr_watcher.go:107 reconnected to Signal or Relay server

  ... 28 seconds later ...

[TRAC] client/internal/peer/wg_watcher.go:147 WireGuard handshake timed out: 0001-01-01 00:00:00 +0000 UTC
[DEBG] client/internal/peer/conn.go:622 WireGuard handshake timeout detected, closing current connection

3G — Same relay, handshake succeeds immediately:

[INFO] shared/relay/client/client.go:293 remote peer is available: sha-<HASH>
[DEBG] client/internal/peer/worker_relay.go:85 peer conn opened via Relay: rels://<SERVER>:443
[DEBG] client/internal/peer/conn.go:507 Relay connection has been established, setup the WireGuard
[DEBG] client/internal/peer/conn.go:773 setup proxied WireGuard connection
[DEBG] client/internal/peer/endpoint.go:87 configure up WireGuard and wait for handshake
[DEBG] client/internal/rosenpass/manager.go:232 received remote rosenpass key <KEY>

[INFO] client/internal/peer/wg_watcher.go:109 first wg handshake detected within: 3.73sec
[TRAC] peer connection metrics [selfhosted, relay, reconnection]:
  signaling→connection: 0.116s, connection→wg_handshake: 3.729s, total: 3.844s

Analysis

1. The relay TCP connection itself establishes fine on WiFi — this is NOT a TLS certificate or handshake issue
2. The network kills long-lived WebSocket connections — "software caused connection abort" indicates active RST injection (likely DPI or an idle-timeout firewall rule)
3. Even when relay reconnects, UDP-over-relay (WireGuard) packets don't traverse — suggesting the middlebox may also be interfering with the WebSocket payload (deep packet inspection of framed data?)
4. Identical setup on 3G bypasses the middlebox and works immediately
5. The one brief WiFi success (0.21s handshake at 12:01) suggests the network interference is intermittent/threshold-based rather than an absolute block

Suggestion

The relay reconnection logic works correctly (guard.go reconnects within 2 seconds). The issue appears to be that:

• The WiFi network's DPI/firewall kills WebSocket connections that carry non-HTTP-looking payloads
• A possible mitigation could be WebSocket ping/pong keepalives at a shorter interval, or payload obfuscation

This matches the iOS report — the underlying issue is network-level interference with relay WebSocket connections, not a client bug per se. But the client could potentially be more resilient to these environments.

Device info

• Samsung Galaxy (Android), WiFi on a corporate/ISP-managed network
• Same device works immediately on mobile data
• Self-hosted infrastructure (management + relay on same server behind HAProxy)