Add network routes access control

src/components/NavigationDocs.jsx

@@ -73,6 +73,7 @@ export const docsNavigation = [
              links: [
                  { title: 'Routing traffic to private networks', href: '/how-to/routing-traffic-to-private-networks' },
                  { title: 'Configuring default routes for Internet traffic', href: '/how-to/configuring-default-routes-for-internet-traffic' },
+                 { title: 'Configuring routes with access control', href: '/how-to/configuring-routes-with-access-control' },
                  { title: 'Resolve overlapping routes', href: '/how-to/resolve-overlapping-routes' },
              ]
          },

src/pages/how-to/configuring-routes-with-access-control.mdx

@@ -0,0 +1,145 @@
+# Configuring routes with access control
+
+<Note>
+    This feature is available from NetBird version 0.30.0 onwards.
+</Note>
+
+By default, network routes allow unrestricted access, meaning any traffic can
+flow through the routes without limitations. This behavior occurs when access
+control groups are not associated with a route. However, when access control
+groups are set, the route inherits access restrictions based on the defined
+policies. Only traffic that meets the criteria specified in these policies can
+access the internal services, ensuring that your network remains secure and that
+only authorized users can reach sensitive resources.
+
+## Route Access Policies and Access Control Groups
+
+Route access policies are unidirectional, applying only from routing
+client to routing peer. Consequently, the access control group only takes effect
+if used as a destination group in the policy.
+
+If an empty group (containing no peers) is used for the access control group
+(and subsequently in the policy), then only the routed network will be affected
+by the access policy, not the routing peer itself.
+
+<Note>
+    If an access control group was applied to the route but no route access policies are
+    enabled or none exist, all routed traffic will be dropped.
+    This contrasts with scenarios where no access control group is applied, in
+    which case all traffic is permitted.
+</Note>
+
+##  Creating a network route with access control group
+Since release `0.30.0`, the management service and dashboard support access control groups for network routes.
+
+To add a Network route with access control groups, access the menu `Network Routes` tab and click the `Add Route` button to create a new route.
+
+In the example below, we are creating a route with the following information:
+
+- Network identifier: `aws-eu-central-1-vpc`
+- Description: `Production VPC in Frankfurt`
+- Network range: `10.10.0.0/16`
+- Routing peer: `server`
+- Distribution Groups: `devs`
+- Access Control Groups: `servers`
+
+<p>
+    <img src="/docs-static/img/how-to-guides/network-route-acl.png" alt="high-level-dia" className="imagewrapper-big"/>
+</p>
+
+Click on `Continue` to proceed.
+
+<p>
+    <img src="/docs-static/img/how-to-guides/network-route-acl-group-settings.png" alt="high-level-dia" className="imagewrapper-big"/>
+</p>
+
+Once you fill in the route information, you can click on the `Add Route` button to save your new route.
+<p>
+    <img src="/docs-static/img/how-to-guides/network-route-acl-saved.png" alt="high-level-dia" className="imagewrapper-big"/>
+</p>
+
+Because you used an access control group, you will be prompted to create a new policy.
+<p>
+    <img src="/docs-static/img/how-to-guides/network-route-acl-prompt.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+
+Click on the `Create Policy` button to proceed.
+
+## Creating Access Control Policy
+If you didn't use the prompt, you can create a new policy by accessing the `Access Control` > `Policies` tab, click on the `Add policy` button to create a new policy.
+In the popup, specify source and destination groups, and add Posture Checks if needed. Make sure to set traffic
+direction only when TCP or UDP protocols are selected. Finally, provide a name and description for your policy.
+
+In the example below, we are creating a one direction policy with the following information:
+- Name: `Devs to Servers`
+- Description: `Devs are allowed to access servers`
+- Protocol: `TCP`
+- Ports: `80`
+- Source Groups: `devs`
+- Destination Groups: `servers`
+
+<p>
+    <img src="/docs-static/img/how-to-guides/network-acl-create-policy.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+
+
+If necessary, you can create new groups simply by entering new names in the input box for either the source or destination lists.
+
+Once you have finished configuring the policy, click `Add Policy` to save it. You will then see your new policy in the table.
+<p>
+    <img src="/docs-static/img/how-to-guides/network-acl-new-policy.png" alt="high-level-dia" className="imagewrapper-big"/>
+</p>
+
+Done! Now, every peer connected to your routing peer can only access port 80 services on the routed network,
+as specified by the defined policy.
+
+## Site-to-Site Traffic Configuration
+
+For site-to-site traffic (where routes are set up in both directions with one
+peer in the distribution group and the other as the routing peer, and vice
+versa), there are two configuration scenarios:
+
+1. With Masquerading Enabled:
+
+- To subject site-to-site traffic to route access policies, ensure masquerading
+  is enabled.
+- You'll need to set up two policies, one for each direction/site.
+
+2. Without Masquerading:
+
+- If masquerading is disabled, access control groups need not be applied.
+- This configuration allows unrestricted access in both directions.
+
+Choose the appropriate configuration based on your security requirements and
+network setup.
+
+## Behavior Changes in Version 0.30.0
+
+Prior to version 0.30.0, routing clients would accept any traffic initiated from
+routed networks behind routing peers. From version 0.30.0 onwards, routing
+clients only accept return traffic for connections initiated by routing clients.
+
+To illustrate this change, consider the following example:
+
+```mermaid
+graph LR
+    A[NetBird Peer A<br>Routing Client] --- B[NetBird Peer B<br>Routing Peer]
+    B --- C[Routed Network]
+```
+
+Pre-0.30.0: Peer A would accept connections initiated from the Routed Network
+through Peer B.
+
+Post-0.30.0: Peer A only accepts return traffic for connections it initiates to
+the Routed Network through Peer B.
+
+To allow traffic initiated from the routed network in version 0.30.0 and later:
+
+1. Ensure masquerade is enabled for the route.
+2. Add a peer access policy to allow specific traffic from the routing peer to
+   the routing client. This is required whether route access policies are set up
+   or not. The traffic flow should be:
+   Routing Client (Peer A) < -- Routing Peer (Peer B)
+
+This configuration allows the routing client (Peer A) to accept incoming traffic
+from the routing peer (Peer B), which may originate from the routed network.

src/pages/how-to/routing-traffic-to-private-networks.mdx

@@ -93,6 +93,17 @@ Distribution groups define that peers that belong to these groups set in this fi
     It doesn't remove the need for the routing peer to be connected to these peers
 </Note>
 
+### Access Control Groups
+These groups provide granular control over internal services within your network. They are used as the destination
+groups in access control policies, allowing you to precisely define which internal services can be accessed by
+different network entities.
+
+When you associate these groups with specific routes, the routes will inherit the access control policies where
+the groups are defined as part of destination groups. This setup enforces access restrictions based on the policies,
+ensuring that only authorized traffic can reach the designated services.
+
+Routes that do not incorporate these groups will permit unrestricted access, allowing all traffic to pass through
+without any limitations.
 
 ## Managing network routes
 A network route describes a network you want to connect with your NetBird peers. It has an identifier, a network range, a routing peer or set of peer groups, and some parameters available for managing priority and masquerading.