English
Deutsch
PolskiMulti-WAN Failover with the Ubiquiti UniFi UCG-Fiber: Setup, Grounding and Configuration
Contents
Achieving 100% network uptime requires a solid Multi-WAN strategy. The Ubiquiti UniFi UCG-Fiber is an excellent gateway for managing multiple internet sources. This guide covers how to set up a robust three-tier failover system.
The Setup Architecture
A highly resilient network requires diverse connection types to prevent a single point of failure. A reliable architecture utilizes:
- WAN1 (Primary): Toya (Fiber Optic) – Offers the lowest latency and highest bandwidth.
- WAN2 (Secondary / Failover 1): Starlink – Provides independent satellite routing if the local terrestrial infrastructure fails.
- WAN3 (Tertiary / Failover 2): ZTE 5G Modem – Acts as the final backup utilizing cellular towers.
Recommended Equipment
For optimal integration with UniFi gear, the external modems must support bridge mode or IP passthrough to avoid Double NAT issues:
- Starlink: The Standard (Gen 3), whose router already provides two built-in Ethernet ports behind the rear cover, or the High Performance business model. Both allow bypassing the default Starlink router via bypass mode — no separate Ethernet adapter is required.
- ZTE 5G Modem: The ZTE MC889 outdoor ODU (Outdoor Unit). It is powered via PoE, handles harsh weather conditions, and provides a clean bridge mode directly to the UCG-Fiber.
Installation and Mandatory Grounding
When deploying Starlink and a 5G modem on a metal mast high above the roofline, strict electrical safety protocols must be followed:
- Lightning Protection: The metal mast must be connected directly to the building’s grounding system (earth rod) using a copper wire of appropriate cross-section (e.g., 16mm²).
- Surge Protection Panels: Outdoor Ethernet cables (STP – Shielded Twisted Pair) acting as antennas for lightning induction must not plug directly into core network switches. Cables should be routed down to the central distribution rack—often located in a secure, climate-stable environment like a cellar—and terminated on dedicated PoE surge protection panels before patching into the UCG-Fiber.
- Cable Management: Ensure outdoor-rated, UV-resistant shielded cables are used.
UniFi OS Configuration
- Navigate to Settings > Internet in the UniFi Network application.
- Select the Primary (WAN1) connection and assign it to the port where the Toya fiber is connected (e.g., via an SFP module).
- Add Secondary (WAN2) for Starlink. Under advanced settings, configure Load Balancing to Failover Only (to save power/data) or Distributed if concurrent usage is preferred.
- Add Tertiary (WAN3) for the ZTE 5G modem, setting its priority lower than Starlink.
- Adjust Echo Server settings (e.g., pinging 1.1.1.1 and 8.8.8.8) to ensure the UCG-Fiber accurately detects an outage and initiates the failover seamlessly.
Summary
This guide outlines the implementation of a resilient triple-WAN failover system using the Ubiquiti UniFi UCG-Fiber. By combining a fiber-optic primary connection (Toya) with satellite (Starlink) and cellular (ZTE 5G) backups, a constant internet connection is maintained. The article emphasizes the necessity of professional grounding for roof-mounted equipment and provides technical steps for configuring load balancing and echo servers within the UniFi OS environment.
Health Checks, Weights and Routes for Selected Traffic
The echo servers from the configuration steps are only part of how a line is judged. By default, UniFi applies an SLA called Auto with three probes per WAN: a ping to ping.ui.com and DNS lookups of ui.com through Cloudflare (1.1.1.1) and Google (8.8.8.8). A WAN is marked down as soon as two of the three probes fail. Finer criteria are defined under Settings > Internet > Create New SLA: custom verification servers (ping or DNS, address, probe interval, averaging period) with thresholds for packet loss, latency and jitter. That is the tool for catching a Starlink or 5G link that is degrading before it fails outright.
When the lines run in load balancing rather than failover, the weights (for example 80 % to 20 %) apply to new connections. A hash over source and destination IP address keeps each session on the WAN it started on until it ends; if one WAN fails, its traffic moves to the lines still online.
Pinning Traffic to One Line
Policy-Based Routing sends selected traffic through a specific interface regardless of the failover order. In UniFi Network 9.4 the rule is created under Settings > Policy Table > Create New Policy > Route, in 9.3 under Settings > Policy Engine > Policy-Based Routes. The source can be networks (VLANs) or individual devices; the destination can be any traffic, IP ranges with ports, domains (only when clients use the gateway as their DNS server) or countries. The Kill Switch decides what happens when the chosen interface goes down: enabled, the traffic stops; disabled, it falls back to the default interface or the next one in priority.
In the three-line layout above, two uses stand out. The guest VLAN can be pinned to Starlink, leaving the fibre to the internal networks. Bulk traffic such as nightly offsite backups can be pinned to the fibre with the Kill Switch enabled, so an outage pauses the backup instead of pushing it over the 5G line and its data plan. For a WAN reserved for such traffic, Ubiquiti’s guidance is to keep it out of active load balancing and set its role to Failover (in Failover Only mode) or Backup (in Load Balancing mode).
Questions and answers
Does the echo server check notice a congested Starlink link, or does it only catch a hard outage?
Only a hard outage. Echo probes are small packets, and a congested link still answers them, so the gateway sees a healthy connection while throughput is unusable. It is the same blind spot that makes a saturated uplink look fine in many dashboards.
Two things narrow it. Where the gateway supports latency thresholds in addition to packet loss, congestion becomes visible as a rising round-trip time long before packets are lost; that is the closest thing to a congestion signal available at this level. And the probe targets should sit on different networks, as 1.1.1.1 and 8.8.8.8 in the article do, so that a route problem to one provider does not read as a dead link.
The part that gets skipped, though, is testing the backup path itself. A secondary link that has not carried traffic for months is an assumption, not a fallback: the modem may have dropped off the network, the bridge mode may have reset after a firmware update, the data plan may have lapsed. Unplugging the primary once a month, deliberately and at a quiet hour, is the only check that covers all three.
Related articles
