Switch unreachable after changing native VLAN on cloud key

I have some trouble setting up my Netgate SG6100 firewall with a USW-Pro-Max-16-PoE Unifi switch with a Unifi Cloud Key Gen 2.
The problem is after I have changed the native VLAN configuration of the CK from default VLAN 1 to the Managements VLAN 20, I totally lost connection to the switch. That is, the cloud key is running as are the two access points connected to the same switch, but the switch is showing “off-line” in the cloud key dashboard. Also, I do have normal internet access so the switch is doing its normal job, only this is I can’t access it anymore.

I have found much information on Tom’s video of configuring pfSense with Unifi equipment, but unfortunately haven’t found an answer yet on how to recover from this situation.
The link to Tom’s video is found here: https://youtu.be/WMyz7SVlrgc?si=KvKPPqvFG85N-r9n

The main question I have are basically:

  1. How to regain access to both Cloud Key and Switch again?
  2. What are the proper steps to get both Cloud Key AND Switch to have an IP assigned in the Management VLAN 20 Subnet instead of native VLAN 20?

Many thanks in advance for any help or support on this one.

I have a video on how to setup management VLAN with UniFi but it’s not really needed since the UniFi control plane is encrypted and it makes the UniFi setups more complex without adding any real value. If you can’t get a VLAN defined to access the systems you already switched you would have to reset those devices.

Each Unifi device gets configured with a specific IP or hostname value for the controller. If the switch is still trying to reach the controller’s old IP, you’ll have to SSH into it and update it with the “set-inform” command (you can search online for how to use the set-inform command). To find the SSH information for the switch, go to Settings > System > General and look for “Device SSH Authentication”. If this wasn’t already checked, then the current config of the switch does not have SSH enabled, and you will need to default the switch config and change the cloud key’s IP back to what it was before, then you can re-adopt the switch.

I presume you also have the APs in VLAN 20. The reason they can reach the controller (have the updated IP address) is that the controller sends a broadcast packet out with its current IP, and so anything Unifi in that VLAN sees that and starts using the new IP.

Hi Tom,
Thanks for pointing to that second video, I haven’t yet seen it so it’s been very helpful watching the video!
The reason I wanted to have the Unifi on a separate Management VLAN, is to keep everything on one subnet, insert of using VLAN 20 (Management) AND VLAN 1.
From your video, correct me if I’m wrong, I have two options:

  1. Try to put the Unifi devices on the separate management VLAN, or
  2. Use the native VLAN 1 as the dedicated management VLAN and move other devices currently on the ‘old’ management VLAN 20 to the ‘new’ VLAN 1 management VLAN.

Although I might prefer the first option, I also don’t have a problem to go for option 2.
However, this still leaves me to have an unreachable switch at the moment.
And yes, just like you described in the video, everything still keeps on working, even when it says offline.

I prefer this as it’s not really an issues and I have all my other networks as VLANs. It has the bonus of making Cisco people very angry.

Also try the method @brwainer suggested above.

Thanks for the details info.
Unfortunately, I haven’t enabled the SSH function on the switch, so I’m afraid I will need to reset it to it’s factory defaults.

I will switch over to the native VLAN 1 as the management VLAN and see if I will delete the current management VLAN 20 or find another purpose for it.

One question left:
If I do a factory reset of the switch alone, will the old configuration be restored from the cloud key, or will this restore all connectivity back and I will need to reconfigure it myself?

I think, but I have not tested, you should be able to reset, adopt, then copy the old settings over to the new switch. I know this works when replacing a switch but since this will have the same MAC address I am not certain.

No, unfortunately what happens is the controller sees the same MAC and gets in a logic loop where it expects that device to be communicating using its key. The device status will showing “Getting Ready” but nothing ever happens. The device’s private key is not kept by the controller, and as far as I know (I haven’t tested this in a few years) there is no way to indicate that you want to re-adopt the device (generate a new key pair for it but keep all other settings the same) because it was reset. Not doing this automatically is a security measure, because otherwise someone could spoof a device talking to the controller and then get your device configs.

As I said though, I haven’t tested this in a few years. Maybe in the meantime they have added a re-adopt button if a device reconnects to the controller.

1 Like