Input chain rules on routing peers for subnet resources

[mrlhansen]

I am not really sure if the following is intentional or not.

I defined a network under "Networks" and the network has several subnets as resources. Next I create an ACL for accessing one of the subnets (e.g. 192.168.0.0/16) by choosing the subnet resource as the destination.

The network has two routing peers, and these peers have a local address inside the 192.168.0.0/16 subnet. The IP address on the routing peer is not accessible due to missing rules in the input chain, while IPs residing on other machines are accessible, because the forwarding chain is correct.

The routing peers are Linux machines and I see the missing rules in the input chain when dumping the nftables.

To Reproduce

Steps to reproduce the behavior:

1. Create a network with the subnet 192.168.0.0/16 as a resource.
2. Assign a routing peer for the network.
3. Create an ACL for accessing the 192.168.0.0/16 subnet.
4. On the node for the routing peer assign the IP address 192.168.1.1
5. Try to ping the 192.168.1.1 from another peer that has access to the 192.168.0.0/16 via the before mentioned ACL.
6. Ping fails due to missing rules in the input chain.

Expected behavior

I would expect the input chain to also honor traffic to the allowed subnet.

Are you using NetBird Cloud?

I am using self-host NetBird's control plane.

NetBird version

0.55.1

Is any other VPN software installed?

No.

Additional context

Here is a partial dump of the nftable rules. The two peers 100.69.3.60, 100.69.42.193 have access to all resources on the routing peers, while 100.69.196.121 only has access to the 10.128.0.0/24 subnet.

table ip netbird {
	set nb0000001 {
		type ipv4_addr
		flags dynamic
		elements = { 100.69.3.60, 100.69.42.193 }
	}

	set nb-4776d0f5 {
		type ipv4_addr
		flags interval
		elements = { 100.69.3.60, 100.69.42.193 }
	}

	set nb-70e1f9f5 {
		type ipv4_addr
		flags interval
		elements = { 100.69.3.60, 100.69.42.193,
			     100.69.196.121 }
	}

	chain netbird-rt-fwd {
		ct state established,related counter packets 5 bytes 306 accept
		...
		ip saddr @nb-4776d0f5 ip daddr 10.132.0.0/24 counter packets 0 bytes 0 accept
		ip saddr @nb-4776d0f5 ip daddr 10.128.0.0/24 counter packets 0 bytes 0 accept
		ip saddr @nb-70e1f9f5 ip daddr 10.128.0.0/24 counter packets 0 bytes 0 accept
	}

	chain netbird-acl-input-rules {
		ct state established,related counter packets 468 bytes 112631 accept
		ip saddr @nb0000001 accept
	}

	chain netbird-acl-input-filter {
		type filter hook input priority filter; policy accept;
		iifname "wt0" jump netbird-acl-input-rules
		iifname "wt0" drop
	}

	chain netbird-acl-forward-filter {
		type filter hook forward priority filter; policy accept;
		meta mark 0x0001bd20 accept
		iifname "wt0" jump netbird-rt-fwd
		iifname "wt0" drop
	}
}

[nazarewk]

While this is still work in progress, please take a look at the explanation at netbirdio/docs#401

PS: yes, the PR contains one big screenshot

[mrlhansen]

@nazarewk Yes, this is does exactly describe the "issue" that I am seeing. I assume the solution is just a secondary rule to give access to the local peer address.

[nazarewk]

I assume the solution is just a secondary rule to give access to the local peer address.

exactly

[mrlhansen]

Thanks for the help, I am closing the issue.