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)

Prerequisites

• A NetBird cloud account or self-hosted instance
• 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

Step 2: Deploy Routing Peers

Install NetBird on a server at each location:

At headquarters:

curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --setup-key YOUR_HQ_SETUP_KEY

At branch office:

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

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

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)

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:

# 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):

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

ping 10.1.0.1  # Branch router
ping 10.1.0.100  # Branch server

From a device at branch office:

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 to initiate connections to remote workers (monitoring, management tools, etc.).

Configuration

1. Create a network route for the office network (as above)
2. On the office system that needs to reach remote workers, add a route to the NetBird network:

# Route to NetBird network through the routing peer
sudo ip route add 100.64.0.0/10 via 10.0.0.50

Where 10.0.0.50 is the routing peer's office IP.

3. Create two access policies allowing traffic in both directions

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 to verify device compliance
• Use Activity Logging 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 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.