some file

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. This guide builds it with Networks, where each site is a Resource gated by its own Policy.

Architecture

Site A device ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Site B device
 (no NetBird)       (peer)                              (peer)         (no NetBird)

Networks is the recommended way to build site-to-site. It has per-Resource access control, is Zero Trust by default, and is the actively developed system.

Use Network Routes instead only when you need site-to-site without any Policy gating traffic — the legacy "wide open" mode with empty Access Control Groups. Networks requires at least one Policy per Resource and has no equivalent.

For the reverse — clientless devices at a site initiating connections to NetBird peers — see Site-to-VPN.

Prerequisites

  • An always-on device at each site to act as the routing peer
  • Different subnets at each site. If both sites use the same range (e.g. 192.168.1.0/24), see 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. Go to 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

You can also assign groups manually after the peer connects, under Peers → select peer → Assigned Groups.

Step 2: Install NetBird on the routing peers

On each site's routing peer:

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

Step 3: Create a Network for each site

Each site becomes its own Network: a Resource for that site's subnet, served by that site's routing peers.

Network A:

  1. Go to Networks → Add Network, name it site-a, and click Create Network
  2. Inside the network, click Add Resource:
    • Enter a name like site-a-subnet
    • Enter the address 10.0.0.0/24 (a subnet, or a single host like 10.0.0.50/32)
    • Expand Additional Options and under Resource Groups, create a group called site-a-cidr (this group represents the subnet for use in policies)
  3. Click Add Routing Peer, select the site-a-routers group, and leave Masquerade enabled (the default)

Leave Masquerade enabled on both routing peers. NetBird's tunnel drops traffic whose source isn't the peer's NetBird IP, so Masquerade is what makes site-to-site work — disabling it on a routing peer breaks the flow. Masquerade is enabled by default everywhere, and the toggle to turn it off only exists on Linux.

NetBird only performs the required outbound SNAT itself on Linux routing peers. Other platforms (OPNsense and pfSense are common examples) don't do this SNAT unless you configure it manually, so use a Linux routing peer for site-to-site.

Network B: repeat the steps — name site-b, Resource address 10.1.0.0/24 with group site-b-cidr, and routing peer group site-b-routers.

Step 4: Create access control policies

Networks requires a Policy on every Resource — without one, the dashboard will not allow access to it. Add one Policy per Network:

  • Network A's Resource: Source Groups = site-b-routers → destination = the site-a-subnet Resource
  • Network B's Resource: Source Groups = site-a-routers → destination = the site-b-subnet Resource

Tighten by protocol/port if needed; use All to allow any.

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:

sudo ip route add 10.1.0.0/24 via 10.0.0.50

Windows (PowerShell, persistent):

route -p add 10.1.0.0 mask 255.255.255.0 10.0.0.50

The Linux ip route add form above applies only until the next reboot. For persistent Linux routes (Netplan or systemd-networkd), follow the same pattern shown in Persistent configuration, substituting your remote site's CIDR (10.1.0.0/24 in this example) for the destination shown there. The Windows route -p add form is already persistent.

Repeat this on the other site with the values swapped, so Site B's router or devices know to reach 10.0.0.0/24 via the local Site B routing peer. Bidirectional site-to-site needs the static routes on both sides.

This step assumes Masquerade is enabled on both routing peers (the default in Step 3). Site-to-site over Networks requires Masquerade to be on — disabling it on a routing peer causes the WireGuard tunnel to drop traffic whose source isn't the peer's NetBird IP, so source-IP preservation isn't currently supported for site-to-site. If you need to preserve source IPs end to end, use the Network Routes site-to-site setup instead, which supports running with Masquerade disabled.

Step 6: Verify

From Site A, ping a device at Site B:

ping 10.1.0.100

Reverse from Site B to confirm both directions work. The destination sees the connection coming from its local routing peer's LAN IP — source IPs are masqueraded at both routing peers.

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