AnyConnect VPN Connecting and reconnecting over and over to the Mearki MX appliances

[rhamersley]

We are encountering users connecting to our Meraki MX appliances through the Cisco Secure Client Anyconnect.   When they connect to the VPN it states it connects then disconnects and then reconnects about 3 to 5 times every time someone logs into the VPN.   After about 5 minutes of this it actually stabilizes and stays static.    Meraki support was not able to provide any feed back why.   Would like to ask the "Community" here to see if anyone else has experienced this and what actions they might have taken.

[CptnCrnch]

Are your users using the Windows Store version of Secure Client?

[rhamersley]

No.  We are using the downloaded AnyConnect Client version from the Meraki Dashboard.   Below is a screen shot of the downloadable AnyConnect Secure Client version.

[rhamersley]

You can see the logs from the Secure Client of the multiple times it connects and disconnects and reconnects.

I know its not my home internet since I have fiber directly into my home and up and down stream speeds are 925MB UP and 910MB down.

10:04:47 AM Reconnecting to Denver Corporate VPN...
10:04:49 AM Establishing VPN - Examining system...
10:05:00 AM Establishing VPN - Activating VPN adapter...
10:05:01 AM Establishing VPN - Configuring system...
10:05:01 AM Establishing VPN...
10:05:01 AM Connected to Denver Corporate VPN.
10:05:01 AM Reconnecting to Denver Corporate VPN...
10:05:02 AM Establishing VPN - Examining system...
10:05:02 AM Establishing VPN - Activating VPN adapter...
10:05:02 AM Establishing VPN - Configuring system...
10:05:02 AM Establishing VPN...
10:05:03 AM Connected to Denver Corporate VPN.
10:05:06 AM Reconnecting to Denver Corporate VPN...
10:05:08 AM Reconnecting, waiting for network connectivity...
10:05:10 AM Reconnecting to Denver Corporate VPN...
10:05:12 AM Establishing VPN - Examining system...
10:05:12 AM Establishing VPN - Activating VPN adapter...
10:05:12 AM Establishing VPN - Configuring system...
10:05:13 AM Establishing VPN...
10:05:13 AM Connected to Denver Corporate VPN.
10:06:16 AM Reconnecting to Denver Corporate VPN...
10:06:17 AM Establishing VPN - Examining system...
10:06:25 AM Establishing VPN - Activating VPN adapter...
10:06:26 AM Establishing VPN - Configuring system...
10:06:26 AM Establishing VPN...
10:06:26 AM Connected to Denver Corporate VPN.
10:06:26 AM Reconnecting to Denver Corporate VPN...
10:06:27 AM Establishing VPN - Examining system...
10:06:27 AM Establishing VPN - Activating VPN adapter...
10:06:27 AM Establishing VPN - Configuring system...
10:06:27 AM Establishing VPN...
10:06:27 AM Connected to Denver Corporate VPN.
10:06:59 AM Reconnecting to Denver Corporate VPN...
10:07:01 AM Reconnecting, waiting for network connectivity...
10:07:14 AM Reconnecting to Denver Corporate VPN...
10:07:17 AM Reconnecting to Denver Corporate VPN...
10:07:18 AM Establishing VPN - Examining system...
10:07:25 AM Establishing VPN - Activating VPN adapter...
10:07:27 AM Establishing VPN - Configuring system...
10:07:27 AM Establishing VPN...
10:07:27 AM Connected to Denver Corporate VPN.
10:07:27 AM Reconnecting to Denver Corporate VPN...
10:07:28 AM Establishing VPN - Examining system...
10:07:28 AM Establishing VPN - Activating VPN adapter...
10:07:28 AM Establishing VPN - Configuring system...
10:07:29 AM Establishing VPN...
10:07:29 AM Connected to Denver Corporate VPN.
10:07:58 AM Reconnecting to Denver Corporate VPN...
10:08:00 AM Reconnecting, waiting for network connectivity...
10:08:09 AM Reconnecting to Denver Corporate VPN...
10:08:11 AM Reconnecting to Denver Corporate VPN...
10:08:11 AM Establishing VPN - Examining system...
10:08:11 AM Establishing VPN - Activating VPN adapter...
10:08:12 AM Establishing VPN - Configuring system...
10:08:12 AM Establishing VPN...
10:08:12 AM Connected to Denver Corporate VPN.
10:09:15 AM Reconnecting to Denver Corporate VPN...
10:09:16 AM Establishing VPN - Examining system...
10:09:24 AM Establishing VPN - Activating VPN adapter...
10:09:26 AM Establishing VPN - Configuring system...
10:09:26 AM Establishing VPN...
10:09:26 AM Connected to Denver Corporate VPN.
10:09:26 AM Reconnecting to Denver Corporate VPN...
10:09:27 AM Establishing VPN - Examining system...
10:09:27 AM Establishing VPN - Activating VPN adapter...
10:09:27 AM Establishing VPN - Configuring system...
10:09:27 AM Establishing VPN...
10:09:27 AM Connected to Denver Corporate VPN.

[alemabrahao]

Does the problem happen to all users? If not, what is different about users who experience the problem?

System version for example.

[rhamersley]

Happens to a majority of our users.   They just deal with it currently.   All users are running Microsoft Windows 10 Pro and all our Meraki MX firmware levels are the same (MX 18.107.2).   Secure Client version is 5.0.03076.

[PhilipDAth]

Does your MX connect using PPPoE by chance, or using a method with an MTU of less than 1500 bytes?

This kind of behaviour often happens when a "black hole" is detected, and the client disconnects and reconnects using a smaller MTU, trying to guess what the end to end MTU actually is.

If you forcibly lower the MTU on a client does the issue go away?  Try something extreme like a 1000 bytes to begin with to prove if it is or is not related to the issue.

[rhamersley]

Quick question where would the MTU config be located at.  Would that be on the XML profile of the Cisco Secure Client side??

[PhilipDAth]

Another thought - is the public IP directly on the MX WAN interface, or does it sit behind something else doing NAT?

[rhamersley]

The Public IP address is on the MX WAN interface and does not sit behind anything.

[rhamersley]

Our Users authenticate using AD credentials that pop up while trying to authenticate using Cisco Secure Client/Anyconnect.

[Travist]

I'm also experiencing this issue in our org, any known fixes yet? Users just have to work through it. 
Our public IP is directly on the MX interface, nothing else doing NAT. Happens both on our MX95 and vMX in Azure. 
MX95 version 18.107.7
VMX-M version 18.107.10

AnyConnect version 5.1.2.42

[Badr-eddine]

Hello, by any chance, has anyone identified the root cause of the recurring instability at the beginning of the VPN session?

Thanks.

[Craig_S]

Has anyone found a fix for this. We just started experiencing this issue on Monday. We have the same issue and the same hardware and software. No help from Cisco Anyconnect support.

[Travist]

We noticed a big improvement after upgrading our Mx from 18.107.11 to 18.211.2. 

[Craig_S]

Unfortunately, we have an MX 84, and it will only run version 18.1XX or lower. Thanks for the reply, though.

[Badr-eddine]

I found the solution: it's a common issue with AnyConnect DTLS negotiation. You need to open UDP port 443 alongside TCP port 443 on the MX/vMX firewall.

[harmankardon]

Any idea why this has just started happening recently, was it a change on the Meraki side or the AnyConnect side?

[Guillaume6hat]

Hello.

Thank you for the information.

When you say we need to open UDP port 443 on the MX, it's in the case the MX is behind a Firewall right ? It MX is directly connected with a public IP, it's not necessary.

We have the same issue, but MX is directly connected to the Internet.