ACLs have no effects on Network Routes #561

@benjvfr commented on GitHub (Dec 28, 2023):

After further troubleshooting, here is what I found :

If there is at least on ACL allowing traffic to "Edge" (here "All to Edge DNS" ; UDP/53), all type of connections related to the connected Network Routes are allowed (even if the ACL specified UDP/53).
This explain why the TCP/443 or ICMP are forwarded to private network through the Edge routing peer.

So for my use case :

Disabling the ACL "All to Edge DNS" restrict pinging 10.50.0.4 (intended) => The route 10.50.0.4/32 is not pushed to clients ; therefore pinging 10.50.0.4 is not working (intended).
Enabling the ACL "All to Edge DNS" pushes route 10.50.0.4 to clients => All type of connections to 10.50.0.4 are allowed, even if the ACL specified UDP/53 ; ping to 10.50.0.4 is working... bug ?

It seems to be a bug.

@benjvfr commented on GitHub (Dec 28, 2023): After further troubleshooting, here is what I found : - If there is at least on ACL allowing traffic to "Edge" (here "All to Edge DNS" ; UDP/53), all type of connections related to the connected Network Routes are allowed (even if the ACL specified UDP/53). - This explain why the TCP/443 or ICMP are forwarded to private network through the Edge routing peer. So for my use case : - Disabling the ACL "All to Edge DNS" restrict pinging 10.50.0.4 (intended) => The route 10.50.0.4/32 is not pushed to clients ; therefore pinging 10.50.0.4 is not working (intended). - Enabling the ACL "All to Edge DNS" pushes route 10.50.0.4 to clients => All type of connections to 10.50.0.4 are allowed, even if the ACL specified UDP/53 ; ping to 10.50.0.4 is working... bug ? It seems to be a bug.

saavagebueno commented

@mlsmaycon commented on GitHub (Jan 3, 2024):

Hello @benjvfr, this is the current behavior of network routes; there is no access control for routed networks.

The access control rule you created only affects traffic targeting the edge node.

We have plans to add support to access control for routed networks this quarter.

@mlsmaycon commented on GitHub (Jan 3, 2024): Hello @benjvfr, this is the current behavior of network routes; there is no access control for routed networks. The access control rule you created only affects traffic targeting the edge node. We have plans to add support to access control for routed networks this quarter.

saavagebueno commented

@benjvfr commented on GitHub (Jan 3, 2024):

Hello, thank you for your answer.

Okay, I asked because in your documentation related to "Manage DNS in your network" it is indicated to add an ACL for UDP/53 to the routing peer, suggesting that ACLs can filter traffic by port/protocol to the private network.

In fact, any ACL can be added here, not specifically UDP/53 to routing peer : there must simply be an ACL authorizing some kind of connection to the routing peer (anything, can be: ICMP, HTTP...).

@benjvfr commented on GitHub (Jan 3, 2024): Hello, thank you for your answer. Okay, I asked because in your documentation related to "[Manage DNS in your network](https://docs.netbird.io/how-to/manage-dns-in-your-network#adding-remote-private-dns-servers)" it is indicated to add an ACL for UDP/53 to the routing peer, suggesting that ACLs can filter traffic by port/protocol to the private network. In fact, any ACL can be added here, not specifically UDP/53 to routing peer : there must simply be an ACL authorizing some kind of connection to the routing peer (anything, can be: ICMP, HTTP...).

saavagebueno commented

@buzzzo commented on GitHub (Jan 3, 2024):

Hello @benjvfr, this is the current behavior of network routes; there is no access control for routed networks.

The access control rule you created only affects traffic targeting the edge node.

We have plans to add support to access control for routed networks this quarter.

Does it means that we could just do an acl like:
src group_a -> dst 192.168.1.0/20 proto tcp port 22 action allow

where 192.168.1.0/24 is a network route

Could i also have an acl like
src group_a -> dst 192.168.1.1/32 proto tcp port 22 action allow
where 192.168.1.1/32 is only an ip under network route reachable tru network routes.

Thx

@buzzzo commented on GitHub (Jan 3, 2024): > Hello @benjvfr, this is the current behavior of network routes; there is no access control for routed networks. > > The access control rule you created only affects traffic targeting the edge node. > > We have plans to add support to access control for routed networks this quarter. Does it means that we could just do an acl like: src group_a -> dst 192.168.1.0/20 proto tcp port 22 action allow where 192.168.1.0/24 is a network route Could i also have an acl like src group_a -> dst 192.168.1.1/32 proto tcp port 22 action allow where 192.168.1.1/32 is only an ip under network route reachable tru network routes. Thx

saavagebueno commented

@logan-hcg commented on GitHub (Mar 28, 2024):

We have plans to add support to access control for routed networks this quarter.

Hi @mlsmaycon , any chance there has been progress on this? I really want to start using netbird at my org, but can't until we can lock down routed networks.

@logan-hcg commented on GitHub (Mar 28, 2024): > We have plans to add support to access control for routed networks this quarter. Hi @mlsmaycon , any chance there has been progress on this? I really want to start using netbird at my org, but can't until we can lock down routed networks.

saavagebueno commented

@logan-hcg commented on GitHub (Mar 29, 2024):

I did some additional experimentation with this. My initial main concern was being able to restrict what ports users could speak to on the routed network when they had access, however I think it is even more critical now.

If a connected peer routes a network, any client that has access to talk to that peer can pass traffic to the routed network, even if that client is not in any of the "distribution groups" for the routed network as long as:

the user knows the CIDR of the routed network; and
which peer(s) are the "routing peer"; and
have at least one ACL which allows them to communicate with that "routing peer"

To "manually" activate access to that routed network:

sudo ip route add <NETWORK/NETMASK> dev wt0 table netbird
sudo wg set wt0 peer <ROUTING_PEER_KEY> allowed-ips <EXISTING_ALLOWED_IPS>,<NETWORK/NETMASK>

This makes sense, because the Netbird documentation talks about "route distribution", and does not make any claims that it is a security boundary. However, I would expect many users would have a similar assumption as I did that there is some security checks preventing traffic being passed if the user's peer is not in the "distribution groups".

@logan-hcg commented on GitHub (Mar 29, 2024): I did some additional experimentation with this. My initial main concern was being able to restrict what ports users could speak to on the routed network when they had access, however I think it is even more critical now. If a connected peer routes a network, _any_ client that has access to talk to that peer can pass traffic to the routed network, even if that client is not in any of the "distribution groups" for the routed network as long as: 1. the user knows the CIDR of the routed network; and 2. which peer(s) are the "routing peer"; and 3. have at least one ACL which allows them to communicate with that "routing peer" To "manually" activate access to that routed network: ```bash sudo ip route add <NETWORK/NETMASK> dev wt0 table netbird sudo wg set wt0 peer <ROUTING_PEER_KEY> allowed-ips <EXISTING_ALLOWED_IPS>,<NETWORK/NETMASK> ``` This makes sense, because the Netbird documentation talks about "route distribution", and does _not_ make any claims that it is a security boundary. However, I would expect many users would have a similar assumption as I did that there is some security checks preventing traffic being passed if the user's peer is not in the "distribution groups".

saavagebueno commented

@florian-obradovic commented on GitHub (May 10, 2024):

I am also affected by this.

From my findings, clients only can access peers behind the routing peer, if you have any ACL which allows some protocol like ICMP to the network group where the advertising node sits:

@florian-obradovic commented on GitHub (May 10, 2024): I am also affected by this. From my findings, clients only can access peers behind the routing peer, if you have any ACL which allows some protocol like ICMP to the network group where the advertising node sits: ![image](https://github.com/netbirdio/netbird/assets/57985125/48449a6d-72ea-4663-8305-75758fddfbe6) ![CleanShot 2024-05-10 at 07 27 36@2x](https://github.com/netbirdio/netbird/assets/57985125/907f3ce0-0cb6-4310-b01b-d2545ff94df7) ![CleanShot 2024-05-10 at 07 19 57@2x](https://github.com/netbirdio/netbird/assets/57985125/88993393-2784-4368-9c89-545409ac00a7)

saavagebueno commented

@marcportabellaclotet-mt commented on GitHub (Jun 13, 2024):

Hello @benjvfr, this is the current behavior of network routes; there is no access control for routed networks.

The access control rule you created only affects traffic targeting the edge node.

We have plans to add support to access control for routed networks this quarter.

I am curious on how you are tackling the routed network filtering. Are there any updates?
Just looking into the current IPTables logic on routers, I understand that these iptable routes need to be updated with a more fine-grained rules.

Ip Tables router rules


Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  -- !100.113.0.0/16       100.113.0.0/16      
ACCEPT     all  --  100.113.0.0/16      !100.113.0.0/16      
NETBIRD-ACL-INPUT  all  --  100.113.0.0/16       100.113.0.0/16      
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
NETBIRD-RT-FWD  all  --  anywhere             anywhere            
NETBIRD-RT-FWD  all  --  anywhere             anywhere            
NETBIRD-RT-FWD  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             mark match 0x7e4
ACCEPT     all  --  anywhere             anywhere             mark match 0x7e4
NETBIRD-ACL-INPUT  all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  -- !100.113.0.0/16       100.113.0.0/16      
ACCEPT     all  --  100.113.0.0/16      !100.113.0.0/16      
NETBIRD-ACL-OUTPUT  all  --  100.113.0.0/16       100.113.0.0/16      
DROP       all  --  anywhere             anywhere            

Chain NETBIRD-ACL-INPUT (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8888
ACCEPT     tcp  --  anywhere             anywhere             tcp spt:8888
ACCEPT     tcp  --  anywhere             anywhere             tcp spt:http-alt
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http-alt

Chain NETBIRD-ACL-OUTPUT (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp spt:8888
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8888
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             anywhere             tcp spt:http-alt

Chain NETBIRD-RT-FWD (3 references)
target     prot opt source               destination         
ACCEPT     all  --  ip-10-170-0-2.eu-west-1.compute.internal  100.113.0.0/16      
ACCEPT     all  --  100.113.0.0/16       ip-10-170-0-2.eu-west-1.compute.internal 
....

Is that correct?

Thanks @mlsmaycon!

@marcportabellaclotet-mt commented on GitHub (Jun 13, 2024): > Hello @benjvfr, this is the current behavior of network routes; there is no access control for routed networks. > > The access control rule you created only affects traffic targeting the edge node. > > We have plans to add support to access control for routed networks this quarter. I am curious on how you are tackling the routed network filtering. Are there any updates? Just looking into the current IPTables logic on routers, I understand that these iptable routes need to be updated with a more fine-grained rules. <details> <summary><i>Ip Tables router rules </i></summary> ``` Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- !100.113.0.0/16 100.113.0.0/16 ACCEPT all -- 100.113.0.0/16 !100.113.0.0/16 NETBIRD-ACL-INPUT all -- 100.113.0.0/16 100.113.0.0/16 DROP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination NETBIRD-RT-FWD all -- anywhere anywhere NETBIRD-RT-FWD all -- anywhere anywhere NETBIRD-RT-FWD all -- anywhere anywhere ACCEPT all -- anywhere anywhere mark match 0x7e4 ACCEPT all -- anywhere anywhere mark match 0x7e4 NETBIRD-ACL-INPUT all -- anywhere anywhere DROP all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- !100.113.0.0/16 100.113.0.0/16 ACCEPT all -- 100.113.0.0/16 !100.113.0.0/16 NETBIRD-ACL-OUTPUT all -- 100.113.0.0/16 100.113.0.0/16 DROP all -- anywhere anywhere Chain NETBIRD-ACL-INPUT (2 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:8888 ACCEPT tcp -- anywhere anywhere tcp spt:8888 ACCEPT tcp -- anywhere anywhere tcp spt:http-alt ACCEPT tcp -- anywhere anywhere tcp dpt:http-alt Chain NETBIRD-ACL-OUTPUT (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp spt:8888 ACCEPT tcp -- anywhere anywhere tcp dpt:8888 ACCEPT tcp -- anywhere anywhere tcp dpt:http-alt ACCEPT tcp -- anywhere anywhere tcp spt:http-alt Chain NETBIRD-RT-FWD (3 references) target prot opt source destination ACCEPT all -- ip-10-170-0-2.eu-west-1.compute.internal 100.113.0.0/16 ACCEPT all -- 100.113.0.0/16 ip-10-170-0-2.eu-west-1.compute.internal .... ``` </details> Is that correct? Thanks @mlsmaycon!

saavagebueno commented

@sat-dish commented on GitHub (Jun 21, 2024):

We are also waiting on an update on this as it's kind of a show stopper for us.

@sat-dish commented on GitHub (Jun 21, 2024): We are also waiting on an update on this as it's kind of a show stopper for us.

saavagebueno commented

@Mntz commented on GitHub (Jul 16, 2024):

Same, we're currently testing Netbird and won't be able to deploy if network routes are not secured.

@Mntz commented on GitHub (Jul 16, 2024): Same, we're currently testing Netbird and won't be able to deploy if network routes are not secured.

saavagebueno commented

@Lamera commented on GitHub (Sep 18, 2024):

@mlsmaycon @braginini When will this PR https://github.com/netbirdio/netbird/pull/2100 be merged?

@Lamera commented on GitHub (Sep 18, 2024): @mlsmaycon @braginini When will this PR https://github.com/netbirdio/netbird/pull/2100 be merged?

saavagebueno commented

@mlsmaycon commented on GitHub (Sep 18, 2024):

We plan it for the 0.30 release in the coming weeks.

@mlsmaycon commented on GitHub (Sep 18, 2024): We plan it for the 0.30 release in the coming weeks.

saavagebueno commented

@florian-obradovic commented on GitHub (Sep 18, 2024):

@mlsmaycon ❤️

We currently use a subnet router and a firewall in between.

We announce routes without masquerading so we can use the Netbird static client IPs in firewall rules.

@florian-obradovic commented on GitHub (Sep 18, 2024): @mlsmaycon ❤️ We currently use a subnet router and a firewall in between. We announce routes **without masquerading** so we can use the Netbird static client IPs in firewall rules.

saavagebueno commented

@mgarces commented on GitHub (Oct 28, 2024):

this has been released since 0.30.0 were you able to test it? You can now assign a Network Route ACL; the name you pic there will need to be in the destination section of the Policy you create.

@mgarces commented on GitHub (Oct 28, 2024): this has been released since `0.30.0` were you able to test it? You can now assign a Network Route ACL; the name you pic there will need to be in the destination section of the Policy you create.

saavagebueno commented

@buzzzo commented on GitHub (Oct 29, 2024):

this has been released since 0.30.0 were you able to test it? You can now assign a Network Route ACL; the name you pic there will need to be in the destination section of the Policy you create.

I see the network routes now as selectable objects in the policy page. But what happens if i would just create a policy having for example as destination 192.168.1.1/32 and NOT the whole 192.168.1.0/24 of a network routes ?

@buzzzo commented on GitHub (Oct 29, 2024): > this has been released since `0.30.0` were you able to test it? You can now assign a Network Route ACL; the name you pic there will need to be in the destination section of the Policy you create. I see the network routes now as selectable objects in the policy page. But what happens if i would just create a policy having for example as destination 192.168.1.1/32 and NOT the whole 192.168.1.0/24 of a network routes ?

saavagebueno commented

@jacac commented on GitHub (Oct 29, 2024):

I've upgraded to 0.30.3 but cannot find the group tab to specify the access control group. This is on a self hosted server.

@jacac commented on GitHub (Oct 29, 2024): I've upgraded to `0.30.3` but cannot find the group tab to specify the access control group. This is on a self hosted server. ![image](https://github.com/user-attachments/assets/209cc28d-87a3-4f24-b59a-eb456b3095a0)

saavagebueno commented