OPNsense Forum

I am transitioning from pfSense to OPNsense, and decided to also update some parts of my network to implement best practices. Unfortunately, now I cannot get internet access for my LAN and VLANs, yet can get it on my "DEBUG" interface...

Here's my network setup:

OPNsense "WAN" (bge3) interface <--> Fiber modem
OPNsense "DEBUG" (bge0) interface <--> PC (This works and provides internet)

For my VLANs (All assigned to ix0 interface, each with static IP and enabled with DHCP):

VLAN 1: "ROUTING" (The idea was to use this for the trunks and routing in the rack, and have LAN as separate VLAN)
VLAN 10: "LAN"
VLAN 99: "NOT"
VLAN 107: "IOT"

OPNsense ix0 interface <--> Unifi Dream Machine Pro (Tagged, Allow All, Native VLAN 1) <--> USW Pro HD 24 (Tagged, Allow All, Native VLAN 1) <--> USW Pro Max 16 PoE (Tagged, Allow All, Native VLAN 1) <--> Unifi AP (Tagged, Allow All, Native VLAN 1)

Since I have two USW switches daisy chained, I was thinking that it has something to do with what I have each port set to in the chain, but tried many permutations and no joy. As example, the connection from the Dream Machine to the 24-port switch is to one of the SFP ports (Tagged, Allow All) and then exits via another SFP port (also set to Tagged, Allow All), then to the SFP port on the 16-port (same - Tagged, Allow All) before the AP port (Tagged, Allow All).

What should the Native VLAN be for each of those steps in the chain? I thought that it would drop packets that enter the trunk if it matches the Native VLAN setting of the trunk port, but setting it to None (what I thought should make it a true trunk) caused no traffic to pass - but setting them all to 1 (not intuitive, but what I have them all set to now) is the closest I've got - at least I can manage all of the switches, but I cannot get internet access on any of the ports (hardwired or WiFi). Yet plugging directly into the back of the OPNsense server on the "DEBUG" interface I created works fine.

I am using Unbound DNS and it's listening on all interfaces.
The WiFi and hardwired connections I am trying are for the LAN VLAN (#10), even with "allow any" rules for VLANs 1 and 10.

Thoughts?

1. You need to create firewall rules for each but the first (V)LAN (this already has an "allow any -> any" rule).
2. You should not mix tagged and untagged VLANs on the same interface (it causes all kinds of subtle problems). Unifi does this and even prefers it, you did well to separate all VLANs on one pyhsical interface and untagged DEBUG on another.
3. Be careful / do not use VLAN 1: Many manufacturers, including Ubiquiti, use that to denote "untagged". For some, it it only how they handle the untagged (V)LAN internally, others handle VLAN 1 and untagged the same. If you do not want to think about this, simply do not use it.

Some UniFi related posts I have made recently together with some stuff you might also need since you are no longer using an UniFi Router as the Main Router :
- https://forum.opnsense.org/index.php?topic=50632.msg258782#msg258782
- https://forum.opnsense.org/index.php?topic=51014.msg260965#msg260965
- https://forum.opnsense.org/index.php?topic=51054.msg261171#msg261171
- https://forum.opnsense.org/index.php?topic=50960.msg261589#msg261589
- https://forum.opnsense.org/index.php?topic=51099.msg261506#msg261506
- https://forum.opnsense.org/index.php?topic=51099.msg261563#msg261563
- https://forum.opnsense.org/index.php?topic=51118.msg261610#msg261610

Let me know if you need anything else : UniFi Switches + In Wall Accesspoints + OPNsense are running just fine here! :)

Ok, thanks for the tips. I tore-down the whole system and rebuilt it - it's better, but it's not working yet.

Now, I can connect to the Unifi APs, and am given a valid IP address from DHCP... but no internet access. I am given the firewall IP (192.168.1.1) for the DNS, which is correct since I'm using Unbound. Again, using the other NIC port setup on my OPNsense box as "DEBUG" with a different IP range works and has internet access.

Everything looks much better in my Unifi Network now (Dream Machine Pro) - none of the devices are dropping in/out and all switches and APs are identified - though I set them to use unique static IPs as they kept falling back to the 192.168.1.20 default which was causing chaos. They didn't appear to get their static ARP addresses from the DHCP server in OPNsense.

I believe that it must still be something with the tagging/trunking on my Unifi chain, if you could take a look - I made a picture to make it easier to follow, this is what I have now:

OPNsense Layout.png

Some more data points:

• While I can access the internet and any of the other VLANs through an untagged VLAN 10 port on the 24-port switch, I cannot access the Dream Machine's WebGUI, which has a static IP address of 192.168.1.2 on VLAN 1. VLAN 10 is configured as 192.168.1.1/24, so why can I not reach 192.168.1.2 on VLAN 1?
• The AP on the 16-port switch allows clients to connect, they get the correct IP and DNS depending on the VLAN subnet, but I cannot get internet access on WiFi. Not even by forcing a public DNS with a static IP address - the clients simply cannot get out to the net, even though the hardwired connections in the same switch can.

Is there anything in OPNsense that I can use to better diagnose what's going on? Or is it simply a problem I have with the tagging/VLANs that is a Unifi issue?

Did you actually create firewall rules (see #1 from my previous post)? Or do you expect that it works without them (hint: it doesn't)?

You need to explain what role the Dream Machine has in your setup. By default it is a network controller, a router, DHCP server and a firewall and lots more. You need to turn off all features except the network controller app or you'll run the risk of services on OPNsense and Dream machine competing against each other.

Also, the OPNsense needs to be connected to one of the internal ports of the dream machine, not one of its WAN ports.

To avoid all of these problems, you may be better off with a Unifi CloudKey or just the Unifi Network Application running on a server instead of the Dream Machine.

Assuming you got that right, let's start with the fact that you didn't mention which VLAN is used for the management network of your unifi devices (the one they use to communicate with the network app). Assuming it is 1, the Unifi default, your OPNsense will never see any traffic on that network as it doesn't have an interface on it. Consequentially, your Unifi Switches and APs never get an answer from DHCP and fall back to their default 192.168.1.20.

In terms of debugging: Turn on logging of all your firewall rules and the default rules to see what your OPNsense sees and drops or allows. And, as mentioned by meyergru, OPNsense follows the philosophy of "deny by default", i.e. no traffic is accepted unless explicitly configured. In contrast, Unifi firewalls are "allow by default" if I remember correctly.

@mooh is correct abount VLAN 1 (untagged) as being the Unifi management network by default. It can be done differently, but it is hard to do.

From your first post, I assumed that your DEBUG network is VLAN 1 (untagged) connected to another port on the switch. That is what I meant by "you did well to separate all VLANs on one physical interface and untagged DEBUG on another". Actually, you have the management network completely separated, which will most probably not work.

Of course, that assumes you actually connect that OpnSense port to an untagged port on your switch. By doing that, you have all tagged ports in OpnSense on one physical port and the untagged port on another, thereby following the rule "do not mix tagged and untagged VLANs on the same port".

Quote from: Yosh1 on March 03, 2026, 02:26:29 AMEverything looks much better in my Unifi Network now (Dream Machine Pro) - none of the devices are dropping in/out and all switches and APs are identified - though I set them to use unique static IPs as they kept falling back to the 192.168.1.20 default which was causing chaos. They didn't appear to get their static ARP addresses from the DHCP server in OPNsense.

Another TIP :

Make sure you have got both Static IP Addressing and Static DHCP Mappings configured on/for all your Switches and Accesspoints !!

I have done it like this :

- 192.168.1.1 to 192.168.1.9 = Routers & Pi-Hole + Unbound Server.
- 192.168.1.10 to 192.168.1.19 = Core Switches
- 192.168.1.20 to 192.168.1.29 = Client Switches
- 192.168.1.30 to 192.168.1.39 = Indoor Accesspoints
- 192.168.1.40 to 192.168.1.49 = Outdoor Accesspoints

This way you always know what to expect when you connect to them via SSH based on their IP Address :)

In fact, I would never use that subnet at all for the reasons explained here (https://forum.opnsense.org/index.php?topic=47099).

Quote from: meyergru on March 03, 2026, 05:37:55 PMIn fact, I would never use that subnet at all for the reasons explained here (https://forum.opnsense.org/index.php?topic=47099).

And you are right! :)


But...


- Ubiquiti UniFi devices and anything outside that range can be a mess when something goes wrong :(
- The chance of me EVER needing/using a VPN is pretty much ZERO.
- I am well aware of VPN IPv4 Address Range conflicts for at least 10 to 15 years now so if I absolutely need to change something at some point then so be it...

For my layout, I like my trusted devices ("LAN") to be in the 192.168.1.1-255 range - just muscle memory. My existing network uses that range, with many uses based on existing static IP addresses that would be a lot of work to change now.
For my VLANs, I set the 3rd octet to match the VLAN ID (e.g. 192.168.107.1 for the "IOT" VLAN 107).

To fix the VLAN 1 issue, I now have OPNsense setup with a trunk to it (no native, only Allow All for tagged) that is intended to carry all of the VLANs other than 1. I am now setting up the untagged VLAN 1 network:
When I setup OPNsense, I set the "lan" (what OPNsense refers to it as) on a spare NIC (bge1). WAN is on bge0. I didn't have that going anywhere, so I have now enabled it in OPNsense as "MGMT" (Management), but I don't know what to do from there. I figure that it will need a static IP address assigned? But then how do I prevent it from interfering with my "LAN" (VLAN 10) network, which has the gateway at 192.168.1.1. It's just needed for routing the management network (e.g. switch-to-switch, APs to switch), so I figure that it will need a firewall rule to allow any? But if I set a static IP (say 192.168.1.5/32), how do I make the Unifi devices use it? Set them to use a gateway of 192.168.1.5?

Everything is turned off on the Dream Machine. I just use it as a controller for the Unifi devices, as I like its form-factor. The standard LAN is set to 192.168.1/24, with it's own IP set as a static 192.168.1.2.

No, I meant DEBUG is what most people call "management network", not to connect WAN to your switch.

To be exakt: Unifi wants its management network to be "VLAN 1" (= untagged), and you can define any user networks as VLANs, yet OpnSense does not like mixing tagged and untagged networks on the same NIC. So, you could use your DEBUG network of 192.168.3.1/24 as management network on VLAN 1 (untagged) with one separate physical of OpnSense connected to that via the switch and another NIC with all of the "real" (= tagged) VLANs. WAN is still on a separate NIC connected to your OpnSense only.

By doing this you avoid using 192.168.1.0/24 altogether, BTW. This might come in handy once you find that your DSL modem or ONT uses 192.168.1.1/24. If you did use that for your management network (or any other (V)LAN, you would have a hard time to access the ONT web interface on another OpnSense NIC.

And sure, you turn DHCP off on your dream machine and use DHCP only from your OpnSense. This will also assign all Unifi devices their IPs, except maybe for your dream machine, which presumably has a static IP that you must assign yourself (like 192.168.3.2/24 in this example).

I think you misread my "DEBUG" network - it's 192.168.3.1, not 192.168.1.3. I use it to prevent myself from being locked-out when working with the 192.168.1.1 range, as it's a separate NIC with it's own DHCP server.

I am now looking at setting it up as you suggest. What IPs/parameters would I set for the following:

• "Management" VLAN 1 setup in OPNsense. Has it's own NIC port on OPNsense and is tied to an untagged/native VLAN 1 port in the Unifi switch.
• UDM Pro setup. Right now I have the "Dream Machine Router" set to 192.168.1.2, with DHCP and other services turned off. "3rd Party Gateway" entries for each of the VLANs (#'s 10, 99, 107)
• "LAN" VLAN 10 in OPNsense. Would like to access the VLAN 1 devices, if possible (connect to UDM Pro to see network controller)
• All other VLANs in OPNsense. Currently have them all set as VLANs on top of ix0 interface (separate NIC), which is tied to an Allow All tagged and no untagged/native in the Unifi switch

Any specific DNS or firewall rules that I should be aware of? I currently just have Allow Any rules for MGMT (VLAN 1) and LAN (VLAN 10) networks.

I had a typo, of course I meant 192.168.3.1/24. That would be the management network on VLAN 1 (untagged).

The UDM Pro would also be on VLAN 1 with 192.168.3.2/24, gateway = 192.168.3.1 (OpnSense). The other VLANs can be defined, but the UDM Pro does not enable DHCP for any of those. Thus, the port it connects to on the switch must be a trunk with untagged VLAN 1 and all VLANs. That is just because the UDM Pro still ist the network controller for the APs and switches.

I like to have the third octet of the network be set the same as the VLAN, so VLAN 10 would be 192.168.10.0/24 a.s.o. The management network is an exemption, because it has VLAN 1 (= untagged).

The OpnSense has two legs, one untagged on one port and one as trunk with all the other VLANs. You can connect that second leg as trunk to the switch as well (it is only that the "parent" NIC for all the VLANs will not be configured on OpnSense.

You will have to define a PASS ALL rule for all VLANs (including MANAGEMENT) to "any" first, to see all of those get internet access.
Of course, this will enable to access any other VLAN, first. Then, you can put block rules before the "PASS ALL" rule to inhibit access from any VLAN as you wish. Usually, that would mean than you LAN (VLAN 10) will either not have any block rule at all or only to the management VLAN.
You can also define specific MAC or IP aliases on your LAN to pass to the MANAGEMENT VLAN.

For most other VLANs, you will most probably want a blocking rule including the "VLAN net"s (there are pre-defined network range aliases for any OpnSense network interface) of all other local VLANs or even a self-created alias including all RFC1918 networks. This is safe, because local traffic in any local VLAN does not pass OpnSense, so it does not block traffic for itself.

Of course, that RFC1918 block rule would also block access to OpnSense services, like DNS, NTP and others. Thus, you will have to specify rules to allow those types of traffic even before your "block RFC1918" rule.

Typically, what you will end up with is a set of rules like these on each interface:

1. Allow specific traffic to OpnSense services (like NTP or DNS).
2. Allow specific clients to do "anything they want" (i.e. your management clients).
3. Block access to specific local networks (like the management network or all other VLANs or even RFC1918).
4. Allow to "any" (i.e. internet access).

How you do that is up to you, however, when you first start out with the "ALLOW ANY" rules as depicted, everything should work and you can set limits from there. Note, that you will find many discussions here where people fight over the pros and cons of one way or the other to do it (e.g. "block RFC1918 rule before allow any" or "allow only to !RFC1918.", combining #3 and #4 above). Even "RFC1918" as an alias is debatable, see: https://forum.opnsense.org/index.php?topic=46094.0

Unifi's "native" intra-vlan L3 routing for switches is handled on vlan 4040, with the default addressing for that vlan as 10.255.253.0/24.  If no devices exist on that subnet when you enable a native Unifi vlan it will assign whatever device that is handling the routing the address 10.255.253.1.

I had been using opnsense as the gateway for all my vlans, but now I'm working through the process to try and migrate the vlan gateways to the Unifi environment.  opnsense needs to first have a vlan device tagged to vlan 4040 on one of your interfaces and configured with the IP address 10.255.253.1.  When you enable the native VLANs on the Unifi switch the switch will automatically create the interface on the Unifi device with the IP 10.255.253.2.  This becomes the transit interface for L3 routing from the Unifi switch to the opnsense firewall.

There are pros and cons here - the main pro being lower latency for LAN traffic.  The con is that ACLs on the Unifi switch are stateless so you don't get as much visibility and control of traffic between VLANs.  If you have IoT or other less trusted VLANs this might require a hybrid configuration where the gateway for more trusted VLANs like home wireless is the Unifi switch while less trusted like IoT use the opnsense firewall as the gateway to allow for stateful rules to manage traffic.

There are some oddities that I am still working through.  My management interface for the Unifi switches is on vlan 1 (untagged) and I am currently seeing lower latency but extremely slow HTTPS traffic with what looks like state errors coming back from the Internet routing in a weird direction.  kea also isn't properly assigning DHCP addresses; I haven't tried with dnsmasq yet.  The solution seems to be moving the management interface on all Unifi devices (as well as the Unifi OS/Unifi network server) to a tagged VLAN managed by the Unifi switch.  It may also require the use of sloppy states, but I haven't gotten that far yet.

Not sure if anyone else (meyergru?) has a Unifi setup where they could experiment with this design.

I do not use L3 routing on my switches, even if they had it. I did not even know how Unifi does that. With their consumer-level switches, they do not offer it, also, with smaller networks, I prefer to have all routing controlled by OpnSense itself.

L3 switching is something that IMHO is relevant only for enterprise-grade installations. Everything I depicted here is strictly L2 on the switches.

Thanks @meyergru for the help. I made the adjustments as you proposed, but kept them on 1 for the 3rd octet:

• UDM: 192.168.1.2/24
  
  • DHCP disabled
  • DHCP Relay to 192.168.1.1
  • All other options disabled (e.g. no DHCP guarding, no isolation)
• OPNsense "MGMT" (VLAN 1): 192.168.1.1/24
  
  • Separate NIC port
  • Plugged into Unifi switch port: Untagged/Native VLAN 1, None tagged
  • No DHCP server... Is that correct?
• OPNsense "LAN" (VLAN 10): 192.168.1.5/24
  
  • Shared NIC port with other VLANs (But the physical interface is not assigned)
  • Plugged into Unifi switch port: No Untagged/Native, All tagged
  • I gave this a *.5 address so that I could enable a DHCP server on it... Is that correct?
    
    • DHCP server has range 192.168.1.160-192.168.1.250
    • DNS servers and gateway both set to "192.168.1.1"
• ** Disabled the other VLAN interfaces (99 & 107) for now, to simplify debugging
• Unbound DNS:
  
  • Network interfaces: All
  • Listen port 53
• Firewall rule for MGMT:
  
  • "Default allow any rule for MGMT"
  • Interface: MGMT
  • Version: IPv4
  • Protocol: *
  • Source: MGMT net
  • Source Port: *
  • Destination: *
  • Destination Port: *
  • Gateway: *
• Firewall rule for LAN:
  
  • "Default allow any rule for LAN"
  • Interface: LAN
  • Version: IPv4
  • Protocol: *
  • Source: LAN net
  • Source Port: *
  • Destination: *
  • Destination Port: *
  • Gateway: *

As it stands, I still cannot get out to the net from a device connected to VLAN 10 through a Unifi AP. The WiFi network is set to VLAN 10. The path between the switches and the AP is the same as I showed in the image in post #3 (Untagged with VLAN 1 and tagged with all). I connect to the WiFi, get an IP address from the DHCP server (it shows in Leases), the client gets "192.168.1.1" for the DNS server, but I cannot get out to the net.

I enabled logging for the pass any rules and see that there's a duplication of actions - an event shows on the "ix0" interface (the parent interface of all of the VLANs, which is not assigned to anything and is not enabled), which gets a "block" but the same exact event is then passed as the next event, now showing as the MGMT interface. What's going on? See image:


Screenshot 2026-03-03 165050.jpg

You cannot have the same network - 192.168.1.0/24 - on both MGMT and LAN. Also the gateway that the DHCP server gives to clients must be the OPNsense IP address in the relevant VLAN.

Right ... and you should enable DHCP on OpnSense for every connected local (V)LAN.

Since we are covering basic networking aspects now: Are you quite certain that OpnSense is right for you? ;-)

Maybe you should start reading here (https://forum.opnsense.org/index.php?topic=42985.0), because that is literally point 1 in that article. By deciding to "keep 192.168.1.x", you deliberately chose to not use a configuration pattern I explained, which by itself guarantees that such things do not happen. You will find that more often than not, there are best practices for a reason.

I'd say thanks for the help, as I have found the issue, but you lost some credit when you switched to telling me to not use OPNsense because I was having an odd issue, which is disappointing. Perhaps you were just being cheeky, but everyone has to start somewhere when learning and forums are a means to learn - if I had all of the answers like you then I wouldn't need to be here. I'll now pass on what I learned to others.

I have solved the issues I was having and will write about it here, in case anyone else shows up with similar problems. It turns out there were two issues with the setup, coming from pfSense:

• The main issue was a simple checkbox. In the DHCP server setup, I had set static ARP entries for all of the networking devices (to prevent ARP spoofing) and so that I can use WOL for some of my systems. I had set one for my main desktop PC, which is what I was using for setup. I then checked the innocuous looking box in the DHCP server settings to "Enable Static ARP entries" thinking, sure, that will then enable the ones I defined in the static mappings table. Apparently that checkbox makes it so that only those defined devices can communicate, blocking all others, which is counter-intuitive - but I can replicate my issues by simply toggling that checkbox and the whole network goes down. When it was checked, it's why I was banging my head because my desktop PC had internet access, but no WiFi client did - the WiFi clients weren't in the static ARP entries list. Once I unchecked it, all of the WiFi and VLANs worked as normal and the network came alive and it's been working fine now.
• The best practice I was going for, by moving my private LAN to VLAN 10 is cumbersome with Unifi hardware. While you can change the APs to use a different management network, the switches do not seem to work on anything other than VLAN 1 (hardcoded). Since I had to use VLAN 1 for management to maintain control of my Unifi hardware, I was then working to move my trusted LAN to use VLAN 10, since you're not supposed to have an untagged port which matches one of the broadcast WiFi network VLANs (so I wasn't supposed to have a WiFi network for VLAN 1 and then had the port for the AP be untagged for VLAN 1 for management). That became hectic because I then had parallel paths into OPNsense because I wanted to maintain 192.168.1.1/24 (muscle memory) for my trusted LAN (now VLAN 10), yet provide a path for the management traffic (VLAN 1), keeping the UDM Pro (the network controller) in that same range for continuity (e.g. 192.168.1.2). It turns out that the Unifi hardware carves out a special case for VLAN 1 whereas there's a single note on their VLAN setup along that lines that simply "VLAN 1 is different and doesn't apply here". In short, you absolutely can use VLAN 1 for the native/untagged port of APs that broadcast a VLAN 1 SSID. My guess is that they specifically don't tag VLAN 1 traffic if the SSID uses VLAN 1 so that it gets its tag when it hits the untagged port - then it routes like normal. I removed all of the VLAN 10 assignments, went back to the way I had it with pfSense, and it's all been running fine - with all hardware reachable in the network controller and WiFi clients getting the appropriate IPs.(

With that solved, I now can enjoy not being tied to Netgate and their now closed-source pfSense and using the better Wireguard implementation for linking sites. I updated to the latest 26.1.3, which I can see that there's work being done to improve the UI for firewall rules, which I am looking forward to. Everything else is great, but I do miss the ability to apply colored separators with friendly names (e.g. a green bar with "Allow: DHCP and DNS" before those rules), like I had in pfSense, for organization. I am using the categories + tree view, which is workable, but is not as nice when comparing similar rules across different interfaces. It also seems like sorting when in tree view when looking at all rules can cause issues if you try to sort things, versus the old interface style of having separate tables for each interface.

Anyways, all good now - thanks for the assistance. Cheers.

Quote from: Yosh1 on March 04, 2026, 07:03:37 PMthanks for the assistance. Cheers.

Just added this : https://forum.opnsense.org/index.php?topic=50632.msg258782#msg258782
To my previous reply : https://forum.opnsense.org/index.php?topic=51127.msg261683#msg261683

IMHO that's all to it : Even with another Router in the game! :)

You noticed the smiley?

There have been discussions back and forth between switching the Unifi management VLAN from untagged (VLAN 1). I once did that and dialled everything back because you then have problems adopting new devices as they only respond on the untagged network. You would need a specifc "initial provisoning" port on your switch for that.

Altogether, I found that the best way (for me) is to stay with Unifi's default (i.e. having untagged/VLAN 1) as the main management network and have all user traffic on different VLANs. The only problem is that the untagged network is being used at all and this can be solved by using two physical interfaces on OpnSense. I like to have multiple interfaces connected to the switch anyway, to have more bandwitdh for inter-VLAN traffic.

Unifi works just fine with IP ranges different from 192.168.1.0/24 and I like to keep that free for ONT/modem access.

Quote from: meyergru on March 04, 2026, 11:32:25 PMI like to have multiple interfaces connected to the switch anyway, to have more bandwitdh for inter-VLAN traffic.

+1 :)

Quote from: Yosh1 on March 04, 2026, 07:03:37 PM..., but everyone has to start somewhere when learning and forums are a means to learn

People here try to help the best they can given the questions they see.

The OPNsense UI provides inline help text. You can either press the i button near a configuration item or make all help text all visible all the time with the "full help" setting near the top right corner. The help text for "Static ARP" says exactly what it does. BTW, DHCP reservations do nothing to prevent ARP spoofing.

Unifi switches can use any vlan for their management network just like all other Unifi gear. The tricky bit is that one needs a switch port (ideally with PoE) configured to that vlan to adopt any new devices, i.e. untag outgoing traffic, tag incoming traffic with the management vlan.

Quote from: mooh on March 05, 2026, 04:03:25 PMUnifi switches can use any vlan for their management network just like all other Unifi gear. The tricky bit is that one needs a switch port (ideally with PoE) configured to that vlan to adopt any new devices, i.e. untag outgoing traffic, tag incoming traffic with the management vlan.

Yeah, though this can bite in certain circumstances that I think are far more likely on a small home network.  Imagine if you only have a single UniFi switch and it either needs replacement or you need to reset it, and for whatever reason the controller isn't available or the switch can't find it.  You're now locked out with no network.  (I may have discovered this once or thrice in the beginning...)

The trouble with these switches, at least the one I have, is there is no OOB management access.  If it can't configure itself from the network you're dead in the water.

Quote from: OPNenthu on March 05, 2026, 10:30:51 PMThe trouble with these switches, at least the one I have, is there is no OOB management access.  If it can't configure itself from the network you're dead in the water.

Not entirely :
- Make sure it gets an IP Address.
- SSH to it.
- Telnet localhost.
- Play with your UniFi Switch as if it was an EdgeSwitch :)

Everything is gone after a reboot tho... :(

To give it an IP address needs a DHCP server on the UniFi default network, right?  So again VLAN 1 or native LAN (untagged) is required, unless you have a UniFi gateway.  Otherwise I guess you have to get to it by its default IP (192.168.1.20).

Does the CLI allow configuration of switch ports, even temporarily?  I wasn't aware.

--

EDIT: I found a 'swctrl' command on the Pro-Max-16, but the 'vlan set' option is not implemented it seems:

USWProMax16PoE-US2.7.1.26# swctrl vlan
Usage: swctrl vlan show id PORT_ID

where  PORT_ID := a list of target port, e.g., 3 or 5-7 or 1,4,9-12

USWProMax16PoE-US2.7.1.26# swctrl vlan set
swctrl[4597]: [error] swctrl.unknown_command(): Command "set" is unknown. Try option "help"

USWProMax16PoE-US2.7.1.26# swctrl vlan help
Usage: swctrl vlan show id PORT_ID
where  PORT_ID := a list of target port, e.g., 3 or 5-7 or 1,4,9-12

Even 'port set' only allows commands for up/down:

USWProMax16PoE-US2.7.1.26# swctrl port help
Usage: swctrl port set { up | down } [ id PORT_ID ]

       swctrl port restart id PORT_ID [ interval SECONDS ]

       swctrl port clear counters [ id PORT_ID ]

       swctrl port show [ id PORT_ID ] [ detail ]
                        counters [id PORT_ID]
                        mirror

where  PORT_ID := a list of target port, e.g., 3 or 5-7 or 1,4,9-12

I think just about the only thing I can do is call 'set-inform' to specify the controller location.  Maybe that's all that's needed, as long as the controller is reachable and already configured.

But to configure that requires a functional network, and without a functional switch you don't have that, and round-and-round I went.  That was the end of adventures with non-default management VLANs for me :P  I guess there's always a way to work around any problem but I don't know if the juice is always worth the squeeze, especially without a requisite amount of experience to be able to recognize the workaround.

What I would recommend to other beginners now is that even if you don't want to use the native LAN for management, at the very least keep a native LAN interface in OPNsense and a small dumb switch that you can use to provision a new UniFi setup in case of disaster.  You always need a fallback way to throw a switch, a controller, and a laptop together for bootstrapping.

...and there we go again. Yes, there may be circumventions. We can discuss that on a theoretical level just endlessly. Once you are in the actual situation your Unifi main switch dies and you need to replace it: Just try. Been there - done that.

Out of experience: You did not consider some things, say:

1. Maybe your Unifi Network Controller is on a VM on a Proxmox VE host which has a trunk port to your switch.
2. Maybe your OpnSense is also on a trunk port and has firewall rules to allow your management PC's MAC from the LAN to access the management VLAN.

Shall I continue? After the fact I can tell you the actual restoration workflow contains way more than the steps you imagine now.

It is a matter of a downtime of minutes vs. (at the very least) hours, trust me.

Therefore, I keep the management LAN untagged - the switch will then automatically connect to the Unifi Network Controller. Your only concern will be to reach the management LAN to make the UNC adopt the new switch and configure it.

Quote from: OPNenthu on March 05, 2026, 11:32:40 PMTo give it an IP address needs a DHCP server on the UniFi default network, right?

Yup!

QuoteSo again VLAN 1 or native LAN (untagged) is required, unless you have a UniFi gateway.

No need for any UniFi Router IMHO :)

QuoteOtherwise I guess you have to get to it by its default IP (192.168.1.20).

That's another option indeed!

QuoteDoes the CLI allow configuration of switch ports, even temporarily?  I wasn't aware.

Yup! :)

QuoteEDIT: I found a 'swctrl' command on the Pro-Max-16, but the 'vlan set' option is not implemented it seems:

Code Select Expand

USWProMax16PoE-US2.7.1.26# swctrl vlan set
swctrl[4597]: [error] swctrl.unknown_command(): Command "set" is unknown. Try option "help"


I used the command 'vlan' to do some quick fixing at the time.

Everything I needed to know was "stolen" from a quick check at 'show running' and before you knew it you are (dis)allowing vlans and stuff...

It was this specific by now older model : https://store.ui.com/us/en/products/us-8

QuoteI think just about the only thing I can do is call 'set-inform' to specify the controller location.

Maybe that's all that's needed, as long as the controller is reachable and already configured.

Well... that is the command to do exactly that and/or fix adoption issues so yeah :)

QuoteBut to configure that requires a functional network, and without a functional switch you don't have that, and round-and-round I went.
That was the end of adventures with non-default management VLANs for me :P

I guess it depends on what kind of other networking equipment you have got laying around and/or how your network is configured.

For example :
I have got one "Emergency Switch Port" on each of my Switches that brings me directly into the Management VLAN a.k.a. also UniFi Native VLAN in case something weird happens...

Even one of the In Wall UAPs has it because it's non-PoE Out Switch Port has no purpose at the specific spot.

QuoteI guess there's always a way to work around any problem but I don't know if the juice is always worth the squeeze, especially without a requisite amount of experience to be able to recognize the workaround.

I guess that's what this post is mainly about :

Quote from: meyergru on March 06, 2026, 08:58:03 AM...and there we go again. Yes, there may be circumventions. We can discuss that on a theoretical level just endlessly. Once you are in the actual situation your Unifi main switch dies and you need to replace it: Just try. Been there - done that.

Out of experience: You did not consider some things, say:

1. Maybe your Unifi Network Controller is on a VM on a Proxmox VE host which has a trunk port to your switch.
2. Maybe your OpnSense is also on a trunk port and has firewall rules to allow your management PC's MAC from the LAN to access the management VLAN.

Shall I continue? After the fact I can tell you the actual restoration workflow contains way more than the steps you imagine now.

It is a matter of a downtime of minutes vs. (at the very least) hours, trust me.

Therefore, I keep the management LAN untagged - the switch will then automatically connect to the Unifi Network Controller. Your only concern will be to reach the management LAN to make the UNC adopt the new switch and configure it.

And I completely agree, but it's simply nice to know your options in case of "disaster" be it your UniFi hardware or your OPNsense Router :)

Something like a week or two ago I read for the first time about https://github.com/opnsense/update#opnsense-bootstrap and now it's another tool I know about in case I end up in a situation that something went horribly wrong and my OPNsense is very close to a reinstall...



The more options, the better !!!