When deploying a new UniFi network using Ubiquiti UniFi hardware and the controller, you may wish to change the management VLAN, and/or the VLAN that the hardware uses to communicate with the UniFi Controller.
In this post, I’m going to go over how to do this, as well as troubleshoot if something should go wrong.
Please note that I’m focusing on the theory and understanding as to how communication is handled, instead of providing step by step instructions which is what readers are usually accustomed to on this blog.
Why would we do this?
Some users (myself included) like to avoid using the default management VLAN of 1. This can be for a number of reasons such as reducing the security vulnerability footprint, customizing for specific customers or environments, or we just like to change it from the default VLAN.
How do we do this?
When you choose to change the default management VLAN, typically you need to maintain a network/subnet on untagged VLAN1. This is because when you purchase or deploy new UniFi equipment, it will always try to obtain an IP on untagged VLAN 1, and try to contact the controller using this network.
By having a functioning “provisioning” network and subnet on VLAN 1, the devices can obtain their configuration, and provision from there.
Once the device is provisioned and attached to the UniFi controller, you can configure it to use a different VLAN as it’s management VLAN.
Keep in mind that you must make the controller available on both the untagged “provisioning” VLAN 1, as well as the new custom management VLAN as well. In my case, I make all the subnets routable so that the UniFi controller is available no matter what subnet and/or VLAN your on.
How do we secure this?
In my example above, I have very restrictive firewall rules on the firewall that is routing the different VLANs and subnets. The only traffic that is allowed to be routed to the untagged “provisioning” VLAN 1 is traffic destined for the UniFi controller, and only the ports that are required for provisioning. All other traffic is restricted, including internet access.
Essentially the only thing that functions on VLAN 1 is routing to the UniFi controller, and DNS for the lookup of the host record “unifi”.
What will happen if I’m doing this wrong?
If you’ve done this wrong, you may notice that original provisioning works, then the AP or switch disappear and go offline after the management VLAN change on the device. This is because it can’t contact the controller after it changes its default management VLAN to the new one you specified.
If the device never contacts the UniFi controller in the first place, then the device isn’t able to contact the controller on the untagged VLAN 1. You need to make sure that the various provisioning methods are available and functioning, and that the subnet is routable and firewall rules allow communication from that subnet to the UniFi controller.
How do we test this?
In my environment on untagged VLAN 1 as well as my custom management VLAN, you can open a browser and type in “unifi” and it will resolve and connect to the UniFi controller. This means it’s available on the default VLAN that the devices look for, as well as the custom management VLAN.
I find using the A host record the easiest way to do this. Please note that my UniFi controller only has one static IP address on the custom management VLAN.