Although all of my staff laptops are members of an Active Directory domain and are managed by Group Policy, I do not manage wireless profiles on those devices using a group policy. The staff member who uses each laptop actually signs into the device using a local account, not a domain account. This means I can use a local administrator account on the affected machines to delete the faulty profile and then import an "all user" profile for the same SSID.   School laptops that are used by students do have wi-fi managed through group policy (primarily to prevent them from connecting to cell phone hotspots as a way to bypass the school firewall). However, I have never experienced this issue on those laptops.   After doing some experimenting over the last few weeks, I think the issue can be avoided if I join the device to wi-fi at the right time during setup.      1. Install a (non-domain) image onto the device over ethernet using MDT.      2. Connect to wi-fi using the local administrator account.      3. Join the laptop to the domain (over wi-fi).      4. Create the local account for the end-user.   If the device is domain-joined with MDT as part of sysprep or domain-joined over ethernet after setup has finished and THEN connected to wi-fi, the resulting wireless profile will be "per user", but will not exhibit any issues.   If the local user account is created and that account is used to join wi-fi, then not only will the wireless profile be "per user", but the wi-fi connection will drop whenever a running task owned by 'SYSTEM', 'LOCAL SERVICE', or 'NETWORK SERVICE' attempts to access something over the network.   ... View more

I had time to play around with one user's Macbook Pro (2018) and another's iPhone (4s). The Mac is running Mojave (10.14.6) and the iPhone is running iOS (9.3.5). I can understand if the iPhone 4s has issues due to an outdated OS, but I have had other Macs successfully authenticate today with different macOS all the way back to 10.10.   When I examine the affected Mac in more detail, the client is being tagged with a VLAN by the SSID and issued an IP address in the VLAN's subnet with the appropriate router and DNS server addresses. Then the splash page pops up.  Credentials are provided, and the splash page returns that the authentication was successful.  But the splash page seems to hang at that point without providing the user an option to click "done" or close otherwise the splash page.   On the Mac, I tried the built-in splash page dialog window (uses Safari), but I also tried by bringing up the splash page in Chrome after going to http://captive.apple.com. The same behavior happened using both browsers.   When I do a packet capture with Wireshark, I see a never ending stream of broadcast and probe response entries that only cease when the user presses "cancel" on the splash page.   I'm stumped.  I had 102 different BYOD Macs connect to this particular SSID today and this happened with 9 of them. ... View more

This is not a scenario that I tested, as I could only get the filter-id attribute to pass a group policy to a device if it authenticated using 802.1X. The majority of devices in my network are BYOD, so 802.1X authentication is not a viable option.   However, if you are using NPS on a Windows server to handle RADIUS authentication, you should be able to set time-based restrictions there and have customized network policies in NPS for passing different group policies depending on day of week and time of day. ... View more

I spent a week testing group policies in multiple scenarios and learned this about policy priority (sorry for the length)...   SSID Rules These are the first rules to be applied to traffic, and therefore have the lowest priority. There are a limited number of globally applied elements that will be effective if set at this level.   Layer 3:  These rules are restricted to IP addresses (in CIDR format) with port targeting. Best used for controlling access to the local network, but can be used to block IP addresses on the internet as well.          THESE RULES CANNOT BE OVERRIDDEN BY HIGHER PRIORITY GROUP POLICIES   Layer 7:  These rules can be used to block (Meraki’s) layer 7 categories, but can also block specific URLs, public IP addresses (in CIDR blocks), or individual TCP/UDP ports.          THESE RULES WILL BE IGNORED IF A POLICY IS ASSIGNED MANUALLY (even if that policy has no layer 7 rules)   Bandwidth:  These rules can be used to set global bandwidth limits for the entire SSID and individual bandwidth limits for clients.        THE *SSID* BANDWIDTH LIMIT CANNOT BE CHANGED BY HIGHER PRIORITY POLICIES        THE *DEVICE* BANDWIDTH LIMIT CAN BE LOWERED BY HIGHER PRIORITY POLICIES   VLAN Tagging:  If the SSID tags the device with a VLAN managed by a device downstream of the MX, then no policy will be applied (only ‘network default’ settings and the rules listed above) If the SSID tags the device with a VLAN that is managed by the MX but there is NO group policy assigned to that VLAN, then only ‘network default’ settings will be applied If the SSID uses NAT mode, then a policy will only be applied if a splash page is configured to do so If the SSID tags the device with a VLAN that is managed by the MX AND there is a group policy assigned to that VLAN, then the VLAN policy will be assigned to the device and it will have higher priority than any policy assigned by a splash page   Splash Page Group Policy (using Active Directory) These policies have the second lowest priority. They can override some of the SSID rules, and they can override ‘network default’ content filtering that has been set on the MX.   Bandwidth:  Lower bandwidth device limits set here will supersede a higher limit set in the SSID rules, but a higher device bandwidth cannot be set.         THESE DEVICE BANDWIDTH RULES CAN BE LOWERED BY HIGHER PRIORITY POLICIES   Layer 3:  These rules can be set to block specific URL patterns, IP addresses (in CIDR format), and even all traffic to specific ports.          A “DENY” RULE WILL REMAIN ACTIVE AND CANNOT BE OVERRIDDEN BY HIGHER PRIORITY POLICIES   Layer 7:  These rules can be used to block (Meraki’s) layer 7 categories, but can also block specific URLs, public IP addresses (in CIDR format), or individual TCP/UDP ports.         THESE RULES WILL BE IGNORED IF A POLICY IS ASSIGNED MANUALLY (even if that policy has no layer 7 rules)   Traffic Shaping:  Layer 7 traffic shaping rules set by this policy will only be applied if this is the highest priority policy that has been assigned to a device.         THESE RULES WILL BE IGNORED IF A POLICY IS ASSIGNED MANUALLY (even if that policy has no traffic shaping rules)   Security Appliance:  Rules set here will be effective and can be used to customize or even override the ‘network default’ content filtering set on the MX.          THESE RULES CAN ONLY BE SUPERSEDED BY A POLICY APPLIED MANUALLY TO DEVICES IN AN MX-MANAGED VLAN   VLAN Tagging:  VLAN tagging in this policy will NOT override any settings that were made at the SSID level         THIS SETTING HAS NO EFFECT IF A SPLASH PAGE ASSIGNS THE POLICY   VLAN Group Policy If a group policy is assigned to a VLAN on the MX and a device is in that VLAN, then then the VLAN-specific policy will be given a higher priority than a policy assigned as a result of splash page authentication. However, it will function in exactly the same manner as a group policy assigned by a splash page. Only a manually assigned group policy will be given a higher priority.   Manually Applied Group Policy This is the highest priority policy that can be assigned. Even if this policy tags a device with an MX-managed VLAN that has been given its own group policy, the manually assigned policy will still have the highest priority.   Bandwidth:  A limit set here will supersede ANY limit set elsewhere (up to the maximum device bandwidth defined in the SSID rules)         THIS RULE CANNOT BE SUPERSEDED   Layer 3:  These rules are effective and enforced. Any rule set here will be enforced unless a Layer 3 DENY rule from any other policy overrides it.        A “DENY” RULE WILL ALWAYS SUPERSEDE AN "ALLOW" RULE FROM A LOWER PRIORITY POLICY   Layer 7:  These rules can be used to block (one of Meraki’s) layer 7 categories, but can also block specific URLs, public IP addresses (in CIDR format), or individual TCP/UDP ports.        ANY RULES APPLIED HERE WILL BE APPLIED   Traffic Shaping:  These rules will be applied, but the upper bandwidth limit is capped at the lowest applied bandwidth restriction that is currently in place.         THESE RULES WILL BE APPLIED TO MATCHING TRAFFIC   VLAN Tagging:  If a manually assigned policy tags a device with a VLAN that is configured as a subnet on the MX AND the VLAN uses the same group policy, then all features of the group policy will function. If the manually assigned policy tags the device with a VLAN managed by a device that is downstream from the MX, then all features of the policy will function ECXEPT the ‘Security Appliance’ settings.     Security Appliance:  Depends on whether or not the device is in a VLAN managed by the MX.         THESE RULES ARE ENFORCED IF THE DEVICE IS IN AN MX-MANAGED VLAN         THESE RULES ARE NOT ENFORCED IF THE DEVICE IS IN A DOWNSTREAM-MANAGED VLAN       Splash Page Group Policy (using RADIUS) Meraki documentation indicates that splash-based RADIUS authentication will honor the filter-id attribute and apply a group policy to devices during authentication. Unfortunately, I cannot get it to work... but I can confirm that it does work if RADIUS is authenticating via 802.1X. (but that method is not feasible in my environment, so it was not extensively tested) ... View more

Thanks for the suggestion to open a support case.  If I ever need to tunnel down and find out where different things are happening, I will be sure to do so.   It never occurred to me that different devices (MX vs. MR) could be applying different policies. I just assumed the MR was a 'dumb' WAP and all group policy was applied by the MX at the MX. But I understand why you would want to apply rules at the AP instead of having the traffic traverse the internal network first. It just makes sense.   However, right now I am just trying to teach myself the ins and outs of group policy. The policies I have created in my production network are working just fine, but the method I have devised for applying them involves a lot of monitoring and manual changes. I am looking for a way to make the process more automatic and 'hands-free', so I am experimenting with things like... AD integrated splash page to set different policies for different clients Using the RADIUS splash page and the filter-id attribute to push different clients into different policies Setting VLAN-based policies on the MX Manually assigning custom policies using the client page in Dashboard (this is what I want to avoid)   At the moment, I am just exploring and trying to understand the behaviors I am seeing. If I understand why something happens the way it does, then I am closer to my goal of knowing how to set things up the way I want. ... View more

OK... here is a scenario with using different group policies   Group Policy #1 has 'append' set for Blocked URL patterns and the list contains roblox.com. As long as Policy #1 is being applied to a device, then roblox.com will be blocked on that device. I then apply Group Policy #2 to the device. Policy #2 has 'Use network default' set for Blocked URL patterns. However, because Policy #2 does not specifically overwrite any existing blocked URL patterns, roblox.com is still blocked because Policy #1 had previously appended it to the blocked URL list. But if I apply Group Policy #3 to the device and this third policy says to 'override' the Blocked URL patterns with youtube.com, I should find that roblox.com now works on that device, but youtube.com no longer works. This would be consistent with the behavior I have witnessed.   But let me change the order of things a bit. A device has Group Policy #1 applied to it and roblox.com is blocked as a result I then apply the 'normal' template to the device. Finally I apply Group Policy #2 to the device. Now roblox.com should work on the device because the intervening application of the 'normal' template wiped out any customization that had been applied by Group Policy #1. I will have to attempt this and see if the resulting behavior is actually as I have described. ... View more

Thanks.   I think I just needed someone to 'listen' as I talked through the whole situation. I have a much better understanding now of how to accomplish what I want with VLANs & Group Policy.   Of course I now have some questions about high-bandwidth flows over the internal network, but that is a topic for a different thread. ... View more

Ahh... so it isn't what device is handling DHCP that determines policy application, but what the client is using as its gateway that determines policy application.  That means...   If my Windows AD domain uses the MX IP as its default gateway, then group policy should get applied as expected to all domain workstations. If I set up an SSID that uses "NAT Mode: Use Meraki DHCP" for IP assignment, then the MX will act as the gateway for those devices and group policy will be applied as expected to all connected devices. If I set up an SSID that uses "Bridge Mode: Make clients part of the LAN" for IP assignment but have my MS320 supply IP addresses, then the 'interface IP' for the relevant VLAN on the MS acts as the gateway for those devices. But group policy should still be applied, because the traffic arrives at the MX from the SVI IP of the MS320, and the MX will apply group policy to all traffic from that IP.   Scenario 1 is exactly the behavior I have witnessed on my network with my domain-joined devices.   Scenario 2 seems to be working as well, but here is where I still have a question... Users connect through an AD splash page and I have different group policies that get applied in this scenario depending on the AD group membership of the user. Those work as expected. However, if I subsequently manually assign a device a different group policy, then BOTH the new custom group policy and the AD group policy seem to be applied simultaneously. Is this expected behavior, or should the manually applied policy be completely overriding the policy assigned during sign-in?   Scenario 3 does not seem to be working in the manner described above. When I set up an SSID in this manner, neither the automatically assigned AD group policy or a manually applied custom policy seem to work as expected. Bandwidth restrictions are still applied, but only port-based Layer-3 firewall rules work. URL/IP-based Layer-3 rules do not work, nor do any Layer-7 firewall rules. Any customization made to the network defaults on the security appliance are also not applied.   I originally had my wireless network set up as described in Scenario 3 so I could VLAN-tag and partition different user groups, but struggled with getting group policy to work properly, so switched to Scenario 2. I got working group policies as a result, but lost the ability to separate different user groups into different VLANs.   Does my problem stem from the fact that my VLANs are set up as interfaces on the MS320 switch?  If I configured my VLANs as subnets on my MX100 instead would that allow me to still partition users into different VLANs but have working group policies get applied to them?   And one last (sort of related) question. I work at a 750 student K-12 school and we have an MX100 (advanced security), an MS320, multiple MS2xx and many MR34/42. Is my network over-designed? Do I actually need the Layer-3 switch? How can I leverage the added functionality of the Layer-3 switch if I have to use the MX for all of my routing in order to properly apply group policies?   Sorry for an even longer reply 🙂 ... View more

Well.. just in case someone stumbles upon this thread in the future and wants to know if there was any resolution...   For about 10 days I had close to a dozen different laptops (all different makes, models & wi-fi chipset) that would spontaneously drop and reconnect their Wi-Fi connections all day long, regardless of which SSID they were connecting to. The network ecosystem at my school is a single physical network running entirely on Meraki hardware, yet this problem only occurred in one building on campus.   I did pursue all of the avenues of investigation that were suggested by those who responded to this thread. In the end, I made no changes to the network.  Last Thursday afternoon, the problem simply vanished.  I could not explain what caused it, and I cannot explain what made it go away.   There are still some other gremlins inhabiting the network in that building, but that is a topic for a different thread. ... View more

Hi Blake,   I will definitely run a packet capture the next time this I can confirm the issue is occurring on a laptop.  At this very moment, I am remotely copying a 5GB .iso file from the server to the teacher laptop that has been most affected by the constantly dropping Wi-Fi.  Of course, as soon as I tried this, everything started working normally on that laptop.   I will travel the building in a few minutes after students dismiss for the day and check teacher laptops for a 'victim' to act as a guinea pig.   ... View more

The Windows server only handles DHCP and DNS for a single SSID.  The only devices that connect to that SSID are school-owned devices that need to communicate with our on-premises servers, printers, and data projectors.  All devices in that subnet have preset IP addresses using DHCP reservations, and IP addresses are not assigned to new devices that connect.   I just examined the DHCP logs on the server from yesterday and scanned for one of the affected laptops. It shows that laptop...    1. Renewing its IP address    2. DNS update request    3. DNS update successful   That pattern repeats over and over every few seconds all day long. The only break in that pattern is when the teacher takes the laptop to another building.  Once there, the laptop connects and that is the last I see of it in the logs until it returns to the affected building. ... View more

Thanks Blake,   That was a possibility I had not considered.   However, when I examine the two switches in the affected building, both of them have L3 routing disabled, and neither are performing VLAN tagging or serving DHCP addresses. VLAN tagging is managed using group policy, and is based on either the SSID being used by the client device, or is manually set by myself when registering personal devices.   All of the affected devices are issued IP addresses by the Windows DHCP server running on our 2012R2 domain controller, and not by any Meraki hardware.  I have verified in the brief period of connectivity before the laptop disassociates that the correct IP address is being assigned to the client laptops by the DHCP server. ... View more

Hi Philip,   I agree that the behavior is reminiscent of a prankster sending out poison packets, but there are a couple of arguments against that...      1. This building houses our primary grades (K-3), and those students do not have personal mobile devices or laptops at school.      2. If someone was spoofing de-auth frames, then there would be more affected teachers/devices.  As it is right now, only a small number of teachers in the building have affected laptops, and the behavior persists even in the evening after all students have gone home.   When examining the wireless event log for the affected computers, there is a repeated pattern of    * 802.11 association    * WPA authentication    * 802.11 disassociation This behavior repeats from a maximum of every 15 seconds for some affected laptops, to a minimum of every 3-4 minutes for others (but not at all for most laptops)   Air Marshal only detects the three printers on campus that also broadcast a Wi-Fi Direct signal to enable printing from tablets.  Nothing else unusual shows up there (aside from the hundreds of Wi-Fi broadcasting vehicles that drive past the school each day.   All 54 access points on campus are running 25.12 firmware.  I actually rebooted all APs on campus (not just the ones in the affected building) to no avail. ... View more

Thanks Rudi,   I added that bit about UNC paths because it seemed a very unusual trigger for this behavior.  To answer your questions...   1. The SSID that these devices connect to is only used by our domain workstations, and they authenticate using Active Directory using the built-in Meraki captive portal.  On that VLAN, DHCP will only issue an IP address to pre-registered devices that have an IP reservation.  There are no RADIUS servers on our network.   2. All the access points on campus have an identical configuration.  That is why the behavior in this one building is perplexing.  It cannot be replicated in any other location on campus (even though all buildings are part of the same physical network).   3. I investigated the possibility that the wireless chipset on the laptops could be the issue. However, of the four different models of laptop that have been affected so far, and although all four use RealTek chipsets, there are three different chipset models between them. ... View more