AnyConnect and McAfee / connection problem

Unanswered Question
Jun 9th, 2010

We actually install AnyConnect 2.4.1012 on many clients with lots of different configurations.

So we have many different issues but one of the main problems is, that AnyConnect and McAfee don't work together.

I have tested the following and could reenact the issue (also with 2.5).

If the AnyConnect client is installed there's a new interface in network connections with an ordinary name (like 'LAN connection 4').

First time I establish a VPN connection the interface gets renamed to 'Cisco AnyConnect VPN Client Connection'.

The connection established until AnyConnect get's an IP address from the ASA.

After that, vpnupdater starts and connection crashes.

At that moment McAfee Internet Security blocks further traffic and there's no chance to get it running until McAfee is reinstalled.

AnyConnect reports: The VPN client driver has encountered an error.

In my opinion the main problem is the renaming

of the interface.

Does anyone have a solution?

How can I prevent AnyConnect to change the interface name?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
a.mefford Tue, 06/22/2010 - 17:23

I was having the same issue and was just able to resolve it.  I uninstalled Mcafee, reinstalled the VPN and found it was working.  Obviously didnt want to keep things in this state so reinstalled Mcafee and both are working in harmony now.

No idea why this resolved it but happy to have both running finally.

stephan.ochs Tue, 06/22/2010 - 23:38

Hi Aaron

Unfortunately that's only a temporary solution.

If you will make an update of AnyConnect or un-/reinstall it, you will run into the same problem again.

Meanwhile I opened a case at TAC.

They will try to recreate the issues in their lab.

Harald Volz Wed, 06/23/2010 - 07:05

Same problem on a student notebook here. The IPsec client isn't working either with error 442 (not able to enable virtual adapter).

Do you have a Cisco Bug-ID?

stephan.ochs Wed, 06/23/2010 - 07:25

With IPSec client 442 is another problem with Vista.
There's no relation to the problem I mentioned.

First you should try this:

Reason 442: Failed to enable virtual adapter.
Attempt a reboot before trying again. Or go to network connection property pages and try to manually enable/disable the _Cisco Systems VPN Adapter_.  Also try to add the following line to vpnclient.ini: [main] VAEnableAlt=0.

Or you run into a specific problem of Vista with IPsec client < V5.0.3.560

Bug ID CSCsi26106

Symptom:
Receiving the following error "Reason 442: failed to enable virtual adapter" appears after Vista reports a duplicate IP address detected. Subsequent connection fail with same message but Vista doesn't report a duplicate IP address detected.

Workaround:
Open "Network and Sharing Center", then select "Manage Network Connections", Enable the Virtual Adapter "VA", then right click on the VA and select "diagnose" from the context menu and after that select, "Reset the network adapter "Local Area Connection X"

This resolves the issue until Vista reports a duplicate IP address again. Follow above step to resolve it again.

If that doesn't work, run the following from cmd, if you have UAC enabled ensure you run cmd as administrator.

reg add HKLM\System\CurrentControlSet\Services\Tcpip\Parameters /v ArpRetryCount /t REG_DWORD /d 0 /f

Vista introduces a new feature called "Receive Window Auto-Tuning".

What it does is to adjust the receive windows size continually based upon the changing network conditions.

Some people reported that auto-tuning cause network time-out problems with some applications and routers.

You can turn it off if you have experienced such problems.

Open up an elevated command prompt.
Enter the following command to disable auto-tuning

netsh interface tcp set global autotuninglevel=disabled

If you found that this doesn't fix your problem, you can turn it back on.

Open up an elevated command prompt.
Enter the following command to enable auto-tuning

netsh interface tcp set global autotuninglevel=normal

You can use this command to view the states of the TCP global paremeters.

netsh interface tcp show global

Harald Volz Wed, 06/23/2010 - 08:58

HI,

it was a XP-Client :-(

Most of the workarounds are known here and did not help. As it was a similar message regarding the VA maybe there is a relation? Have you seen a working IP-Sec-Client installation on an Mac-afee total security secured client?Currently we have two cisco clients on this notebook - none is able to enable the VA.

Regards

Harald

stephan.ochs Wed, 06/23/2010 - 22:48

Sure, there is a relation.

Unfortunately I only get informed of non-working installations.

So I don't know, if there are some that don't have the problem.

But I'm sure, there are...

In this case we have a lot of different systems (about 5.500) with different configuration/software/OS.

Sometimes you have two identical (?) installations. One works, the other doesn't.

I will keep you informed if I get more information from Cisco.

JESSICA Walsh Thu, 03/10/2011 - 08:19

Has anyone gotten any more updates on this? I just rolled the 2.5.2019 AC client and....all my XP users with McAfee are broken again. Are there any workarounds other than uninstalling McAfee. This is defeating the purpose of having auto-update client software.

andrewswanson Tue, 08/02/2011 - 08:01

recently came across similar issues when we upgraded to 2.5. all anyconnect clients running our McAfee enterprise AV upgraded ok but one client running BT Netprotect Plus (McAfee) failed. the anyconnect upgrade install went ok according to the anyconnect logs but when user tried to connect, the connection failed with VA errors and termination reason 13.

user resolved the issue by unchecking the "Use Access Protection" (see below) box and disabling the real-time scanner for the first connection attempt

hth

andy

Actions

This Discussion