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?
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
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.
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.
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.
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.
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.
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.
Do you solve this problem?
My network have got same error. I don't know to fix issue. Please help me.
@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.