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

rhamersley
Getting noticed

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

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.

 

 

16 Replies 16
CptnCrnch
Kind of a big deal
Kind of a big deal

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

rhamersley
Getting noticed

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_0-1706714118629.png

 

rhamersley
Getting noticed

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
Kind of a big deal
Kind of a big deal

Does the problem happen to all users? If not, what is different about users who experience the problem?
 
System version for example.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
rhamersley
Getting noticed

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
Kind of a big deal
Kind of a big deal

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
Getting noticed

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

PhilipDAth
Kind of a big deal
Kind of a big deal

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

rhamersley
Getting noticed

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

rhamersley
Getting noticed

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

Travist
Comes here often

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
Getting noticed

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

 

Thanks.

Craig_S
Comes here often

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
Comes here often

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

Craig_S
Comes here often

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

Badr-eddine
Getting noticed

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.

Get notified when there are additional replies to this discussion.