[GH-ISSUE #4277] LAN to LAN traffic between peers not working #8844

Open
opened 2026-08-05 01:19:45 -04:00 by saavagebueno · 11 comments
Owner

Originally created by @Ignattious on GitHub (Aug 4, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4277

Describe the problem

2 Peers

Netbird A
Netbird B

Each peer / site has 1 LAN attached:
A 10.1.100.0/24
B 10.1.101.0/24

Can ping between:

Netbird Peer Site A to LAN B (Using Netbird 100.190.x.x source)
Netbird Peer Site B to LAN A (Using Netbird 100.190.x.x source)

Cannot Ping from Peer A LAN to Peer B LAN (Using LAN IP source)
Cannot Ping from Peer B LAN to Peer A LAN (Using LAN IP source)

To Reproduce

Add 2 Peers
Add Resources
Add Resource to Routing Peer

Expected behavior

Should be able to route between LAN networks using 2 ore more routing peers

Self Hosted
netbird version 0.52.2
No Other VPN software

Can see packets going over wt0 tunnel but get dropped on routing peer before going into LAN network, If the source is a netbird 100.190.x.x address from either end packets are transferred normally.

Policy should be allowed to be created to allow LAN networks from 2 different peers to communicate. In some cases, it is impossible to install netbird on all machines and we must rely on routing peers to provide communication between 2 different networks

Tailscale has similar functionality:

https://tailscale.com/kb/1214/site-to-site

Originally created by @Ignattious on GitHub (Aug 4, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4277 **Describe the problem** 2 Peers Netbird A Netbird B Each peer / site has 1 LAN attached: A 10.1.100.0/24 B 10.1.101.0/24 Can ping between: Netbird Peer Site A to LAN B (Using Netbird 100.190.x.x source) Netbird Peer Site B to LAN A (Using Netbird 100.190.x.x source) Cannot Ping from Peer A LAN to Peer B LAN (Using LAN IP source) Cannot Ping from Peer B LAN to Peer A LAN (Using LAN IP source) **To Reproduce** Add 2 Peers Add Resources Add Resource to Routing Peer **Expected behavior** Should be able to route between LAN networks using 2 ore more routing peers Self Hosted netbird version 0.52.2 No Other VPN software Can see packets going over wt0 tunnel but get dropped on routing peer before going into LAN network, If the source is a netbird 100.190.x.x address from either end packets are transferred normally. Policy should be allowed to be created to allow LAN networks from 2 different peers to communicate. In some cases, it is impossible to install netbird on all machines and we must rely on routing peers to provide communication between 2 different networks Tailscale has similar functionality: https://tailscale.com/kb/1214/site-to-site
saavagebueno added the triage-needed label 2026-08-05 01:19:45 -04:00
Author
Owner

@1nerdyguy commented on GitHub (Aug 4, 2025):

Netbird, to my knowledge, does not have this feature. You can publish a site to a client/group of clients, but not a site to site.

<!-- gh-comment-id:3151184598 --> @1nerdyguy commented on GitHub (Aug 4, 2025): Netbird, to my knowledge, does not have this feature. You can publish a site to a client/group of clients, but not a site to site.
Author
Owner

@stildalf commented on GitHub (Aug 7, 2025):

@Ignattious ,

Out of interest, are your A & B peers also the gateways for their relevant LANs?
(such as pfSense/OPNsense perhaps)

<!-- gh-comment-id:3163915521 --> @stildalf commented on GitHub (Aug 7, 2025): @Ignattious , Out of interest, are your A & B peers also the gateways for their relevant LANs? (such as pfSense/OPNsense perhaps)
Author
Owner

@nadieaqui commented on GitHub (Aug 7, 2025):

@Ignattious ,

Out of interest, are your A & B peers also the gateways for their relevant LANs? (such as pfSense/OPNsense perhaps)

@stildalf , I have the same problem, and A & B are the gateways for their relevant LANs for my scenario. Any insight would be appreciated. thank you.

<!-- gh-comment-id:3165485579 --> @nadieaqui commented on GitHub (Aug 7, 2025): > [@Ignattious](https://github.com/Ignattious) , > > Out of interest, are your A & B peers also the gateways for their relevant LANs? (such as pfSense/OPNsense perhaps) @stildalf , I have the same problem, and A & B are the gateways for their relevant LANs for my scenario. Any insight would be appreciated. thank you.
Author
Owner

@fre4ki commented on GitHub (Aug 7, 2025):

You have to set a static route on your default router for the other side and route it to your local netbird router.

i never tested this but for my understanding this should work.

Edit: but when i think about that, this is not the concept of ZTNA. How should policies checked when the user are unknown.

<!-- gh-comment-id:3165713082 --> @fre4ki commented on GitHub (Aug 7, 2025): You have to set a static route on your default router for the other side and route it to your local netbird router. i never tested this but for my understanding this should work. Edit: but when i think about that, this is not the concept of ZTNA. How should policies checked when the user are unknown.
Author
Owner

@fuomag9 commented on GitHub (Mar 12, 2026):

Netbird, to my knowledge, does not have this feature. You can publish a site to a client/group of clients, but not a site to site.

https://docs.netbird.io/manage/network-routes/use-cases/by-scenario/site-to-site-home

I could not manage to replicate their documentation, also for me:
peer on lan A -> LAN B
peer on lan B -> LAN A

But as soon as I try to do client LAN A -> client LAN B it stops working. From tcpdump I can see the packet routed from client on LAN A to the peer of LAN A, but it never reaches the peer of LAN B (nor the lan B client of course)

<!-- gh-comment-id:4051110500 --> @fuomag9 commented on GitHub (Mar 12, 2026): > Netbird, to my knowledge, does not have this feature. You can publish a site to a client/group of clients, but not a site to site. https://docs.netbird.io/manage/network-routes/use-cases/by-scenario/site-to-site-home I could not manage to replicate their documentation, also for me: peer on lan A -> LAN B peer on lan B -> LAN A But as soon as I try to do client LAN A -> client LAN B it stops working. From tcpdump I can see the packet routed from client on LAN A to the peer of LAN A, but it never reaches the peer of LAN B (nor the lan B client of course)
Author
Owner

@1nerdyguy commented on GitHub (Mar 12, 2026):

How are you setting your network routes, specifically the static routes to
the routing peers ?

On Thu, Mar 12, 2026, 6:44 PM fuomag9 @.***> wrote:

fuomag9 left a comment (netbirdio/netbird#4277)
https://github.com/netbirdio/netbird/issues/4277#issuecomment-4051110500

Netbird, to my knowledge, does not have this feature. You can publish a
site to a client/group of clients, but not a site to site.

https://docs.netbird.io/manage/network-routes/use-cases/by-scenario/site-to-site-home

I could not manage to replicate their documentation, also for me:
peer on lan A -> LAN B
peer on lan B -> LAN A

But as soon as I try to do client LAN A -> client LAN B it stops working.
From tcpdump I can see the packet routed from client on LAN A to the peer
of LAN A, but it never reaches the peer of LAN B (nor the lan B client of
course)


Reply to this email directly, view it on GitHub
https://github.com/netbirdio/netbird/issues/4277#issuecomment-4051110500,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHSVITC2PUU52U5K524Q3ED4QNDVBAVCNFSM6AAAAACWQKTMOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJRGEYTANJQGA
.
You are receiving this because you commented.Message ID:
@.***>

<!-- gh-comment-id:4052077721 --> @1nerdyguy commented on GitHub (Mar 12, 2026): How are you setting your network routes, specifically the static routes to the routing peers ? On Thu, Mar 12, 2026, 6:44 PM fuomag9 ***@***.***> wrote: > *fuomag9* left a comment (netbirdio/netbird#4277) > <https://github.com/netbirdio/netbird/issues/4277#issuecomment-4051110500> > > Netbird, to my knowledge, does not have this feature. You can publish a > site to a client/group of clients, but not a site to site. > > > https://docs.netbird.io/manage/network-routes/use-cases/by-scenario/site-to-site-home > > I could not manage to replicate their documentation, also for me: > peer on lan A -> LAN B > peer on lan B -> LAN A > > But as soon as I try to do client LAN A -> client LAN B it stops working. > From tcpdump I can see the packet routed from client on LAN A to the peer > of LAN A, but it never reaches the peer of LAN B (nor the lan B client of > course) > > — > Reply to this email directly, view it on GitHub > <https://github.com/netbirdio/netbird/issues/4277#issuecomment-4051110500>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHSVITC2PUU52U5K524Q3ED4QNDVBAVCNFSM6AAAAACWQKTMOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJRGEYTANJQGA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >
Author
Owner

@fuomag9 commented on GitHub (Mar 13, 2026):

How are you setting your network routes, specifically the static routes to
the routing peers ?

LAN A CIDR: 192.168.7.0/24
LAN B CIDR: 192.168.50.0/24

LAN A Client: 192.168.7.122
LAN B Client: 192.168.50.170

Peer A: 192.168.6.252
Peer B: 192.168.8.14

Static route on LAN A Router (unifi): network 192.168.50.0/24 via next hop 192.168.6.252 distance 1
Static route on LAN B Router (unifi): network 192.168.7.0/24 via next hop 192.168.8.14 distance 1

<!-- gh-comment-id:4053904969 --> @fuomag9 commented on GitHub (Mar 13, 2026): > How are you setting your network routes, specifically the static routes to > the routing peers ? > […](#) LAN A CIDR: 192.168.7.0/24 LAN B CIDR: 192.168.50.0/24 LAN A Client: 192.168.7.122 LAN B Client: 192.168.50.170 Peer A: 192.168.6.252 Peer B: 192.168.8.14 Static route on LAN A Router (unifi): network 192.168.50.0/24 via next hop 192.168.6.252 distance 1 Static route on LAN B Router (unifi): network 192.168.7.0/24 via next hop 192.168.8.14 distance 1
Author
Owner

@1nerdyguy commented on GitHub (Mar 13, 2026):

I'm pretty sure your issues is your static routes are backwards.

LAN A Router should have a route for Lan B via Peer A
Lan B should have a route for Lan A via Peer B

On Fri, Mar 13, 2026 at 4:45 AM fuomag9 @.***> wrote:

fuomag9 left a comment (netbirdio/netbird#4277)
https://github.com/netbirdio/netbird/issues/4277#issuecomment-4053904969

How are you setting your network routes, specifically the static routes to
the routing peers ?
… <#m_1894331166795873849_>

LAN A CIDR: 192.168.7.0/24
LAN B CIDR: 192.168.50.0/24

LAN A Client: 192.168.7.122
LAN B Client: 192.168.50.170

Peer A: 192.168.6.252
Peer B: 192.168.8.14

Static route on LAN A Router (unifi): network 192.168.7.0/24 via next hop
192.168.8.14 distance 1
Static route on LAN B Router (unifi): network 192.168.50.0/24 via next
hop 192.168.6.252 distance 1


Reply to this email directly, view it on GitHub
https://github.com/netbirdio/netbird/issues/4277#issuecomment-4053904969,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHSVITB3SHKITRNN2D37J4T4QPKDPAVCNFSM6AAAAACWQKTMOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJTHEYDIOJWHE
.
You are receiving this because you commented.Message ID:
@.***>

<!-- gh-comment-id:4057110934 --> @1nerdyguy commented on GitHub (Mar 13, 2026): I'm pretty sure your issues is your static routes are backwards. LAN A Router should have a route for Lan B via Peer A Lan B should have a route for Lan A via Peer B On Fri, Mar 13, 2026 at 4:45 AM fuomag9 ***@***.***> wrote: > *fuomag9* left a comment (netbirdio/netbird#4277) > <https://github.com/netbirdio/netbird/issues/4277#issuecomment-4053904969> > > How are you setting your network routes, specifically the static routes to > the routing peers ? > … <#m_1894331166795873849_> > > LAN A CIDR: 192.168.7.0/24 > LAN B CIDR: 192.168.50.0/24 > > LAN A Client: 192.168.7.122 > LAN B Client: 192.168.50.170 > > Peer A: 192.168.6.252 > Peer B: 192.168.8.14 > > Static route on LAN A Router (unifi): network 192.168.7.0/24 via next hop > 192.168.8.14 distance 1 > Static route on LAN B Router (unifi): network 192.168.50.0/24 via next > hop 192.168.6.252 distance 1 > > — > Reply to this email directly, view it on GitHub > <https://github.com/netbirdio/netbird/issues/4277#issuecomment-4053904969>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHSVITB3SHKITRNN2D37J4T4QPKDPAVCNFSM6AAAAACWQKTMOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJTHEYDIOJWHE> > . > You are receiving this because you commented.Message ID: > ***@***.***> >
Author
Owner

@fuomag9 commented on GitHub (Mar 13, 2026):

I'm pretty sure your issues is your static routes are backwards.

LAN A Router should have a route for Lan B via Peer A
Lan B should have a route for Lan A via Peer B

I did a typo as they were not swapped, unfortunately they were correct (I edited the post)

<!-- gh-comment-id:4057199258 --> @fuomag9 commented on GitHub (Mar 13, 2026): > I'm pretty sure your issues is your static routes are backwards. > > LAN A Router should have a route for Lan B via Peer A > Lan B should have a route for Lan A via Peer B > […](#) I did a typo as they were not swapped, unfortunately they were correct (I edited the post)
Author
Owner

@fuomag9 commented on GitHub (Mar 13, 2026):

@1nerdyguy I used codex because I wanted more debugging help and this is what I found out

Running this did make ping work

 ssh core@192.168.6.252 'sudo nft insert rule ip filter FORWARD iifname "ens18" oifname "wt0" ip saddr 192.168.7.0/24 ip daddr 192.168.50.0/24 accept'
 ssh core@192.168.8.14 'sudo nft insert rule ip filter FORWARD iifname "ens18" oifname "wt0" ip saddr 192.168.50.0/24 ip daddr 192.168.7.0/24 accept'

Both peers had:

  • FORWARD policy set to drop
  • Docker-managed chains present
  • only these generic accepts:
    • iifname "wt0" accept
    • oifname "wt0" ct state related,established accept

That means new traffic from ens18 -> wt0 was never allowed, which is what caused this

<!-- gh-comment-id:4057713581 --> @fuomag9 commented on GitHub (Mar 13, 2026): @1nerdyguy I used codex because I wanted more debugging help and this is what I found out Running this did make ping work ``` ssh core@192.168.6.252 'sudo nft insert rule ip filter FORWARD iifname "ens18" oifname "wt0" ip saddr 192.168.7.0/24 ip daddr 192.168.50.0/24 accept' ssh core@192.168.8.14 'sudo nft insert rule ip filter FORWARD iifname "ens18" oifname "wt0" ip saddr 192.168.50.0/24 ip daddr 192.168.7.0/24 accept' ``` Both peers had: - FORWARD policy set to drop - Docker-managed chains present - only these generic accepts: - iifname "wt0" accept - oifname "wt0" ct state related,established accept That means new traffic from ens18 -> wt0 was never allowed, which is what caused this
Author
Owner

@stratacast commented on GitHub (Jun 28, 2026):

This is sad. I have been fighting with site-to-site all night, to find out their documentation is just made up at this point, because site-to-site does not work at all! Only VPN-to-site works

<!-- gh-comment-id:4825188679 --> @stratacast commented on GitHub (Jun 28, 2026): This is sad. I have been fighting with site-to-site all night, to find out their documentation is just made up at this point, because site-to-site does not work at all! Only VPN-to-site works
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#8844