Hi All, I setup an Anyconnect server on a Azure vMX and at first everything was working just fine - VPN worked with SSO, domain joined PCs would just auto-login to the VPN and could access resources in Azure just fine. Then after about 1 week (nothing changed) the VPN stopped authenticating. It would still display the "success" window on login attempt, but it just hangs and never logs in.  If you close the window, Anyconnect thinks the user cancelled auth and it doesn't connect. Below is the window that pops up on login.  6/30/2022 - Anyconnect Message log        11:11:13 AM    Contacting VPN.        11:15:26 AM    User credentials prompt cancelled.        11:16:26 AM    Ready to connect.        11:43:44 AM    Contacting VPN.        11:44:06 AM    User credentials prompt cancelled.        11:44:06 AM    Ready to connect. I even tested with a test user on a non-domain joined PC and the corporates SSO login page opens fine and I can login, then this window pops up again and the connection hangs.  Changing auth type from SAML to Meraki Authentication allows users to connect with Meraki credentials, so I know the vMX and Anyconnect server is fine, the issue lies within the SAML, but it worked beautifully and then stopped. MX code is 16.16 Any thoughts or tips to pursue a fix for this?   ... View more

Hi All, Having some issues with Anyconnect on MX 64 (MX 17.6). I have a very basic Anyconnect setup. Below is a diagram of how I have my MX setup in a lab setting. I put static NAT in my router to port forward a custom port for Anyconnect using 8443. AAA is set to use Meraki Cloud Authentication. Client Anyconnect version is 4.10~ When I connect I do get a login prompt but after successful Auth the connection fails. At this point it stalls for a few and then the following two popup errors are displayed This happens everytime I get through the login. Anyone have this issue? I did a packet capture and look through the event logs but I can't see what is causing the connection failure.  EDIT: I did finally find something in the event log that shows a possible clue: May 18 13:38:17   AnyConnect VPN connection event msg: Server IP=10.10.40.19 Server port=8443 Prot[TCP] Peer IP=X.X.X.X Peer port=48571 conn_id[4] Connection closed. May 18 13:38:08   AnyConnect VPN session event msg: Sess-ID[5] Peer IP=X.X.X.X User[torydav@...]: Session connected. Session Type: SSL May 18 13:38:08   AnyConnect VPN session event msg: Sess-ID[2] Peer IP=X.X.X.X User[torydav@...]: Session disconnected. Session Type: SSL, Duration: 0d:00h:33m:12s, Bytes xmt: 0, Bytes rcv: 0, Reason: Port Suspended May 18 13:38:08   AnyConnect VPN authentication success msg: Peer IP=X.X.X.X Peer port=48571 AAA[6]: AAA authentication successful May 18 13:38:02   AnyConnect VPN connection event msg: Server IP=10.10.40.19 Server port=8443 Prot[TCP] Peer IP=X.X.X.X Peer port=48571 conn_id[4] SSL connection established. Cipher: ECDHE-RSA-AES256-GCM-SHA384 Thoughts? ... View more

Hey All, Did anyone experience problems with the Meraki API (Python Module, version 1.18.2) between 8 PM and 9 PM Eastern Time? It was brief, but it occurred during a scheduled change window where it did not work.  I didn't notice any change in my enviroment at all during this time, and I was on a call with no issues performing a migration, which relied on the API to execute changes and do pre/post checks. Timeline of events: 6:30 PM on 2/24/2022 - API was working, ran my prechecks script. 8:05 PM Tried running the script multiple times over 1/2 hour period of time. 8:35 PM Decided that since the API was returning the same timeout message, that I would proceed manually. 2022-02-24 20:05:10       meraki:     INFO > Meraki dashboard API session initialized with these parameters: {'version': '1.18.2', 'api_key': '************************************a96f', 'base_url': 'https://api.meraki.com/api/v1', 'single_request_timeout': 60, 'certificate_path': '', 'requests_proxy': '', 'wait_on_rate_limit': True, 'nginx_429_retry_wait_time': 60, 'action_batch_retry_wait_time': 60, 'retry_4xx_error': False, 'retry_4xx_error_wait_time': 60, 'maximum_retries': 2, 'simulate': False, 'be_geo_id': None, 'caller': None, 'use_iterator_for_get_pages': False} 2022-02-24 20:05:10       meraki:    DEBUG > {'tags': ['organizations', 'configure'], 'operation': 'getOrganizations', 'method': 'GET', 'url': '/organizations', 'params': None} 2022-02-24 20:05:10       meraki:     INFO > GET https://api.meraki.com/api/v1/organizations 2022-02-24 20:06:10       meraki:  WARNING > organizations, getOrganizations - HTTPSConnectionPool(host='api.meraki.com', port=443): Read timed out. (read timeout=60), retrying in 1 second At about 930 after the completing the work manually I tested again just for kicks, and started getting 200 OKs   2022-02-24 21:29:52       meraki:     INFO > Meraki dashboard API session initialized with these parameters: {'version': '1.18.2', 'api_key': '************************************a96f', 'base_url': 'https://api.meraki.com/api/v1', 'single_request_timeout': 60, 'certificate_path': '', 'requests_proxy': '', 'wait_on_rate_limit': True, 'nginx_429_retry_wait_time': 60, 'action_batch_retry_wait_time': 60, 'retry_4xx_error': False, 'retry_4xx_error_wait_time': 60, 'maximum_retries': 2, 'simulate': True, 'be_geo_id': None, 'caller': None, 'use_iterator_for_get_pages': False} 2022-02-24 21:29:52       meraki:    DEBUG > {'tags': ['organizations', 'configure'], 'operation': 'getOrganizations', 'method': 'GET', 'url': '/organizations', 'params': None} 2022-02-24 21:29:52       meraki:     INFO > GET https://api.meraki.com/api/v1/organizations 2022-02-24 21:29:53       meraki:     INFO > GET https://n61.meraki.com/api/v1/organizations 2022-02-24 21:29:53       meraki:     INFO > organizations, getOrganizations - 200 OK Was this a Meraki issue? Routing over the Internet? Something else? I didn't notice anything on my end that was wrong. I've used this code 5 nights a week for the last few weeks without issue and my code is frozen right now, meaning there are no changes happening until the project ends.  Thoughts? ... View more

Hey all, I'm looking for some assistance to prove, or disprove, some issues noticed with Spanning-Tree protocol, specifically with Meraki in a multi-vendor switching topology. It has been said, with some evidence to back it up, that Meraki switches do not support true 802.1w per-VLAN Rapid STP. And in any case where a Meraki switch connects to a non-Meraki, specifically Cisco Catalyst or another vendor such as Aruba, that the non-Meraki switch should be configured with a single-instance of MSTP. The idea here is that the Meraki implementation of 802.1w runs a single-instance of STP and therefore isn't compatible with a true per-vlan spanning-tree configuration in a mixed vendor environment where there are multiple VLANs with different switches set as the root for different VLANs. Looking at the data sheet for the MS390, under supported protocols, this is clearly spelled out as it says "Single instance of Rapid STP". However, looking at the MS 350 data sheet it simply states "802.1w, RSTP" with no mention of RPVST+ So the data sheet confirms this, this has been observed as an issue in the wild, but I'd like to hear from the community on this topic. 1. I am seeking your experience with the above. 2. I am seeking your recommendations to mitigate this. Thanks, Tor ... View more

Hi all, Here is a question about what seems like a rather unique situation, you can be the judge of the "uniqueness" of what I am about to share. For context to the question, please read the below: I built a script that will allow me to quickly and efficiently execute on the following: 0. Discover and backup all switchport configuration within a specified Meraki network, store to a file for later use. 1. Unbind a network from a configuration template. 2. Rebind that network to a new configuration template. 3. Optionally, if desired, bind (Automatically, or manually) those switches to their appropriate switch profiles. 4. Take a "post migration" snapshot of the switchport configuration on all switches within the network. 5. Analyze the before and after snapshots, which identifies the "local overrides" that were present (and lost) before the config template move. 6.  Optionally push those local overrides only back up to the switches. This is fairly specific to a customer that I work with that has around 60 sites they want move out of one single template and spread them across 10 or so different templates. We are executing on this during change windows, and doing about 2 or 3 sites per night. So far so good overall, it does work and fixes the issue within the Dashboard where unbinding switches or networks from templates tosses out the port configuration.  They also have MR's at these locations (Only MS and MR), which is where my question comes in if you made it this far. My question is this: what considerations do I need to know about when it comes to moving the MRs. The networks are all "combined" networks, so when we move the network, the switching and APs all move together. So far there has been no issue with APs. In testing, I've not seen any downtime at all regarding APs doing this workflow, and hardly any downtime on the switches either. I even tested in my lab running the API calls while connected to my MR33 that was being moved between templates. There isn't any issue because there isn't any configuration change, and if there is, its brief because the switchport configs are pushed back up and the profiles are mirrored to the original switch profiles. Nothing changes. Well there is a new situation that I can't test and that is with Meshing enabled. There is one site that has multiple buildings, they employ MR74s with external outdoor antennae's to form a mesh which provides network access wirelessly to other buildings. What concerns do you have here? I personally don't feel as though they will be affected or that the APs will even go offline, if they do we can have someone reboot the equipment but it's a long walk between buildings, and I want to make this as painless as possible and to make sure all my bases are covered. There is some chance the switches could go offline briefly, and it has happened, but it's a minor chance as in the majority of my cases thus far there is no downtime at all. Thoughts? ... View more