Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About ronnieshih75
ronnieshih75
Building a reputation
Member since Jan 21, 2021
Oct 16 2024
Community Record
85
Posts
63
Kudos
4
Solutions
Badges
Oct 9 2024
8:04 AM
2 Kudos
Apple devices are sending accurate information down to the IOS version. We verified this by talking to users in person and comparing their device types to meraki dashboard. So why can't Meraki at least make that work? It's virtually completely non-working since many months ago, it used to work "just a little bit" and now not at all. I literally manually block these by hand on a daily basis. Let's not go down the path of talking about using 802.1.x auth and getting away from PSK SSID to prevent personal devices from getting onto a wireless network, we already talked about this above. We have several reasons why we cannot change the password readily for our legacy PSK based SSID, that's why I went down this path hoping this feature would work. Meraki should come out clean on why this doesn't work and kill this feature already. I've opened at least 3 tickets on this over the years and it has gone nowhere.
... View more
Oct 9 2024
6:48 AM
1 Kudo
This feature is still not working on AP firmware v30.7, a ton of months after I posted this originally.
... View more
Aug 16 2024
10:50 AM
2 Kudos
It still does not work properly for us, even with most apple devices properly identified by meraki via dhcp user agent string.
... View more
May 1 2024
5:03 AM
I opened a Meraki support ticket and they played it as a firmware update as always, using v30.6 . But this really doesn't fix the problem either after I upgraded ap firmware for some 40 wireless networks. They did note that this feature does not work for 802.1x authenticated wireless network, and I accept that. He did state that this should work for a PSK wireless network but it is not, no matter what firmware version the AP's are sitting on. Once again, I have a PSK network that I cannot get rid of and readily change password on as many IoT devices are connecting to it. We just need to block personal mobile apple and android devices not MDM managed.
... View more
Apr 19 2024
7:49 AM
1 Kudo
We already have a SSID using RADIUS servers with 802.1X auth using internal CA issued certificates, for all windows machines. I will be turning off PEAP authentication off that network then personal devices with no enterprise issued certs can get on that network. However, I have 1 PSK based network that I cannot readily change the preshared key on, that is why I'm looking for this feature to work. My question is that if Meraki is detecting some clients properly under the "device type,os" field, then why isn't the feature at least working for those identified devices? I get the whole user agent string thing through DHCP request and I've been down this path with meraki support. I usually get a fall-off-the-cliff answer with support but noting this problem to them at the Cisco corporate office in Chicago only gets me pulled into a small room so I don't embarrass them in front of a large crowd red faced. If this feature does not work at all, then by all means it should be taken off the dashboard completely.
... View more
Apr 19 2024
7:20 AM
So the solution is to spend another half a million dollars?! I am looking to block personal mobile devices from getting on wifi, not MDM enterprise managed devices. None of these personal devices would be managed whatsoever with MDM software but needs to be blocked off specific wifi networks. Because we deployed Forescout and it has its shortcoming is cannot fingerprint mobile devices properly either.
... View more
Apr 19 2024
7:02 AM
Have been trying to get this feature to work literally for years. We need to block iphone and android devices on 2 SSIDs. The SSIDs are configured through a template with the template assigned to over 200 wireless networks. I can obviously see iphones with specific IOS versions being detected under Monitor/Clients but these devices are not getting blocked at all according to the policy I configured. I've called Meraki support about this in the past and was given a fudge-over type of vague answer why this feature does not work and they are working on a different method to make this work. Advise on whether anyone has this working at all.
... View more
Apr 12 2024
8:15 AM
2 Kudos
Problem solved by reversing the custom expression setup. thanks!
... View more
Apr 12 2024
7:53 AM
Are you say I should have wsus server's IP as destination and from of Any? Because even Meraki support said what I have is right 😂
... View more
Apr 12 2024
6:58 AM
We are looking to send microsoft patches from a WSUS server behind the MX450, via multiple MX450 headends from our data center via WAN2, down via the spokes' MX84 or MX85 WAN2. This is so that WAN1 of both SD-WAN headends and spokes remains relatively free for other production applications. We configured VPN traffic custom expression of the following on both MX450 headends and MX84 and MX85 spokes: protocol: any, source: ip address of wsus server 10.105.x.x, source port: any, destination: any, destination port: any We see this traffic flowing over WAN2 on the MX450s, but we DO NOT see this traffic flowing over WAN2 for MX84 or MX85 spokes. I verified this by doing packet capture for "site-to-site vpn over internet1" and "site-to-site vpn over internet2". Active-Active autovpn is enabled on all spokes, so autovpn is established on both WAN1 and 2 on all spokes. please advise what can be the issue.
... View more
Jun 1 2023
9:59 AM
It is a Meraki Nxxx URL. But I do not have the full URL as I'm waiting for a field tech to tell me when it happens again. We run MX85 + MR56, neither one of these have splash authentication enabled. However, the wireless network that contains and run the MR56 during the time period this happened shows splash authentication attempts in Network-wide/Monitor/Event log
... View more
May 30 2023
11:41 AM
One of our locations run all MR56 AP's on v29.5.1 firmware, and it has been so for many months. The wireless network is tied to a template which defines all SSIDs and settings. One of the SSIDs use 802.1X auth against RADIUS service running on our Forescout servers. The SSID has no splash authentication enabled, with "None (direct access)" checked. Basically, end users would login to the Windows OS, and Windows OS uses AD credential in the background, passes the creds to the RADIUS server and endpoint devices automatically connect. We have had no issues with this setup, until recently, when we started upgrading some Windows 10 to Windows 11 OS. We've come across a few instances of endpoint laptops getting the "Action required prompt" in the Windows 11 wifi widget. Upon clicking on that, it opens a browser and attempts to connect to one of the dashboard URLs as if splash auth or captive portal is enabled. This does not happen on all windows 11 endpoints, just some. This splash authentication attempts also show up in the event log of the relevant wifi network in the Meraki dashboard. Any insight to why splash authentication is happening?
... View more
Mar 26 2023
9:09 AM
So what do you think is the problem with traffic to 10.130.0.0/16 when hub#2 and hub#3 are configured as a combo for spokes? I have not upgraded hub#1 due to fear of issues without backup hub to failover to for spokes. This is on the to-do list. My plan right now is to configure all spokes with hub#1 in the hub list, then upgrade firmware on hub#1. I was suggested to run the new hubs on v18.106 by another meraki support tech due to performance improvements for MX450 with firmware v18.106 . If upgrading firmware on the hub#1 fixes this issue then we'll get that done asap.
... View more
Mar 26 2023
8:48 AM
Through a lot of testing. I noticed the following odd behavior: - When I configure a spoke with hub#3 as primary and hub#1 as secondary, getting to anything in 10.130.0.0/16 is snappy. No issues, no additional BGP routes in the route table - When I configure a spoke with hub#2 as primary and hub#1 as secondary, getting to anything in 10.130.0.0/16 is snappy. No issues, no additional BGP routes in the route table - When I configure a spoke with hub#2 as primary and hub#3 as secondary, getting to anything in 10.130.0.0/16 has a delay and seems to behave like a failover happened, when our application finally loads in Edge browser, sometimes with a 'network has changed' message. I see additional BGP routes on top of the static routes. I believe those self created BGP routes are getting in the way with inter-hub communication turned on, for hub#2 and hub#3. Even though static routes by default has the lowest admin distance over BGP routes.
... View more
Mar 25 2023
9:42 PM
Experimenting again late night. I added static route of 10.130.0.0/16 to both hub#2 and hub#3 I noticed the following: - for a spoke with hub#3 as primary and hub#1 as secondary, I see routes as: active, 10.130.0.0/16, meraki vpn: static route, next hop of hub#3 active, 10.130.0.0/16, meraki vpn: static route, next hop of hub#1 inactive, 10.130.0.0/16 , BGP - next hop of hub#1 - for a spoke with hub#2 as primary and hub#3 as secondary, where I removed the original single hub#1. I see routes as: active, 10.130.0.0/16, meraki vpn: static route, next hop of hub#2 active, 10.130.0.0/16, meraki vpn: static route, next hop of hub#3 inactive, 10.130.0.0/16, internal, BGP - next hop of hub#1 active, 10.130.0.0/16, internal, BGP - next hop of hub#3 active, 10.130.0.0/16, internal, BGP - next hop of hub#2 I understand the static routes since I added them, but I am not understanding the plethora of BGP routes especially for spoke where I removed hub#1 and added hub#2 as primary and hub#3 as secondary. I am getting sporadic routing behavior for the second scenario where the BGP routes are there. Do I actually have inter-hub communication turned on for hub#2 and hub#3 ??? hence the BGP routes? I don't see where BGP routes are popping in from because we run all hubs in routed mode with only OSPF enabled talking to backend Nexus switches.
... View more
Mar 25 2023
9:00 PM
Hub#2 and Hub#3 both have OSPF enabled to advertise routes into the nexus 9k backend switches. I actually believe the inter-hub communication, which was enabled by default, before meraki support disabled it, had iBGP peering established amongst all the hubs. Because I see remnants of this route as 'BGP' for some spokes. So if static route for 10.130.0.0/16 only existed on hub#1, then spokes established with hub#2 and hub#3 would flow over hub#1 to hit 10.130.0.0/16 . Even though we know this inefficient, however, it is almost like a 'backup' if somehow static routes on hub#2 and hub#2 goes haywire.
... View more
Mar 25 2023
7:49 AM
I must have a brain fart this morning. You are correct 10.0.0.0/9 does not cover 10.130.0.0/16 . I recall now that the route was in there when I inherited this whole infrastructure. Good point on using 10.0.0.0/8 however that might off traffic for our other portion of the network. Yep, the people who came before me built Azure infrastructure on the other side of our data center using 10.129.0.0 and on. This theoretically would work but might cause routing issues. I'll put it on the to be tested list. With the above said, what are my proper courses of action? - do I have meraki support re-enable inter-hub communication? does this serve any purpose? OR - do I simply need to pop in the static route of 10.130.0.0/16 on the two new MX450 hubs?
... View more
Mar 25 2023
7:11 AM
I have a static route 10.0.0.0/9 as summary route on all three hubs, it's advertised through vpn. I have another static route of 10.130.0.0/16, it's advertised through vpn, but only on hub #1. 10.0.0.0/9 really covers 10.130.0.0/16, but for the life of me I cannot recall why I placed this on hub#1, perhaps something didn't work with the summary route by itself. Also, what appears to be happening is that spokes somehow know that they need to get to 10.130.0.0/16 through hub #1 only since they all homed to hub#1 in the past and that route somehow remained in the list. I took off hub#1 and place in just hub#2 or #3 as sd-wan hub in the past few days for some spokes, then traffic from spokes to 10.130.0.0/16 breaks. I have to have hube#1 in the hub list for the spoke to get to 10.130.0.0/16. I'm not sure if the above has something to do with meraki support turning off inter-hub communication. It appears to some degree yes. If inter-hub communication is turned on, then a spoke homed to hub#2 knows to route over to hub#1 to get to 10.130.0.0/16. But this is not ideal and is not what I want the traffic to flow. A spoke homed to hub#2 simply needs to get to 10.130.0.0/16 via the summary 10.0.0.0/9 route via hub#2, no need to route through hub#1.
... View more
Mar 25 2023
6:06 AM
Hello, we recently brought up additional MX450s with a second and third hub sites. I had opened a case with meraki support a while back because I had no idea that the LAN side networks must be diverse in order for hub option to even be abled. Therefore, a tech suggested that we disable the ability for hubs to communicate among each other. However, this feature had nothing to do with the ability to enable the new hubs. We then created 2 other diverse backend /29 transit networks for the two new MX450s and enabled the two new hubs. My first question is: what does this ability for hubs to communicate amongst each other do? Second question is: I have some strange routing issue with spokes still needing to talk to the first original hub because I apparently had defined static routes for specific destination on that original hub in the past and it is the hub that endpoints are shooting over to for communication with those specific destinations. However, I have summary static routes defined on the 2 new hubs and spokes are not taking the path through the 2 new hubs for those specific destinations. The minute I disable those specific routes, endpoints aren't using summary route to get to those destinations. Should I be speaking to our hosted data center backend to see what's up with this? thanks
... View more
Feb 24 2023
4:49 AM
4 Kudos
Well, we did consider using BGP, but it requires us to run MX450 in one-armed mode, which means we need a pair of super high-end high-powered routers in front of the MX450 to NAT with MX450 having just 1 single IP address. Since it needs to talk to the internet and internally at the same time. That was not an option for us either to scale out quickly, as it took some 6+ months for us to purchase a pair of Cisco ASR routers for a separate project due to supply chain issues. We just cannot wait that long. There are things I wanted to do from design perspective but reality shows me otherwise. So I'm left with this right now. Cisco responded last night and they can disable the ability for hubs to talk to each other in the backend, it's an hidden option. I'll be calling Cisco support this morning to get this going.
... View more
Feb 23 2023
4:38 PM
You basically answered my question. Layers 3 needs to be in different subnets, which means multiple OSPF areas. We do not have a second data center, and Azure VMX cannot handle the traffic volume we have. And our existing MX450 hub cannot handle high volume of traffic when software patching is happening through 170 spokes, basically sheer volume of packets pegs the CPU of the MX450 to between 90 to 100%. I actually called Cisco out on this at their Chicago Cisco office. In any case, that's not my objective here. Our company is expanding extremely fast and we need to scale out. Suggestions from multiple sources say to deploy multiple MX450 hubs. We are also looking at another SD-WAN solutions.
... View more
Feb 23 2023
3:56 PM
We currently have 1 single MX450 hub sitting inside our on-prem data center. A second and a third set of MX450 were acquired and after 2 months of design, tonight came down to bring them up and running. We've configured the LAN side to be in the same 10.28.0.0/29 subnet across the three sets of MX450, because it's easier to advertise via a single OSPF area 0 in the backend to Nexus 9k switches. Upon attempting to enable site-to-site VPN, on the second set of MX450, I received error message: "There were errors in saving this configuration: The local subnet 10.28.0.0/29 conflicts with a remote VPN subnet on the network IL - DC - CPC MX450-1 - appliance (10.28.0.0/29)." Does this basically mean that all hub sites must sit inside diverse LAN subnets? And this translates to setting up multiple OSPF areas for route exchanges in the backend? thank you.
... View more
Jan 4 2023
11:06 AM
2 Kudos
Thank you for the articles. I found the issues eventually myself. The endpoint test laptop did not have certificate meant for client/server authentication from our internal CA installed. Also our Forescout server did not have the intermediate certs from the subordinate CA servers. After that, I also found out that on the endpoint, I had to configure authentication to do "Computer authentication" only because user was getting tried and that's not what I want. THEN, I found out on the Forescout or RADIUS server, a different cert was getting hit. So I had to reconfigure the client end to use that cert instead. 802.1x EAP-TLS authentication then started working.
... View more
Jan 3 2023
10:02 AM
Once again I'm hitting this community for some potential answers. I am attempting to setup 802.1x authentication using certificate on a "wired" Windows 10 host against Forescout as the RADIUS server. Forescout does not have great documentation on how this should be done on the Windows side. Currently, Meraki support verified that the Windows 10 test host I have is not sending 802.1x auth attempts and failing over to MAC address bypass directly. On the Meraki switch side, just to verify nothing is setup wrong, I have an access policy under switching/access policies: - my RADIUS server with the Forescout's host IP port 1812 and shared secret -> verified to work - RADIUS testing enabled - RADIUS CoA enabled - RADIUS accounting with the Forescout's host IP port 1813 and shared secret - RASIUS attribute specifying group policy name: None - Host Mode: Single-Host -> I have just a laptop attached to a switch port - Access policy type: Hybrid authentication - Guest VLAN: our guest vlan ID of 133 - Failed Auth VLAN: None - Re-authentication Interval: None - Critical Auth VLAN: None - Voice VLAN client: Bypass authentication - URL redirect walled garden: disabled - Systems Manager enrollment: disabled I believe the above works, I am not clear regarding what settings should be on the Windows 10 host side, even with Forescout's professional service help. I have our internal CA's root cert loaded in Forescout, as well as on the Windows 10 host. Windows 10 host is configured with these settings under the Authentication tab of the Ethernet NIC: - Enable IEEE 802.1X authentication - Choose a network authentication method: "Microsoft: Smart Card or other certificate" - Verify the server's identity by validating the certificate unchecked Under "Microsoft: Smart Card or other certificate" Advanced setting: - Use a certificate on this computer with Certificate Issuer being our internal root CA's cert - Extended Key Usage (EKU) checked - All Purpose unchecked, Client Authentication checked, AnyPurpose unchecked Please advise, thank you.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 978 | Apr 12 2024 8:15 AM | |
| 4173 | Jan 4 2023 11:06 AM | |
| 6480 | Nov 29 2022 12:25 PM | |
| 7019 | Aug 27 2021 9:40 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 8 | 38056 | |
| 7 | 38175 | |
| 5 | 39156 | |
| 4 | 1263 | |
| 4 | 37141 |
© 2024 Cisco Systems, Inc.
