Cisco VPN Client with Windows 7 and 3g datacards – WWAN support

When we upgraded to Windows 7 we found that our laptops would not connect to our VPN over 3G Datacards using the Cisco VPN Client.

This is due to the Cisco VPN Client software not supporting WWAN devices. Initially we were stunned to learn that the latest VPN Client wasn’ compatible with Windows 7! Subsequently they did release a version – we currently use version: But at the same time they announced that the VPN Client was end of life and that you should be using the AnyConnect client instead (that’s a whole different story see:

This meant that WWAN was never going to be supported in the Cisco VPN Client and we could not upgrade to AnyConnect VPN due to our reliance on IPSECv1 VPN Tunnels (see article above).

After much searching we managed to find a solution:

The problem is apparently to do with a limit on Citrix DNE instrumentation measuring! Quite how this makes the VPN Client work with WWAN cards is beyond me but it does!

Cisco ASA Anyconnect VPN per Device IPSECv2 tunnels using certificates – no failover

After we upgraded from Windows XP to Windows 7 we started getting problems with VPN users not being able to connect or weird things happening (random re-boots!).

We then discovered that Cisco did not support the VPN Client using IPSEC tunnels in Windows 7! We apparently had to use the new Anyconnect VPN tunnels and client software.

Our VPN setup is rather different to the standard VPN setup – most IT Managers setup their VPN on a per user basis (particularly with the newer SSL VPNs). That’s all well and good but what happens if they have been using a communal laptop on the road – we have several laptops that are held as a pool for use by anyone. Our staff logon to these laptops as a standard user called ‘User’ and then connect to the company with VPN using their network username and password. What happens if the laptop is lost or stolen? You have no means of revoking access to the VPN for that laptop. This scenario extends to home users as well who may have had their desktop computer stolen in a house robbery. And, most importantly, this scenario is also relevant for mobile devices which we are increasingly connecting to the VPN system.

Rather than live with this problem we prefer to create a separate tunnel group for each device with its own IPSEC shared secret password. When we are notified we can then delete that tunnel group and know without doubt that the device cannot be used to access our network. We are effectively creating a 2 factor authentication solution – something the user has (a company approved device) and something they know (their username and password). This system also has the added advantage of locking down VPN access to company approved devices only – vitally important to keep the nasties out of your company network.

For our VPN system we have 2 Cisco ASA units working in Active/Standby mode – if one unit fails or is brought down for maintenance the other unit automatically kicks in. On Cisco ASA units with the most up to date software the VPN tunnels do not disconnect when this failover occurs, all IPSEC VPN tunnels stay up. This is a fantastic feature for when we need to update software on the ASAs – we can simply failover and work on the inactive unit without having to inform VPN users, then failback and work on the other unit in the same way – no downtime whatsoever. In addition our 2 units are in different geographic locations with a good point to point link between them. This all provides a very robust service – something we really need with so many users these days on the road or home working in various parts of the world.

Therefore, we wanted to replicate this system with the Anyconnect VPN solution and not suffer the problems with the incompatible VPN client software in Windows 7. But we soon came across a major problem.

Anyconnect VPN relies on IKEv2 or SSL which both require the use of certificates from a certificate authority (CA) rather than shared secrets. This is fine as the Cisco ASA contains a CA server component which you can set up to serve certificates to the VPN tunnel groups. Devices then use a separate certificate according to their device tunnel group. We tested this setup on a lone Cisco ASA 5505 unit before moving the configuration to our production ASA 5510 units that are in Active/Standby mode.

And that’s when the problem became apparent – the Cisco ASA software does not support a Certificate Authority on ASA units setup as Active/Standby units. The only suggestion Cisco could make was to use a Windows based certificate authority but that meant extra servers being tied up as CA servers with failover setup between the 2 – not trivial!

In the end we had to give up. As it turned out, Cisco recognised this as a bug which is still active awaiting resolution see: (You will need a Cisco support username to view this).

In the meantime they did update their IPSECv1 based VPN client to support Windows 7 so we have happily been using that without any problems (current version: with our IPSECv1 per device VPN setup. However, Cisco have stated that the VPN Client is end of life and will no longer be updated. They recommend you use the Anyconnect client instead – useless advice as we can’t use that becuase of the CA server failover problem!

MSCHAP-v2 for Cisco ASA VPN connections using Radius on Windows Server 2008

When we upgraded our Windows domain servers to 2008 we found the default authentication methods had changed – PAP/SPAP was no longer enabled by default:


Consequently our VPN users could not connect as it turned out they were using PAP/SPAP by default.

We wanted to MS-CHAP-v2 for obvious security reasons so we needed to find out how to change our VPN tunnel groups on the Cisco ASA unit to use the stronger authentication method.

Within each tunnel group:

Configuration -> Remote Access VPN -> IPSEC (IKEv1) Connection Profiles (or whatever type of VPN you use)

Under Advanced -> Password Management

Enable the password management option:


You can also set the password expiration notification here if you use that on your network – this is the Active Directory password expiration i.e. you are prompted every so often to change your network password. If you have users that are permanently on VPN connections then this can be set to warn them well before their expiration so that your IT team does not get calls regarding passwords not working ūüôā

The Password Management turns on MS-CHAP-v2 for your VPN connections so you can keep your Radius servers using MS-CHAP-v2 only and ensure you are using the strongest authentication on your VPN connections.

NOTE: Once MS-CHAP-v2 is working you will notice that a extra box appears for domain in your VPN Client logon dialog box Рyou should enter your Windows Active Directory root domain in this box.


Command line setup of Cisco VPN on ASA 5500

These VPN setup notes are for an ASA 5500 unit but relate, in general, to all Cisco firewall units:

Notes created 4 December 2008


Company name: IBM

VPN IP Range:

VPN IP Subnet Mask:

Internal network IP range:

Internal network IP range subnet mask:

Primary DNS server:

Secondary DNS server:

Radius authentication server IP:

Remote access vpn configuration :

You can use the ASDM interface (GUI for Cisco ASA units) to enter details or

For command line input:

Use telnet or Putty as telnet.

At password prompt type ‘cisco’.

Then type ‘enable’ and enter enable password (same one you logon to asdm with).

1. Initial setup of ipsec – just need to do once:

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto dynamic-map dyn1 10 set transform-set ESP-3DES-SHA

crypto dynamic-map dyn1 10 set reverse-route

crypto map WAN_map 65535 ipsec-isakmp dynamic dyn1

crypto map WAN_map interface WAN

crypto isakmp enable WAN

crypto isakmp enable management

crypto isakmp policy 10 authentication pre-share encryption 3des hash sha group 2 lifetime 86400

crypto isakmp nat-traversal  20

crypto isakmp ipsec-over-tcp port 10000

2. Setup authentication server – use Radius for Windows based domain, do not use NT Domain (this is legacy NT only):

Radius uses active directory for group policy settings e.g. allow or deny remote access on users dialin tab.

Note: Items in quotes ” are supplied by you – do not include quotes:

aaa-server IBM_Auth_servers protocol radius

aaa-server¬†IBM_Auth_servers (LAN) host¬†¬† key¬†“radius server secret key”¬† radius-common-pw “radius server password”

IBM_Auth_Servers¬†is the ASA’s connection to the Windows Radius authentication server and¬†can be setup in ASDM under Configuration, Properties, AAA Setup, AAA Server Objects. Add a server group called IBM_Auth_servers and then add the IP number of the Radius server.¬†

Note: you can add more than one Radius server IP, so you could add a remote radius server for failover if you have two ASA units failing over.

Radius servers are setup using Internet Authentication Service in Admin Tools – add the Cisco units internal IP (gateway IP) and shared secret and password.

 3. Setup group policy:

configure terminal

group-policy IBM_VPN internal

group-policy IBM_VPN attributes dns-server value vpn-tunnel-protocol IPSec



Note: Secondary DNS server should be on remote failover site if you have 2 ASA units failing over.

4. Setup IP Pool:

configure terminal

ip local pool IBM_VPN_POOL mask


Note: the VPN IP range should be a separate range from your normal network and not used by any other service.

5. Setup Tunnel group – for each machine or site:

Items in quotes ” are supplied by you – do not include quotes:

configure terminal

tunnel-group IBM_VPN_London type ipsec-ra

tunnel-group IBM_VPN_London general-attributes address-pool IBM_VPN_POOL authentication-server-group IBM_Auth_Servers default-group-policy IBM_VPN


tunnel-group¬†IBM_VPN_London ipsec-attributes¬†pre-shared-key “your secret key”



Note: IBM_VPN_London is an individual tunnel group for a set of machines.¬†e.g. you may use¬†“IBM_VPN_Germany” for another remote office¬†as a site name or “IBM_DESKTOP_77_WindowsXP” for an individual machine

“Your secret key” is the key you type into the VPN client software¬†– use to obtain 64 character key (do a separate one for each tunnel group i.e. each site¬†and/or machine, DO NOT USE THE SAME KEY for all tunnel groups. In this way you can revoke a key and assign a new one without having to redo all VPN connections.

6. For the vpn client to be able to access internal network and go to internet via vpn tunnel (no split tunneling):

6a. Internet access:

See: Allowing Cisco VPN to access Internet via tunnel

configure terminal

same-security-traffic permit intra-interface

nat (WAN) 10

6b. Internal access:

access-list Inside_nat0_outbound line 4 extended permit ip


7. Allow local LAN access

To enable clients with ‘Allow Local access’ option set on VPN Client to be able to access their local resources do the following (this is so a user can access local resources like NAT drives or network printers whilst connected to the VPN – otherwise all traffic goes via the VPN link):

See: Cisco Local LAN Access Notes

access-list LOCAL_LAN_Access remark Clients with local lan access option set – internet and dns access is still via tunnel

access-list LOCAL_LAN_Access standard permit host group-policy IBM_VPN attributes split-tunnel-policy excludespecified split-tunnel-network-list value LOCAL_LAN_Access

8. Setup on client machine:

Use VPN client software available from: Cisco VPN Client Software Download Site

Connect to external IP of ASA unit (WAN address) using IBM_VPN as VPN name and enter secret key for the tunneling group setup for this machine or site.

9. To list connections:

In ASDM goto Monitoring, VPN, VPN Statistics, Sessions Рthis will list all current sessions with relevant username, IP and encryption details.