[GH-ISSUE #6258] macOS: ICE P2P endpoint update overwrites subnet route AllowedIPs (v0.71.4) #12953

Open
opened 2026-08-05 02:07:05 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @yusoofsh on GitHub (May 25, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/6258

Bug Report

Version: 0.71.4 (daemon + CLI)
OS: macOS darwin/arm64
Interface type: Userspace (utun100)

Description

When a subnet route (10.20.0.0/16) is advertised by a gateway peer, the client correctly adds the route to WireGuard AllowedIPs momentarily, but then the ICE P2P endpoint selection overwrites AllowedIPs back to only the peer IP, dropping the subnet route.

Steps to Reproduce

  1. Configure a subnet route (e.g. 10.20.0.0/16) via a gateway peer in Netbird management
  2. Connect client on macOS with netbird up
  3. Observe WireGuard AllowedIPs via wg show utun100 allowed-ips

Expected Behavior

<gateway-pubkey>    100.124.153.211/32 10.20.0.0/16

Actual Behavior

<gateway-pubkey>    100.124.153.211/32

Client Log Evidence

Route is added correctly, then immediately overwritten by ICE endpoint update:

DEBG client/iface/iface.go:196: Adding allowed IP to interface utun100 and peer <pubkey>: allowed IP 10.20.0.0/16
...
DEBG client/iface/iface.go:161: updating interface utun100 peer <pubkey>, endpoint 16.78.6.223:49094, allowedIPs [100.124.153.211/32]

The iface.go:161 call (triggered by ICE P2P candidate selection) sets AllowedIPs without merging existing route AllowedIPs — it replaces with only the peer IP.

Impact

Subnet routing completely broken on macOS userspace mode. Traffic to routed subnet (10.20.0.0/16) is silently dropped by WireGuard because the subnet is not in AllowedIPs.

Workaround

Manually run after connect:

sudo wg set utun100 peer <gateway-pubkey> allowed-ips 100.124.153.211/32,10.20.0.0/16

This gets overwritten again on next ICE update.

Originally created by @yusoofsh on GitHub (May 25, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/6258 ## Bug Report **Version:** 0.71.4 (daemon + CLI) **OS:** macOS darwin/arm64 **Interface type:** Userspace (utun100) ### Description When a subnet route (10.20.0.0/16) is advertised by a gateway peer, the client correctly adds the route to WireGuard AllowedIPs momentarily, but then the ICE P2P endpoint selection overwrites AllowedIPs back to only the peer IP, dropping the subnet route. ### Steps to Reproduce 1. Configure a subnet route (e.g. 10.20.0.0/16) via a gateway peer in Netbird management 2. Connect client on macOS with `netbird up` 3. Observe WireGuard AllowedIPs via `wg show utun100 allowed-ips` ### Expected Behavior ``` <gateway-pubkey> 100.124.153.211/32 10.20.0.0/16 ``` ### Actual Behavior ``` <gateway-pubkey> 100.124.153.211/32 ``` ### Client Log Evidence Route is added correctly, then immediately overwritten by ICE endpoint update: ``` DEBG client/iface/iface.go:196: Adding allowed IP to interface utun100 and peer <pubkey>: allowed IP 10.20.0.0/16 ... DEBG client/iface/iface.go:161: updating interface utun100 peer <pubkey>, endpoint 16.78.6.223:49094, allowedIPs [100.124.153.211/32] ``` The `iface.go:161` call (triggered by ICE P2P candidate selection) sets AllowedIPs without merging existing route AllowedIPs — it replaces with only the peer IP. ### Impact Subnet routing completely broken on macOS userspace mode. Traffic to routed subnet (10.20.0.0/16) is silently dropped by WireGuard because the subnet is not in AllowedIPs. ### Workaround Manually run after connect: ```bash sudo wg set utun100 peer <gateway-pubkey> allowed-ips 100.124.153.211/32,10.20.0.0/16 ``` This gets overwritten again on next ICE update.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#12953