Exit nodes, routes & split tunnel

By default QuickZTNA connects your devices directly to each other. Three features extend that: exit nodes (egress through a peer), subnet routes (reach non-QuickZTNA hosts behind a peer), and split tunneling (keep some traffic off the tunnel).

Exit nodes

An exit node routes a device’s traffic out through a chosen peer — useful for a stable egress IP or reaching region-locked resources.

ztna exit-node list                  # available (approved) exit nodes
ztna exit-node suggest               # the recommended one
ztna set --exit-node 100.64.0.9      # route traffic through that peer
ztna set --exit-node auto            # let QuickZTNA pick
ztna set --exit-node-allow-lan-access # keep your local LAN reachable
ztna set --exit-node off             # stop using an exit node

A machine offers itself as an exit node with ztna up --advertise-exit-node, but it only becomes usable once an admin approves it (see the admin access-control guide).

Subnet routes

A subnet route lets peers reach hosts that aren’t running QuickZTNA, by going through a device that is on their network.

• Advertise a subnet from a device on that network:

  sudo ztna up --advertise-routes 10.0.0.0/24,192.168.1.0/24

  Advertised routes are inert until an admin approves them. View them with ztna route list.

• Accept approved routes on a device that should use them:

  ztna set --accept-routes          # or: ztna up --accept-routes

Subnet routing on the gateway side is a Linux capability (ztna up --gateway for a headless subnet gateway).

Split tunneling

Split tunneling keeps specific destinations off the QuickZTNA tunnel (they use your normal network path). Inspect the current exclusions:

ztna split-tunnel list      # CIDRs excluded from the tunnel

Next

• Connecting & everyday commands — status, peers, DNS, profiles.
• Admin: access control — approving routes and exit nodes.
• CLI reference — every flag for up, set, route, and exit-node.