Error after upgrade to AnyConnect 4.10.07061

[db_fab_bochum]

After an upgrade from AnyConnect 4.10.06079 to 4.10.07061 we have this error on our clients "The VPN connection was terminated due to loss of the network interface. A new connection is necessary, which requires re-authentication."

We use Gina to log in the VPN before we use the Windows login. The first VPN login sucess and after the login in windows, AnyConnect destroy the VPN-Tunnel with the Error-Message "The VPN connection was terminated due to loss of the network interface. A new connection is necessary, which requires re-authentication." 

Can Anybody help?

[AKAITWizard]

After updating to 4.10.07061 we are seeing this message more often especially when unlocking computers from being gone for several min. 

The VPN Connection was terminated to enforce a newly determined tunnel MTU and could not be automatically re-established. A new connection is necessary, which requires re-authentication. 

[TODavies]

Hi db_fab_bochum, 

We have also seen this behaviour after upgrading to 4.10.07061 - did you manage to resolve this issue? 

Thanks.

[db_fab_bochum]

Hello TODavies,

We have opened a ticket and are waiting for a solution. The new 7062 version has the same error. The error seems to be in the NAM component and in the proxy settings. The Cisco NAM team is working with us to troubleshoot.

[asr.security]

With 07061 same issue as TS and also the issue described here (both issues exist at the same time): https://community.cisco.com/t5/vpn/anyconnect-not-working-when-winhttpautoproxysvc-win10-is-not/m-p/4864727#M289887

I'll probably open a TAC case tomorrow since I can't find any workaround or solution.

I actually see the VPNVA is uninstalled and re-installed, no idea what triggers it.

[Boot Session: 2023/07/04 10:31:42.500]

>>> [Delete Device - ROOT\NET\0000]
>>> Section start 2023/07/04 10:34:55.459
cmd: "C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\VACon64.exe" -remove VPNVA "C:\WINDOWS\system32\drivers\vpnva64-6.sys"
dvi: Query-and-Remove succeeded
<<< Section end 2023/07/04 10:34:55.503
<<< [Exit status: SUCCESS]

[asr.security]

Doesn't happen using WiFi only wired ethernet. No issues with MR1.

---

App eventlog: Bron: Security-SPP:
De hardware is gewijzigd sinds de computer de vorige keer is opgestart.
Toepassings-id = 55c92734-d682-4d71-983e-d6ec3f16059f, SKU-id = 73111121-5638-40f6-bc11-f1d7b0d64300.

Cisco AC SMC eventlog:

11:34:18: error:
Function: CThread::invokeRun
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\common\utility\thread.cpp
Line: 463
Invoked Function: IRunnable::Run
Return Code: -32112629 (0xFE16000B)
Description: BROWSERPROXY_ERROR_NO_PROXY_FILE

Error: 11:34:13: (id: 2115)
Error Message to display to the user:
De VPN-verbinding is beëindigd vanwege een nieuwe netwerkinterface en is niet automatisch opnieuw opgebouwd. Er moet opnieuw verbinding worden gemaakt. Hierbij is herverificatie vereist.

Info: 11:34:13:
Function: CVirtualAdapter::EnableVA64
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\agentutilities\windowsvirtualadapter.cpp
Line: 2141
The VPN adapter driver has been disabled

Error: 11:34:12:
Function: CVirtualAdapter::IsVAEnabled
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\agentutilities\windowsvirtualadapter.cpp
Line: 3332
Unexpected VA status bits: 0x1812003

Warn: 11:34:12:
Function: CMainThread::WaitWhileProcessingEvents
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\agent\mainthread.cpp
Line: 12262
Invoked Function: CMainThread::internalProcessEvents
Return Code: -32702455 (0xFE0D0009)
Description: MAINTHREAD_ERROR_UNEXPECTED

Info: 11:34:11:
IP addresses from active interfaces:
Ethernet: 192.168.1.36, FE80:0:0:0:4379:5FA2:651E:9A3C

Info: 11:34:11:
A network interface has gone down.

Info: 11:34:10:
The Primary SSL connection to the secure gateway is down.

Info: 11:34:10:
The VPN client has sent the following close message to the gateway:
Unable to apply proxy settings that are received from the secure gateway.

Info: 11:34:10:
The Primary SSL connection to the secure gateway is being torn down.

Info: 11:34:10:
The Primary DTLS connection to the secure gateway is being torn down.

Info: 11:34:10:
Function: CTND::OnTunnelStateChange
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\agent\tnd.cpp
Line: 2061
tunnel state change (2->3)

Error: 11:34:10:
Termination reason code 127:
Unable to apply proxy settings that are received from the secure gateway.

Error: 11:34:10:
Function: GetProxySettingsFromBrowser
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\common\proxy\browserproxy.cpp
Line: 822
Invoked Function: CWinsecApiImpersonateUser
Return Code: -32833504 (0xFE0B0020)
Description: WINSECAPI_ERROR_GETUSERTOKEN_FAILED

Info: 11:34:09:
Host Configuration:
Public address: 192.168.1.36/24
Potential public addresses: 192.168.1.36
Private Address: 10.y
Private IPv6 Address: FE80:0:0:0:5DFF:8533:7673:926D/126 (auto-generated)
Remote Peers: x (TCP port 443, UDP port 443, source address 192.168.1.36)
Private Networks: none
Private IPv6 Networks: none
Public Networks: 25 ()
Public IPv6 Networks: none
Tunnel Mode: yes
Tunnel all DNS: yes

Info: 11:34:09:
Function: CTND::OnTunnelStateChange
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\agent\tnd.cpp
Line: 2061
tunnel state change (1->2)

Info: 11:34:09:
The entire VPN connection is being reconfigured.

Info: 11:34:09:
Routing table - fixed - deleted route
Destination Netmask Gateway IfAddr IfName IfIndex LL Metric
192.168.1.0 255.255.255.0 0.0.0.0 192.168.1.30 Wi-Fi 19 Y 256

Warn: 11:34:09:
Reconfigure reason code 15:
New network interface.

Info: 11:34:09:
IP addresses from active interfaces:
Ethernet: 192.168.1.36, FE8
Ethernet 2: 10.y, FE8
Wi-Fi: 192.168.1.30, FE8

Info: 11:33:03:
The Primary DTLS connection to the secure gateway has been established.

Info: 11:33:03:
The Primary DTLS connection to the secure gateway is being established.

Info: 11:33:03:
The VPN connection has been established and can now pass data.

Info: 11:33:03:
Function: CVirtualAdapter::EnableVA
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\agentutilities\windowsvirtualadapter.cpp
Line: 2560
Enabling the VPN adapter was successful (422 ms; drvEnable-125|ifWait-0|ifAddrWait-47)

Info: 11:33:02:
Function: CTcpTransport::internalReadSocket
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\common\ipc\udptcptransports_win.cpp
Line: 382
Invoked Function: ::WSARecv
Return Code: 10053 (0x00002745)
Description: De software op uw hostcomputer heeft een verbinding verbroken.

Error: 11:32:53:
Function: ConnectMgr::activateConnectEvent
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\api\connectmgr.cpp
Line: 1692
NULL object. Cannot establish a connection at this time.

Info: 11:32:53:
Function: ClientIfcBase::detach
File: c:\temp\build\thehoff\phoenix_mr70.316886046509\phoenix_mr7\vpn\api\clientifcbase.cpp
Line: 503
Shutting down vpnapi

[jeremystanley]

We are experiencing the same issue on 07061 and 07062. A wired connection does not retain the SBL-initiated VPN connection after logging in to Windows. The issue does not occur when the device is connected via wireless.
Have you opened a TAC yet? I was going to, but it appears I need to go to a different group on our end as I do not have entitlement to AnyConnect, but if somebody else has already opened a TAC I may not want to put myself through that internal struggle.

[asr.security]

Unfortunately I didn't get to it until late this afternoon. Your summing up is exactly what happens here too. Today I found out that using a wired connection also works (does not trigger the issue) if WiFi is disabled in Windows (Windows 10 in our case). So having both active/connected at start-up triggers the issue. WiFi only: no issue. Ethernet only+WiFi disabled: no issue.

Today I also tried 07062 (unfortunately I read your message after) and can confirm the issue is there too. This was what I expected since only a NAM issue was fixed compared to 07061 but of course I wanted to test the latest 4.10 release and rule this out.

I've opened a support case at our supplier and asked them to open a TAC case Monday or early next week. Hopefully this'll be resolved quickly. I'll update this thread with any significant news.

[Chia]

Any updates to the TAC case?

[asr.security]

Yes, very busy so I forgot to update here. The issue was fixed for us. It is a bug on the MR7 anyconnect image, see link below. The bug describes a different error than our users saw but there were syslog messages indicating the same issue. 

Workaround was adding the 'msie-proxy lockdown disable' atrribute to the affected group policies.

group-policy "group policy name" attributes

msie-proxy lockdown disable

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwf67833

[asr.security]

See my message below to Chia:

Yes, very busy so I forgot to update here. The issue was fixed for us. It is a bug on the MR7 anyconnect image, see link below. The bug describes a different error than our users saw but there were syslog messages indicating the same issue. 

Workaround was adding the 'msie-proxy lockdown disable' atrribute to the affected group policies.

group-policy "group policy name" attributes

msie-proxy lockdown disable

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwf67833

[jeremystanley]

Thanks for that. Though it is a bummer. We do not manage the concentrator, we are the only (relatively) small group using SBL and presumably the only group experiencing this issue since we can only reproduce it with SBL. None of the other groups use SBL, so I only presume they don't experience the issue.
So unfortunately, it sounds like we will have to deal with it unless Cisco ever remediates the issue from the client software; but from that bug article, it sounds like they won't be doing that any time soon.

[jeremystanley]

Looks like a new AnyConnect client has been released: 4.10.07073

Curious if anybody has tested that.

[stephan.ochs]

4.10.07073 still has https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwf67833

TAC gave me those two choices to solve it:

1. Stay on this version and reset the proxy configuration to its default settings
   msie-proxy server none
   msie-proxy method no-modify
   msie-proxy except-list none
   msie-proxy local-bypass disable
   msie-proxy pac-url none
   msie-proxy lockdown disable
2. Change to Version 5.
   The only version that is not affected by the defect from the secure client is 5.0.02075 otherwise is affected by the same issue.

My response:

Choice 1 is funny.
Of course, if the client does not get any proxy settings, this error cannot occur.
But the proxy settings are needed because the user can't work without it.
He would have a working VPN but can’t use it for his purpose.

If my car's tire is flat, I can remove it.
Then I no longer have a flat tire on my car and the issue is removed.
But I still can't drive the car.
You know what I mean?

Implementing choice 2 will take a long time and involve a great deal of effort.

So we get back to the main question: Is it foreseeable that this error will be corrected promptly in 4.10?

With CSCwf67833 I see that 54 support cases are already registered there.
Apparently there are also other customers who need the proxy settings and cannot simply switch them off.
Cisco should be aware that this is an urgent issue, act quickly and fix the problem.

To explain, why version 5 was suggested:
We urgently need an update because of this: Cisco AnyConnect Secure Mobility Client Software for Windows and Cisco Secure Client Software for Windows Privilege Escalation Vulnerability
This is fixed in 4.10.07061 and 5.0.02075.
Version 4 has the proxy bug, with version 5 we would have to invest much work to change our installation and cli scripts. 

[CiscoBoy]

Any updates to this? I've hit this bug on 4.10.07062, usually when the PC wakes up from sleep or when flipping between different wifi Networks.

We arent really to move onto Version 5/Secure Client yet