ZeroTier exit node not working? Check route, NAT and client

The route table shows a default through the ZeroTier interface, the network reports online, and a browser still exits from the local ISP address. That combination is common and it is not a client bug. A default route only says where packets should go; something has to forward and translate them at the other end. Three separate parts have to be true before an exit node works.

The route exists but nothing exits

Check the client's route table first. A line such as default via 10.147.20.5 dev zt0 proves the route was installed, not that the destination will accept the traffic. The next hop has to be a member that is willing and able to forward it.

If the same request still leaves through the physical interface, the client did not install the route, or it installed it with a metric that lost to the local default. If the request disappears after the route is installed, the exit member is receiving packets and failing to forward or translate them. A client that keeps the physical default never sends a packet to the exit at all.

That distinction decides where to work. Comparing a public address before and after the change separates a route that was never used from one that was used and dropped, and it takes one command instead of a review of the whole configuration. Do the comparison before changing anything else, so both results come from the same starting state.

Three parts that must all be true

An exit is a chain, and the weakest link sets the symptom. The table below lists the links in the order they usually fail.

The first row is the one the option name hides. A member becomes an exit only when its kernel forwards packets between the ZeroTier interface and the internet-facing interface, and when the reply path is translated back to the tunnel. Without that forwarding, the member is a peer, not a gateway.

The controller row is authorization, not configuration. Advertising 0.0.0.0/0 through a member tells every client where the exit is; it does not make that member capable of carrying the traffic. It also does not verify that the member has a working path to the internet. ZeroTier's exit-node documentation covers the same split between node, route and client.

Configure the exit node to forward and translate

Enable IPv4 forwarding persistently, then add source NAT for traffic leaving the WAN interface. The filter rules must allow the forwarded flow in both directions, because forwarding and translation are separate from permission:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Replace zt0 and eth0 with the names on the host; a rule saved for an example interface does not follow packets on a real one. Make the changes persistent through the firewall manager that owns the rules, because a command in an interactive shell disappears at the next reboot.

If the host runs a firewall manager such as UFW or firewalld, add the rules through that manager instead of stacking iptables lines beside it. Two owners editing the same chains produce a policy that depends on boot order. Ordering matters when the manager generates its own chains. Test from a client after reloading the manager, not before.

Advertise the route and accept it on the client

On the network controller, add a managed route for 0.0.0.0/0 whose next hop is the exit member's ZeroTier address. Then, on the member that should use it, allow the override for that network. The permission is local: it does not reconfigure other members and it does not change the controller.

zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1

The last command should report the ZeroTier interface and the exit member's address. If it still reports the physical interface, the route is missing or a competing default has a better metric.

Keep the setting scoped to the network that needs it. Enabling default-route acceptance globally, or on a network that should only provide a private subnet, sends traffic through an exit that was never sized for it.

Verify the exit and check the other address families

Request a public address from a service that reports the source, and compare it with the exit node's WAN address. Then load a named site to confirm DNS still resolves, and test one application that matters rather than only a browser.

A dual-stack client can keep using its native IPv6 path while IPv4 exits through ZeroTier. If the goal is to hide or control all traffic, a separate ::/0 route and IPv6 forwarding on the exit are required, and an IPv4 test says nothing about them.

Linux reverse-path filtering can also drop valid exit traffic on the client. ZeroTier documents an rp_filter consideration for participating members; change that setting deliberately and only after the route and NAT are confirmed, not as the first experiment.

If the requirement is access to a NAS or one office subnet, a managed route for that prefix is a smaller and safer change than a full exit. Sending all browsing through another device is a different decision from reaching one private resource, and it deserves a separate review.