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.78k stars 487 forks source link

access policies are not working on /32 routes #1750

Open ez1976 opened 6 months ago

ez1976 commented 6 months ago

Hello. question regarding Relays and access control i have 3 linux machines configured as Relays. 2 in our on-prem and one in AWS all 3 relays can communicate between them and all 3 of them can access all the networks and routes. now i am trying to create a dedicated route to limit peers to access ONLY 4 machines with /32 in their route. If i put the peer in the group that has access to the cidr that the relays are , then the remote peer can access anything he needs. so i created 3 different routes for each relay with /32 in their CIDR and gave access to all the groups on the server. then i created an access policy that gives all the groups access to those 3 relay route entries so they can still ping and communicate with them. (even gave it 50 in the prioriy) but as soon as i put the peer inside the isolated group, he cant communicate with anyone (including the internal 100.X.X.X network). cannot ping the internal or real IP address of the relays. guessing if he cant access the relay, he cant access the remote route.

this is after putting the peer inside the isolated group: [root@opencachehub ~]# netbird status -d Peers detail: Daemon version: 0.26.3 CLI version: 0.26.3 Management: Connected to https://connect.qwilt.com:33073/ Signal: Connected to http://connect.qwilt.com:10000/ Relays: [stun:connect.qwilt.com:3478] is Available [turn:connect.qwilt.com:3478?transport=udp] is Available Nameservers: [52.8.5.13:53, 10.66.25.96:53] for [.] is Available FQDN: opencachehub.vpn.qwilt.com NetBird IP: 100.120.178.106/16 Interface type: Userspace Quantum resistance: false Routes: - Peers count: 0/0 Connected [root@opencachehub ~]#

trying to ping the relay [root@opencachehub ~]# ping 100.120.81.117 PING 100.120.81.117 (100.120.81.117) 56(84) bytes of data. but after putting the peer inside the access policy that gives access to /24 of the network it works: [root@opencachehub ~]# ping us-w1-relay01.it.qwilt.com PING us-w1-relay01.it.qwilt.com (10.66.25.56) 56(84) bytes of data. 64 bytes from us-w1-relay01.it.qwilt.com (10.66.25.56): icmp_seq=1 ttl=64 time=1.63 ms 64 bytes from us-w1-relay01.it.qwilt.com (10.66.25.56): icmp_seq=2 ttl=64 time=1.73 ms 64 bytes from us-w1-relay01.it.qwilt.com (10.66.25.56): icmp_seq=3 ttl=64 time=1.80 ms ^C --- us-w1-relay01.it.qwilt.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.636/1.727/1.809/0.085 ms [root@opencachehub ~]# ping 100.120.81.117 PING 100.120.81.117 (100.120.81.117) 56(84) bytes of data. 64 bytes from 100.120.81.117: icmp_seq=1 ttl=64 time=1.79 ms 64 bytes from 100.120.81.117: icmp_seq=2 ttl=64 time=1.72 ms 64 bytes from 100.120.81.117: icmp_seq=3 ttl=64 time=1.82 ms ^C --- 100.120.81.117 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.722/1.780/1.826/0.055 ms [root@opencachehub ~]#

does access policies support /32 at all? do i need to put the relay servers in a dedicated vlan and give the remote peers full access to that vlan? and that vlan can access all the other networks on our internal network?

tried putting the relay peer group in the isolated group but still no access unless i give it access to the full /24 network

pascal-fischer commented 6 months ago

Hi @ez1976, I am not sure I can follow what is happening. So you have:

From the status output it looks like the peer in the isolated group can not communicate with any other peers because it shows Peers count: 0/0 Connected so it is not receiving any peers from management