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.
[…] Change management VLAN on Ubiquiti UniFi Hardware and Controller […]
How did you make the Unifi Controller available on both a tagged VLAN and the general untagged network? Does it live in (as in the IP address is in) the subnet of VLAN 1/untagged, but you route to it from other VLANs via a L3 device? Thanks!
Hi Jamie,
Thanks for reaching out. I have a few of the subnets on different VLANs routable. I do the routing on a Sophos UTM which has multiple (virtual) adapters sitting on each different subnet/VLAN. This way it can provide routing and I can enforce strict firewall controls.
This way, when a UniFi device is attached to the network on the default untagged network, the only thing it has access to is a DHCP/DNS server, and the UniFi controller which resides on a different subnet. It performs the DNS lookup of “unifi”, provisions and then changes to the appropriate VLAN for management.
Hope this helps!
Cheers,
Stephen
Thanks Stephen. So the controller lives on a VLAN, but is accessible from the untagged VLAN 1 through an L3 device (UTM). And out of the box, Unifi gear is preconfigured to resolve the FQDN “unifi” to provision to the controller, hence the DNS record? You don’t have to console into a Unifi switch for example to set the controller FQDN for provisioning? Thanks.
Hi Jamie,
That is correct (the routing, VLANs, and L3 routing). And yes, provisioning is all automatic, no SSHing needed.
You can find all the different adoption methods available here: https://help.ubnt.com/hc/en-us/articles/204909754-UniFi-Device-Adoption-Methods-for-Remote-UniFi-Controllers
You can use DNS, DHCP, etc… I just chose DNS because it’s easy and my Sophos UTM has a built in DNS server that I use for subnets/VLANs that I don’t want or have servers on.
Stephen
[…] you’ve purchased some Ubiquiti UniFi hardware… You have configured it, possibly even changed your management VLAN. Now it’s time to get production […]
[…] Change management VLAN on Ubiquiti UniFi Hardware and Controller […]
[…] Change management VLAN on Ubiquiti UniFi Hardware and Controller […]
Thanks for the theory, how about a step by step. Something that doesn’t seem to exist with anything Unifi. I am starting to think there is a conspiracy or some sort of law that prevents it.
Hi Jeff,
Sorry, but it’s a little tricky with a how-to on this specific topic. The steps would vary depending on which firewall you’re using, what router you’re using to provide routing between the subnets, etc.
In my case I’m using a Sophos UTM firewall and UniFi switches, but the setup will probably vary from person to person.
I was hoping to go in to the theory, to teach so that readers can setup their own environments and hardware to do this.
Essentially you just need to make all subnets routable, firewall the routing between subnets to only allow communication to the UniFi controller, and set it all up.
If you have a specific question, feel free to ask me and I’ll do my best to answer!
Cheers,
Stephen
Just to say thanks again Stephen. This week I followed the guidance from earlier this year, and put the Unifi devices onto untagged VLAN to be provisioned, gave the DNS entry for “unifi” for those devices that resolves to the controller on a different tagged VLAN, and made sure the Unifi devices could route to it. Now got a fully VLAN enabled home network, thanks again!
Hi Jamie, glad it helped!
Like Jeff I have spent days trying to get this setup with unifi switches and AP and a pfSense firewall. A step by step would really be helpful. Understand that each setup is different, but (at least in my case), if I try to change the unifi devices to my tagged management VLAN, the controller loses contact with them.,
So to be clear, get everything setup on the untagged network, then transfer the controller to the management tagged VLAN? When you say ” you just need to make all subnets routable” – can you be clearer. What do you mean by routable? All subnets? Does that mean IOT and Guest VLANs?
Also when you say ” the only thing it has access to is a DHCP/DNS server, and the UniFi controller which resides on a different subnet. It performs the DNS lookup of “unifi”, provisions and then changes to the appropriate VLAN for management.” Any explanation of these steps would be helpful.
Thanks
Hi Sam,
It may be difficult and confusing, but once you figure out it becomes super easy to setup.
A step by step guide is hard to create, since everyone’s configuration is different not only because of their unique setup, but also because they won’t be using the exact same hardware.
You don’t need to “move” the controller from on VLAN to another, you can configure it on the VLAN you want it on, the important thing is that you need to make it routable to other VLANs.
Typically, VLANs are different networks and cannot communicate with each other unless you have a gateway or router, that routes packets and allows the different VLANs to communicate with each other.
When your networks are routable and can communicate, it won’t matter what VLAN they are on, they will be able to communicate with the controller, the important part is to have a DNS entry for “unifi” on the DNS server that services both the untagged VLAN and the destination VLAN you want to move APs and switches to.
When you attach a new device, and the networks are routable, the unifi switch or AP will connect, allow provisioning, and when you move it it to your destination VLAN should continue to be available.
I hope that clears it up.
Cheers,
Stephen
Great article, I’ve just built a largish (15 VLANS) network using UniF and Fortinet, first time using both products for a ground up build. I used a similar setup having been learning UNiFi’s native VLAN idiosyncrasies, and wanting a MGMT VLAN that was not the default native VLAN1 UNiFI employ.
I currently have to SSH to inform adoption, not practical given amount of kit I need to deploy. I was also wondering how to make adoption/discovery much smoother, and this article seems to be the answer.
I’m going to work through these suggestions and hopefully see some nice results. Found another useful article that links with this for Fortigate users, re: DHCP option 43 and Cloud access ports for the controller, I hope you don’t mind me linking here:
https://forum.fortinet.com/tm.aspx?m=167433
Hi Dom,
Glad to hear if the post helped! By the way, I have another blog post covering the best adoption methods for UniFi, check it out here: The Best UniFi Device Adoption Method.
Cheers,
Stephen
Hi Stephen,
first of all, thank you very much for that very helpfull post.
I was nearly in despair to get a switch back running, after resetting. Make the native VLAN rotuable was the key. Although this is logical, sometimes you can’t see the forest for the trees.
But now, I`ve got another problem. I was updating all devices to the newest firmware and now my CloudKey isn´t reachable anymore. For me it seems, that you`re always sawing on the branch you are sitting on. The Cloud key is the one, who is resonsible for updating a device and in addition to that, spreading the configurations. This in turn leads to problems, when the CloudKey is updating the switch it is directly connected to and get`s itself “out of the game”.
Now I am not able to reach it anymore and the only way to get it back running seems to be a hardreset and some experimentation….
Do you have any idea or advice?
I would be very grateful!
Thanks in advance,
Armando
Hi Armando,
We’re you updating the cloud key? Or just the other devices on the network.
If it was a failed upgrade, you should be able to reset it and restore a backup to get it to the state it was in prior.
Cheers
Stephen
Hi Stephen,
thx for the quick reply.
First I was updating the CloudKey. Everything went fine.
Then I wanted to update all other exisiting Unifi-Devices in my network (3 Switches, 2 APs). After clicking on “update” on the Switch, the CloudKey is directly connected to (via Port 8 PoE), the webinterface stuck after a while an now the CloudKey isn`t reachable anymore.
Not reachable means the webinterface. Pings are partilly – not consistently – sucessful. Doesn`t look good in any way,…
BR
Armando
Hi Armando,
Since the unit is being powered by PoE, was it gracefully shutdown before the switch restarted (and possibly restarted the cloud key)?
I’m wondering if it may have been corrupted, if it was reset without a proper shutdown.
If troubleshooting fails and you can’t get it working by doing the usual (restarting it), then I’d recommend restoring your last backup after a reset.
Cheers,
Stephen
Good question. To be honest, I don’t know. I think I already ran into that Problem, the last time I was updating my UniFi Devices, but then have been busy with adopting that switch after resetting (glad I found your article 😉 and forgot it.
So this is a behavior, which should be corrected by Ubiquiti, I would say. Otherwise everybody, who’s connecting a Cloud Key this way, will ran into that problem. Failure by design?
Will give a feedback after reset and restore of the Cloud Key – when I’ll find time to it.
For now, thank you very, very much so far!
BR
Armando
It’s just a consideration that needs to be taken in to account when updating the infrastructure.
I hope the post and responses helped! 🙂
Cheers,
Stephen
Hi Stephen,
it took a while to get back to this.
I found out the following.
I have two different versions of US-8 Switches (USW-8P (old) | USC-8P (new)). Ubiquiti changed to ARM processors some time ago and so the Switches, which look exactly the same (and are labeled the same), differ from the old ones (cli VS. icli etc.).
Having the CloudKey connected to the USC-Switch (Port with PoE pass-through) leads to the known probs.
Then I changed the USC with the USW-Switch and now everything works fine…
Maybe someone else is facing the same problems.
However, now I can do updates without “kicking myself out”.
Hope that helps.
BR
Armando
You can read more here for example:
Hi Stephan,
I am in the process of migration my network from mikrotik to unifi, the first question which came up was how to handle provisioning without a native vlan. So your write up helps a lot. thx
I run a Sophos XG in front of the unifi switches but I realized that I can’t set up an A Record without a suffix.
e.g. “test.dns.com” resolves fine if set up as static dns host in Sophos. But “unifi” doesn’t work this way, since a suffix is missing.
How did you solve that?
Best
Pete
Hi Pete,
Happy to hear you’re moving to UniFi, it’s great!
As for your question, on my internal network I have a full Active Directory configured with a domain name. My Domain controllers actually handle DNS and DHCP for my network.
Additionally, I have a Sophos UTM, which provides DHCP and DNS for a few other VLANs/Subnets, such as my native untagged VLAN.
What I would recommend, is just choose something that has relevance that doesn’t actually exist. For example “MyLAN.local” or “StephenLAN.local”, and use that as an internal domain. Then from there, configure your DHCP/DNS to use that as the domain for IPs issues, DNS records, etc.
I’ve never actually been asked this, so I just came up with that, I’m not quite sure if it’s best practice nor not.
Alternatively, if you do own a domain, you can use that internally as well, and just make sure you replicate the real DNS records on to your internal DNS so your external lookups function.
Hope this helps!
Cheers,
Stephen
thanks for your quick replay.
maybe I misunderstood the concept of provisioning with unifi.
On every new device there is the address “http://unifi:8080/inform” preconfigured. I thought that is where the new device expect the unifi controller. Is this correct?
I could set up a static dns entry in Sophos like “unifi.local” which does resolve fine. But then I need to change the inform address on every new device via ssh to “http://unifi.local:8080/inform. Which is not the best way to provision.
Hey Stephen,
I couldn’t make DNS on Sophos work but DHCP 43 does work well.
However while testing several provisioning scenarios I figured out the following:
I put my unifi switch as well as the unifi controller in VLAN2 which is my management network. Whenever I deploy a switch I set up dedicated access ports for each and every VLAN available on in this network. Just for the case that something goes really wrong.
I plugged in a brand new 8 port switch into the dedicated VLAN2 access port and immediately the switch showed up in unifi controller and I could adopt it.
So my questions is, why do you then still need vlan1 as well as routing on your firewall between VLAN1 and VLAN2 (or whatever your management vlan is)?
Furthermore this way, I also don’t need static dns entries or DHCP 43.
Best
Pete
Hi Pete,
I did it my way so that any UniFi device could be plugged in to an untagged network port, and be able to be adoptable. Also, so that if any other devices were plugged in, they wouldn’t have access to any network resources. The Untagged network is strictly locked down and only allows traffic to the controller in my environment.
By having “access ports”, this allows any device to plug in and have access to network resources, which I did not want.
In an office environment, this would help protect against unauthorized users, or people plugging devices in to the network, as they would be on the untagged VLAN and have access to nothing.
Also, in my environment I have many VLANs with different purposes, so with them being routable, I can configure firewall rules between the different VLANs and subnets to restrict traffic for security.
Hope this helps explain.
Cheers,
Stephen
alright,
I see your point. thx
It’s a matter of having devices in untrusted environments where strangers could plug in devices by their own, while having many VLANs with different purposes is a different topic and not necessarily related to VLAN1 and provisioning of unifi devices.
It’s that, and I just like to have everything organized and a process for everything 🙂
I totally agree.
As I said, I am new to unifi coming from cisco, mikrotik etc. and when reading about the provisioning part of unifi I felt like this could become complicated. Especially if you like to run a dedicated management vlan, as I usually do.
So far, unifi deployment is maybe too easy and if you have the common networking theory in mind, this seems to make things rather more complicated than reality is. 😉
Thanks for the article. I learned a lot about Ubiquiti in such a concise article.
I am working with a system set up by another engineer, and I am used to HP, Extreme and Cisco who handle VLANS differently. Could you please clarify one thing?
I have a Ubiquiti US-48 with PoE and NanoHD AP’s. You say that the AP needs to be adopted on VLAN 1, but than can be moved to a different management VLAN (2 for example).
How do I configure the Ubiquiti switch port? By default I think they use “All” which I understand to mean VLAN 1 untagged, and all the rest tagged. Will the AP automatically tag it’s management traffic or do I have to alter the port’s VLAN? If I have to change the port’s VLAN, what is the proper way to set it up?
Thanks and keep up the good work. I’m glad I found your site.
Hey Tom,
Thanks for the feedback and your kind words!
Now to answer your question. That is correct, by default the ports should all be trunk ports, all trunks available (tagged), and VLAN 1 (untagged).
The way I designed my network (and others may be different), is that I just wanted to plug and play UniFi devices and have them auto-configure, however I wanted my Management VLAN to be different than the default untagged.
When a device is connected, it gets DHCP IP and looks for “unifi” and attempts to adopt. The untagged VLAN 1 is a restricted VLAN that is fully routable to my other subnets/VLANs, however it’s heavily firewalled to ONLY allow traffic to the UniFi controller (and a few other services).
After the new UniFi device shows up in the controller, I adopt it, and then go to it’s configuration and change the management VLAN. The device will then update the config, and attempt to DHCP on the management VLAN and from that point on, only use it for management.
Typically, you don’t want to touch the ports configuration as the UniFi devices typically need access to all VLANs (in my case I have 5 wireless networks all on different VLANs, so the AP has to have access to all those on the trunk).
Inside of the UniFi controller, after the device is adopted, is where you would modify and change the UniFi devices management VLAN to your preferred VLAN.
Again, keep in mind for this scenario to work, both the untagged VLAN 1 as well as the management VLAN will need to have access to the UniFi controller.
Hope this helps!
Cheers,
Stephen
Thanks again Stephen.
I think I understand better now and will try what I have learned when I can get back on site.
Ubiquiti is definitely a little different. To have it automatically move the AP-to-Controller traffic to a tagged vlan is convenient but a little confusing. I could certainly wish for some better documentation!
Tom
Hello,
I am trying to do this but am missing something I think. I have quite a bit of Unifi gear, used it for over a yeat and have been using a separate Management VLAN. I am trying to achieve the adoption & security functionality mentioned using VLAN 1 (I am using a pfSense Firewall, not Unifi) … It’s just better !! 🙂
My problem is I do not see how a firewall can secure VLAN 1 if it is not associated with a subnet ? pfSense is typical of most firewalls in that it cannot filter anything unless it has IP addresses to work with.
What am I missing ?
BRgds/Alan
Hi Alan,
Whatever device you’re using for firewalling and routing will have to have an IP address on each subnet it routes (this is also the IP address the devices on each subnet use as a gateway).
Cheers
Stephen
Thanks Stephen,
So you mean you create a subnet to associate with VLAN 1 which is basically only used for the cloudkey and adoptions ?
BRgds/Alan
Hi Alan,
Yes, that’s the case. I have another blog post that covers this method if you give the site a search.
Hi Stephen
Thank you again for your very helpfull guidance in configuring VLAN on Unifi Controller.
Your assistance helped understand what should be done for changing the default Management VLAN in the Unifi Controller. and what type of Network to choose when not using Unifi Security Gateway or Unifi Dream Machine.
Very helpfull
Thank you
Best Regards
RedaDZ
Glad it helped!
Hi Stephen,
Thank you for your thread responses to answer questions.
From your 8/11 reply to Tom – “Inside of the UniFi controller, after the device is adopted, is where you would modify and change the UniFi devices management VLAN to your preferred VLAN.”
Where/How? I do not see this. Our US-48 is running 5.76.7.13442.
Our problem is the switch provisions, but as soon as we change the profile, we lose contact.
Dan
Hi Dan,
If you change the Management VLAN for a specific device, the new network it sits on has to be routable to the VLAN and/or subnet that the controller resides on.
Are these networks routable?
Cheers,
Stephen
Hi Stephen, I would like to change my management vlan 1 in UDM PRO, to a tagged vlan within the device. The only solution I found, which your article inspired me, was a firewall rule from it’s new management vlan pointing to the ip address of the controller. Then modifying each device to the new management vlan workd for me. But im not sure if this way of procceding is quite secure. How Im going to work a better solution out ?
Thx for oyur help
Best Regards Andy
Thanks for posting this!
Hi Stephen, Can a USW-Pro-24-PoE be used as a router for Vlans? I’m having an issue getting the Vlans to establish an internet connection. I’m doing a test lab and I have setup one port on the USW to be used as vlan10. The device that is connect does get the correct ip address and everything but I cannot get out to the internet and I cannot communicate with any other devices.
Hi mj,
I just did a quick check, and it appears the USW-Pro-24-PoE does support intra-VLAN routing. You should be able to have it perform VLAN routing on the different subnets inside of your LAN. I’d recommend checking to see if the routing is functioning before troubleshooting the internet issue.
As for the internet issue, what are you using to act as your internet router? And have you configured your routing to send all traffic to the device that’s performing your WAN routing? You’ll also need to make sure that your internet router accepts traffic from all the different subnets (in case it has any ACLs or security restrictions that might be blocking internet access from subnets other than it’s own).
Cheers,
Stephen