Group policy not applying to end user devices after reboot

[Adam2104]

I have several group policies attached to various wireless clients in my network. There's a single SSID that has a VLAN tag of 20. The group policy is tagging certain devices with VLAN10. This works great, until the access point reboots (say a power outage, or software upgrade), then, when the AP is booting back up the group policy isn't applied and devices that should be in VLAN10 are getting IP addresses from VLAN20. This is a problem because eventually the group policy DOES get applied but the clients have already gotten IP addresses from the wrong VLAN and thus cannot communicate out.

I'm running an MR42, I've tried both the latest stable and the latest beta release and the results were the same. VLAN tags not applied to group policy clients immediately after reboot.

Am I missing something? Is there some "wait until everything is ready before turning on the radios" option that will make the group policy apply after rebooting an access point?

[kYutobi]

What VLAN is your AP under? 

[Adam2104]

Not sure why that matters? It's in VLAN 1, native VLAN, for management only.

[kYutobi]

Reason I ask is because I believe there was some type of similar issue for me way back when. What happens when you leave the AP on blank instead of VLAN1 just for giggles. Let me know @Adam2104 

[Adam2104]

I actually reconfigured it for blank this morning after I factory reset all the APs. They're were griping about a bad IP configuration, even though they were configured for static.

I find it odd that that switches require the VLAN to be configured when you set a static IP. The access points do not.

edit: I'll have to recreate my group policy configuration to try again with the blank VLAN. I'll do that and report back.

[Adam2104]

So I tried again, I created a new group policy that assigns a different VLAN than the SSID's base VLAN tag (50 vs 10). Sadly, traffic from those clients still shows up in the SSID's VLAN tag immediately following a reboot of the access point, they are then later pushed into the group policy VLAN, but only after they've managed to get an IP address from the wrong subnet.

[Adam2104]

I've done some more testing, this time not with VLAN assignment but with Layer3 firewall rules. The same behavior occurs. It takes over 70 seconds for the group policy to be applied to a client, during which time any L3 firewall rules that are specific to that client ARE NOT ACTIVE. Also, it seems that once the policy actually applies any connections/streams that were up during this period of no firewall enforcement will remain up until terminated (I tested with ping).

So, it seems to me, that if you're using group policies with WPA PSK to do any kind of policy enforcement you've got a major security hole every single time your access point reboots. There's a large window of time, over a minute, where the client is not filtered. I guess I will have to completely rework my approach to L3 firewall group policies to try to workaround this.

[GreenMan]

Can I suggest you raise a case with Support for this?

[Adam2104]

I have, I'm waiting for a response. I figured I'd reach out to the community to see if anyone else has seen the same thing.

[kYutobi]

Keep us posted @Adam2104 on what they find.

[Adam2104]

I opened the case and it was confirmed that this looks to be broken. Now we're waiting on a fix to which there is no ETA.

[bwatkins]

Adam,

Did this ever get resolved?

[Adam2104]

Supposedly, in MR26.5. Sadly, I never did test the fix because MR26 had horrible DHCP intermittent failures on bridged mode SSIDs. I finally got so fed up with all the bugs in MR and MX that I ripped it all out and put in Ubiquiti hardware which has been flawless.

[bwatkins]

Sounds like it would fix the problem and break something else.  We have about 480 AP's, so not sure if I have the luxury of replacing the hardware at this time.  I'll have to look at other alternatives.

[cuongct]

Hi Adam,

Do you solve this problem?

My network have got same error. I don't know to fix issue. Please help me.

[Adam2104]

@cuongct I'm not sure I follow your question. This particular bug was fixed in MR firmware 26.5. If you're running a newer version than that then you're probably encountering some other problem.

[cuongct]

Thanks Adam

[cuongct]

My network have got same error. Please help me.