mirror of
https://github.com/netbirdio/docs.git
synced 2026-04-16 15:36:36 +00:00
Streamlined site-to-site docs in new dedicated section. Removed old use-case guide and added redirects
This commit is contained in:
Ashley Mensah
@@ -510,6 +510,22 @@ const nextConfig = {
|
||||
destination: '/manage/dns/custom-zones',
|
||||
permanent: true,
|
||||
},
|
||||
// Site-to-site documentation restructure redirects
|
||||
{
|
||||
source: '/use-cases/setup-site-to-site-access',
|
||||
destination: '/manage/site-to-site',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/manage/peers/site-to-site/db-workload-migration',
|
||||
destination: '/manage/site-to-site/connect-cloud-environments',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/manage/networks/homelab/access-home-network',
|
||||
destination: '/manage/site-to-site/connect-home-networks',
|
||||
permanent: true,
|
||||
},
|
||||
]
|
||||
},
|
||||
rewrites: async () => {
|
||||
|
||||
@@ -92,16 +92,6 @@ export const docsNavigation = [
|
||||
},
|
||||
]
|
||||
},
|
||||
{
|
||||
title: 'Connect Site-to-Site',
|
||||
isOpen: true,
|
||||
links: [
|
||||
{
|
||||
title: 'Simplify Workload Migrations',
|
||||
href: '/manage/peers/site-to-site/db-workload-migration'
|
||||
},
|
||||
]
|
||||
},
|
||||
{ title: 'Auto Update', href: '/manage/peers/auto-update' },
|
||||
]
|
||||
},
|
||||
@@ -140,13 +130,17 @@ export const docsNavigation = [
|
||||
{ title: 'Route Traffic to Multiple IP resources', href: '/manage/networks/routing-traffic-to-multiple-resources' },
|
||||
{ title: 'Access Restricted Website Domain Resources', href: '/manage/networks/accessing-restricted-domain-resources' },
|
||||
{ title: 'Access Entire Domains Within Networks', href: '/manage/networks/accessing-entire-domains-within-networks' },
|
||||
{
|
||||
title: 'Homelab',
|
||||
isOpen: true,
|
||||
links: [
|
||||
{ title: 'Access Home Network', href: '/manage/networks/homelab/access-home-network' },
|
||||
]
|
||||
},
|
||||
]
|
||||
},
|
||||
{
|
||||
title: 'Site-to-Site',
|
||||
isOpen: false,
|
||||
links: [
|
||||
{ title: 'Overview', href: '/manage/site-to-site' },
|
||||
{ title: 'Connect Home Networks', href: '/manage/site-to-site/connect-home-networks' },
|
||||
{ title: 'Connect Office Networks', href: '/manage/site-to-site/connect-office-networks' },
|
||||
{ title: 'Connect Cloud Environments', href: '/manage/site-to-site/connect-cloud-environments' },
|
||||
{ title: 'Advanced Configuration', href: '/manage/site-to-site/advanced-configuration' },
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -353,7 +347,6 @@ export const docsNavigation = [
|
||||
{
|
||||
title: 'USE CASES',
|
||||
links: [
|
||||
{ title: 'Site-to-Site and Site-to-VPN', href: '/use-cases/setup-site-to-site-access' },
|
||||
{ title: 'Serverless and NetBird', href: '/use-cases/netbird-on-faas' },
|
||||
{ title: 'Routing peers and Kubernetes', href: '/use-cases/routing-peers-and-kubernetes' },
|
||||
{ title: 'Implement Zero Trust with NetBird', href: '/use-cases/implement-zero-trust' },
|
||||
|
||||
@@ -1,166 +0,0 @@
|
||||
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.
|
||||
@@ -1,375 +0,0 @@
|
||||
# Simplify Connectivity During Workload Migrations
|
||||
|
||||
For DevOps and platform engineering teams, workload migration presents significant challenges, especially when transferring
|
||||
data-intensive applications between different environments or cloud providers. Key challenges include:
|
||||
|
||||
* **Security Vulnerabilities**: Exposing databases or application servers to the public internet during migration increases
|
||||
the risk of data breaches and unauthorized access.
|
||||
* **Network Complexity**: Setting up VPNs or configuring firewall rules for temporary access complicates the migration
|
||||
process and can lead to misconfigurations.
|
||||
* **Performance Issues**: Traditional methods may suffer from latency and bandwidth limitations, slowing down large data
|
||||
transfers.
|
||||
|
||||
This guide introduces NetBird as a solution for secure and efficient workload migration by:
|
||||
|
||||
* **Enhancing Security**: Creating a secure overlay network that implements zero-trust principles, ensuring data remains protected throughout the migration process.
|
||||
* **Simplifying Network Configuration**: Eliminating the need for complex VPN setups or firewall rule changes, streamlining the migration workflow.
|
||||
* **Optimizing Performance**: Using NetBird's decentralized, point-to-point connections to bypass central servers, potentially reducing network bottlenecks and, thus, latency.
|
||||
|
||||
To demonstrate how to use NetBird for securely migrating workloads to the cloud while maintaining access to on-premise databases, we'll walk through the following process:
|
||||
|
||||
* Set up a local PostgreSQL database with a sample table, simulating an on-premise data resource.
|
||||
* Create a Python-based workload that interacts with this database, representing an on-premise application.
|
||||
* Migrate the Python workload to a cloud instance, while keeping the database on-premise.
|
||||
* Establish a secure connection between the cloud workload and on-premise database using NetBird.
|
||||
* Verify that the migrated cloud workload can securely access and interact with the on-premise database.
|
||||
|
||||
This practical scenario illustrates how NetBird enables organizations to use cloud resources for workloads while maintaining secure access to sensitive on-premise data, facilitating a hybrid cloud approach to database workload migration.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To follow along with this use case, ensure you meet the following requisites:
|
||||
|
||||
* A [NetBird account](https://app.netbird.io/)
|
||||
* [NetBird installed](https://docs.netbird.io/get-started/install) in your laptop or local machine.
|
||||
* A cloud-based VM instance (e.g., AWS EC2, Google Compute Engine, or Azure VM) to serve as the destination for the migrated workload.
|
||||
* Python 3.x installed on both source and destination instances.
|
||||
* Ability to create and use Python virtual environments on both instances (optional but recommended to avoid OS conflicts).
|
||||
* PostgreSQL and the corresponding client tools installed on the source (on-premise) instance.
|
||||
* Sufficient permissions to create and modify database users and edit `postgresql.conf` and `pg_hba.conf` configuration files.
|
||||
|
||||
Now that you have the prerequisites ready let's outline the process for creating a secure pathway for workload migration between your local environment and the remote cloud VM:
|
||||
|
||||
1. Creating the Testing Environment (Local Database and Workload)
|
||||
2. Installing and Configuring NetBird on Destination Instance(s)
|
||||
3. Setting Up NetBird's Access Control for Secure Data Transfer
|
||||
4. Preparing PostgreSQL Database for Remote Access via NetBird
|
||||
5. Initiating Secure Connection for Database Workload Migration
|
||||
|
||||
This approach ensures a protected and efficient migration of your workload, leveraging NetBird's capabilities for enhanced security and simplified networking.
|
||||
|
||||
## 1. Creating the Testing Environment (Local Database and Workload)
|
||||
|
||||
Create a new database and user:
|
||||
|
||||
```bash
|
||||
createdb demo_db
|
||||
createuser -s demo_user
|
||||
```
|
||||
|
||||
Connect to the database:
|
||||
|
||||
```bash
|
||||
psql -d demo_db
|
||||
```
|
||||
|
||||
Once connected, run the following SQL code to create the `employees` table and fill it with sample data:
|
||||
|
||||
```sql
|
||||
CREATE TABLE employees (
|
||||
id SERIAL PRIMARY KEY,
|
||||
name VARCHAR(100),
|
||||
department VARCHAR(100)
|
||||
);
|
||||
|
||||
INSERT INTO employees (name, department) VALUES
|
||||
('John Doe', 'IT'),
|
||||
('Jane Smith', 'HR'),
|
||||
('Mike Johnson', 'Sales');
|
||||
```
|
||||
|
||||
Verify the table was created by printing it to the terminal:
|
||||
|
||||
```bash
|
||||
$ psql -d demo_db -c "SELECT * FROM employees;"
|
||||
```
|
||||
|
||||
The expected output is:
|
||||
|
||||
```bash
|
||||
id | name | department
|
||||
----+--------------+------------
|
||||
1 | John Doe | IT
|
||||
2 | Jane Smith | HR
|
||||
3 | Mike Johnson | Sales
|
||||
(3 rows)
|
||||
```
|
||||
|
||||
With the database up and running, you are ready to create the local workload.
|
||||
|
||||
Create a new folder for the Python environment, then navigate to it and run:
|
||||
|
||||
```bash
|
||||
python3 -m venv venv
|
||||
```
|
||||
|
||||
Activate the `venv` virtual environment:
|
||||
|
||||
```bash
|
||||
source venv/bin/activate
|
||||
```
|
||||
|
||||
Install the dependencies for the demo workload:
|
||||
|
||||
```bash
|
||||
pip install psycopg2-binary
|
||||
```
|
||||
|
||||
Create the demo workload: `employee_workload.py`
|
||||
|
||||
```python
|
||||
import psycopg2
|
||||
|
||||
def get_employees():
|
||||
conn = psycopg2.connect(
|
||||
dbname="demo_db",
|
||||
user="demo_user",
|
||||
password="",
|
||||
host="localhost"
|
||||
)
|
||||
cur = conn.cursor()
|
||||
cur.execute("SELECT * FROM employees")
|
||||
rows = cur.fetchall()
|
||||
cur.close()
|
||||
conn.close()
|
||||
return rows
|
||||
|
||||
if __name__ == "__main__":
|
||||
employees = get_employees()
|
||||
print("(On-Premise) Employee List:")
|
||||
for employee in employees:
|
||||
print(f"ID: {employee[0]}, Name: {employee[1]}, Department: {employee[2]}")
|
||||
```
|
||||
|
||||
This is a simple workload that uses the `psycopg2` library to connect to the `demo_db` database you created a moment ago and then retrieve and print the values of the `employees` table to the terminal.
|
||||
|
||||
Run the script:
|
||||
|
||||
```bash
|
||||
python3 employee_workload.py
|
||||
```
|
||||
|
||||
Here's the expected output:
|
||||
|
||||
```bash
|
||||
(On-Premise) Employee List:
|
||||
ID: 1, Name: John Doe, Department: IT
|
||||
ID: 2, Name: Jane Smith, Department: HR
|
||||
ID: 3, Name: Mike Johnson, Department: Sales
|
||||
```
|
||||
|
||||
Notice the `(On-Premise)` label in the code. You'll change this to `(Remote)` after migration to distinguish between local and remote workloads.
|
||||
|
||||
## 2. Installing and Configuring NetBird on Destination Instance(s)
|
||||
|
||||
With the on-premise environment ready, you can install NetBird on the destination instance.
|
||||
|
||||
Login to NetBird and navigate to `Peers`. Ensure the source instance, the one hosting the database, is connected.
|
||||
|
||||
|
||||
|
||||
Next, generate a setup key for enhanced security when connecting your remote workload to the NetBird network:
|
||||
|
||||
* Go to `Setup Keys` in the left menu
|
||||
* Click `Create Setup Key`
|
||||
* Enter a descriptive name for the setup key (e.g., "Remote Workload 01"). Also, set an expiration date and define auto-assigned groups (if required). You can find [more information regarding setup key options in the documentation](https://docs.netbird.io/manage/peers/register-machines-using-setup-keys).
|
||||
* Copy the generated key since you'll need it shortly
|
||||
|
||||
|
||||
|
||||
To install the NetBird agent on the remote instance, run the following command:
|
||||
|
||||
```shell
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
```
|
||||
|
||||
The script automatically installs the NetBird agent and starts the corresponding service. Check the service is up and running:
|
||||
|
||||
```bash
|
||||
sudo systemctl status netbird
|
||||
```
|
||||
|
||||
The output should be similar to:
|
||||
|
||||
```bash
|
||||
● netbird.service - A WireGuard-based mesh network that connects your devices i>
|
||||
Loaded: loaded (/etc/systemd/system/netbird.service; enabled; preset: enab>
|
||||
Active: active (running) since Thu 2024-09-19 15:52:27 UTC; 24s ago
|
||||
Main PID: 2865 (netbird)
|
||||
Tasks: 5 (limit: 1113)
|
||||
Memory: 15.9M (peak: 16.1M)
|
||||
CPU: 24ms
|
||||
CGroup: /system.slice/netbird.service
|
||||
└─2865 /usr/bin/netbird service run --config /etc/netbird/config.j>
|
||||
```
|
||||
|
||||
To enable the service on startup, run:
|
||||
|
||||
```bash
|
||||
sudo systemctl enable netbird
|
||||
```
|
||||
|
||||
Now you can connect to the NetBird network using the setup key. Ensure to replace `<YOUR_SETUP_KEY>` with the key you generated:
|
||||
|
||||
```bash
|
||||
netbird up --setup-key <YOUR_SETUP_KEY>
|
||||
```
|
||||
|
||||
Check NetBird status by running:
|
||||
|
||||
```shell
|
||||
sudo netbird status
|
||||
```
|
||||
|
||||
The expected output is similar to the following:
|
||||
|
||||
```bash
|
||||
OS: linux/amd64
|
||||
Daemon version: 0.29.0
|
||||
CLI version: 0.29.0
|
||||
Management: Connected
|
||||
Signal: Connected
|
||||
Relays: 2/2 Available
|
||||
Nameservers: 0/0 Available
|
||||
FQDN: remote-workload.netbird.cloud
|
||||
NetBird IP: 100.85.195.197/16
|
||||
Interface type: Kernel
|
||||
Quantum resistance: false
|
||||
Routes: -
|
||||
Peers count: 0/0 Connected
|
||||
```
|
||||
|
||||
If everything goes as expected, you will see your remote workload in NetBird's `Peers` dashboard.
|
||||
|
||||
|
||||
|
||||
## 3. Setting Up NetBird's Access Control for Secure Data Transfer
|
||||
|
||||
NetBird's `Default` access control policy assigns all peers to the `All` group, enabling bidirectional access between devices and users. While this default setting allows immediate connectivity between your remote workload and on-premise database, it's recommended to implement stricter access controls. [NetBird Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access) enable you to limit connections to the on-premise instance, ensuring only authorized users or devices can access it, thus enhancing security.
|
||||
|
||||
To create a new policy:
|
||||
|
||||
* Go to `Access Control > Policies`
|
||||
* Click `Add Policy` to create a new policy. For more details on creating access policies, refer to [Managing Access with NetBird: Groups and Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access).
|
||||
|
||||
For this use case, we disabled the `Default` policy and created the following one:
|
||||
|
||||
* **Source Group**: `On-Premise-DB`
|
||||
* **Destination Group**: `Remote Workloads`
|
||||
* **Protocol**: TCP
|
||||
* **Port**: 5432 (default PostgreSQL port)
|
||||
* **Action**: Allow
|
||||
|
||||
This policy restricts access to the local environment where the database is running by only allowing the members of the group `Remote Workloads` to connect.
|
||||
|
||||
|
||||
|
||||
The next step is to assign peers to their respective groups. To add the remote instance to the `Remote Workloads` group:
|
||||
|
||||
* Navigate to `Peers` in the left menu
|
||||
* Click on `remote-workload` (or any name you gave to the remote instance)
|
||||
* Find the `Assigned Groups` field and select `Remote Workloads` from the dropdown list.
|
||||
|
||||
|
||||
|
||||
Follow a similar procedure to assign your local machine to the `On-Premise-DB` group:
|
||||
|
||||
* Locate and click on the local peer
|
||||
* Find the `Assigned Groups` field and select `On-Premise-DB` from the dropdown list.
|
||||
|
||||
|
||||
|
||||
Your network configuration is complete, enabling secure communication between the remote instance and your local machine via an encrypted WireGuard tunnel. However, additional adjustments are necessary to finalize the workload migration process.
|
||||
|
||||
## 4. Preparing PostgreSQL Database for Remote Access via NetBird
|
||||
|
||||
Your PostgreSQL database requires editing two files: `postgresql.conf` and `pg_hba.conf` to enable remote connections. Locate these files using the `psql` console, as their paths may vary based on your operating system and installation method:
|
||||
|
||||
```bash
|
||||
$ psql postgres
|
||||
```
|
||||
|
||||
Once logged, run the following commands:
|
||||
|
||||
```sql
|
||||
SHOW config_file;
|
||||
SHOW hba_file;
|
||||
```
|
||||
|
||||
The output should be similar to:
|
||||
|
||||
```sql
|
||||
config_file
|
||||
-------------------------------------------------
|
||||
/opt/homebrew/var/postgresql@14/postgresql.conf
|
||||
(1 row)
|
||||
|
||||
hba_file
|
||||
---------------------------------------------
|
||||
/opt/homebrew/var/postgresql@14/pg_hba.conf
|
||||
(1 row)
|
||||
```
|
||||
|
||||
Now edit `postgresql.conf`. Uncomment and modify the line `listen_address` as follows:
|
||||
|
||||
```bash
|
||||
listen_address = '*'
|
||||
```
|
||||
|
||||
Next, edit `pg_hba.conf` and add the following line:
|
||||
|
||||
```bash
|
||||
host all all 100.85.0.0/10 md5
|
||||
```
|
||||
|
||||
These changes allow PostgreSQL to listen on all interfaces and accept connections from the NetBird IP range (100.85.0.0/10). While sufficient for this example, keep in mind that production environments should implement stronger authentication and security options.
|
||||
|
||||
## 5. Initiating Secure Connection for Database Workload Migration
|
||||
|
||||
To complete the migration, deploy your workload to the remote instance by recreating the local setup: establish a Python virtual environment, install the `psycopg2-binary` library, and create `employee_workload.py`. However, in the Python code, you must update the `host` parameter, replacing `localhost` with the NetBird-assigned IP address of the remote instance. You can find this IP address in your peers' list on your NetBird dashboard.
|
||||
|
||||
|
||||
|
||||
Optionally, you can change the label `(On-Premise)` with `(Remote)` as mentioned earlier. The Python code should look similar to this:
|
||||
|
||||
```python
|
||||
import psycopg2
|
||||
|
||||
def get_employees():
|
||||
conn = psycopg2.connect(
|
||||
dbname="demo_db",
|
||||
user="demo_user",
|
||||
password="",
|
||||
host="NETBIRD_IP_OR_DOMAIN_NAME"
|
||||
)
|
||||
cur = conn.cursor()
|
||||
cur.execute("SELECT * FROM employees")
|
||||
rows = cur.fetchall()
|
||||
cur.close()
|
||||
conn.close()
|
||||
return rows
|
||||
|
||||
if __name__ == "__main__":
|
||||
employees = get_employees()
|
||||
print("(Remote) Employee List:")
|
||||
for employee in employees:
|
||||
print(f"ID: {employee[0]}, Name: {employee[1]}, Department: {employee[2]}")
|
||||
```
|
||||
|
||||
Now, run the script:
|
||||
|
||||
```bash
|
||||
python3 employee_workload.py
|
||||
```
|
||||
|
||||
Here's the output
|
||||
|
||||
```bash
|
||||
(Remote) Employee List:
|
||||
ID: 1, Name: John Doe, Department: IT
|
||||
ID: 2, Name: Jane Smith, Department: HR
|
||||
ID: 3, Name: Mike Johnson, Department: Sales
|
||||
```
|
||||
|
||||
This simple script confirms the migration was successful. You just established a secure, firewall-free connection from your remote instance to your on-premise database via NetBird, which demonstrates its power in simplifying robust network security.
|
||||
|
||||
301
src/pages/manage/site-to-site/advanced-configuration.mdx
Normal file
301
src/pages/manage/site-to-site/advanced-configuration.mdx
Normal file
@@ -0,0 +1,301 @@
|
||||
import { Note, Warning } from '@/components/mdx'
|
||||
|
||||
# Advanced Configuration
|
||||
|
||||
This guide covers technical details for site-to-site connectivity, including masquerade options, access control configuration, and troubleshooting.
|
||||
|
||||
## Understanding Masquerade
|
||||
|
||||
Masquerade determines how source IP addresses are handled when traffic passes through a routing peer.
|
||||
|
||||
### With Masquerade (Default)
|
||||
|
||||
When enabled, the routing peer performs NAT on forwarded traffic:
|
||||
- Source IP is replaced with the routing peer's NetBird IP
|
||||
- Return traffic is automatically translated back
|
||||
- Simpler setup—no additional routing configuration needed on remote networks
|
||||
|
||||
```
|
||||
Device A (192.168.1.50) → Routing Peer → [Source becomes 100.64.0.10] → Remote Network
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- Works out of the box
|
||||
- No configuration needed on the remote network
|
||||
- Compatible with Networks and Network Routes
|
||||
|
||||
**Disadvantages:**
|
||||
- Original source IP is hidden
|
||||
- Access control is limited to the routing peer level
|
||||
- Audit logs show routing peer IP, not original device
|
||||
|
||||
### Without Masquerade
|
||||
|
||||
When disabled, original source IPs are preserved:
|
||||
- Traffic appears to come from the original device
|
||||
- Remote network must have routes back to the source network
|
||||
- Required for some compliance and auditing scenarios
|
||||
|
||||
```
|
||||
Device A (192.168.1.50) → Routing Peer → [Source stays 192.168.1.50] → Remote Network
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- Source IP preserved for auditing
|
||||
- More accurate traffic analysis
|
||||
- Required for certain network configurations
|
||||
|
||||
**Disadvantages:**
|
||||
- Requires manual route configuration on both ends
|
||||
- NetBird access control cannot restrict individual source devices
|
||||
- More complex setup
|
||||
|
||||
<Warning>
|
||||
Without masquerade, traffic from unknown source IPs will be rejected by NetBird's policy engine. You cannot use ACL Groups or Network Resources without masquerade enabled.
|
||||
</Warning>
|
||||
|
||||
## Choosing the Right Approach
|
||||
|
||||
| Requirement | Recommended Approach |
|
||||
|------------|---------------------|
|
||||
| Simple remote access | Networks with masquerade |
|
||||
| Site-to-site with access control | Network Routes with masquerade and ACL Groups |
|
||||
| Audit trail needs source IPs | Network Routes without masquerade + OS firewall |
|
||||
| Compliance requirements | Depends on specific requirements |
|
||||
|
||||
## Network Routes with ACL Groups
|
||||
|
||||
ACL Groups provide route-level access control when using Network Routes with masquerade.
|
||||
|
||||
### How ACL Groups Work
|
||||
|
||||
1. Create a Network Route with an ACL Group assigned
|
||||
2. Create access policies that grant access to the ACL Group
|
||||
3. Only peers with policies granting access to the ACL Group can use the route
|
||||
|
||||
### Configuration Example
|
||||
|
||||
**Step 1: Create the Network Route**
|
||||
|
||||
1. Go to **Network Routes**
|
||||
2. Add route for `192.168.100.0/24`
|
||||
3. Select your routing peer
|
||||
4. Enable Masquerade
|
||||
5. Add ACL Group: "remote-resources"
|
||||
|
||||
**Step 2: Create Access Policies**
|
||||
|
||||
For the route to be active, you need at least one policy granting access to the routing peer:
|
||||
|
||||
```
|
||||
Source: any-group → Destination: routing-peer-group (any protocol)
|
||||
```
|
||||
|
||||
To grant access to the routed network:
|
||||
|
||||
```
|
||||
Source: authorized-users → Destination: remote-resources (TCP, specific ports)
|
||||
```
|
||||
|
||||
<Note>
|
||||
The routing peer must be accessible via some policy for the route to activate. The route itself is controlled by policies targeting the ACL Group.
|
||||
</Note>
|
||||
|
||||
## Site-to-Site Configuration Details
|
||||
|
||||
### Bidirectional Route Setup
|
||||
|
||||
Site-to-site requires routes in both directions:
|
||||
|
||||
**Site A → Site B:**
|
||||
- Network Route: Site B's subnet
|
||||
- Routing Peer: Site A's routing peer
|
||||
- Masquerade: Enable for simplicity
|
||||
|
||||
**Site B → Site A:**
|
||||
- Network Route: Site A's subnet
|
||||
- Routing Peer: Site B's routing peer
|
||||
- Masquerade: Enable for simplicity
|
||||
|
||||
### Access Policies for Site-to-Site
|
||||
|
||||
At minimum, routing peers need connectivity:
|
||||
|
||||
```
|
||||
Source: site-a-routing-peers → Destination: site-b-routing-peers (All)
|
||||
```
|
||||
|
||||
For ACL Group-controlled access:
|
||||
|
||||
```
|
||||
Source: site-a-resources → Destination: site-b-resources (specific protocols)
|
||||
Source: site-b-resources → Destination: site-a-resources (specific protocols)
|
||||
```
|
||||
|
||||
### Configuring Clientless Devices
|
||||
|
||||
Devices without NetBird need routes to remote networks through the local routing peer.
|
||||
|
||||
**Linux:**
|
||||
|
||||
```bash
|
||||
# Temporary route
|
||||
sudo ip route add 192.168.200.0/24 via 192.168.100.10
|
||||
|
||||
# Persistent route (Ubuntu/Debian with Netplan)
|
||||
# Edit /etc/netplan/01-netcfg.yaml
|
||||
network:
|
||||
ethernets:
|
||||
eth0:
|
||||
routes:
|
||||
- to: 192.168.200.0/24
|
||||
via: 192.168.100.10
|
||||
```
|
||||
|
||||
**Windows (PowerShell as Administrator):**
|
||||
|
||||
```powershell
|
||||
# Temporary route
|
||||
route add 192.168.200.0 mask 255.255.255.0 192.168.100.10
|
||||
|
||||
# Persistent route
|
||||
route -p add 192.168.200.0 mask 255.255.255.0 192.168.100.10
|
||||
```
|
||||
|
||||
**macOS:**
|
||||
|
||||
```bash
|
||||
# Temporary route
|
||||
sudo route add -net 192.168.200.0/24 192.168.100.10
|
||||
|
||||
# Persistent routes require a launch daemon or network configuration tool
|
||||
```
|
||||
|
||||
**Router-level (recommended):**
|
||||
|
||||
Configure your router to advertise routes via DHCP or add static routes that apply to all devices on the network.
|
||||
|
||||
## Networks vs Network Routes Detailed Comparison
|
||||
|
||||
| Aspect | Networks | Network Routes |
|
||||
|--------|----------|----------------|
|
||||
| Supported scenarios | VPN-to-Site only | All (VPN-to-Site, Site-to-VPN, Site-to-Site) |
|
||||
| Access control | Per-resource policies | Per-route with ACL Groups |
|
||||
| Masquerade | Always enabled | Configurable |
|
||||
| Setup complexity | Simpler UI workflow | More manual configuration |
|
||||
| Routing peer redundancy | Built-in | Manual configuration |
|
||||
| Policy requirement | Only resource policies | Routing peer + ACL Group policies |
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Route Not Active
|
||||
|
||||
**Symptoms:** Peers don't see the route; `netbird routes list` shows nothing
|
||||
|
||||
**Causes:**
|
||||
1. No access policy grants access to the routing peer
|
||||
2. Routing peer is offline
|
||||
3. ACL Group has no policies granting access
|
||||
|
||||
**Solution:**
|
||||
- Ensure at least one policy connects to the routing peer's group
|
||||
- Verify routing peer status in the dashboard
|
||||
- Check ACL Group policies exist
|
||||
|
||||
### Traffic Times Out
|
||||
|
||||
**Symptoms:** Ping or connections hang, no response
|
||||
|
||||
**Causes:**
|
||||
1. Routing peer can't reach the destination network
|
||||
2. Masquerade disabled and no return route exists
|
||||
3. Firewall blocking traffic
|
||||
|
||||
**Solution:**
|
||||
- Test from the routing peer: `ping <destination>` directly
|
||||
- If masquerade is off, verify return routes are configured
|
||||
- Check OS firewall on routing peer: `iptables -L -n` or equivalent
|
||||
|
||||
### Connection Works One Way
|
||||
|
||||
**Symptoms:** Can reach remote site but responses don't return
|
||||
|
||||
**Causes:**
|
||||
1. Missing reverse route (site-to-site)
|
||||
2. Asymmetric policies
|
||||
3. Stateful firewall issues
|
||||
|
||||
**Solution:**
|
||||
- Ensure routes exist in both directions
|
||||
- Verify policies allow return traffic
|
||||
- Check firewall state tracking
|
||||
|
||||
### Wrong Traffic Routed
|
||||
|
||||
**Symptoms:** Unexpected traffic going through NetBird
|
||||
|
||||
**Causes:**
|
||||
1. Overlapping routes
|
||||
2. Route priority issues
|
||||
3. Incorrect subnet configuration
|
||||
|
||||
**Solution:**
|
||||
- Review all Network Routes for overlaps
|
||||
- Use more specific routes where needed
|
||||
- Verify subnet CIDR notation is correct
|
||||
|
||||
### Debugging Commands
|
||||
|
||||
**On the routing peer:**
|
||||
|
||||
```bash
|
||||
# Check NetBird status
|
||||
netbird status
|
||||
|
||||
# List active routes
|
||||
netbird routes list
|
||||
|
||||
# Check system routes
|
||||
ip route show
|
||||
|
||||
# Monitor traffic (Linux)
|
||||
sudo tcpdump -i any -n host 192.168.200.50
|
||||
|
||||
# Check forwarding is enabled
|
||||
cat /proc/sys/net/ipv4/ip_forward
|
||||
```
|
||||
|
||||
**On a client peer:**
|
||||
|
||||
```bash
|
||||
# Check which route is being used
|
||||
netbird networks ls
|
||||
|
||||
# Trace the path
|
||||
traceroute 192.168.200.50
|
||||
```
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
### Routing Peer Placement
|
||||
|
||||
- Place routing peers on machines with good network connectivity
|
||||
- Avoid routing through bandwidth-constrained links
|
||||
- Consider dedicated hardware for high-traffic scenarios
|
||||
|
||||
### Multiple Routing Peers
|
||||
|
||||
For high availability or load distribution:
|
||||
- Deploy multiple routing peers for the same route
|
||||
- NetBird will distribute traffic across available peers
|
||||
- Monitor peer health and remove failed peers promptly
|
||||
|
||||
### Monitoring
|
||||
|
||||
Track these metrics for routing peers:
|
||||
- CPU and memory usage
|
||||
- Network throughput
|
||||
- Connection count
|
||||
- Packet loss and latency
|
||||
|
||||
Use NetBird's [activity logging](/manage/activity) to monitor access patterns and troubleshoot issues.
|
||||
287
src/pages/manage/site-to-site/connect-cloud-environments.mdx
Normal file
287
src/pages/manage/site-to-site/connect-cloud-environments.mdx
Normal file
@@ -0,0 +1,287 @@
|
||||
import { Note, Warning } from '@/components/mdx'
|
||||
|
||||
# Connect Cloud Environments
|
||||
|
||||
This guide helps DevOps engineers set up secure connectivity between cloud environments, on-premise infrastructure, and hybrid deployments.
|
||||
|
||||
## What You'll Achieve
|
||||
|
||||
After following this guide, you'll be able to:
|
||||
- Connect cloud workloads to on-premise databases (VPN-to-Site)
|
||||
- Bridge multiple cloud providers (Site-to-Site)
|
||||
- Enable secure workload migration between environments
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A [NetBird account](https://app.netbird.io/)
|
||||
- Access to deploy VMs or containers in your cloud environment
|
||||
- Network configuration permissions in your cloud VPC
|
||||
|
||||
## Scenario 1: Cloud Workload Accessing On-Premise Database
|
||||
|
||||
A common hybrid cloud pattern: your application runs in the cloud but needs to access an on-premise database.
|
||||
|
||||
### Architecture Overview
|
||||
|
||||
```
|
||||
Cloud VM ────► NetBird Tunnel ────► Routing Peer ────► Database Server
|
||||
(peer) (peer) (on-premise)
|
||||
```
|
||||
|
||||
### Step 1: Deploy a Routing Peer On-Premise
|
||||
|
||||
Install NetBird on a server in your data center that can reach the database:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
```
|
||||
|
||||
Create a setup key in the dashboard and connect:
|
||||
|
||||
```bash
|
||||
sudo netbird up --setup-key YOUR_SETUP_KEY
|
||||
```
|
||||
|
||||
### Step 2: Create a Network for On-Premise Resources
|
||||
|
||||
1. Go to **Networks** in the dashboard
|
||||
2. Click **Add Network** and name it "On-Premise Data Center"
|
||||
3. Click **Add Resource**
|
||||
4. Add your database subnet or specific IP (e.g., `10.100.0.0/24` or `10.100.0.50/32`)
|
||||
5. Assign to a group like "on-prem-databases"
|
||||
|
||||
### Step 3: Add the Routing Peer
|
||||
|
||||
1. In your network, click **Add Routing Peer**
|
||||
2. Select your on-premise server
|
||||
3. Click **Add Routing Peer**
|
||||
|
||||
### Step 4: Deploy NetBird on Cloud Workloads
|
||||
|
||||
**For VMs:**
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
sudo netbird up --setup-key YOUR_CLOUD_SETUP_KEY
|
||||
```
|
||||
|
||||
**For containers (Docker Compose):**
|
||||
|
||||
```yaml
|
||||
services:
|
||||
netbird:
|
||||
image: netbirdio/netbird:latest
|
||||
network_mode: host
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
environment:
|
||||
- NB_SETUP_KEY=YOUR_SETUP_KEY
|
||||
volumes:
|
||||
- netbird-config:/etc/netbird
|
||||
restart: unless-stopped
|
||||
|
||||
volumes:
|
||||
netbird-config:
|
||||
```
|
||||
|
||||
**For Kubernetes:**
|
||||
|
||||
Use the [NetBird Kubernetes Operator](/manage/integrations/kubernetes) for production deployments.
|
||||
|
||||
### Step 5: Create Access Policies
|
||||
|
||||
1. Go to **Access Control > Policies**
|
||||
2. Create a policy:
|
||||
- Source: Group containing your cloud workloads
|
||||
- Destination: "on-prem-databases"
|
||||
- Protocol: TCP
|
||||
- Ports: 5432 (PostgreSQL), 3306 (MySQL), etc.
|
||||
|
||||
### Step 6: Configure Your Application
|
||||
|
||||
Update your application's database connection to use the on-premise IP:
|
||||
|
||||
```python
|
||||
# Example: Python with PostgreSQL
|
||||
conn = psycopg2.connect(
|
||||
host="10.100.0.50", # On-premise database IP
|
||||
dbname="production",
|
||||
user="app_user",
|
||||
password="secure_password"
|
||||
)
|
||||
```
|
||||
|
||||
Your cloud application can now securely access the on-premise database.
|
||||
|
||||
---
|
||||
|
||||
## Scenario 2: Multi-Cloud Connectivity (Site-to-Site)
|
||||
|
||||
Connect workloads across different cloud providers (AWS, GCP, Azure) without exposing them to the public internet.
|
||||
|
||||
<Note>
|
||||
Multi-cloud site-to-site requires Network Routes because the Networks feature doesn't yet support this scenario.
|
||||
</Note>
|
||||
|
||||
### Architecture Overview
|
||||
|
||||
```
|
||||
AWS VPC ────► Routing Peer ────► NetBird ────► Routing Peer ────► GCP VPC
|
||||
(10.0.0.0/16) (peer) (peer) (10.1.0.0/16)
|
||||
```
|
||||
|
||||
### Step 1: Deploy Routing Peers in Each Cloud
|
||||
|
||||
**AWS:**
|
||||
|
||||
Launch an EC2 instance in your VPC with NetBird installed. Use the following user data:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
netbird up --setup-key YOUR_AWS_SETUP_KEY
|
||||
```
|
||||
|
||||
**GCP:**
|
||||
|
||||
Launch a Compute Engine instance in your VPC:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
netbird up --setup-key YOUR_GCP_SETUP_KEY
|
||||
```
|
||||
|
||||
### Step 2: Create Network Routes
|
||||
|
||||
**For AWS VPC:**
|
||||
1. Go to **Network Routes**
|
||||
2. Add route: `10.0.0.0/16`
|
||||
3. Routing peer: Your AWS instance
|
||||
4. Enable Masquerade
|
||||
|
||||
**For GCP VPC:**
|
||||
1. Add route: `10.1.0.0/16`
|
||||
2. Routing peer: Your GCP instance
|
||||
3. Enable Masquerade
|
||||
|
||||
### Step 3: Create Access Policies
|
||||
|
||||
Create policies allowing the routing peers to communicate:
|
||||
|
||||
1. Go to **Access Control > Policies**
|
||||
2. Create bidirectional policies between the routing peer groups
|
||||
|
||||
### Step 4: Configure VPC Routing
|
||||
|
||||
**AWS VPC:**
|
||||
|
||||
Add a route in your route table:
|
||||
- Destination: `10.1.0.0/16` (GCP CIDR)
|
||||
- Target: Your NetBird routing peer instance
|
||||
|
||||
**GCP VPC:**
|
||||
|
||||
Add a custom route:
|
||||
- Destination: `10.0.0.0/16` (AWS CIDR)
|
||||
- Next hop: Your NetBird routing peer instance
|
||||
|
||||
### Step 5: Test Connectivity
|
||||
|
||||
From an AWS instance:
|
||||
|
||||
```bash
|
||||
ping 10.1.0.100 # GCP instance
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Scenario 3: Secure Workload Migration
|
||||
|
||||
Migrate workloads between environments while maintaining connectivity to dependencies.
|
||||
|
||||
### Example: Migrating from On-Premise to Cloud
|
||||
|
||||
1. **Before migration**: Application and database both on-premise
|
||||
2. **During migration**: Application in cloud, database still on-premise
|
||||
3. **After migration**: Both in cloud (NetBird connection can be removed or repurposed)
|
||||
|
||||
### Step 1: Establish Connectivity First
|
||||
|
||||
Before migrating the application, set up VPN-to-Site connectivity (Scenario 1) so the cloud application can reach the on-premise database.
|
||||
|
||||
### Step 2: Deploy the Cloud Application
|
||||
|
||||
Deploy your application in the cloud with NetBird configured. Test that it can reach the on-premise database.
|
||||
|
||||
### Step 3: Cutover
|
||||
|
||||
Switch traffic to the cloud application. The database connection works identically—just over NetBird instead of the local network.
|
||||
|
||||
### Step 4: Complete Migration
|
||||
|
||||
Once the database is also migrated to the cloud:
|
||||
1. Update the application's database connection to the new cloud IP
|
||||
2. Remove the on-premise network from NetBird
|
||||
3. Optionally remove NetBird from the application if no longer needed
|
||||
|
||||
---
|
||||
|
||||
## Cloud-Specific Considerations
|
||||
|
||||
### AWS
|
||||
|
||||
- Use VPC endpoints where possible for AWS services
|
||||
- Security groups must allow traffic from the NetBird routing peer
|
||||
- Consider using an Auto Scaling group for the routing peer with a static ENI
|
||||
|
||||
### GCP
|
||||
|
||||
- Firewall rules must allow traffic from the routing peer's internal IP
|
||||
- Use instance groups for high availability
|
||||
- Enable IP forwarding on the routing peer instance
|
||||
|
||||
### Azure
|
||||
|
||||
- Network security groups must allow traffic from the routing peer
|
||||
- Consider using a Virtual Machine Scale Set for HA
|
||||
- Enable IP forwarding on the routing peer NIC
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Security
|
||||
|
||||
- Use dedicated setup keys per environment (dev, staging, production)
|
||||
- Restrict access policies to specific ports and protocols
|
||||
- Enable [activity logging](/manage/activity) for compliance
|
||||
|
||||
### High Availability
|
||||
|
||||
- Deploy multiple routing peers and configure failover
|
||||
- Monitor routing peer health with your existing tools
|
||||
- Use cloud-native load balancing where appropriate
|
||||
|
||||
### Performance
|
||||
|
||||
- Place routing peers close to the resources they serve
|
||||
- Use direct peering where possible (NetBird will automatically optimize paths)
|
||||
- Monitor latency and throughput between environments
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Cloud workload can't reach on-premise:**
|
||||
1. Verify the routing peer is online: `netbird status`
|
||||
2. Check the routing peer can reach the target: `ping 10.100.0.50`
|
||||
3. Verify access policies are configured correctly
|
||||
|
||||
**Multi-cloud connectivity issues:**
|
||||
1. Confirm both routing peers are connected to NetBird
|
||||
2. Check VPC routing tables have correct entries
|
||||
3. Verify security groups/firewall rules allow traffic
|
||||
|
||||
**High latency:**
|
||||
1. Check routing peer placement and network connectivity
|
||||
2. Verify traffic is using direct peer-to-peer connections (not relays)
|
||||
3. Review cloud network configuration for bottlenecks
|
||||
|
||||
For advanced configuration including masquerade options and detailed access control, see [Advanced Configuration](/manage/site-to-site/advanced-configuration).
|
||||
207
src/pages/manage/site-to-site/connect-home-networks.mdx
Normal file
207
src/pages/manage/site-to-site/connect-home-networks.mdx
Normal file
@@ -0,0 +1,207 @@
|
||||
import { Note, Warning } from '@/components/mdx'
|
||||
|
||||
# Connect Home Networks
|
||||
|
||||
This guide helps homelabbers set up remote access to home network devices and optionally connect multiple home networks together.
|
||||
|
||||
## What You'll Achieve
|
||||
|
||||
After following this guide, you'll be able to:
|
||||
- Access your NAS, media server, or home automation from anywhere (VPN-to-Site)
|
||||
- Optionally connect two home networks together so devices can communicate (Site-to-Site)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A [NetBird account](https://app.netbird.io/)
|
||||
- NetBird installed on your laptop or phone ([installation guide](/get-started/install))
|
||||
- An always-on device at home to serve as the routing peer (Raspberry Pi, NAS with Docker, old laptop, etc.)
|
||||
|
||||
## Part 1: Access Home Devices from Anywhere (VPN-to-Site)
|
||||
|
||||
This is the most common homelab scenario: you're traveling and want to access devices on your home network.
|
||||
|
||||
### Step 1: Connect Your Laptop to NetBird
|
||||
|
||||
If you haven't already, install NetBird on your laptop and connect:
|
||||
|
||||
1. Download NetBird from [app.netbird.io/install](https://app.netbird.io/install)
|
||||
2. Run the application and click **Connect** in the system tray
|
||||
3. Complete the sign-up process in your browser
|
||||
4. Verify your device appears in the [NetBird dashboard](https://app.netbird.io/) under **Peers**
|
||||
|
||||
### Step 2: Find Your Home Subnet
|
||||
|
||||
Before configuring NetBird, identify your home network's subnet.
|
||||
|
||||
**On your routing peer device, run:**
|
||||
|
||||
```bash
|
||||
# Linux
|
||||
ip route | grep -E "^[0-9]"
|
||||
|
||||
# macOS
|
||||
netstat -rn | grep default
|
||||
```
|
||||
|
||||
Look for your local subnet, typically something like `192.168.1.0/24` or `192.168.0.0/24`.
|
||||
|
||||
### Step 3: Create a Network for Your Home LAN
|
||||
|
||||
1. Go to **Networks** in the NetBird dashboard
|
||||
2. Click **Add Network**
|
||||
3. Name it "Home LAN" and click **Save**
|
||||
|
||||
### Step 4: Add Your Home Subnet as a Resource
|
||||
|
||||
1. In your new network, click **Add Resource**
|
||||
2. Enter a name like "Home Subnet"
|
||||
3. Enter your home subnet (e.g., `192.168.1.0/24`)
|
||||
4. Create a group called "home-lan" for the destination
|
||||
5. Click **Add Resource**
|
||||
|
||||
<Note>
|
||||
For more granular access, add specific device IPs instead of the entire subnet. For example, add `192.168.1.50/32` to only allow access to your NAS.
|
||||
</Note>
|
||||
|
||||
### Step 5: Create an Access Policy
|
||||
|
||||
1. After adding your resource, click **Create Policy**
|
||||
2. Set **Source** to a group containing your devices (e.g., "All Users" or create "Home Users")
|
||||
3. Set **Destination** to "home-lan"
|
||||
4. Set **Protocol** to All
|
||||
5. Name it "Home LAN Access" and click **Add Policy**
|
||||
|
||||
### Step 6: Set Up the Routing Peer
|
||||
|
||||
The routing peer forwards traffic from NetBird to your local network. Use any always-on device:
|
||||
- Raspberry Pi
|
||||
- Synology/QNAP NAS (via Docker)
|
||||
- Old laptop running Linux
|
||||
- Home server
|
||||
|
||||
**Install NetBird on your routing peer:**
|
||||
|
||||
1. In the NetBird dashboard, go to **Setup Keys**
|
||||
2. Create a new setup key (one-time use recommended)
|
||||
3. On your routing peer, run:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
sudo netbird up --setup-key YOUR_SETUP_KEY
|
||||
```
|
||||
|
||||
4. In the Networks view, click **Add Routing Peer** on your Home LAN network
|
||||
5. Select your new peer and click **Add Routing Peer**
|
||||
|
||||
### Step 7: Test the Connection
|
||||
|
||||
From your laptop (connected to a different network like mobile data or coffee shop WiFi):
|
||||
|
||||
```bash
|
||||
ping 192.168.1.1 # Your router
|
||||
ping 192.168.1.50 # Your NAS or other device
|
||||
```
|
||||
|
||||
You can now access your home devices from anywhere.
|
||||
|
||||
---
|
||||
|
||||
## Part 2: Connect Two Home Networks (Site-to-Site)
|
||||
|
||||
Want to connect your home network with a family member's? This requires Network Routes instead of Networks.
|
||||
|
||||
<Note>
|
||||
Site-to-site requires Network Routes because the Networks feature doesn't yet support bidirectional routing between sites.
|
||||
</Note>
|
||||
|
||||
### Example Scenario
|
||||
|
||||
- **Your home**: `192.168.1.0/24` with routing peer "home-rpi"
|
||||
- **Parents' home**: `192.168.2.0/24` with routing peer "parents-rpi"
|
||||
|
||||
### Step 1: Set Up Routing Peers at Both Locations
|
||||
|
||||
Install NetBird on a device at each home following the same process as Part 1, Step 6.
|
||||
|
||||
### Step 2: Create Network Routes
|
||||
|
||||
1. Go to **Network Routes** in the dashboard
|
||||
2. Click **Add Route**
|
||||
|
||||
**For your home network:**
|
||||
- Network: `192.168.1.0/24`
|
||||
- Routing Peer: Select "home-rpi"
|
||||
- Enable **Masquerade** (recommended)
|
||||
- Click **Save**
|
||||
|
||||
**For parents' home network:**
|
||||
- Network: `192.168.2.0/24`
|
||||
- Routing Peer: Select "parents-rpi"
|
||||
- Enable **Masquerade** (recommended)
|
||||
- Click **Save**
|
||||
|
||||
### Step 3: Create Access Policies
|
||||
|
||||
Create policies that allow the routing peers to communicate:
|
||||
|
||||
1. Go to **Access Control > Policies**
|
||||
2. Add a policy:
|
||||
- Source: Group containing "home-rpi"
|
||||
- Destination: Group containing "parents-rpi"
|
||||
- Protocol: All (or restrict as needed)
|
||||
|
||||
### Step 4: Configure Clientless Devices
|
||||
|
||||
For devices without NetBird to reach the other network, add a static route pointing to the local routing peer.
|
||||
|
||||
**Example on a Linux device at your home:**
|
||||
|
||||
```bash
|
||||
# Route to parents' network through your routing peer
|
||||
sudo ip route add 192.168.2.0/24 via 192.168.1.100
|
||||
```
|
||||
|
||||
Where `192.168.1.100` is your routing peer's local IP.
|
||||
|
||||
<Note>
|
||||
For persistent routes, configure them in your router's DHCP settings or the device's network configuration.
|
||||
</Note>
|
||||
|
||||
### Step 5: Test Cross-Network Access
|
||||
|
||||
From a device at your home:
|
||||
|
||||
```bash
|
||||
ping 192.168.2.1 # Parents' router
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Home Devices to Access
|
||||
|
||||
| Device | Typical Access Method |
|
||||
|--------|----------------------|
|
||||
| Synology/QNAP NAS | Web UI (port 5000/5001), SMB shares |
|
||||
| Home Assistant | Web UI (port 8123) |
|
||||
| Plex/Jellyfin | Web UI (port 32400/8096) |
|
||||
| Pi-hole | Web UI (port 80), DNS (port 53) |
|
||||
| Security cameras | RTSP streams, web interfaces |
|
||||
| Printers | IPP/AirPrint, web interfaces |
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Can't reach home devices:**
|
||||
1. Verify the routing peer is online: check `netbird status` on the routing peer
|
||||
2. Ensure the routing peer can reach local devices: `ping 192.168.1.1` from the routing peer
|
||||
3. Check that your access policy includes your user/device
|
||||
|
||||
**Intermittent connectivity:**
|
||||
1. Ensure the routing peer has a stable internet connection
|
||||
2. Check if your ISP blocks VPN traffic (try a different port or protocol)
|
||||
|
||||
**Site-to-site not working:**
|
||||
1. Verify both routing peers are online and connected
|
||||
2. Check that static routes are configured on clientless devices
|
||||
3. Ensure access policies allow traffic in both directions
|
||||
|
||||
For advanced configuration options including masquerade settings and access control, see [Advanced Configuration](/manage/site-to-site/advanced-configuration).
|
||||
238
src/pages/manage/site-to-site/connect-office-networks.mdx
Normal file
238
src/pages/manage/site-to-site/connect-office-networks.mdx
Normal file
@@ -0,0 +1,238 @@
|
||||
import { Note, Warning } from '@/components/mdx'
|
||||
|
||||
# Connect Office Networks
|
||||
|
||||
This guide helps IT administrators set up secure remote access to office resources and connect multiple office locations.
|
||||
|
||||
## What You'll Achieve
|
||||
|
||||
After following this guide, you'll be able to:
|
||||
- Enable remote workers to access office resources (VPN-to-Site)
|
||||
- Allow office systems to reach remote workers (Site-to-VPN)
|
||||
- Connect branch offices to headquarters (Site-to-Site)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A [NetBird account](https://app.netbird.io/)
|
||||
- Admin access to office network infrastructure
|
||||
- A server or VM at each office location to serve as the routing peer
|
||||
|
||||
## Scenario 1: Remote Worker Access (VPN-to-Site)
|
||||
|
||||
The most common business scenario: employees need to access office resources while working remotely.
|
||||
|
||||
### Step 1: Deploy a Routing Peer at the Office
|
||||
|
||||
Choose an always-on server at your office. This can be:
|
||||
- A dedicated Linux VM
|
||||
- A Windows Server
|
||||
- A Docker container on an existing server
|
||||
|
||||
**Install NetBird:**
|
||||
|
||||
```bash
|
||||
# Linux
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
|
||||
# Windows (PowerShell as Administrator)
|
||||
Invoke-WebRequest -Uri "https://pkgs.netbird.io/install.ps1" -OutFile "install.ps1"; .\install.ps1
|
||||
```
|
||||
|
||||
**Connect using a setup key:**
|
||||
|
||||
1. In the NetBird dashboard, go to **Setup Keys**
|
||||
2. Create a reusable key for server deployments
|
||||
3. Run: `netbird up --setup-key YOUR_SETUP_KEY`
|
||||
|
||||
### Step 2: Create a Network for Office Resources
|
||||
|
||||
1. Go to **Networks** in the dashboard
|
||||
2. Click **Add Network** and name it "Office LAN"
|
||||
3. Click **Add Resource** and enter your office subnet (e.g., `10.0.0.0/24`)
|
||||
4. Assign it to a group like "office-resources"
|
||||
|
||||
### Step 3: Add the Routing Peer
|
||||
|
||||
1. In the Office LAN network, click **Add Routing Peer**
|
||||
2. Select your office server
|
||||
3. Click **Add Routing Peer**
|
||||
|
||||
### Step 4: Create Access Policies
|
||||
|
||||
1. Go to **Access Control > Policies**
|
||||
2. Create a policy:
|
||||
- Name: "Remote Worker Office Access"
|
||||
- Source: "Remote Workers" group (or appropriate user group)
|
||||
- Destination: "office-resources"
|
||||
- Protocol: Choose based on needs (TCP for most apps, All for full access)
|
||||
|
||||
### Step 5: Onboard Remote Workers
|
||||
|
||||
Distribute NetBird to remote workers:
|
||||
|
||||
1. Create setup keys for employee devices
|
||||
2. Have employees install NetBird and connect
|
||||
3. Add employees to the "Remote Workers" group
|
||||
|
||||
Employees can now access office resources from any location.
|
||||
|
||||
---
|
||||
|
||||
## Scenario 2: Office Systems Reaching Remote Workers (Site-to-VPN)
|
||||
|
||||
Some scenarios require office systems to initiate connections to remote workers (monitoring, management tools, etc.).
|
||||
|
||||
<Note>
|
||||
Site-to-VPN requires Network Routes because the Networks feature doesn't support clientless devices initiating connections.
|
||||
</Note>
|
||||
|
||||
### Step 1: Set Up the Routing Peer
|
||||
|
||||
Follow Scenario 1, Step 1 to deploy a routing peer at the office.
|
||||
|
||||
### Step 2: Create a Network Route for the Office Network
|
||||
|
||||
1. Go to **Network Routes**
|
||||
2. Click **Add Route**
|
||||
3. Enter the office subnet (e.g., `10.0.0.0/24`)
|
||||
4. Select your routing peer
|
||||
5. Enable **Masquerade**
|
||||
6. Click **Save**
|
||||
|
||||
### Step 3: Configure the Office System
|
||||
|
||||
On the office system that needs to reach remote workers, add a route to the NetBird network:
|
||||
|
||||
```bash
|
||||
# Route to NetBird network through the routing peer
|
||||
sudo ip route add 100.64.0.0/10 via 10.0.0.50
|
||||
```
|
||||
|
||||
Where `10.0.0.50` is the routing peer's office IP.
|
||||
|
||||
### Step 4: Create Bidirectional Access Policies
|
||||
|
||||
Create policies allowing traffic in both directions:
|
||||
|
||||
1. Office to remote workers (for initiated connections)
|
||||
2. Remote workers to office (for responses)
|
||||
|
||||
---
|
||||
|
||||
## Scenario 3: Branch Office Connectivity (Site-to-Site)
|
||||
|
||||
Connect multiple office locations so all devices can communicate.
|
||||
|
||||
### Example Setup
|
||||
|
||||
- **Headquarters**: `10.0.0.0/24` with routing peer "hq-router"
|
||||
- **Branch Office**: `10.1.0.0/24` with routing peer "branch-router"
|
||||
|
||||
### Step 1: Deploy Routing Peers
|
||||
|
||||
Install NetBird on a server at each location. Create dedicated groups for each:
|
||||
- "hq-routing-peers" for headquarters
|
||||
- "branch-routing-peers" for branch office
|
||||
|
||||
### Step 2: Create Network Routes
|
||||
|
||||
**For headquarters:**
|
||||
1. Go to **Network Routes**
|
||||
2. Add route: `10.0.0.0/24`
|
||||
3. Routing peer: "hq-router"
|
||||
4. Enable Masquerade
|
||||
5. Optionally add ACL Groups for access control
|
||||
|
||||
**For branch office:**
|
||||
1. Add route: `10.1.0.0/24`
|
||||
2. Routing peer: "branch-router"
|
||||
3. Enable Masquerade
|
||||
4. Optionally add ACL Groups
|
||||
|
||||
### Step 3: Create Access Policies
|
||||
|
||||
Create policies allowing the routing peers to communicate:
|
||||
|
||||
```
|
||||
Source: hq-routing-peers → Destination: branch-routing-peers (All protocols)
|
||||
Source: branch-routing-peers → Destination: hq-routing-peers (All protocols)
|
||||
```
|
||||
|
||||
For route-level access control, also create policies for the ACL Groups if configured.
|
||||
|
||||
### Step 4: Configure Network Equipment
|
||||
|
||||
**Option A: Router-level routes (recommended)**
|
||||
|
||||
Configure your routers to advertise routes to the remote network via DHCP or add static routes:
|
||||
|
||||
```
|
||||
# On HQ router, route to branch through routing peer
|
||||
10.1.0.0/24 via 10.0.0.50 (hq-router's IP)
|
||||
|
||||
# On Branch router, route to HQ through routing peer
|
||||
10.0.0.0/24 via 10.1.0.50 (branch-router's IP)
|
||||
```
|
||||
|
||||
**Option B: Per-device routes**
|
||||
|
||||
Add routes on individual devices that need cross-site access:
|
||||
|
||||
```bash
|
||||
# On HQ device
|
||||
sudo ip route add 10.1.0.0/24 via 10.0.0.50
|
||||
|
||||
# On Branch device
|
||||
sudo ip route add 10.0.0.0/24 via 10.1.0.50
|
||||
```
|
||||
|
||||
### Step 5: Test Connectivity
|
||||
|
||||
From a device at headquarters:
|
||||
|
||||
```bash
|
||||
ping 10.1.0.1 # Branch router
|
||||
ping 10.1.0.100 # Branch server
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices for Business Deployments
|
||||
|
||||
### Access Control
|
||||
|
||||
- Create specific groups for different access levels (IT Admin, Sales, Engineering)
|
||||
- Use protocol restrictions (e.g., only allow RDP to certain servers)
|
||||
- Implement time-limited setup keys for contractor access
|
||||
|
||||
### High Availability
|
||||
|
||||
For critical connections, consider:
|
||||
- Multiple routing peers at each location
|
||||
- Monitoring routing peer health
|
||||
- Automatic failover configuration
|
||||
|
||||
### Security
|
||||
|
||||
- Enable [Posture Checks](/manage/access-control/posture-checks) to verify device compliance
|
||||
- Use [Activity Logging](/manage/activity) to audit access
|
||||
- Implement MFA through your identity provider
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Remote workers can't access office resources:**
|
||||
1. Verify the routing peer is online and connected
|
||||
2. Check access policies include the user's group
|
||||
3. Ensure the routing peer can reach office resources locally
|
||||
|
||||
**Branch office connectivity issues:**
|
||||
1. Confirm both routing peers show as connected in the dashboard
|
||||
2. Verify static routes are configured correctly
|
||||
3. Check firewall rules aren't blocking traffic
|
||||
|
||||
**Slow performance:**
|
||||
1. Check routing peer placement—it should have good network connectivity
|
||||
2. Consider enabling [lazy connections](/manage/peers/lazy-connection) for large deployments
|
||||
3. Review network route priorities if multiple routes exist
|
||||
|
||||
For advanced configuration including masquerade options and detailed access control, see [Advanced Configuration](/manage/site-to-site/advanced-configuration).
|
||||
130
src/pages/manage/site-to-site/index.mdx
Normal file
130
src/pages/manage/site-to-site/index.mdx
Normal file
@@ -0,0 +1,130 @@
|
||||
import { Note } from '@/components/mdx'
|
||||
import { Tiles } from '@/components/Tiles'
|
||||
|
||||
# Site-to-Site Connectivity
|
||||
|
||||
Site-to-site connectivity allows you to connect entire networks together, enabling devices to communicate across locations without installing the NetBird client on every device.
|
||||
|
||||
## Understanding Remote Access Scenarios
|
||||
|
||||
NetBird supports three distinct remote access scenarios. Understanding which one you need is the first step to a successful setup.
|
||||
|
||||
### VPN-to-Site
|
||||
|
||||
A NetBird peer (device running the NetBird client) accesses devices on a remote network that don't have NetBird installed.
|
||||
|
||||
```
|
||||
Your Laptop ──────► NetBird Tunnel ──────► Routing Peer ──────► Office Printer
|
||||
(peer) (peer) (clientless)
|
||||
```
|
||||
|
||||
**Common use cases:**
|
||||
- Access your home NAS from anywhere
|
||||
- Reach office servers while traveling
|
||||
- Connect to IoT devices on a remote network
|
||||
|
||||
**Implementation:** Use [Networks](/manage/networks) (recommended) or [Network Routes](/manage/network-routes/routing-traffic-to-private-networks)
|
||||
|
||||
### Site-to-VPN
|
||||
|
||||
A device without NetBird initiates connections to NetBird peers. This is the reverse of VPN-to-Site—the clientless device starts the connection.
|
||||
|
||||
```
|
||||
Office Server ──────► Routing Peer ──────► NetBird Tunnel ──────► Your Laptop
|
||||
(clientless) (peer) (peer)
|
||||
```
|
||||
|
||||
**Common use cases:**
|
||||
- Office monitoring systems pushing data to remote analysts
|
||||
- On-premise servers initiating backups to cloud peers
|
||||
- Legacy systems that must initiate outbound connections
|
||||
|
||||
**Implementation:** Requires [Network Routes](/manage/network-routes/routing-traffic-to-private-networks) (Networks does not currently support this)
|
||||
|
||||
### Site-to-Site
|
||||
|
||||
Devices on separate networks communicate with each other, with neither running NetBird directly. Each network has a routing peer that handles traffic.
|
||||
|
||||
```
|
||||
Home NAS ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Office Server
|
||||
(clientless) (peer) (peer) (clientless)
|
||||
```
|
||||
|
||||
**Common use cases:**
|
||||
- Connect branch office networks to headquarters
|
||||
- Link home networks of family members
|
||||
- Bridge on-premise data centers with cloud VPCs
|
||||
|
||||
**Implementation:** Requires [Network Routes](/manage/network-routes/routing-traffic-to-private-networks) (Networks does not currently support this)
|
||||
|
||||
<Note>
|
||||
The Networks feature currently supports VPN-to-Site only. For Site-to-VPN and Site-to-Site scenarios, use Network Routes. Networks support for these scenarios may be added in future releases.
|
||||
</Note>
|
||||
|
||||
## Which Scenario Do I Need?
|
||||
|
||||
| I want to... | Scenario | Feature to Use |
|
||||
|-------------|----------|----------------|
|
||||
| Access home devices from my laptop | VPN-to-Site | Networks or Network Routes |
|
||||
| Access office resources while traveling | VPN-to-Site | Networks or Network Routes |
|
||||
| Let an office server connect to my laptop | Site-to-VPN | Network Routes only |
|
||||
| Connect two home networks together | Site-to-Site | Network Routes only |
|
||||
| Link branch offices | Site-to-Site | Network Routes only |
|
||||
| Bridge cloud VPC with on-premise network | Site-to-Site | Network Routes only |
|
||||
|
||||
## How It Works
|
||||
|
||||
All scenarios use a routing peer—a device running NetBird that forwards traffic for its local network:
|
||||
|
||||
1. **Deploy a routing peer** at each site (any device running NetBird with access to the local network)
|
||||
2. **Configure routing** to advertise each site's subnet through NetBird
|
||||
3. **Set access policies** to control which peers can reach which networks
|
||||
4. **Configure clientless devices** to route traffic through the routing peer (for Site-to-VPN and Site-to-Site)
|
||||
|
||||
<Tiles
|
||||
title="Choose Your Guide"
|
||||
items={[
|
||||
{
|
||||
href: '/manage/site-to-site/connect-home-networks',
|
||||
name: 'Connect Home Networks',
|
||||
description: 'For homelabbers: access your NAS, home automation, media servers, and connect family homes',
|
||||
},
|
||||
{
|
||||
href: '/manage/site-to-site/connect-office-networks',
|
||||
name: 'Connect Office Networks',
|
||||
description: 'For IT admins: enable remote worker access, connect branch offices, and link multiple sites',
|
||||
},
|
||||
{
|
||||
href: '/manage/site-to-site/connect-cloud-environments',
|
||||
name: 'Connect Cloud Environments',
|
||||
description: 'For DevOps: bridge cloud and on-premise, enable hybrid deployments, migrate workloads',
|
||||
},
|
||||
{
|
||||
href: '/manage/site-to-site/advanced-configuration',
|
||||
name: 'Advanced Configuration',
|
||||
description: 'Deep dive into masquerade options, access control, and troubleshooting',
|
||||
},
|
||||
]}
|
||||
/>
|
||||
|
||||
## Key Concepts
|
||||
|
||||
| Term | Description |
|
||||
|------|-------------|
|
||||
| Routing peer | A device running NetBird that forwards traffic for its local network |
|
||||
| Clientless device | A device that doesn't run NetBird (printers, IoT, legacy systems) |
|
||||
| Network Routes | Legacy feature for routing traffic to private networks (supports all scenarios) |
|
||||
| Networks | Newer feature for defining network resources (VPN-to-Site only) |
|
||||
| Masquerade | NAT that hides source IPs behind the routing peer's IP (simplifies setup) |
|
||||
|
||||
## Quick Reference: Networks vs Network Routes
|
||||
|
||||
| Capability | Networks | Network Routes |
|
||||
|-----------|----------|----------------|
|
||||
| VPN-to-Site | Yes | Yes |
|
||||
| Site-to-VPN | No | Yes |
|
||||
| Site-to-Site | No | Yes |
|
||||
| Setup complexity | Simpler | More configuration required |
|
||||
| Access control | Per-resource policies | Per-route with ACL Groups |
|
||||
|
||||
For detailed technical configuration including masquerade options, access control setup, and troubleshooting, see [Advanced Configuration](/manage/site-to-site/advanced-configuration).
|
||||
@@ -1,529 +0,0 @@
|
||||
import {Note} from "@/components/mdx";
|
||||
|
||||
# Setting up Site-to-Site/VPN access over NetBird
|
||||
|
||||
This page explains the characteristics of **Site-to-Site**, **Site-to-VPN**, and **VPN-to-Site** setups and how to configure them with NetBird. We'll start by defining key terminology and reviewing the available setup options before walking through concrete implementation examples.
|
||||
|
||||
## Overview
|
||||
|
||||
A **Site** in the context of this guide refers to any single network or subnet that is typically not exposed to the Internet nor directly accessible from other Sites.
|
||||
|
||||
Examples include:
|
||||
- Home or office networks
|
||||
- Internal networks at cloud providers or datacenters
|
||||
- Restricted VLANs
|
||||
- Internal container or VM networking ranges
|
||||
- Other VPN networking ranges
|
||||
- Another NetBird organization's resource ranges
|
||||
|
||||
A **device** in this guide refers to any physical computing device (PC, laptop, phone, datacenter server, etc.) or virtual computing device (VM, container, load balancer, etc.). A **device** can be either **clientless** or a **Peer**.
|
||||
|
||||
**Clientless devices** are **devices** that don't run a NetBird client themselves (they are not **Peers**).
|
||||
|
||||
A **Peer** is a **device** running the NetBird client directly on it:
|
||||
|
||||
- A laptop running the NetBird client directly on the system is a **Peer**
|
||||
- A laptop running the NetBird client in a container using default (internal) networking mode is not a **Peer** - the container itself is the **Peer** in this case
|
||||
- A laptop running the NetBird client in a container using host-networking mode could be considered a **Peer**
|
||||
|
||||
Other **bold** terms refer to NetBird-specific features or configuration options:
|
||||
**Network Route**, **Network**, **Resource**, **Access Control Policy**, **ACL Group**.
|
||||
|
||||
Non-bold terms refer to context-specific concepts:
|
||||
- route: a generic term for an operating system network route
|
||||
- resource: a generic term for software or a machine listening on a specific IP address and port
|
||||
|
||||
|
||||
### Site-to-Site
|
||||
|
||||
A **Site-to-Site** setup enables **clientless** devices from two or more **Sites** to reach each other. Each **Site** requires at least one **Peer** to route traffic over the VPN, but other on-site devices don't need to run (or even be aware of) the VPN software.
|
||||
|
||||
The **clientless** devices must be configured to route the remote **Site**'s IP address range through the local **Peer**. You can configure this manually using commands and persist it with your operating system's native tools, or automate it using DHCP route advertisements or device management software.
|
||||
|
||||
The remote **Peer** must also know how to route responses back to the local **Site**. Typically, you'll need to set up a pair of routes to enable site-to-site access:
|
||||
|
||||
1. A route from the local **Peer** to the remote **Site** for outbound traffic
|
||||
2. A reverse route from the remote **Site** to the local **Peer** for return traffic
|
||||
|
||||
### Site-to-VPN
|
||||
|
||||
A **Site-to-VPN** setup enables a **clientless** device to reach **Peers** in the VPN network.
|
||||
|
||||
You can think of this as the 'local half' of a **Site-to-Site** setup. The **clientless** devices need to be configured to reach the VPN network, but typically no additional setup is required to route responses back from the VPN.
|
||||
|
||||
### VPN-to-Site
|
||||
|
||||
A **VPN-to-Site** setup enables a **Peer** to reach **clientless** devices on a network external to the VPN itself. This is the default mode of operation for most VPNs, but we're including it here for completeness. In NetBird, this scenario is achieved using **Networks** or the older **Network Routes** feature.
|
||||
|
||||
## NetBird implementations overview
|
||||
|
||||
While NetBird doesn't yet have explicit support for Site-to-VPN or Site-to-Site scenarios, you can achieve them using one of the following approaches, depending on your requirements:
|
||||
|
||||
1. Using a **Network Route** for each **Site** with Masquerade (with or without **ACL Groups**)
|
||||
2. Using a **Network Route** for each **Site** without Masquerade (without **ACL Groups**)
|
||||
3. Using a **Network** **Resource** with Masquerade
|
||||
|
||||
All of these options require the following:
|
||||
|
||||
- You must manually configure **clientless** devices to route traffic appropriately
|
||||
- The easiest method is using device management software or DHCP route advertisements from your local router
|
||||
- You can only have one routing **Peer** per **Site**
|
||||
- Routing traffic correctly and reliably through multiple routing devices is extremely complex (if not impossible), so multi-peer routing is out of scope for this guide
|
||||
|
||||
You'll need to consider one of two primary tradeoffs:
|
||||
|
||||
1. **Forfeit source IP information to preserve basic access control** - Use Masquerade to maintain a basic form of access control
|
||||
- Masqueraded traffic can only be controlled by **Access Control Policies** attached to the **Routing Peer**, with no way to restrict access for specific **clientless** devices
|
||||
- You can still create coarse-grained access controls by setting up multiple **Network** **Routing Peers** for different purposes
|
||||
2. **Forfeit access control to preserve source IP information** - Skip Masquerade to keep the original source IP addresses (this allows any traffic through)
|
||||
- This approach may be required for specific networking setups
|
||||
|
||||
## Prerequisites and initial assumptions
|
||||
|
||||
For this guide, we'll use four `libvirt` Ubuntu virtual machines, split into two separate **Sites** (networks) as follows:
|
||||
```shell
|
||||
root@vms ~# virsh net-dhcp-leases local-site
|
||||
... IP address Hostname ...
|
||||
... ---------------------------------...
|
||||
... 192.168.122.144/24 local-nb-01 ...
|
||||
... 192.168.122.65/24 local-01 ...
|
||||
|
||||
root@vms ~# virsh net-dhcp-leases remote-site
|
||||
... IP address Hostname ...
|
||||
...------------------------------------...
|
||||
... 192.168.100.189/24 remote-nb-01 ...
|
||||
... 192.168.100.215/24 remote-01 ...
|
||||
```
|
||||
|
||||
All VMs can be reached from the host `vms`:
|
||||
```shell
|
||||
kdn@pc ~> ssh vms.lan ping -c1 192.168.100.189
|
||||
PING 192.168.100.189 (192.168.100.189) 56(84) bytes of data.
|
||||
64 bytes from 192.168.100.189: icmp_seq=1 ttl=64 time=0.154 ms
|
||||
|
||||
--- 192.168.100.189 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.154/0.154/0.154/0.000 ms
|
||||
kdn@pc ~> ssh vms.lan ping -c1 192.168.122.144
|
||||
PING 192.168.122.144 (192.168.122.144) 56(84) bytes of data.
|
||||
64 bytes from 192.168.122.144: icmp_seq=1 ttl=64 time=0.162 ms
|
||||
|
||||
--- 192.168.122.144 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.162/0.162/0.162/0.000 ms
|
||||
```
|
||||
|
||||
Both **Sites** can reach the Internet, and devices within each site can communicate with each other, but they cannot directly reach devices on the other **Site**:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh 192.168.100.189 -J vms.lan ping -c1 192.168.122.144
|
||||
PING 192.168.122.144 (192.168.122.144) 56(84) bytes of data.
|
||||
From 192.168.122.1 icmp_seq=1 Destination Port Unreachable
|
||||
|
||||
--- 192.168.122.144 ping statistics ---
|
||||
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
|
||||
|
||||
kdn@pc ~ [1]>
|
||||
```
|
||||
|
||||
The `local-site` network VMs are also directly attached to my LAN. The `remote-site` VMs are only attached to their network, so we'll reference them by IP address and use `vms` as an SSH jump host.
|
||||
|
||||
The devices `local-01` and `remote-01` are **clientless** for the purposes of this guide. Additionally, `remote-01` runs CoreDNS, which responds with `OK` to `http://192.168.100.10/health`.
|
||||
|
||||
The **Peers** are configured as follows:
|
||||
|
||||
| dns_label | netbird_ip | groups |
|
||||
|----------------|------------------|---------------------|
|
||||
| `local-nb-01` | `100.83.73.97` | `s2s: local peers` |
|
||||
| `remote-nb-01` | `100.83.136.209` | `s2s: remote peers` |
|
||||
|
||||
We'll grant access between:
|
||||
- `local-01` running on the `local-site` through **Routing Peer** `local-nb-01` using **Group** `s2s: local peers`
|
||||
- `remote-01` running on the `remote-site` through **Routing Peer** `remote-nb-01` using **Group** `s2s: remote peers`
|
||||
|
||||
<Note>
|
||||
This guide assumes the use of a Linux terminal, but the commands used are relatively simple and ubiquitous
|
||||
and should easily translate to other operating systems.
|
||||
</Note>
|
||||
|
||||
## Site-to-Site with Masquerade
|
||||
|
||||
The **Masquerade** option means that packets forwarded by a **Routing Peer** will:
|
||||
- Have their source IP address replaced with the **Routing Peer**'s NetBird IP address when leaving the **Site**
|
||||
- Be translated back from the **Routing Peer**'s IP address to the local **Site**'s IP address when returning
|
||||
|
||||
This is currently the easiest way to configure routing because it uses existing **Peer** forwarding and policy enforcement facilities.
|
||||
|
||||
The main downsides of this approach are:
|
||||
|
||||
- Loss of source IP addressing information, which may be required for auditing purposes
|
||||
- Very coarse-grained access control limited to the **Routing Peer**'s permissions
|
||||
|
||||
### Site-to-Site using Network Routes with Masquerade and without Access Control
|
||||
|
||||
In this section, we'll set up Site-to-Site **Network Routes** with Masquerade but without access control. We'll start by configuring the required **Network Routes** and **Access Control Policies**, then manually configure a **clientless** device to route traffic through the local **Routing Peer**. Finally, we'll verify that everything works as expected.
|
||||
|
||||
#### Setting up a simple VPN-to-Site access
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/routes-noacl-vpn-to-site.png" alt="routes-noacl-vpn-to-site"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
and an **Access Control Policy** that establishes connectivity between the (future) **Routing Peers**:
|
||||
|
||||
<p id="unidirectional-routing-peer-policy">
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/acl-ping-to-local-only.png" alt="acl-ping-to-local-only"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
It doesn't matter that this is a unidirectional ICMP rule in the wrong direction - **Network Routes** are activated as soon as any **Access Control Policy** establishes connectivity to the **Routing Peer**, as explained in [Network Routes caveats](/manage/network-routes/routing-traffic-to-private-networks#network-routes-caveats).
|
||||
</Note>
|
||||
|
||||
We can verify that the local **Peer** can reach the `remote-site` using both `ping` and `curl`:
|
||||
```shell
|
||||
kdn@pc ~> ssh local-nb-01.lan "netbird networks ls"
|
||||
Available Networks:
|
||||
|
||||
- ID: network-route-srvs-site
|
||||
Network: 192.168.122.0/24
|
||||
Status: Selected
|
||||
|
||||
kdn@pc ~> ssh local-nb-01.lan "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.475 ms
|
||||
|
||||
--- 192.168.100.10 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.475/0.475/0.475/0.000 ms
|
||||
|
||||
kdn@pc ~> ssh local-nb-01.lan "curl 192.168.100.10/health; echo"
|
||||
OK
|
||||
```
|
||||
|
||||
#### Setting up the clientless device
|
||||
|
||||
Now we'll manually configure the **clientless** `local-01` device to route traffic to the `remote-site` through `local-nb-01`'s local IP address `192.168.122.144`:
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "ip route | grep 192.168.100"
|
||||
kdn@pc ~ [1]> ssh local-01.lan "sudo ip route add 192.168.100.0/24 via 192.168.122.144"
|
||||
kdn@pc ~> ssh local-01.lan "ip route | grep 192.168.100"
|
||||
192.168.100.0/24 via 192.168.122.144 dev enp7s0
|
||||
```
|
||||
|
||||
<Note>
|
||||
This step is better handled via a DHCP server's route advertisement, but that's outside the scope of this guide.
|
||||
</Note>
|
||||
|
||||
This won't work yet from a **clientless** device because we're missing the other half of the connection needed to route responses back:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "ping -c1 192.168.100.10"
|
||||
PING 192.168.100.10 (192.168.100.10) 56(84) bytes of data.
|
||||
|
||||
--- 192.168.100.10 ping statistics ---
|
||||
1 packets transmitted, 0 received, 100% packet loss, time 0ms
|
||||
|
||||
kdn@pc ~ [1]>
|
||||
```
|
||||
|
||||
#### Closing the loop with a reverse Network Route
|
||||
|
||||
Now we can complete the setup by enabling the reverse **Network Route** (from `remote-site` to `local-site`):
|
||||
|
||||
<p id="routes-noacl-site-to-site">
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/routes-noacl-site-to-site.png" alt="routes-noacl-site-to-site"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Let's verify it's working for both ICMP and HTTP:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "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=62 time=0.867 ms
|
||||
|
||||
--- 192.168.100.10 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.867/0.867/0.867/0.000 ms
|
||||
kdn@pc ~> ssh local-01.lan "curl 192.168.100.10/health; echo"
|
||||
OK
|
||||
```
|
||||
|
||||
#### Confirming remote Site access to the local Site
|
||||
|
||||
Let's fetch the `local-01` IP address, perform the reverse setup on `remote-01`, and test access back from the `remote-site`:
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "ip a | grep 192.168.122"
|
||||
inet 192.168.122.65/24 metric 100 brd 192.168.122.255 scope global dynamic enp7s0
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ip route | grep 192.168.122"
|
||||
kdn@pc ~ [1]> ssh 192.168.100.215 -J vms.lan "sudo ip route add 192.168.122.0/24 via 192.168.100.189"
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ip route | grep 192.168.122"
|
||||
192.168.122.0/24 via 192.168.100.189 dev enp7s0
|
||||
kdn@pc ~> ssh 192.168.100.189 -J vms.lan "ping -c1 192.168.122.65"
|
||||
PING 192.168.122.65 (192.168.122.65) 56(84) bytes of data.
|
||||
64 bytes from 192.168.122.65: icmp_seq=1 ttl=63 time=0.523 ms
|
||||
|
||||
--- 192.168.122.65 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.523/0.523/0.523/0.000 ms
|
||||
kdn@pc ~>
|
||||
```
|
||||
|
||||
### Site-to-Site using Network Routes with Masquerade and Access Control
|
||||
|
||||
We'll start by picking up where we left off in the previous example: [Site-to-Site using Network Routes with Masquerade and without Access Control](#site-to-site-using-network-routes-with-masquerade-and-without-access-control). Now we can restrict access to the remote **Site**'s resources to ICMP only and verify the restrictions are enforced. We'll set up and verify unidirectional access first, then enable bidirectional access.
|
||||
|
||||
First, let's add dedicated `* resources` Access Control Groups to the **Network Routes**:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/routes-with-acl-site-to-site.png" alt="routes-with-acl-site-to-site"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Note that we're using a different Group to grant access to the **Network Route** than the one used for **Routing Peers**. Using the **Routing Peer**'s Group in **ACL Groups** would also work and be slightly simpler to manage.
|
||||
|
||||
<Note>
|
||||
Granting access only to the **Network Route**'s **ACL Groups** still requires at least one **Access Control Policy** that grants any kind of access directly to the **Routing Peer**. This makes the **Network Route** visible to the **Peer** using the route.
|
||||
|
||||
This is in stark contrast to Network Resources, where:
|
||||
- **Resource** **Groups** control both access and discovery in a single step
|
||||
- **Routing Peer** permissions aren't required unless you want to access its LAN IPs
|
||||
</Note>
|
||||
|
||||
Next, let's set up **Access Control Policies** for one-way access from `local-site` to `remote-site`:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/acl-unidirectional-site-to-site.png" alt="acl-unidirectional-site-to-site"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Now we can verify that `ping` (ICMP) is allowed while `curl` (HTTP) is blocked in the local-to-remote direction:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "ip route | grep 192.168.100"
|
||||
192.168.100.0/24 via 192.168.122.144 dev enp7s0
|
||||
kdn@pc ~> ssh local-01.lan "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=62 time=0.738 ms
|
||||
|
||||
--- 192.168.100.10 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.738/0.738/0.738/0.000 ms
|
||||
kdn@pc ~> ssh local-01.lan "curl -sv -m 2 192.168.100.10/health; echo"
|
||||
* Trying 192.168.100.10:80...
|
||||
|
||||
* Connection timed out after 2002 milliseconds
|
||||
* closing connection #0
|
||||
```
|
||||
|
||||
Let's also verify that reverse access (from `remote-site` to `local-site`) isn't possible yet:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ip route | grep 192.168.122"
|
||||
192.168.122.0/24 via 192.168.100.189 dev enp7s0
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ping -c1 192.168.122.65"
|
||||
PING 192.168.122.65 (192.168.122.65) 56(84) bytes of data.
|
||||
|
||||
--- 192.168.122.65 ping statistics ---
|
||||
1 packets transmitted, 0 received, 100% packet loss, time 0ms
|
||||
|
||||
kdn@pc ~ [1]>
|
||||
```
|
||||
|
||||
Finally, let's enable the `s2s: ping to local resources` **Access Control Policy**:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/acl-bidirectional-site-to-site-minus-routing-peer.png" alt="acl-bidirectional-site-to-site-minus-routing-peer"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
We don't need to enable the reverse ICMP policy to the **Routing Peer**, as explained [previously](#unidirectional-routing-peer-policy).
|
||||
</Note>
|
||||
|
||||
Now let's verify that remote-to-local access is working:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ip route | grep 192.168.122"
|
||||
192.168.122.0/24 via 192.168.100.189 dev enp7s0
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ping -c1 192.168.122.65"
|
||||
PING 192.168.122.65 (192.168.122.65) 56(84) bytes of data.
|
||||
64 bytes from 192.168.122.65: icmp_seq=1 ttl=62 time=0.755 ms
|
||||
|
||||
--- 192.168.122.65 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.755/0.755/0.755/0.000 ms
|
||||
kdn@pc ~>
|
||||
```
|
||||
|
||||
### Site-to-Site using Network Resources with Masquerade
|
||||
|
||||
In this section, we'll replicate the previous [Site-to-Site using Network Routes with Masquerade and Access Control](#site-to-site-using-network-routes-with-masquerade-and-access-control) configuration using **Network Resources** and verify that it works. We'll start by setting up a **Network** for each **Site**, enable the minimum set of **Access Control Policies** required (which already exist), and finally verify that access control is working as expected.
|
||||
|
||||
Let's start by creating two new **Networks**, one for each **Site**:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/network-local-noacl.png" alt="network-local-noacl"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/network-remote-noacl.png" alt="network-remote-noacl"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
and enable the two required **Access Control Policies**:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/acl-networks-bidirectional.png" alt="acl-networks-bidirectional"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
Unlike **Network Routes**, you don't need policies granting access to the **Routing Peers**.
|
||||
|
||||
However, a reverse **Access Control Policy** is mandatory for **Resources** - the reverse route won't be advertised on the local client and response packets will be lost, otherwise.
|
||||
</Note>
|
||||
|
||||
Let's verify it's working:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "ip route | grep 192.168.100"
|
||||
192.168.100.0/24 via 192.168.122.144 dev enp7s0
|
||||
kdn@pc ~> ssh local-01.lan "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=62 time=0.783 ms
|
||||
|
||||
--- 192.168.100.10 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.783/0.783/0.783/0.000 ms
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ip route | grep 192.168.122"
|
||||
192.168.122.0/24 via 192.168.100.189 dev enp7s0
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ping -c1 192.168.122.65"
|
||||
PING 192.168.122.65 (192.168.122.65) 56(84) bytes of data.
|
||||
64 bytes from 192.168.122.65: icmp_seq=1 ttl=62 time=0.925 ms
|
||||
|
||||
--- 192.168.122.65 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.925/0.925/0.925/0.000 ms
|
||||
```
|
||||
|
||||
Let's also verify that no additional traffic is allowed:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "curl -m 2 192.168.100.10/health; echo"
|
||||
curl: (28) Connection timed out after 2002 milliseconds
|
||||
```
|
||||
|
||||
### Asymmetric Network Resource policies
|
||||
|
||||
The reverse **Access Control Policy** doesn't need to match the protocol and access level of the forward policy. Established connections will be routed back correctly as long as the reverse (operating system) route is registered on the remote end.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/acl-networks-bidirectional-assymetric.png" alt="acl-networks-bidirectional"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Now we can verify that `local-site` can reach `remote-site` only over ICMP:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "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=62 time=0.836 ms
|
||||
|
||||
--- 192.168.100.10 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.836/0.836/0.836/0.000 ms
|
||||
kdn@pc ~ [1]> ssh local-01.lan "nc -v -w 2 192.168.100.10 22"
|
||||
nc: connect to 192.168.100.10 port 22 (tcp) failed: Connection timed out
|
||||
kdn@pc ~ [1]>
|
||||
```
|
||||
|
||||
while `remote-site` can only reach `local-site` over SSH:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ip route | grep 192.168.122"
|
||||
192.168.122.0/24 via 192.168.100.189 dev enp7s0
|
||||
kdn@pc ~> ssh 192.168.100.215 -J vms.lan "ping -c1 192.168.122.65"
|
||||
PING 192.168.122.65 (192.168.122.65) 56(84) bytes of data.
|
||||
|
||||
--- 192.168.122.65 ping statistics ---
|
||||
1 packets transmitted, 0 received, 100% packet loss, time 0ms
|
||||
|
||||
kdn@pc ~ [1]> ssh 192.168.100.215 -J vms.lan "nc -w 2 192.168.122.65 22"
|
||||
SSH-2.0-OpenSSH_9.7p1 Ubuntu-7ubuntu4.3
|
||||
kdn@pc ~>
|
||||
```
|
||||
|
||||
## Site-to-Site without Masquerade
|
||||
|
||||
This approach preserves source IP addressing information, but the traffic will be immediately rejected by the remote **Routing Peer** if you try to enable any **Access Control Policies** (such as **Network Resources** or **ACL Groups** on **Network Routes**).
|
||||
|
||||
This happens because all access control in NetBird is currently based on **Peer** IP addresses. Packets arriving from different address spaces (without Masquerade) are unknown to the NetBird policy engine and are therefore immediately rejected by the receiving **Peer**/**Routing Peer**.
|
||||
|
||||
<Note>
|
||||
We plan to address these limitations in the future by implementing dedicated facilities for setting up and applying granular policies to Site-to-Site and Site-to-VPN scenarios.
|
||||
|
||||
In the meantime, you can manually restrict forwarded traffic using your operating system's firewall - for example, by implementing `FORWARD` policies on Linux.
|
||||
</Note>
|
||||
|
||||
### Site-to-Site using Network Routes without Masquerade
|
||||
|
||||
Simply disable Masquerade on each **Network Route** from [the first example](#site-to-site-using-network-routes-with-masquerade-and-without-access-control).
|
||||
|
||||
To summarize, you'll need:
|
||||
- A pair of local and remote **Network Routes**
|
||||
- An **Access Control Policy** to establish connectivity between **Routing Peers**
|
||||
- Manual route configuration on **clientless** devices pointing to the respective **Routing Peers**
|
||||
|
||||
The **Network Routes** list will look just like [above](#routes-noacl-site-to-site):
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/routes-noacl-site-to-site.png" alt="routes-noacl-site-to-site"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
but you'll need to turn off **Masquerade** in each **Network Route**'s update dialog:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/route-without-masquerading.png" alt="route-without-masquerading"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
Only one **Access Control Policy** is required, just like [above](#unidirectional-routing-peer-policy):
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/use-cases/setup-site-to-site-access/acl-ping-to-local-only.png" alt="acl-ping-to-local-only"
|
||||
className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
With these two pieces of configuration in place, we can verify that `ping` works:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh local-01.lan "ip route | grep 192.168.100"
|
||||
192.168.100.0/24 via 192.168.122.144 dev enp7s0
|
||||
kdn@pc ~> ssh local-01.lan "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=62 time=0.897 ms
|
||||
|
||||
--- 192.168.100.10 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.897/0.897/0.897/0.000 ms
|
||||
```
|
||||
|
||||
and that packets arrive unmodified on the remote end:
|
||||
|
||||
```shell
|
||||
kdn@pc ~> ssh 192.168.100.10 -J vms.lan "sudo tcpdump -nvv -i any --immediate-mode -l icmp"
|
||||
tcpdump: WARNING: any: That device doesn't support promiscuous mode
|
||||
(Promiscuous mode not supported on the "any" device)
|
||||
tcpdump: data link type LINUX_SLL2
|
||||
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
|
||||
17:32:17.845428 enp7s0 In IP (tos 0x0, ttl 62, id 56506, offset 0, flags [DF], proto ICMP (1), length 84)
|
||||
192.168.122.65 > 192.168.100.10: ICMP echo request, id 4480, seq 1, length 64
|
||||
17:32:17.845468 enp7s0 Out IP (tos 0x0, ttl 64, id 51781, offset 0, flags [none], proto ICMP (1), length 84)
|
||||
192.168.100.10 > 192.168.122.65: ICMP echo reply, id 4480, seq 1, length 64
|
||||
^C⏎
|
||||
```
|
||||
Reference in New Issue
Block a user