Part 1: Why ZeroTier Fits Mobile Private Networks

This series describes a private network pattern for mobile sites: RVs, boats, trailers, and other installations that move between LTE, 5G, Starlink, dock Wi-Fi, marina ethernet, and periods with no internet at all.¹

The goal:

https://ha.aurora.zt.example.com

opens Home Assistant from anywhere with a normal browser-trusted certificate, without asking the owner to remember an IP address, install a private CA, or bypass certificate warnings.

The complete design uses five pieces:

ZeroTier for private overlay connectivity.
A self-hosted ZeroTier controller, managed through ZTnet.
Split-horizon DNS, with each site able to resolve its own names locally.
Managed routes and managed DNS so users do not configure routes by hand.
Public ACME certificates using DNS-01 validation, issued on each device that supports local ACME automation.

This first article is the introduction to the series. It explains why ZeroTier is a good fit for the networking layer and frames the decisions the later articles build on. Read it first, then work through the parts in order; each one assumes the design context established here.

In this series#

Part 1 sets the design context; Parts 2 through 5 build the network one layer at a time.

Why ZeroTier Fits Mobile Private Networks (this article) — the design case for ZeroTier as the overlay for sites behind carrier NAT, changing WAN links, and intermittent internet.
Self-Hosting a ZeroTier Controller with ZTnet — running the control plane yourself: controller scope, ZTnet, access control, and backups.
Split-Horizon DNS for Mobile ZeroTier Sites — local authoritative names that survive offline operation, plus DNSSEC-aware public delegation.
Managed Routes and DNS in ZeroTier — distributing LAN routes and resolver settings from the controller so users reach private services without manual setup.
Trusted Certificates for Private ZeroTier Sites — public ACME certificates over DNS-01 for internal-only names, issued on each device.

Step-by-step plan#

Use this article as the design gate before building the network.

Identify the mobile sites that need access, such as aurora and calypso.
Choose one registered DNS namespace for the fleet, such as zt.example.com.
Assign each site a unique LAN subnet before installing customer equipment.
Decide which device is the site gateway. For this series, that is the RutOS router.
Decide which users and support devices need access to each site.
Choose the overlay model: one ZeroTier network per customer site unless a shared network has a specific operational reason.
Confirm that LAN-only services can be reached from the site router.
Reserve names for the public and private DNS plan before issuing certificates, including _acme-challenge aliases for every device that will renew its own certificate.
Build the remaining pieces in order: controller, DNS, routes, then per-device certificates.

The mobile-site problem#

Fixed-site remote access designs usually assume at least one stable point: a public IP address, a static WAN interface, a fixed firewall, or a predictable upstream network. Mobile sites rarely have any of those.

Typical constraints include:

Carrier-grade NAT on LTE and 5G links.
WAN changes between Starlink, cellular, marina Wi-Fi, and ethernet.
Customer fleets where each owner must only see their own site.
Devices that cannot run VPN clients, such as cameras, battery monitors, marine electronics, and some embedded controllers.
Weeks of degraded or absent internet connectivity.

The network still has to be supportable. A technician may need to reach several sites, an owner may have two vehicles, and a local Home Assistant instance should continue to work when the WAN is down.

Why inbound VPN server patterns do not fit well#

Traditional VPN designs often require the mobile site to act as a server. That is a poor match for carrier networks.

WireGuard, IPsec, and OpenVPN can all work well when at least one endpoint has a stable, reachable address. In an RV or vessel, the router is often behind one or more layers of NAT. Port forwarding is unavailable, the WAN address changes, and the path may switch while the user is connected.

A central hub can solve this, but then every site must tunnel through that hub. That introduces a standing relay, bandwidth planning, routing complexity, and a larger failure domain. For a fleet, it also creates an operator-owned choke point for customer traffic.

What ZeroTier provides#

ZeroTier creates a virtual Ethernet-style network between approved members. Members can be laptops, phones, servers, routers, or small embedded hosts. The physical network is used only as transport.

       [support laptop]             [owner phone]
              |                         |
              +------ ZeroTier net -----+
                         |
                  [RutOS router]
                    ZT: 10.147.20.1
                         |
                 LAN: 192.168.42.0/24

The design benefits are practical:

NAT traversal handles many CGNAT cases without inbound port forwarding.
The virtual network is independent of the current WAN interface.
Membership is controlled centrally per network.
Managed routes can expose a whole LAN through one router member.
Rules can restrict traffic between customers, operators, and devices.
Router support is available on OpenWrt-derived platforms, including RutOS.

ZeroTier also separates the controller role from the root server role. A controller decides network membership and distributes network configuration. ZeroTier roots help nodes find and reach each other. This distinction matters when self-hosting the controller: self-hosting removes the dependency on ZeroTier Central for membership and network configuration, but it does not automatically replace the global root infrastructure.

Why this is useful for RutOS and HAOS sites#

In this pattern, the Teltonika RutOS router joins ZeroTier and acts as the site gateway. Most LAN devices do not need to run ZeroTier at all. The examples use Teltonika RutOS, but the design applies to any OpenWrt-based router with a ZeroTier package; or any other router that can run ZeroTier in a supported way.

That has several advantages:

The ZeroTier member list stays small.
A stolen or replaced router has one identity to revoke.
LAN-only devices remain simple LAN devices.
Routes can be managed per site instead of per device.
The router can also provide local DNS for the site.

What ZeroTier does not solve by itself#

ZeroTier is only the transport layer. It does not by itself provide the complete user experience described at the start of this article.

The following still have to be designed:

DNS names that work locally and remotely.
Browser-trusted certificates for private addresses.
Routes from ZeroTier clients to LAN-only devices.
Backup and recovery for the controller and site identities.

Be precise about what offline means here. Remote ZeroTier access still requires some usable network path between the client and the site. If Aurora has no WAN at all, a remote user cannot reach it through ZeroTier. The offline requirement in this series means that local users on the site LAN should still resolve names and use valid TLS certificates without depending on public DNS or a live CA check.

Alternatives considered#

Tailscale and Headscale are excellent choices for many private networks. They are especially strong for user-device access and identity-oriented policy. For this fleet pattern, ZeroTier is attractive because it presents a virtual Ethernet-style network, is well established on router-class and OpenWrt-derived systems, and has a controller model that can be self-hosted while preserving the same basic client behavior.

WireGuard meshes are simple and fast when the addressing model is stable. They become more operationally expensive when every site is mobile, behind CGNAT, and owned by a different customer. A hub-and-spoke WireGuard design is valid, but the hub becomes part of the data plane.

OpenVPN remains useful in constrained networks, especially in TCP mode, but it is heavier to operate and is not a natural fit for a fleet of small mobile sites.

Design principle for the rest of the series#

The rest of the series keeps the overlay small and lets each site remain operational on its own LAN:

Control plane:
  ZTnet + ZeroTier controller -> membership, addresses, routes, DNS settings

Transport:
  ZeroTier overlay -> user devices and site routers

Site services:
  RutOS -> routing, firewalling, local DNS

Public infrastructure:
  Cloudflare DNS -> parent zone and ACME validation names
  Let's Encrypt  -> public certificates issued by device-local ACME clients

That separation is what makes the system supportable. The public DNS provider and CA are needed during provisioning and renewal. They should not be required for a user already on Aurora’s LAN to resolve ha.aurora.zt.example.com or load Home Assistant over HTTPS.

Reference documentation#

Written in collaboration between Claude, GPT, and Adam Sherman’s human brain; the wetware retained final veto power. ↩