netbirdio / netbird

Connect your devices into a secure WireGuard®-based overlay network with SSO, MFA and granular access controls.
https://netbird.io
BSD 3-Clause "New" or "Revised" License
10.81k stars 490 forks source link

Issues with site-2-site VPN on version 0.25.9 #1623

Open deB4SH opened 7 months ago

deB4SH commented 7 months ago

Describe the problem

NOTE: this is copies from a slack thread

Hi all, I have a selfhosted netbird running with three clients joined. All clients should share their specific lan environments with each other and allow other devices in their own network to use the others. I already have setup all network routes required and configured the according ip ranges, routing peers, distribution groups and masquerade for each route. The hosts with the client installed are able to reach ips in other local networks but sadly not other hosts using them as gateway.

As example: 192.168.10.0/24 made available over node-1 ( .10.2) 192.168.11.0/24 made available over node-2 ( .11.2)

Routers in each network do provide a network route for clients to communicate towards the other network over the given gateway ip. Node-1 can reach ips within the .11 network. When tracerouting from a host near to node-1 it gets stuck on node-1 and the traffic is not forwarded over the wireguard interface

What configuration did I miss? Did i missunderstood the automatic masquerade setup of netbird?

Somehow I can't get site-to-site vpn working with netbird. Seems that the masquerading is not working properly. Before my switch to netbird I configured all "ingress"-nodes to each site via PostUp and PostDown to build up the masquarade rules via iptables

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE;

The issue resolved when downgrading to version 0.25.4 from 0.25.9 Also needed to add an iptable entry for the masquerade iptables -t nat -A POSTROUTING -o wt0 -j MASQUERADE

To Reproduce

Steps to reproduce the behavior:

  1. Setup Netbird in different Networks
  2. Create Access Rules and Network Configurations to share networks to each other instance
  3. enable masquarade

Expected behavior

Working site 2 site networking

Are you using NetBird Cloud?

selfhosted

xiaolei0125 commented 7 months ago

I also encountered a similar issue when using 0.25.8, but it was resolved after rolling back to 0.24.3.

ednxzu commented 5 months ago

I also have the same issue, tho the peers in each of my sites can ping and connect to remote machines on their netbird IP (100.x.y.z).

I was using latest, tried to roll back as advised here, but it didn't change anything.

I'll keep posting if I make any progress.

deB4SH commented 5 months ago

I'm still on 0.25.4 and need to manually add need to manually add iptables -t nat -A POSTROUTING -o wt0 -j MASQUERADE after each boot. (iptable-save) After this everything work quite well - maybe you are missing the postrouting @ednxzu ?

ednxzu commented 5 months ago

I forgot to report back, but I managed to get it to work.

Each nodes on each site needed: -A FORWARD -d -j ACCEPT -A FORWARD -s -j ACCEPT

these had to be added manually (maybe an improvement ?)

where subnet_of_remote_site is the subnet englobing all your site LAN, in my case, each site gets 10.x.0.0/16 so site 1 would be 10.1.0.0/16, site 2 10.2.0.0/16

to be manually added. Other than that, I had issue with port security in openstack not allowing traffic from the tunnel network to exit the router instance.

using the latest version worked in my case.

dobe commented 4 months ago

same here using. netbird version 0.27.6 i also need to:

iptables -t nat -A POSTROUTING -o wt0 -j MASQUERADE

expecting this to be configured automatically

cassidea commented 4 months ago

Each nodes on each site needed: -A FORWARD -d -j ACCEPT -A FORWARD -s -j ACCEPT

these had to be added manually (maybe an improvement ?)

Same here. Unfortunately I couldn't get it working in systemd's ExecStartPre or ExecStartPost-hook but had to execute it manually. The rules showed up in iptables -S but packets wouldn't be handled correctly.

My current solution: in systemd-script: ExecStartPre=iptables -t nat -A POSTROUTING -o wt0 -j MASQUERADE manually after every reboot: sudo iptables -A FORWARD -s 10.0.0.0/16 -j ACCEPT; sudo iptables -A FORWARD -d 10.0.0.0/16 -j ACCEPT