[GH-ISSUE #1009] Network route without masquerading issue #1728

Open
opened 2026-08-05 00:43:43 -04:00 by saavagebueno · 3 comments
Owner

Originally created by @Alemiz112 on GitHub (Jul 10, 2023).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/1009

Describe the problem
Hi, I have setup a peer with network masquerading disabled to expose subnet 172.16.10.0/24 to other peers and their network. The other peer is able to reach this subnet. With configured routes in a network router all other LAN devices should be able reach this subnet too. However, this does not seem to work.

To Reproduce
Steps to reproduce the behavior:

  1. Setup network route to expose subnet 172.16.10.0/24 and assign it to the peer.
  2. Create client peer in the LAN network with access to the 172.16.10.0/24 subnet.
  3. Test that client peer can connect to i.e 172.16.10.2 - this should work. (peer is running on a machine with LAN IP 192.168.2.200)
  4. Setup route on LAN router (192.168.2.1): 172.16.10.0/24 -> 192.168.2.200

Expected behavior
Any device in 192.168.2.0/24 network should be able to reach anything in 172.16.10.0/24.

What actually happens
A LAN device can not reach the routed subnet and appears to be stuck after it is routed to 192.168.2.200.
image

Additional context
192.168.2.200's routes:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    100    0        0 ens18
100.71.0.0      0.0.0.0         255.255.0.0     U     0      0        0 wt0
172.16.0.0      100.71.101.110  255.255.255.0   UG    0      0        0 wt0
172.16.10.0     100.71.101.110  255.255.255.0   UG    0      0        0 wt0
192.168.0.0     100.71.101.110  255.255.255.0   UG    0      0        0 wt0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 ens18
192.168.2.1     0.0.0.0         255.255.255.255 UH    100    0        0 ens18

LAN router routes:

0.0.0.0/24 dev vtun0  proto kernel  scope link
default via 10.144.101.1 dev eth0  proto zebra
10.144.101.0/24 dev eth0  proto kernel  scope link  src 10.144.101.93
10.9.0.0/24 dev vtun0  proto kernel  scope link  src 10.9.0.1
172.16.10.0/24 via 192.168.2.200 dev switch0  proto zebra // <-- this
192.168.2.0/24 dev switch0  proto kernel  scope link  src 192.168.2.1
  • I have recently migrated to NetBird from Wireguard. Before, with Wireguard, the setup was the same (172.16.10.0/24 routed through 192.168.2.200) and everything was working as expected.
Originally created by @Alemiz112 on GitHub (Jul 10, 2023). Original GitHub issue: https://github.com/netbirdio/netbird/issues/1009 **Describe the problem** Hi, I have setup a peer with network masquerading disabled to expose subnet `172.16.10.0/24` to other peers and their network. The other peer is able to reach this subnet. With configured routes in a network router all other LAN devices should be able reach this subnet too. However, this does not seem to work. **To Reproduce** Steps to reproduce the behavior: 1. Setup network route to expose subnet `172.16.10.0/24` and assign it to the peer. 2. Create client peer in the LAN network with access to the `172.16.10.0/24` subnet. 3. Test that client peer can connect to i.e `172.16.10.2` - this should work. (peer is running on a machine with LAN IP `192.168.2.200`) 4. Setup route on LAN router (`192.168.2.1`): `172.16.10.0/24` -> `192.168.2.200` **Expected behavior** Any device in `192.168.2.0/24` network should be able to reach anything in `172.16.10.0/24`. **What actually happens** A LAN device can not reach the routed subnet and appears to be stuck after it is routed to `192.168.2.200`. ![image](https://github.com/netbirdio/netbird/assets/45739737/d0c4007a-62fa-46ed-8196-04f7ddb6013b) **Additional context** `192.168.2.200`'s routes: ``` Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 ens18 100.71.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wt0 172.16.0.0 100.71.101.110 255.255.255.0 UG 0 0 0 wt0 172.16.10.0 100.71.101.110 255.255.255.0 UG 0 0 0 wt0 192.168.0.0 100.71.101.110 255.255.255.0 UG 0 0 0 wt0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ens18 192.168.2.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens18 ``` LAN router routes: ``` 0.0.0.0/24 dev vtun0 proto kernel scope link default via 10.144.101.1 dev eth0 proto zebra 10.144.101.0/24 dev eth0 proto kernel scope link src 10.144.101.93 10.9.0.0/24 dev vtun0 proto kernel scope link src 10.9.0.1 172.16.10.0/24 via 192.168.2.200 dev switch0 proto zebra // <-- this 192.168.2.0/24 dev switch0 proto kernel scope link src 192.168.2.1 ``` * I have recently migrated to NetBird from Wireguard. Before, with Wireguard, the setup was the same (`172.16.10.0/24` routed through `192.168.2.200`) and everything was working as expected.
saavagebueno added the bugclient labels 2026-08-05 00:43:43 -04:00
Author
Owner

@nazarewk commented on GitHub (Apr 17, 2025):

@Alemiz112 were you able to figure this out? Is it still an issue no the latest version?

<!-- gh-comment-id:2813431131 --> @nazarewk commented on GitHub (Apr 17, 2025): @Alemiz112 were you able to figure this out? Is it still an issue no the latest version?
Author
Owner

@Alemiz112 commented on GitHub (Apr 17, 2025):

Hi, no not really. I am still using Netbird in the same environment, but I never really figured out what the issue was.

I should probably say that the issue eventually resolved itself after the client was restarted several times. However, I still get this issue from time to time. The solution for me is to restart all clients that need certain route as well as client broadcasting the route until it "magically" starts working.

<!-- gh-comment-id:2813444376 --> @Alemiz112 commented on GitHub (Apr 17, 2025): Hi, no not really. I am still using Netbird in the same environment, but I never really figured out what the issue was. I should probably say that the issue eventually resolved itself after the client was restarted several times. However, I still get this issue from time to time. The solution for me is to restart all clients that need certain route as well as client broadcasting the route until it "magically" starts working.
Author
Owner

@nazarewk commented on GitHub (Apr 17, 2025):

Thanks for getting back to us. Such a long-standing issue might warrant some debugging/reproduction on our side in the future. Note, we plan to at least review all the remaining open GitHub issues first before handling them.

<!-- gh-comment-id:2813586076 --> @nazarewk commented on GitHub (Apr 17, 2025): Thanks for getting back to us. Such a long-standing issue might warrant some debugging/reproduction on our side in the future. Note, we plan to at least review all the remaining open GitHub issues first before handling them.
Sign in to join this conversation.
No Label bug client
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#1728