sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-08-28 02:31:28 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: prune redundant Networks and Network Routes use cases (#749)

Browse Source 
The Networks and Network Routes "By Scenario" / "By Resource Type" /
"By Configuration" subgroups had grown into reskinned walkthroughs of
flows already on the concept pages. Collapse to what's actually
distinct, flatten the survivors up one level, fold unique nuggets
into the concept pages.

Networks:
- Delete the "By Resource Type" trio (Multiple IP Resources, Domain
  Resources, Wildcard Domains) and Remote Worker Access — all rehashes
  of /manage/networks. Fold the wildcard-vs-base-domain gotcha and the
  shared-policy pattern into the concept page.
- Delete the Use Cases overview; fold the VPN-to-Site framing into the
  concept page.
- Flatten access-home-devices and cloud-to-on-premise up out of
  /by-scenario/.

Network Routes:
- Consolidate site-to-site-{home,office,cloud} into one
  /manage/network-routes/use-cases/site-to-site page covering the
  shared walkthrough plus AWS/GCP/Azure routing-peer requirements.
- Move exit-nodes, access-control, overlapping-routes, and
  advanced-configuration up out of /by-{scenario,configuration}/.
- Trim advanced-configuration (301 → 144 lines), dropping masquerade
  basics, ACL setup, site-to-site flow, and HA repetition duplicated
  elsewhere. Keep the masquerade trade-off matrix, Networks-vs-Routes
  comparison, troubleshooting, and debug commands.
- Delete the Use Cases overview.

Permanent redirects added for every removed URL. Inbound references
updated across introduction, ipv6, homelab, cloud, security,
site-to-site overview, android-tv/tvOS install pages, and the concept
pages.
This commit is contained in:
Jack Carter
2026-05-13 14:17:43 +02:00
committed by GitHub
parent 3459beb3c5
commit 442116bb8f
138 changed files with 461 additions and 2036 deletions
Download Patch File Download Diff File Expand all files Collapse all files

90
src/components/NavigationDocs.jsx
View File

@@ -195,42 +195,13 @@ export const docsNavigation = [
title: 'Use Cases',
isOpen: false,
links: [
{ title: 'Overview', href: '/manage/networks/use-cases' },
{
title: 'By Scenario',
isOpen: false,
links: [
{
title: 'Access Home Devices',
href: '/manage/networks/use-cases/by-scenario/access-home-devices',
},
{
title: 'Remote Worker Access',
href: '/manage/networks/use-cases/by-scenario/remote-worker-access',
},
{
title: 'Cloud to On-Premise',
href: '/manage/networks/use-cases/by-scenario/cloud-to-on-premise',
},
],
title: 'Access Home Devices',
href: '/manage/networks/use-cases/access-home-devices',
},
{
title: 'By Resource Type',
isOpen: false,
links: [
{
title: 'Multiple IP Resources',
href: '/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources',
},
{
title: 'Domain Resources',
href: '/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources',
},
{
title: 'Wildcard Domains',
href: '/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks',
},
],
title: 'Cloud to On-Premise',
href: '/manage/networks/use-cases/cloud-to-on-premise',
},
{
title: 'Site-to-VPN',
@@ -249,49 +220,28 @@ export const docsNavigation = [
title: 'Use Cases',
isOpen: false,
links: [
{ title: 'Overview', href: '/manage/network-routes/use-cases' },
{
title: 'By Scenario',
isOpen: false,
links: [
{
title: 'Site-to-Site: Home',
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-home',
},
{
title: 'Site-to-Site: Office',
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-office',
},
{
title: 'Site-to-Site: Cloud',
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-cloud',
},
{
title: 'Exit Nodes',
href: '/manage/network-routes/use-cases/by-scenario/exit-nodes',
},
],
title: 'Site-to-Site',
href: '/manage/network-routes/use-cases/site-to-site',
},
{
title: 'By Configuration',
isOpen: false,
links: [
{
title: 'Access Control',
href: '/manage/network-routes/use-cases/by-configuration/access-control',
},
{
title: 'Overlapping Routes',
href: '/manage/network-routes/use-cases/by-configuration/overlapping-routes',
},
{
title: 'Advanced Configuration',
href: '/manage/network-routes/use-cases/by-configuration/advanced-configuration',
},
],
title: 'Exit Nodes',
href: '/manage/network-routes/use-cases/exit-nodes',
},
],
},
{
title: 'Access Control',
href: '/manage/network-routes/access-control',
},
{
title: 'Overlapping Routes',
href: '/manage/network-routes/overlapping-routes',
},
{
title: 'Advanced Configuration',
href: '/manage/network-routes/advanced-configuration',
},
],
},
{

4
src/pages/get-started/install/android-tv.mdx
View File

@@ -81,6 +81,6 @@ the SSO flow, the QR code dialog in the NetBird app will automatically dismiss i
## What's next?
- Manage your device's [access](/manage/access-control/manage-network-access) to the network
- Use your device for [remote access access to your home network](/manage/networks/use-cases/by-scenario/access-home-devices)
- Use your device as an [exit node](/manage/network-routes/use-cases/by-scenario/exit-nodes#make-the-peer-an-exit-node-routing-peer)
- Use your device for [remote access access to your home network](/manage/networks/use-cases/access-home-devices)
- Use your device as an [exit node](/manage/network-routes/use-cases/exit-nodes#make-the-peer-an-exit-node-routing-peer)

4
src/pages/get-started/install/tvos.mdx
View File

@@ -54,5 +54,5 @@ the SSO flow, after a few seconds the authentication dialog in the NetBird app w
## What's next?
- Manage your device's [access](/manage/access-control/manage-network-access) to the network
- Use your device for [remote access access to your home network](/manage/networks/use-cases/by-scenario/access-home-devices)
- Use your device as an [exit node](/manage/network-routes/use-cases/by-scenario/exit-nodes#make-the-peer-an-exit-node-routing-peer)
- Use your device for [remote access access to your home network](/manage/networks/use-cases/access-home-devices)
- Use your device as an [exit node](/manage/network-routes/use-cases/exit-nodes#make-the-peer-an-exit-node-routing-peer)

2
src/pages/introduction.mdx
View File

@@ -61,7 +61,7 @@ It literally takes less than 5 minutes to deploy a secure point-to-point VPN wit
'Learn how to provide secure access to LANs, VPS instances, and corporate private networks.',
},
{
href: '/manage/network-routes/use-cases/by-scenario/exit-nodes',
href: '/manage/network-routes/use-cases/exit-nodes',
name: 'Configure Default Routes',
description: 'Set up default routes for internet traffic and configure exit nodes for your network.',
},

12
src/pages/manage/network-routes/use-cases/by-configuration/access-control.mdx → src/pages/manage/network-routes/access-control.mdx
View File

@@ -34,25 +34,25 @@ In this example, we create a route with the following settings (see [Key Concept
- **Access Control Groups:** `servers`
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-configuration/access-control/network-route-acl.png" alt="Network route configuration with access control" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/access-control/network-route-acl.png" alt="Network route configuration with access control" className="imagewrapper-big"/>
</p>
Click **Continue** to proceed.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-configuration/access-control/network-route-acl-group-settings.png" alt="Network route group settings" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/access-control/network-route-acl-group-settings.png" alt="Network route group settings" className="imagewrapper-big"/>
</p>
Complete the configuration and click **Add Route** to save.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-configuration/access-control/network-route-acl-saved.png" alt="Saved network route" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/access-control/network-route-acl-saved.png" alt="Saved network route" className="imagewrapper-big"/>
</p>
Because you assigned an access control group, you will be prompted to create a policy:
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-configuration/access-control/network-route-acl-prompt.png" alt="Policy creation prompt" className="imagewrapper"/>
<img src="/docs-static/img/manage/network-routes/access-control/network-route-acl-prompt.png" alt="Policy creation prompt" className="imagewrapper"/>
</p>
Click **Create Policy** to continue.
@@ -73,7 +73,7 @@ In this example, we create a policy with:
- **Destination Groups:** `servers`
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-configuration/access-control/network-acl-create-policy.png" alt="Create access control policy" className="imagewrapper"/>
<img src="/docs-static/img/manage/network-routes/access-control/network-acl-create-policy.png" alt="Create access control policy" className="imagewrapper"/>
</p>
You can create new groups by typing a name in the source or destination input fields.
@@ -81,7 +81,7 @@ You can create new groups by typing a name in the source or destination input fi
Click **Add Policy** to save. The policy appears in the table.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-configuration/access-control/network-acl-new-policy.png" alt="New policy in table" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/access-control/network-acl-new-policy.png" alt="New policy in table" className="imagewrapper-big"/>
</p>
With this configuration, peers connected to your routing peer can only access port 80 on the routed network.

144
src/pages/manage/network-routes/advanced-configuration.mdx Normal file
View File

@@ -0,0 +1,144 @@
import { Warning } from '@/components/mdx'
# Advanced Configuration
This page covers masquerade trade-offs, a Networks-vs-Network-Routes comparison, and troubleshooting.
For the basics — masquerade behavior, ACL Groups, HA — see [Network Routes Concepts](/manage/network-routes#key-concepts). For ACL Group setup, see [Access Control](/manage/network-routes/access-control). For Site-to-Site walkthroughs, see [Site-to-Site](/manage/network-routes/use-cases/site-to-site).
## Masquerade: when to enable or disable
[Masquerade](/manage/network-routes#masquerade) is the default. It NATs traffic through the routing peer so the remote network sees the routing peer's IP instead of the original source.
**With masquerade (default):**
- Works out of the box — no return route needed on the remote network
- Compatible with ACL Groups and Network Resources
- Source IP is hidden, so audit logs show the routing peer IP rather than the originating device
**Without masquerade:**
- Original source IPs are preserved for accurate auditing
- Required if your compliance regime needs source-IP visibility on the remote network
- Requires a return route on the remote network's infrastructure back to the NetBird CIDR
<Warning>
Without masquerade, traffic from unknown source IPs is rejected by NetBird's policy engine. You cannot use ACL Groups or Network Resources with masquerade disabled.
</Warning>
### Choosing the right approach
| Requirement | Approach |
|---|---|
| Simple remote access | [Networks](/manage/networks) with masquerade |
| Site-to-Site with access control | Network Routes with masquerade + ACL Groups |
| Audit trail needs source IPs | Network Routes without masquerade + OS firewall on the remote network |
| Compliance requirements | Depends on the specific framework |
## Networks vs Network Routes
| 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 | More manual configuration |
| Routing peer redundancy | Built-in | Manual configuration |
| Policy requirement | Resource policies only | Routing peer + ACL Group policies |
## Troubleshooting
### Route not active
**Symptoms:** Peers do not 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 that ACL Group policies exist
### Traffic times out
**Symptoms:** Ping or connections hang with no response.
**Causes:**
1. Routing peer cannot reach the destination network
2. Masquerade is disabled and no return route exists
3. Firewall is blocking traffic
**Solution:**
- Test from the routing peer: `ping <destination>` directly
- If masquerade is off, verify return routes are configured on the remote network
- Check the OS firewall on the routing peer: `iptables -L -n` or equivalent
### Connection works one way
**Symptoms:** Can reach the remote site but responses do not 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 — see [Overlapping Routes](/manage/network-routes/overlapping-routes)
- Use more specific routes where needed
- Verify subnet CIDR notation is correct
### Debug commands
**On the routing peer:**
```bash
# NetBird status
netbird status
# Active routes
netbird routes list
# System routes
ip route show
# Monitor traffic (Linux)
sudo tcpdump -i any -n host <destination>
# Confirm IP forwarding is enabled
cat /proc/sys/net/ipv4/ip_forward
```
**On a client peer:**
```bash
# Which networks/routes are selected
netbird networks ls
# Trace the path
traceroute <destination>
```
## Performance
- Place routing peers on machines with good network connectivity to the resources they serve and to the internet
- Avoid routing through bandwidth-constrained links
- For high-throughput scenarios, consider dedicated hardware
- Track CPU, memory, network throughput, and connection count on routing peers
- Use [activity logging](/manage/activity) to monitor access patterns and troubleshoot issues
For high availability (multiple routing peers per route), see [High Availability](/manage/network-routes#high-availability) on the concept page.

16
src/pages/manage/network-routes/index.mdx
View File

@@ -14,7 +14,7 @@ Network Routes require NetBird [v0.9.0](https://github.com/netbirdio/netbird/rel
</Note>
<Warning>
By default, Network Routes bypass Access Control rules. Traffic flows freely to routed networks unless you [configure access control explicitly](/manage/network-routes/use-cases/by-configuration/access-control). See [Network Routes caveats](#network-routes-caveats) for details.
By default, Network Routes bypass Access Control rules. Traffic flows freely to routed networks unless you [configure access control explicitly](/manage/network-routes/access-control). See [Network Routes caveats](#network-routes-caveats) for details.
</Warning>
## Network Routes vs Networks
@@ -204,7 +204,7 @@ This requires configuring your external network router with a return route to yo
## Network Routes Caveats
Unless [configured explicitly](/manage/network-routes/use-cases/by-configuration/access-control), Network Routes ignore Access Control rules. This can lead to unexpected access.
Unless [configured explicitly](/manage/network-routes/access-control), Network Routes ignore Access Control rules. This can lead to unexpected access.
This limitation led to the creation of [Networks](/manage/networks), which uses mandatory Groups for both access control and advertisement. Clients do not see a resource until they have access to its Group.
@@ -319,22 +319,22 @@ To prevent permission overflow, use dedicated Routing Peers for Network Routes a
title="Use Cases"
items={[
{
href: '/manage/network-routes/use-cases',
name: 'Use Cases Overview',
description: 'Site-to-Site, Site-to-VPN, and configuration scenarios',
href: '/manage/network-routes/use-cases/site-to-site',
name: 'Site-to-Site',
description: 'Connect two networks through routing peers at each end',
},
{
href: '/manage/network-routes/use-cases/by-scenario/exit-nodes',
href: '/manage/network-routes/use-cases/exit-nodes',
name: 'Exit Nodes',
description: 'Route all internet traffic through a specific peer',
},
{
href: '/manage/network-routes/use-cases/by-configuration/access-control',
href: '/manage/network-routes/access-control',
name: 'Access Control',
description: 'Use ACL Groups to control who can access routed networks',
},
{
href: '/manage/network-routes/use-cases/by-configuration/overlapping-routes',
href: '/manage/network-routes/overlapping-routes',
name: 'Overlapping Routes',
description: 'Handle scenarios where multiple routes have the same CIDR',
},

2
src/pages/manage/network-routes/use-cases/by-configuration/overlapping-routes.mdx → src/pages/manage/network-routes/overlapping-routes.mdx
View File

@@ -60,7 +60,7 @@ netbird routes select -a route3
Open the NetBird system tray application and navigate to **Network Routes**. Click the checkbox next to each route to select or deselect it.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-configuration/overlapping-routes/select-network-routes.png" alt="Route selection in system tray" className="imagewrapper"/>
<img src="/docs-static/img/manage/network-routes/overlapping-routes/select-network-routes.png" alt="Route selection in system tray" className="imagewrapper"/>
</p>
### Enabling All Routes

301
src/pages/manage/network-routes/use-cases/by-configuration/advanced-configuration.mdx
View File

@@ -1,301 +0,0 @@
import { Note, Warning } from '@/components/mdx'
# Advanced Configuration
This guide covers technical details for site-to-site connectivity, including masquerade options, access control, and troubleshooting.
## Understanding Masquerade
Masquerade determines how source IP addresses are handled when traffic passes through a routing peer.
### With Masquerade (Default)
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
- No additional routing configuration is 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 the routing peer IP, not the original device
### Without Masquerade
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 is 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 matching policies can use the route
### Configuration Example
**Step 1: Create the Network Route**
1. Go to **Network Routes**
2. Add a 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, create a 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 a policy for the route to activate. The route itself is controlled by policies targeting the ACL Group.
</Note>
## Site-to-Site Configuration
### Bidirectional Route Setup
Site-to-site requires routes in both directions:
**Site A to Site B:**
- Network Route: Site B's subnet
- Routing Peer: Site A's routing peer
- Masquerade: Enabled (recommended)
**Site B to Site A:**
- Network Route: Site A's subnet
- Routing Peer: Site B's routing peer
- Masquerade: Enabled (recommended)
### 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 for all devices on the network.
## Networks vs Network Routes
| 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 | More manual configuration |
| Routing peer redundancy | Built-in | Manual configuration |
| Policy requirement | Resource policies only | Routing peer + ACL Group policies |
## Troubleshooting
### Route Not Active
**Symptoms:** Peers do not 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 that ACL Group policies exist
### Traffic Times Out
**Symptoms:** Ping or connections hang with no response
**Causes:**
1. Routing peer cannot reach the destination network
2. Masquerade is disabled and no return route exists
3. Firewall is blocking traffic
**Solution:**
- Test from the routing peer: `ping <destination>` directly
- If masquerade is off, verify return routes are configured
- Check the OS firewall on the routing peer: `iptables -L -n` or equivalent
### Connection Works One Way
**Symptoms:** Can reach the remote site but responses do not 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 distributes 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.

244
src/pages/manage/network-routes/use-cases/by-scenario/site-to-site-cloud.mdx
View File

@@ -1,244 +0,0 @@
import { Note } from '@/components/mdx'
# Site-to-Site: Cloud Environments
This guide shows how to connect cloud VPCs across providers or bridge cloud and on-premise networks using Network Routes.
## What You'll Achieve
After following this guide, workloads across different cloud providers (AWS, GCP, Azure) or between cloud and on-premise can communicate without exposing traffic to the public internet.
```
AWS VPC ────► Routing Peer ────► NetBird ────► Routing Peer ────► GCP VPC
(10.0.0.0/16) (peer) (peer) (10.1.0.0/16)
```
<Note>
Multi-cloud Site-to-Site requires Network Routes because the Networks feature doesn't yet support this scenario.
</Note>
## Prerequisites
- A [NetBird cloud account](https://app.netbird.io/) or [self-hosted instance](/selfhosted/selfhosted-quickstart)
- Access to deploy VMs in your cloud environments
- Network configuration permissions in your cloud VPCs
## Example: Multi-Cloud Connectivity
Connect workloads across AWS and GCP:
- **AWS VPC**: `10.0.0.0/16`
- **GCP VPC**: `10.1.0.0/16`
## Step 1: Create Setup Keys with Groups
Before deploying routing peers, create setup keys with auto-assigned groups:
1. Go to **Setup Keys** in the NetBird dashboard
2. Click **Create Setup Key**
3. For AWS:
- Name: "AWS Routing Peer"
- Auto-assigned groups: Create and add `aws-routing-peers`
- Click **Create**
4. For GCP:
- Name: "GCP Routing Peer"
- Auto-assigned groups: Create and add `gcp-routing-peers`
<Note>
You can also add groups to peers manually after setup. Go to **Peers**, select the peer, and add groups under **Assigned Groups**.
</Note>
## Step 2: 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 3: Create Network Routes
**For AWS VPC:**
1. Go to **Network Routes**
2. Click **Add Route**
3. Network range: `10.0.0.0/16`
4. Routing Peer: Select your AWS instance (or use "aws-routing-peers" Peer Group)
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-cloud/add-route-aws-vpc.png" alt="Create route for AWS VPC" className="imagewrapper"/>
</p>
5. Distribution Groups: "gcp-routing-peers"
6. Access Control Groups: "aws-routing-peers" (required for route-level policies—this group becomes the destination in access policies; without it, policies targeting this route won't apply)
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-cloud/add-route-aws-groups.png" alt="AWS route distribution and access control groups" className="imagewrapper"/>
</p>
7. Network Identifier: `aws-vpc`
8. Enable **Masquerade** (in Additional Settings)
9. Click **Add Route**
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-cloud/add-route-masquerade.png" alt="Enable masquerade in additional settings" className="imagewrapper"/>
</p>
**For GCP VPC:**
1. Click **Add Route**
2. Network range: `10.1.0.0/16`
3. Routing Peer: Select your GCP instance (or use "gcp-routing-peers" Peer Group)
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-cloud/add-route-gcp-vpc.png" alt="Create route for GCP VPC" className="imagewrapper"/>
</p>
4. Distribution Groups: "aws-routing-peers"
5. Access Control Groups: "gcp-routing-peers" (required for route-level policies—this group becomes the destination in access policies; without it, policies targeting this route won't apply)
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-cloud/add-route-gcp-groups.png" alt="GCP route distribution and access control groups" className="imagewrapper"/>
</p>
6. Network Identifier: `gcp-vpc`
7. Enable **Masquerade** (in Additional Settings)
8. Click **Add Route**
## Step 4: Create Access Policies
Create two policies allowing the routing peers to communicate in both directions:
1. Go to **Access Control > Policies**
2. Create policies between the routing peer groups:
```
Source: aws-routing-peers → Destination: gcp-routing-peers (All)
Source: gcp-routing-peers → Destination: aws-routing-peers (All)
```
For route-level access control (if Access Control Groups configured), you can restrict by protocol and port:
```
Source: aws-routing-peers → Destination: gcp-routing-peers (specific protocols)
Source: gcp-routing-peers → Destination: aws-routing-peers (specific protocols)
```
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-cloud/add-policy-aws-to-gcp-tcp.png" alt="AWS to GCP policy with TCP port 443" className="imagewrapper"/>
</p>
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-cloud/add-policy-gcp-to-aws-udp.png" alt="GCP to AWS policy with UDP port 53" className="imagewrapper"/>
</p>
## Step 5: 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 (ENI)
**GCP VPC:**
Add a custom route:
- Destination: `10.0.0.0/16` (AWS CIDR)
- Next hop: Your NetBird routing peer instance
<Note>
Enable IP forwarding on routing peer instances in both clouds.
</Note>
## Step 6: Test Connectivity
From an AWS instance:
```bash
ping 10.1.0.100 # GCP instance
```
From a GCP instance:
```bash
ping 10.0.0.100 # AWS instance
```
## Cloud-Specific Considerations
### AWS
- Security groups must allow traffic from the NetBird routing peer
- Enable source/destination check disabled on the routing peer instance
- 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
- Enable IP forwarding on the routing peer instance
- Use managed instance groups for high availability
### Azure
- Network security groups must allow traffic from the routing peer
- Enable IP forwarding on the routing peer NIC
- Consider using a Virtual Machine Scale Set for HA
## Secure Workload Migration
Use Site-to-Site connectivity for migrating workloads between environments:
### 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 (use VPN-to-Site via [Networks](/manage/networks/use-cases/by-scenario/cloud-to-on-premise))
3. **Cutover**: Switch traffic to the cloud application
4. **After migration**: Once database is also migrated, update connection strings and remove NetBird if no longer needed
## 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
**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
## Advanced Configuration
For masquerade options, ACL Groups, and detailed troubleshooting, see [Advanced Configuration](/manage/network-routes/use-cases/by-configuration/advanced-configuration).

192
src/pages/manage/network-routes/use-cases/by-scenario/site-to-site-home.mdx
View File

@@ -1,192 +0,0 @@
import { Note } from '@/components/mdx'
# Site-to-Site: Home Networks
This guide shows how to connect two home networks together so devices can communicate across locations—without installing NetBird on every device.
## What You'll Achieve
After following this guide, devices on one home network can communicate with devices on another home network. For example:
- Your home NAS can back up to your parents' NAS
- Family members can access shared media servers
- IoT devices can communicate across homes
```
Home A: NAS ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Parents' NAS
(no NetBird) (peer) (peer) (no NetBird)
```
<Note>
Site-to-Site requires Network Routes because the Networks feature doesn't yet support bidirectional routing between sites.
</Note>
## Prerequisites
- A [NetBird cloud account](https://app.netbird.io/) or [self-hosted instance](/selfhosted/selfhosted-quickstart)
- An always-on device at each home to serve as routing peers (Raspberry Pi, NAS with Docker, etc.)
- Different subnets at each location (if both use `192.168.1.0/24`, see [Resolve Overlapping Routes](/manage/network-routes/use-cases/by-configuration/overlapping-routes))
## 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: Create Setup Keys with Groups
Before installing NetBird on your routing peers, create setup keys with auto-assigned groups:
1. Go to **Setup Keys** in the NetBird dashboard
2. Click **Create Setup Key**
3. For your home routing peer:
- Network Identifier: "Home Routing Peer"
- Auto-assigned groups: Create and add `home-routing-peers`
- Click **Create**
4. Repeat for parents' home:
- Network Identifier: "Parents Routing Peer"
- Auto-assigned groups: Create and add `parents-routing-peers`
<Note>
You can also add groups to peers manually after setup. Go to **Peers**, select the peer, and add groups under **Assigned Groups**.
</Note>
## Step 2: Install NetBird on Routing Peers
**At your home:**
```bash
curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --setup-key YOUR_HOME_SETUP_KEY
```
**At parents' home:**
```bash
curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --setup-key YOUR_PARENTS_SETUP_KEY
```
## Step 3: Create Network Routes
1. Go to **Network Routes** in the dashboard
2. Click **Add Route**
**For your home network:**
- Network range: `192.168.1.0/24`
- Routing Peer: Select "home-rpi" (or use "home-routing-peers" Peer Group)
- Distribution Groups: "parents-routing-peers"
- Access Control Groups: "home-routing-peers" (optional—for route-level policies, this group becomes the destination in access policies; without it, policies targeting this route won't apply)
- Network Identifier: `home-lan`
- Enable **Masquerade** in Additional Settings (recommended for simplicity)
- Click **Add Route**
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-home/add-new-route-home-rpi.png" alt="Create route for home network" className="imagewrapper"/>
</p>
**For parents' home network:**
- Network range: `192.168.2.0/24`
- Routing Peer: Select "parents-rpi" (or use "parents-routing-peers" Peer Group)
- Distribution Groups: "home-routing-peers"
- Access Control Groups: "parents-routing-peers" (optional—for route-level policies, this group becomes the destination in access policies; without it, policies targeting this route won't apply)
- Network Identifier: `parents-lan`
- Enable **Masquerade** in Additional Settings (recommended)
- Click **Add Route**
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-home/add-new-route-parents-rpi.png" alt="Create route for parents network" className="imagewrapper"/>
</p>
## Step 4: Create Access Policies
Create two policies that allow the routing peers to communicate in both directions:
1. Go to **Access Control > Policies**
2. Add first policy:
- Network Identifier: "Home to Parents"
- Source: "home-routing-peers"
- Destination: "parents-routing-peers"
- Protocol: All (or restrict as needed)
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-home/add-policy-home-to-parents.png" alt="Create policy for home to parents" className="imagewrapper"/>
</p>
3. Add second policy:
- Network Identifier: "Parents to Home"
- Source: "parents-routing-peers"
- Destination: "home-routing-peers"
- Protocol: All (or restrict as needed)
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-home/add-policy-parents-to-home.png" alt="Create policy for parents to home" className="imagewrapper"/>
</p>
## Step 5: Configure Clientless Devices
For devices without NetBird to reach the other network, add a static route pointing to the local routing peer.
**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.
**On a Windows device:**
```powershell
route add 192.168.2.0 mask 255.255.255.0 192.168.1.100
```
<Note>
For persistent routes, configure them in your router's DHCP settings or the device's network configuration.
</Note>
**Router-level configuration (recommended):**
Configure your router to advertise routes via DHCP or add a static route that applies to all devices:
```
# On your home router
Destination: 192.168.2.0/24
Gateway: 192.168.1.100 (your routing peer's IP)
```
## Step 6: Test Cross-Network Access
From a device at your home:
```bash
ping 192.168.2.1 # Parents' router
ping 192.168.2.50 # Parents' NAS
```
From a device at parents' home:
```bash
ping 192.168.1.1 # Your router
ping 192.168.1.50 # Your NAS
```
## Troubleshooting
**Site-to-site not working:**
1. Verify both routing peers are online and connected: check `netbird status` on each
2. Check that static routes are configured on clientless devices
3. Ensure access policies allow traffic in both directions
**Can't reach specific devices:**
1. Verify the device has a route to the remote network
2. Check firewall rules on the target device
3. Ensure the routing peer can reach the target on its local network
**Traffic works one way but not the other:**
1. Check that both network routes exist
2. Verify access policies exist for both directions
3. Ensure static routes are configured at both ends
## Advanced Configuration
For masquerade options, ACL Groups for access control, and detailed troubleshooting, see [Advanced Configuration](/manage/network-routes/use-cases/by-configuration/advanced-configuration).

222
src/pages/manage/network-routes/use-cases/by-scenario/site-to-site-office.mdx
View File

@@ -1,222 +0,0 @@
import { Note } from '@/components/mdx'
# Site-to-Site: Office Networks
This guide shows how to connect multiple office locations so all devices can communicate—including those without NetBird installed.
## What You'll Achieve
After following this guide, devices at different office locations can communicate with each other:
- Branch office servers can access headquarters databases
- Printers and IoT devices can be managed from any location
- Legacy systems can communicate across sites
```
HQ Server ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Branch Server
(no NetBird) (peer) (peer) (no NetBird)
```
<Note>
Site-to-Site requires Network Routes because the Networks feature doesn't yet support bidirectional routing between sites.
</Note>
## Prerequisites
- A [NetBird cloud account](https://app.netbird.io/) or [self-hosted instance](/selfhosted/selfhosted-quickstart)
- Admin access to network infrastructure at each location
- A server or VM at each location to serve as routing peers
## 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: Create Setup Keys with Groups
Before installing NetBird on your routing peers, create setup keys with auto-assigned groups:
1. Go to **Setup Keys** in the NetBird dashboard
2. Click **Create Setup Key**
3. For headquarters:
- Name: "HQ Routing Peer"
- Auto-assigned groups: Create and add `hq-routing-peers`
- Click **Create**
4. For branch office:
- Name: "Branch Routing Peer"
- Auto-assigned groups: Create and add `branch-routing-peers`
<Note>
You can also add groups to peers manually after setup. Go to **Peers**, select the peer, and add groups under **Assigned Groups**.
</Note>
## Step 2: Deploy Routing Peers
Install NetBird on a server at each location:
**At headquarters:**
```bash
curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --setup-key YOUR_HQ_SETUP_KEY
```
**At branch office:**
```bash
curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --setup-key YOUR_BRANCH_SETUP_KEY
```
## Step 3: Create Network Routes
**For headquarters:**
1. Go to **Network Routes**
2. Click **Add Route**
3. Network range: `10.0.0.0/24`
4. Routing Peer: Select "hq-router" (or use "hq-routing-peers" Peer Group)
5. Distribution Groups: "branch-routing-peers"
6. Access Control Groups: "hq-routing-peers" (required for route-level policies—this group becomes the destination in access policies; without it, policies targeting this route won't apply)
7. Network Identifier: `hq-network`
8. Enable **Masquerade** (in Additional Settings)
9. Click **Add Route**
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-office/add-route-hq-network.png" alt="Create route for headquarters network" className="imagewrapper"/>
</p>
**For branch office:**
1. Click **Add Route**
2. Network range: `10.1.0.0/24`
3. Routing Peer: Select "branch-router" (or use "branch-routing-peers" Peer Group)
4. Distribution Groups: "hq-routing-peers"
5. Access Control Groups: "branch-routing-peers" (required for route-level policies—this group becomes the destination in access policies; without it, policies targeting this route won't apply)
6. Network Identifier: `branch-network`
7. Enable **Masquerade** (in Additional Settings)
8. Click **Add Route**
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-office/add-route-branch-network.png" alt="Create route for branch network" className="imagewrapper"/>
</p>
## Step 4: Create Access Policies
Create two policies allowing the routing peers to communicate in both directions:
```
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 (if ACL Groups configured), you can restrict by protocol and port:
```
Source: hq-routing-peers → Destination: branch-routing-peers (specific protocols)
Source: branch-routing-peers → Destination: hq-routing-peers (specific protocols)
```
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-office/add-policy-hq-to-branch-tcp.png" alt="HQ to branch policy with TCP ports 8080 and 53" className="imagewrapper"/>
</p>
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/site-to-site-office/add-policy-branch-to-hq-tcp.png" alt="Branch to HQ policy with TCP port 443" className="imagewrapper"/>
</p>
## Step 5: 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
Destination: 10.1.0.0/24
Gateway: 10.0.0.50 (hq-router's IP)
# On Branch router, route to HQ through routing peer
Destination: 10.0.0.0/24
Gateway: 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 (Linux)
sudo ip route add 10.1.0.0/24 via 10.0.0.50
# On Branch device (Linux)
sudo ip route add 10.0.0.0/24 via 10.1.0.50
```
**Windows (PowerShell):**
```powershell
# On HQ device
route -p add 10.1.0.0 mask 255.255.255.0 10.0.0.50
# On Branch device
route -p add 10.0.0.0 mask 255.255.255.0 10.1.0.50
```
## Step 6: Test Connectivity
From a device at headquarters:
```bash
ping 10.1.0.1 # Branch router
ping 10.1.0.100 # Branch server
```
From a device at branch office:
```bash
ping 10.0.0.1 # HQ router
ping 10.0.0.100 # HQ server
```
## Site-to-VPN: Office Systems Reaching Remote Workers
Some scenarios require office systems without NetBird to initiate
connections to NetBird-connected peers (monitoring, backups, management
tools, etc.). See [Site-to-VPN](/manage/networks/use-cases/site-to-vpn)
for the full step-by-step guide, including DNS resolution and the
per-service port-forwarding alternative.
## 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:
- Deploy multiple routing peers at each location
- Use peer groups for automatic failover
- Monitor routing peer health
### 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
**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
## Advanced Configuration
For masquerade options, ACL Groups, and detailed troubleshooting, see [Advanced Configuration](/manage/network-routes/use-cases/by-configuration/advanced-configuration).

10
src/pages/manage/network-routes/use-cases/by-scenario/exit-nodes.mdx → src/pages/manage/network-routes/use-cases/exit-nodes.mdx
View File

@@ -58,7 +58,7 @@ Clients running v0.55.0 or later auto-apply these routes unless the user has exp
Navigate to the NetBird dashboard and select the **Peers** tab.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/exit-nodes/netbird-peers.png" alt="Dashboard peers view" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/use-cases/exit-nodes/netbird-peers.png" alt="Dashboard peers view" className="imagewrapper-big"/>
</p>
### 2. Select the Routing Peer
@@ -66,7 +66,7 @@ Navigate to the NetBird dashboard and select the **Peers** tab.
Choose the peer that will serve as your exit node.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/exit-nodes/netbird-peers-routing-peer.png" alt="Routing peer selection" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/use-cases/exit-nodes/netbird-peers-routing-peer.png" alt="Routing peer selection" className="imagewrapper-big"/>
</p>
### 3. Configure the Exit Node
@@ -74,13 +74,13 @@ Choose the peer that will serve as your exit node.
Click **Add Exit Node**. In the dialog, assign one or more distribution groups to specify which peers should use this exit node.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/exit-nodes/netbird-peers-add-exit-node.png" alt="Add exit node dialog" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/use-cases/exit-nodes/netbird-peers-add-exit-node.png" alt="Add exit node dialog" className="imagewrapper-big"/>
</p>
To make the exit node available without automatic activation, disable **Auto Apply**. Users can then enable it manually.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/exit-nodes/exit-node-auto-apply.png" alt="Auto Apply option" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/use-cases/exit-nodes/exit-node-auto-apply.png" alt="Auto Apply option" className="imagewrapper-big"/>
</p>
Click **Add Exit Node** to complete the configuration. Masquerading is enabled by default.
@@ -90,7 +90,7 @@ Click **Add Exit Node** to complete the configuration. Masquerading is enabled b
Check the peer view to confirm the routing peer is marked as an exit node.
<p>
<img src="/docs-static/img/manage/network-routes/use-cases/by-scenario/exit-nodes/netbird-peers-routing-peer-exit-node.png" alt="Exit node confirmation" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/network-routes/use-cases/exit-nodes/netbird-peers-routing-peer-exit-node.png" alt="Exit node confirmation" className="imagewrapper-big"/>
</p>
### 5. Configure DNS

136
src/pages/manage/network-routes/use-cases/index.mdx
View File

@@ -1,136 +0,0 @@
import { Tiles } from '@/components/Tiles'
import { Note, Warning } from '@/components/mdx'
# Network Routes Use Cases
These guides show how to use [Network Routes](/manage/network-routes) for Site-to-Site and Site-to-VPN connectivity—scenarios where clientless devices need to communicate across networks.
## What Are Site-to-Site and Site-to-VPN?
Network Routes enables two connectivity patterns that go beyond standard VPN-to-Site access:
**Site-to-Site** connects two networks together, with neither end-device running NetBird. Each network has a routing peer that handles traffic forwarding.
```
Home NAS ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Office Server
(no NetBird) (peer) (peer) (no NetBird)
```
**Site-to-VPN** allows clientless devices to initiate connections to NetBird peers—the reverse of VPN-to-Site.
```
Office Server ──────► Routing Peer ──────► NetBird Tunnel ──────► Your Laptop
(no NetBird) (peer) (peer)
```
<Note>
For VPN-to-Site (NetBird peers accessing clientless devices), you can use either [Networks](/manage/networks/use-cases) (recommended for simplicity) or Network Routes.
</Note>
## Understanding Key Concepts
Network Routes provides several features that differentiate it from Networks and enable more advanced scenarios:
### Masquerade
Masquerade controls whether the routing peer hides the original source IP address when forwarding traffic:
- **Enabled (default)** — The routing peer performs NAT, making traffic appear to originate from its own IP. Simpler setup since remote networks don't need return routes.
- **Disabled** — Original source IPs are preserved, enabling accurate audit trails. Requires manual route configuration on both ends.
Use masquerade when you want simple setup. Disable it when compliance or auditing requires source IP visibility.
### Distribution Groups
Distribution Groups determine which peers receive the network route configuration. When you add peers to a distribution group, they automatically get the route—no manual configuration on each client.
For site-to-site scenarios, each site's routing peer should be in the other site's distribution group to receive routes back.
### ACL Groups
ACL Groups provide route-level access control. When you assign an ACL Group to a Network Route:
1. The route inherits access restrictions from policies targeting that group
2. Only peers with policies granting access to the ACL Group can use the route
3. Without an ACL Group, routes allow unrestricted access
<Warning>
If an ACL Group is assigned but no policies grant access to it, all routed traffic will be dropped.
</Warning>
### High Availability
Deploy multiple routing peers for the same route to provide failover. NetBird clients automatically select the best available peer based on:
- Connection type (direct vs relayed)
- Defined metric priority (lower = higher priority)
- Connection quality
## Why Use Network Routes?
Network Routes is required when you need:
- **Site-to-Site connectivity** — Connect two networks together
- **Site-to-VPN connectivity** — Clientless devices initiating connections
- **Masquerade control** — Preserve source IPs for auditing
- **ACL Groups** — Route-level access control
<Tiles
title="By Scenario"
items={[
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-home',
name: 'Site-to-Site: Home Networks',
description: 'Connect multiple home networks so devices can communicate across locations',
},
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-office',
name: 'Site-to-Site: Office Networks',
description: 'Connect branch offices to headquarters and enable cross-site communication',
},
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-cloud',
name: 'Site-to-Site: Cloud Environments',
description: 'Bridge cloud VPCs across providers or connect cloud to on-premise',
},
]}
/>
<Tiles
title="By Configuration"
items={[
{
href: '/manage/network-routes/use-cases/by-scenario/exit-nodes',
name: 'Exit Nodes',
description: 'Route all internet traffic through a specific peer',
},
{
href: '/manage/network-routes/use-cases/by-configuration/access-control',
name: 'Access Control',
description: 'Use ACL Groups to control who can access routed networks',
},
{
href: '/manage/network-routes/use-cases/by-configuration/overlapping-routes',
name: 'Overlapping Routes',
description: 'Handle scenarios where multiple routes share the same CIDR',
},
{
href: '/manage/network-routes/use-cases/by-configuration/advanced-configuration',
name: 'Advanced Configuration',
description: 'Masquerade options, troubleshooting, and detailed configuration',
},
]}
/>
## Configuration Pattern
All Site-to-Site and Site-to-VPN scenarios follow this pattern:
1. **Deploy routing peers** at each site
2. **Create network routes** for each site's subnet
3. **Create access policies** allowing routing peers to communicate
4. **Configure clientless devices** to route traffic through the local routing peer
For step-by-step instructions, choose your scenario above. For technical details and troubleshooting, see [Advanced Configuration](/manage/network-routes/use-cases/by-configuration/advanced-configuration).
## Need Simpler VPN-to-Site Access?
If you only need NetBird peers to access remote resources (not site-to-site or site-to-vpn), the [Networks](/manage/networks/use-cases) feature offers a simpler setup experience with per-resource access control.

123
src/pages/manage/network-routes/use-cases/site-to-site.mdx Normal file
View File

@@ -0,0 +1,123 @@
import { Note } from '@/components/mdx'
# Site-to-Site
Site-to-Site connects two networks through routing peers at each end. Neither end-device needs NetBird installed — the routing peers forward traffic across the NetBird tunnel.
## Architecture
```
Site A device ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Site B device
(no NetBird) (peer) (peer) (no NetBird)
```
<Note>
For one-way access from a NetBird peer to clientless devices behind a routing peer (VPN-to-Site), prefer [Networks](/manage/networks) — it has per-resource access control and simpler setup. Network Routes is required when you need Site-to-Site, source-IP preservation (masquerade disabled), or ACL Groups.
For the reverse — clientless devices at a site initiating connections to NetBird peers — see [Site-to-VPN](/manage/networks/use-cases/site-to-vpn).
</Note>
## Prerequisites
- A NetBird account ([cloud](https://app.netbird.io/) or [self-hosted](/selfhosted/selfhosted-quickstart))
- An always-on device at each site to act as the routing peer (server, VM, Raspberry Pi, NAS with Docker)
- Different subnets at each site. If both sites use the same range (e.g. `192.168.1.0/24`), see [Overlapping Routes](/manage/network-routes/overlapping-routes)
## Example
Two sites, A and B:
- Site A: `10.0.0.0/24`, routing peer group `site-a-routers`
- Site B: `10.1.0.0/24`, routing peer group `site-b-routers`
## Step 1: Create setup keys for each site
Create one setup key per site with an auto-assigned group for that site's routing peers.
1. **Setup Keys** → **Create Setup Key**
2. For Site A: name "Site A Routing Peer", auto-assign group `site-a-routers`
3. Repeat for Site B with group `site-b-routers`
<Note>
You can also assign groups manually after the peer connects, under **Peers** → select peer → **Assigned Groups**.
</Note>
## Step 2: Install NetBird on the routing peers
On each site's routing peer:
```bash
curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --setup-key YOUR_SETUP_KEY
```
## Step 3: Create network routes
Add one route per site under **Network Routes** → **Add Route**:
**Site A:**
- Network range: `10.0.0.0/24`
- Routing Peer: the `site-a-routers` group (or a specific peer)
- Distribution Groups: `site-b-routers`
- Access Control Groups: `site-a-routers` (optional — see [Access Control](/manage/network-routes/access-control))
- Network Identifier: `site-a`
- Enable **Masquerade** under Additional Settings (recommended — see [Advanced Configuration](/manage/network-routes/advanced-configuration) for the disabled case)
**Site B:** swap the values — `10.1.0.0/24`, `site-b-routers` as routing peer, `site-a-routers` in distribution.
## Step 4: Create bidirectional policies
Site-to-Site requires two policies — one for each direction:
```
site-a-routers → site-b-routers (All protocols)
site-b-routers → site-a-routers (All protocols)
```
Tighten by protocol/port if needed.
## Step 5: Tell clientless devices about the remote subnet
Devices without NetBird need a static route pointing to the local routing peer.
**Router-level (recommended)** — add a static route on the site's router so all devices inherit it:
```
Destination: 10.1.0.0/24 # remote network
Gateway: 10.0.0.50 # local routing peer
```
**Per-device fallback** — Linux:
```bash
sudo ip route add 10.1.0.0/24 via 10.0.0.50
```
Windows (PowerShell, persistent):
```powershell
route -p add 10.1.0.0 mask 255.255.255.0 10.0.0.50
```
## Step 6: Verify
From Site A, ping a device at Site B:
```bash
ping 10.1.0.100
```
Reverse from Site B to confirm both directions work.
## Cloud routing peers
When the routing peer is a cloud instance, the VPC needs to allow it to forward traffic on behalf of other addresses:
- **AWS**: Disable the source/destination check on the routing peer's ENI. Add a VPC route table entry with the remote CIDR as the destination and the routing peer's ENI as the target. Security groups must allow traffic from the routing peer.
- **GCP**: Enable IP forwarding on the instance. Add a custom route in the VPC with the remote CIDR as the destination and the routing peer instance as the next hop. Firewall rules must allow traffic from the routing peer's internal IP.
- **Azure**: Enable IP forwarding on the routing peer's NIC. Add a route table entry with the remote CIDR pointing at the routing peer. Network security groups must allow the traffic.
## Next steps
- [Access Control](/manage/network-routes/access-control) — restrict who can use a route via ACL Groups
- [Overlapping Routes](/manage/network-routes/overlapping-routes) — handle sites with the same CIDR
- [Advanced Configuration](/manage/network-routes/advanced-configuration) — masquerade trade-offs, troubleshooting, comparison with Networks

8
src/pages/manage/networks/how-routing-peers-work.mdx
View File

@@ -32,7 +32,7 @@ NetBird offers two ways to configure routing peers. Both are actively maintained
**[Network Routes](/manage/network-routes) (legacy, still supported)**
- Distribution Groups and ACL Groups are configured separately.
- ACL Groups are optional, which means a route without them grants unrestricted access to the destination CIDR for every peer in the Distribution Group.
- Only needed today for [exit node](/manage/network-routes/use-cases/by-scenario/exit-nodes) setups and [site-to-site](/use-cases/site-to-site) configurations. Use Networks for everything else.
- Only needed today for [exit node](/manage/network-routes/use-cases/exit-nodes) setups and [site-to-site](/use-cases/site-to-site) configurations. Use Networks for everything else.
For a scenario-by-scenario comparison, see our [site-to-site documentation](/use-cases/site-to-site).
@@ -220,17 +220,17 @@ Specifics:
description: 'Legacy routing peer feature still supported for scenarios Networks does not yet cover',
},
{
href: '/manage/network-routes/use-cases/by-configuration/access-control',
href: '/manage/network-routes/access-control',
name: 'Access Control on Network Routes',
description: 'Use ACL Groups to restrict who reaches a routed network',
},
{
href: '/manage/network-routes/use-cases/by-configuration/masquerade',
href: '/manage/network-routes/advanced-configuration',
name: 'Masquerade',
description: 'When to enable or disable source IP rewriting on a route',
},
{
href: '/manage/network-routes/use-cases/by-scenario/exit-nodes',
href: '/manage/network-routes/use-cases/exit-nodes',
name: 'Exit Nodes',
description: 'Route all internet-bound traffic through a controlled location',
},

32
src/pages/manage/networks/index.mdx
View File

@@ -8,9 +8,27 @@ However, installing the agent on every machine is not always feasible. Networks
<img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="high-level-dia" className="imagewrapper-big"/>
</p>
## VPN-to-Site Use Case
Networks enables VPN-to-Site access — a device running NetBird (like your laptop) reaches devices on a remote network without installing NetBird on every target.
```
Your Laptop ──────► NetBird Tunnel ──────► Routing Peer ──────► Target Device
(peer) (peer) (no NetBird)
```
**Example scenarios:**
- Access your home NAS from a coffee shop
- Reach office servers while traveling
- Connect to IoT devices on a remote network
## Networks vs. Network Routes
Networks is the newer, simpler replacement for Network Routes. We encourage you to use Networks where possible; however, Networks do not yet support all remote access scenarios. Network Routes will continue to be actively maintained, so use whichever fits your use case.
Networks is the newer, simpler replacement for Network Routes — for VPN-to-Site, prefer Networks. Use [Network Routes](/manage/network-routes) when you need:
- Clientless devices initiating connections (Site-to-VPN)
- Two networks communicating with each other (Site-to-Site)
- Source-IP preservation (masquerade disabled)
For a detailed comparison, see our [site-to-site documentation](/use-cases/site-to-site).
@@ -132,6 +150,10 @@ Example policy allowing the `Berlin Office` group to access the internal CRM sys
<img src="/docs-static/img/manage/networks/index/resource-acl-1.png" alt="resource-acl" className="imagewrapper-big"/>
</p>
### Share one policy across multiple resources
To apply the same policy to several resources, assign them to the same resource group and create one policy with that group as the destination. For example, two internal DNS servers at `172.16.30.2` and `172.17.100.2` can share a single UDP/53 policy by placing both in an `office-dns-servers` group. Skip the **Access Control** tab when adding each resource, then create the shared policy once from any of them.
<Note>
Policies for domain or wildcard domain resources may unintentionally affect peers with IP range resources, since IP ranges can match any address. We recommend using dedicated networks and routing peers for domain-based resources to prevent unwanted access. A fix for this behavior is planned for an upcoming release.
</Note>
@@ -175,11 +197,9 @@ To enable DNS wildcard routing, go to **Settings** > **Networks** > **Enable DNS
Starting with NetBird v0.59.0, the local DNS forwarder port changed from `5353` to `22054` to avoid port collisions. For backward compatibility, the new port is only used when **all peers in the account** run v0.59.0 or newer. If any peer is on an older version, port `5353` is used for all peers.
</Note>
## Use Cases
- [Routing traffic to multiple IP resources](/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources)
- [Accessing restricted website domain resources](/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources)
- [Accessing entire domains within networks](/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks)
<Note>
A wildcard resource like `*.dev.example.com` matches subdomains only, not the base domain. To allow access to `dev.example.com` as well, add it as a separate resource — assigning it to the same resource group reuses the existing routing peers and policies.
</Note>
## Get Started

16
src/pages/manage/networks/use-cases/by-scenario/access-home-devices.mdx → src/pages/manage/networks/use-cases/access-home-devices.mdx
View File

@@ -38,7 +38,7 @@ If you haven't already, install NetBird on your laptop and connect:
2. Under **Assigned Groups**, add a new group: "Home Users"
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/access-home-devices/add-user-group.png" alt="Add user group" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/access-home-devices/add-user-group.png" alt="Add user group" className="imagewrapper"/>
</p>
## Step 3: Find Your Home Subnet
@@ -64,7 +64,7 @@ Look for your local subnet, typically something like `192.168.1.0/24` or `192.16
3. Name it "Home LAN" and click **Save**
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/access-home-devices/add-network-home-lan.png" alt="Add network" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/access-home-devices/add-network-home-lan.png" alt="Add network" className="imagewrapper"/>
</p>
## Step 5: Add Your Home Subnet as a Resource
@@ -76,7 +76,7 @@ Look for your local subnet, typically something like `192.168.1.0/24` or `192.16
5. Click **Continue** to proceed to the **Access Control** tab
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/access-home-devices/add-resource-home-network.png" alt="Add resource" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/access-home-devices/add-resource-home-network.png" alt="Add resource" className="imagewrapper"/>
</p>
<Note>
@@ -93,7 +93,7 @@ For more granular access, add specific device IPs instead of the entire subnet.
6. Click **Add Resource** to save the resource with its policy
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/access-home-devices/add-policy-home-lan.png" alt="Add policy" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/access-home-devices/add-policy-home-lan.png" alt="Add policy" className="imagewrapper"/>
</p>
## Step 7: Set Up the Routing Peer
@@ -123,13 +123,13 @@ sudo netbird up --setup-key YOUR_SETUP_KEY
4. In the Networks view, click **Add Routing Peer** on your Home LAN network
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/access-home-devices/add-routing-peer.png" alt="Add routing peer button" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/access-home-devices/add-routing-peer.png" alt="Add routing peer button" className="imagewrapper"/>
</p>
5. Select your new peer and click **Add Routing Peer**
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/access-home-devices/add-routing-peer-home-network.png" alt="Add routing peer" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/access-home-devices/add-routing-peer-home-network.png" alt="Add routing peer" className="imagewrapper"/>
</p>
## Step 8: Test the Connection
@@ -167,5 +167,5 @@ You can now access your home devices from anywhere.
## Next Steps
- **Need Site-to-Site?** If you want to connect two home networks together, see [Site-to-Site: Home Networks](/manage/network-routes/use-cases/by-scenario/site-to-site-home)
- **Advanced configuration:** See [Advanced Configuration](/manage/network-routes/use-cases/by-configuration/advanced-configuration) for masquerade options and access control details
- **Need Site-to-Site?** If you want to connect two home networks together, see [Site-to-Site](/manage/network-routes/use-cases/site-to-site)
- **Advanced configuration:** See [Advanced Configuration](/manage/network-routes/advanced-configuration) for masquerade options and access control details

212
src/pages/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks.mdx
View File

@@ -1,212 +0,0 @@
# Accessing entire domains within networks
This guide shows how to provide access to entire internal domains using NetBird [Networks](/manage/networks) with [wildcard domain resources](/manage/networks#resources). Wildcard domains simplify access management when teams need to reach multiple subdomains under a common parent domain.
## Example scenario
An AI software company needs to provide secure access to two internal environments:
1. **Development environment** (`*.dev.example.com`): Shared workspace for code development, testing, and collaboration
2. **AI model training environment** (`*.ai.example.com`): Sensitive AI models and datasets with restricted access
Using wildcard domains, developers can access any subdomain under `*.dev.example.com`, while data scientists access `*.ai.example.com`. This separation ensures team members only reach resources relevant to their roles.
### Prerequisites
Before starting, ensure you have:
- [NetBird clients](/get-started) installed on developer and data scientist devices
- [Routing peers](/manage/networks#routing-peers) configured in your network using [setup keys](/manage/peers/access-infrastructure/setup-keys-add-servers-to-network)
- [Nameservers](/manage/dns) configured in NetBird to resolve domain queries
## Enable DNS wildcard routing
DNS wildcard routing allows NetBird to resolve subdomain requests through routing peers. This must be enabled before using wildcard domain resources.
<Note>
DNS wildcard routing shifts DNS resolution from the local client to the routing peer, enabling access control rules and optimized traffic routing.
</Note>
To enable DNS wildcard routing:
1. Navigate to `Settings` > `Networks` in NetBird
2. Toggle `Enable DNS wildcard routing`
![Enabling DNS wildcard routing](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/01-domains-within-networks.png)
<Note>
DNS wildcard routing requires routing peers and clients running version `0.35.0` or later. Restart your routing peers and clients after enabling this feature.
</Note>
<Note>
DNS Forwarder port change: Starting with NetBird v0.59.0, the local DNS forwarder switches from port <code>5353</code> to <code>22054</code> to avoid collisions. For backward compatibility, the Management Service applies the new port only when <strong>all peers in the account</strong> run v0.59.0 or newer.
</Note>
## Set up the development network
### Create the network
1. Navigate to `Networks` > `Networks` in the NetBird dashboard
2. Click `Add Network`
3. Enter a name (e.g., `Development Network`) and optional description
4. Click `Add Network`
![Creating Developers Domain Network](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/02-domains-within-networks.png)
### Add routing peers
Click `Add Routing Peer` to enable access to resources in this network.
![Add Routing Peers Window](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/03-domains-within-networks.png)
Choose your routing configuration:
- Select `Routing Peers` to add a single peer
- Select `Peer Group` to add multiple peers for high availability
- Click `Continue`
![Local Routing Peers](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/04-domains-within-networks.png)
In `Advanced Settings`:
- Enable `Masquerade` to access private networks without configuring local routers
- Set `Metric` to prioritize routers (lower values = higher priority)
- Click `Add Routing Peer`
![Masquerade and Metric](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/05-domains-within-networks.png)
### Add a wildcard domain resource
Click `Add Resource` to open the resource modal.
![Add Domain Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/06-domains-within-networks.png)
In the **Resource** tab, configure the resource:
- **Name**: `Development Wildcard Domain`
- **Address**: `*.dev.example.com`
- Expand **Additional Options** and under **Resource Groups**, select or create a group (e.g., `Development Domain`)
- Click **Continue** to proceed to the **Access Control** tab
![Add Development Wildcard Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/07-domains-within-networks.png)
### Create an access policy
In the **Access Control** tab, click **Add Policy** to grant developers access to `*.dev.example.com`.
Configure the policy:
- **Protocol**: `ALL`
- **Source**: `Developers`
- **Destination**: `Development Domain` (auto-populated)
![Developers Policy](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/09-domains-within-networks.png)
Click `Continue` to optionally add posture checks, then `Continue` again. Enter a policy name (e.g., `Development Wildcard Domain Policy`) and click `Add Policy`.
![Developers Policy Name](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/10-domains-within-networks.png)
Click **Add Resource** to save the resource with its policy.
### Add the base domain resource
Wildcard domains (`*.dev.example.com`) only match subdomains, not the base domain itself. To also allow access to `dev.example.com`, add it as a separate resource.
1. Navigate to `Networks` > `Development Network` and click `Add Resource`
![Development Network](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/11-domains-within-networks.png)
2. In the **Resource** tab, configure the resource:
- **Name**: `Development Regular Domain`
- **Address**: `dev.example.com`
- Expand **Additional Options** and under **Resource Groups**, select `Development Domain` (same group as the wildcard)
- Click **Continue** to proceed to the **Access Control** tab, then click **Add Resource**
![Regular Domain Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/12-domains-within-networks.png)
Since you used the same group, NetBird automatically applies the existing routing peers and access policies.
![Development Network Resources](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/13-domains-within-networks.png)
Verify the configuration from a developer workstation:
```bash
$ netbird networks ls
Available Networks:
- ID: Development Regular Domain
Domains: dev.example.com
Status: Selected
Resolved IPs:
[example.com]: 93.184.215.14, 2606:2800:21f:cb07:6820:80da:af6b:8b2c
- ID: Development Wildcard Domain
Domains: *.dev.example.com
Status: Selected
Resolved IPs: -
```
## Set up the AI model training network
Follow the same steps to create a network for data scientists.
Create a new network named `AI Model Training Network`:
![AI Network](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/14-domains-within-networks.png)
Add routing peers (single or group for high availability):
![AI Routing Peers](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/15-domains-within-networks.png)
Add the wildcard domain resource for `*.ai.example.com`. In the **Resource** tab, enter the name and address, then expand **Additional Options** to assign a resource group (e.g., `AI Domain`). Click **Continue** to go to the **Access Control** tab:
![AI Wildcard Domain Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/16-domains-within-networks.png)
In the **Access Control** tab, click **Add Policy** and create an access policy for the `Data Scientists` group:
![AI Team Access Policy](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/17-domains-within-networks.png)
Click **Add Resource** to save. Then add the base domain `ai.example.com` as a separate resource using the same resource group. The completed network:
![AI Network](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/18-domains-within-networks.png)
### Add specific subdomain resources
You can add individual subdomain resources for more granular access control. For example, to add a specific AI model subdomain:
Click `Add Resource`, enter the subdomain name and address in the **Resource** tab, expand **Additional Options** to assign it to the appropriate resource group, then click **Continue** and **Add Resource**:
![New AI Model Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/19-domains-within-networks.png)
The network now shows all resources:
![AI Training Model Network](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks/20-domains-within-networks.png)
Verify from a data scientist workstation:
```bash
$ netbird networks ls
Available Networks:
- ID: AI Model Training Wildcard Domain
Domains: *.ai.example.com
Status: Selected
Resolved IPs: -
- ID: AI Regular Domain
Domains: ai.example.com
Status: Selected
Resolved IPs: -
- ID: DataSage Model
Domains: datasage.ai.example.com
Status: Selected
Resolved IPs: -
- ID: NeuroPulse Model
Domains: neuropulse.ai.example.com
Status: Selected
Resolved IPs: -
- ID: QuantumNet Model
Domains: quantumnet.ai.example.com
Status: Selected
Resolved IPs: -
```
Data scientists now have access to `ai.example.com` and all its subdomains. You can create additional access policies for individual subdomains or organize data scientists into teams with different permissions as needed.

154
src/pages/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources.mdx
View File

@@ -1,154 +0,0 @@
# Accessing restricted domain resources
This guide shows how to access restricted websites or services using NetBird [Networks](/manage/networks) with [domain resources](/manage/networks#resources). Domain resources are useful when the target service is behind a load balancer with frequently changing IP addresses.
## Example scenario
A company hosts an accounting application at `accounting.example.com` on AWS infrastructure in the EU Central region. The application runs on an EC2 instance behind a load balancer.
The company wants to implement zero trust access with role-based permissions:
- **Finance team**: HTTP/HTTPS access to `accounting.example.com` (ports 80 and 443)
- **Support team**: SSH access to the backend at `example.com` (port 22)
### Prerequisites
Before starting, ensure you have:
- [NetBird clients](/get-started) installed on finance and support team devices
- [Routing peers](/manage/networks#routing-peers) configured in the AWS VPC using [setup keys](/manage/peers/access-infrastructure/setup-keys-add-servers-to-network)
## Create a network
1. Navigate to `Networks` > `Networks` in the NetBird dashboard
2. Click `Add Network`
3. Enter a name (e.g., `AWS EU Network`) and optional description
4. Click `Add Network`
![Create Network](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/01-restricted-domain.png)
### Add routing peers
Click `Add Routing Peer` to enable access to the network's resources.
![Add Routing Peers Window](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/02-restricted-domain.png)
In the next window:
- Select `Routing Peers` to add a single peer (e.g., `aws-router`)
- Or select `Peer Group` to add multiple peers for high availability
- Click `Continue`
![Local Routing Peers](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/03-restricted-domain.png)
In `Advanced Settings`:
- Enable `Masquerade` to access private networks without configuring local routers
- Set `Metric` to prioritize routers (lower values = higher priority)
- Click `Add Routing Peer`
![Masquerade and Metric](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/04-restricted-domain.png)
### Add the accounting subdomain resource
Click `Add Resource` to open the resource modal.
![Add Network Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/05-restricted-domain.png)
In the **Resource** tab, configure the resource:
- **Name**: `Accounting restricted subdomain`
- **Address**: `accounting.example.com`
- Expand **Additional Options** and under **Resource Groups**, select or create a group (e.g., `Accounting Subdomain`)
- Click **Continue** to proceed to the **Access Control** tab
![Add Accounting Website Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/06-restricted-domain.png)
### Create an access policy for the finance team
In the **Access Control** tab, click **Add Policy** to define access for the finance team.
Configure the policy:
- **Protocol**: `TCP`
- **Source**: `Finance` (the finance team group)
- **Destination**: `Accounting Subdomain` (auto-populated)
- **Ports**: `80` and `443`
![Finance Policy](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/08-restricted-domain.png)
Click `Continue` to optionally add posture checks, then `Continue` again. Enter a policy name (e.g., `Accounting subdomain Policy`) and click `Add Policy`.
![Finance Policy Name](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/09-restricted-domain.png)
Click **Add Resource** to save the resource with its policy.
### Add the top-level domain resource for support
The support team needs SSH access to the backend at `example.com`. Add a new resource:
1. In the `AWS EU Network` screen, click `Add Resource`
2. In the **Resource** tab, configure:
- **Name**: `Restricted Website TLD`
- **Address**: `example.com`
- Expand **Additional Options** and under **Resource Groups**, select or create a group (e.g., `Webserver`)
3. Click **Continue** to proceed to the **Access Control** tab
![Add TLD Resource](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/10-restricted-domain.png)
### Create an access policy for the support team
In the **Access Control** tab, click **Add Policy** to create a policy for SSH access:
1. Configure:
- **Protocol**: `TCP`
- **Source**: `Support`
- **Destination**: `Webserver`
- **Ports**: `22`
2. Click `Continue`
![Add Support Team Policy](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/11-restricted-domain.png)
3. Optionally add posture checks, then click `Continue`
4. Enter a policy name (e.g., `Restricted Website TLD Policy`) and click `Add Policy`
![Name Support Team Policy](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/12-restricted-domain.png)
Click **Add Resource** to save the resource with its policy.
## Verify the configuration
The completed network shows both resources with their access policies:
![AWS EU Network](/docs-static/img/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources/13-restricted-domain.png)
Use the NetBird CLI to verify access. From a finance team workstation:
```bash
$ netbird networks list
Available Networks:
- ID: Accounting restricted subdomain
Domains: accounting.example.com
Status: Selected
Resolved IPs: -
- ID: Internal Web Services
Domains: *.company.internal
Status: Selected
Resolved IPs: -
```
From a support team workstation:
```bash
$ netbird networks list
Available Networks:
- ID: Internal Web Services
Domains: *.company.internal
Status: Selected
Resolved IPs: -
- ID: Restricted Website TLD
Domains: example.com
Status: Selected
Resolved IPs:
[example.com]: 93.184.215.14, 2606:2800:21f:cb07:6820:80da:af6b:8b2c
```
Each team sees only the resources they have access to, with appropriate port restrictions enforced by the access policies.

131
src/pages/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources.mdx
View File

@@ -1,131 +0,0 @@
# Routing traffic to multiple IP resources
This guide shows how to route traffic to multiple IP resources using NetBird [Networks](/manage/networks) with [IP resources](/manage/networks#resources). This is a common scenario for DevOps and Platform teams who need to provide differentiated access to on-premises or cloud infrastructure.
## Example scenario
In this example, you will configure access to an internal network (`172.16.0.0/15`) with these requirements:
- All users need access to DNS servers at `172.16.30.2` and `172.17.100.2` (UDP port 53 only)
- The DevOps team needs full access to the entire network range
Traffic will be routed through [routing peers](/manage/networks#routing-peers) running inside the network.
### Create a network
Navigate to `Networks` > `Networks` in the NetBird dashboard:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/view-wild-network-1.png" alt="new-net-1" className="imagewrapper-big"/>
</p>
Click `Add Network` to open the setup wizard. Enter a name and description for the network, then click `Continue`:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/new-example-network-2.png" alt="new-net2" className="imagewrapper"/>
</p>
### Add a routing peer
Click `Add routing peer` and select a peer from your network:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-routing-peer-1.png" alt="new-example-routing-peer-1" className="imagewrapper"/>
</p>
Click `Continue`, then accept the defaults and click `Add Routing Peer`:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-routing-peer-2.png" alt="new-routing-peer-2" className="imagewrapper"/>
</p>
### Add the network resource
Click `Add Resource` to open the resource modal. In the **Resource** tab:
1. Enter `Office network` as the name
2. Enter `172.16.0.0/15` as the address
3. Expand **Additional Options** and assign the resource group `office-network` — this group will be used in the access policy for the DevOps team
4. Click **Continue** to proceed to the **Access Control** tab
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-resource-1.png" alt="new-example-resource-1" className="imagewrapper"/>
</p>
### Create an access policy for the network resource
In the **Access Control** tab, click **Add Policy** to create a policy that grants the `DevOps` group full access to the `office-network` resource group.
Configure the policy fields as shown:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-resource-acl-1.png" alt="new-resource-acl-1" className="imagewrapper-big"/>
</p>
Click `Continue` twice, then click `Add Policy`:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-resource-acl-2.png" alt="new-resource-acl-2" className="imagewrapper-big"/>
</p>
Click **Add Resource** to save the resource with its policy.
### Add the DNS server resources
Add the first DNS server as a resource. Click `Add Resource` and in the **Resource** tab:
1. Enter the DNS server name and IP address `172.16.30.2`
2. Expand **Additional Options** and assign the resource group `office-dns-servers`
3. Click **Continue** to proceed to the **Access Control** tab
4. Skip adding a policy for now — click **Add Resource** to save without a policy (you will create a shared policy after adding both DNS servers)
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-resource-2.png" alt="new-example-resource-2" className="imagewrapper"/>
</p>
Repeat the same steps for the second DNS server at `172.17.100.2`, assigning it to the same `office-dns-servers` group:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-resource-3.png" alt="new-example-resource-3" className="imagewrapper"/>
</p>
### Create an access policy for DNS servers
Now that both DNS servers share the `office-dns-servers` resource group, create a single policy for both. From the network view, click **Add Policy** next to one of the DNS server resources.
Create a policy that grants the `All users` group access to the `office-dns-servers` resource group on UDP port 53 only:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-resource-acl-3.png" alt="new-resource-acl-3" className="imagewrapper-big"/>
</p>
Click `Continue` twice, then click `Add Policy`. Use a generic policy name to cover both DNS server addresses:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/add-example-resource-acl-4.png" alt="new-resource-acl-4" className="imagewrapper-big"/>
</p>
### View the network
After completing the wizard, the network appears in the Networks list:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/view-example-network-1.png" alt="view-example-network-1" className="imagewrapper-big"/>
</p>
Click the network name to view details:
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources/view-example-network-2.png" alt="view-example-network-2" className="imagewrapper-big"/>
</p>
From this view, you can edit or add resources and routing peers using the `Edit` buttons in each section.
You have now created a network with multiple resources that provide different access levels to different user groups within your organization.
## Get started
<p float="center" >
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
</p>
- Make sure to [star us on GitHub](https://github.com/netbirdio/netbird)
- Follow us [on X](https://x.com/netbird)
- Join our [Slack Channel](/slack-url)
- NetBird [latest release](https://github.com/netbirdio/netbird/releases) on GitHub

191
src/pages/manage/networks/use-cases/by-scenario/remote-worker-access.mdx
View File

@@ -1,191 +0,0 @@
import { Note } from '@/components/mdx'
# Remote Worker Access (VPN-to-Site)
This guide shows how to enable remote workers to securely access office resources using the Networks feature.
<Note>
For the mental model — see [How Routing Peers Work — Mental model](/manage/networks/how-routing-peers-work#mental-model-how-traffic-flows).
</Note>
## What You'll Achieve
After following this guide, employees will be able to access office servers, applications, and services while working remotely—without exposing those resources to the internet.
```
Remote Laptop ──────► NetBird Tunnel ──────► Routing Peer ──────► Office Server
(peer) (at office) (no NetBird)
```
## Prerequisites
- A [NetBird cloud account](https://app.netbird.io/) or [self-hosted instance](/selfhosted/selfhosted-quickstart)
- Admin access to office network infrastructure
- A server or VM at the office to serve as the routing peer
## Step 1: Connect a Remote Worker Device to NetBird
If you haven't already, install NetBird on a remote worker's 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 the device appears in the [NetBird dashboard](https://app.netbird.io/) under **Peers**
## Step 2: Add the Remote Worker to a User Group
1. In the **Peers** section of the dashboard, select the remote worker's device
2. Under **Assigned Groups**, add a new group: `remote-workers`
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/remote-worker-access/peer-remote-worker-assigned-group.png" alt="Add remote worker to group" className="imagewrapper"/>
</p>
## Step 3: Find Your Office Subnet
Before configuring NetBird, identify your office network's subnet.
**On your routing peer device, run:**
```bash
# Linux
ip route | grep -E "^[0-9]"
# Windows (PowerShell)
Get-NetRoute | Where-Object { $_.DestinationPrefix -like "*.*.*.*/*" }
```
Look for your local subnet, typically something like `10.0.0.0/24` or `192.168.1.0/24`.
## Step 4: Create a Network for Office Resources
1. Go to **Networks** in the NetBird dashboard
2. Click **Add Network**
3. Name it "Office LAN" and click **Save**
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/remote-worker-access/add-network-office-lan.png" alt="Add network" className="imagewrapper"/>
</p>
## Step 5: Add Your Office Subnet as a Resource
1. In your new network, click **Add Resource**
2. In the **Resource** tab, enter a name like "Office Subnet"
3. Enter your office subnet (e.g., `10.0.0.0/24`)
4. Expand **Additional Options** and under **Resource Groups**, create a group called `office-lan`
5. Click **Continue** to proceed to the **Access Control** tab
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/remote-worker-access/add-resource-office-subnet.png" alt="Add resource" className="imagewrapper"/>
</p>
<Note>
For more granular access, add specific server IPs instead of the entire subnet. For example, add `10.0.0.50/32` to only allow access to a specific file server.
</Note>
## Step 6: Create an Access Policy
1. In the **Access Control** tab, click **Add Policy**
2. Set **Source** to "`remote-workers`"
3. Set **Destination** to `office-lan`
4. Set **Protocol** based on needs (TCP for most apps, All for full access)
5. Name it "Remote Worker Office Access" and click **Add Policy**
6. Click **Add Resource** to save the resource with its policy
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/remote-worker-access/add-policy-remote-worker-office-access.png" alt="Create policy for remote worker office access" className="imagewrapper"/>
</p>
## Step 7: Set Up the Routing Peer
The routing peer forwards traffic from NetBird to your office network. Choose an always-on server at your office:
- A dedicated Linux VM
- A Windows Server
- A Docker container on an existing 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). Add `office-lan` to **Auto-assigned groups** and click **Create Setup Key**.
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/remote-worker-access/create-new-setup-key-office-lan.png" alt="Create setup key" className="imagewrapper"/>
</p>
<Note>
You can also add groups to peers manually after setup. Go to **Peers**, select the peer, and add groups under **Assigned Groups**.
</Note>
3. On your routing peer, run:
```bash
# Linux
curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --setup-key YOUR_SETUP_KEY
# Windows (PowerShell as Administrator)
Invoke-WebRequest -Uri "https://pkgs.netbird.io/install.ps1" -OutFile "install.ps1"; .\install.ps1
netbird up --setup-key YOUR_SETUP_KEY
```
4. In the Networks view, click **Add Routing Peer** on your Office LAN network
5. Select your new peer and click **Add Routing Peer**
## Step 8: Test the Connection
From the remote worker's laptop (connected outside the office network):
```bash
ping 10.0.0.1 # Your office router
ping 10.0.0.50 # Your file server or other device
```
Remote workers can now access office resources from any location.
## Step 9: Onboard Additional `remote-workers`
For additional remote workers:
1. Have employees install NetBird from [app.netbird.io/install](https://app.netbird.io/install)
2. After they connect, go to **Peers** and select their device
3. Under **Assigned Groups**, add them to the "`remote-workers`" group
Alternatively, create a setup key with "`remote-workers`" as an auto-assigned group for streamlined onboarding.
## Best Practices for Business Deployments
### Access Control
- Create specific groups for different access levels (e.g., `it-admins`, `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 via [Notifications](/manage/settings/notifications) to get alerted when a routing peer disconnects
- 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
**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
## Next Steps
- **Need Site-to-VPN or Site-to-Site?** If office systems need to initiate connections to remote workers, or you need to connect branch offices, see [Network Routes Use Cases](/manage/network-routes/use-cases)
- **Advanced configuration:** See [Advanced Configuration](/manage/network-routes/use-cases/by-configuration/advanced-configuration) for masquerade options and detailed access control

12
src/pages/manage/networks/use-cases/by-scenario/cloud-to-on-premise.mdx → src/pages/manage/networks/use-cases/cloud-to-on-premise.mdx
View File

@@ -43,7 +43,7 @@ Look for your local subnet, typically something like `10.100.0.0/24`.
3. Name it "On-Premise Data Center" and click **Save**
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/cloud-to-on-prem/add-network-on-prem-datacenter.png" alt="Add network" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/add-network-on-prem-datacenter.png" alt="Add network" className="imagewrapper"/>
</p>
## Step 3: Add Your Database as a Resource
@@ -55,7 +55,7 @@ Look for your local subnet, typically something like `10.100.0.0/24`.
5. Click **Continue** to proceed to the **Access Control** tab
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/cloud-to-on-prem/add-resource-database-servers.png" alt="Add resource" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/add-resource-database-servers.png" alt="Add resource" className="imagewrapper"/>
</p>
<Note>
@@ -73,7 +73,7 @@ For more granular access, add specific database IPs instead of the entire subnet
7. Click **Add Resource** to save the resource with its policy
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/cloud-to-on-prem/add-policy-on-prem-databases.png" alt="Add policy" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/add-policy-on-prem-databases.png" alt="Add policy" className="imagewrapper"/>
</p>
## Step 5: Set Up the Routing Peer On-Premise
@@ -84,7 +84,7 @@ The routing peer forwards traffic from NetBird to your data center network. Inst
2. Create a new setup key (one-time use recommended). Add `on-prem-databases` to **Auto-assigned groups** and click **Create Setup Key**.
<p>
<img src="/docs-static/img/manage/networks/use-cases/by-scenario/cloud-to-on-prem/create-new-setup-key-on-prem-db.png" alt="Create setup key" className="imagewrapper"/>
<img src="/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/create-new-setup-key-on-prem-db.png" alt="Create setup key" className="imagewrapper"/>
</p>
<Note>
@@ -216,5 +216,5 @@ Your cloud application can now securely access the on-premise database.
## Next Steps
- **Need Multi-Cloud Site-to-Site?** If you need to connect cloud VPCs across providers, see [Site-to-Site: Cloud](/manage/network-routes/use-cases/by-scenario/site-to-site-cloud)
- **Advanced configuration:** See [Advanced Configuration](/manage/network-routes/use-cases/by-configuration/advanced-configuration) for masquerade options and detailed access control
- **Need Multi-Cloud Site-to-Site?** If you need to connect cloud VPCs across providers, see [Site-to-Site](/manage/network-routes/use-cases/site-to-site)
- **Advanced configuration:** See [Advanced Configuration](/manage/network-routes/advanced-configuration) for masquerade options and detailed access control

89
src/pages/manage/networks/use-cases/index.mdx
View File

@@ -1,89 +0,0 @@
import { Tiles } from '@/components/Tiles'
import { Note } from '@/components/mdx'
# Networks Use Cases
These guides show how to use the [Networks](/manage/networks) feature for VPN-to-Site access—where NetBird peers access devices on remote networks that don't have NetBird installed.
## What is VPN-to-Site?
VPN-to-Site allows a device running NetBird (like your laptop) to access devices on a remote network (like your home or office) without installing NetBird on every device.
```
Your Laptop ──────► NetBird Tunnel ──────► Routing Peer ──────► Target Device
(peer) (peer) (no NetBird)
```
**Example scenarios:**
- Access your home NAS from a coffee shop
- Reach office servers while traveling
- Connect to IoT devices on a remote network
<Note>
Networks supports VPN-to-Site only. For Site-to-VPN (clientless devices initiating connections) or Site-to-Site (connecting two networks), use [Network Routes](/manage/network-routes/use-cases).
</Note>
<Tiles
title="By Scenario"
items={[
{
href: '/manage/networks/use-cases/by-scenario/access-home-devices',
name: 'Access Home Devices',
description: 'Access your NAS, home automation, and media servers from anywhere',
},
{
href: '/manage/networks/use-cases/by-scenario/remote-worker-access',
name: 'Remote Worker Access',
description: 'Enable employees to access office resources while working remotely',
},
{
href: '/manage/networks/use-cases/by-scenario/cloud-to-on-premise',
name: 'Cloud to On-Premise',
description: 'Connect cloud workloads to on-premise databases and services',
},
]}
/>
## Understanding Resource Types
In Networks, a **resource** represents something you want to make accessible through the VPN tunnel—whether that's a single server, an entire subnet, or a domain-based service. Resources are what your routing peers make reachable to authorized NetBird clients.
NetBird supports three types of resources:
- **IP resources** — Single IP addresses (`192.168.1.10`) or CIDR ranges (`172.16.0.0/16`). Use these when you know the exact IP addresses of your target devices or want to grant access to an entire subnet.
- **Domain resources** — Specific fully-qualified domain names like `app.example.com`. Use these when the target service has a stable hostname but its IP address may change (common with cloud load balancers or dynamic DNS).
- **Wildcard domain resources** — Domain patterns like `*.internal.company.com` that match all subdomains. Use these when you have many services under a shared domain and want to avoid creating individual resources for each one.
Each resource can have its own access policy, allowing you to grant different levels of access to different teams—for example, giving developers full access to a development subnet while restricting everyone else to specific services.
<Tiles
title="By Resource Type"
items={[
{
href: '/manage/networks/use-cases/by-resource-type/routing-traffic-to-multiple-resources',
name: 'Multiple IP Resources',
description: 'Route traffic to multiple IP resources with different access policies',
},
{
href: '/manage/networks/use-cases/by-resource-type/accessing-restricted-domain-resources',
name: 'Domain Resources',
description: 'Access restricted websites and domain-based resources',
},
{
href: '/manage/networks/use-cases/by-resource-type/accessing-entire-domains-within-networks',
name: 'Wildcard Domains',
description: 'Access entire domains using wildcard DNS routing',
},
]}
/>
## Need More Than VPN-to-Site?
If your scenario requires:
- Clientless devices initiating connections (Site-to-VPN)
- Two networks communicating with each other (Site-to-Site)
- Disabling masquerade for source IP preservation
See [Network Routes Use Cases](/manage/network-routes/use-cases) instead.

2
src/pages/manage/networks/use-cases/site-to-vpn.mdx
View File

@@ -365,7 +365,7 @@ changes if the peer is re-enrolled), and that `dnsmasq` is not bound to
- [Networks — Concept](/manage/networks)
- [Network Routes — Concept](/manage/network-routes)
- [Site-to-Site: Office Networks](/manage/network-routes/use-cases/by-scenario/site-to-site-office)
- [Site-to-Site](/manage/network-routes/use-cases/site-to-site)
- [Site-to-Site Overview](/use-cases/site-to-site)
## Appendix: Per-Service Port Forwarding

2
src/pages/manage/settings/ipv6.mdx
View File

@@ -50,7 +50,7 @@ Access control policies apply to both IPv4 and IPv6 traffic. When a peer has an
### Exit Nodes
When an exit node route (`0.0.0.0/0`) is configured and the peer supports IPv6, management automatically creates a matching `::/0` route. See [Exit Nodes](/manage/network-routes/use-cases/by-scenario/exit-nodes#ipv6-support) for details.
When an exit node route (`0.0.0.0/0`) is configured and the peer supports IPv6, management automatically creates a matching `::/0` route. See [Exit Nodes](/manage/network-routes/use-cases/exit-nodes#ipv6-support) for details.
### Network Routes

4
src/pages/use-cases/cloud/index.mdx
View File

@@ -40,12 +40,12 @@ For connecting cloud VPCs to on-premise networks, see the [Site-to-Site Connecti
description: 'Build distributed AI infrastructure across multiple clouds with ArgoCD and MicroK8s',
},
{
href: '/manage/networks/use-cases/by-scenario/cloud-to-on-premise',
href: '/manage/networks/use-cases/cloud-to-on-premise',
name: 'Cloud to On-Premise Access',
description: 'Connect cloud workloads to on-premise databases and services',
},
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-cloud',
href: '/manage/network-routes/use-cases/site-to-site',
name: 'Multi-Cloud Site-to-Site',
description: 'Bridge cloud VPCs across providers using Site-to-Site routing',
},

4
src/pages/use-cases/homelab/index.mdx
View File

@@ -25,12 +25,12 @@ For connecting entire home networks (accessing devices that don't have NetBird i
description: 'Run NetBird directly on your MikroTik router for whole-network connectivity',
},
{
href: '/manage/networks/use-cases/by-scenario/access-home-devices',
href: '/manage/networks/use-cases/access-home-devices',
name: 'Access Home Devices',
description: 'Set up VPN-to-Site access to reach home network devices from anywhere',
},
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-home',
href: '/manage/network-routes/use-cases/site-to-site',
name: 'Connect Home Networks',
description: 'Link multiple home networks together using Site-to-Site routing',
},

2
src/pages/use-cases/security/implement-zero-trust.mdx
View File

@@ -500,7 +500,7 @@ Broken DNS is the most common cause of "NetBird is broken" complaints. For every
Use routing peers and Networks when you need to reach private subnets (LAN, VPC, on-premises) rather than only NetBird overlay peers.
<Warning>
**Network Routes vs Networks:** Legacy [Network Routes](/manage/network-routes) bypass Access Control policies by default unless [Access Control Groups are explicitly configured](/manage/network-routes/use-cases/by-configuration/access-control). The newer [Networks](/manage/networks) feature (v0.35.0+) handles this automatically—resources only become visible to peers after a policy explicitly grants access. For Zero Trust implementations, we recommend using Networks instead of legacy Network Routes.
**Network Routes vs Networks:** Legacy [Network Routes](/manage/network-routes) bypass Access Control policies by default unless [Access Control Groups are explicitly configured](/manage/network-routes/access-control). The newer [Networks](/manage/networks) feature (v0.35.0+) handles this automatically—resources only become visible to peers after a policy explicitly grants access. For Zero Trust implementations, we recommend using Networks instead of legacy Network Routes.
</Warning>
### 5.1 Requirements for a routing peer

41
src/pages/use-cases/site-to-site/index.mdx
View File

@@ -74,19 +74,19 @@ Your Laptop ──────► NetBird Tunnel ──────► Exit Node
- Route traffic through a trusted network for compliance
- Mask your location for privacy
**Implementation:** Requires [Network Routes](/manage/network-routes/use-cases/by-scenario/exit-nodes)
**Implementation:** Requires [Network Routes](/manage/network-routes/use-cases/exit-nodes)
## Which Scenario Do I Need?
| I want to... | Scenario | Feature to Use |
|-------------|----------|----------------|
| Access home devices from my laptop | VPN-to-Site | [Networks](/manage/networks/use-cases/by-scenario/access-home-devices) |
| Access office resources while traveling | VPN-to-Site | [Networks](/manage/networks/use-cases/by-scenario/remote-worker-access) |
| Access home devices from my laptop | VPN-to-Site | [Networks](/manage/networks/use-cases/access-home-devices) |
| Access office resources while traveling | VPN-to-Site | [Networks](/manage/networks) |
| Let an office server connect to my laptop | Site-to-VPN | [Networks](/manage/networks/use-cases/site-to-vpn) |
| Connect two home networks together | Site-to-Site | [Network Routes](/manage/network-routes/use-cases/by-scenario/site-to-site-home) only |
| Link branch offices | Site-to-Site | [Network Routes](/manage/network-routes/use-cases/by-scenario/site-to-site-office) only |
| Bridge cloud VPC with on-premise network | Site-to-Site | [Network Routes](/manage/network-routes/use-cases/by-scenario/site-to-site-cloud) only |
| Route all internet traffic through a specific peer | Exit Node | [Network Routes](/manage/network-routes/use-cases/by-scenario/exit-nodes) only |
| Connect two home networks together | Site-to-Site | [Network Routes](/manage/network-routes/use-cases/site-to-site) only |
| Link branch offices | Site-to-Site | [Network Routes](/manage/network-routes/use-cases/site-to-site) only |
| Bridge cloud VPC with on-premise network | Site-to-Site | [Network Routes](/manage/network-routes/use-cases/site-to-site) only |
| Route all internet traffic through a specific peer | Exit Node | [Network Routes](/manage/network-routes/use-cases/exit-nodes) only |
## How It Works
@@ -101,17 +101,12 @@ All scenarios use a routing peer—a device running NetBird that forwards traffi
title="VPN-to-Site Guides (Networks)"
items={[
{
href: '/manage/networks/use-cases/by-scenario/access-home-devices',
href: '/manage/networks/use-cases/access-home-devices',
name: 'Access Home Devices',
description: 'Access your NAS, home automation, and media servers from anywhere',
},
{
href: '/manage/networks/use-cases/by-scenario/remote-worker-access',
name: 'Remote Worker Access',
description: 'Enable employees to access office resources while working remotely',
},
{
href: '/manage/networks/use-cases/by-scenario/cloud-to-on-premise',
href: '/manage/networks/use-cases/cloud-to-on-premise',
name: 'Cloud to On-Premise',
description: 'Connect cloud workloads to on-premise databases and services',
},
@@ -122,22 +117,12 @@ All scenarios use a routing peer—a device running NetBird that forwards traffi
title="Site-to-Site Guides (Network Routes)"
items={[
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-home',
name: 'Connect Home Networks',
description: 'Link multiple home networks so devices can communicate across locations',
href: '/manage/network-routes/use-cases/site-to-site',
name: 'Site-to-Site',
description: 'Connect two networks (home, office, or cloud) through routing peers at each end',
},
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-office',
name: 'Connect Office Networks',
description: 'Connect branch offices to headquarters and enable cross-site communication',
},
{
href: '/manage/network-routes/use-cases/by-scenario/site-to-site-cloud',
name: 'Connect Cloud Environments',
description: 'Bridge cloud VPCs across providers or connect cloud to on-premise',
},
{
href: '/manage/network-routes/use-cases/by-configuration/advanced-configuration',
href: '/manage/network-routes/advanced-configuration',
name: 'Advanced Configuration',
description: 'Masquerade options, ACL Groups, and troubleshooting',
},