---
title: "Routes"
description: "Set up subnet routers and exit nodes, approve routes by hand or with auto approvers, mark global exit nodes in failover order, and route per region."
---

Slopscale supports route advertising and can be used to manage [subnet
routers](https://tailscale.com/docs/features/subnet-routers) and [exit
nodes](https://tailscale.com/docs/features/exit-nodes) for a tailnet.

- [Subnet routers](#subnet-router) may be used to connect an existing network such as a virtual
  private cloud or an on-premise network with your tailnet. Use a subnet router to access devices where Tailscale can't
  be installed or to gradually rollout Tailscale.
- [Exit nodes](#exit-node) can be used to route all Internet traffic for another Tailscale
  node. Use it to securely access the Internet on an untrusted Wi-Fi or to access online services that expect traffic
  from a specific IP address.

To hand a subnet or exit node to some machines only, with the approval made
for you, see [Networks](/slopscale/ref/networks).

## Subnet router

The setup of a subnet router requires double opt-in, once from a subnet router and once on the control server to allow
its use within the tailnet. Optionally, use [`autoApprovers` to automatically approve routes from a subnet
router](#automatically-approve-routes-of-a-subnet-router).

### Setup a subnet router

#### Configure a node as subnet router

Register a node and advertise the routes it should handle as comma separated list:

```console
$ sudo tailscale up --login-server <YOUR_SLOPSCALE_URL> --advertise-routes=10.0.0.0/8,192.168.0.0/24
```

If the node is already registered, it can advertise new routes or update previously announced routes with:

```console
$ sudo tailscale set --advertise-routes=10.0.0.0/8,192.168.0.0/24
```

Finally, [enable IP forwarding](#enable-ip-forwarding) to route traffic.

#### Enable the subnet router on the control server

The routes of a tailnet can be displayed with the `slopscale nodes list-routes` command. A subnet router with the
hostname `myrouter` announced the IPv4 networks `10.0.0.0/8` and `192.168.0.0/24`. Those need to be approved before they
can be used.

```console
$ slopscale nodes list-routes
ID | Hostname | Approved | Available      | Serving (Primary)
1  | myrouter |          | 10.0.0.0/8     |
   |          |          | 192.168.0.0/24 |
```

Approve all desired routes of a subnet router by specifying them as comma separated list:

```console
$ slopscale nodes approve-routes --identifier 1 --routes 10.0.0.0/8,192.168.0.0/24
Node updated
```

The node `myrouter` can now route the IPv4 networks `10.0.0.0/8` and `192.168.0.0/24` for the tailnet.

```console
$ slopscale nodes list-routes
ID | Hostname | Approved       | Available      | Serving (Primary)
1  | myrouter | 10.0.0.0/8     | 10.0.0.0/8     | 10.0.0.0/8
   |          | 192.168.0.0/24 | 192.168.0.0/24 | 192.168.0.0/24
```

#### Use the subnet router

To accept routes advertised by a subnet router on a node:

```console
$ sudo tailscale set --accept-routes
```

See the official [Tailscale
documentation](https://tailscale.com/docs/features/subnet-routers#use-your-subnet-routes-from-other-devices) for how to
use a subnet router on different operating systems.

### Restrict the use of a subnet router with a policy

The routes announced by subnet routers are available to the nodes in a tailnet. By default, without a policy enabled,
all nodes can accept and use such routes. Configure a policy to explicitly manage who can use routes.

The policy snippet below defines three hosts, a subnet router `router`, a regular node `node` and `service.example.net`
as internal service that can be reached via a route on the subnet router `router`. It allows the node `node` to access
`service.example.net` on port 80 and 443 which is reachable via the subnet router. Access to the subnet router itself is
denied.

```json title="Access the routes of a subnet router without the subnet router itself"
{
  "hosts": {
    // the router is not referenced but announces 192.168.0.0/24
    "router": "100.64.0.1/32",
    "node": "100.64.0.2/32",
    "service.example.net": "192.168.0.1/32"
  },
  "grants": [
    {
      "src": ["node"],
      "dst": ["service.example.net"],
      "ip": ["80,443"]
    }
  ]
}
```

### Automatically approve routes of a subnet router

The initial setup of a subnet router usually requires manual approval of their announced routes on the control server
before they can be used by a node in a tailnet. Slopscale supports the `autoApprovers` section in a policy to automate
the approval of routes served with a subnet router.

The policy snippet below defines the tag `tag:router` owned by the user `alice`. This tag is used for `routes` in the
`autoApprovers` section. The IPv4 route `192.168.0.0/24` is automatically approved once announced by a subnet router
that advertises the tag `tag:router`.

```json title="Subnet routers tagged with tag:router are automatically approved"
{
  "tagOwners": {
    "tag:router": ["alice@"]
  },
  "autoApprovers": {
    "routes": {
      "192.168.0.0/24": ["tag:router"]
    }
  },
  "grants": [
    // more rules
  ]
}
```

Advertise the route `192.168.0.0/24` from a subnet router that also advertises the tag `tag:router` when joining the tailnet:

```console
$ sudo tailscale up --login-server <YOUR_SLOPSCALE_URL> --advertise-tags tag:router --advertise-routes 192.168.0.0/24
```

See the [official Tailscale
documentation](https://tailscale.com/docs/reference/syntax/policy-file#auto-approvers) for more information on auto
approvers.

## Exit node

The setup of an exit node requires double opt-in, once from an exit node and once on the control server to allow its use
within the tailnet. Optionally, use [`autoApprovers` to automatically approve an exit
node](#automatically-approve-an-exit-node-with-auto-approvers).

### Suggested exit nodes

Every approved exit node is suggested to the other clients: it carries the
`suggest-exit-node` capability on their view of it, as it does on Tailscale's
own control plane, so `tailscale exit-node suggest` picks one and the Apple
clients list them. Nothing needs to be written in the policy for this. To
suggest only some of the exit nodes, mark them as global exit nodes.

### Global exit node

An administrator can mark an exit node as the one every client is told to
prefer, with no policy involved:

```console
$ slopscale nodes global-exit-node --identifier 7
$ slopscale nodes global-exit-node --identifier 7 --revoke
```

Marking approves the node's exit routes, so it serves as an exit node as soon
as it advertises them. While at least one node is marked, only the marked
nodes carry `suggest-exit-node` on the other clients' view of them, and every
node carries `auto-exit-node`, the way Tailscale's exit node suggestions work:
`tailscale exit-node suggest` names a marked node, and a client set to use an
exit node automatically picks it:

```console
$ sudo tailscale set --exit-node=auto:any
```

The control server cannot switch a client's exit-node use on by itself; that
stays with the device (or its MDM policy). Several nodes may be marked, in
which case each client picks the closest by DERP region. The same operation is
`POST /api/v1/node/{id}/global-exit-node` with an optional `{"enabled": false}` body, and a node's `globalExitNode` field reports the mark. Clearing
the mark keeps the approved routes, so the node stays a suggested exit node
like any other.

### Exit node failover in a fixed order

To have every client use one exit node and fall back to another only while
the first is offline, mark both and give them a priority, the highest first:

```console
$ slopscale nodes global-exit-node --identifier 7 --priority 20   # office
$ slopscale nodes global-exit-node --identifier 8 --priority 10   # data center
```

While any global exit node has a priority, every node carries the
`traffic-steering` capability and each marked node's peer view carries its
priority as `Hostinfo.Location.Priority`, the way Tailscale's own control
plane steers traffic. A client set to `--exit-node=auto:any` then picks the
highest priority that is online instead of the closest by DERP region,
moves to the next one when it goes offline, and returns as soon as the
higher one is back. Nodes with the same priority, 0 included, are split by
each client on its own (a stable hash of the two node ids, not DERP
latency), so give every node its own value when the order matters. Nodes
with priority 0 come last. Clients older than Tailscale 1.86 ignore the
priority and keep picking by DERP region.

The priority is part of the mark: marking without `--priority` keeps the
current one, clearing the mark resets it to 0, and the same field is
`priority` in the API body and `exitNodePriority` on the node. In the
console, the machine's routes tab has the field under "Global exit node",
and the overview tile names the node clients take first.

### Setup an exit node

#### Configure a node as exit node

Register a node and make it advertise itself as an exit node:

```console
$ sudo tailscale up --login-server <YOUR_SLOPSCALE_URL> --advertise-exit-node
```

If the node is already registered, it can advertise exit capabilities like this:

```console
$ sudo tailscale set --advertise-exit-node
```

Finally, [enable IP forwarding](#enable-ip-forwarding) to route traffic.

#### Enable the exit node on the control server

The routes of a tailnet can be displayed with the `slopscale nodes list-routes` command. An exit node can be recognized
by its announced routes: `0.0.0.0/0` for IPv4 and `::/0` for IPv6. The exit node with the hostname `myexit` is already
available, but needs to be approved:

```console
$ slopscale nodes list-routes
ID | Hostname | Approved | Available | Serving (Primary)
1  | myexit   |          | 0.0.0.0/0 |
   |          |          | ::/0      |
```

For exit nodes, it is sufficient to approve either the IPv4 or IPv6 route. The other will be approved automatically.

```console
$ slopscale nodes approve-routes --identifier 1 --routes 0.0.0.0/0
Node updated
```

The node `myexit` is now approved as exit node for the tailnet:

```console
$ slopscale nodes list-routes
ID | Hostname | Approved  | Available | Serving (Primary)
1  | myexit   | 0.0.0.0/0 | 0.0.0.0/0 | 0.0.0.0/0
   |          | ::/0      | ::/0      | ::/0
```

#### Use the exit node

The exit node can now be used on a node with:

```console
$ sudo tailscale set --exit-node myexit
```

See the official [Tailscale documentation](https://tailscale.com/docs/features/exit-nodes#use-the-exit-node)
for how to use an exit node on different operating systems.

### Restrict the use of an exit node with a policy

An exit node is offered to all nodes in a tailnet. By default, without a policy enabled, all nodes in a tailnet can
select and use an exit node. Configure `autogroup:internet` in a policy rule to restrict who can use _any_ of the
available exit nodes.

```json title="Example use of autogroup:internet"
{
  "grants": [
    {
      "src": ["..."],
      "dst": ["autogroup:internet"],
      "ip": ["*"]
    }
  ]
}
```

### Restrict access to exit nodes per user or group

A user can use _any_ of the available exit nodes with `autogroup:internet`. Alternatively, the policy snippet below
assigns each user a specific exit node while hiding all other exit nodes. The user `alice` can only use an exit node
tagged with `tag:exit1` while user `bob` can only use an exit node tagged with `tag:exit2`.

```json title="Assign each user a dedicated exit node"
{
  "tagOwners": {
    "tag:exit1": ["alice@"],
    "tag:exit2": ["bob@"]
  },
  "grants": [
    {
      "src": ["alice@"],
      "dst": ["autogroup:internet"],
      "via": ["tag:exit1"],
      "ip": ["*"]
    },
    {
      "src": ["bob@"],
      "dst": ["autogroup:internet"],
      "via": ["tag:exit2"],
      "ip": ["*"]
    }
  ]
}
```

### Automatically approve an exit node with auto approvers

The initial setup of an exit node usually requires manual approval on the control server before it can be used by a node
in a tailnet. Slopscale supports the `autoApprovers` section in a policy to automate the approval of a new exit node as
soon as it joins the tailnet.

The policy snippet below defines the tag `tag:exit` owned by the user `alice`. This tag is used for the `exitNode` entry
in the `autoApprovers` section. A new exit node that advertises the tag `tag:exit` is automatically approved:

```json title="Exit nodes tagged with tag:exit are automatically approved"
{
  "tagOwners": {
    "tag:exit": ["alice@"]
  },
  "autoApprovers": {
    "exitNode": ["tag:exit"]
  },
  "grants": [
    // more rules
  ]
}
```

Advertise a node as exit node and also advertise the tag `tag:exit` when joining the tailnet:

```console
$ sudo tailscale up --login-server <YOUR_SLOPSCALE_URL> --advertise-tags tag:exit --advertise-exit-node
```

See the [official Tailscale documentation](https://tailscale.com/docs/reference/syntax/policy-file#autoapprovers)
for more information on auto approvers.

## High availability

Slopscale supports high availability routing. Multiple subnet routers with overlapping routes or multiple exit nodes can
be used to provide high availability for users. If one router node goes offline, another one can serve the same routes
to clients. See the official [Tailscale documentation on high
availability](https://tailscale.com/docs/how-to/set-up-high-availability#subnet-router-high-availability) for details.

This feature is enabled by default when at least two nodes advertise the same prefix. See the configuration options
`node.routes.ha` in the [configuration file](/slopscale/ref/configuration) for details.

### Regional routing

When the routers for a prefix sit in different DERP regions, slopscale steers each client to the router that shares
its region, as Tailscale's [regional routing](https://tailscale.com/blog/regional-routing) does. A region is the DERP
region a node reports as its home, so it needs no configuration beyond a [DERP map](/slopscale/ref/derp) with more than one
region. A client whose region has no healthy router for the prefix, or that has not reported a region, uses the
tailnet-wide primary, which is the lowest node ID among the healthy routers. A client that changes region is steered
again. The `/debug/routes` endpoint lists the per-region primaries next to the tailnet-wide ones.

## Troubleshooting

### Enable IP forwarding

A subnet router or exit node is routing traffic on behalf of other nodes and thus requires IP forwarding. Check the
official [Tailscale documentation](https://tailscale.com/docs/features/subnet-routers#enable-ip-forwarding) for how to
enable IP forwarding.