Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About mak2018
mak2018
Here to help
Member since Apr 11, 2018
Nov 8 2023
Community Record
24
Posts
0
Kudos
0
Solutions
Badges
Sep 27 2023
8:22 AM
Update to all this, it seems OSX clients won't tag ZOOM traffic over a Meraki SSID, but the AP will tag that traffic once it sees it. I assume this is due to fast lane on OSX but I really don't have any way to confirm that. Can you disable fast lane via Meraki? At the end of the day we have it working mostly for what we want and these are the traffic shaping rules we ended up with. We see the tags from the client or the wired side of the AP if the client isn't tagging it.
... View more
Sep 22 2023
4:04 PM
@GIdenJoe These are the default rules you are referring to? If so have you had good results using them? I can set ZOOM to use whatever I want and can go as far as to match those default rules.
... View more
Sep 22 2023
2:07 PM
The reason I did is because 56/CS7 is what Cisco recommended and ZOOM defaults to. I am not seeing the right tags from the client connected to the AP when it reaches the firewall. So it’s either all traffic is being tagged as CS7 or none of it. Versus outside the office where my voice and video are being tagged correctly. I can change CS7 to something else once I have this working correctly.
... View more
Sep 22 2023
11:43 AM
Yeah so that is from my house, so the only rules applying there are ZOOM marking them which it is doing. In the office doing a packet capture from the firewall for wireless clients I don't see any tags or I see all (CS7) 56 which is just odd. So I figured Meraki must be doing something nefarious because on the backbone we are just trusting the tags and prioritizing traffic based on them. Below is from the firewall for a wireless client at the office and all their traffic towards the internet. You can see all this users traffic is tagged as CS7 and we see the complete opposite from other users with 0 tags whatsoever. I wanted to be sure that if Meraki does see those tags it doesn't limit bandwidth to them. So that is where the traffic shaping rules came into play and how to best ensure we had them configured correctly. When checking all the moving parts we are seeing odd behavior and not sure what is causing it. Make a long story short we are tagging traffic from ZOOM and we aren't seeing those tags applied correctly to wireless clients. We know those clients can send/receive those tags because we see them outside the office, why inside the office we don't see the same behavior is the unknown. Do you know if I specify a localsubnet on a rule will Meraki tag all packets on that subnet that match the ports I have defined on that same rule? Its just not clear on what exactly those definitions are doing. Let me see if I can decipher what wired office clients are doing.
... View more
Sep 22 2023
10:57 AM
I have no MX, I have PAN firewalls at the office. At home, outside of my network and sans Meraki I get the correct tags via my ZOOM client installed via the MSI file. I want the same behavior in the office but again something is not translating. Sometimes clients get all CS7 (56) and sometimes they get none at all. All of them share the same wireless/core/firewall which is prioritizing traffic, but why some get tagged with 1 tag and others get no tags is the problem I am having. And since this is only deployed on our wireless I am looking at the APs as part of the problem. But traffic that is tagged is being influenced and given priority, I can see that. ZOOM admin console: Packet capture from my home office, so the only influence here is ZOOM sending DSCP tags 56 and 40 to my client and vice versa so I know ZOOM can tag its traffic correctly on both windows and OSX. What I don't fully understand is the correlation of ZOOM sending tags and Meraki honoring them if seen, adding them if not seen and or stripping them?
... View more
Sep 22 2023
9:58 AM
Good point, so to be clear, we have ZOOM configured to push DSCP tags but our windows clients aren't honoring them along with some OSX clients in the office. So to get around that we are trying to enforce them via Meraki as well as no bandwidth limits for traffic matching those DSCP markings. But what does it matter if ZOOM is enforcing them and as well as Meraki? I mean if the tag is there no harm no foul, if it isn't then Meraki should apply it right?
... View more
Sep 22 2023
9:46 AM
I am NOT specifying destination ZOOM CIDRs in the shaping rules in Meraki. Are you saying don't specify 443/80 on the traffic shaping rules? The only place I am specifying them on the firewall and I have to in order to be sure the FW is only prioritizing traffic to and from those specific IPs. On my PAN FW We are matching ports/destination IPs and DSCP tags to prioritize traffic so what I am trying to accomplish is to ensure the tags we are prioritizing are being sent from ZOOM, honored/applied if not already by Meraki and then prioritized accordingly.
... View more
Sep 22 2023
9:30 AM
Yeah man, we have done all that. I am more focused on the Meraki side as to what is the best way to enforce/apply those tags on the AP/wireless side.
... View more
Sep 22 2023
9:14 AM
Trying to wrap my head around the best way to apply traffic shaping rules to tag/enforce DSCP ZOOM traffic via MR access points. We are applying DSCP tags from ZOOM so my assumption is that I need to enforce those on the SSIDs which we have done below. But because zoom uses 443/80 and I choose the ports as definitions it tags all 443/80 with DSCP7 which I am not sure I want. On the edge we are prioritizing traffic based on those tags and destination IPs (long list of ZOOM/Teans CIDRS) so this works because all wireless traffic over the ports below are prioritized through the network to the FW. FW then decides what to prioritize based on our QOS policies. Teams seems easier as we are using specific UDP ranges whereas ZOOM uses http/https ports which can turn into a problem. Is there a better way to do this to only tag ZOOM specific traffic using definitions?
... View more
May 18 2022
10:28 AM
Is there a way to limit API access to a read only account? Just not clear after reading the documentation if API gets all admin access or you can limit via the user account access?
... View more
Dec 15 2021
6:16 AM
We have been using Meraki for years and all of a sudden last week Windows 10 clients weren't able to connect. Auth would succeed on the Windows NPS server but on the client side they would get a message saying "Cant connect to this network" or something to that affect. OSX clients can connect without issue. Support team found that unchecking 'verify server certificate' allowed them connect. So the ops team updated both certs and restarted NPS but still some users are getting the same message and unchecking that setting allows them to connect. Does anyone have any idea what can be done on those Windows 10 clients to allow them to verify the cert and connect? The cert is valid and the only think I can think of is something changed on those win10 clients that is preventing them installing or validating a new cert? Note that we have always had a cert on the NPS server and this was never an issue until last week.
... View more
May 5 2020
1:51 PM
Ok, cert was installed without the key which broke auth for win10 clients. OSX and Android were able to auth without issue regardless of whether they key was installed on the NPS server. Once the cert + key were reinstalled it started working (had to stop/start NPS). Hopefully this helps someone in the future.
... View more
May 5 2020
11:14 AM
Thanks but I didnt install the cert, another team did so I can't say if it was installed right or wrong. But all of this would lead me to believe it is cert related. First link doesn't apply as we aren't using win7 clients, all win10 and OSX. Second link looks promising because when I look at the recently renewed/installed cert on the NPS server it has no KEY whereas the previous ones did. Checking with the team that manages that aspect right now.
... View more
May 5 2020
11:08 AM
Password complexity didn't change and if it was that I would assume it would be across the board but it isn't. Its just this single NPS server. Same CA digicert. The only thing we have seen in the packet captures showed some TLS mismatches between windows clients and the NPS server but even when enabling 1.2 which the Windows clients appear to be using it made no difference. At my wits end here.
... View more
May 5 2020
10:50 AM
have a strange issue. Are primary NPS (2008R2) authenticating against AD has been working a long time. The cert expired and that server was recently patched. Cert was renewed, installed and the policy updated to start using it. Sometime between all of this (COVID-19 no one in the office to notice) Windows10 clients can no longer connect and the logs on the NPS server show the right clients/policy/etc.. but always deny access based on: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect. If I test auth from the Meraki portal using that same u/p it works fine. If I push auth to another radius server in our environment those Windows10 clients can connect without issue. Obviously, different server, different cert but identical policies. I have tired everything, recreating the policy. update the pres-hared key, disabling cert check on local clients, enabling TLS1.2 but nothing seems to matter. Note OSX/Andorid have no issues connecting via the same policy/NPS server..Just seems to be windows 10 machines. Does anyone have any ideas that can help me figure this out?
... View more
Feb 11 2019
8:13 AM
What do you want to know exactly? What settings are changed where? I don't follow your question. Like I said Win10 cannot create the profile by itself when a user attempts to connect for the first time. It has to be created manually and that is the problem I am trying to solve. FWIW I asked the help desk team for the settings they are using and will share them.
... View more
Feb 9 2019
1:01 PM
PEAP man and its from digicert or thawte IIRC. Dont know the settings as I am not on the helpdesk but the fact remains something with Win10 and the NPS/CERT is causing an issue. Manually creating the profile or pushing out via GPO doesn't solve the issue at hand, its just a workaround.
... View more
Feb 8 2019
12:50 PM
Nope because it doesn't even get far enough to create the profile automatically in Win10. It just fails to connect without creating a profile. Trying to make this work so no manual intervention is needed.
... View more
Feb 8 2019
12:38 PM
We have our coporate SSID that seems to simply not work on Windows10 clients. Help desk has to manually configure the profiles on Win10 boxes in order to allow them to connect. We have tested this ad nausea and from what I gather when a win10 user attempts to connect and authentication is pushed to an NPS server using a wildcard certificate an error 16 is thrown on the NPS server. But if I use the same u/p from the meraki portal to test authentication it works fine. Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect. If we push AUTH to an NPS server using a cert that matches its name it works without issue. OSX doesn't have this issue, just windows. Has anyone seen this before?
... View more
Apr 12 2018
11:41 AM
Yes and no, server name isn't but the domain is. We use split dns my man. I am good now, just wanted to know what my options were. Been using Meraki + NPS + public certs for a long time.
... View more
Apr 12 2018
11:32 AM
Initially tried to use an existing wildcard (not the norm) but in the end just bought one with the server name itself.
... View more
Apr 11 2018
3:58 PM
Been using Meraki and NPS for sometime. Usually get a digicert installed on the NPS and users need to accept the cert the first time when authenticating. Is there a way to just allow them to authenticate and validate the cert without them having to accept it?
... View more
© 2024 Cisco Systems, Inc.
