Since upgrading to 26.7.x.x, all my VLAN devices (192.168.20.x, 192.168.40.x) now have LAN IP addresses. Here's my configuration (ssh'd into the Protectli VP2420 box):
*** OPNsense.home.lan: OPNsense 26.7.1_1 (amd64) ***
DMZ (igc2) -> v4: 192.168.30.1/24 (Protectli hardware port 3, DMZ addresses are correct)
Guest (vlan01) -> v4: 192.168.20.1/24
IoT (vlan02) -> v4: 192.168.40.1/24
LAN (bridge0) -> v4: 192.168.1.1/24. (Protectli hardware port 1, routes to WiFi)
OPT4 (igc3) -> (Bridged to LAN for external devices)
WAN (igc1) -> v4/DHCP4. (Protectli hardware port 2)
------------------------------------------------------------------------------------
Interfaces: Assignments
wan WAN hardware igc1
lan LAN bridge bridge0 (LAN->OPT4 Bridge)
opt1 DMZ hardware igc2
opt2 Guest vlan vlan01 Guest_VLAN (Parent: igc0, Tag: 20)
opt3 IoT vlan vlan02 IoT_VLAN (Parent: igc0, Tag: 40)
opt4 OPT4 hardware igc3
opt5 OPT5 hardware igc0
BACK PANEL OF VP2420
___________________________________
| |
| [Port 4] [Port 3] [Port 2] [Port 1] <-- (Physical Labels)
| igc3 igc2 igc1 igc0 <-- (OPNsense OS Names)
|___________________________________|
Prior to the upgrade, all guest devices were assigned IP addresses in the 192.168.20.x space and all IoT devices were assigned IP addresses in the 192.168.40.x space. Now the ARP table shows all devices that are part of vlan01 (Guest) and vlan02 (IoT) having LAN IPs in 192.168.1.x space. I've tried rebooting several times but no luck. How do I get my VLAN IPs back? I don't want guests and IOT devices on my LAN.
The devices might get their IPs from the DHCP on OPNsense. That they get IPs assigned from the wrong subnet indicates, that they are able to communicate with the DHCP on the other subnet.
If you think, your OPNsense configuration is correct, check the subnet separation outside.
How did you do this? Which device is connected to port 1?
What is the purpose of the bridge? What are the member ports?
What are the parent interfaces for the VLAN interfaces?
Mixing bridges and VLAN tagging can be tricky...
Quote from: viragomann on August 02, 2026, 09:38:58 AMThe devices might get their IPs from the DHCP on OPNsense. That they get IPs assigned from the wrong subnet indicates, that they are able to communicate with the DHCP on the other subnet.
If you think, your OPNsense configuration is correct, check the subnet separation outside.
How did you do this? Which device is connected to port 1?
The configuration listed above worked fine under OPNSense 21.x. I am now aware that 26.7 doesn't like mixing an untagged LAN with tagged VLANs on the same interface port (igc0 is on Protectli's port 1). I had also bridged the LAN to igc3 on port 4 under 21.x after getting locked out of the wireless LAN during setup of the wireless AP. It's nice having a free external ethernet port available in case the wireless network goes down again but it's certainly not mandatory.
Can you post the output of "ifconfig -a", please? Redact external IP addresses. Private ones are not a security concern, but if you like, change them, too. I am after a full view of VLAN parent devices and bridge memberships.
Kind regards,
Patrick
Quote from: dseven on August 02, 2026, 10:32:17 AMWhat is the purpose of the bridge? What are the member ports?
What are the parent interfaces for the VLAN interfaces?
Mixing bridges and VLAN tagging can be tricky...
Quote from: dseven on August 02, 2026, 10:32:17 AMWhat is the purpose of the bridge? What are the member ports?
What are the parent interfaces for the VLAN interfaces?
Mixing bridges and VLAN tagging can be tricky...
The purpose of the bridge is to give LAN access to future hard-wired clients. Interface assignments are shown in the original post. The untagged LAN + both tagged VLANs are on igc0 (port 1 of the Protecli) and go ONLY to the Unifi AP. This worked fine up to and including OPNSense 21.x but I now understand that 26.7 doesn't seem to like mixing untagged and tagged frames on one port. I'm trying to setup a VLAN for the LAN so all three will be VLANs on igc0. I'm not sure if this is compatible with the bridge setup though.
Planned reconfiguration:
VLANs on igc0: vlan00 (LAN) + vlan01 (Guest) + vlan02 (IoT)
Must I remove the LAN bridge to make this work?
Quote from: Patrick M. Hausen on August 02, 2026, 09:14:19 PMCan you post the output of "ifconfig -a", please? Redact external IP addresses. Private ones are not a security concern, but if you like, change them, too. I am after a full view of VLAN parent devices and bridge memberships.
Kind regards,
Patrick
Hi Patrick, here you go:
igc0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 64:62:66:22:4c:ab
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 64:62:66:22:4c:ac
inet xx.xx.xx.xx netmask 0xfffff800 broadcast 255.255.255.255
inet6 x
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
igc2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: DMZ (opt1)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 00:e0:4c:68:1c:12
hwaddr 64:62:66:22:4c:ad
inet 192.168.30.1 netmask 0xffffff00 broadcast 192.168.30.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
igc3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: OPT4 (opt4)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 64:62:66:22:4c:ae
media: Ethernet autoselect
status: no carrier
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
pfsync0: flags=0 metric 0 mtu 1500
options=0
maxupd: 128 defer: off version: 1500
syncok: 1
groups: pfsync
pflog0: flags=1000141<UP,RUNNING,PROMISC,LOWER_UP> metric 0 mtu 33152
options=0
groups: pflog
vlan01: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Guest (opt2)
options=4000000<MEXTPG>
ether 64:62:66:22:4c:ab
inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vlan02: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: IoT (opt3)
options=4000000<MEXTPG>
ether 64:62:66:22:4c:ab
inet 192.168.40.1 netmask 0xffffff00 broadcast 192.168.40.255
groups: vlan
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
options=10<VLAN_HWTAGGING>
ether 58:9c:fc:10:4f:48
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
bridge flags=0<>
member: igc0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 1 priority 128 path cost 55 vlan protocol 802.1q
member: igc3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 4 priority 128 path cost 2000000 vlan protocol 802.1q
groups: bridge
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vlan00: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4000000<MEXTPG>
ether 64:62:66:22:4c:ab
groups: vlan
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Quote from: tonys on August 02, 2026, 09:45:45 PMThe purpose of the bridge is to give LAN access to future hard-wired clients. Interface assignments are shown in the original post. The untagged LAN + both tagged VLANs are on igc0 (port 1 of the Protecli) and go ONLY to the Unifi AP.
You didn't say anything about what's connected to igc0 in your original post.
Quote from: tonys on August 02, 2026, 09:45:45 PMThis worked fine up to and including OPNSense 21.x but I now understand that 26.7 doesn't seem to like mixing untagged and tagged frames on one port.
That's not true - I'm still doing it, and it works fine - although some people here will try to convince you that it's a terrible idea. Nothing changed in this regard between 26.1 and 26.7 AFAIK anyway.
Quote from: tonys on August 02, 2026, 09:45:45 PMMust I remove the LAN bridge to make this work?
I'm pretty sure you can't put a bridge on igc0 and also have VLAN interfaces on igc0 (and expect it to work) - do one or the other.
Life will generally be better if you just get rid of the bridge, IMO.
That would be readable much better in code tags like so - I trimmed it down to the essential parts.
igc0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
igc2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: DMZ (opt1)
igc3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: OPT4 (opt4)
vlan01: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Guest (opt2)
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
vlan02: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: IoT (opt3)
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
member: igc0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 1 priority 128 path cost 55 vlan protocol 802.1q
member: igc3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 4 priority 128 path cost 2000000 vlan protocol 802.1q
vlan00: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
Your problem is that even back in FreeBSD 14 (OPNsense 26.1) and earlier this is a forbidden configuration. A bridge member interface cannot have VLAN subinterfaces. Period. If it worked for your use case then by accident.
In FreeBSD 15 (OPNsense 26.7) the bridge now supports VLAN subinterfaces directly on the bridge interface. OPNsense does not use that feature yet, but the new bridge capability now triggers all sorts of weird behaviour with your faulty setup.
Recommendation: move LAN to an unused port and do not mix tagged and untagged interfaces in the same port. Remove igc0 from the bridge.
This is the only way to fix your problem.
Kind regards,
Patrick
Quote from: dseven on August 02, 2026, 09:52:07 PMThat's not true - I'm still doing it, and it works fine - although some people here will try to convince you that it's a terrible idea. Nothing changed in this regard between 26.1 and 26.7 AFAIK anyway.
You are right that it can and does work in specific situations. As you can see from this thread and my last reply the shit hits the fan when you add other features and e.g. make the untagged port member of a bridge. Then suddenly and very surprisingly all hell breaks loose.
So it is generally not recommended.
Once the new VLAN aware bridge code in FreeBSD 15 and up
- has stabilized
- is fully integrated into OPNsense including the UI
- is tested to work flawlessly with pf
there will be more up to date ways to turn your OPNsense box into a "software switch" but until then not mixing tagged and untagged is considered best practice unless you know very well what you are doing.
Kind regards,
Patrick
Perhaps, but I think the issues here are a bit orthogonal - someone could still fall into the trap of trying to put a bridge across multiple physical interfaces and then doing VLANs on top even if they weren't trying to mix tagged and untagged frames - that still won't work (until a possible future, where OPNsense harnesses the new "VLAN filtering bridge" functionality, as you say)
Quote from: tonys on August 02, 2026, 09:45:45 PMThe untagged LAN + both tagged VLANs are on igc0 (port 1 of the Protecli) and go ONLY to the Unifi AP.
If you need the VLAN 1 stuff for Ubiquiti UniFi equipment then this would be the right setup :
OPNsense :- NIC #1 = LAN Untagged
- NIC #2 = Additional Tagged VLANs
Add a Switch between OPNsense and the UniFi UAP :- Switch Port #1 = Untagged and connected to OPNsense NIC #1
- Switch Port #2 = Tagged and connected to OPNsense NIC #2
- Switch Port #3 that has PoE or PoE+ Output and carries :
Untagged LAN network from OPNsense NIC #1 coming from Switch Port #1
Tagged Additional VLANs from OPNsense NIC #2 coming from Switch Port #2
UniFi UAP :- Connected to Switch Port #3 that has PoE or PoE+ Output and is then reachable via VLAN 1 which will be the OPNsense LAN network from NIC #1.
- The WiFi SSIDs will then use all the Tagged Additional VLANs from OPNsense NIC #2.
I hope the above is clear enough and if you have questions then let me know :)
OK, so for better or for worse, I removed the LAN bridge completely. The new configuration is as follows (igc3 is now unconnected):
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
igc2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: DMZ (opt1)
igc3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
vlan00: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 1 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
vlan01: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
vlan02: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
While this seems to be correct, I can't figure out how to add the VLAN address ranges back in (i.e., I want vlan01 to be 192.168.20.x and vlan02 to be 192.168.40.x). Note that I also added vlan00 for the LAN address block of 192.168.1.x. Unfortunately, nothing has changed at all. All devices remain stuck on the LAN IPs. I used to be able to add interfaces opt2 and opt3 for the VLANs but I can't do this now. What am I doing wrong?
Another interesting thing is that the Unifi AP is seeing the proper tag names from the Guest and IoT VLANs even though they're all LAN IPs. I find this very confusing - how does the Unifi AP see the proper VLAN names but OPNSense doesn't assign the proper IPs? See the attached screen shot.
You can't use a VLAN interface for VLAN 1 unless it's tagged on whatever is (directly) connected to igc0. If that's a UniFi AP, VLAN 1 is probably not going to be tagged.
You'd need to assign your other VLAN interfaces (Interfaces -> Assignments), then configure them (Interfaces -> [Guest], etc), then setup the DHCP service(s) for them.
If you just have a single UniFi AP and no wired devices, you could assign igc0 to LAN (i.e. use it untagged, with Guest and IoT tagged), and accept that you'll burn in hell for it (I'll see you down there)... otherwise you're going to need a managed switch.
With Unifi, you actually can use VLAN 1, but it is tricky:
You can create a VLAN 1 and name it. And then, you can create a named port profile with no native VLAN and allow all tagged VLANs. If you do that, VLAN 1 will be tagged, too.
Matter-of-fact, I have two "trunk-type" port profiles, one with the usual setup where VLAN 1 is the "native" VLAN as usual, which is used for APs, uplinks and devices, where the native VLAN is 1 and one for OpnSense, where the "fully-tagged" port profile is used. This works perfectly.
You also can do "all tagged" on Unifi APs and switches as well, but the default is that they normally expect their management VLAN to be untagged, so adopting a new one in an otherwise "all tagged" network setup would require a special "adoption port" on the switch and after adoption, you would have to move the AP.
Therefore, the proposed setup better bridges the gap between OpnSense's "do not mix tagged and untagged on the same interface" and Unifi's expectations.
2026-08-03 09_15_40-Settings _ unifi — Mozilla Firefox.png 2026-08-03 09_14_46-Settings _ unifi — Mozilla Firefox.png
Quote from: meyergru on August 03, 2026, 09:16:42 AMYou also can do "all tagged" on Unifi APs and switches as well, but the default is that they normally expect their management VLAN to be untagged, so adopting a new one in an otherwise "all tagged" network setup would require a special "adoption port" on the switch and after adoption, you would have to move the AP.
Using TAGGED for Management Network purposes in combination with Ubiquiti UniFi products IMHO falls in this category too :
Quote from: dseven on August 03, 2026, 08:34:34 AMand accept that you'll burn in hell for it
LOL! :P
So... damned if you do, damned if you don't 🤣🤣
Quote from: dseven on August 03, 2026, 03:51:35 PMSo... damned if you do, damned if you don't 🤣🤣
Well... you shouldn't... so... you have got a choice... sort of... LOL! ^_^
I went back to my original configuration as posted in the beginning of this thread (listed from the SSH login to OPNSense):
*** OPNsense.home.lan: OPNsense 26.7.1_1 (amd64) ***
DMZ (igc2) -> v4: 192.168.30.1/24
Guest (vlan01) -> v4: 192.168.20.1/24
IoT (vlan02) -> v4: 192.168.40.1/24
LAN (igc0) -> v4: 192.168.1.1/24
WAN (igc1) -> v4/DHCP4: x.x.x.x
From one of my LAN devices (192.168.1.63), I attempted pings to the Guest (192.168.20.1) and IoT (192.168.40.1) vlans and there is no connectivity as expected. This means there are no leaks that could lead to bleeding FROM the LAN TO the Guest or IoT networks. Unfortunately, I still have no devices connecting on either vlan - all devices are getting LAN IPs. I don't see how to check for bleeding from the Guest or IOT vlans to the LAN since I can't get any device onto either vlan.
This is bad - the Guest and IoT devices have complete access to my LAN. How do I check for leakage if I can't get any devices to connected to either VLAN?
At the start, you had a bridge. Is that bridge now completely gone? Updated ifconfig output might be helpful.
Otherwise I'd tend to suspect that your WiFi is misconfigured...
Quote from: tonys on August 06, 2026, 02:03:39 AMI went back to my original configuration as posted in the beginning of this thread (listed from the SSH login to OPNSense)
So I could repeat my first post as well. ;-)
Quote from: tonys on August 06, 2026, 02:03:39 AMFrom one of my LAN devices (192.168.1.63), I attempted pings to the Guest (192.168.20.1) and IoT (192.168.40.1) vlans and there is no connectivity as expected. This means there are no leaks that could lead to bleeding FROM the LAN TO the Guest or IoT networks.
No. This just means, that there is no layer 3 leak, but VLANs must separate network segments at layer 2.
Explanation: When the (LAN) device tries to access an IP in another network segment it doesn't do ARP resolution, but sends to packets directly to the gateway, which is the firewall. If access to the other subnet isn't permitted here, the access fails of course.
Quote from: tonys on August 06, 2026, 02:03:39 AMUnfortunately, I still have no devices connecting on either vlan
However, to get an IP from a DHCP server, a device sends the request to the broadcast. But since it doesn't have a network setting at this point, it sends the request to the overall broadcast address, which is 255.255.255.255, and this goes across layer 3 boundaries. So it also reaches a DHCP in the obviously other subnet.
So your network setup might leak at layer 2.
Quote from: viragomann on August 06, 2026, 10:08:45 AMHowever, to get an IP from a DHCP server, a device sends the request to the broadcast. But since it doesn't have a network setting at this point, it sends the request to the overall broadcast address, which is 255.255.255.255, and this goes across layer 3 boundaries. So it also reaches a DHCP in the obviously other subnet.
That's not really what happens. Broadcasts never "reach" between subnets. In the case of a broadcast DHCP request, there is no subnet yet. The DHCP packet gets transmitted in a broadcast ethernet frame (destination ff:ff:ff:ff:ff:ff). Any DHCP server in that layer 2 domain can reply to that request. The ethernet frame containing the request can (and should, in this case) include a VLAN tag. When OPNsense receives such tagged frames on igc0, if there is a correctly-configured VLAN subinterface for that VLAN ID, that interface will handle the frame. If there's a DHCP service listening on that interface, it should respond accordingly. Otherwise it should be ignored.
Here's an example of a DHCP request on VLAN 5 as seen by tcpdump:
root@opnsense:~ # tcpdump -nnei igc0 vlan and port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:58:48.234885 52:3f:a3:79:d1:2c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 354: vlan 5, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:3f:a3:79:d1:2c, length 308
08:58:48.235421 00:d0:b4:01:a5:a1 > 52:3f:a3:79:d1:2c, ethertype 802.1Q (0x8100), length 350: vlan 5, p 0, ethertype IPv4 (0x0800), 10.1.5.1.67 > 10.1.5.201.68: BOOTP/DHCP, Reply, length 304
...
... and an example on VLAN 11, for which no VLAN interface exists:
root@opnsense:~ # tcpdump -nnei igc0 vlan and port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:05:50.914317 66:78:39:f8:6b:89 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 11, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 66:78:39:f8:6b:89, length 304
09:05:51.970468 66:78:39:f8:6b:89 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 11, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 66:78:39:f8:6b:89, length 304
09:05:54.123988 66:78:39:f8:6b:89 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 11, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 66:78:39:f8:6b:89, length 304
Quote from: dseven on August 06, 2026, 11:11:04 AMThat's not really what happens. Broadcasts never "reach" between subnets. In the case of a broadcast DHCP request, there is no subnet yet. The DHCP packet gets transmitted in a broadcast ethernet frame (destination ff:ff:ff:ff:ff:ff). Any DHCP server in that layer 2 domain can reply to that request.
So what is different here to that I wrote??
ff:ff:ff:ff:ff:ff = 255.255.255.255
^^
Quote from: dseven on August 06, 2026, 11:11:04 AMThe ethernet frame containing the request can (and should, in this case) include a VLAN tag.
And this is the part, which might not work here.
Yes, you're right, the broadcast shouldn't leave its VLAN. But the VLAN separation doesn't seam to work at layer 2.
Quote from: viragomann on August 06, 2026, 11:44:30 AMQuote from: dseven on August 06, 2026, 11:11:04 AMThat's not really what happens. Broadcasts never "reach" between subnets. In the case of a broadcast DHCP request, there is no subnet yet. The DHCP packet gets transmitted in a broadcast ethernet frame (destination ff:ff:ff:ff:ff:ff). Any DHCP server in that layer 2 domain can reply to that request.
So what is different here to that I wrote??
You wrote "... this goes across layer 3 boundaries. So it also reaches a DHCP in the obviously other subnet.", which makes it sound like the DHCP request gets routed at layer 3. It doesn't.
Quote from: viragomann on August 06, 2026, 11:44:30 AMQuote from: dseven on August 06, 2026, 11:11:04 AMThe ethernet frame containing the request can (and should, in this case) include a VLAN tag.
And this is the part, which might not work here.
Yes, you're right, the broadcast shouldn't leave its VLAN. But the VLAN separation doesn't seam to work at layer 2.
What are you based that assessment on? It works for me...
Quote from: dseven on August 06, 2026, 11:51:24 AMYou wrote "... this goes across layer 3 boundaries.
That's correct. ff:ff:ff:ff:ff:ff, the MAC broadcard address, goes to any device in the local layer 2.
If the VLAN segmentation doesn't work, it goes to any devices in other alleged VLANs as well. And this is, what we're talking here about, the basic issue of this thread, we are trying to resolve.
Quote from: dseven on August 06, 2026, 11:51:24 AMWhat are you based that assessment on? It works for me...
The issue of the TO.
It works in my setup as well, but I don't complain.
^^
I don't know what a "TO" is, but I have not yet seen any proof that a DHCP request from a tagged ethernet frame is getting a response from the DHCP service on the base ("untagged") interface. I suspect that the request frame is not actually arriving tagged, which is why I suspect WiFi misconfiguration. I'd suggest that the OP (original poster) double-check that first, then maybe try tcpdump like I showed...
Also I wanted to confirm that the bridge is completely out of the picture, because it could be doing something silly like grabbing the tagged frame, stripping the tag, and dumping it onto its member interfaces.
Quote from: dseven on August 06, 2026, 12:14:59 PMI don't know what a "TO" is
The thread opener.
Quote from: dseven on August 06, 2026, 12:14:59 PMbut I have not yet seen any proof that a DHCP request from a tagged ethernet frame is getting a response from the DHCP service on the base ("untagged") interface
Again, I didn't ever complain that this is possible in a correctly configured network with subnets. But we are trying to solve an issue here and I tried to give a possible explanation for it.
Man!!!
I bet it is layer 8.
Quote from: dseven on August 06, 2026, 09:50:21 AMAt the start, you had a bridge. Is that bridge now completely gone? Updated ifconfig output might be helpful.
Otherwise I'd tend to suspect that your WiFi is misconfigured...
@viragomann... here is the updated config and yes, the bridge is completely gone and igc3 is disconnected. Sorry about the confusion.
Notes:
- VLAN02 and VLAN03 are unresponsive from anywhere other than OPNSense itself. I can ping 192.168.20.1 and 192.168.40.1 but only when I'm logged directly into the OPNSense shell via SSH. I don't know what layer these pings are operating from.
- The VLAN networks are enabled in UnifiOS and labeled correctly as Guest and IoT with the appropriate tags (20 and 40 respectively). I highly doubt there is a misconfiguration in Unifi OS as it's the same as it always has been and worked just fine under all OPNSense releases up to and including 21.x. The devices listed in Unifi OS are shown on the correct networks (LAN, Guest, and IoT) but they all have LAN IPs. All of my problems started after upgrading to 26.7.x.
- OPNSense's ARP table clearly shows the issue - both VLANs are shown with IP's of 192.168.20.1 and 192.168.40.1 but none of the devices can reach them. Instead, OPNSense incorrectly dumps them into LAN IPs.
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
inet xxx.xxx.xxx.xxx netmask 0xfffff800 broadcast 255.255.255.255
inet6 x cac%igc1 prefixlen 64 scopeid 0x2
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igc2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: DMZ (opt1)
inet 192.168.30.1 netmask 0xffffff00 broadcast 192.168.30.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igc3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
media: Ethernet autoselect
status: no carrier
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff000000
groups: lo
enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
vlan00: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
vlan01: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Guest (opt2)
inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
vlan02: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: IoT (opt3)
inet 192.168.40.1 netmask 0xffffff00 broadcast 192.168.40.255
groups: vlan
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
Have you reboot (opnsense) since eliminating the bridge? There may be some artifact from it lurking somewhere.
Otherwise try this tcpdump to see "what's happening on the wire":
tcpdump -nnvvei igc0 '(ether host aa:bb:cc:dd:ee:ff and port 67) or (vlan and ether host aa:bb:cc:dd:ee:ff and port 67)'
Substitute the MAC address of a Guest or IoT device (in two places), and make it (re)connect.
Quote from: tonys on August 06, 2026, 10:31:38 PM- VLAN02 and VLAN03 are unresponsive from anywhere other than OPNSense itself. I can ping 192.168.20.1 and 192.168.40.1 but only when I'm logged directly into the OPNSense shell via SSH. I don't know what layer these pings are operating from.
Because you are pinging Gateway IP Addresses from the Router they are active on... so... yeah... that always works! :)
If I were you I would just start from "almost scratch" and configure everything as needed step by step :
- Create VLAN #1 on OPNsense.
- Double check everything in the UniFi Controller.
- Test if it works.
- Create VLAN #2 on OPNsense.
- Double check everything in the UniFi Controller.
- Test if it works.
And so on... :)
Quote from: dseven on August 07, 2026, 09:13:34 AMHave you reboot (opnsense) since eliminating the bridge? There may be some artifact from it lurking somewhere.
Otherwise try this tcpdump to see "what's happening on the wire":
tcpdump -nnvvei igc0 '(ether host aa:bb:cc:dd:ee:ff and port 67) or (vlan and ether host aa:bb:cc:dd:ee:ff and port 67)'
Substitute the MAC address of a Guest or IoT device (in two places), and make it (re)connect.
Feedback:
- OPNSense router has been rebooted MANY times since removing the bridge
- This wireless device is supposed to be on the IoT VLAN (192.168.40.x). It used to be under v21 and earlier, but now it keeps reconnecting to the LAN. The Roku screen shows it's on the IoT network WITH theTHE IoT password (very different from the LAN password) but it keeps getting a LAN IP. The Unifi wireless AP also shows it on the IoT network which it must be because I gave it the IoT password. Yet it got a LAN IP. ??
tcpdump -nnvvei igc0 '(ether host d4:be:dc:20:de:dd and port 67) or (vlan and ether host d4:be:dc:20:de:dd and port 67)'
tcpdump: listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:24:11.301381 d4:be:dc:20:de:dd > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from d4:be:dc:20:de:dd, length 548, xid 0x70cd0629, Flags [none] (0x0000)
Client-Ethernet-Address d4:be:dc:20:de:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
Requested-IP (50), length 4: 192.168.1.127
Parameter-Request (55), length 5:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
Hostname (12)
Hostname (12), length 9: "RokuUltra"
16:24:11.301551 64:62:66:22:4c:ab > d4:be:dc:20:de:dd, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.1.1.67 > 192.168.1.127.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x70cd0629, Flags [none] (0x0000)
Your-IP 192.168.1.127
Client-Ethernet-Address d4:be:dc:20:de:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Server-ID (54), length 4: 192.168.1.1
Lease-Time (51), length 4: 5452
Subnet-Mask (1), length 4: 255.255.255.0
Default-Gateway (3), length 4: 192.168.1.1
Domain-Name-Server (6), length 4: 192.168.1.1
Domain-Name (15), length 8: "home.lan"
I found the problem. The Unifi OS configuration had its Default, Guest, and IoT networks set up correctly with the proper tags (20 for Guest, 40 for IoT) but the tags weren't showing up in the network table list. Google Gemini led me to this issue and showed me how to correct it - basically, MANUALLY add the two tags to their respective networks. Why they didn't copy over when I defined those networks remains a mystery (maybe a bug?) but once I manually added the tags, all devices disconnected from the native (LAN) network and reconnected on their proper networks.
Attached is a Unifi OS screenshot after adding these tags. The bottom table is where I originally set up the networks with their tags. The top table was generated by UnifiOS but was missing the VLAN tags so I added the tags manually. FYI, the VLAN definition for the LAN is currently disabled in OPNSense. It seems to be unnecessary to tag the LAN so I'm able to combine untagged LAN with the two VLANs on one port going to the Unifi AP. Hopefully this settles your debate over combining tagged and untagged traffic, LOL.
Thanks for all your help gentlemen. Now it's time to move on to the next problem (LAN stalls requiring using an external VPN to stop LAN blocks to Quad9 encrypted DNS from Apple's Private Relay traffic).
Quote from: tonys on August 08, 2026, 04:19:52 AMHopefully this settles your debate over combining tagged and untagged traffic, LOL.
See you again when this goes horribly wrong and you do not even remember what you did to make that possible. We never said it was not feasible, but depending on what you do, there can be lots of problems. This may be influenced by your NIC hardware on OpnSense, and is especially true for Unifi switches, which have all kinds of problems with VLANs. If you want a taste of it, look here (https://community.ui.com/releases/89921c9e-9807-4729-83bc-785aea616de3?replyId=b466cb18-5491-4e51-bc12-2bb35d937e31).
The current switch software releases of some switch models have a problem separating untagged and tagged LANs during switch startup. Depending on the startup order of your machines, they can get IPv4 from any of your VLANs (since all of them are presented untagged). With 802.1x enabled, you may see all IPv6 prefixes at once on untagged ports.
But, as Patrick often says: You do you, LOL. The advice given in here is free - and you are also free to take it or leave it.
For one, you won't get correct interface statistics. The counters of the untagged interfaces will be the sum of all tagged and untagged packets. No, that is not a bug.
Quote from: meyergru on August 08, 2026, 09:00:10 AMThe current switch software releases of some switch models have a problem separating untagged and tagged LANs during switch startup.
This seems like a good reason not to use UniFi switches. I actually had been considering buying some to deploy, but now I'm reconsidering!
It seems to me like this would present some issues even when not mixing tagged and untagged on the same interface in OPNsense. e.g. OPNsense broadcasting IPv6 RA on (only tagged) VLANs, with a Windows PC on an "access" switch port on one specific VLAN. If the switch acts "dumb" during boot, it would forward those tagged frames (for all VLANs, not just the specific one) to the Windows PC port, where Windows (at least with some NIC types) has been known to strip VLAN tags and blindly process the frame as if it was received untagged. This would cause bogus IPv6 configuration in Windows.
I observed this on Linux, too. The 802.1x implementation of the Realtek-based Unifi switches is fully broken at this time, BTW: During bootstrap, when the RADIUS server cannot be reached, the training does not work, so initially, all 802.1x-enbaled ports go to their fallback VLAN.
What seems to be the case is that those Unifi switches do not wait for the RAIDUS server to become available before the allow 802.1x training (of course, that means you have to initialize non-802.1x-enabled ports first). Gen Z at work, I suppose...
Quote from: meyergru on August 08, 2026, 09:00:10 AMIf you want a taste of it, look here (https://community.ui.com/releases/89921c9e-9807-4729-83bc-785aea616de3?replyId=b466cb18-5491-4e51-bc12-2bb35d937e31).
For those who do not know :
You need to Enable
Early Access in your UniFi Account to be able to view the link above.
AFAIK it's still free and the change is applied immediately :)
In short :The link mentions only the "New Age" Switches as I like to call them.
Pretty much everything with Flex/Lite/Pro in the name.
Older models like the 16 Port 150 Watt PoE/PoE+ model or the small 8 port model with PoE/PoE+ Input and Passive PoE Output are not mentioned.
That appears to be a discussion thread for an early access release of the switch firmware. The models listed would be those for which that release is/was available.
Google AI tells me that the "Flex" and "Ultra" switches use cheap Realtek SoCs, which default to acting as a dumb switch until the OS and software finish booting and tell them what to do, and that the Pro and Enterprise models use Marvell or Broadcom ASICs, which are flash-backed, and start up already knowing what to do. I don't necessarily believe that this is entirely accurate, but it seems plausible...
Quote from: meyergru on August 08, 2026, 09:00:10 AMQuote from: tonys on August 08, 2026, 04:19:52 AMHopefully this settles your debate over combining tagged and untagged traffic, LOL.
See you again when this goes horribly wrong and you do not even remember what you did to make that possible. We never said it was not feasible, but depending on what you do, there can be lots of problems. This may be influenced by your NIC hardware on OpnSense, and is especially true for Unifi switches, which have all kinds of problems with VLANs. If you want a taste of it, look here (https://community.ui.com/releases/89921c9e-9807-4729-83bc-785aea616de3?replyId=b466cb18-5491-4e51-bc12-2bb35d937e31).
The current switch software releases of some switch models have a problem separating untagged and tagged LANs during switch startup. Depending on the startup order of your machines, they can get IPv4 from any of your VLANs (since all of them are presented untagged). With 802.1x enabled, you may see all IPv6 prefixes at once on untagged ports.
But, as Patrick often says: You do you, LOL. The advice given in here is free - and you are also free to take it or leave it.
I'm not using a Unifi nor other switch and have no requirement for one in the foreseeable future. My AP is the Unifi Pro 7 wireless (UFO style) on one Protecli port and my entire network is wireless with the sole exception of an internet-facing OpenVPN Access Server which is on its own dedicated Protecli port.
I'll continue testing without the external VPN and if anything changes, I'll post here.