Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend route access policy docs #233

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
1 change: 1 addition & 0 deletions src/components/NavigationDocs.jsx
Original file line number Diff line number Diff line change
Expand Up @@ -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' },
]
},
Expand Down
144 changes: 144 additions & 0 deletions src/pages/how-to/configuring-routes-with-access-control.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,144 @@
# 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 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`

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

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

<p>
<img src="/docs-static/img/how-to-guides/network-route-acl.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>

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

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