UDM Pro Preventing NetBird P2P Connections Across Firewall?

Hi Tom @LTS_Tom

I was watching Talking Heads Ep. 439 last night and heard you talking with Jeff about testing NetBird and Tailscale. I’ve been banging my head against the wall with this for a few weeks now and haven’t made any headway. I was wondering if you had any insight, or if you might be able to test something similar.

My setup is a UDM Pro as my firewall, sitting behind an AT&T BGW320 that is configured in IP Passthrough mode. I have AT&T Fiber with a dynamic public IP (not behind CGNAT). I’m self-hosting a NetBird server behind a Traefik reverse proxy, with ports 80, 443, and 3478 forwarded to the server.

On my home network (behind the UDM) I have:

  • TrueNAS server
  • Plex server

Outside my network I have:

  • iPhone
  • MacBook
  • My parents’ Windows laptops

Here’s the behavior I’m seeing:

  • Any two devices that are both outside the UDM establish a P2P connection.
  • Any two devices that are both inside the UDM also establish a P2P connection.
  • But the moment the connection has to traverse the UDM (inside ↔ outside), it always falls back to a relayed connection.

For example, if my MacBook is outside my network, it gets a P2P connection to my iPhone. If I bring the MacBook inside my network, it immediately gets P2P connections to my TrueNAS and Plex server, but it can no longer establish P2P with the external devices—it falls back to relayed. As soon as I take the MacBook back outside, P2P to the external devices works again.

That’s what has me convinced the UDM is somehow the common denominator.

I’ve already tried:

  • Disabling IPS/IDS completely.
  • Leaving IPS/IDS enabled but unchecking all of the peer-to-peer related detections.
  • Enabling UPnP.
  • Confirming that I’m not behind CGNAT.
  • Verifying that the BGW320 is in IP Passthrough mode.

None of those changed the behavior.

I’ve also considered moving my NetBird server to a VPS just to rule out whether the issue is related to the server and the internal clients sharing the same public IP address. I haven’t tried that yet because it feels like P2P should still work in this scenario.

Since the BGW320 is just passing the public IP through to the UDM, I wouldn’t expect it to be interfering, which is another reason I’m leaning toward the UDM.

Have you run into anything like this before, or do you have any ideas what the UDM could be doing that would prevent direct P2P connections only when traffic has to cross the firewall? I’m hoping I’m just overlooking a setting somewhere, but at this point I’m running out of ideas.

Are you sure you have all the external ports opened and port forwarded to the Netbird server?

Do the logs in the UDM show any blocks for that traffic?

Yes I am sure the ports are mapped according to the self hosted port requirements.
Advanced guide - NetBird Docs . The Doc says I need 80, 443, 3478

And the UDM logs from today does not show any blocks for the netbird devices. I have connect/disconnected my iPhone a dozen times, The phone is on cellular so external to my network. Here is the output from netbird status -d on the internal routing peer. the iphone and dt-10 are external to the network

root@netbird:/# netbird status -d
Peers detail:
iphone-cpbpilot-16-131.netbird.selfhosted:
NetBird IP: 100.86.16.131
Public key: wSuymzrVnZibkU5wLwHiHYVyR9I17hOWyJ0zpnskekI=
Status: Connected
– detail –
Connection type: Relayed
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address: rels://netbird.mydomain.io:443
Last connection update: 14 seconds ago
Last WireGuard handshake: 14 seconds ago
Transfer status (received/sent) 180 B/124 B
Quantum resistance: false
Networks: -
Latency: 0s

dt-10.netbird.selfhosted:
NetBird IP: 100.86.61.47
Public key: F7iv33uhYpvQY2ggbaRTkjYeCR+nSW/6Sx3RKIIiVjE=
Status: Connected
– detail –
Connection type: Relayed
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address: rels://netbird.mydomain.io:443
Last connection update: 17 hours, 8 minutes ago
Last WireGuard handshake: 1 minute, 35 seconds ago
Transfer status (received/sent) 26.2 MiB/53.3 MiB
Quantum resistance: false
Networks: -
Latency: 0s

connors-macbook-pro.netbird.selfhosted:
NetBird IP: 100.86.80.136
Public key: 4OYdsWpLEYLtnXoB7JPxgZ92bpudnqN/c5hdSveSxFg=
Status: Connecting
– detail –
Connection type: -
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address:
Last connection update: 18 hours, 47 minutes ago
Last WireGuard handshake: -
Transfer status (received/sent) 0 B/0 B
Quantum resistance: false
Networks: -
Latency: 0s

truenas-scale.netbird.selfhosted:
NetBird IP: 100.86.157.180
Public key: DIW24Z8UJ8h02+ChxGmgFCsBg30DZRXMRXePdoQ/5XE=
Status: Connected
– detail –
Connection type: P2P
ICE candidate (Local/Remote): host/host
ICE candidate endpoints (Local/Remote): 10.11.10.84:51820/10.11.10.135:51820
Relay server address: rels://netbird.mydomain.io:443
Last connection update: 18 hours, 29 minutes ago
Last WireGuard handshake: 3 seconds ago
Transfer status (received/sent) 98.8 KiB/364.7 KiB
Quantum resistance: false
Networks: -
Latency: 669.602µs

iphone-cpbpilot-191-14.netbird.selfhosted:
NetBird IP: 100.86.191.14
Public key: U6+uJ8dY5MbWLU8L4S+w4O4oOu+z18YIvwYRYzy+tRc=
Status: Connecting
– detail –
Connection type: -
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address:
Last connection update: 1 day, 14 hours ago
Last WireGuard handshake: -
Transfer status (received/sent) 0 B/0 B
Quantum resistance: false
Networks: -
Latency: 0s

Events:
[INFO] SYSTEM (71572a7d-814a-4d40-9b92-95c7178d50f2)
Message: daemon config changed (source=startup)
Time: 1 day, 14 hours ago
Metadata: source: startup, type: config_changed
[INFO] SYSTEM (d3a1a526-e779-4e76-aadb-6d92c05a2d9e)
Message: Network map updated
Time: 1 day, 14 hours ago
[INFO] SYSTEM (a813b1b2-f589-40ce-bd1a-8dd30f96ce7d)
Message: Network map updated
Time: 1 day, 11 hours ago
[INFO] SYSTEM (e329868a-fe51-476f-9924-71c518ba6a05)
Message: Network map updated
Time: 1 day, 11 hours ago
[INFO] SYSTEM (9c0ccbfd-8c26-4c86-a825-a5a90d1e716a)
Message: Network map updated
Time: 19 hours, 27 minutes ago
[INFO] SYSTEM (14fb151b-47c5-4ea0-ace0-eea47becc424)
Message: Network map updated
Time: 18 hours, 30 minutes ago
[INFO] SYSTEM (9876241d-2b71-44ad-b536-01061ccc349e)
Message: Network map updated
Time: 18 hours, 29 minutes ago
[INFO] SYSTEM (236188ff-3b46-4609-a578-e3d9a27b9cd0)
Message: Network map updated
Time: 17 hours, 8 minutes ago
[INFO] SYSTEM (debe81d3-288d-4104-abb6-62b3dc46149f)
Message: Network map updated
Time: 16 hours, 9 minutes ago
OS: linux/amd64
Daemon version: 0.73.2
CLI version: 0.73.2
Profile: default
Management: Connected to https://netbird.mydomain.io:443
Signal: Connected to https://netbird.mydomain.io:443
Relays:
[stun:netbird.mydomain.io:3478] is Available
[rels://netbird.mydomain.io:443] is Available via ws
Nameservers:
FQDN: netbird.netbird.selfhosted
NetBird IP: 100.86.111.80/16
Interface type: Kernel
Wireguard port: 51820
Quantum resistance: false
Lazy connection: false
SSH Server: Disabled
Networks: 10.11.10.0/24
Peers count: 3/5 Connected

I would go and check the Netbird logs and see where the failure is.

After looking at the logs and discussing this on the netbird slack and some testing. It turn out using the default wireguard port on the internal devices was the problem. Our only guess is that since the UDM does have a wiregard vpn server setup it was intercepting any of the traffic on that port. After changing all the internal devices to a different random port I am able to get P2P connections!

2 Likes