Egress routing

Egress routing lets mesh devices reach external services (databases, APIs, SaaS) through another device’s IP. The external service sees that device’s address — not yours.

This is different from direct mesh access (device.mesh:port), which reaches services on mesh devices. Egress routing reaches services outside the mesh through a mesh device.

When to use it

• IP allowlisting — MongoDB Atlas, AWS RDS, or Stripe only allows your server’s IP
• Regional access — A service is region-locked; route through a device in the right region
• VPC reachability — A database is only reachable from a specific network

Not for all traffic

jalth routes per-hostname, not all internet traffic. For full-tunnel egress, use a Tailscale exit node or similar.

Example: MongoDB Atlas

# On the VM with the allowlisted IP:
jalth route add "*.mongodb.net" --name atlas

# Or from any device, specify the gateway:
jalth route add "*.mongodb.net" --name atlas --via production-vm

Every enrolled device can now connect to Atlas using their normal connection string. Atlas sees the VM’s IP.

More examples

jalth route add "*.rds.amazonaws.com" --name aws-db --via db-gateway
jalth route add "api.stripe.com" --name stripe --via us-east-vm
jalth route ls
jalth route remove atlas

Requirements

The --via device must have a cloudflared tunnel (from jalth serve or jalth ssh enable). Route management requires operator or admin role.

How it works

1. Worker creates a tunnel hostname route on the gateway device
2. Split tunnel is updated to include 100.80.0.0/16 (egress routing range)
3. DNS queries for the hostname pattern resolve through the gateway’s tunnel
4. Traffic exits from the gateway device’s network