Configuring Exit Nodes for Internet Traffic

Updated August 17, 2026

Exit nodes route all internet-bound traffic from your devices through a designated routing peer. This guide explains how to configure default routes for internet traffic.

Concepts

Default Routes

A default route (0.0.0.0/0 for IPv4) directs all internet traffic through a designated routing peer.

When IPv6 overlay addressing is enabled for the peer, the management server automatically creates a matching ::/0 route so that both IPv4 and IPv6 internet traffic flow through the exit node. Peers without IPv6 enabled have their IPv6 traffic blocked to prevent leakage.

Routing Peer

The routing peer acts as the exit node for internet traffic. It applies masquerading so that traffic appears to originate from the routing peer's public IP address.

Distribution Groups

Peers in the distribution groups send their internet traffic through the routing peer once it connects.

Exit Node Selection and Auto Apply

Auto Apply answers one question: when a device receives an exit node, does it start using it immediately, or does it wait for the user to turn it on?

• Auto Apply enabled (the default): devices in the distribution groups start routing internet traffic through the exit node as soon as they receive it. Users do not have to do anything, and most will not notice.
• Auto Apply disabled: the exit node appears as an option in the user's NetBird menu, like an offered network they have not joined. Nothing changes until the user selects it there.

In both cases the user's own choice wins. A user who deselects the exit node on their device stays off it even with Auto Apply enabled, and a user who selects it manually stays on it. Auto Apply sets the starting position of the switch on each device; it is not a lock. It cannot enforce the exit node against a user's explicit choice.

Existing Exit Node Routes

Exit node routes created before the Auto Apply feature was introduced are treated as having Auto Apply enabled. This preserves the previous behavior where exit nodes were applied automatically.

Clients running v0.55.0 or later auto-apply these routes unless the user has explicitly selected or deselected an exit node. Administrators can change the Auto Apply setting at any time.

Configuration Steps

1. Open the Servers list

Navigate to the NetBird dashboard and open Peers (exit nodes are typically unattended machines like a VPS, router, or always-on host).

2. Select the Routing Peer

Choose the peer that will serve as your exit node.

3. Configure the Exit Node

Click Add Exit Node. In the dialog, assign one or more distribution groups to specify which peers should use this exit node.

To make the exit node available without automatic activation, disable Auto Apply. Users can then enable it manually.

Click Add Exit Node to complete the configuration. Masquerading is enabled by default.

4. Verify the Configuration

Check the peer view to confirm the routing peer is marked as an exit node.

5. Configure DNS

Add a DNS server with the match domain set to ALL. Local DNS servers may not be accessible from the routing peer, and this also prevents DNS-based location leaks.

See Manage DNS in your network for details.

Regional Exit Nodes

A single exit node forces every user through one location: a user in Florida whose only exit node sits in California sends all internet traffic across the country and back. If your users are spread across regions, you want each device to exit near itself.

You get this by adding one routing peer per region to the same exit node with the same metric. When metrics are equal, each device measures its latency to every exit node and picks the lowest one, which in practice means the nearest one. With different metrics, you get primary/failover instead, so keep them equal for regional distribution.

The running example: an exit node in us-east and one in us-west, users on both coasts.

1. Deploy a routing peer per region

Set up one routing peer in each region as described in the configuration steps above. Both need masquerading and a stable internet path.

2. Add both peers to the same exit node

In the exit node's configuration, add both routing peers and leave the metric identical on both. Adding them as two separate exit node entries does not work: metrics and nearest-peer selection only apply between routing peers of the same route, so separate entries give every device both default routes with no coordinated selection.

The finished state: one exit node entry, both regional routing peers under it with the same metric, and the distribution group on each.

3. Keep the distribution group and access policy scoped

Use a dedicated distribution group for the devices that should full-tunnel rather than the built-in All group, and keep the access policy one-directional from that group to the routing peers. Every device in the distribution group sends all of its internet traffic through whichever exit node it selects.

The policy that makes the exit nodes reachable: the distribution group as the source, the routing peers' group as the destination, one direction only.

4. Verify

On an east-coast device, run netbird status -d: the peer carrying the 0.0.0.0/0 route is the selected exit node, shown on its Networks line. Then confirm the egress path by checking the device's public IP against the us-east exit node's public IP. A west-coast device should show the us-west peer instead.

What this does and does not do

This is nearest-exit selection plus automatic failover, not load balancing: each device follows its own lowest-latency exit node, and traffic is not spread evenly across the exit nodes. See Latency switching for the selection mechanism.

Latency-based selection is also not a guarantee of which exit node a given user lands on. If a rule must always hold, such as certain users always exiting in a specific country, use separate exit nodes with per-group distribution, or posture checks as in Geo-Based Exit Node Routing below.

Traffic to your own sites is unaffected by any of this: routes to specific internal ranges are more specific than 0.0.0.0/0, so devices reach those resources directly through the routing peer that advertises them, regardless of which exit node carries their internet traffic.

Geo-Based Exit Node Routing

Some compliance setups require a device's location to decide its tunnel mode. A common example: company devices must send all internet traffic through a corporate exit node while traveling abroad, but keep a normal split tunnel at home, where only internal resources go through NetBird.

You can build this with a Country and Region posture check attached to the access policy of a 0.0.0.0/0 Network resource. In the Networks model, a posture check on the access policy controls whether a peer receives the resource's routes at all. Peers that pass the check receive the default route and switch to a full tunnel. Peers that fail it never receive the route and keep their split tunnel, with direct internet access and all other NetBird resources working as before. When a peer's location or the check itself changes, connected peers converge to the new state within about a minute, without reconnecting.

The following example builds this goal: any device outside the United States sends all its internet traffic through the exit node, while devices inside the US keep their split tunnel. Traveling employees' devices are in the group remote-workers, and the exit node peer is in the group exit-nodes.

1. Create the Posture Check

Navigate to Access Control → Posture Checks, click Add Posture Check, and select Country and Region. On the Block tab, add United States, then save the check as "Outside the US".

Peers located in a blocked country fail the check, so the full-tunnel policy below stops applying to them and they keep their split tunnel. Peers anywhere else pass the check and get the full tunnel. NetBird determines the location from the public IP the peer uses to reach the management service, resolved with MaxMind's GeoLite2 City database, and shows it as country and city on the peer in the dashboard. On self-hosted deployments, the management server needs the database configured; see Geolocation Database.

2. Create the Network Resource

Navigate to Networks and create a network for the location that hosts your exit node, for example us-datacenter, or reuse an existing network if the exit node peer already routes one. Add a resource named internet-egress with the address 0.0.0.0/0, optionally assign it to a new group internet-egress, and add your exit node peer as the routing peer. Keep Masquerade enabled: without it, forwarded traffic leaves the exit node with the device's overlay IP as its source address, and replies never find their way back.

3. Create the Access Policy

Navigate to Access Control → Policies and add a policy from remote-workers to the internet-egress group (or the resource directly, if you skipped the group), protocol ALL. Before saving, open Posture Checks, browse for "Outside the US", and attach it.

This policy is all the exit node needs to forward internet traffic; no additional policy to the routing peer itself is required.

Also set a DNS server with match domain ALL; see Configure DNS above. Without it, devices keep sending DNS queries to their local resolver outside the tunnel, so a full-tunnel device still reveals its location through DNS even though all other traffic is tunneled. The nameserver applies to the whole group, and both tunnel modes handle it correctly: full-tunnel devices reach it through the exit node, while split-tunnel devices reach the same nameserver over their normal direct path. Resolution keeps working on both.

4. Verify

On a device outside the US, run netbird networks ls and confirm the internet-egress network is selected. Then check the device's public IP (for example with curl ifconfig.me): it should be the exit node's IP.

On a device inside the US, the same checks show no internet-egress network, the device's own public IP, and working internet. Internal NetBird resources remain reachable on both devices.

Performance Expectations

An exit node carries each device's entire internet traffic through a single WireGuard tunnel, and a single tunnel is processed largely on one CPU core of the exit node. This caps each device's throughput at single-tunnel speed: typically a few Gbps on a modern server CPU running Linux kernel WireGuard. The exact figure depends on the exit node's per-core speed, the tunnel MTU, and traffic direction (see the benchmark assumptions), but it does not grow with parallel streams.

Because this is a fixed cap rather than a percentage cost, what you observe depends on your internet line rate:

• On links up to about 1 Gbps, an exit node typically adds little to no throughput loss.
• On multi-gigabit links, full-tunnel throughput tops out at the tunnel cap, so a large relative drop against a 5 or 10 Gbps line is expected behavior, not a misconfiguration.

A common mistake is scaling the wrong dimension: adding CPU cores to the exit node or running more parallel streams on a device does not raise that device's ceiling, because the tunnel still serializes on one core. Per-core CPU speed does raise it, so for fast individual clients pick the exit node hardware with the fastest single-core performance available. More cores raise the aggregate capacity across many devices; see Sizing Routing Peers for measured per-size numbers.

If throughput lands well below a few Gbps, check these before resizing hardware:

• Relayed connection. Run netbird status -d on the device and confirm the connection to the exit node shows type P2P. Relayed traffic is significantly slower than a direct connection.
• Userspace WireGuard. Devices on Windows and macOS, and peers running in userspace mode, reach well below kernel-mode numbers.
• Exit node limits. If the connection is P2P and both ends run kernel WireGuard, check the exit node's CPU load, the tunnel MTU, and the traffic direction against Tuning for more throughput.

IPv6 Support

When IPv6 is enabled in your account settings and the exit node peer supports it, the management server automatically generates a ::/0 route alongside the 0.0.0.0/0 route. No additional configuration is needed.

For peers that do not have IPv6 enabled (older clients, or accounts with IPv6 disabled), IPv6 traffic is blocked at the tunnel interface to prevent unintentional leakage through the exit node.

You can disable IPv6 on individual clients with the --disable-ipv6 flag:

netbird up --disable-ipv6

See IPv6 Overlay Addressing for more details on enabling IPv6 for your account.

High Availability

Exit nodes support high availability configurations. With equal metrics you get nearest-exit selection as described in Regional Exit Nodes; with different metrics you get primary/failover. See Creating Highly Available Routes for more information.