I have a couple users in my environment who have x64 Windows 7 computers and would like to use the VPN. The Cisco ISPEC VPN client doesn't support x64 and I haven't been able to convince management to shell out the cash for the ANYconnect SSL licenses so I'm stuck with L2TP.
My problem is that when my Windows 7 client connects it uses the "DefaultL2Lgroup" group policy.
ERROR: "713903 Group = DefaultL2LGroup, IP = x.x.x.x, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting"
There's no option in the Windows VPN configuration to select a group and I've been up and down the Cisco configs and nothing seems to change this behavior.
I suppose I could just let it use the "DefaultL2Lgroup" but dangit I want it to work the way I want it too, not the other way around.
That said I'd like it to use the group of my choice but I'd settle for it to default to the "DefaultRAGroup".
Well, after spending a considerable amount of time on this problem, I have finally solved the puzzle!
First things first, however. Did you know that Cisco has created the "AnyConnect Essentials" license for ASA code 8.2? This license gives you the ability to run AnyConnect (which is supported on Win 7 and even 64-bit versions of Windows) without purchasing any expensive WebVPN licenses. This licesnse is one flat price (very reasonable, too) and allows unlimited connections to the box (limited only by horsepower). The ASA can also deliver the software to the client using Java or ActiveX, so there is no need to stage the software on the client before-hand. Also, I was not able to get an L2TP connection to do split tunneling, whereas AnyConnect can. See the below link for details about the license.
Now, on with the show. To get L2TP working, I decided to take a step backward and start from the beginning. I followed the document below to setup a working L2TP VPN from a computer running XP.
However, in the document where it shows the screenshots of the Windows computer, you actually want to check the CHAPv2 box and uncheck the CHAPv1 box. While CAHPv1 works, CHAPv2 is more secure than version 1. If you running an external radius server, it may even require version 2. Also, take note that the computer is set to "Require encryption". Changing this setting changes the proposals that the computer offers during phase 2 negotiation.
After I got this working, I took the next step and tried to connect a Vista computer. This failed. I then captured the output of a "debug crypto isakmp 255" on both connections and compared them. I saw that Vista offers different proposals than XP did. So, I changed my ASA config to allow one of the new proposals. Then, the Vista computer worked.
Finally, I connected the Windows 7 computer. Magically, it worked! I captured the debug output and saw that Windows 7 offers the same proposals that Vista offered. Thus, it worked after I fixed Vista.
Then, I wanted to know what the difference was between "Require encryption" and "Maximum strength encryption" was. So, I set all three of my test computers to "max strength" and captured the debug output. I have assembled my findings and attached them to this post.
So, my ASA configuration ended up looking like this:
crypto ipsec transform-set 3desmd5 esp-3des esp-md5-hmac
crypto ipsec transform-set 3desmd5 mode transport
crypto ipsec transform-set aes128sha esp-aes esp-sha-hmac
crypto ipsec transform-set aes128sha mode transport
crypto ipsec transform-set aes256sha esp-aes-256 esp-sha-hmac
crypto ipsec transform-set aes256sha mode transport
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map out_dyn_map 10 set transform-set 3desmd5 aes128sha aes256sha
crypto map outside_map 65000 ipsec-isakmp dynamic out_dyn_map
crypto map outside_map interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
crypto isakmp policy 65535
group-policy DefaultRAGroup internal
group-policy DefaultRAGroup attributes
dns-server value 192.168.1.4
vpn-tunnel-protocol IPSec l2tp-ipsec
tunnel-group DefaultRAGroup general-attributes
authentication-server-group LOCAL ! this is a default command and is normally hidden
tunnel-group DefaultRAGroup ipsec-attributes
tunnel-group DefaultRAGroup ppp-attributes
no authentication chap
For phase 1, when a Windows XP computer connects, the ASA assigns isakmp policy 10 to the connection, while the ASA assigns isakmp policy 65535 to the Vista and Win7 connections. Note that I created policy 10 per the Cisco instructions above. I actually do not need policy 10 because XP also offers 3des-sha1 as a phase 1 proposal. (See attached PDF for proposals.)
For phase 2, when Windows runs in "Require encryption" mode, the "3desmd5" transform set is used for XP, while the "aes128sha" transform is used for Vista and Win 7. However, when you crank up the Windows encryption to use "Maximum strength encryption", then the "3desmd5" transform set is still used for XP, while the "aes256sha" transform is used for Vista and Windows 7.
When creating your connection in Windows 7, be sure to find the following options and change them:
-set "include windows logon domain" to unchecked unless you're using a back-end radius server which needs it
-set "type of vpn" to "L2TP". Then, click "advanced", choose "preshared key", and enter your key.
-set "CHAP" to unchecked, but leave "CHAPv2" still checked.
Three final notes:
First, if you're using local username authentication on the ASA, you need to add the "mschap" keyword to the end of the username. This causes the ASA to store the password differently in the memory.
Second, Microsoft has alleged that the ASA is not compatible with simultaneous L2TP connections from newer verions of Windows (both Vista and Windows 7). The below document outlines why. I, however, did not run into this problem. I am running ASA 8.2(2) and was able to connecte multiple computers without issue. Perhaps this was only a problem in older ASA code.
Third, this post does not take into account any of the NAT configurations of the ASA. You will need to perform the usual NAT exemptions to make your tunnel work after you're done configuring all of this. Also, the L2TP tunnel will be a full tunnel, not a split tunnel. Since you will be hairpinning all client traffic to the internet, you will need to provide NAT for that, as well. Oh, and the same-security-traffic command will be needed for hairpinning, too.
I hope this information helps many people, as I know that I have not seen any good information on the internet about this configuration.