diff --git a/src/pages/use-cases/remote-access/exit-nodes.mdx b/src/pages/use-cases/remote-access/exit-nodes.mdx index e98140404..4aba92eec 100644 --- a/src/pages/use-cases/remote-access/exit-nodes.mdx +++ b/src/pages/use-cases/remote-access/exit-nodes.mdx @@ -158,11 +158,13 @@ Traffic to your own sites is unaffected by any of this: routes to specific inter 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](/manage/access-control/posture-checks#country-and-region) attached to the access policy of a `0.0.0.0/0` [Network resource](/manage/networks). 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. +You can build this with a [Country and Region posture check](/manage/access-control/posture-checks#country-and-region) attached to the access policy that connects your users' group to the exit node's group. NetBird distributes a route only from a routing peer the device is allowed to connect to. When the posture check fails, the policy stops applying, the exit node peer drops out of the device's peer list, and the default route is withdrawn with it. - - Build this in **Networks**. Adding a posture check to an exit node created as a [Route](/manage/network-routes) does not work: the default route still installs on every peer in the distribution groups, and devices failing the check lose internet entirely. - +Devices that pass the check receive the default route and switch to a full tunnel. Devices that fail it do not receive the route, or lose it, and keep their split tunnel, with direct internet access and all other NetBird resources working as before. When the check changes, connected devices converge to the new state within about a minute, without reconnecting. A device is also re-evaluated each time it reconnects. + + + Attach the posture check to the policy between the users and the exit node peer, not to the exit node route's **Access Control Groups**. A check in that position only blocks traffic at the exit node: the default route still installs on every device in the distribution groups, and a device failing the check loses internet entirely. + 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`. @@ -170,29 +172,31 @@ The following example builds this goal: any device outside the United States sen 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](/selfhosted/maintenance/geo-support). +Peers located in a blocked country fail the check, so the 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](/selfhosted/maintenance/geo-support). -### 2. Create the Network Resource +### 2. Configure the Exit Node -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. - - - If you create the resource through the [API](/ipa/resources/networks), set `"enabled": true` explicitly on the resource and `"masquerade": true` on the routing peer. The API reference marks both fields as required; when omitted, the API currently defaults them to disabled. - +Add the exit node as described in the [configuration steps](#configuration-steps) above, with `remote-workers` as the distribution group and **Auto Apply** enabled, so the full tunnel activates on its own whenever the route arrives. Leave the route's **Access Control Groups** empty; the policy in the next step does the gating. ### 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. +Navigate to **Access Control** → **Policies** and add a policy from `remote-workers` to `exit-nodes`, 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. +This must be the only policy that connects `remote-workers` to the exit node peer. If another policy also allows that connection, for example a broad **All** to **All** rule, the peer stays reachable through it, the route keeps arriving, and the posture check has no effect on the tunnel mode. Scope any other policies so they do not cover the exit node peer. Also set a DNS server with match domain `ALL`; see [Configure DNS](#5-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 outside the US, run `netbird networks ls` and confirm the exit node is listed and 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 exit node entry, the device's own public IP, and working internet. `netbird status` no longer lists the exit node peer. Internal NetBird resources remain reachable on both devices. + +### Switching the Exit Node Off Inside the Office + +The same shape solves a different everyday need: keep NetBird connected while a laptop is in the office, but send internet traffic through the office gateway instead of the exit node, and switch the exit node back on when the laptop leaves. Replace the Country and Region check with a [Peer Network Range](/manage/access-control/posture-checks#peer-network-range) check with the **Block** action and your office subnet, for example `192.168.1.0/24`, and attach it to the same policy. While the laptop's own address is inside that range, the exit node is withdrawn and the operating system uses its local gateway. When the laptop connects from anywhere else, the route returns and Auto Apply activates the exit node again. -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. +The check compares the device's local interface addresses, as reported when the client connects, and the public IP it connects from. A local interface counts as its whole subnet, so the range you enter must be at least as wide as the netmask the office hands out: `192.168.1.0/24` matches a device on that `/24`, while a `/32` or a `/25` never will. See [Peer Network Range](/manage/access-control/posture-checks#peer-network-range) for the matching rules. Windows and macOS clients reconnect on their own when the network changes, so the check is re-evaluated within seconds of the laptop moving. Linux clients do not, and are re-evaluated on their next `netbird up` or service restart. Android clients cannot report local ranges; see [Peer Network Range Check on Android](/manage/access-control/posture-checks#peer-network-range-check-on-android). ## Enforcing the Exit Node on Managed Devices