trashpanda.cc

Kohlenstoff-basiert Zweibeiniges Säugetier

Setting up VLANs on Unifi gear

I have approximately eleventy billion devices connected to my wlan, most of which are some flavour of Internet-of-Things equipment. Some of them are well-designed and almost trustworthy; some of them I only grudgingly tolerate the existence of because their security is so poor.

This situation is only getting worse - there are some devices which I don't trust but HAVE to be connected, like the solar system. I've long-wanted a setup where these kinds of device can have their own virtual network isolated from the rest of what's going on, but crucially remain reachable from the main network so that I can manage and pull data off them.

Finally, I think I might have got there. This is probably only of practical use if you also have Unifi networking gear, but the approach might be interesting even if not.

The requirements

  • network A is the default trusted network, on which all devices can talk to each other, and all devices can access the outside world
  • network B is a non-trusted network on which no devices can talk to each other, but which can be accessed from network A for management purposes. This has no connection to the outside world
  • a semi-trusted network C also on which no devices can talk to each other, but which can be accessed from network A for management purposes. This does have a connection to the outside world, but it's direct and doesn't transit through the default network A.

Normal IoT devices have no business talking to the outside world, so they go straight onto network B. They can be accessed from network A (for example, by Home Assistant) but can't talk to each other or get outside. This is the default destination for anything that I don't trust.

Wierdo IoT devices that I don't trust but insist on talking to the outside world go on network C. These can't talk amongst themselves, can be managed from network A, but can also reach directly outside. I'm not happy about these, if I'm honest, but unfortunately I don't get a choice - the solar vendor gets uppity if their system goes offline, so this is a compromise keeping their traffic away from my stuff.

The implementation

I have an entirely Unifi-based network setup - a Cloud Gateway Ultra manages everything; a 16-port PoE Lite switch connects everything, and U6+ access points do the wavebandy stuff. There's a Fritzbox hanging off the back of the Cloud Gateway that acts as a DSL modem, but it's not an active participant otherwise.

This is complete overkill for a single house, but it does have the advantage of being very easy to manage once you've figured out what needs to happen. That is as follows.

In the Unifi control plane, I've created three networks with individual names and VLAN ids. They also have a separate DHCP range.

These VLANs are each attached to a separate WLAN network, which broadcasts on all the APs.

VLANs A and C allow internet access - A because it's the default network, and C because the devices demand it. VLAN B has that access disabled. That solves the question of access to the outside world.

To enable devices on VLAN A to manage devices on VLANs B and C, you need to create a rule in the Policy Engine which allows return from B and C to A. You do this by creating a new rule, selecting the source as A and the destination as B or C, selecting Allow as the action, and Return Traffic as the connection state. This is the magic bit - it's effectively a special rule that lets devices on B and C reply to A, but only when they're being spoken to.

Once you've figured that bit out, it's all perfectly logical and relatively easy to implement.

The practice

I originally thought I would have to go round and individually-reconfigure each IoT device to use the new WLANs, which would have been... tedious. Some of them are hidden inside walls and behind appliances, so it would probably have taken the better part of a weekend, and much swearing.

However, Unifi has another trick up its sleeve which negates the need to do this - Virtual Network Override.

Select the device you want to move from the list of clients in the original WLAN, select the Settings tab, and check the Virtual Network Override box. Then select the VLAN that you want to move the device to, and it will be shifted over to the new VLAN without needing to do anything on the device itself. It will pick up a new address from the VLAN's DHCP scope and the rules will be applied.

That saves hours of faffing about, with the minor drawback that these devices are still on the original WLAN it's not immediately obvious that they're "different". New devices will pick up all the settings if you connect them to one of the WLANS that you've attached the VLAN to.

It took a while to figure out, but it now Just Works.

I've written this down because a lot of information about how to do these kinds of things is contained in YouTube videos, which has to be THE WORST medium to communicate this kind of tricky, fiddly, in-depth configuration tasks. Quite apart from the fact that I can read 10x faster than even the fastest video can play, the talents to communicate this kind of information on screen is, how shall we say, unevenly distributed, and not much appears to have landed on the hosts who seem to specialise in this topic. Please - just write the damn stuff down and be done with it...