diff --git a/public/docs-static/img/how-to-guides/network-acl-create-policy.png b/public/docs-static/img/how-to-guides/network-acl-create-policy.png new file mode 100644 index 00000000..cb65082a Binary files /dev/null and b/public/docs-static/img/how-to-guides/network-acl-create-policy.png differ diff --git a/public/docs-static/img/how-to-guides/network-acl-new-policy.png b/public/docs-static/img/how-to-guides/network-acl-new-policy.png new file mode 100644 index 00000000..e29f6cff Binary files /dev/null and b/public/docs-static/img/how-to-guides/network-acl-new-policy.png differ diff --git a/public/docs-static/img/how-to-guides/network-route-acl-group-settings.png b/public/docs-static/img/how-to-guides/network-route-acl-group-settings.png new file mode 100644 index 00000000..69d24664 Binary files /dev/null and b/public/docs-static/img/how-to-guides/network-route-acl-group-settings.png differ diff --git a/public/docs-static/img/how-to-guides/network-route-acl-saved.png b/public/docs-static/img/how-to-guides/network-route-acl-saved.png new file mode 100644 index 00000000..f9cf9d84 Binary files /dev/null and b/public/docs-static/img/how-to-guides/network-route-acl-saved.png differ diff --git a/public/docs-static/img/how-to-guides/network-route-acl.png b/public/docs-static/img/how-to-guides/network-route-acl.png new file mode 100644 index 00000000..f7d0458e Binary files /dev/null and b/public/docs-static/img/how-to-guides/network-route-acl.png differ diff --git a/src/components/NavigationDocs.jsx b/src/components/NavigationDocs.jsx index c15e6ede..bb0f5bfe 100644 --- a/src/components/NavigationDocs.jsx +++ b/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' }, ] }, diff --git a/src/pages/how-to/configuring-routes-with-access-control.mdx b/src/pages/how-to/configuring-routes-with-access-control.mdx new file mode 100644 index 00000000..8471fd0c --- /dev/null +++ b/src/pages/how-to/configuring-routes-with-access-control.mdx @@ -0,0 +1,144 @@ +# Configuring routes with access control + + + This feature is available from NetBird version 0.30.0 onwards. + + +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. + + + 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. + + +## Creating Access Control Policy + +After 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` + +

+ high-level-dia +

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

+ high-level-dia +

+ +## Creating a network route with access control group + +Access the `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` + +

+ high-level-dia +

+ +

+ high-level-dia +

+ +Once you fill in the route information, you can click on the `Add Route` button +to save your new route. +

+ high-level-dia +

+ +Done! Now, every peer connected to your routing peer will be able to send TCP +traffic on port 80 to your external network according to 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
Routing Client] --- B[NetBird Peer B
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.