In this blog, I will describe some common mistakes with regards to L2TP-ipsec or IPSEC & Webvpn & the cisco ASA.
L2TP-ipsec
It's support by window7 and macosx and most phone devices as a native client. It's not overly hard to configured , but can be tiresome to trouble-shoot if you don't know what to look at. A lot of errors or misconfiguration could lead to a nightmarish of problems.
1st
Make sure you have the group-policy presented with <l2tp-ipsec> as the vpn-tunnel-protocol
group-policy MYRA-policy1 internal
group-policy MYRA-policy1 attributes
dns-server value 8.8.8.8 8.8.4.4
vpn-tunnel-protocol l2tp-ipsec <<-------here
split-tunnel-policy tunnelall
default-domain value example.com
user-authentication enable
With out identification of the vpn protocol, your ASA will not know how to handle the request and will not try to establish l2tp. This is a commonly missed action, & by most ASA firewall engineers who trys to setup l2tp-ipsec Remote-Access.
2nd
Next, ensure you have a aaa authentication server or LOCAL. If using a local user, create the password with ms-chap
ASW1(config)# username example password i'msecured mschap <<----here we add the word ms-chap
ASW1(config)#
3rd
Next, ensure the service-type is set for remote-access under the user attributes
service-type ?
username mode commands/options:
admin User is allowed access to the configuration prompt.
nas-prompt User is allowed access to the exec prompt.
remote-access User is allowed network access.
4th
Make sure to craft a vpn pool range and ensure that it's big enough to cover your suspected range;
show run | incl Pool02
ip local pool VPNPool02 192.168.150.33-192.168.150.64 mask 255.255.255.0
and
show ip local pool VPNpool02
Begin End Mask Free Held In use
192.168.150.33 192.168.150.64 0.0.0.0 32 0 0
Available Addresses:
192.168.150.33
192.168.150.34
192.168.150.35
192.168.150.36
192.168.150.37
192.168.150.38
192.168.150.39
192.168.150.40
192.168.150.41
192.168.150.42
192.168.150.43
( output trunacate )
5th
NOTE: I recently found out that if you don't specify a netmask for the pool, that weird things can happen with regards to your clients actually accessing the network.
6th
Ensure the VPNpool network is distributed into your IGP ( static , static redistribution,etc.....)
7th
Ensure that we use
chap vrs
pap for the tunnel-group authentication ( PAP is not as secured )
8th
You probably want to "NONAT" the vpn pool range. Remember, from a zone concept, the POOL are outside from the lower security-level by the firewall perspective
9th
In your crypto and dynamic map you need to define a trans-form set wth mode transport;
crypto ipsec ikev1 transform-set tset esp-aes-256 esp-sha-hmac
crypto ipsec ikev1 transform-set tset1 esp-aes-256 esp-md5-hmac
crypto ipsec ikev1 transform-set tset3 esp-aes esp-md5-hmac
crypto ipsec ikev1 transform-set tset2 esp-aes esp-sha-hmac
crypto ipsec ikev1 transform-set tset4 esp-3des esp-sha-hmac
crypto ipsec ikev1 transform-set tset5 esp-3des esp-md5-hmac
crypto ipsec ikev1 transform-set l2tp1 esp-aes esp-sha-hmac
crypto ipsec ikev1 transform-set l2tp1 mode transport <<< here
crypto ipsec ikev1 transform-set l2tp2 esp-aes esp-md5-hmac
crypto ipsec ikev1 transform-set l2tp2 mode transport <<< here
crypto ipsec security-association pmtu-aging infinite
crypto dynamic-map myDYN-MAP 5 set ikev1 transform-set l2tp1 l2tp2
crypto dynamic-map myDYN-MAP 10 set ikev1 transform-set tset tset1 tset2 tset3 tset4 tset5
crypto map ourvpn 65535 ipsec-isakmp dynamic myDYN-MAP
crypto map ourvpn interface outside
In the above I have 2 trans-form sets l2tp1 and l2tp2 and both are defined within the dynamic map as seq#5, the l2tp client must accept and offer a proposal of AES128 with md5 or sha ( 3des is secured but slowly being eliminated as a standard encryption cipher )
10th
NOTE: I worked with cisco TAC back in 2009 on a problem, and they always suggest to set the dynamic map as the highest seq# in your parent crypto map. I think this is now BCP, so seq# 65535 is the highest number in our 2 byte 1word sequence numbering.
Finally
Craft you tunnel-group and assigned the appropriate group-policy ( here's a completed tunnel-group);
show running-config tunnel-group RA_l2tp
tunnel-group RA_l2tp type remote-access
tunnel-group RA_l2tp general-attributes
address-pool VPNPool02
default-group-policy MYRA-policy1
tunnel-group RA_l2tp ipsec-attributes
ikev1 pre-shared-key *****
tunnel-group RA_l2tp ppp-attributes
authentication ms-chap-v2
Moving on to IPSEC;
You have some of the same issues as l2tp-ipsec;
- group-policy protocol type
- vpnpool and assignment
- local or radius server authentication
- but we don't have to worry about transform-set with transport or pap/chap authentication
With both of these remote-access methods, you can use any of the following to diagnostic the clients;
- ASA packet capture
- show vpn-sessiondb ra-ikev1-ipsec
- show ip local pool <poolname>
- packet-tracer
And lastly WEBVPN;
As complex as it seems, it too has issues that you might want to address.
1st
Ensure you enable it and on the right interface
ASFW1# show run webvpn
webvpn
enable outside <------HERE
anyconnect image disk0:/anyconnect-win-2.5.2014-k9.pkg 1
anyconnect image disk0:/anyconnect-macosx-i386-2.5.2014-k9.pkg 2
anyconnect image disk0:/anyconnect-linux-2.5.2014-k9.pkg 3
anyconnect enable <<--HERE
tunnel-group-list enable
2nd
For Anyconnect to work, you need to enable anyconnect duh! ( see above show output )
3rd
It's highly advise able to install some client packages and order them with a numbering. Cisco BCPs states to place the most common OS client 1st in the ordering;
ASFW1# show webvpn anyconnect
1. disk0:/anyconnect-win-2.5.2014-k9.pkg 1 dyn-regex=/Windows NT/
CISCO STC win2k+
2,5,2014
Mon 12/20/2010 9:07:59.98
2. disk0:/anyconnect-macosx-i386-2.5.2014-k9.pkg 2 dyn-regex=/Intel Mac OS X/
CISCO STC Darwin_i386
2.5.2014
Mon Dec 20 08:50:51 MST 2010
3. disk0:/anyconnect-linux-2.5.2014-k9.pkg 3 dyn-regex=/Linux i[1-9]86/
CISCO STC Linux
2.5.2014
Mon Dec 20 08:48:33 MST 2010
3 AnyConnect Client(s) installed
So I installed 3 client packages from windows,macosx,linux ( 1 2 3 )
4th
As with the group-policy, you need to specify ssl-client and/os ssl-clientless depending on your needs
group-policy DefaultRAGroup attributes
dns-server value 8.8.8.8 8.8.4.4
vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless <---- ( for client and clientless )
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split-tun-ipsec
default-domain value example.com
user-authentication enable
5th
NOTE: if you don't specify a group-policy under your tunnel-group, the ASA uses the default group policy.
6th
With ssl webvpn, you can do any of the following for diagnostics
- ASA packet capture
- show vpn-sessiondb anyconnect
- show ip local pool <poolname>
- packet-tracer
And finally, when clients are connecting and they have problems. The show vpn-sessiondb command is useful to see if the ASA has identified the group and user.
Term mon and logging will also show you errors;
e.g ( a bad password )
%ASA-6-713172: Group = RA_l2tp, IP = 70.193.201.232, Automatic NAT Detection Status: Remote end IS behind a NAT device This end IS behind a NAT device
%ASA-6-113009: AAA retrieved default group policy (policy3) for user = RA_l2tp
%ASA-5-713119: Group = RA_l2tp, IP = 70.193.201.232, PHASE 1 COMPLETED
%ASA-5-713076: Group = RA_l2tp, IP = 70.193.201.232, Overriding Initiator's IPSec rekeying duration from 0 to 4608000 Kbs
%ASA-6-602303: IPSEC: An outbound remote access SA (SPI= 0x0C388EE0) between 128.22.1.28 and 70.193.201.232 (user= RA_l2tp) has been created.
%ASA-5-713049: Group = RA_l2tp, IP = 70.193.201.232, Security negotiation complete for User () Responder, Inbound SPI = 0x13e0b09c, Outbound SPI = 0x0c388ee0
%ASA-6-602303: IPSEC: An inbound remote access SA (SPI= 0x13E0B09C) between 128.22.1.28 and 70.193.201.232 (user= RA_l2tp) has been created.
%ASA-5-713120: Group = RA_l2tp, IP = 70.193.201.232, PHASE 2 COMPLETED (msgid=8edca3e4)
%ASA-6-110003: Routing failed to locate next hop for 105 from NP Identity Ifc:10.1.1.1/0 to LANFAIL:10.1.1.2/0
%ASA-6-302015: Built inbound UDP connection 593 for outside:70.193.201.232/3147 (70.193.201.232/3147) to identity:128.22.1.28/1701 (128.22.1.28/1701)
%ASA-6-113015: AAA user authentication Rejected : reason = Invalid password : local database : user = kfelix1 <<< HERE
e.g ( bad group I misconfigured my client group name with ThisIsAwrongGroup and the ASA is smart enough to tell you so :) )
%ASA-4-713255: IP = 70.193.201.232, Received ISAKMP Aggressive Mode message 1 with unknown tunnel group name 'ThisIsAwrongGroup'.
e.g ( bad transform set " this was l2tp with no mode of transport " so we have a phase2 mismatch error )
%ASA-6-713172: Group = RA_l2tp, IP = 70.193.201.232, Automatic NAT Detection Status: Remote end IS behind a NAT device This end IS behind a NAT device
%ASA-6-113009: AAA retrieved default group policy (policy3) for user = RA_l2tp
%ASA-5-713119: Group = RA_l2tp, IP = 70.193.201.232, PHASE 1 COMPLETED
%ASA-5-713257: Phase 2 failure: Mismatched attribute types for class Encapsulation Mode: Rcv'd: UDP Transport Cfg'd: UDP Tunnel(NAT-T)
%ASA-5-713257: Phase 2 failure: Mismatched attribute types for class Encapsulation Mode: Rcv'd: UDP Transport Cfg'd: UDP Tunnel(NAT-T)
%ASA-5-713257: Phase 2 failure: Mismatched attribute types for class Encapsulation Mode: Rcv'd: UDP Transport Cfg'd: UDP Tunnel(NAT-T)
%ASA-5-713257: Phase 2 failure: Mismatched attribute types for class Encapsulation Mode: Rcv'd: UDP Transport Cfg'd: UDP Tunnel(NAT-T)
%ASA-5-713904: Group = RA_l2tp, IP = 70.193.201.232, All IPSec SA proposals found unacceptable!
%ASA-3-713902: Group = RA_l2tp, IP = 70.193.201.232, QM FSM error (P2 struct &0x00007ffd8d8371c0, mess id 0xa65c811c)!
%ASA-3-713902: Group = RA_l2tp, IP = 70.193.201.232, Removing peer from correlator table failed, no match!
%ASA-5-713259: Group = RA_l2tp, IP = 70.193.201.232, Session is being torn down. Reason: Phase 2 Mismatch
%ASA-4-113019: Group = RA_l2tp, Username = , IP = 70.193.201.232, Session disconnected. Session Type: IKEv1, Duration: 0h:00m:01s, Bytes xmt: 0, Bytes rcv: 0, Reason: Phase 2 Mismatch
NOTEs:
From the client perspective, if they are not challenged for a password; than nine out of ten times, it's a bad group defined on the client behalf , if your using groups and not relying on the default-group
( a group defined under MACOSX )
( a group not defined MACOSX so the default RAgroup would be used on the ASA )
From the client perspective, if they are challenged for a password, but can't login; than nine out of ten times, the client has submitted the wrong password or username, or if using radius/tacacs; "the asa can't reach the radius server"
The show vpn-sessiondb and logging will help to determine what direction you would need to go. You can always craft a user and test the group permissions and policies.
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
