sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-10-26 22:49:04 +01:00
Code Issues Packages Projects Releases Wiki Activity

Restructuring Phase 3 (#492)

Browse Source
This commit is contained in:
Brandon Hopkins
2025-11-24 18:25:44 +01:00
committed by GitHub
parent c40c132caa
commit 0080ae97df
477 changed files with 800 additions and 564 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pages/manage/network-routes/configuring-default-routes-for-internet-traffic.mdx
+129
View File
@@ -0,0 +1,129 @@
# Configuring default routes for Internet traffic
NetBird introduces a way to redirect a peer's internet traffic through what is commonly known as exit nodes.
This setup allows you to direct all internet-bound traffic from your devices through a specified routing
peer.
<Note>
This feature is available from Netbird version v0.27.0 onwards.
</Note>
## Concepts
### Default Routes
A default route, specified with the network address `0.0.0.0/0` for IPv4 and `::/0` for IPv6, directs internet-bound
traffic from your devices
through a designated routing peer.
<Note>
Currently, IPv6 traffic is not supported and is blocked to prevent unintentional traffic leakage.
</Note>
### Routing Peer
The routing peer functions as the exit node for the Internet traffic. Once configured, it automatically handles traffic
it receives from connected peers, applying masquerading to ensure traffic appears to originate from the routing peer's
public IP address.
### Distribution Groups
Peers within the specified distribution group are configured to send their Internet traffic to the routing peer over the
VPN.
This setup is activated as soon as the routing peer is connected.
### Exit Node Selection and Auto Apply Behavior
Administrators configure exit nodes from the dashboard, and can optionally mark the default route (0.0.0.0/0) as selected by default. Clients will then auto-apply the selected exit node if the route is configured with **Auto Apply** or the user has made a local choice on the device.
- **Auto Apply**: when enabled on an exit node route, clients will auto-apply that exit node. Users can still manually disable it from the client if they choose to use that exit node.
- **Client override**: if a user selects or deselects an exit node on their device, that local choice takes precedence over the management server’s preference. This includes the ability to deselect a forced/selected route sent by management.
<Note>
Management can provide preferences for exit node selection, but the client user’s explicit selection or deselection is always respected on that device.
</Note>
<Note>
Exit node auto-apply feature requires NetBird client **v0.55.0** or later.
</Note>
### Existing exit node routes
Exit node routes that existed before the Auto Apply feature are treated as if **Auto Apply** is enabled by default. This preserves previous behavior where exit nodes were applied automatically when distributed.
- Clients running v0.55.0 or later will auto-apply these existing routes unless the user has explicitly selected/deselected an exit node on the device.
- Administrators can edit any exit node route in the dashboard to change its Auto Apply setting at any time.
## Configuration Steps
### Access the Dashboard peers tab
Navigate to the NetBird dashboard to begin the configuration process.
<p>
<img src="/docs-static/img/manage/network-routes/configuring-default-routes-for-internet-traffic/netbird-peers.png" alt="dashboard-peers-view"
className="imagewrapper-big"/>
</p>
### Select the designated routing peer
<p>
<img src="/docs-static/img/manage/network-routes/configuring-default-routes-for-internet-traffic/netbird-peers-routing-peer.png" alt="routing-peer-view"
className="imagewrapper-big"/>
</p>
### Make the peer an exit node routing peer
Hit the `Add Exit Node` button to configure the peer as an exit node routing peer.
In the opened window, specify which peers should use the default route by assigning one or more distribution groups.
These peers will automatically route their internet traffic through the routing peer upon its connection.
<p>
<img src="/docs-static/img/manage/network-routes/configuring-default-routes-for-internet-traffic/netbird-peers-add-exit-node.png" alt="add-exit-node-view"
className="imagewrapper-big"/>
</p>
If you want exit nodes to be available without being automatically enabled on clients, enable the **Auto Apply** option. When Auto Apply is on, clients will auto-apply the exit node, but users can manually disable it from the client.
<p>
<img src="/docs-static/img/manage/network-routes/configuring-default-routes-for-internet-traffic/exit-node-auto-apply.png" alt="exit-node-auto-apply" className="imagewrapper-big"/>
</p>
Then hit the `Add Exit Node` button to complete the configuration.
The routing peer is automatically set up to handle and route traffic it receives from connected peers. Masquerading
remains enabled by default to mask the original source IP addresses.
### Verify the configuration
Verify the configuration in the peer view. The routing peer should now be marked as an exit node.
<p>
<img src="/docs-static/img/manage/network-routes/configuring-default-routes-for-internet-traffic/netbird-peers-routing-peer-exit-node.png" alt="routing-peer-exit-node-view"
className="imagewrapper-big"/>
</p>
### DNS Configuration
Add a DNS server with the match domain set to `ALL`.
This is important, as locally configured DNS servers might not be accessible from the routing peer.
This also helps to avoid leaking the client's location.
See [Manage DNS in your network](/manage/dns).
## High Availability
Like for other network routes, high availability configurations are supported for default
routes. Refer to
the [Creating Highly Available Routes](/manage/network-routes/routing-traffic-to-private-networks#creating-highly-available-routes)
section for more information.
## Get started
<p float="center" >
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
</p>
- Make sure to [star us on GitHub](https://github.com/netbirdio/netbird)
- Follow us [on X](https://x.com/netbird)
- Join our [Slack Channel](/slack-url)
- NetBird [latest release](https://github.com/netbirdio/netbird/releases) on GitHub
src/pages/manage/network-routes/configuring-routes-with-access-control.mdx
+147
View File
@@ -0,0 +1,147 @@
# 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. This ensures 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 the routing
client to the routing peer. Consequently, the access control group only takes effect
when 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 `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
(see [Concepts](/manage/network-routes/routing-traffic-to-private-networks#concepts) to learn more about the fields):
- 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/manage/network-routes/configuring-routes-with-access-control/network-route-acl.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
Click on `Continue` to proceed.
<p>
<img src="/docs-static/img/manage/network-routes/configuring-routes-with-access-control/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/manage/network-routes/configuring-routes-with-access-control/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/manage/network-routes/configuring-routes-with-access-control/network-route-acl-prompt.png" alt="high-level-dia" className="imagewrapper"/>
</p>
Click on the `Create Policy` button to proceed.
## Creating an Access Control Policy
If you did not use the prompt, you can create a new policy by accessing the `Access Control` > `Policies` tab, then clicking 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 unidirectional 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/manage/network-routes/configuring-routes-with-access-control/network-acl-create-policy.png" alt="high-level-dia" className="imagewrapper"/>
</p>
If necessary, you can create new groups 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/manage/network-routes/configuring-routes-with-access-control/network-acl-new-policy.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
The route has been created successfully. 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:
### 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.
### 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/manage/network-routes/resolve-overlapping-routes.mdx
+93
View File
@@ -0,0 +1,93 @@
# Resolve overlapping routes with the route selection feature
NetBird [Network Routes](/manage/network-routes/routing-traffic-to-private-networks) feature enables peers to access external networks such as VPCs, LANs,
or office networks seamlessly.
In most scenarios, network administrators connect their NetBird peers to these external networks by defining a network route,
which includes specifying a network range, such as `172.17.0.0/16`, and assigning a routing peer.
However, challenges arise when multiple networks have overlapping network ranges. To solve this, NetBird introduces
a route selection feature. This feature allows users to explicitly choose which routes to apply on the client side, ensuring
that peers connect to the correct network without conflicts.
<Note>
The route selection feature is available in the NetBird client version `v0.27.4` and later.
</Note>
## How to use the route selection feature
There are two ways to use the route selection feature:
- Command line interface (CLI) via the `netbird routes` command.
- GUI via the NetBird system tray application.
### Select routes using the CLI
To list available routes using the CLI, you can use the `netbird routes list` command:
```bash
demo@netbird:~$ netbird routes list
Available Routes:
- ID: aws-vpc-ireland
Network: 172.17.0.0/16
Status: Selected
- ID: aws-vpc-ohio
Network: 172.17.0.0/16
Status: Selected
```
In the example above, we have two routes with overlapping network ranges. Both of them are selected, which means that they are active on the client side and conflicting.
To select a specific route, you can use the `netbird routes select` command. You can provide a list of routes
```bash
demo@netbird:~$ netbird routes select aws-vpc-ireland
Routes selected successfully.
```
<Note>
When running the `netbird routes select` command, the NetBird client will automatically deselect all other routes by default.
</Note>
Below are some examples of how to use the `netbird routes select` command:
```bash
# select all routes
netbird routes select all
# select multiple routes
netbird routes select route1 route2
# append a route to the selected routes without deselecting the others
netbird routes select -a route3
```
### Select routes using the GUI
To select routes using the GUI, you can open the NetBird system tray application and navigate to the `Network Routes` menu.
You can select or deselect routes by clicking on the checkbox next to the route name.
<p>
<img src="/docs-static/img/manage/network-routes/resolve-overlapping-routes/select-network-routes.png" alt="select-network-routes" className="imagewrapper-big"/>
</p>
### Enabling All Routes
When using the command `netbird routes select all` in the CLI or the button in the GUI,
all currently available routes are selected. This action includes any new routes that become available in the future.
This basically restores the default behavior of the NetBird client, where all routes are selected by default.
### Disabling All Routes
When using the command `netbird routes deselect all` in the CLI or the button GUI, all routes are deselected.
This applies not only to the currently available routes but also to any routes that might be added in the future.
## Get started
<p float="center" >
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
</p>
- Make sure to [star us on GitHub](https://github.com/netbirdio/netbird)
- Follow us [on X](https://x.com/netbird)
- Join our [Slack Channel](/slack-url)
- NetBird [latest release](https://github.com/netbirdio/netbird/releases) on GitHub
src/pages/manage/network-routes/routing-traffic-to-private-networks.mdx
+366
View File
@@ -0,0 +1,366 @@
# Routing Traffic to Private Networks
<div className="videowrapper">
<iframe src="https://www.youtube.com/embed/VQuPuBOAknQ" allow="fullscreen;"></iframe>
</div>
<br/><br/>
<Note>
**WARNING:** `Network Routes` will allow any traffic to pass through to the routed networks without regard for
the Access Control rules, unless you [configure those explicitly](/manage/network-routes/configuring-routes-with-access-control).
See [Network Routes caveats](#caveats) below for a more detailed explanation.
</Note>
NetBird provides fast and reliable end-to-end encryption between peers in your network. You can install the agent on every desktop, VM, container, or physical server to create a fast, secure peer-to-peer mesh network. This is the desired configuration, but some cases do not allow for agent installation or can slow down migration from legacy systems:
- Side-by-side migrations where part of your network is already using NetBird but needs to access services that are not.
- Systems that have limited operating system access, such as IoT devices, printers, and managed services.
- Legacy networks where an administrator is unable to install the agent on all nodes.
In these cases, you can configure network routes assigning routing peers to connect existing infrastructure. Routing peers will forward packets between your NetBird peers and your other networks; they can masquerade traffic going to your data centers or embedded devices, reducing the need for external route configuration and agent installation.
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
<Note>
If you want to see the Network Routes feature in action, try our managed version at https://app.netbird.io/routes. It's free and easy to use.
</Note>
## Concepts
### Network routes
A network route describes the network you want to connect with your NetBird peers. It has an identifier, a network range or list of domains, a routing peer, and some parameters available for managing priority and masquerading.
<Note>
Network routes are available in NetBird [v0.9.0](https://github.com/netbirdio/netbird/releases) or later.
</Note>
**Network identifiers and ranges** Network identifiers are names for each network you want to route traffic from your peers, and ranges are IP ranges declared in CIDR notation which refers to an external network. The combination of identifiers and these ranges makes a single network.
**Routing peer**: A routing peer is a peer that routes packets between your routed network and the other NetBird peers.
**Routing group**: A routing group is a set of routing peers. Each will route packets between your routed network and the other NetBird peers.
**High availability routes**: A highly available route is a combination of multiple routes with the same network identifier and ranges. They have different routing peers or routing peer groups offering highly available paths for communication between your peers and external networks.
Nodes connected to routing peers will choose one of them to route packets to external networks based on connection type and defined metrics.
**Masquerade**: Masquerade hides other NetBird network IPs behind the routing peer local address when accessing the target network range. This option allows access to your private networks without configuring routes on your local routers or other devices.
_If you do not enable this option, you must configure a route to your NetBird network in your external network infrastructure._
**DNS Routes**: An alternative to specifying a network range directly is to use DNS routes. Instead of adding the network directly, you can add multiple domains in a route that will be dynamically resolved on the client. The resolved IP addresses for these domains will be added as routes. For example, a network administrator can ensure that traffic to `website.com` or `api.website.com` is routed through a specific machine. So they configure DNS routes for these domains instead of specifying the IP ranges.
By default, DNS routes are resolved every 60 seconds. You can adjust this interval using the `--dns-router-interval` flag:
```bash
netbird up --dns-router-interval 30s
```
Additionally, the keep routes switch is enabled by default.
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-dns-routes.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
When the keep routes switch is on, and a domain no longer resolves to an IP address, the corresponding route will still be maintained (and any new resolved IP addresses will be added).
If the switch is off, the routes will be replaced with the newly resolved IP addresses.
The purpose of the keep routes functionality is to retain previously resolved routes after IP address updates, in order to maintain stable connections. For example, long-running connections to an IP address that are still valid even if the DNS now resolves to a different IP address (e.g., DNS-based load balancing).
<Note>
DNS Routes are available for NetBird [v0.28.0](https://github.com/netbirdio/netbird/releases) or later.
</Note>
<Note>
Currently, wildcard domains are not supported for DNS routes.
</Note>
<Note>
DNS Forwarder port change: starting with NetBird v0.59.0, the local DNS forwarder used for routed DNS routes switches from port <code>5353</code> to <code>22054</code> to avoid collisions on client devices. For backward compatibility, the Management Service applies the new port only when <strong>all peers in the account</strong> run v0.59.0 or newer. If any peer is below v0.59.0, port <code>5353</code> will be used for all peers in that account.
</Note>
### Metric and priority
Metric defines prioritization when choosing the main routing peer in a high availability network. Lower metrics have higher priority.
Outside of high availability routes, the metric has no effect.
### Distribution groups
Distribution groups specify which peers will receive the network route. Peers that belong to the groups specified in this field will automatically receive the network route configuration.
<Note>
This does not remove the need for the routing peer to be connected to these peers.
</Note>
### Access Control Groups
Access Control Groups provide granular control over internal services within your network. They are used as 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 inherit the access control policies where
the groups are defined as 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.
### Creating a Network Route
Access the `Network Routes` tab and click the `Add Route` button to create a new route.
This will open a route configuration screen where you can add the information about the network you want to route:
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-add-button.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
Now you can enter the details of your 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: `172.31.0.0/16`
- Routing peer: `ec2-demo-node`
- Distribution Groups: `All`
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-create.png" alt="high-level-dia" className="imagewrapper" width="70%"/>
</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/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-saved-new.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
The route has been created successfully. Now every peer connected to your routing peer will be able to send traffic to your external network.
### Creating a Network Route with Routing Group
You can use a peer group to automatically add any Linux peers from the groups as routing peers. To do so, follow the steps above but select the `Peer group` tab.
Ensure that the peer groups have Linux peers, as traffic routing is only supported on Linux machines.
Groups with multiple peers automatically provide [high availability routing](#high-availability-routes).
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-groups-create.png" alt="high-level-dia" className="imagewrapper" width="70%"/>
</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/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-groups-saved-new.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
The route has been created successfully. Now every peer connected to the peer members of the groups will be able to send traffic to your external network.
### Creating highly available routes
To avoid a single point of failure when managing your network, we recommend installing NetBird on every resource. However, when running NetBird on every machine is not feasible, you still want to ensure a reliable connection to your private network. The NetBird Network Routes feature has a High Availability (HA) mode, allowing one or more NetBird peers to serve as routing peers for the same private network.
There are two options to enable HA routes:
1. Use a peer group with more than one peer in it.
2. Add more individual peers to the route.
The first option is covered [above](#creating-a-network-route-with-routing-group).
To enable the high-availability mode by adding individual peers, click on `Add Peer` in the High Availability column in the Network Routes
table and select a peer in the `Routing Peer` field. Then select the `Distribution Groups` and click on `Add Route`. This
routing configuration will be distributed to machines in the selected groups `Distribution Groups`.
In the following example, we are adding the peer `aws-nb-europe-router-az-b` to the `aws-eu-central-1-vpc` route:
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-create-ha.png" alt="high-level-dia" className="imagewrapper" width="70%"/>
</p>
This way, peers connected to `aws-nb-europe-router-az-a` and `aws-nb-europe-router-az-b` will have highly available access to the `172.31.0.0/16` network.
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-saved-new-ha.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
<Note>
The number of routes that form a highly available route is unlimited.
Each connected peer will pick one routing peer to use as the router for a network.
NetBird agent bases this decision on metric prioritization (lower the metric, higher the priority) and connection attributes like direct or relayed connections.
</Note>
### Apply different routes to peers with group attribution
You can select as many distribution groups as you want for your network route.
Peers that belong to the specified group will use the route automatically to connect to the underlying network.
Remember to link groups to peers that need to access the route and, if required,
add access control rules ensuring connectivity between these peers and the routing peers.
In the following example (see column `Distribution Groups`), peers that belong to the group `berlin-office` will use
the `aws-nb-europe-router-az-a` routing peer to access the `aws-eu-central-1-vpc` network.
Peers that belong to the `london-office` group will use the `aws-nb-europe-router-az-b` routing peer.
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-groups-attribution.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
### Routes without masquerading
If you want more transparency and would like to manage your external network routers, you may choose to disable masquerade for your network routes.
In this case, the routing peer will not hide any NetBird peer IP and will forward the packets to the target network transparently.
This will require a routing configuration on your external network router pointing your NetBird network back to your routing peer.
This way, devices that do not have the agent installed can communicate with your NetBird peers.
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/netbird-network-routes-masquerading.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
## Network Routes caveats
Unless [configured explicitly](/manage/network-routes/configuring-routes-with-access-control), the **Network Routes** feature will not take into
consideration any of the Access Control rules. This might lead to surprising outcomes, which may initially appear to be security vulnerabilities.
**Important:** Understanding these caveats is essential for properly securing your network routes.
This has led us to create another, more intuitive design of **Networks** with their **Resources**, **Routers** and
mandatory **Groups** used for both access control and advertisement: your client will not "see" the resource
until it has access to its **Group**.
### Example: Network Route Configuration
Let's assume a **Network Route** is distributed through `Group R` (Routing Peer) to `Group A` (intended client):
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/route-ip-address.png" alt="route-ip-address" className="imagewrapper-big"/>
</p>
After creating an **Access Policy** granting `ICMP` access from `Group A` to `Group R`:
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/policy-icmp-group-r.png" alt="ICMP policy from group A to R" className="imagewrapper-big"/>
</p>
You will be able to access everything on the routed network without any restrictions.
This is because **Network Route** requires access to the **Routing Peer** to activate at all, which can be confusing.
```shell
root@brys-vm-nbt-ubuntu-01:~# netbird networks ls
Available Networks:
- ID: network-route-srvs-site
Network: 192.168.100.0/24
Status: Selected
root@brys-vm-nbt-ubuntu-01:~# ping -c1 192.168.100.10
PING 192.168.100.10 (192.168.100.10) 56(84) bytes of data.
64 bytes from 192.168.100.10: icmp_seq=1 ttl=63 time=0.521 ms
--- 192.168.100.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.521/0.521/0.521/0.000 ms
root@brys-vm-nbt-ubuntu-01:~# curl 192.168.100.10/health && echo
OK
```
### Setting up a Network Resource secured by HTTP policy
In the following example, we set up a **Network Resource** for a `*.nb.test` wildcard domain
using ACL group `manual:srvs`:
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/resource-domain.png" alt="*.nb.test domain Resource" className="imagewrapper-big"/>
</p>
Granting HTTP-only access to that resource from group `manual:client`:
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/policy-http.png" alt="a HTTP-only policy from manual:client group" className="imagewrapper-big"/>
</p>
Everything appears to be set up correctly. We have HTTP access and can confirm the domain was resolved:
```shell
root@brys-vm-nbt-ubuntu-02:~# netbird networks ls
Available Networks:
- ID: *.nb.test
Domains: *.nb.test
Status: Selected
Resolved IPs: -
root@brys-vm-nbt-ubuntu-02:~# curl srv.nb.test/health; echo
OK
root@brys-vm-nbt-ubuntu-02:~# netbird networks ls
Available Networks:
- ID: *.nb.test
Domains: *.nb.test
Status: Selected
Resolved IPs:
[srv.nb.test.]: 192.168.100.10
```
Before finishing, let's verify that only HTTP access is granted:
```shell
root@brys-vm-nbt-ubuntu-02:~# ping -c1 srv.nb.test
PING srv.nb.test (192.168.100.10) 56(84) bytes of data.
64 bytes from 192.168.100.10: icmp_seq=1 ttl=63 time=0.242 ms
--- srv.nb.test ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.242/0.242/0.242/0.000 ms
```
However, this reveals an unexpected behavior:
```shell
root@brys-vm-nbt-ubuntu-02:~# ssh srv.nb.test
root@srv.nb.test: Permission denied (publickey).
```
Did we inadvertently grant access to the **Network Route**?
```shell
root@brys-vm-nbt-ubuntu-02:~# netbird networks ls
Available Networks:
- ID: *.nb.test
Domains: *.nb.test
Status: Selected
Resolved IPs:
[srv.nb.test.]: 192.168.100.10
```
This does not appear to be the case.
### Why did we get ping and SSH access for the domain?
Unrestricted access to the `srv.nb.test` domain was granted, because we have used the same **Routing Peer**
for both **Network Route** and the newly created **Network**:
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/network-routers.png" alt="Network's `manual:router:srvs` router" className="imagewrapper-big"/>
</p>
Here are this specific **Routing Peer**'s details:
<p>
<img src="/docs-static/img/manage/network-routes/routing-traffic-to-private-networks/routing-peer-groups.png" alt="Routing Peer's detail page with Network Route handling" className="imagewrapper-big"/>
</p>
It is a member of both routing groups:
1. `m:group-r` to advertise the **Network Route**,
2. `manual:router:srvs` to advertise the **Network** and its domain **Resource**,
<Note>
You can address the "overflowing permissions" issue by setting up a dedicated set of **Routing Peers**
to handle the **Network Routes** and never using those for anything else (especially **Networks**).
While this is achievable, it is extremely easy to miss during configuration.
</Note>
## Get started
<p float="center" >
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
</p>
- Make sure to [star us on GitHub](https://github.com/netbirdio/netbird)
- Follow us [on X](https://x.com/netbird)
- Join our [Slack Channel](/slack-url)
- NetBird [latest release](https://github.com/netbirdio/netbird/releases) on GitHub