VLAN devices are on LAN IPs

[tonys]

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":

Code Select Expand

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"

[tonys]

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).

[meyergru]

Hopefully 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.

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.

[Patrick M. Hausen]

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.

[dseven]

The 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.

[meyergru]

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...

[nero355]

If you want a taste of it, look here.

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.

[dseven]

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...

[tonys]

Hopefully 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.

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.