Secure Connect - Client VPN Connect, reconnect, connect, reconnect

[JamesHammy]

All,

I'm hoping somebody can help here. We have recently implemented MX devices devices across all our offices and use Umbrella with the cloud-based Secure Connect feature connecting all sites together.

As part of this solution, we have the Secure Connect environment setup to allow client VPN access for home/remote working, which as I understand it, is like a cloud-managed, stripped down version of direct MX/ASA-based VPN access. We have two datacentres configured (London and Frankfurt) and it works very well.

One thing that has been annoying me though is if we connect to the VPN while on an Ethernet connection, it initially connects, then immediately disconnects and reconnects, at least two times. The connection then remains perfect up to maximum session time limit.

If we connect via a WiFi connection, it connects first time and then works perfectly for the entirety of the session.

I found some posts on these very forums with a similar issue but it was specific to on-premise MX/ASA device client VPN termination and not Cisco's cloud variant. There was talk of it potentially being an MTU issue, which was resolved by amending the MX/ASA config slightly. It's not possible to make these amendments on the cloud version though.

I've been working with Meraki support for over a month and we've tried several things, mainly along the lines of disabling IPv6 on the various adapters and within the client config file itself, all to no avail.

I'm told the three mechanisms that would cause a reconnection/renegotiation event are:

1. MTU value changes
2. IPv4 or IPv6 addresses change
3. Routing table changes

All of the above make sense to me logically but none of them are changing. Plus, why is it only happening when on an Ethernet connection and never on WiFi?

The testing has been completed and and off our corporate LAN, from home connections and while hot spotted, all with the same LAN-based issues.

The below is what we consistently see in the message history. To be clear, it never re-prompts for credentials other than at initial connection but it does make successfully connecting a mess of toaster notifications before access is consistent.

Any bright ideas? I've been submitting various DART bundles throughout.

21/07/2025
13:46:47 Ready to connect.
13:46:59 Contacting London, UK.
13:46:59 Posture Assessment: Required for access
13:46:59 Posture Assessment: Checking for updates...
13:46:59 Posture Assessment: Initiating...
13:47:05 Posture Assessment: Active
13:47:05 Posture Assessment: Initiating...
13:47:20 User credentials entered.
13:47:21 Establishing VPN session...
13:47:21 The Cisco Secure Client - Downloader is performing update checks...
13:47:21 Checking for profile updates...
13:47:21 Checking for customization updates...
13:47:21 Performing any required updates...
13:47:21 The Cisco Secure Client - Downloader update checks have been completed.
13:47:21 Establishing VPN - Initiating connection...
13:47:21 Establishing VPN session...
13:47:22 Establishing VPN - Examining system...
13:47:22 Establishing VPN - Activating VPN adapter...
13:47:23 Establishing VPN - Configuring system...
13:47:23 Establishing VPN...
13:47:23 Connected to London, UK.
13:47:27 Reconnecting to London, UK...
13:47:27 Establishing VPN - Examining system...
13:47:28 Establishing VPN - Activating VPN adapter...
13:47:28 Establishing VPN - Configuring system...
13:47:28 Establishing VPN...
13:47:28 Connected to London, UK.

[alemabrahao]

Take a look at this.

https://documentation.meraki.com/CiscoPlusSecureConnect/Cisco___Secure_Connect_Troubleshooting_Guide...

[JamesHammy]

Thanks for that but I'd actually read that and none of it was relevant for this issue. Even the link to the wider troubleshooting article only deals actual connection failures, which we don't suffer from.

[PhilipDAth]

> is like a cloud-managed, stripped down version of direct MX/ASA-based VPN access

I would say the opposite.  It's more like it's on steroids rather than stripped down.  It is very feature rich.

> it initially connects, then immediately disconnects and reconnects, at least two times.

The client requires both UDP and TCP to operate at its best.  I have seen many deployments where only TCP was allowed in the site firewall.  Check upstream firewalls for the Ethernet.

Is the Ethernet and WiFi networks behind the same site firewall, and using the same Internet connection?

To test for an MTU issue, on a Windows machine, run this command to find the name of the wired Ethernet adaptor:

netsh interface ipv4 show subinterface 

Then temporarily change the MTU with something like:

netsh interface ipv4 set subinterface “Ethernet” mtu=1200

If that stops the issue - you know you have an MTU issue.  If it keeps happening - look for a different issue.

[JamesHammy]

---

@PhilipDAth wrote:

> is like a cloud-managed, stripped down version of direct MX/ASA-based VPN access

I would say the opposite.  It's more like it's on steroids rather than stripped down.  It is very feature rich.

> it initially connects, then immediately disconnects and reconnects, at least two times.

The client requires both UDP and TCP to operate at its best.  I have seen many deployments where only TCP was allowed in the site firewall.  Check upstream firewalls for the Ethernet.

Is the Ethernet and WiFi networks behind the same site firewall, and using the same Internet connection?

To test for an MTU issue, on a Windows machine, run this command to find the name of the wired Ethernet adaptor:

netsh interface ipv4 show subinterface 

Then temporarily change the MTU with something like:

netsh interface ipv4 set subinterface “Ethernet” mtu=1200

If that stops the issue - you know you have an MTU issue.  If it keeps happening - look for a different issue.

---

Don't get me wrong, it's a great solution and it is very reliable but the configuration options within the web interface are very limited. A lot of the work involves hacking around with XML/config file settings, where a lot of this would be configurable within the VPN setup on the appliance for on-premise setups.

UDP traffic is a good call as I know the lack of DTLS connection can cause issues but we see no issues when connecting via WiFi behind the same environment, with the same policies applied. Having said that, I have just noticed from trawling the logs manually (Cisco/Meraki support didn't mention it) that a DTLS connection is brought up a little while after the TLS connection is made but after a few error events, is closes again, presumably falling back to TLS only. I'll pick this up separately and troubleshoot.

I've checked all the MTU settings and there is nothing untoward. We actually even have MTU set to 1280 in our config files so that setting will be applying regardless of the underlying adapter being used.

[JamesHammy · Accepted solution]

Ok, so I've found the problem while trawling the logs myself.

I suspect what's happening is that when on the LAN and opening a VPN connection, the LAN connection drops briefly while the session connects and then our saved WiFi SSID briefly connects because it's determined that the LAN is no longer available. We deploy corporate WiFi using certificate-based RADIUS authentication and GPO-based SSID population, meaning no interaction required from a user perspective at all.

The Cisco VPN connection which is negotiated based on the original interface status information then detects that the WiFi adapter is also now connected so goes through a session renegotiation and routing changes. Then when the WiFi detects the LAN/VPN is alive it disconnects and the same process happens again.

After that, we're in business and it stays connected.

Here are the crucial event log entries I found:

• Event ID 2070 – A new network interface has been detected
• Event ID 2073 – IP addresses from active interfaces – It lists the Ethernet adapter, the Cisco VPN adapter and then (crucially) the WiFi adapter
• Event ID 2012 – Reconfigure reason code 15 – New network interface
• Event ID 2056 - A routing table change notification has been received.  Starting automatic correction of the routing table.
• Event ID 2026 – Routing table – fixed – deleted route – WiFi adapter
• Event ID 2057 – Automatic correction of the routing table has been successful
• Event ID 2042 – The entire VPN connection is being reconfigured
• Event ID 3021 – Reconnecting to London, UK….
• Event ID 2040 – The entire VPN connection has been reconfigured

Glad to have finally got the bottom of the issue!

[PhilipDAth]

You just reminded me of a problem I once saw.

The machines were getting 100MB/s wired connections - but the WiFi was FASTER than the wired connection, so the machines kept swapping over to their WiFi connection.

[JamesHammy]

That would be more than a bit frustrating! I think the default Windows 11 mechanism is to only connect to WiFi if ethernet is not available. Kind of resolves that 'two default routes not allowed' problem.

[PhilipDAth]

> I think the default Windows 11 mechanism is to only connect to WiFi if ethernet is not available.

Negative.  It connects to both, and lays in a default route to both using an interface metric.  The lowest metric wins.  The fastest reported access speed gets the lowest metric.

Here is a snapshot of the routing table on my machine.  Do you see how I have two default routes?  The one with the metric of 30 (which is my WiFi) is currently winning.

[JamesHammy]

Ah so the plot thickens and that's useful to know. Is that two default route thing only while you're connected to the VPN or just generally while the machine is in use? 

I've just done a check and if I'm just using the machine without VPN, my WiFi adapter stays disconnected and the LAN adapter is, correctly, the only default route in the routing table:

For your default route battle, I suppose it's using the reported link speed value, which if you're WiFi 6E/7 could well exceed your (presumably) gigabit network card? OR it's just completely random!

If I connect to the VPN, I can see the WiFi adapter does indeed connect and adds in the additional default route within Windows, but the WiFi has a higher metric than LAN, with the VPN route much lower than all others, obviously.

Checking the AnyConnect VPN logs though, I can see it strips the WiFi route from its own table, after a bit of a recalculation and this is what causes my session reconnections.

Then it continues rock solid for the whole day.