More adventures in Unifi-land

I’ve written here before (part 1: build-out, part-2: 10x upgrade) about the network I’ve built and manage for a 40-apartment building here in Helsinki. This week I embarked on a configuration upgrade I probably should have implemented ages ago, but which only now got priority. No pictures this time — they’d all be screenshots, anyway!

To recap: the network provides 40 fully-isolated wired and wireless subnets (VLAN, IP and Wifi SSID/PSK) for each of the apartments, plus a shared, building-wide network available to all residents through the common spaces (as well as in their homes for any visitors). The UDM-Pro core router is providing all the routing, NAT and firewalling for this purpose and its all managed in the Unifi Network controller over the cloud.

Ever since the original setup at 100/100 Mbps capacity and through the 1Gbps upgrade last year, which are described in the previous posts, the core router has been in DHCP mode towards the WAN, address-translating all IPv4 traffic, and delegating global IPv6 addresses to each of the nets. This made setup more convenient, but with up to 200 active client devices, a single outward facing IP address simply is not enough — probably hasn’t been enough for a long time. So that had to be replaced.

While the WAN link would have been happy DHCP assigning us more public IP addresses as it was, the Unifi functionality does not include running NAT over a pool of dynamically assigned addresses, nor was it easy to set up the subnets to acquire public addresses instead — though that works fine for IPv6, thanks to prefix delegation.

So, I had to ask our ISP Suomicom to assign us a static network instead and do a lot of repetitive address assignment and NAT configuration by hand. This is one of the big weaknesses of Unifi: while it is Linux-based, and I could easily inspect its live network configuration over ssh using the usual commands, ie, ip, iptables and ip6tables, there’s no supported way of changing that configuration except via the Unifi Network web GUI. An automated script would have made this much more comfortable.

A whole lot of clicking around, then. At least I could verify my actions via the command line.

1. Swap the Settings / Internet config from IPv4 Connection: DHCPv4 to Static IP, enter the new IP, subnet, gateway and DNS servers, and verify connectivity remains after committing these changes.
2. Add an Additional IP Address (range) for one statically assigned address per network (to be used in a subsequent step).
3. Also replace IPv6 Configuration from DHCPv6 Prefix Delegation with Static IP using the address space assigned to us. Unifi would have been happy to operate IPv6 with DHCPv6 Prefix Delegation even with static IPv4, but that wasn’t an option for our ISP — instead, we got a static /48 prefix to work with.
4. Change one of the Settings / Networks VLANs to use its own Additional IP Address from step 2 as its Internet Source IP, verify that routing remains. This can be done either from a client device on the network, as well as from the UDM command line with traceroute -s [internal subnet router ip] 1.1.1.1
5. Jump to the IPv6 tab of the network in question, change its Interface Type from Prefix Delegation to Static and assign it its own IPv6 address prefix from the address space assigned to us. Each network got its own subnet id with a /64 prefix.
6. After verifying both of the steps work on one of the networks, repeat them on each of the 40, one by one. Tedius and error prone via the GUI.
7. Finally, check both iptables -t nat -L -v (IPv4) and ip -6 route (IPv6) for errors, and find none because you’re accurate.

Continue enjoying a 1 Gbps fiber connected, building-wide private network installation with Wifi5 coverage. This’ll hopefully last a while before demand picks up for a Wifi6 upgrade. Thanks to Suomicom for their prompt support as usual.