Applied engineering · Guaxuma case
Why we chose Tailscale to connect two rural operations
In Iguatemi and Sidrolândia, each site had two internet paths, all behind CGNAT. The solution had to preserve redundancy, run on the gateways, and leave the servers untouched.
The real environment
Redundancy was present, but the paths were not equivalent
In Iguatemi, operations relied on a low-quality rural radio connection. We introduced a new satellite-based connection as the primary path and retained the radio link only as fallback. In Sidrolândia, satellite connectivity had been primary; once fiber arrived, it became the main path and the satellite link moved to fallback.
The connections available to both sites operated behind CGNAT. A public address on only one path would not follow the complete failover chain. In Sidrolândia, keeping fiber behind CGNAT avoided an extra cost that would not solve the full design or provide a proportional operational benefit.
Goalmoon also implemented a new Ubiquiti architecture to organize the networks. That work deserves a separate analysis. This article focuses on the next decision: how to connect the sites without turning servers into VPN endpoints or giving up their fallback links.
Conceptual architecture
Two sites, four links, and one common layer at the gateways
This diagram summarizes the public architecture. It omits addresses, identifiable equipment, and internal configurations.
Iguatemi
Satellite connection as primary · rural radio as fallback
Sidrolândia
Fiber as primary · satellite connection as fallback
The available paths operated behind CGNAT. The interconnection follows the gateways and does not require publishing an internal service directly to the internet.
Decision criteria
The solution had to follow the network, not rely on the servers
We did not conduct a formal vendor contest. We started with concrete operational requirements and looked for a layer that could run on both UDM gateways, advertise the local networks, and continue working when the internet path changed.
Run at the gateways
Interconnection had to reside on the UDMs, with no additional client or service installed on management-system servers.
Work behind CGNAT
All four internet paths needed to participate without depending on a fixed public entry point.
Preserve local services
Servers, workstations, and devices would keep using the addresses and gateways of their own networks.
Follow failover
Switching between the primary link and fallback should not require reconfiguring the VPN.
Support operations
Inter-site access, authorized remote access, revocation, and diagnosis needed documented procedures.
The choice
Tailscale began interconnecting the networks directly through the UDMs
We installed Tailscale on the gateways and configured each UDM as a subnet router. Each device advertises its local network to the secure mesh and forwards authorized traffic. Servers remain behind the gateways, with no Tailscale client, address change, or direct internet exposure.
Tailscale uses NAT traversal techniques to attempt a direct device-to-device connection. When that is not possible, it can use an encrypted relay. In this deployment, communication started through a relay and then established a direct connection even with CGNAT on both sides.
That behavior addressed the central requirement: connectivity between sites would depend on gateways and advertised routes, while servers remained dedicated to the local work for which they had been installed.
From setup to operations
The decision was complete only after testing failure, recovery, and restart
We first validated bidirectional communication, access to authorized services, and remote support sessions. We then restarted the gateways to confirm that the installation and advertised routes persisted.
In Sidrolândia, we interrupted the fiber link and confirmed automatic transition to the fallback path. We then validated the return to fiber. The inter-site route remained available during the failover and failback cycle. The same operating principle was documented for Iguatemi’s pair of links.
We also produced three levels of documentation: an engineering reference, an administrator procedure, and a simple guide for remote users. The technical solution gained an explicit operating, support, and revocation model.
What we learned
Avoiding a cost matters only when the architecture remains verifiable
A public IP address is neither inherently wrong nor inherently beneficial. In this case, purchasing it for just one path would not solve continuity across providers. The combination of gateways, subnet routes, and NAT traversal delivered the required outcome without adding an expense that provided no practical benefit in the chosen design.
The UDM deployment uses a community integration rather than a native UniFi interface feature. Restarts, system updates, and recovery therefore require verification procedures. This is an accepted, documented, and monitored operational responsibility.
The broader lesson was to separate layers without isolating them. The new network architecture created the foundation; WAN redundancy preserved alternate paths; and Tailscale added secure interconnection. Each solves a distinct problem, and all must be tested together.
What we actually validated
The two networks exchanged traffic behind CGNAT, a direct connection was established after the initial relay, bidirectional access and remote support worked, routes persisted after restart, and communication followed the tested failover and failback cycle. No client was installed on the servers.
The limits that still remain
- Interconnection still depends on at least one working internet path at each site.
- A fallback link preserves connectivity while retaining its own capacity and quality constraints.
- A connection may use a relay when direct traversal is unavailable; the path should be observed during support.
- The UDM integration must be checked after material system updates.
- Authorized access requires policy, approval, revocation, and periodic review; a VPN does not replace that governance.