Router Intro

The router is the most important piece of infrastructure in this network. Everything that connects to the internet passes through it. Every VLAN, every firewall rule, every VPN tunnel starts here. Getting this layer right is the foundation everything else builds on.

The source material this series draws on covers OpenWrt running on a NETGEAR consumer router. This series diverges significantly: all three sites in this network run Ubiquiti UniFi hardware, and the approach reflects that choice throughout. Where the original covers command line configuration of OpenWrt, this series covers the UniFi web interface and the decisions behind each configuration.

Why Ubiquiti UniFi

The choice of Ubiquiti is not the only valid choice, but it is a coherent one worth explaining.

UniFi is an ecosystem. Routers, switches, access points, cameras, phones, and door controllers all share a common management interface and a common configuration model. Adding a new access point to the network is a matter of plugging it in and clicking Adopt. VLAN configuration on a switch propagates to the access points automatically. The management interface is consistent across the whole estate.

For a three-site network with multiple devices at each location, this consistency has real practical value. The alternative, managing each device independently with its own configuration paradigm, introduces the kind of complexity that makes mistakes more likely and recovery from failures more difficult.

OpenWrt is more powerful in the sense of being more flexible. It runs on cheap commodity hardware and can be configured to do almost anything given sufficient time and expertise. For a homelab where learning is part of the point, it is a legitimate choice. For a network that needs to be reliable and manageable with limited overhead, UniFi is the more pragmatic one.

The three routers

Each site runs its own Ubiquiti gateway, sized appropriately for the location:

Prevernal The primary site. The Dream Machine SE (UDM-SE) is the core: a 1U rack-mounted appliance combining a security gateway, 8-port PoE switch, and integrated UniFi Network controller. It handles the WAN connection for Burnage, manages all VLANs at that site, and terminates the WireGuard VPN tunnels to the other two sites.

Vernal A smaller UniFi gateway appropriate for the site. Manages the local VLANs in the 10.2.x.x address space and connects back to Prevernal via WireGuard.

Estival The same approach as Vernal. Manages the local VLANs in the 10.3.x.x address space and connects back to Prevernal via WireGuard.

All three routers are managed via the UniFi Network application. Prevernal runs the controller locally on its integrated storage. Vernal and Estival can be managed either through their own local interfaces or remotely via Prevernal or the UniFi Site Manager.

What this section covers

The router section works through the configuration of Prevernal in detail, with notes where Vernal and Estival differ. The following pages cover each significant area of configuration:

• Installation — Physical setup, initial configuration, and firmware update of the UDM-SE
• Initial configuration — System settings, DNS, NTP, and SSH access
• Network design — Implementing the VLAN structure from the network design section
• Firewall — Rules, traffic policies, and inter-VLAN routing
• WireGuard VPN — Server setup, client configuration, and inter-site connectivity
• DNS — Internal DNS resolver configuration and split DNS
• DHCP — Address assignment, reservations, and DHCP options
• Dynamic DNS — Keeping the WAN hostname current for VPN endpoint stability
• WiFi — SSID configuration, VLAN mapping, and radio settings
• Intrusion Prevention — IPS/IDS configuration and threat management
• Port forwarding — Exposing services to the internet where needed
• Monitoring — Traffic analysis, device statistics, and alerting

A note on the UniFi management model

UniFi has an important architectural distinction worth understanding before diving into configuration: the controller and the gateway are logically separate even when physically combined.

The controller is the UniFi Network application: the software that stores configuration, manages device adoption, and provides the web interface. On the UDM-SE, the controller runs on the integrated SSD. On a separate machine (such as the February homelab server), the controller can run independently.

The gateway is the network hardware itself: routing packets, enforcing firewall rules, and managing VLANs. The gateway operates independently of the controller once configured. If the controller goes offline, existing network configuration continues to work. Only changes to configuration require the controller to be available.

This matters in practice because it means:

• The UDM-SE failing means both the gateway and the controller go offline simultaneously
• Running the controller on the homelab server means the gateway can continue operating during controller maintenance
• Multiple sites can share a single controller instance if needed

For the purposes of this series, the controller runs on the UDM-SE at Burnage. Once the February homelab server is operational, migrating the controller there is a sensible next step and is covered in the server section.

Configuration philosophy

UniFi configuration is done through the web interface rather than configuration files or command line tools. This is a deliberate design choice by Ubiquiti: the controller maintains the authoritative configuration, and devices receive their configuration from the controller rather than storing it locally.

The practical implication is that manual SSH changes to a device are overwritten by the controller on the next sync. Configuration belongs in the web interface. SSH is for diagnostics and emergency recovery, not for routine configuration.

This is a different mental model from OpenWrt, where the configuration files on the device are the source of truth. Neither is wrong, but understanding the UniFi model upfront prevents the frustration of making SSH changes that disappear after the next controller push.

The router is not just a box. It is the policy engine for the entire network. Time spent getting the VLAN structure, firewall rules, and DNS configuration right here pays back every day the network runs reliably. Rushing this section to get to the interesting server and application work is a false economy.