[GH-ISSUE #1539] issue with routing masquerading off #2623

Open
opened 2026-08-05 00:48:07 -04:00 by saavagebueno · 4 comments
Owner

Originally created by @hacklhar on GitHub (Feb 7, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/1539

Hi guys, we´ve following setup

Client A (Peer) , netbird agent installed, private ip 192.168.0.65, netbird ip 100.84.174.255
Client B (Routing Peer), netbird agent installed, private ip 10.40.2.4, netbird ip 100.84.174.207
Client C (Webserver), no netbird agent installed, private ip 10.40.4.4

If we add routes for 10.40.2.0/24 and 10.40.4.0/24, masquerading enabled on manager and add Client A & Client B to the Distribution group. We are able to communicate between Client A and Client B (via private ip and netbird ip), and it´s also possible to communicate from Client A to Client C. But Client C can´t reach Client A.

If we add routes for 10.40.2.0/24 and 10.40.4.0/24, masquerading disabled on manager and add Client A & Client B to the Distribution group. We are able to communicate between Client A and Client B (via private ip and netbird ip). But now we are unable to communicate from Client A to Client C and vice versa.

We tried to add a manually route on Client C for the netbird vpn subnet, to route the traffic to routing peer 10.40.2.4. But this is also not working.

We didn´t find more details about the required configuration in the documentation. Would be great if someone has an idea to solve the routing issue.

Regardsm
Harald

Originally created by @hacklhar on GitHub (Feb 7, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/1539 Hi guys, we´ve following setup Client A (Peer) , netbird agent installed, private ip 192.168.0.65, netbird ip 100.84.174.255 Client B (Routing Peer), netbird agent installed, private ip 10.40.2.4, netbird ip 100.84.174.207 Client C (Webserver), no netbird agent installed, private ip 10.40.4.4 If we add routes for 10.40.2.0/24 and 10.40.4.0/24, masquerading enabled on manager and add Client A & Client B to the Distribution group. We are able to communicate between Client A and Client B (via private ip and netbird ip), and it´s also possible to communicate from Client A to Client C. But Client C can´t reach Client A. If we add routes for 10.40.2.0/24 and 10.40.4.0/24, masquerading disabled on manager and add Client A & Client B to the Distribution group. We are able to communicate between Client A and Client B (via private ip and netbird ip). But now we are unable to communicate from Client A to Client C and vice versa. We tried to add a manually route on Client C for the netbird vpn subnet, to route the traffic to routing peer 10.40.2.4. But this is also not working. We didn´t find more details about the required configuration in the documentation. Would be great if someone has an idea to solve the routing issue. Regardsm Harald
saavagebueno added the feature-requesttriage-needed labels 2026-08-05 00:48:07 -04:00
Author
Owner

@hacklhar commented on GitHub (Feb 8, 2024):

Sorry forget to mention our goal ;) We need to communicate from Client A to Client C and vice versa while masquerading is disabled

<!-- gh-comment-id:1933460491 --> @hacklhar commented on GitHub (Feb 8, 2024): Sorry forget to mention our goal ;) We need to communicate from Client A to Client C and vice versa while masquerading is disabled
Author
Owner

@Hobby-Student commented on GitHub (Jun 3, 2024):

I just tried the same and got the same result. I'd love to see A<->C (in both directions) communication working until the BSD (opnsense) client is fully working.

<!-- gh-comment-id:2146219286 --> @Hobby-Student commented on GitHub (Jun 3, 2024): I just tried the same and got the same result. I'd love to see A<->C (in both directions) communication working until the BSD (opnsense) client is fully working.
Author
Owner

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

Sounds like a kind of a reverse route feature request to allow communication from the non-NetBird machine to NetBird peer? I don't think this is easily achievable without a custom routing device setup or access to the Client C itself?

Did you manage to figure this out?

<!-- gh-comment-id:2824670882 --> @nazarewk commented on GitHub (Apr 23, 2025): Sounds like a kind of a reverse route feature request to allow communication from the non-NetBird machine to NetBird peer? I don't think this is easily achievable without a custom routing device setup or access to the Client C itself? Did you manage to figure this out?
Author
Owner

@PizzaLovingNerd commented on GitHub (May 30, 2026):

Closing as documented. Disable masquerade, configure a return route for the NetBird CIDR through the routing peer, and ensure IP forwarding is enabled. See https://docs.netbird.io/manage/network-routes#routes-without-masquerading. Cheers!

<!-- gh-comment-id:4585440026 --> @PizzaLovingNerd commented on GitHub (May 30, 2026): Closing as documented. Disable masquerade, configure a return route for the NetBird CIDR through the routing peer, and ensure IP forwarding is enabled. See https://docs.netbird.io/manage/network-routes#routes-without-masquerading. Cheers!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#2623