DYNR/netbird
2
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-08-05 00:15:26 -04:00
Code Issues 23.5k Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5273] Netbird Doesn't Route External Network > Netbird Network Traffic #10876

New Issue
Open
opened 2026-08-05 01:27:34 -04:00 by saavagebueno · 7 comments
saavagebueno commented 2026-08-05 01:27:34 -04:00
Owner
Copy Link

Originally created by @ev5unleash on GitHub (Feb 6, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5273

Describe the problem

When either using the Networks or Network Route feature of Netbird, agentless devices are unable to initiate connections to Netbird peers, only the other way around. Traffic will flow both directions IF the Netbird peer initiates the connection with the agentless device.

After observing the traffic, I have narrowed the issue down to the netbird routing peer. The netbird routing peer will see the ICMP pings on the external network interface, but never pass them to the wt0 interface for other peers on the Netbird network.

Even after creating a linux route to accept the traffic and pass it to the wt0 interface, traffic will leave the wt0 interface but never get to the netbird peer.

To Reproduce

Steps to reproduce the behavior:

  1. Setup a routing peer with a network route or add a route as a resource WITHOUT masquerade.
  2. Setup a static route on the external network side and point the netbird subnet range to the routing peer.
  3. Join the Netbird network with a device (Windows was tested).
  4. Ping a node on the Netbird network (no response)

Expected behavior

With Masquerading disabled, clients on the Netbird network should be accessible by the external network so long as a route on the external network has been set up.

Are you using NetBird Cloud?

Self-Hosted

NetBird version
Management v0.64.5
Dashboard v2.31.0
Client 0.64.5

Is any other VPN software installed?

No

Debug output

To help us resolve the problem, please attach the following anonymized status output

netbird status -dA

Peers detail:
win11-2.netbird-vpn.anon-0P1MV.domain:
NetBird IP: 10.131.241.241
Public key: mCffSoEg2PG664vnNYzZYRLLGsLe+3XFtYJmO3SXOH8=
Status: Connected
-- detail --
Connection type: P2P
ICE candidate (Local/Remote): host/host
ICE candidate endpoints (Local/Remote): 10.131.194.5:51820/10.130.90.71:51820
Relay server address: rels://netbird.anon-0P1MV.domain:443
Last connection update: 15 seconds ago
Last WireGuard handshake: 10 seconds ago
Transfer status (received/sent) 303.9 KiB/766.4 KiB
Quantum resistance: false
Networks: -
Latency: 236.608µs

win11-1.netbird-vpn.anon-0P1MV.domain:
NetBird IP: 10.131.242.68
Public key: Fab/T8ZqHngN+ll1DsphpUFfoY7AEkS9mexlO0Pw9Fk=
Status: Connecting
-- detail --
Connection type: -
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address:
Last connection update: 12 minutes, 52 seconds ago
Last WireGuard handshake: -
Transfer status (received/sent) 0 B/0 B
Quantum resistance: false
Networks: -
Latency: 0s

dellxps15-wh.netbird-vpn.anon-0P1MV.domain:
NetBird IP: 10.131.251.176
Public key: vz9i2BB4fGLY79yggP4I4laUJG74uwiOdFqhvyoZ4iU=
Status: Connecting
-- detail --
Connection type: -
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address:
Last connection update: 51 minutes, 20 seconds ago
Last WireGuard handshake: -
Transfer status (received/sent) 0 B/0 B
Quantum resistance: false
Networks: -
Latency: 0s

desktop-fg403fr.netbird-vpn.anon-0P1MV.domain:
NetBird IP: 10.131.253.203
Public key: 0prAbDR9RWf17geuupoHOs0NBPxb3Eq9yrEKH5k0bxc=
Status: Connecting
-- detail --
Connection type: -
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address:
Last connection update: 51 minutes, 20 seconds ago
Last WireGuard handshake: -
Transfer status (received/sent) 0 B/0 B
Quantum resistance: false
Networks: -
Latency: 0s

evan-fw16.netbird-vpn.anon-0P1MV.domain:
NetBird IP: 10.131.255.113
Public key: AhOD32xCan3a7fWNGZEmR2dAQdBp9iV+ejUeh2i75hg=
Status: Connecting
-- detail --
Connection type: -
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address:
Last connection update: 51 minutes, 20 seconds ago
Last WireGuard handshake: -
Transfer status (received/sent) 0 B/0 B
Quantum resistance: false
Networks: -
Latency: 0s

Events:
[INFO] SYSTEM (36eec242-a26f-4e71-b238-188535d916ac)
Message: Network map updated
Time: 17 minutes, 20 seconds ago
[INFO] SYSTEM (3ccbe5a6-7127-44fb-9926-7a31a9103d07)
Message: Network map updated
Time: 17 minutes, 7 seconds ago
[INFO] SYSTEM (22000aae-adc8-4e95-ac4a-285dffe32158)
Message: Network map updated
Time: 16 minutes, 54 seconds ago
[INFO] SYSTEM (f3429a96-5370-4464-ad68-5793d9464e12)
Message: Network map updated
Time: 15 minutes, 42 seconds ago
[INFO] SYSTEM (4045dc57-2af0-4a02-969e-25ff9bfbca2e)
Message: Network map updated
Time: 15 minutes, 23 seconds ago
[INFO] SYSTEM (1b525b2d-0afc-4fa1-bfa0-c92822213fa6)
Message: Network map updated
Time: 15 minutes, 15 seconds ago
[INFO] SYSTEM (40471358-bc64-4c10-9399-3c8c10af2cb7)
Message: Network map updated
Time: 14 minutes, 47 seconds ago
[INFO] SYSTEM (6ea93353-3644-4e48-9611-dfa517d7f261)
Message: Network map updated
Time: 13 minutes, 36 seconds ago
[INFO] SYSTEM (7a0176f8-aec8-43ca-85d5-ceffc0092875)
Message: Network map updated
Time: 13 minutes, 4 seconds ago
[INFO] SYSTEM (8132ee96-90be-473d-a1fe-46c653e5fb27)
Message: Network map updated
Time: 12 minutes, 52 seconds ago
OS: linux/amd64
Daemon version: 0.64.5
CLI version: 0.64.5
Profile: default
Management: Connected to https://netbird.anon-0P1MV.domain:443
Signal: Connected to https://netbird.anon-0P1MV.domain:443
Relays:
[stun:netbird.anon-0P1MV.domain:3478] is Available
[rels://netbird.anon-0P1MV.domain:443] is Available
Nameservers:
FQDN: netbird-r1.netbird-vpn.anon-0P1MV.domain
NetBird IP: 10.131.242.209/20
Interface type: Kernel
Quantum resistance: false
Lazy connection: false
SSH Server: Disabled
Networks: 10.130.150.0/23, 10.130.8.0/24
Peers count: 1/5 Connected

Create and upload a debug bundle, and share the returned file key:

netbird debug for 1m -AS -U

Key
1954ba0b09de76b928b9bc532d2d10f3b3a26883921c5867fb94b94053445f27/4a73a69f-cbcb-4445-ab83-2bd6c576f1e1

Uploaded files are automatically deleted after 30 days.

Alternatively, create the file only and attach it here manually:

netbird debug for 1m -AS

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

Have you tried these troubleshooting steps?

  • [Yes] Reviewed client troubleshooting (if applicable)
  • [Yes] Checked for newer NetBird versions
  • [Yes] Searched for similar issues on GitHub (including closed ones)
  • [Yes] Restarted the NetBird client
  • [Yes] Disabled other VPN software
  • [Yes] Checked firewall settings
Originally created by @ev5unleash on GitHub (Feb 6, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5273 **Describe the problem** When either using the Networks or Network Route feature of Netbird, agentless devices are unable to initiate connections to Netbird peers, only the other way around. Traffic will flow both directions IF the Netbird peer initiates the connection with the agentless device. After observing the traffic, I have narrowed the issue down to the netbird routing peer. The netbird routing peer will see the ICMP pings on the external network interface, but never pass them to the wt0 interface for other peers on the Netbird network. Even after creating a linux route to accept the traffic and pass it to the wt0 interface, traffic will leave the wt0 interface but never get to the netbird peer. **To Reproduce** Steps to reproduce the behavior: 1. Setup a routing peer with a network route or add a route as a resource WITHOUT masquerade. 2. Setup a static route on the external network side and point the netbird subnet range to the routing peer. 3. Join the Netbird network with a device (Windows was tested). 4. Ping a node on the Netbird network (no response) **Expected behavior** With Masquerading disabled, clients on the Netbird network should be accessible by the external network so long as a route on the external network has been set up. **Are you using NetBird Cloud?** Self-Hosted **NetBird version** Management v0.64.5 Dashboard v2.31.0 Client 0.64.5 **Is any other VPN software installed?** No **Debug output** To help us resolve the problem, please attach the following anonymized status output netbird status -dA Peers detail: win11-2.netbird-vpn.anon-0P1MV.domain: NetBird IP: 10.131.241.241 Public key: mCffSoEg2PG664vnNYzZYRLLGsLe+3XFtYJmO3SXOH8= Status: Connected -- detail -- Connection type: P2P ICE candidate (Local/Remote): host/host ICE candidate endpoints (Local/Remote): 10.131.194.5:51820/10.130.90.71:51820 Relay server address: rels://netbird.anon-0P1MV.domain:443 Last connection update: 15 seconds ago Last WireGuard handshake: 10 seconds ago Transfer status (received/sent) 303.9 KiB/766.4 KiB Quantum resistance: false Networks: - Latency: 236.608µs win11-1.netbird-vpn.anon-0P1MV.domain: NetBird IP: 10.131.242.68 Public key: Fab/T8ZqHngN+ll1DsphpUFfoY7AEkS9mexlO0Pw9Fk= Status: Connecting -- detail -- Connection type: - ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: 12 minutes, 52 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Networks: - Latency: 0s dellxps15-wh.netbird-vpn.anon-0P1MV.domain: NetBird IP: 10.131.251.176 Public key: vz9i2BB4fGLY79yggP4I4laUJG74uwiOdFqhvyoZ4iU= Status: Connecting -- detail -- Connection type: - ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: 51 minutes, 20 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Networks: - Latency: 0s desktop-fg403fr.netbird-vpn.anon-0P1MV.domain: NetBird IP: 10.131.253.203 Public key: 0prAbDR9RWf17geuupoHOs0NBPxb3Eq9yrEKH5k0bxc= Status: Connecting -- detail -- Connection type: - ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: 51 minutes, 20 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Networks: - Latency: 0s evan-fw16.netbird-vpn.anon-0P1MV.domain: NetBird IP: 10.131.255.113 Public key: AhOD32xCan3a7fWNGZEmR2dAQdBp9iV+ejUeh2i75hg= Status: Connecting -- detail -- Connection type: - ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: 51 minutes, 20 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Networks: - Latency: 0s Events: [INFO] SYSTEM (36eec242-a26f-4e71-b238-188535d916ac) Message: Network map updated Time: 17 minutes, 20 seconds ago [INFO] SYSTEM (3ccbe5a6-7127-44fb-9926-7a31a9103d07) Message: Network map updated Time: 17 minutes, 7 seconds ago [INFO] SYSTEM (22000aae-adc8-4e95-ac4a-285dffe32158) Message: Network map updated Time: 16 minutes, 54 seconds ago [INFO] SYSTEM (f3429a96-5370-4464-ad68-5793d9464e12) Message: Network map updated Time: 15 minutes, 42 seconds ago [INFO] SYSTEM (4045dc57-2af0-4a02-969e-25ff9bfbca2e) Message: Network map updated Time: 15 minutes, 23 seconds ago [INFO] SYSTEM (1b525b2d-0afc-4fa1-bfa0-c92822213fa6) Message: Network map updated Time: 15 minutes, 15 seconds ago [INFO] SYSTEM (40471358-bc64-4c10-9399-3c8c10af2cb7) Message: Network map updated Time: 14 minutes, 47 seconds ago [INFO] SYSTEM (6ea93353-3644-4e48-9611-dfa517d7f261) Message: Network map updated Time: 13 minutes, 36 seconds ago [INFO] SYSTEM (7a0176f8-aec8-43ca-85d5-ceffc0092875) Message: Network map updated Time: 13 minutes, 4 seconds ago [INFO] SYSTEM (8132ee96-90be-473d-a1fe-46c653e5fb27) Message: Network map updated Time: 12 minutes, 52 seconds ago OS: linux/amd64 Daemon version: 0.64.5 CLI version: 0.64.5 Profile: default Management: Connected to https://netbird.anon-0P1MV.domain:443 Signal: Connected to https://netbird.anon-0P1MV.domain:443 Relays: [stun:netbird.anon-0P1MV.domain:3478] is Available [rels://netbird.anon-0P1MV.domain:443] is Available Nameservers: FQDN: netbird-r1.netbird-vpn.anon-0P1MV.domain NetBird IP: 10.131.242.209/20 Interface type: Kernel Quantum resistance: false Lazy connection: false SSH Server: Disabled Networks: 10.130.150.0/23, 10.130.8.0/24 Peers count: 1/5 Connected Create and upload a debug bundle, and share the returned file key: netbird debug for 1m -AS -U Key 1954ba0b09de76b928b9bc532d2d10f3b3a26883921c5867fb94b94053445f27/4a73a69f-cbcb-4445-ab83-2bd6c576f1e1 *Uploaded files are automatically deleted after 30 days.* Alternatively, create the file only and attach it here manually: netbird debug for 1m -AS **Screenshots** If applicable, add screenshots to help explain your problem. **Additional context** Add any other context about the problem here. **Have you tried these troubleshooting steps?** - [Yes] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [Yes] Checked for newer NetBird versions - [Yes] Searched for similar issues on GitHub (including closed ones) - [Yes] Restarted the NetBird client - [Yes] Disabled other VPN software - [Yes] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:27:34 -04:00
saavagebueno commented 2026-08-05 01:27:35 -04:00
Author
Owner
Copy Link

@cnpmx commented on GitHub (Feb 19, 2026):

We need this as feature request when/if possible. Might as well be a problem of Windows itself and it's Windows Filtering Platform (WFP), since i have previously worked on diagnosing such issues with Windows peers and have seen packets go through the Netbird Router i have installed in corporate network, but not going out or being filtered on the Windows peer itself.

<!-- gh-comment-id:3925211743 --> @cnpmx commented on GitHub (Feb 19, 2026): We need this as feature request when/if possible. Might as well be a problem of Windows itself and it's Windows Filtering Platform (WFP), since i have previously worked on diagnosing such issues with Windows peers and have seen packets go through the Netbird Router i have installed in corporate network, but not going out or being filtered on the Windows peer itself.
saavagebueno commented 2026-08-05 01:27:35 -04:00
Author
Owner
Copy Link

@rcambrj commented on GitHub (May 16, 2026):

I think I may be hitting the same bug, or a narrower variant of it.

My setup:

  • router is a NetBird-connected routing peer
  • agentless is a normal LAN host behind that router on 10.0.0.0/24
  • peer is a NetBird peer with NetBird IP 10.1.0.11
  • the LAN subnet is configured in NetBird as a routed network
  • on peer, ip route show table all contains:
    10.0.0.0/24 dev netbird table 7120

Observed behavior:

  • From peer, ping to router's Netbird address works
  • From router, ping to peer's NetBird address works
  • From router, ping to agentless's LAN address works
  • From agentless, ping to router's LAN address works
  • From agentless, ping to peer's NetBird address fails, curl fails, all traffic fails
  • From agentless, ping to peer's public Internet IP works
  • With an older NetBird version, from agentless, ping to peer's NetBird address works:
    • working: 0.59.10
    • non-working: 0.61.0 through 0.70.5

Packet traces:
On router, for the failing case (agentless -> peer NetBird IP), I see:

  • ICMP echo request arrives from the LAN
  • it is forwarded out the NetBird interface

Example:

br-lan In  IP 10.0.0.22 > 10.1.0.11: ICMP echo request
netbird Out IP 10.0.0.22 > 10.1.0.11: ICMP echo request

On the destination peer, I see the packet arrive on the netbird interface:

netbird In  IP 10.0.0.22 > 10.1.0.11: ICMP echo request

But peer never sends a reply.

For the reverse direction (peer -> agentless), traffic works fine through the same routed subnet path. On router I see:

netbird In  IP 10.1.0.11 > 10.0.0.22: ICMP echo request
br-lan Out IP 10.1.0.11 > 10.0.0.22: ICMP echo request
br-lan In  IP 10.0.0.22 > 10.1.0.11: ICMP echo reply
netbird Out IP 10.0.0.22 > 10.1.0.11: ICMP echo reply

Other info:

  • all tests conducted on Linux
  • the destination peer has the routed subnet in table 7120
  • ip route get 10.0.0.22 on the destination peer resolves via netbird
  • reverse path filtering does not seem to be the issue:
    • net.ipv4.conf.all.rp_filter = 0
    • net.ipv4.conf.netbird.rp_filter = 2
<!-- gh-comment-id:4468419869 --> @rcambrj commented on GitHub (May 16, 2026): I think I may be hitting the same bug, or a narrower variant of it. My setup: - `router` is a NetBird-connected routing peer - `agentless` is a normal LAN host behind that router on `10.0.0.0/24` - `peer` is a NetBird peer with NetBird IP `10.1.0.11` - the LAN subnet is configured in NetBird as a routed network - on `peer`, `ip route show table all` contains: `10.0.0.0/24 dev netbird table 7120` Observed behavior: - From `peer`, ping to `router`'s Netbird address works - From `router`, ping to `peer`'s NetBird address works - From `router`, ping to `agentless`'s LAN address works - From `agentless`, ping to `router`'s LAN address works - From `agentless`, ping to `peer`'s NetBird address **fails**, `curl` fails, all traffic fails - From `agentless`, ping to `peer`'s public Internet IP works - With an older NetBird version, from `agentless`, ping to `peer`'s NetBird address **works**: - working: 0.59.10 - non-working: 0.61.0 through 0.70.5 Packet traces: On `router`, for the failing case (`agentless -> peer NetBird IP`), I see: - ICMP echo request arrives from the LAN - it is forwarded out the NetBird interface Example: ```text br-lan In IP 10.0.0.22 > 10.1.0.11: ICMP echo request netbird Out IP 10.0.0.22 > 10.1.0.11: ICMP echo request ``` On the destination `peer`, I see the packet arrive on the netbird interface: ``` netbird In IP 10.0.0.22 > 10.1.0.11: ICMP echo request ``` But `peer` never sends a reply. For the reverse direction (`peer` -> `agentless`), traffic works fine through the same routed subnet path. On `router` I see: ``` netbird In IP 10.1.0.11 > 10.0.0.22: ICMP echo request br-lan Out IP 10.1.0.11 > 10.0.0.22: ICMP echo request br-lan In IP 10.0.0.22 > 10.1.0.11: ICMP echo reply netbird Out IP 10.0.0.22 > 10.1.0.11: ICMP echo reply ``` Other info: - all tests conducted on Linux - the destination peer has the routed subnet in table 7120 - ip route get 10.0.0.22 on the destination peer resolves via netbird - reverse path filtering does not seem to be the issue: - `net.ipv4.conf.all.rp_filter = 0` - `net.ipv4.conf.netbird.rp_filter = 2`
saavagebueno commented 2026-08-05 01:27:35 -04:00
Author
Owner
Copy Link

@lixmal commented on GitHub (May 16, 2026):

See https://docs.netbird.io/manage/networks/use-cases/site-to-vpn

<!-- gh-comment-id:4468991883 --> @lixmal commented on GitHub (May 16, 2026): See https://docs.netbird.io/manage/networks/use-cases/site-to-vpn
saavagebueno commented 2026-08-05 01:27:35 -04:00
Author
Owner
Copy Link

@rcambrj commented on GitHub (May 17, 2026):

Thanks @lixmal I think that's entirely applicable to my case (I can't speak for @ev5unleash ).

So it seems that after netbird 0.59.10 (not inclusive), IP forwarding into the netbird network must be SNATed, which indeed isn't the case in my network. Unfortunately SNAT doesn't fit my network model. What's the reason for that requirement? Can it be toggleable?

Lastly, @ev5unleash if my issue isn't the same please say so and I'll open a fresh one.

<!-- gh-comment-id:4470013122 --> @rcambrj commented on GitHub (May 17, 2026): Thanks @lixmal I think that's entirely applicable to my case (I can't speak for @ev5unleash ). So it seems that after netbird 0.59.10 (not inclusive), IP forwarding into the netbird network must be SNATed, which indeed isn't the case in my network. Unfortunately SNAT doesn't fit my network model. What's the reason for that requirement? Can it be toggleable? Lastly, @ev5unleash if my issue isn't the same please say so and I'll open a fresh one.
saavagebueno commented 2026-08-05 01:27:35 -04:00
Author
Owner
Copy Link

@rcambrj commented on GitHub (May 22, 2026):

Just wanted to add some closure from my side. I created this repository which:

  • reproduces the problem with 0.70.5
  • proves that 0.59.5 doesn't suffer the problem
  • proves that it can be fixed with a vibe-coded patch (unaudited - do not run in production)

It also justifies why SNAT is unwanted in some scenarios.

I had originally reported this problem on the Netbird slack back in November 2025, and I solved it by switching from the hosted Netbird service to the self-hosted option. I can only imagine that the Netbird team had rolled out this feature to the hosted Netbird service before later porting it to the self-hosted repository, because a few months later the problem reared its ugly head again in the self-hosted option. That's why I was only recently able to reproduce the problem in an isolated sandbox (the repro repository above) - the problem didn't exist in self-hosted back in November.

Anyway, I've chosen to switch my homelab to Tailscale, because they appear to treat subnet forwarding without SNAT as a first class feature.

Sorry folks, I hope you decide to improve Netbird with this feature some day.

<!-- gh-comment-id:4519777663 --> @rcambrj commented on GitHub (May 22, 2026): Just wanted to add some closure from my side. I created [this repository](https://github.com/rcambrj/netbird-repro) which: - reproduces the problem with 0.70.5 - proves that 0.59.5 doesn't suffer the problem - proves that it can be fixed with a vibe-coded patch (unaudited - do not run in production) It also justifies why SNAT is unwanted in some scenarios. I had [originally reported](https://netbirdio.slack.com/archives/C02KHAE8VLZ/p1763076264642559) this problem on the Netbird slack back in November 2025, and I solved it by switching from the hosted Netbird service to the self-hosted option. I can only imagine that the Netbird team had rolled out this feature to the hosted Netbird service before later porting it to the self-hosted repository, because a few months later the problem reared its ugly head again in the self-hosted option. That's why I was only recently able to reproduce the problem in an isolated sandbox (the repro repository above) - the problem didn't exist in self-hosted back in November. Anyway, I've chosen to [switch my homelab to Tailscale](https://github.com/rcambrj/dotfiles/commit/a3faef6528a99cd6e8e09a7af58fa84b7912e86c), because they appear to treat [subnet forwarding without SNAT](https://tailscale.com/docs/features/subnet-routers#disable-snat) as a first class feature. Sorry folks, I hope you decide to improve Netbird with this feature some day.
saavagebueno commented 2026-08-05 01:27:35 -04:00
Author
Owner
Copy Link

@lixmal commented on GitHub (May 22, 2026):

@rcambrj It seems you were relying on a bug related to squashing rules. Resource -> NetBird rules are not quite implemented that's why you have to rely on Masquerading to leverage Peer to Peer rules, for the time being. 0.71.0 (IPv6) laid one step in that direction so it will be possible soon-ish

<!-- gh-comment-id:4520086580 --> @lixmal commented on GitHub (May 22, 2026): @rcambrj It seems you were relying on a bug related to squashing rules. Resource -> NetBird rules are not quite implemented that's why you have to rely on Masquerading to leverage Peer to Peer rules, for the time being. 0.71.0 (IPv6) laid one step in that direction so it will be possible soon-ish
saavagebueno commented 2026-08-05 01:27:35 -04:00
Author
Owner
Copy Link

@budzi-2bi commented on GitHub (Jun 1, 2026):

I had the same problem. I needed my local servers and my other VPN clients to access netbird peers (also servers) through a netbird peer in my local server network. It was supposed to be used for monitoring and server management, and I needed netbird peers to see the real IP address of the servers/VPN clients accessing them (security logs requirement). If I do SNAT on the routing peer in my local server network, every connection to the netbird peers will be logged as connection from the routing peer in local server network.

Unfortunately, I also had to implement tailscale for this, but would really love to see this implemented in Netbird.

<!-- gh-comment-id:4597070542 --> @budzi-2bi commented on GitHub (Jun 1, 2026): I had the same problem. I needed my local servers and my other VPN clients to access netbird peers (also servers) through a netbird peer in my local server network. It was supposed to be used for monitoring and server management, and I needed netbird peers to see the real IP address of the servers/VPN clients accessing them (security logs requirement). If I do SNAT on the routing peer in my local server network, every connection to the netbird peers will be logged as connection from the routing peer in local server network. Unfortunately, I also had to implement tailscale for this, but would really love to see this implemented in Netbird.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2021 Q4
2021 Q4
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
accessibility
accessibility
accessibility
acl
acl
acl
agent
agent
agent
agent
agent
agent
Android
Android
Android
Android
Android
Android
api
api
api
authentik
authentik
authentik
automation
automation
automation
azure
azure
azure
battery-usage
battery-usage
battery-usage
bug
cache
cache
cache
client
client
client
client-ui
client-ui
client-ui
cloud
cloud
cloud
cloud-only
cloud-only
cloud-only
cloudflare
cloudflare
cloudflare
community
community
community
compatibility
compatibility
compatibility
config-idp
config-idp
config-idp
config-issue
config-issue
config-issue
connection
connection
connection
contribution
contribution
contribution
coturn
coturn
coturn
cross-vpn
cross-vpn
cross-vpn
dashboard
dashboard
dashboard
data-usage
data-usage
data-usage
distribution
distribution
distribution
dns
dns
dns
docker
docker
docker
documentation
documentation
documentation
duplicate
duplicate
duplicate
enhancement
enhancement
event-stream
event-stream
event-stream
feature-request
feature-request
feature-request
freebsd
freebsd
freebsd
getting-started
getting-started
getting-started
go
go
go
good first issue
good first issue
good first issue
gui
gui
gui
help wanted
help wanted
help wanted
home-assistant
home-assistant
home-assistant
idp
idp
idp
inconsistency
inconsistency
inconsistency
integration
integration
integration
integrations
integrations
integrations
ios
ios
ios
ipv6
ipv6
ipv6
jwt
jwt
jwt
k8s
k8s
k8s
keycloak
keycloak
keycloak
linux
linux
linux
login
login
login
macos
macos
macos
management-service
management-service
management-service
Medium
Medium
Medium
missing-docs
missing-docs
missing-docs
mobile
mobile
mobile
moved-internal
moved-internal
moved-internal
needs-review
needs-review
needs-review
netbird-ui
netbird-ui
netbird-ui
networking
networking
networking
new-platform
new-platform
new-platform
nginx
nginx
nginx
notification
notification
notification
okta
okta
okta
openwrt
openwrt
openwrt
P2
P2
P2
packaging
packaging
packaging
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
performance
performance
performance
postgres
postgres
postgres
posture-checks
posture-checks
posture-checks
psk
psk
psk
pull-request
Mirrored from GitHub Pull Request
 question
question
question
refactor
refactor
refactor
relay
relay
relay
release
release
release
rfc
rfc
rfc
routes
routes
routes
security
security
security
security-improvement
security-improvement
security-improvement
security-related
security-related
security-related
self-hosting
self-hosting
self-hosting
server
server
server
signal
signal
signal
sleep-issue
sleep-issue
sleep-issue
ssh
ssh
ssh
ssl
ssl
ssl
status
status
status
store
store
store
synology
synology
synology
system-compatibility-issue
system-compatibility-issue
system-compatibility-issue
test-suite
test-suite
test-suite
third-party-integration
third-party-integration
third-party-integration
triage
triage
triage
triage
triage
triage
triage-needed
triage-needed
triage-needed
troubleshooting
troubleshooting
troubleshooting
UX
UX
UX
waiting-feedback
waiting-feedback
waiting-feedback
windows
windows
windows
wontfix
wontfix
wontfix
zitadel
zitadel
zitadel
No Label triage-needed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dynr-servers saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#10876
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?