ZeroTier to a LAN: UFW route rules, not a port allow

Reaching a printer on the office LAN through a ZeroTier member sounds like one rule, and it is actually three decisions in three different places. The overlay has to know where the LAN is, the Linux host has to be willing to forward packets, and the LAN has to know how to send the reply back. An inbound rule that opens a port on the gateway touches none of those. It is the wrong tool applied to the right host.

Three jobs, three owners

The managed route belongs to the ZeroTier network configuration. It tells members that a prefix is reachable through a particular member address.

Forwarding belongs to the Linux kernel and to whatever owns its firewall policy. It decides whether a packet arriving on the overlay leaves again on the physical interface. A host that is not forwarding will silently drop the packet after accepting it. The sender sees a timeout and nothing appears in the service log.

The return path belongs to the LAN. Its hosts and its router need to know that the overlay prefix is reachable through your gateway's LAN address, or something has to translate the traffic so the question never arises.

Each of those can be correct while the others fail, which is why a test that only pings the gateway proves nothing about the service behind it.

Point the managed route at the member

Add a route for the intended LAN prefix through the gateway's overlay address, not through its LAN address. The overlay address is the one other members can reach; the LAN address is only meaningful on the wire.

Members must accept managed routes for the design to work, and their own local networks must not already use the prefix you are advertising. A remote laptop that sits on 192.168.60.0/24 at home cannot also route 192.168.60.0/24 through the overlay.

Keep the advertised prefix as narrow as the task allows. Advertising a larger aggregate to influence preference may also claim address space you do not own, and the resulting conflict appears on the devices that connect to both networks. It can also make a member prefer a path that leads nowhere. Keep the route honest and let policy do the rest.

Write the prefix and the member address into the same note as the firewall rules, because the most common failure is a route pointing at the wrong member.

Enable transit in the kernel

Read the running forwarding value before changing anything, then persist the setting through the mechanism your system already uses rather than through a one-off command that disappears at reboot.

If UFW owns the policy, its route rules express forwarding for a source, destination and interface pair. Those are separate from inbound rules that open a service on the gateway itself:

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

The interface name is the actual overlay device on that host, which you can read from ip link; it is not a fixed string across installations. If the host forwards by default and UFW is not in the path, the route rule will be ignored and the kernel settings are what matter.

Choose how replies come back

With source preservation, the LAN service sees the real overlay address and replies to it. That requires a route on the LAN host or its router pointing the overlay prefix at your gateway, which is a change outside the Linux box.

When that route cannot be added, scoped source translation makes the request look like it came from the gateway on the LAN. Replies then return locally and no LAN routing change is needed, at the cost of losing the original source in the service logs.

Scope the translation to the overlay source and the specific LAN destination. Translating everything leaving the LAN interface is the broad version that later surprises whoever reads the rules, and it also hides traffic that should have been blocked.

Neither choice grants unsolicited access from the LAN back to arbitrary overlay members. If that is wanted, it is a separate rule with its own review.

Test from a real member

Connect from another member, not from the gateway, and request one permitted service. Then try a service that should stay closed, and repeat both tests after a reconnect and after a reboot of the gateway.

A member that reports ONLINE, or a successful ping to the gateway overlay address, does not validate the route, the forward rule or the reply path:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

The second command shows which interface the packet would use for the LAN host, and the third shows whether the route rule exists in the form you intended. If both look right and the service still times out, the reply path is the remaining suspect.