iOS: leak-proof kill switch — protect engine sockets so includeAllNetworks doesn't collapse the connection

[VishalDobariya26]

Before posting

• I searched existing discussions and issues for similar requests.
• I checked the documentation to confirm this is not already supported.
• This is a product idea or enhancement request, not a support question.
• I removed or anonymized sensitive details from examples and screenshots.

Product area

Mobile app

Problem or use case

As a developer integrating the NetBird gomobile SDK into an iOS app
(NEPacketTunnelProvider with an exit node advertising 0.0.0.0/0),

I want to offer a leak-proof kill switch — no traffic ever leaves outside the tunnel, including during reconnects.

Because this is impossible on iOS today:

• Route-based full tunnel (0.0.0.0/0 in NEIPv4Settings.includedRoutes) is leak-proof only WHILE connected. When the tunnel drops (e.g. Wi-Fi loss) and On-Demand re-establishes it, traffic egresses over the physical interface during the gap → the real IP leaks.
• iOS's includeAllNetworks would seal that gap, but ~10s after connect the management/relay connection collapses (0 peers, management → Connecting…):
  includeAllNetworks captures the engine's OWN signal/relay sockets and loops them into the tunnel. (Peer was relayed in our tests.)
• We can't work around it with excludedRoutes: the signal server address is not exposed by the SDK, and relay/peer endpoints are runtime-only and change on roaming / ICE renegotiation / relay failover.

Proposed solution

Provide one (or both) on the mobile SDK:

A) Protect the engine's own sockets so they stay OFF the tunnel interface (equivalent to WireGuard-go's protect() / bind-to-interface / socket mark). This makes includeAllNetworks usable directly — no app-side exclusions needed.
Preferred: cleanest and most robust.

B) If A isn't feasible, expose the signal, relay/TURN, and management endpoints currently in use (getters + a change notification), plus a supported way to update the exclusion set without a full tunnel reset, so integrators can maintain excludedRoutes dynamically.

Acceptance: an iOS integrator can enable includeAllNetworks (or an SDK-provided "block non-tunnel traffic" mode) without the control plane collapsing, so no traffic egresses outside the tunnel at any point, including during reconnects.

Alternatives or workarounds considered

• Route-based full tunnel (0.0.0.0/0 in NEIPv4Settings.includedRoutes): leak-proof only while connected; leaks the real IP in the reconnect gap.
• includeAllNetworks = true: seals the gap but collapses the management/relay connection ~10s after connect (captures the engine's own sockets).
• excludedRoutes for NetBird's endpoints: not possible — signal address isn't exposed by the SDK, and relay/peer endpoints are runtime-only and change.
• On-Demand always-connect: reduces the gap but can't eliminate it. None of these give a leak-proof result on iOS.

Community impact and priority

• Number of users/teams/peers affected: any iOS integrator needing a kill switch / leak-proof full tunnel (privacy-focused deployments)
• Deployment type: both (Cloud / self-hosted)
• Frequency: continuous — applies the whole time the iOS client is used with an exit node
• Blocking production adoption? Yes — a true kill switch cannot ship on iOS today, and IP can leak on every reconnect

Examples from other tools or products

Commercial iOS VPNs (NordVPN, Proton VPN, Mullvad) ship leak-proof kill switches by controlling their own WireGuard/IKEv2 stack and using includeAllNetworks while excluding their own server endpoints. WireGuard-go keeps its socket off the tunnel via protect()/bind-to-interface.

Security, privacy, and compatibility considerations

Without this, an iOS user's real IP and DNS can leak during reconnects — a privacy gap for a VPN product. The requested fix (protecting the engine's own sockets) is a standard technique and should be transparent to other platforms and existing behavior.

Implementation ideas

Mirror WireGuard-go's protect() / bind-to-interface / socket-mark so the engine's management, signal, and relay sockets never route over the utun. Alternatively, expose those endpoints via the SDK with a change callback so integrators can maintain excludedRoutes dynamically (without a tunnel reset).

Are you willing to help?

Not at this time.

Additional context

No response