ACLs have no effects on Network Routes

[benjvfr]

Describe the problem When adding a network route with a routing peer, the ACL do not seems to apply. See below for the complete use case. (NetBird 0.25.2)

To Reproduce Steps to reproduce the behavior:

1. Add a routing peer named "edge-gw" (Docker) which is placed in the DMZ of the private network. The underlying network is configured to let this routing peer being able to route to a service (my-private-service) hosted in the private network at 10.50.0.4/32 (web service on TCP 443).

2. Tag the "edge-gw" routing peer with "Edge" tag.

3. In "Network Routes", click "Add route" :

   • Network Identifier > my-private-service
   • Network Range > 10.50.0.4/32
   • Routing Peer > Select "edge-gw"
   • Distribution groups > "Developers"
   • Enabled > True
   • Masquerade > True

4. In "Access Control" :

   • All rules are disabled, except for DNS forwarding (which is routed through the same "edge-gw" routing peer).

5. On a "dev-peer" machine, which belongs to the 'Developers" group :

   • "netstat -nr" show the route 10.50.0.4/32 being distributed (which seems right)
   • curl https://my-private-service.<redacted-domain> (10.50.0.4) returns the web HTML page, which seems wrong as no ACL rules are setup to allow traffic for TCP 443 in NetBird ACL. Same for pinging 10.50.0.4.

Expected behavior If no ACL are enabled, traffic should not be forwarded to the private network via routing peer (even if route is distributed). As no ACL route exists for "Developers > Edge" on TCP 443, traffic should be dropped. This is not the case.

Screenshots

1. Routing peer "edge-gw" :

2. Network routes

   

3. ACL

   

4. Dev peer

   

Is this the normal behavior ? Or I misconfigured something ?

[benjvfr]

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.

[mlsmaycon]

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.

[benjvfr]

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...).

[buzzzo]

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

[logan-hcg]

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]

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:

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".

[florian-obradovic]

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:

[marcportabellaclotet-mt]

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!

[sat-dish]

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

[Mntz]

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