Liam Symonds

Refreshing my home network with TP-Link's Omada

Liam Symonds -

I recently came to the realisation that my home network strategy was not working. Whilst running the stock ISP provided router/AP combo had worked fine for over a decade, my onboarding of more and more untrusted devices onto my network as well as the expansion of the network outside of my home's four walls started to warrant an investment into better equipment.

My first thought was to try and survive with the basics: unmanaged switches and old router/AP combos running in access-point mode. This did work for a while, but I really struggled with getting roaming and bandwidth control to work nicely between the differently branded devices. In addition, I absolutely hated the lack of observability this solution provided.

I had no idea who was connected to where or who was using exorbitant bandwidth without individually logging in to each access point, remembering where that information was stored (depending on the brand), and then extrapolating that data based on device names from the main router's client list.

I had heard of Ubiquiti's prosumer Unifi devices from the internet and friends so this was my first choice. However, after searching, I struggled to find a supplier that actually had Unifi's small-home-office-sized units in stock. I waited for a few days, checked again, and found the same stock issues. My patience borders zero so I then began looking for alternatives where I eventually settled on TP Link's Omada.

For the uninitiated: Omada is TP Link's software defined networking (SDN) solution. Like Ubiquiti's Unifi, you configure all components and devices of a network via a software portal known as a controller. Each change (i.e. to a WLAN) is then promoted to all relevant devices that have been adopted by the controller.

My purchase was as follows:

  • 1x ER605 multi-WAN VPN router
  • 1x ER605 8-port gigabit L2+ switch
  • 1x EAP610 Wi-Fi 6 AP
  • 1x EAP225-Outdoor AP

Gradual Migration

As I valued my life, I did not want to take the network offline for my family and visitors whilst I messed around configuring and breaking a new network setup. However, I still wanted to be able to test what I had done and be able to use the connected devices fully.

The solution? Double NAT.

Double NAT allows you to create a network within a network. Instead of connecting your ADSL or Fibre connection to your router's WAN port, you connect an ethernet cable from a different network. You then allow the different network's DHCP server to assign the new router a local WAN IP address, and you're off to the races with full internet connectivity and an isolated network to mess with (break).

Adopting a new Omada network via a Software Controller

As I had (and still have) a perfectly good home server in my office, I opted to run a software controller for Omada instead of purchasing their OC200 hardware controller for £70.

A few days before the equipment got delivered I set this up in order to mess around with it and define my network. There are numerous official and unofficial ways of installing it, but I went with a full system install in an LXC container running on Proxmox.

When the equipment finally did arrive, I struggled to work out what the best way to adopt the equipment from the software controller was.

My existing home network's (Network A) addressing and my desired home network's (Network B) addressing were completely different, and the controller needed constant access to devices in order to provision them correctly. I couldn't put the controller on Network A as that would've involved setting static routes on the router manually which would've been immediately wiped upon adopting it to the controller.

Eventually, I got it working. My process was as follows:

  • Created, installed and configured the software controller on network A.
  • Performed configuration (such as setting up VLANs and ACLs) before hand.
  • Updated the software controller's host to be on the desired management LAN of Network B via a static network configuration.
  • Updated the hard-wired client machine to also be on TP-Link's default network for new devices (192.168.0.0/24).
  • Connected the hard-wired client machine to one of the router's LAN ports.
  • Logged into the router and configured the LAN on it to be the same as management VLAN of Network B.
  • Updated the client machine's static networking configuration to be the management VLAN of Network B.
  • Connected the software controller's host to another of the router's LAN ports.
  • Logged in to the software controller and adopted the router.
  • Connected all of the other devices and adopted them.

Client/switch IP conflicts

After a few days of running and using the network I started to get certificate errors when accessing HTTPS enabled services on my home server. A few minutes after each occurrence, the error would stop.

It turned out that the switches I bought were actually Layer 2+ switches which are dynamically assigned an IP address on each VLAN in order to be enable IP routing of packets. At some point during the initial setup of the network I had configured a static IP address directly on the home server that was conflicting with this.

At random times the switch would receive and forward all connections destined for the home server to its administration interface.

There were no errors or logs and no indication in the software controller or manual that the switch would require an IP address on each VLAN in order to function.

After I changed the home server to retrieve its IP via DHCP and set a static reservation for that server a few IP addresses after the switch's, the errors stopped.

ACLs

Contrary to posts at the top of Google when you search, Omada Gateway ACLs can be configured to be stateful. That is, if a connection is allowed out, its response will be allowed back in.

Switch ACLs on the other hand (at the time of writing) are not. During setup I did manage to create a somewhat stateful alternative by making use of Omada's default allow rule set on their ACLs. Instead of creating allow rules and having a default deny at the bottom, I created deny rules and left everything else to be allowed.

Something else I learned was that switch ACLs also take effect at the gateway level. This means that you should be just as careful when creating switch ACLs as you are creating gateway ones as they are more than capable of completely locking you out of your network.

If you lose access to your controller, you lose access to each device without a factory reset too. Go ahead and ask me how I know.

To prevent this from happening a second time I created a safety rule allowing all traffic from and to my management VLAN and configured that to be the highest priority rule.

Wireguard VPNs

I am a big Wireguard fan and use it for all of my VPN functionality at home and professionally. Unfortunately, the implementation of Wireguard on the Omada gateway left a lot to be desired.

Wireguard clients are by default given unrestricted access to all VLANs. No ACLs affect them, so it's impossible to restrict their reach beyond creating individual firewalls on each network device.

If you don't have a completely flat network with everything in a single VLAN, I'd recommend giving it a miss and hosting the VPN on a virtual machine where you can then configure appropriate firewall rules.

Final Thoughts

Overall, I'm happy with my purchase. It was my first time setting up SDN infrastructure but the network has been rock solid ever since.

There are a few quirks (especially around ACLs still), but those quirks wouldn't ever be enough to drive me away from recommending this for use in the home and small business office environment.

The software controller, once configured, is brilliant and easy to use. The APs are absolutely fantastic and give me whole home Wi-Fi coverage for multiple clients that easily achieves the full speeds of my upstream FTTP connection without breaking a sweat.