KEA DHCP lease should not be resumed when client switches VLAN
-
I have recently added VLANs, mainly to segregate IOT devices and restrict their access to Internet, LAN, or both, depending on whether they are cloud-only, fully local, or need access to both. I tested all the firewall rules and believe they are all correct.
I use free Radius with Unifi .
To change a client VLAN, I do the following :
a) add an entry for the client MAC and VLAN to free Radius
b) force the client to reconnect in UnifiThis causes the client packets to be tagged with the new VLAN, and forces it to make a new DHCP lease request.
The problem is this :
- the client, unaware of the VLAN change, tries to resume the previous lease
- KEA honors the lease, even though it was issued in the other VLAN.
- the client keeps its old IP address
- in many cases, the client becomes inaccessible, due to its IP being in the wrong subnet, and firewall rules
Workaround I found :
a) go to Settings / DHCP leases
b) click "clear all DHCP leases" (or just one client)
c) force client to reconnect in Unifi again
d) it makes another DHCP request, and this time, obtains the correct IP in the new VLAN's subnetIs there a custom option for the KEA DHCP server to deny the lease resumption when the VLAN is changed in step 3) above ? It seems like a bug to me.
Context :
I have 311 IOT Wifi clients. I don't know for sure which ones can operate with cloud, local, or both. I want to grant them minimum permissions to operate.
I built a neat little GUI that lets me perform steps 1 and 2 with just a couple clicks. It connects to my freeradius container via SSH to update the MAC->VLAN list, and sends SIGHUP to the service. It then uses the Unifi API to force the client to reconnect.
As I experiment and find out how each client / or client model behaves, I switch the VLAN back and forth quickly. But KEA gets in the way by resuming the DHCP leases after the VLAN switch, when it shouldn't.
I suppose I can add some code to my tool to connect to also login to pfSense, and clear the DHCP lease. Not sure if the pfSense REST API package allows. That really seems like a hack that should not be necessary, though.
-
@madbrain What version? If Plus, see if this patch helps: https://forum.netgate.com/post/1239153
-
@SteveITS Thanks !
It's 26.03 . Let me try to apply it. -
@SteveITS It's a monster patch. The word VLAN doesn't appear in the thread. It seems related to static DHCP reservations not being cleared when modified. I have run into that sort of problem before. But I am not sure that's the case here.
I started with 100% of my devices in VLAN 1, with 100% of them having DHCP reservations in that subnet.
I then made some Radius edits & Unifi reconnect to move a bunch of devices to other VLANs. Some got new IPs, some did not not. Clearing the leases and forcing reconnect seemed to have worked at first.
However, I just tried to move them all back to VLAN 1, as I ran into some issues. The leases from the other VLAN all got resumed. And they got resumed even after I cleared the leases in the GUI.
So, I'm not sure what to think at this point.
Anyway, it's dark now, and my Wifi lights couldn't turn on, and I shouldn't be experimenting with my network when it's dark. So, to try to recover, I :
- disabled Radius in Unifi, so every client defaults back to VLAN 1.
- turned off all the Unifi SSIDs temporarily to get all clients offline.
- cleared all DHCP leases in pfSense.
- rebooted pfSense.
- turned the SSIDs in Unifi back on.
All Wifi clients properly came back online, and got their IP from the default VLAN 1 subnet, and my lights are back on. I'll have to continue this when there is daylight tomorrow.
The 230 lightbulbs were not the ones I had switched VLAN on, though. They were all still on VLAN 1. I had moved 58 Kasa smartplugs to an Internet-only VLAN. They are supposed to be able to function locally. It looked like I got some kind of broadcast storm on the APs that brought the whole network down to its knees, sigh. It is a mesh network and I expect some traffic increase from VLANs, but not for it to become completely unusable. I think I must have gotten my inter-VLAN routing rules wrong.
-
@madbrain It was just a stab, thought maybe it would help. :-/
-
Can you capture a trace of a DHCP (re-)negotiation between Kea and a 'changed client'? Goes without saying that Kea should not be allowing the 're-lease' of an IP address from the pool of a corresponding interface to which the DHCP client is properly not connected.
Would be ideal to attach the PCAP itself to your reply.
-
@tinfoilmatt said in KEA DHCP lease should not be resumed when client switches VLAN:
Goes without saying that Kea should not be allowing the 're-lease' of an IP address from the pool of a corresponding interface to which the DHCP client is properly not connected
These are my thoughts also.
When "VLAN" are activated, the traffic come all the "VLAN" flow over the same wire, but for every VLAN number there is an interface, and a DHCP server behind it, all with their own pools.
What I'm missing in the first post : a VLAN aware setup has to be done on the pfSense side of things, but there is the also the other side also : a VLAN capable switch that 'undo's' the VLAN wire, and makes individual LANs again, and these are connected (wire of Wifi, whatever) to the devices, who, after all, might be aware of the concept VLAN, but most devices are not.
I could setup my desktop's NIC with a VLAN ID greater then zero, for example "100", and I can create a "VLAN100 interface" on pfSense, and don't need any extra hardware to make this work. From now on my PC live son it's own V100 network, and the default LAN interface and the default 'non VLAN' LAN DHCP server shouldn't (can't !) receive any DHCP requests anymore from my VLAN-100-desktop-PC. This should work (I remember trying it ones).
Anyway ... just my thoughts / 2 cents ....
-
@tinfoilmatt I will do so, once I resolve the broadcast storm issues I have been running into with Unifi. It seems that using unmanaged switches in between pfSense and the Unifi APs may be causing problems. The VLAN tagged packets in theory should just travel through, and I didn't expect any issue. I'm going to temporarily remove the switches altogether and connect a Unifi AP directly to pfSense, with the other 9 APs as mesh downlinks, meaning there is nothing unmanaged in the chain, to see if those broadcast storm issues go away. I read on some Unifi forums that there were problems in some cases where some packets from Wifi clients were being broadcast to multiple VLANs instead of just the VLAN selected by Radius; so it may well be a Unifi problem.
-
Sounds like you're on the right track.
-
@madbrain yeah while a dumb switch should pass the tags sure - the problem it doesn't understand them, so yeah broadcast or multicast would be sent out to all ports, which could cause problems.
Once you start segmenting your network and using vlans, all switches should be vlan capable. You don't need full managed enterprise level sort of switches.. You can for sure find vlan capable switches on the cheap.. Like $40 for 8 port gig should be easy enough to find.
You can still leverage dumb switches you have.. But they should be used only as downstream switches where everything on that switch is in the same vlan.. And upstream is a vlan switch where you can place that dumb switch into the specific vlan you want.
-
Unfortunately, it's not a just $40 expense. There are three 10 Gbps switches involved. 2 x TP-Link TL-SX105, and 2 x Netgear GS110MX. They were chosen because they are 100% silent. There are also 2 more 1 Gbps 16-ports, and two 1 Gbps 8-port switches. They are located in various rooms around the house, and are entirely silent - fanless, which is a requirement.
I made a list of what it would cost to replace the entire setup with Unifi managed switches. It came to $1500. That includes 1 x USW-aggregation, 2 x USW Pro Max 16, 3 x USW Flex 2.5G, and 6 SFP+ modules, and 6 DAC cables.
For now, I'm still going to experiment with disconnecting all the Ethernet segments temporarily, to see if there are still broadcast storms. I'm still working on my management tool to do mass VLAN changes in FreeRadius on the large number of Unifi Wifi clients with a couple clicks.
-
Why not just go for their routing solution, too? pfSense is more complicated because it's more standards-based.
-
@tinfoilmatt I sit 3ft from my router more than 8 hours a day, and Ubiquiti doesn't make a fanless 10 Gbps router product. All of them are small form factor with small high RPM fans that are too noisy for me to tolerate. Fanless is a requirement for me.
I built a PC with a very large HAF case, that is fanless. It has an AMD 5700G APU, NH-D15 cooler, 48GB of RAM, 5 x 4TB of NVMe striped SSD, an X550-T2 NIC, is running Proxmox. pfSense is just one VM. There are many others, and containers. Obviously it was a significant cost to build this box, but part prices in May 2023 when I built it were far more reasonable than today. pfSense used to run on a very similar bare metal PC I built at the same time - same APU, but much less RAM and storage. I just moved pfSense to a VM on Proxmox. It saved me a bunch of watts since I was able to turn off the PC that was running pfSense bare metal.
Ubiquiti still doesn't have a fanless 10 Gbps router product on the market that would be suitable. Even if they did have one, I would also still need to buy their managed switches on top of that. The hypothetical fanless Unifi 10 Gbps router would add to my power consumption also, since my Proxmox box would still need to stay up for all the other services.
I know I'm not the only one mixing pfSense router with Unifi APs, so I'm trying to make that work. It has worked fine for the last 3 years when not using VLANs. I am just adding the VLANs now.
-
@madbrain I have been using unifi APs for 10+ years, I just replaced 3 that were over 10 years old, I think closer to 11.. With 2 U7 Lites.. Which sofar been happy with. I do like their APs - not a fan of most of their other devices.. The switches are over priced, other than the little flex minis that I have 2 of - but they are limited in features, but I do like the size and that you can power them with poe, and simple usb connection. They worked out nicely for my use case.
As to 10ge that can do vlans - yeah those are not that cheap yet.. And 10ge copper produces quite a bit of heat so good luck with any sort of density of ports without a fan.
I have had zero issues with the APs and vlans - but then again all my switches are vlan capable - cisco SG300s, one SG250, etc. So no they were not 40 dollar switches either. Other then the 2 flex minis.
Maybe you could rethink your 10ge deployment? Not everything needs 10ge ;) Even if all 300 of your iot devices ended up going through the same wire.. 1 gig would prob be enough there, or 2.5ge if you wanted more headroom.. I don't have anywhere near that many lightbulbs, etc. But I have quite a few - and they use nothing as far as bandwidth. But one thing with wifi lightbulbs, at least all the ones I have played with - they love to broadcast, I mean a LOT!! I block it at the switch ports the APs are connected to so a broadcast from devices on 1 AP don't come down the wire and then go out the the other AP, etc.
That is one thing a higher end switch would allow you to do to control traffic you want to keep isolated or off much of the rest of your network via acls
APs sure don't need a 10ge uplink, not for iot devices that is for sure.
With a rethink of where you need 10ge, and where you can get by with less which = less cost for managed switches, etc.
-
@johnpoz said in KEA DHCP lease should not be resumed when client switches VLAN:
@madbrain I have been using unifi APs for 10+ years, I just replaced 3 that were over 10 years old, I think closer to 11.. With 2 U7 Lites.. Which sofar been happy with. I do like their APs - not a fan of most of their other devices.. The switches are over priced, other than the little flex minis that I have 2 of - but they are limited in features, but I do like the size and that you can power them with poe, and simple usb connection. They worked out nicely for my use case.
[/quote]It's been 7 years using Unifi APs for me. Originally NanoHD. Now U6-LR. I had a lot of problems with their USG-3P router. Many bugs. I never bought their switches. No reason until now, since I was not using VLANs.
I went from Orbi to Ubiquiti. Orbi kept forcing firmware upgrades that caused device regressions, with absolutely no way to roll back. God knows Ubiquiti firmware upgrades have had regressions too, but at least I have the ability to roll back when there is now. I needed a mesh system, since I only have 2 rooms wired out of 17.
I used to have 6 NanoHDs. Now 10 U6-LR. Two wired APs, each with 4 downlinks (2 are double meshed).As to 10ge that can do vlans - yeah those are not that cheap yet.. And 10ge copper produces quite a bit of heat so good luck with any sort of density of ports without a fan.
Yes, that's why I have two fanless TP-Link SX105,. I used to have a single 8-port Trendnet. The fan drove me crazy. The TP-Link have each failed once, likely due to heat. They were both replaced under their lifetime warranty. I expect they will fail again.
Realtek recently came out with much lower power and cost RTL8127 10gbe chipsets. There are a few NICs on Amazon already. They are PCIe 4.0 x1 which is nice, compared to the PCIe 3.0 x4 NICs I'm currently using - Intel and Aquantia. I have not tried one yet. They have both copper and fiber versions. They are supposed to come up with low-power parts for switches as well. I don't think there is one on the market yet, either unmanaged or managed. These may be the answer to the fanless 10 Gbe problem. It remains to be seen whether Ubiquiti would choose to put any of these chips in their upcoming switches, though.
Maybe you could rethink your 10ge deployment? Not everything needs 10ge ;)
Oh absolutely, I only have two wired rooms, those are the only ones that really need 10g. There are 4 systems currently on 10G, and one on 2.5G. There used to be one more 10G system that was bare metal pfsense, but that went down to 4 when I got Proxmox. So, that's in theory only 5 high-speed 10G ports needed. Except 2 ports are needed to connect 1 G switches, one in each room. And 2 10G ports to connect the two rooms together. So, total of 10 high-speed ports needed between 3 rooms. The two TL-SX105 provide 10 ports in one room. The GS110MX provides 2 ports in the other room.
Even if all 300 of your iot devices ended up going through the same wire.. 1 gig would prob be enough there, or 2.5ge if you wanted more headroom..
I know 1G is more than enough for IOT. Most of them are not even going over wire. Currently, controller shows 79 clients connected to the two wired APs. The other 239 are all on mesh APs. Obviously, they are all very low bandwidth. There is about 30-40% utilization on the 2.4 GHz channels for all APs. About 20-25% for the two 5 GHz bands used as backhaul for the mesh.
I don't have anywhere near that many lightbulbs, etc. But I have quite a few - and they use nothing as far as bandwidth. But one thing with wifi lightbulbs, at least all the ones I have played with - they love to broadcast, I mean a LOT!! I block it at the switch ports the APs are connected to so a broadcast from devices on 1 AP don't come down the wire and then go out the the other AP, etc.
My 230 bulbs are all Philips Wiz. Which ones do you have ? And yes, I know they love to broadcast. It would likely cost 5 figures for me to add wiring for all APs, so for now I'm going to continue use mesh to connect them.
That is one thing a higher end switch would allow you to do to control traffic you want to keep isolated or off much of the rest of your network via acls
My plan is to use pfSense to do the inter-VLAN routing. IOT devices don't really need to talk to each other. They mainly talk to Home assistant which is a VM on the same physical host as pfSense. Unifi APs isolate the VLANs over mesh. But it seems the unmanaged switches in between get in the way. Even if they didn't cause broadcast storms (and I'm still investigating that), ethernet devices on unmanaged switches could go to promiscuous mode and sniff other VLANs. How likely that is, I don't know, but it's a security risk. Even with fully managed switches and VLANs, if sharing a single SSID / password and using Radius to assign VLANs, one could sniff all the MACs wirelessly when on site, and if they knew the password, spoof another device's MAC and gain access to another VLAN. The only fix for that is to use separate VLAN per SSID. Then you get into the problem of max # of SSIDs per radio, and the saturation of traffic that causes. I won't be going that route. One thing that would be attractive is the possibility of using PPSK + Radius to manage VLANs. Unifi does not allow that on its APs, though. It's either PPSK or Radius. You can't combine both.
APs sure don't need a 10ge uplink, not for iot devices that is for sure.
No, I don't.
With a rethink of where you need 10ge, and where you can get by with less which = less cost for managed switches, etc.
My Proxmox host had 4 NICs. I can assign a dedicated 1 Gbe NIC to a Unifi Wifi AP. And leave the wired segment on the 10 Gbe NIC. But they have to be in different VLANs and subnets for this to work. I also have to unplug the AP in the second room from the wired 10 Gbe LAN, and make it a mesh AP. That will increase the maximum depth of the mesh links to 3 APs. I have already tested it this way, and it works, though.
I still can't permanently disconnect my wired LAN, I can only do it a few hours a day, otherwise , things like my Plex server VM will fail to record from the wired OTA turner in the other room. That's one reason I have been slow at doing the testing. Another being I keep running into LLM AI limits to write my app, and the local one I have going takes hours per response and produces not so good code. It already does many things the Unifi controller can't do, though, but tons of bugs left to fix.
-
So, I temporarily switched my network to APs only, taking out all unmanaged switches out of the picture.
Motherboard 1 Gbe NIC has a Unifi AP directly attached. Other 9 APs are mesh downlinks. VLAN for clients is assigned by Radius . All VLAN tagged traffic is supposed to go through these APs.
Good news: I have not seen any client making DHCP requests that ended up in the wrong VLAN and getting the wrong IP during this test.
Bad news : I still got broadcast storms after changing a few IOT clients to the Internet-only VLAN. I added a window in my tool that monitors the band utilization, and it shows this for one AP. It's similar for the others. It drops back to normal the moment I selected the clients, reset them to VLAN 1, and forced Unifi to reconnect them.
Edit: the few clients I switched were appliances like my Bosch dishwasher and LG washer/dryer, Winix air purifiers, which I would not expect to be doing broadcasts/multi-cast. I didn't switch any lightbulb to the "Internet-only" VLAN, since these lightbulbs have a local API, and for now, can stay on VLAN 1, though I plan to switch them to the "LAN only" VLAN, once I solve the broadcast storm issue.
I'm not really sure what to make of it. It could be either a Unifi or pfSense issue. But it's for sure not caused by any unmanaged switch.
Here are my VLAN definitions in pfSense.
Interface assignments
Firewall rules for LAN (VLAN 1) :
Rules for Internet only (VLAN 2) :
Note that I did not make any interface assignment changes in pfSense for this test when I switched NIC. I just changed the bridge configuration in Proxmox so that vtnet1 became the motherboard 1Gbe NIC instead of one of the ports on the Intel X550-T2 NIC. pfSense doesn't know the difference since the virtual NIC MAC is assigned in Proxmox.
The broadcast storm must be caused by either incorrect VLAN routing rules in pfSense, or a Unifi bug. I have never setup VLANs before, so I'm guessing it's the rules causing the storm. Any help would be appreciated.
-
@madbrain said in KEA DHCP lease should not be resumed when client switches VLAN:
The broadcast storm must be caused by either incorrect VLAN routing rules in pfSense
There is no incorrect routing here.. Pfsense is attached to a network, it knows how to route it. "Broadcasts" are not routed anyway.
What I would do is sniff that traffic - what is it made up of? A broadcast storm is normally a term to describe a loop in a network, which causes it to be overwhelmed with broadcast traffic..
https://en.wikipedia.org/wiki/Broadcast_storm
Is that increase you see in traffic actually broadcast or multicast that is being looped?.. Or is something constantly looking for something and since it can't get to it or find it its sending traffic like crazy..
I have seen my alexas go insane when internet was down and dns was not responding with what they were looking for.. I woke up to my pihole listing millions and millions of queries from all my alexas.. They were all asking for the same thing multiple times a second.. And didn't like the response they were getting.
A packet capture of what that increase in traffic actually is could be very informative to what is causing it.
-
@johnpoz said in KEA DHCP lease should not be resumed when client switches VLAN:
There is no incorrect routing here.. Pfsense is attached to a network, it knows how to route it. "Broadcasts" are not routed anyway.
What I would do is sniff that traffic - what is it made up of? A broadcast storm is normally a term to describe a loop in a network, which causes it to be overwhelmed with broadcast traffic..
https://en.wikipedia.org/wiki/Broadcast_storm
Is that increase you see in traffic actually broadcast or multicast that is being looped?.. Or is something constantly looking for something and since it can't get to it or find it its sending traffic like crazy..
I have seen my alexas go insane when internet was down and dns was not responding with what they were looking for.. I woke up to my pihole listing millions and millions of queries from all my alexas.. They were all asking for the same thing multiple times a second.. And didn't like the response they were getting.
A packet capture of what that increase in traffic actually is could be very informative to what is causing it.
Thanks.
I don't know yet what specific traffic it is, and whether it is broadcast or multi-cast.
The few clients I switched VLAN on were appliances like my Bosch dishwasher and LG washer/dryer, Winix air purifiers, which I would not expect to be doing broadcasts/multi-cast. I didn't switch any lightbulb to the "Internet-only" VLAN, since these lightbulbs have a local API, and for now, can stay on VLAN 1, though I plan to switch them to the "LAN only" VLAN, once I solve the storm issue.
I also tested with the Unifi SSID "multi-cast to unicast" option, and it made no difference, FYI.
How would you suggest I run the packet capture on the pfSense side ?
I have to look into how to do it on the APs as well. I could have sworn there used to be a button on the controller for this. I can ssh, but will also have to look for the right CLI.
-
@madbrain yeah depending on your firmware, the controller version and AP itself there would be a button. But like there is no button on my U7 Lites, but I can ssh to them run tcpdump
What/where did you create that graph showing the high network utilization - I would do the sniff there, if pfsense interfaces are seeing the high utilization of network you could just do the packet capture there under diagnostics.
What specific APs, firmware and controller version are you running?
edit: oh they moved it... I am running U7 Lites, 8.6.7 firmware with controller software being 10.3.58 running on Unifi OS (5.0.6) on a linux vm.. And it shows up if you click on the device, then airview, then highlight one of the devices (ap) you will see packet capture all the way to the right pop up.
But depending might not be supported, I have older flexHD AP that thinking of deploying outside currently connected and I don't see the packet capture button pop up there, but it does have tcpdump if I ssh to it.. Wonder if packet capture not showing up because I currently have its radio's off?
-
@johnpoz said in KEA DHCP lease should not be resumed when client switches VLAN:
What/where did you create that graph showing the high network utilization - I would do the sniff there, if pfsense interfaces are seeing the high utilization of network you could just do the packet capture there under diagnostics.
The graph I posted was my tool using the controller API. It would be showing the same data that you found in the graph from the current controller, except on a shorter time frame, easier to visualize.
What specific APs, firmware and controller version are you running?
U6-LR, EA firmware 6.7.51, controller 10.3.58 .
edit: oh they moved it... I am running U7 Lites, 8.6.7 firmware with controller software being 10.3.58 running on Unifi OS (5.0.6) on a linux vm.. And it shows up if you click on the device, then airview, then highlight one of the devices (ap) you will see packet capture all the way to the right pop up.
Yes, I found that.
But depending might not be supported, I have older flexHD AP that thinking of deploying outside currently connected and I don't see the packet capture button pop up there, but it does have tcpdump if I ssh to it.. Wonder if packet capture not showing up because I currently have its radio's off?
I think packet capture must be specific to certain models. Maybe U6 vs U7, or chipset.
Anyway, to get back to the original DHCP issue, I have concluded that there is no problem with pfSense. The issue with getting the wrong IP was related to Radius caching in Unifi. My GUI tool was updating the VLAN for a client in the freeradius config, then immediately forcing a Settings/Reconnect on that Wifi client using the Unifi API. It turns out that Unifi has a cache for Radius authentication, and does not immediately trigger the Radius re-auth, if the client had previously authenticated with Radius within the last minute. I was testing rapidly by clicking back and forth in my GUI. I have a single button that does both the Radius update, and Unifi client reconnect. If I wait about one minute and force reconnect the client again, Unifi forces a Radius reauth, and it switches to the correct VLAN. It was painful to figure that out, as I had to enable debug logging in both pfSense KEA DHCP server and freeradius.
Here is what I had to add in the custom DHCP server options in pfSense to enable it.
{ "loggers": [ { "name": "kea-dhcp4.packets", "output-options": [{ "output": "syslog:kea-dhcp4", "pattern": "%m\n" }], "severity": "DEBUG", "debuglevel": 10 } ] }In freeradius - running in a Ubuntu 24.04 lxc container on proxmox, not in pfSense :
root@radius-dev:/etc/freeradius/3.0/sites-enabled# cat /etc/freeradius/3.0/mods-enabled/linelog-vlan linelog vlan_log { filename = /var/log/freeradius/vlan.log format = "%T | %{Calling-Station-Id} | %{reply:Tunnel-Private-Group-Id}" }Then, I added "vlan_log" as the last line of the post-auth section in /etc/freeradius/3.0/sites-enabled/default .
This let me trace the incoming Radius requests from Unifi for that client - the only one that I switched VLAN on for testing purposes :
root@radius-dev:/etc/freeradius/3.0/sites-enabled# tail -f /var/log/freeradius/vlan* | grep 84-72-07-81-11-ED 2026-04-29-12.38.25.634023 | 84-72-07-81-11-ED | 2 2026-04-29-12.40.11.118653 | 84-72-07-81-11-ED | 1 2026-04-29-12.41.02.423494 | 84-72-07-81-11-ED | 2 2026-04-29-12.45.00.025150 | 84-72-07-81-11-ED | 1 2026-04-29-12.46.48.017847 | 84-72-07-81-11-ED | 2 2026-04-29-12.48.00.218718 | 84-72-07-81-11-ED | 1 2026-04-29-12.49.00.370991 | 84-72-07-81-11-ED | 2 2026-04-29-13.24.48.548272 | 84-72-07-81-11-ED | 2In the pfSense server DHCP log, I see :
Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_RECEIVED [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vtnet1.2 Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_SEND [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: trying to send packet DHCPOFFER (type 2) from 192.168.106.1:67 to 192.168.106.7:68 on interface vtnet1.2 Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_RECEIVED [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vtnet1.2 Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_SEND [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: trying to send packet DHCPACK (type 5) from 192.168.106.1:67 to 192.168.106.7:68 on interface vtnet1.2This is all expected for freeradius and pfsense.
Unfortunately, the 2.4 GHz band utilization for this client on the AP it's connected to instantly goes to 100%. There is no increased traffic on the pfSense side. It really looks like a Unifi issue. I have still not been to figure out why. This is a showstopper and completely preventing me from using VLANs with Unifi.
I have done a few packet traces on the AP, and am not seeing anything unusual, regardless of which VLAN the client is on. I must not be doing the capture right.
I may need to open a support case with Ubiquiti to get to the bottom of this.
