mirror of
https://github.com/netbirdio/docs.git
synced 2026-10-19 20:19:06 +02:00
Restructuring Phase 3 (#492)
This commit is contained in:
Brandon Hopkins
@@ -0,0 +1,230 @@
|
||||
# Accessing entire domains within networks
|
||||
|
||||
Companies often operate internal environments using assigned domains that remain inaccessible to the public for security and compliance reasons. Creating routing resources for these environments can quickly become a problem for DevOps and Platform teams, especially as different stakeholders frequently request new resources. Moreover, when these resources span across different networks, managing them becomes even more challenging.
|
||||
|
||||
NetBird's [Networks](https://docs.netbird.io/manage/networks) streamlines this process, allowing organizations to configure secure access to internal resources efficiently using [Wildcard domain resources](https://docs.netbird.io/manage/networks#resources). This reduces the administrative burden on IT teams and enhances overall productivity.
|
||||
|
||||
## Example Use Case Scenario
|
||||
|
||||
In this scenario, an AI software company needs secure access to its internal domains, encompassing both development and AI model training environments. This integration is vital for maintaining robust internal network security while ensuring seamless domain access across the entire network infrastructure.
|
||||
|
||||
### Configuration Overview
|
||||
|
||||
1. **Development Environment**:
|
||||
- Wildcard Domain: `*.dev.example.com`
|
||||
- Purpose: Provides developers with access to a shared workspace for code development, testing, and collaboration.
|
||||
|
||||
2. **AI Model Training Environment**:
|
||||
- Wildcard Domain: `*.ai.example.com`
|
||||
- Purpose: Houses sensitive AI models and datasets, requiring restricted access to ensure security and integrity.
|
||||
|
||||
### Implementation Steps
|
||||
|
||||
- **Network Setup**: Using NetBird's Networks you can configure a secure network that connects local and remote users to these internal environments through routing peers. This involves configuring wildcard domains for both environments to enable seamless access while accommodating future growth.
|
||||
- **Access Control**: NetBird's [Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access) allow you to implement stringent policies that enforce zero trust principles, assigning different access permissions to developers and data scientists. For instance, you can grant developers access to `*.dev.example.com`, while data scientists gain access to `*.ai.example.com`. This clear separation ensures that team members only access the resources essential to their roles, maintaining a robust security posture.
|
||||
- **Operational Benefits**: This configuration supports uninterrupted workflows, allowing developers and data scientists to work efficiently without connectivity issues. Furthermore, NetBird's centralized management of routing peers simplifies handling resources distributed across different networks, ensuring seamless connectivity and reducing complexity. Additionally, the process of creating new resources is streamlined, reducing administrative overhead and accelerating responses to frequent resource requests.
|
||||
|
||||
## Pre-requisites
|
||||
|
||||
To effectively access entire domains within your internal networks using NetBird, ensure the following pre-requisites are met:
|
||||
|
||||
- **NetBird Clients**: Install [NetBird clients](https://docs.netbird.io/get-started) on all devices used by developers and data scientists. This is essential to establish secure connectivity to your internal resources.
|
||||
- **Routing Peers**: Configure [NetBird routing peers](https://docs.netbird.io/manage/networks#routing-peers) within your network infrastructure using [setup keys](https://docs.netbird.io/manage/peers/access-infrastructure/setup-keys-add-servers-to-network). Routing peers facilitate traffic routing across different network segments, ensuring seamless access to both internal domains.
|
||||
- **Nameserver Configuration**: Ensure that your Nameservers are properly configured within your NetBird account to resolve all domain queries. This step is critical for enabling seamless domain name resolution across your network, facilitating efficient connectivity to both your development and AI model training environments. For detailed instructions, refer to the [Manage DNS in Your Network](https://docs.netbird.io/manage/dns).
|
||||
|
||||
## Enabling DNS Wildcard Routing
|
||||
|
||||
Enabling DNS wildcard routing is crucial for handling sub-domain requests across your development and AI model training environments, ensuring seamless access for developers and data scientists to all necessary subdomains without requiring additional configuration.
|
||||
|
||||
Note that enabling DNS wildcard routing shifts the DNS resolution responsibility from the local client system to the routing peer. Compared to the previous behavior of DNS routes via network routes, this transition facilitates enhanced access control rules available in newer NetBird client versions and optimizes traffic management by directing queries to the nearest routing peer service. This setup simplifies the DNS management process and bolsters security and network efficiency.
|
||||
|
||||
<Note>
|
||||
(1) Support for more restricted rules will be available in future releases.
|
||||
</Note>
|
||||
|
||||
To enable DNS wildcard routing in your NetBird account, follow these steps:
|
||||
|
||||
* Navigate to `Settings` > `Networks` within your NetBird account.
|
||||
* `Enable DNS wildcard routing` by toggling the appropriate setting. This will allow your network to resolve all subdomains under a specified domain.
|
||||
|
||||
|
||||
|
||||
<Note>
|
||||
The `Enable DNS wildcard routing` is supported by routing peers and routing clients running version `0.35.0` or later.
|
||||
Once the feature is enabled, you may need to restart your routing peers and clients to apply the changes.
|
||||
</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>
|
||||
|
||||
## Setting Up Developers' Network Environment
|
||||
|
||||
To create a network for the developer environment:
|
||||
|
||||
* Navigate to `Networks` > `Networks` in NetBird's dashboard.
|
||||
* Click the `Add Network` button.
|
||||
* Give a descriptive name to the network, e.g., `Development Network`. Optionally, add a description.
|
||||
* Click `Add Network` to continue.
|
||||
|
||||
|
||||
|
||||
### Adding Routing Peers
|
||||
|
||||
Click `Add Routing Peer` to make accessible the resources within this network to the developers.
|
||||
|
||||
|
||||
|
||||
You will see two tabs: `Routing Peers` and `Peer Group`.
|
||||
|
||||
* Select `Routing Peers` to add one peer at a time to the network.
|
||||
* Select `Peer Group` to enable high availability by adding multiple peers to the network.
|
||||
* Click `Continue` once ready.
|
||||
|
||||
|
||||
|
||||
In the `Advanced Settings` tab:
|
||||
|
||||
* Set `Masquerade` if you want to access private networks without configuring local routers or other devices.
|
||||
* Set the `Metric` to prioritize routers, using lower values for higher priority peers.
|
||||
* When ready, click `Add Routing Peer`.
|
||||
|
||||
|
||||
|
||||
### Adding a Wildcard Domain Resource
|
||||
|
||||
Click `Add Resource` to create the wildcard domain resource.
|
||||
|
||||
|
||||
|
||||
* Give the resource a descriptive name, e.g., `Development Wildcard Domain`
|
||||
* Enter the wildcard domain for this environment, e.g., `*.dev.example.com`.
|
||||
* Under `Assigned Groups`, select or create a group, e.g., `Development Domain`. This group will be used to create an access policy to allow developers access to all subdomains ending with `.dev.example.com`.
|
||||
* Click `Add Resource` when ready.
|
||||
|
||||
|
||||
|
||||
### Creating an Access Policy
|
||||
|
||||
Click `Create Policy` to grant developers access to `*.dev.example.com`.
|
||||
|
||||
|
||||
|
||||
* Under `Protocol`, leave `ALL`.
|
||||
* Under `Source` choose the group corresponding to developers, e.g., `Developers`.
|
||||
* The `Destination` is automatically set to the group you used when creating the resource, e.g., `Development Domain`.
|
||||
|
||||
|
||||
|
||||
* Click `Continue` to set `Posture Checks`. This step is optional, meaning you can click `Continue` for this example.
|
||||
* Provide a descriptive name for the policy, e.g., `Development Wildcard Domain Policy`.
|
||||
* Click `Add Policy` to finish.
|
||||
|
||||
|
||||
|
||||
Now that the development environment is set up, you can streamline the process of creating new resources using NetBird.
|
||||
|
||||
### Adding a Regular Domain Resource
|
||||
|
||||
The wildcard domain you configured, `*.dev.example.com`, only covers subdomains following the `.` (dot). Therefore, you need to configure a primary domain alongside your wildcard domain within your network settings. This dual approach guarantees that all levels of your domain hierarchy are adequately resolved and accessible.
|
||||
|
||||
Suppose you want to create the regular domain `dev.example.com`.
|
||||
|
||||
* Navigate to `Networks` > `Development Network` and click `Add Resource`.
|
||||
|
||||
|
||||
|
||||
* Provide an appropriate name for the resource, such as `Development Regular Domain`.
|
||||
* In the `Address` field, enter the regular domain `dev.example.com`.
|
||||
* Under `Assigned Groups` select the same group used for the wildcard domain, e.g., `Development Domain`.
|
||||
* Click `Add Resource` to continue.
|
||||
|
||||
|
||||
|
||||
That's it! Since you used the group `Development Domain`, NetBird will automatically configure for you routing peers and access policies, granting your developers the necessary access permissions.
|
||||
|
||||
|
||||
|
||||
You can confirm the configuration by listing the available networks using the command `netbird networks ls` from any developer workstation. The output should resemble the following:
|
||||
|
||||
```bash
|
||||
$ netbird networks ls
|
||||
Available Networks:
|
||||
|
||||
- ID: Development Regular Domain
|
||||
Domains: dev.example.com
|
||||
Status: Selected
|
||||
Resolved IPs:
|
||||
[example.com]: 93.184.215.14, 2606:2800:21f:cb07:6820:80da:af6b:8b2c
|
||||
|
||||
- ID: Development Wildcard Domain
|
||||
Domains: *.dev.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
```
|
||||
|
||||
## Creating AI Model Training Network
|
||||
|
||||
For our use case, data scientists operate from different network segments or diverse geographical locations. Using the same steps previously outlined, you can overcome the challenges associated with this scenario by creating a new network with its corresponding routing peers, resources, and access policies.
|
||||
|
||||
From the `Networks` screen, click `Add Network` to set up an appropriate network for your data scientists:
|
||||
|
||||
|
||||
|
||||
As with developers, you can configure a single routing peer or a group of routing peers for high availability:
|
||||
|
||||
|
||||
|
||||
You can also set up a wildcard domain resource for this environment:
|
||||
|
||||
|
||||
|
||||
And establish an access policy tailored to your data scientists:
|
||||
|
||||
|
||||
|
||||
You will need a regular domain, too; simply create the corresponding resource. The overview of your new network might resemble the following:
|
||||
|
||||
|
||||
|
||||
Need a new subdomain for testing the latest model? From NetBird's Networks screen, just click `Add Resource`, name it, enter the desired subdomain, and assign it to the appropriate group for this environment:
|
||||
|
||||
|
||||
|
||||
In summary, you can easily add, remove, and edit network resources from the Networks dashboard.
|
||||
|
||||
|
||||
|
||||
With this setup, all members of the `Data Scientists` group have access to `ai.example.com` and its subdomains:
|
||||
|
||||
```bash
|
||||
$ netbird networks ls
|
||||
Available Networks:
|
||||
|
||||
- ID: AI Model Training Wildcard Domain
|
||||
Domains: *.ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: AI Regular Domain
|
||||
Domains: ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: DataSage Model
|
||||
Domains: datasage.ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: NeuroPulse Model
|
||||
Domains: neuropulse.ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: QuantumNet Model
|
||||
Domains: quantumnet.ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
```
|
||||
|
||||
However, using your newly acquired knowledge, you can create access policies for each subdomain or organize data scientists into teams with varied permissions. With NetBird, the possibilities are endless.
|
||||
@@ -0,0 +1,158 @@
|
||||
# Accessing restricted website domain resources
|
||||
|
||||
It is very common to find scenarios where you need to access restricted websites or services. This can be due to company policies, geographical restrictions, or even to avoid tracking. These resources are often located behind a cloud load balancer, which changes IP addresses frequently, making it hard to whitelist them. NetBird can help you access these resources by routing your traffic through a [routing peer](https://docs.netbird.io/manage/network-routes/routing-traffic-to-private-networks#routing-peer) configured with [Networks](https://docs.netbird.io/manage/networks) using [Domain resources](https://docs.netbird.io/manage/networks#resources).
|
||||
|
||||
## Example Use Case Scenario
|
||||
|
||||
Imagine a company that runs its accounting application at the subdomain `accounting.example.com`. The website is behind a load balancer and hosted on an EC2 instance within the company's AWS infrastructure in the EU Central region. To enhance security, the company decided to follow zero-trust principles by giving differentiated access to the finance and support teams tailored to their specific responsibilities and operational needs.
|
||||
|
||||
To this end, the company deployed [NetBird clients](https://docs.netbird.io/get-started) on the devices used by both the finance and support teams. Complementing this, [NetBird routing peers](https://docs.netbird.io/manage/networks#routing-peers) were configured within the AWS VPC using [setup keys](https://docs.netbird.io/manage/peers/access-infrastructure/setup-keys-add-servers-to-network). This configuration guarantees a solid foundation for streamlined and secure connectivity.
|
||||
|
||||
More importantly, this setup allows the company to use NetBird's Networks and [Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access), to ensure that only authorized finance and support team members access the restricted website domain as follows:
|
||||
|
||||
- **Finance Team**: HTTP and HTTPS access to the website frontend at `accounting.example.com` over ports `80` and `443`, respectively.
|
||||
- **Support Team**: SSH access to backend resources at `example.com` over port `22`, enabling server management, troubleshooting, and support tasks.
|
||||
|
||||
This configuration adds another layer of security within the AWS environment, thus reinforcing the company network security framework and enhancing operational efficiency.
|
||||
|
||||
## Creating a Network for the Restricted Website Domain
|
||||
|
||||
To create a new network for the accounting website subdomain:
|
||||
|
||||
* Go to `Networks` > `Networks` in NetBird's dashboard.
|
||||
* Click the `Add Network` button.
|
||||
* Give a memorable name to the network, such as `AWS EU Network`. Optionally, add a description.
|
||||
* Click `Add Network` to proceed.
|
||||
|
||||
|
||||
|
||||
### Adding Routing Peers
|
||||
|
||||
Continue the process by clicking `Add Routing Peer`. This step is necessary to enable the network's resources to be accessible to other peers.
|
||||
|
||||
|
||||
|
||||
In the next window, you will see two tabs: `Routing Peers` and `Peer Group`.
|
||||
|
||||
* Choose `Routing Peers` to add a single peer to the network, e.g., `aws-router`.
|
||||
* Alternatively, you can select `Peer Group` to add multiple peers simultaneously for high availability.
|
||||
* Click `Continue` once ready.
|
||||
|
||||
|
||||
|
||||
In the `Advanced Settings` tab:
|
||||
|
||||
* Set `Masquerade` if you want to access private networks without configuring local routers or other devices.
|
||||
* Set the `Metric` to prioritize routers. Lower values indicate higher priority.
|
||||
* Click `Add Routing Peer`.
|
||||
|
||||
|
||||
|
||||
### Adding Network Resources
|
||||
|
||||
Next, click `Add Resource` to add the accounting website resource.
|
||||
|
||||
|
||||
|
||||
* Give the network resource an appropriate name, e.g., `Accounting restricted subdomain`
|
||||
* Enter the restricted website domain for the accounting website, in this example, `accounting.example.com`.
|
||||
* Under `Assigned Groups`, select or create a group, like `Accounting Subdomain`. This group will be used to create an access policy to allow the finance team access to the restricted subdomain.
|
||||
* Click `Add Resource` when done.
|
||||
|
||||
|
||||
|
||||
### Creating Access Policies
|
||||
|
||||
The last step consists of creating an access control policy. Click `Create Policy` to create a new policy for the finance team.
|
||||
|
||||
|
||||
|
||||
Since the finance team only needs access to the web-based app at `accounting.example.com`, this policy will restrict access to ports: `TCP/80` for `HTTP` traffic and `TCP/443` for encrypted `HTTPS` traffic.
|
||||
|
||||
* Under `Protocol`, select `TCP`.
|
||||
* Under `Source` choose the group corresponding to the finance team, e.g., `Finance`.
|
||||
* The `Destination` is automatically set to the group of the newly created resource, e.g., `Accounting Subdomain`.
|
||||
* Under `Ports`, enter `80` and `443`, the default ports for `HTTP` and `HTTPS` traffic.
|
||||
|
||||
|
||||
|
||||
* Click `Continue` to move to the `Posture Checks` tab, where you can optionally create or select posture checks for this policy.
|
||||
* Click `Continue` again, and provide a descriptive name for the policy, e.g., `Accounting subdomain Policy`.
|
||||
* Click `Add Policy` to finish.
|
||||
|
||||
|
||||
|
||||
### Setting Up Additional Resources and Access Policies
|
||||
|
||||
Contrary to the finance team, the support team does not need access to the front end of the restricted accounting app but to the back end of the top-level domain: `example.com`, meaning you must add a new network resource and access policy for this team.
|
||||
|
||||
To set up a new network resource:
|
||||
|
||||
* In the `AWS EU Network` screen, click `Add Resource`.
|
||||
* Give the resource a descriptive name, for example, `Restricted Website TLD`.
|
||||
* Enter the domain, in our case, `example.com`.
|
||||
* Under `Assigned Groups`, select or create the appropriate group such as `Webserver`. This group will be used to create a policy allowing the support team to access the TLD `example.com`.
|
||||
|
||||
|
||||
|
||||
Next, create an access policy for the support team. Usually, support teams only need SSH access to the website backend, meaning that they only need access to the `TCP/22` port:
|
||||
|
||||
* Click `Add Policy` next to the `Restricted Website TLD` resource.
|
||||
* Under `Protocol`, select `TCP`.
|
||||
* Set `Source` to `Support` and `Destination` to `Webserver`. This allows the support team to access the restricted website backend over SSH.
|
||||
* Under `Ports`, enter `22`, the default port for SSH.
|
||||
* Click `Continue`.
|
||||
|
||||
|
||||
|
||||
* Optionally, select or create posture checks for this policy. Click `Continue`.
|
||||
* Give a name to the policy on the final tab, such as `Restricted Website TLD Policy`.
|
||||
|
||||
|
||||
|
||||
This completes the network setup. You have configured two network resources, their respective access policies, and routing peers.
|
||||
|
||||
|
||||
|
||||
Now, you can review, select, or deselect available networks using NetBird's CLI.
|
||||
|
||||
Here's the output of the `netbird networks list` command from a Finance team client:
|
||||
|
||||
```bash
|
||||
$ netbird networks list
|
||||
Available Networks:
|
||||
|
||||
- ID: Accounting restricted subdomain
|
||||
Domains: accounting.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: Internal Web Services
|
||||
Domains: *.company.internal
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
```
|
||||
|
||||
As expected, finance members only have access to `accounting.example.com`.
|
||||
|
||||
Here's the output from a support team workstation:
|
||||
|
||||
```bash
|
||||
$ netbird networks list
|
||||
Available Networks:
|
||||
|
||||
- ID: Internal Web Services
|
||||
Domains: *.company.internal
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: Restricted Website TLD
|
||||
Domains: example.com
|
||||
Status: Selected
|
||||
Resolved IPs:
|
||||
[example.com]: 93.184.215.14, 2606:2800:21f:cb07:6820:80da:af6b:8b2c
|
||||
```
|
||||
|
||||
As you can see, the support team only has access to the TLD `example.com`
|
||||
|
||||
That's it! Using NetBird's Networks feature, you can efficiently create and manage custom network traffic routes and access policies for restricted website domain resources.
|
||||
@@ -0,0 +1,166 @@
|
||||
import {Note} from "@/components/mdx";
|
||||
|
||||
# How to Set up NetBird to Access Your Home Network
|
||||
|
||||
This step-by-step guide describes how to quickly get started with NetBird and access your home network remotely.
|
||||
You will achieve a secure connection between your entire home network and NetBird, enabling remote devices to access
|
||||
local network resources through a routing peer using the [NetBird Networks feature](/manage/networks/homelab/access-home-network).
|
||||
|
||||
## Download and Install NetBird
|
||||
<br/>
|
||||
|
||||
<Button href="https://app.netbird.io/install" arrow="right" children="Download NetBird" />
|
||||
|
||||
## Connect Your Laptop
|
||||
|
||||
NetBird comes with a Desktop UI application that can be found in the systray. If it hasn't automatically started, look for `NetBird` in the application list, run it, and click `Connect`:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/get-started/systray.png" alt="login-to-netbird" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
Alternatively, you can run the `netbird up` command in the terminal.
|
||||
</Note>
|
||||
|
||||
At this point a browser window pops up starting an interactive SSO login session that will register your laptop. You will be prompt to sign up and confirm your device registration:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/homelab/access-home-network/login-screen-dark.png" alt="login-to-netbird" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
After the registration is complete, proceed to the [**NetBird dashboard**](https://app.netbird.io/) to confirm that your laptop is in the network. You will see it in the `Peers` view.
|
||||
|
||||
## Create a New NetBird Network
|
||||
1. Go to the **Networks** tab in the side bar
|
||||
2. Click **Add Network** and give it a name such as “Home LAN", and optionally add a description.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/homelab/access-home-network/add-network-home-lan.png" alt="add-network-home-lan" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
## Identify Your Local Subnet
|
||||
Use the steps below to quickly identify your local subnet for use as a Network Resource.
|
||||
### Windows
|
||||
1. Open **Command Prompt**.
|
||||
2. Run:
|
||||
```bash
|
||||
ipconfig
|
||||
```
|
||||
3. Look for your active network adapter.
|
||||
4. Note the values for:
|
||||
- `IPv4 Address`
|
||||
- `Subnet Mask`
|
||||
Example:
|
||||
```
|
||||
IPv4 Address. . . . . . . . . . . : 192.168.1.10
|
||||
Subnet Mask . . . . . . . . . . : 255.255.255.0
|
||||
```
|
||||
The subnet is `192.168.1.0/24`.
|
||||
### Linux
|
||||
1. Open **Terminal**.
|
||||
2. Run:
|
||||
```bash
|
||||
ip -c a
|
||||
```
|
||||
or
|
||||
```bash
|
||||
ip route
|
||||
```
|
||||
3. Identify the active interface (e.g., `eth0`, `wlan0`) and note the IP with CIDR suffix:
|
||||
Example:
|
||||
```
|
||||
inet 192.168.1.10/24
|
||||
```
|
||||
The subnet is `192.168.1.0/24`.
|
||||
### macOS
|
||||
1. Open **Terminal**.
|
||||
2. Run:
|
||||
```bash
|
||||
ifconfig
|
||||
```
|
||||
3. Locate the active interface (`en0`, `en1`, etc.).
|
||||
4. Look for:
|
||||
- `inet` (IP address)
|
||||
- `netmask` (in hex)
|
||||
Example:
|
||||
```
|
||||
inet 192.168.1.10 netmask 0xffffff00
|
||||
```
|
||||
Hex `0xffffff00` = `255.255.255.0`, which is `/24`.
|
||||
The subnet is `192.168.1.0/24`.
|
||||
|
||||
## Define Your LAN as a Network Resource
|
||||
1. Click **Add Resource**.
|
||||
2. Enter a name like "Home Subnet" and the CIDR of your home network into the Address field (e.g., 192.168.1.0/24).
|
||||
3. Assign it to a Destination Group, create one called "home-lan" so you can write access policies using this group.
|
||||
4. Click **Add Resource**.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/homelab/access-home-network/add-resource-home-network.png" alt="add-resource-home-network" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
Alternatively, if you do not want to allow access your entire home subnet, you can get more granular by only
|
||||
allowing
|
||||
access to a single static IP address for your added resource (e.g., 192.168.1.50/32).
|
||||
</Note>
|
||||
|
||||
## Create an Access Control Policy
|
||||
|
||||
To allow access to resources in your home network, you need to create an access control policy that defines which
|
||||
peers can access the network.
|
||||
|
||||
1. After adding your resource, click **Create Policy**.
|
||||
2. Set Source to the group of NetBird peers you want to allow access (e.g., "All Users" or a specific group like "Home Users").
|
||||
3. Set **Destination** to the "home-lan" group you made.
|
||||
4. For **Protocol**, choose All.
|
||||
5. Name it "Home LAN Access" and click **Add Policy**.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/homelab/access-home-network/add-policy-home-lan.png" alt="add-policy-home-lan" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
## Add Your User to the Home User Group
|
||||
|
||||
In order to access your home network, you need to add your users to a group that is used in the access control policy,
|
||||
you've previously created.
|
||||
|
||||
1. Go to the **Team** tab in the side bar.
|
||||
2. Find your user row and click on the **GROUPS** column in the table.
|
||||
3. Add "Home Users" by typing it in the input box and pressing Enter.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/homelab/access-home-network/add-user-group.png" alt="add-network-home-lan" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
## Choose or Add a Routing Peer in Your LAN
|
||||
|
||||
1. Click **Add Routing Peer**.
|
||||
2. Pick any always-on machine on your home network (Windows, Linux, Mac, Docker, Raspberry Pi).
|
||||
3. Install the NetBird agent on it using a [one-off setup key](/manage/peers/register-machines-using-setup-keys#types-of-setup-keys) using the CLI installer.
|
||||
4. Ensure this machine has access to both the internet and your LAN subnet.
|
||||
5. Choose this machine as your routing peer and click **Continue** and **Add Routing Peer**.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/homelab/access-home-network/add-routing-peer-home-network.png" alt="add-routing-peer-home-network"
|
||||
className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/homelab/access-home-network/add-routing-peer.png" alt="add-routing-peer-home-network"
|
||||
className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
## Test the Connection
|
||||
|
||||
1. Pick any IP within your Home LAN, such as the IP of your NAS, printer, or another service and run:
|
||||
|
||||
```bash
|
||||
ping 192.168.x.x
|
||||
```
|
||||
|
||||
2. A successful ping response confirms that your routing peer is correctly routing traffic to resources in your home network.
|
||||
|
||||
That’s it! You’ve successfully mapped your entire home LAN into a NetBird Network. Any peer included in your access policy
|
||||
can now securely access resources in your home subnet via your designated routing peer, without the need to open router ports or install software on every device.
|
||||
@@ -0,0 +1,173 @@
|
||||
# Networks
|
||||
|
||||
NetBird provides a fast and secure peer-to-peer mesh network with end-to-end encryption, enabling devices and machines
|
||||
running the NetBird agent to connect directly. This setup allows for precise network segmentation,
|
||||
isolation of individual machines, and secure remote access without the need to open ports or expose resources to the
|
||||
internet. However, there are situations where installing the agent on every machine is not feasible or hasn't been
|
||||
completed, requiring access to entire LANs, office networks, or cloud VPCs instead.
|
||||
|
||||
Starting from version `0.35.0`, NetBird introduces Networks, a new concept that allows you to map your internal networks
|
||||
such as LANs, VPCs, or office networks, and manage access to internal resources without installing NetBird agent.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="high-level-dia" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
Networks replace the old [Network Routes](/manage/network-routes/routing-traffic-to-private-networks) concept, which is now deprecated.
|
||||
Existing Network routes will continue to work as before, but we recommend migrating to Networks for better access
|
||||
management to your resources.
|
||||
</Note>
|
||||
|
||||
## Concepts
|
||||
### Networks
|
||||
Networks are configuration containers that map your on-premise or cloud networks in a logical set of configurations,
|
||||
making it easier to visualise and manage access to your internal resources. You can create multiple networks to represent your
|
||||
different environments, such as office networks, cloud VPCs, or on-premise LANs.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/index/new-network-2.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
### Routing peers
|
||||
To access your internal resources, you need to route traffic from your NetBird peers to your internal networks.
|
||||
Routing peers are machines that connect your NetBird peers and your internal networks.
|
||||
You can add as many routing peers as you need using single peers or groups to ensure high availability and load balancing.
|
||||
You can define masquerading and priority for each routing peer.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/index/add-routing-peer-1.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
|
||||
### Resources
|
||||
Resources are individual machines, services, or subnets within your internal network. You can define resources as single
|
||||
IP addresses, IP ranges, domain names, or wildcard domains (e.g., *.company.internal) when enabling [DNS wildcard routing](#enable-dns-wildcard-routing).
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/index/resources-1.png" alt="resources" className="imagewrapper-big"/>
|
||||
</p>
|
||||
<Note>
|
||||
Support to exit nodes and site-2-site VPNs may become available in future releases. In the meantime you can use [Network routes](/manage/network-routes/routing-traffic-to-private-networks) add your exit-node routes and site-2-site routes.
|
||||
</Note>
|
||||
|
||||
### Domain Resources
|
||||
|
||||
In addition to routing IP addresses, NetBird also supports routing domain names. In the Dashboard you can just pass
|
||||
a domain name (eg: `example.com`) or a wildcard domain (eg: `*.example.com`) in place where you would normally
|
||||
put an IP address range. Then NetBird clients will start responding to and routing the given domain.
|
||||
|
||||
Please consult the
|
||||
[Debugging access to Domain Resources](/how-to/troubleshooting-client#debugging-access-to-domain-resources)
|
||||
documentation to troubleshoot common issues with this type of resources yourself.
|
||||
|
||||
<Note>
|
||||
Due to a mix of a bug and initial design choice clients running `0.59.0` & `0.59.1` might not be able to resolve
|
||||
domain Resources served by Routing Peers running versions `0.59.0` to `0.59.9` in case when all the Peers in the
|
||||
NetBird organization are running versions `0.59.0` or newer.
|
||||
|
||||
Installing client in versions `<= 0.58.2` or `>= 0.59.2` or upgrading a Routing Peer to version `0.59.10+` will
|
||||
resolve this issue.
|
||||
</Note>
|
||||
|
||||
On a technical level the feature works as follows:
|
||||
|
||||
1. Initially (when NetBird connects) the operating system is instructed to use NetBird to resolve the requested
|
||||
domain(s). No routing rules are configured yet.
|
||||
2. An Application (could be a web browser) requests a domain `example.com` from the Operating System
|
||||
1. the Operating System requests a name from NetBird's Local DNS Forwarder, by default running on port `53` of:
|
||||
- for MacOS & Windows: the highest available IP address in your NetBird range, usually `100.xxx.255.254:53`
|
||||
- for other systems: local NetBird client's IP address, eg: `100.xxx.123.45`
|
||||
2. the Local DNS Forwarder forwards the query to Remote DNS Resolver running on Routing Peer's address
|
||||
and the following port:
|
||||
- `22054` for version `0.59.0` and newer
|
||||
- `5353` for versions below `0.58.x` and older
|
||||
3. the Routing Peer resolves the domain name using its local configuration (often independent of NetBird) and returns
|
||||
the result.
|
||||
4. the Local DNS Forwarder sets up routing rules for IP addresses returned from the query,
|
||||
before returning them to the Application
|
||||
- see [Trigger the Domain Resource](/how-to/troubleshooting-client#trigger-the-domain-resource)
|
||||
to observe this behaviour "in action".
|
||||
3. the Application receives the result "as usual", except for a slight delay before all of the above takes place the
|
||||
first time a domain name is requested,
|
||||
4. all subsequent requests to `example.com` will be served instantly from the Local DNS Forwarder's cache
|
||||
|
||||
<Note>
|
||||
NetBird tries its best to automatically open up DNS forwarder ports on Routing Peer's firewalls, but might fail on
|
||||
some system configurations and you might need to open up above 2 ports manually.
|
||||
|
||||
You can verify that firewall allows the DNS request in using following command issued from the clients device
|
||||
`nslookup -port=22054 <routed-domain> <routing-peer-ip>`, eg: `nslookup -port=22054 example.com 100.123.45.67`.
|
||||
|
||||
This is by far the most common cause of issues with domain Resources.
|
||||
</Note>
|
||||
|
||||
## Manage access to resources
|
||||
|
||||
To manage access to resources, you can assign them to groups and create [access control policies](/manage/access-control/manage-network-access#creating-policies) to define which peers can access them.
|
||||
See the image below with an example resource `CRM`:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/index/resources-2.png" alt="resource-group" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
Access control policies are rules that define which peers can access the resources in your network. You can create policies based on the source and destination groups, and the type of traffic allowed (e.g., TCP, UDP, ICMP).
|
||||
The groups assigned to resources should always be placed in the destination input field of the policy.
|
||||
The peers belonging to the source groups will receive the resources linked to the policy and the firewall rules will be applied according to what is defined.
|
||||
See the example below with a policy that allows the group `Berlin Office` to access the internal CRM system:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/index/resource-acl-1.png" alt="resource-acl" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior.
|
||||
</Note>
|
||||
|
||||
## Enable DNS wildcard routing
|
||||
When you configure wildcard domains as resources, you need to enable DNS wildcard routing. Which has an additional effect in comparison to the previous DNS routes behavior from Network routes; it switches the DNS resolution to the routing peer instead of the local client system.
|
||||
This is also useful for regular DNS routes when you want to resolve the domain names using the routing peer's IP infrastructure, which will allow for more restricted access control rules in newer versions of the clients (**1**) and for the traffic to go to a near routing peer service.
|
||||
<Note>
|
||||
(1) Support for more restricted rules will be available in future releases.
|
||||
</Note>
|
||||
You can enable DNS resolution on the routing peer by accessing your account `Settings` > `Networks` > Enable DNS wildcard routing. See example below:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/index/settings-1.png" alt="settings-acl" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
The `Enable DNS wildcard routing` is supported by routing peers and routing clients running version 0.35.0 or later.
|
||||
Once the feature is enabled, you may need to restart your routing peers and clients to apply the changes.
|
||||
</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>
|
||||
|
||||
## Differences between Networks and Network Routes
|
||||
|
||||
| | Networks | Network routes |
|
||||
|---------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Requires extra policy connecting routing peers to distribution peers?** | No, the connection is implied when a policy is added to control access to resources | Yes, the routing peers need to have a policy that connects them to peers in the distribution groups |
|
||||
| **Needs distribution groups?** | No, the source groups in the policies define the distribution groups | Yes, they need to be explicitly defined per network route configured |
|
||||
| **Requires adding full sets of configurations per routed resource?** | No, the routing peers in a Network are used to route all resources in that network | Yes, every network route needs to have a routing peer, distribution group, access control group, and the network range or DNS route |
|
||||
| **Allows edit routed resources?** | Yes, you can edit ranges or domains | No, you can't edit IP ranges or DNS routes once created |
|
||||
| **Allows edit names?** | Yes, names are editable | No, names are defined once while creating the route |
|
||||
| **Support to wildcard domains?** | Yes, wildcard domains are supported | No, network routes are limited to individual domains |
|
||||
| **Support for exit-nodes?** | No, even though that exit-nodes can be linked to on-premises or cloud networks, they invalidate other resources | Yes, but the same note is valid when using an exit-node to route other traffic to the same resources |
|
||||
| **Support for site-2-site IP ranges routing?** | No, but support is planned | Yes, when you create a network route without access control groups |
|
||||
|
||||
|
||||
## Use cases
|
||||
- [Routing traffic to multiple IP resources](/manage/networks/routing-traffic-to-multiple-resources)
|
||||
- [Accessing restricted website domain resources](/manage/networks/accessing-restricted-domain-resources)
|
||||
- [Accessing entire domains within networks](/manage/networks/accessing-entire-domains-within-networks)
|
||||
|
||||
## 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
|
||||
@@ -0,0 +1,111 @@
|
||||
# Routing traffic to multiple IP resources
|
||||
Adding routes to resources within on-premises or cloud is a common scenario for DevOps and Platform teams. In this guide, we will show you how to route traffic to multiple IP resources using NetBird's [Networks](/manage/networks) using [IP resources](/manage/networks#resources).
|
||||
|
||||
## Example
|
||||
In the following scenario, we will cover the case where all users have restricted access to internal DNS servers in the internal network, and the DevOps team has full access to the entire network.
|
||||
The network address is `172.16.0.0/15` and DNS servers has the IPs `172.16.30.2` and `172.17.100.2`.
|
||||
These IP ranges will be routed using [Routing peers](/manage/networks#routing-peers) running in the network.
|
||||
|
||||
### Create a Network
|
||||
To create a Network, navigate to the `Networks` > `Networks` section in the NetBird dashboard:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/view-wild-network-1.png" alt="new-net-1" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Click on `Add Network` to follow a Wizard that will guide you through the steps to create a network and add resources to it.
|
||||
|
||||
First, we fill out the network Name and Description as shown in the image below and click `Continue`:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/new-example-network-2.png" alt="new-net2" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
### Add a routing peer
|
||||
Next we are asked to add a routing peer to the network. Let's click on `Add routing peer` and select a node from that VPC:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-routing-peer-1.png" alt="new-example-routing-peer-1" className="imagewrapper"/>
|
||||
</p>
|
||||
Click on `Continue` and then accept the defaults to add a routing peer by clicking on `Add Routing Peer`:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-routing-peer-2.png" alt="new-routing-peer-2" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
### Add the network resource
|
||||
Following the guide, we are asked to add a new resource.
|
||||
|
||||
Click on `Add Resource` and enter the `Office network` name and use the IP range `172.16.0.0/15` as the address:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-resource-1.png" alt="new-example-resource-1" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
We can also assign a group to this resource; in this example, we will assign the group `office-network` to it. This way, we can create a policy that allows the DevOps team to access the entire IP range.
|
||||
|
||||
### Add an access control policy for the network resource
|
||||
Next, in the guide, we will be asked to create an access control policy. Here, we will create a policy that allows all access to the `office-network` group of the IP range `172.16.0.0/15`
|
||||
resource to peers in the `DevOps` group.
|
||||
|
||||
Click on `Create Policy` and fill out the fields as shown in the image below:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-resource-acl-1.png" alt="new-resource-acl-1" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Click on `Continue` 2 times and then click on `Add Policy` to save the policy:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-resource-acl-2.png" alt="new-resource-acl-2" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
### Add the DNS server resources
|
||||
Now, let's add the DNS servers resources to the network. Click on `Add Resource` and enter the IP address of the first DNS server:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-resource-2.png" alt="new-example-resource-2" className="imagewrapper"/>
|
||||
</p>
|
||||
We will use the same group, `office-dns-servers`, for both resources, allowing all users to access the DNS servers.
|
||||
|
||||
This time, when asked to create a policy, we will click on Later to skip it since we will create one more resource for this configuration.
|
||||
|
||||
Now, let's add another resource for the second DNS server:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-resource-3.png" alt="new-example-resource-3" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
### Add an access control policy for the DNS server resource
|
||||
This time, we will create a policy that allows access to the `office-dns-servers` group of DNS IP resources to peers in
|
||||
the `All users` group. They will be granted access only to the `UDP` port `53` of these servers.
|
||||
|
||||
Click on `Create Policy` and fill out the fields as shown in the image below:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-resource-acl-3.png" alt="new-resource-acl-3" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Click on `Continue` 2 times and then click on `Add Policy` to save the policy:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/add-example-resource-acl-4.png" alt="new-resource-acl-4" className="imagewrapper-big"/>
|
||||
</p>
|
||||
This time, we made the Policy name a bit more generic to cover both DNS server addresses.
|
||||
|
||||
### View the network
|
||||
After completing the wizard, you will be able to see the network you just created in the Networks list:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/view-example-network-1.png" alt="view-example-network-1" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
To access a detailed view of the network, click on the network name:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/networks/routing-traffic-to-multiple-resources/view-example-network-2.png" alt="view-example-network-2" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
You can edit or add more resources or routing peers to the network by clicking on the `Edit` buttons of each section in the detailed view.
|
||||
|
||||
With the steps above, we created resources that allow different levels of access to multiple user groups within a single organization network.
|
||||
|
||||
## 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
|
||||
Reference in New Issue
Block a user