Files
tsunagi/docs/exit-node.md
T
UltradesuandClaude Sonnet 5.5 47c5d38d0c Exit nodes on macOS: pf anchor for offering, routes plus route-to for using
The exit-node host rules existed only for Linux (iptables + policy routing);
macOS reported "only supported on Linux yet".

Offering: a pf anchor com.apple/tsunagi-exit-<if> (evaluated by the stock
pf.conf) holds a nat rule per offered range and a pass-in rule. pf is enabled
if needed and the pfctl -E reference is released when the rules are removed.
net.inet.ip.forwarding is only read, never written, as on Linux.

Using: macOS has no uidrange policy routing and the agent is root, so the
overlay gets 0.0.0.0/1 and 128.0.0.0/1 routes and a pf route-to rule (matched
by the agent's uid) sends the agent's own QUIC/relay traffic back out the
physical interface, translated to its address. The rules are loaded before the
routes, so a failed load never sends traffic into a tunnel it cannot exempt
the agent from. IPv6 is blocked with rejecting ::/1 and 8000::/1 routes.
ExitHostPlan gains `overlay` (every network range) for the route-to exemption;
Linux ignores it.

Known limits: the egress is the default route's interface at apply time; other
root processes also bypass the tunnel. Forwarding hints in the CLI and tray
name the macOS sysctl. The rule text and command order are unit-tested with a
scripted host; nothing was run against a live pf/route (needs root), so the
route-to + nat second-pass behaviour is unverified.

Checks: cargo fmt --check, cargo clippy --locked --workspace --all-targets
-D warnings and cargo test --locked --workspace --all-targets, run on macOS
only.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-03 12:29:40 +01:00

4.8 KiB

Exit nodes

A member can offer itself as an exit node in a network. Other members can then send all their internet traffic through it, the way a commercial VPN or Tailscale's exit nodes work. Linux only for now.

Using it

The offering side, per network, off by default:

tsng network exit-node <network> on      # or off

Rules are installed even when the kernel does not forward yet, and status says so. Turning forwarding on is left to you, on purpose:

sudo sysctl -w net.ipv4.ip_forward=1

The using side:

tsng exit-node                  # who offers one
tsng exit-node <name|id>        # send everything through it
tsng exit-node off

The tray does the same: a checkbox on the network tile to offer, and an icon on each device in the devices window that offers one, with a confirmation.

One device has one default route, so it uses one exit node at a time; choosing another replaces the first. Offering is per network, so a device can be an exit node in one network and not in another.

How it works

  • An offering agent says so in its control-plane Announce (exit_node), and only once its rules are in place. Members see which peers offer one.
  • Server: iptables masquerades the overlay range of that network out of any other interface and allows forwarding for it. Rules carry the tag tsunagi-exit:<interface>:<range> and are removed when the offer ends, the network stops, and when the agent exits. Only networks that offer have rules, so the others' traffic is not forwarded.
  • Client: policy routing, with no change to the main table. Table 28787 holds default dev <interface>, and three rules sit after Tailscale's: 5280 uidrange <agent uid> lookup main (the agent's own connections never go through the tunnel, which would be a loop), 5290 lookup main suppress_prefixlength 0 (LAN and other specific routes keep working) and 5300 lookup 28787.
  • Packets for addresses outside every overlay range are sent to the exit node by the router; the exit node's replies are accepted from any source. A member that is not your exit node cannot do that.
  • IPv6 is blocked while you use one. There is no IPv6 through an exit node, and letting it go the ordinary way would leak it. The same three rules exist for IPv6 with an unreachable default in the table, so applications get an immediate "network unreachable" and fall back to IPv4. LAN, ULA and other specific IPv6 routes keep working, and so does the agent's own IPv6. A host with no IPv6 has nothing to block and is left alone.

macOS

macOS has no iptables and no per-user policy routing, so the same behaviour is built from pf and route. The agent runs as root there.

  • Offering: a pf anchor com.apple/tsunagi-exit-<interface> (the stock /etc/pf.conf already evaluates com.apple/*) holds nat on <egress> from <range> to any -> (<egress>) and a pass in rule. pf is enabled if it was off, and that reference is released when the rules go. Forwarding is only read: sudo sysctl -w net.inet.ip.forwarding=1, which macOS forgets at reboot. The egress is the default route's interface at the time the rules are applied; after it changes (Wi-Fi to Ethernet) switch the offer off and on.
  • Using: 0.0.0.0/1 and 128.0.0.0/1 routes through the overlay interface, and a pf route-to rule that sends the agent's own traffic (matched by its user id, root) back out the physical interface, with translation to that interface's address. Anything else you run as root also bypasses the tunnel. IPv6 is blocked with rejecting ::/1 and 8000::/1 routes.
  • Not verified on a live host when this was written: run tsng exit-node and check sudo pfctl -a com.apple/tsunagi-exit-utunN -s rules -s nat.

What it does not do

  • The agent must run as a system service (its own user). The uid exemption would otherwise cover everything you run. A per-user agent refuses to use an exit node and says why.
  • If the exit node disappears the rules stay and traffic is dropped until it returns or you run tsng exit-node off. This is deliberate: falling back to the direct path would leak traffic nobody agreed to send in the clear. The agent logs it once, status and the tray say so loudly.
  • IPv6-only destinations are unreachable meanwhile; carrying IPv6 through the exit node is not implemented. DNS is untouched.
  • Kernel forwarding is only read, never changed.

Trust

Anyone who knows the network's secret can pick your exit node if you offer one, and you carry what they send: it leaves from your address and is yours to answer for. The exit node sees every destination and, for plain traffic, its contents. Choosing an exit node means trusting its owner completely. Offer one only in networks whose members you trust, and only from a machine you are willing to have that traffic come from.