FORWARD don't work properly

[barto95100]

Describe the problem
Host A test to ping other host (B), don't work but if the node netbird on LAN A ping the host (B) is ok

The route is configured on netbird dashboard

[Fantu]

Hi, I think it is useful to know more information, at least netbird version used as 0.24.4 have changes/fix relating forward #1305

[mlsmaycon]

Hello @barto95100 can you share the following details of your setup?

• is there are any custom configurations for the host A to access the IP of host B? any external routes, or custom firewall rules in any of the hosts?
• is NetBird A able to reach host B?

[barto95100]

My responsable :
is there are any custom configurations for the host A to access the IP of host B? any external routes, or custom firewall rules in any of the hosts?

YEs the host A sens paquet to routeur (gateway of host A) and on gateway (mikrotik) I havé a route to indicate to Subnet B -> NEtbird A, I start tcpdump on netbird 1 to view if paquet is received and it’s OK, and on netbird B nothing arrived from Netbird1

is NetBird A able to reach host B?

YEs netbird A access all host behind Netbird B

[mlsmaycon]

Hello @barto95100 ,

You need to add forward and maybe nat rules on netbird A:

sudo nft insert rule ip filter FORWARD ip saddr 10.150.10.49/32 accept
sudo nft insert rule ip filter FORWARD ip daddr 10.150.10.49/32  accept
sudo nft insert rule ip netbird netbird-rt-nat ip daddr 10.150.10.49/32  counter masquerade

[ydkn]

Hi there,

I also have an issue with the current version (0.24.4) that looks similar to the problem described here. If I downgrade to 0.24.3 everything works fine again.

To my env:
It is self-hosted and consists of 3 sites with a separate subnet behind Netbird (Netbird running on the gateway for each site). I have multiple routing rules so each site can reach systems in the subnets at the other sites (no masquerading).

It stopped working after upgrading to 0.24.4 from 0.24.3. Enabling masquerading in the routes also did not work. If I manually add the masquerading rule using iptables it starts working again.

From what I seen using tcpdump it looks like packets are not forwarded - e.g. (IPs are from the subnets of 2 sites - trying to ping a server from the subnet of site A (172.28.64.0/18) in the subnet of site B (172.28.0.0/18))

09:24:39.674826 IP 172.28.116.63 > 172.28.0.2: ICMP echo request, id 26408, seq 245, length 64
09:24:40.681451 IP 172.28.116.63 > 172.28.0.2: ICMP echo request, id 26408, seq 246, length 64
09:24:41.680920 IP 172.28.116.63 > 172.28.0.2: ICMP echo request, id 26408, seq 247, length 64
09:24:42.682501 IP 172.28.116.63 > 172.28.0.2: ICMP echo request, id 26408, seq 248, length 64
09:24:43.687602 IP 172.28.116.63 > 172.28.0.2: ICMP echo request, id 26408, seq 249, length 64
09:24:44.689743 IP 172.28.116.63 > 172.28.0.2: ICMP echo request, id 26408, seq 250, length 64
09:24:45.694963 IP 172.28.116.63 > 172.28.0.2: ICMP echo request, id 26408, seq 251, length 64

I already tried adding a few FORWARD ACCEPT rules with iptables incl. the nft rules from @mlsmaycon above without any success.

[mlsmaycon]

Hello @ydkn, can you share more information about your network setup and firewall rules added manually?

Is there any rules that you added before that is not being used in the new nftables chains?

[ydkn]

Hi @mlsmaycon,

As I'm trying to use the setup without masquerading there are not much rules in place - see attached diagram for reference.

The configured routes also look fine - e.g. on 172.28.0.2:

172.28.64.0/18 via 172.29.254.112 dev wt0 
172.28.128.0/18 via 172.29.254.112 dev wt0 
172.29.252.0/22 dev wt0 proto kernel scope link src 172.29.254.112 

I also did restarts of the gateway servers to avoid any rules that I added during testing interfere with the setup.

[mlsmaycon]

@ydkn thanks for sharing. Can you confirm that the gateways are also unable to connect to the IPs behind the other gateways?

[ydkn]

@mlsmaycon I dug a little deeper and figured this out:

I had Netbird running not only on the gateways but also on most of the servers within the subnets of the site. Routing is setup to always use the local gateway for the other sites and also the routing rules in netbird only use the instance running on the gateway nodes to avoid routing conflicts. (That allowed my to have a fallback in case there is an issue with gateway gateway itself - internet access would still work)

The routes in Netbird are only assigned to the instances running on the gateway servers (there is also no route configured on the other systems running Netbird within the local subnet - so this seems to work)

If I shutdown Netbird on the other systems (and the local routing is used). I can reach systems behind the gateway from behind another gateways but not the gateway IP itself (local IP).
Example: I can ping 172.28.0.3 from 172.28.64.0/18 but NOT 172.28.0.2

[ydkn]

Correction on my last post:
Even with the Netbird agent running on other servers within the local subnet I can reach them from another site. I only have problems reaching things on the gateway server that do not use the Wiregurad/Netbird IP.

This would point into the direction that local forwarding does not work correctly.

If I ping the local IP of a remote gateway from another gateway it also works. I only can't reach the remote gateway IP from another subnet.

Example:
From 172.28.64.0/18 I can reach 172.28.0.0/18 except 172.28.0.2 (gateway) which is only reachable from 172.28.64.32 (gateway)

[Horus-K]

After setting up iptables, the network can be connected ， but，I want to know why the https protocol does not take effect

[mlsmaycon]

After setting up iptables, the network can be connected ， but，I want to know why the https protocol does not take effect

@Horus-K can you check configuring a larger MTU (e.g. 1420) for the nodes involved?

[mlsmaycon]

@ydkn , would you join our Slack workspace to troubleshooting your issue?