OpenVPN Client conflicts with Cisco AnyConnect Secure Mobility Client on Windows 7

[Lior Ben-Porat]

Cisco AnyConnect? Secure Mobility Client is installed by default on many CORP workstations, it functions as a firewall, Wifi manager, and VPN manager to the corporation's resources.

After installing OpenVPN client (used to connect to a different VPN), once I connect to that VPN with OpenVPN client (while connected to a public Wifi using the Cisco AnyConnect? application), the OpenVPN client will connect successfully, but immediately after that the Cisco AnyConnect? client will drop the connection with the Wifi.

The only workaround I have right now is to run OpenVPN client inside a VM machine while the host machine is connected to the Wifi using the Cisco AnyConnect? application.

This error was observed on:
Windows 7 x64
OpenVPN-Client 2.4
Cisco AnyConnect? Secure Mobility Client 3.1.04059

[Gert Döring]

Are you using OpenVPN with the (server-pushed) option "redirect-gateway block-local", which would block local communication in the LAN? This *might* be the reason why the AnyConnect? client gets unhappy (because it thinks it has lost the local connection).

Besides that, I can't see what we could do about it - Cisco's clients are notorious for blocking anything else (by design)...

[Lior Ben-Porat]

Replying to cron2:

Are you using OpenVPN with the (server-pushed) option "redirect-gateway block-local", which would block local communication in the LAN? This *might* be the reason why the AnyConnect? client gets unhappy (because it thinks it has lost the local connection).

Besides that, I can't see what we could do about it - Cisco's clients are notorious for blocking anything else (by design)...

---

We are not using that option on the OVPN server (we do use it on the CORP VPN, but this is unrelated to the topic).

Honestly it looks more like a conflict with the TUN/TAP devices of both the Cisco AnyConnect? and the OVPN client.
I googled it a little bit and found that OVPN has similar problem on Mac too:
​https://code.google.com/p/tunnelblick/issues/detail?id=18
The guys at 'tunnelblick' project mentioned that it's a problem with the TUN/TAP driver they use.
​http://tuntaposx.sourceforge.net/faq.xhtml
Here they provided a useful Perl script that switches between regular TUN installation and the Cisco's TUN.
I wish there was something like that for Windows too.

[nurban512]

Replying to lior:

We are not using that option on the OVPN server (we do use it on the CORP VPN, but this is unrelated to the topic).

Honestly it looks more like a conflict with the TUN/TAP devices of both the Cisco AnyConnect? and the OVPN client.
I googled it a little bit and found that OVPN has similar problem on Mac too:
​https://code.google.com/p/tunnelblick/issues/detail?id=18
The guys at 'tunnelblick' project mentioned that it's a problem with the TUN/TAP driver they use.
​http://tuntaposx.sourceforge.net/faq.xhtml
Here they provided a useful Perl script that switches between regular TUN installation and the Cisco's TUN.
I wish there was something like that for Windows too.

---

Were you ever able to find a solution to this issue? Currently running into the same problem myself.

[Lior Ben-Porat]

Replying to nurban512:

Replying to lior:

We are not using that option on the OVPN server (we do use it on the CORP VPN, but this is unrelated to the topic).

Honestly it looks more like a conflict with the TUN/TAP devices of both the Cisco AnyConnect? and the OVPN client.
I googled it a little bit and found that OVPN has similar problem on Mac too:
​https://code.google.com/p/tunnelblick/issues/detail?id=18
The guys at 'tunnelblick' project mentioned that it's a problem with the TUN/TAP driver they use.
​http://tuntaposx.sourceforge.net/faq.xhtml
Here they provided a useful Perl script that switches between regular TUN installation and the Cisco's TUN.
I wish there was something like that for Windows too.

---

Were you ever able to find a solution to this issue? Currently running into the same problem myself.

Unfortunately not, I decided to run the OVPN client inside a VM to avoid conflicts with the Cisco driver.
This is not the best solution since not *all* of the network activity goes through the VPN, but this good enough for what I needed back then...

[beseezy]

If you click on the properties of the TAP-Windows Adapter V9 adapter inside of Windows Network Connections, you should see an entry called "Cisco AnyConnect? Network Access Manager Filter Driver". If you un-check the checkbox next to the Cisco filter driver and hit OK, it will fix the binding issue following the OpenVPN client handshake and the OpenVPN client can co-exist on the same Windows instance as the Cisco AnyConnect? client.

Tested with the following:
Windows 7 SP1 x64 w/KB3212646 (January 2017 Cumulative Monthly Rollup)
OpenVPN client version 2.4.0
TAP-Windows 9.21.2
Cisco AnyConnect? Secure Mobility client version 4.3.02039

[dark-vex]

Replying to beseezy:

If you click on the properties of the TAP-Windows Adapter V9 adapter inside of Windows Network Connections, you should see an entry called "Cisco AnyConnect? Network Access Manager Filter Driver". If you un-check the checkbox next to the Cisco filter driver and hit OK, it will fix the binding issue following the OpenVPN client handshake and the OpenVPN client can co-exist on the same Windows instance as the Cisco AnyConnect? client.

Tested with the following:
Windows 7 SP1 x64 w/KB3212646 (January 2017 Cumulative Monthly Rollup)
OpenVPN client version 2.4.0
TAP-Windows 9.21.2
Cisco AnyConnect? Secure Mobility client version 4.3.02039

This it seems not valid for Windows 10 x64 build 10586.753 with Cisco AnyConnect? Secure Mobility client 4.3.04027 but also with the version 3.1.04059

[alfab]

The issue is still there with:

• Win 10 x64 1809
• OpenVPN 2.4.7 x86_64-w64-mingw32
• Cisco AnyConnect? Security Mobility Client 4.5.04029

The "Cisco AnyConnect? Network Access Manager Filter Driver" was already un-check in the "TAP-Windows Adapter V9"