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-prompt.png b/public/docs-static/img/how-to-guides/network-route-acl-prompt.png new file mode 100644 index 00000000..0830c28c Binary files /dev/null and b/public/docs-static/img/how-to-guides/network-route-acl-prompt.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..a32a574d 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 15220143..8a44e3ab 100644 --- a/src/components/NavigationDocs.jsx +++ b/src/components/NavigationDocs.jsx @@ -97,6 +97,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..be4b36d4 --- /dev/null +++ b/src/pages/how-to/configuring-routes-with-access-control.mdx @@ -0,0 +1,145 @@ +# 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 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` + +

+ high-level-dia +

+ +Click on `Continue` to proceed. + +

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

+ +Because you used an access control group, you will be prompted to create a new policy. +

+ high-level-dia +

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

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

+ +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
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. \ No newline at end of file diff --git a/src/pages/how-to/routing-traffic-to-private-networks.mdx b/src/pages/how-to/routing-traffic-to-private-networks.mdx index 2a1af16d..5a75168c 100644 --- a/src/pages/how-to/routing-traffic-to-private-networks.mdx +++ b/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 +### 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.