Meraki

rhbirkelund

I see that there has already been a few post on this here and here. Just recently, I have also been granted RO access to an Organization with an API Source IP restriction. When trying to get organizations IDs for specific orgs (not including this), I'm getting random 403s just by the query alone. Exception has occurred: APIError organizations, getOrganizations - 403 Forbidden, {'errors': ['Your client IP address [ip address] is not within an approved subnet for organization [org name and id]']} ... meraki.exceptions.APIError: organizations, getOrganizations - 403 Forbidden, {'errors': ['Your client IP address [ip address] is not within an approved subnet for organization [org name and id]']} I can guarantee that I am not changing IP addresses, which makes it even more odd as to why it works sometimes, and others don't. I fully understand that there may be requirements to limit on Source IP, who may use the API towards ones organization. What I do not understand, is why must this restriction affect ALL my organizations?! Why send a 403, and thus make the Endpoint fail, rather sending a 200 that everything is OK, but in the management details field state that there is an IP restriction? This is already the case for Orgs that have Dashboard IP, unlicensed or anything else. I would even go as far as to argue that having a 403 returned on an API Source IP restriction makes the Meraki IP completely unreliable and in some cases unusable. Not I will have to manually determine the Org ID, rather then simply iterating through the orgs for the ones I am to work on. No automation at all, available.

rhbirkelund

I almost can't believe it. After having a case open for a whole year. OpenRoaming now works!

rhbirkelund

Good job, everyone. 🙌

rhbirkelund

Wow - that was not something I had expected. I really feel like the amount of gotcha's in Meraki lately if going through the roof.

rhbirkelund

I have 17.18.2 running on 9300s in our lab. So far nothing extraordinary.

rhbirkelund

Very likely that is the same concept as Meraki AutoVPN over MPLS. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS As long as there is an exit node to the internet where the MXes can call home, and get information about their peers, the VPN should build between the MXes directly - eventhough each peer only has privately routed IP adresses. The MX'es require Internet access, otherwise they won't be able to get information about eachother and establish VPN connection. However, if Internet access is lost, the VPN connection will not go down immediately, as peer information is purged over time. Internet access to the registry matters only if there's a change in contact information after the VPN tunnel goes down. If contact information between the peers are the same, the VPN tunnel will go up again, even if Internet access is still missing. However, after a couple of hours, the peer information will be purged, and the tunnel will go down again. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Site-to-site_VPN/Meraki_Auto_VPN_-_Configuration_and_Troubleshooting#VPN_Registry_Disconnected

rhbirkelund

OpenRoaming integration with Cisco Spaces Change: Updated prerequisites: "Pending Public Release of Open Roaming New Architecture". Coindicing with my case that's been open since January being updated with it finally being fixed.

rhbirkelund

Does the dashboard still complain with a device managed switch? I think we do the same with semicolons on non-Meraki or switches not in Meraki Dashboard, but perhaps this would be a better fit for using tags?

rhbirkelund

I'd avoid the EOX API for everything Meraki. It's buggy, and data seems inconsistent, and the Support Mailling list just seems uninterested in fixing it. I've had some queries I tried following up on, and no one seemed interested to do anything about it.

rhbirkelund

Are you talking about the Cisco Champions? Because, that is not my impression at all.

rhbirkelund · ‎Dec 7 2025

I have never had a customer using Systems Manager, and I don't really think it's that relevant for customers in my country. I've only ever touched through the CMNA stack that I got at first, and has since then played around with it a little to get a feeling of how it works and how to use it. I have devices at home that I have enrolled. Systems Manager in its entirety as an MDM solution, I don't think it relevant however, there are som aspects of Systems Manager that I still think might be useful, and would be interested to see if or how it could be continued or even improved.

rhbirkelund · ‎Dec 4 2025

I see many customers going with Intune, since they find it better Simply out of curiosity, why makes you think SM is superior? Why is it better than Intune or other MDM systems?

rhbirkelund · ‎Dec 3 2025

Yes, but that shouldn't necessary, since it's Meraki itself that's the Root and Intermediate CA. I also don't see where I should upload this. The Certificate page, is related to Access Manager. This is not Access Manager.

rhbirkelund · ‎Dec 3 2025

The SCEP certificate issuing is not something I do as such, but Meraki SM, upon enrollment. I login with my Entra Credentials to the SM portal, which creates a profile, including SCEP certificate. Once enrollment is done, as far as I understand the documentation, Entra is out of the picture again. From there on, it's the trust relationship between the Trusted Access profile and Meraki Cloud Authentication.

rhbirkelund · ‎Dec 3 2025

Hey I've been trying to lab a couple of things today, one of them being Wireless Trusted Access. Since Meraki now supports Entra ID integration, it's possible to use Entra and IdP for the Wireless Trusted Access. After working through a combination of three deployment guides, I've finally gotten so far as to getting the enrollment to work. I am able to browse to portal.meraki.com with my Network ID, login with Entra ID credentials and enroll my device for Trusted Access. Downloading and Installing the Profile for my iPhone, works. I am almost at the finishline however, I've reached a block, that I have no idea what's causing it. When I attempt to connect to my Trusted Access SSID, my client fails and the Eventlog shows EAP Failure. No other details, no nothing. And for the life of me, I cannot understand what's not working. It seems there is some trust that is missing, but I'm not sure where it is, since this should all be provisioned automagically by Systems Manager. Organization -> Configure -> Certificates, has the SCEP CA as trusted anchor, but I'm not entirely sure, that this is related. Any ideas as to what I am missing?

rhbirkelund · ‎Nov 26 2025

I am not implying that it is supported. Simply stating numbers. From what I understand, 20 ms RTT is the requirement between AP and CCG. Is it a hard limit? I doubt it, so with longer RTT it would probably still work. From my understanding, it's possible to have the MCG assigned one network, and have APs on several other networks, all connecting back to the same MCG. That way, sites can be segregated, and all still have one exit point, much like the Local Mode APs we know today on 9800 platform. Of course, the APs need to have a way back to the MCG. Whether this is a routed link or a VPN connection, who knows. As long as there is a route back, that is not Internet. All I'm saying is, will it work? Likely, yes. Is it supported? No. As is the case with most corner-case Cisco deployments. And if it doesn't work? Too bad, it should have been tested in a POC before deployment.

rhbirkelund · ‎Nov 26 2025

I think you should be able to achieve this by using VLAN profiles, and define a Named VLAN group, where you can concatenate VLANs, much like a VLAN group on a Wireless Controller. You'll have to create a VLAN profile, and define a group with vlans. Assign the APs to that VLAN profile, and then refer to the Named VLAN in on the SSID settings.

rhbirkelund · ‎Nov 25 2025

I'm curious, what's the requirement for only sending 80/443 over VPN, based on?

rhbirkelund · ‎Nov 24 2025

You probably have to dig through old Sales Orders, and look them up in CCW-R. At this stage, I think your best option is to bite the cost and physically get up to the AP, or accept that you have two "spare APs" mounted somewhere unreachable.

rhbirkelund · ‎Nov 23 2025

Otherwise you could try the "Meraki Click of Faith". Type in the SKU, and just click Add, eventhough nothing shows up in the search. This has usually been the case with Meraki SKUs in CCW.

rhbirkelund · ‎Nov 23 2025

Any chance it's already claimed in the inventory, but just not assigned a network? In that case, the mac address would suffice.

rhbirkelund · ‎Nov 23 2025

Or a set of NoName, unmanaged 4port switches from a nearby electronics store, may also do it.

rhbirkelund · ‎Nov 23 2025

Seems to work?

rhbirkelund · ‎Nov 20 2025

No, an AP can only tunnel all its SSIDs to the same MCG cluster.

rhbirkelund · ‎Nov 19 2025

An AP can only tunnel SSIDs to one MCG cluster.

About rhbirkelund

rhbirkelund

Community Record

Badges