cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7829
Views
0
Helpful
15
Replies

Supporting L2L, IPSEC and L2TP VPN Connections Simultaneously PIX

rfranzke
Level 1
Level 1

Hello all,

I am trying to implement a solution on my PIX FW (pix804-24.bin) to be able to support an L2L VPN session with dynamic user VPN sessions where the clients will use a mix of IPSEC(Nat detection) and L2TP. We have always supported the IPSEC stuff and that has worked great for many years. I am now trying to add in L2TP support so that I can support Android phones/ipads, etc along with Windows clients with the built in VPN l2tp clients. Everything works fine except for the new L2TP stuff. Gets to phase one completing but then tries to use the crypto map which is used for the L2L VPN. It seems to fail because the endpoint IP addresses are not in the ACL configred for the L2L crypto-map. Does anyone know if there are issues supporting all of these configurations all at once. And if not can anyone see what I have wrong in here which would make this not work. Here are the relevant configurations:

C515-A# sh run crypto
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set company-ras esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set company-l2tp esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map company-ras 1 match address company-dynamic
crypto dynamic-map company-ras 1 set pfs
crypto dynamic-map company-ras 1 set transform-set ESP-3DES-SHA ESP-3DES-MD5 company-ras
crypto dynamic-map company-ras 1 set security-association lifetime seconds 28800
crypto dynamic-map company-ras 1 set security-association lifetime kilobytes 4608000
crypto dynamic-map company-ras 2 match address company-dynamic
crypto dynamic-map company-ras 2 set transform-set company-l2tp
crypto dynamic-map company-ras 2 set security-association lifetime seconds 28800
crypto dynamic-map company-ras 2 set security-association lifetime kilobytes 4608000
crypto map company-map 1 match address company-colo
crypto map company-map 1 set pfs
crypto map company-map 1 set peer colo-pix-ext
crypto map company-map 1 set transform-set ESP-3DES-SHA ESP-3DES-MD5
crypto map company-map 1 set security-association lifetime seconds 28800
crypto map company-map 1 set security-association lifetime kilobytes 4608000
crypto map company-map 1 set nat-t-disable
crypto map company-map 2 ipsec-isakmp dynamic company-ras
crypto map company-map interface outside
crypto isakmp identity address
crypto isakmp enable outside

crypto isakmp nat-traversal 3600


crypto isakmp policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 2
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
C515-A# sh run tunnel-group
tunnel-group DefaultRAGroup general-attributes
address-pool company-ras
authentication-server-group radius LOCAL
default-group-policy l2tp
tunnel-group DefaultRAGroup ipsec-attributes
pre-shared-key *
tunnel-group DefaultRAGroup ppp-attributes
authentication pap
no authentication chap
authentication ms-chap-v2
authentication eap-proxy
tunnel-group company-ras type remote-access
tunnel-group company-ras general-attributes
address-pool company-ras
authentication-server-group radius LOCAL
tunnel-group company-ras ipsec-attributes
pre-shared-key *
tunnel-group company-admin type remote-access
tunnel-group company-admin general-attributes
address-pool company-admin
authentication-server-group radius LOCAL
default-group-policy company-admin
tunnel-group company-admin ipsec-attributes
pre-shared-key *
tunnel-group company-admin ppp-attributes
no authentication chap
authentication ms-chap-v2
tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
pre-shared-key *
isakmp keepalive threshold 15 retry 10
C515-A# sh run group-policy
group-policy DfltGrpPolicy attributes
dns-server value 10.10.10.20 10.10.10.21
vpn-tunnel-protocol IPSec
pfs enable
split-tunnel-policy tunnelspecified
split-tunnel-network-list value company-SPLIT-TUNNEL-ACL
default-domain value company.int
nac-settings value DfltGrpPolicy-nac-framework-create
group-policy company-admin internal
group-policy company-admin attributes
wins-server none
dhcp-network-scope none
vpn-access-hours none
vpn-simultaneous-logins 20
vpn-idle-timeout 30
vpn-session-timeout none
vpn-tunnel-protocol IPSec l2tp-ipsec
ip-comp disable
re-xauth disable
group-lock none
pfs enable
split-tunnel-network-list value company-ADMIN-SPLIT-TUNNEL-ACL
group-policy l2tp internal
group-policy l2tp attributes
dns-server value 10.10.10.20 10.10.10.21
vpn-tunnel-protocol l2tp-ipsec
pfs disable
split-tunnel-policy tunnelall
default-domain value company.int
nac-settings value DfltGrpPolicy-nac-framework-create

Relevant debug output

C515-A# Sep 03 02:09:33 [IKEv1 DEBUG]: IP = 66.25.14.195, Oakley proposal is acceptable
Sep 03 02:09:33 [IKEv1 DEBUG]: IP = 66.25.14.195, IKE Peer included IKE fragmentation capability flags:  Main Mode:        True  Aggressive Mode:  False
Sep 03 02:09:33 [IKEv1 DEBUG]: IP = 66.25.14.195, IKE SA Proposal # 1, Transform # 1 acceptable  Matches global IKE entry # 3
Sep 03 02:09:33 [IKEv1]: IP = 66.25.14.195, Connection landed on tunnel_group DefaultRAGroup
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Automatic NAT Detection Status:     Remote end   IS   behind a NAT device     This   end is NOT behind a NAT device
Sep 03 02:09:33 [IKEv1]: IP = 66.25.14.195, Connection landed on tunnel_group DefaultRAGroup
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Freeing previously allocated memory for authorization-dn-attributes
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, PHASE 1 COMPLETED
Sep 03 02:09:33 [IKEv1]: IP = 66.25.14.195, Keep-alive type for this connection: None
Sep 03 02:09:33 [IKEv1]: IP = 66.25.14.195, Keep-alives configured on but peer does not support keep-alives (type = None)
Sep 03 02:09:33 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 66.25.14.195, Starting P1 rekey timer: 21600 seconds.
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Received remote Proxy Host data in ID Payload:  Address 172.16.0.104, Protocol 17, Port 0
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Received local Proxy Host data in ID Payload:  Address x.x.x.x, Protocol 17, Port 1701
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, L2TP/IPSec session detected.
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, QM IsRekeyed old sa not found by addr
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Static Crypto Map check, checking map = company-map, seq = 1...
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Static Crypto Map check, map = company-map, seq = 1, ACL does not match proxy IDs src:66.25.14.195 dst:x.x.x.x
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 66.25.14.195/255.255.255.255/17/0 local proxy x.x.x.x/255.255.255.255/17/1701 on interface outside
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, QM FSM error (P2 struct &0x501c1f0, mess id 0xa181b866)!
Sep 03 02:09:33 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 66.25.14.195, IKE QM Responder FSM error history (struct &0x501c1f0)  <state>, <event>:  QM_DONE, EV_ERROR-->QM_BLD_MSG2, EV_NEGO_SA-->QM_BLD_MSG2, EV_IS_REKEY-->QM_BLD_MSG2, EV_CONFIRM_SA-->QM_BLD_MSG2, EV_PROC_MSG-->QM_BLD_MSG2, EV_HASH_OK-->QM_BLD_MSG2, NullEvent-->QM_BLD_MSG2, EV_COMP_HASH
Sep 03 02:09:33 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Removing peer from correlator table failed, no match!
Sep 03 02:09:33 [IKEv1]: Ignoring msg to mark SA with dsID 204910592 dead because SA deleted
Sep 03 02:10:05 [IKEv1 DEBUG]: IP = 66.25.14.195, Oakley proposal is acceptable
Sep 03 02:10:05 [IKEv1 DEBUG]: IP = 66.25.14.195, IKE Peer included IKE fragmentation capability flags:  Main Mode:        True  Aggressive Mode:  False
Sep 03 02:10:05 [IKEv1 DEBUG]: IP = 66.25.14.195, IKE SA Proposal # 1, Transform # 1 acceptable  Matches global IKE entry # 3
Sep 03 02:10:05 [IKEv1]: IP = 66.25.14.195, Connection landed on tunnel_group DefaultRAGroup
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Automatic NAT Detection Status:     Remote end   IS   behind a NAT device     This   end is NOT behind a NAT device
Sep 03 02:10:05 [IKEv1]: IP = 66.25.14.195, Connection landed on tunnel_group DefaultRAGroup
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Freeing previously allocated memory for authorization-dn-attributes
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, PHASE 1 COMPLETED
Sep 03 02:10:05 [IKEv1]: IP = 66.25.14.195, Keep-alive type for this connection: None
Sep 03 02:10:05 [IKEv1]: IP = 66.25.14.195, Keep-alives configured on but peer does not support keep-alives (type = None)
Sep 03 02:10:05 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 66.25.14.195, Starting P1 rekey timer: 21600 seconds.
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Received remote Proxy Host data in ID Payload:  Address 172.16.0.104, Protocol 17, Port 0
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Received local Proxy Host data in ID Payload:  Address x.x.x.x, Protocol 17, Port 1701
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, L2TP/IPSec session detected.
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, QM IsRekeyed old sa not found by addr
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Static Crypto Map check, checking map = company-map, seq = 1...
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Static Crypto Map check, map = company-map, seq = 1, ACL does not match proxy IDs src:66.25.14.195 dst:x.x.x.x
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 66.25.14.195/255.255.255.255/17/0 local proxy x.x.x.x/255.255.255.255/17/1701 on interface outside
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, QM FSM error (P2 struct &0x501c1f0, mess id 0xa5db9562)!
Sep 03 02:10:05 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 66.25.14.195, IKE QM Responder FSM error history (struct &0x501c1f0)  <state>, <event>:  QM_DONE, EV_ERROR-->QM_BLD_MSG2, EV_NEGO_SA-->QM_BLD_MSG2, EV_IS_REKEY-->QM_BLD_MSG2, EV_CONFIRM_SA-->QM_BLD_MSG2, EV_PROC_MSG-->QM_BLD_MSG2, EV_HASH_OK-->QM_BLD_MSG2, NullEvent-->QM_BLD_MSG2, EV_COMP_HASH
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Removing peer from correlator table failed, no match!
Sep 03 02:10:05 [IKEv1]: Ignoring msg to mark SA with dsID 204914688 dead because SA deleted

The two debug outputs that have me worried are the following:

Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Received remote Proxy Host data in ID Payload:  Address 172.16.0.104, Protocol 17, Port 0
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Received local Proxy Host data in ID Payload:  Address x.x.x.x, Protocol 17, Port 1701

Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Static Crypto Map check, checking map = company-map, seq = 1...
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Static Crypto Map check, map = company-map, seq = 1, ACL does not match proxy IDs src:66.25.14.195 dst:x.x.x.x
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 66.25.14.195/255.255.255.255/17/0 local proxy x.x.x.x/255.255.255.255/17/1701 on interface outside
Sep 03 02:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 66.25.14.195, QM FSM error (P2 struct &0x501c1f0, mess id 0xa5db9562)!

This seems to indicate that its detecting NAT but then failing assigning it to the crypto map entry because the networks being encrypted are not in the configured ACL which is true. It needs to use the dynamic-map entry and it does not seem to be.

Do I need to create another dynamic map entry to get this to work instead of adding lines to the same dynamic map entry with a lesser priority (higher number)?

Thanks in advance for any help here.

2 Accepted Solutions

Accepted Solutions

Hello,

That's not gonna do the trick, l2tp clients are kindda picky you know so if they dont hit the correct policy first they just stop trying it. Do the following:

no crypto dynamic-map company-ras 1 match address company-dynamic

no crypto dynamic-map company-ras 1 set pfs

no crypto dynamic-map company-ras 1 set transform-set ESP-3DES-SHA ESP-3DES-MD5 company-ras

crypto dynamic-map company-ras 1 set transform-set company-l2tp ESP-3DES-SHA ESP-3DES-MD5 company-ras

The above will not affect the existing IPsec clients at all, those clients will not use the pfs statement and will connect even if the match address is not configured (that is optional) besides Cisco IPsec clients will hit first the transport mode policy and fail however these will continue trying it and succesfully hit the other PH2 policy.

Regarding your last question, I was reffering specifically to the l2tp support for android, and yes you need to be running one of those versions.

http://www.cisco.com/en/US/docs/security/asa/asa82/release/notes/asarn82.html#wp431562

--Tavo

View solution in original post

Hey Bob,

Let's split this up a little bit, first let's get into the split-tunneling:

You are completely right,  this split-tunnel issue with L2TP has more to do with the client itself. Although we can get it to work:

Here is our first option which is the one you tried to implement already:

We can use the same classful network for both corporate network, which is  accessed by L2TP/PPTP client, and a pool, which isused for IP address  assignment.

For example, use 10.x.y.0/24 for corporate subnets and  10.a.b.0/24 for a pool.

Uncheck the following checkbox on a client:

TCP/IP Properties > Advanced > Use default gateway on remote network

In this case PPTP/L2TP client will add the following route into the routing table instead of adding default route via tunnel server:

10.0.0.0/8 via

This works for all versions of Windows. You don't need to configure anything special on your VPN server.

You might wanna take a look at this:

http://support.microsoft.com/kb/254231/en-us

Now our second option would be to use ASA Intercept DHCP Feature:

The ASA will intercept the DHCPINFORM message from a client and responds with the

parameters documented here:

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/i3.html#wp1886194

This is what we need to do:

group-policy DfltGrpPolicy attributes 

wins-server value 1.2.3.4 

dns-server value 5.6.7.8 

vpn-tunnel-protocol IPSec l2tp-ipsec  

split-tunnel-policy tunnelspecified 

split-tunnel-network-list value SPLIT 

default-domain value does.not.work.com 

split-dns value this.works.com  

intercept-dhcp 255.255.255.128 enable

address-pools value VPDN1

**(You already noticed that the default-domain doesnot get injected on the client, I'll expand on that later).

ip local pool VPDN1 192.168.2.2-192.168.2.126 mask 255.255.255.128

access-list SPLIT standard permit 192.168.1.0 255.255.255.0

access-list SPLIT standard permit 192.168.0.0 255.255.255.0

With such configuration ASA will send the following DHCP options to L2TP/IPSEC clients:

1   Subnet Mask (from "intercept-dhcp 255.255.255.128 enable")

15  DNS Domain Name (from "split-dns value this.works.com")

249 Classless Static Route (Microsoft) (from SPLIT ACL)

IP-address, DNS Server IP and WINS Server IP are assigned via IPCP.

The "this.works.com, " (yes, with a comma and a blank) domain  name will be put into the DNS Suffix Search List and to the  Connection-specific DNS Suffix. So, this has nothing to do with Split-DNS that is used by Cisco VPN Client.

Note that ASA always uses assigned IP address as the next-hop IP address in routes sent to clients.

Ok, now let's talk about the default-domain limitation, this is a PPP IPCP  protocol limitation.

This protocol does not support dns  suffix option, so it is not possible to provide L2TP, PPTP or any  other PPP client with default domain.

As per RFC 1877, only DNS server and WINS server IP addresses are supported by IPCP for name resolution:

http://www.ietf.org/rfc/rfc1877.txt

If you find any answer helpful don't forget to rate it as this will help others.

Regards.

View solution in original post

15 Replies 15

Gustavo Medina
Cisco Employee
Cisco Employee

Hello,

We cannot use the default tunnel mode on the transform-set because l2tp clients use transport mode therefore we need to use transport mode on the headend as well; try the following:

crypto ipsec transform-set l2tp esp-3des esp-sha-hmac

crypto ipsec transform-set l2tp mode transport

no crypto dynamic-map company-ras 1 match address company-dynamic

no crypto dynamic-map company-ras 1 set pfs

no crypto dynamic-map company-ras 1 set transform-set ESP-3DES-SHA ESP-3DES-MD5 company-ras

crypto dynamic-map company-ras 1 set transform-set l2tp ESP-3DES-SHA ESP-3DES-MD5 company-ras

Give it a shot with the above changes, for the Android platforms you need to be running 8.4(1) or 8.2(5) and the android devices have to be running 2.1 or later.

Regards,

Thanks for the reply here Gustavo. I realized after I posted this that I had left out the transport mode part. I tried adding it in but things still do not seem to work. I tweaked the config some but have not had a chance to post it up yet: Here is the new updated configuration:

access-list company-l2tp extended permit ip any company-vpn-net 255.255.255.224
access-list company-l2tp extended permit ip any company-admin-net 255.255.255.224
access-list company-dynamic extended permit ip any company-vpn-net 255.255.255.224
access-list company-dynamic extended permit ip any company-admin-net 255.255.255.224

ip local pool company-ras 10.10.90.129-10.10.90.158 mask 255.255.255.224

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set company-ras esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set company-l2tp esp-3des esp-sha-hmac
crypto ipsec transform-set company-l2tp mode transport
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map company-ras 1 match address company-dynamic
crypto dynamic-map company-ras 1 set pfs
crypto dynamic-map company-ras 1 set transform-set ESP-3DES-SHA ESP-3DES-MD5 company-ras
crypto dynamic-map company-ras 1 set security-association lifetime seconds 28800
crypto dynamic-map company-ras 1 set security-association lifetime kilobytes 4608000
crypto dynamic-map company-l2tp 1 match address company-l2tp
crypto dynamic-map company-l2tp 1 set transform-set company-l2tp ESP-3DES-SHA ESP-3DES-MD5
crypto dynamic-map company-l2tp 1 set security-association lifetime seconds 28800
crypto dynamic-map company-l2tp 1 set security-association lifetime kilobytes 4608000
crypto map company-map 1 match address company-colo
crypto map company-map 1 set pfs
crypto map company-map 1 set peer colo-pix-ext
crypto map company-map 1 set transform-set ESP-3DES-SHA ESP-3DES-MD5
crypto map company-map 1 set security-association lifetime seconds 28800
crypto map company-map 1 set security-association lifetime kilobytes 4608000
crypto map company-map 1 set nat-t-disable
crypto map company-map 2 ipsec-isakmp dynamic company-ras
crypto map company-map 3 ipsec-isakmp dynamic company-l2tp
crypto map company-map interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 2
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
crypto isakmp nat-traversal 3600

group-policy l2tp internal
group-policy l2tp attributes
dns-server value 10.10.10.20 10.10.10.21
vpn-tunnel-protocol l2tp-ipsec
pfs disable
split-tunnel-policy tunnelall
default-domain value company.int

tunnel-group DefaultRAGroup general-attributes
address-pool company-ras
authentication-server-group radius LOCAL
default-group-policy l2tp
tunnel-group DefaultRAGroup ipsec-attributes
pre-shared-key *
tunnel-group DefaultRAGroup ppp-attributes
authentication pap
no authentication chap
authentication ms-chap-v2
authentication eap-proxy

The main difference is that I added a new dynamic crypto map instead of sharing the existing one. I am still getting the same debug errors as before though so no change there.

I need to have the company-ras dynamic map in place because it is what is supporting existing IPSEC over Nat-T users. Trying not to break those if possible. I can try and configure this during a maintenance window to see if I get any further with it. I added a new dynamic map using the L2TP transform set in the latest configuration. Will this not achieve the same thing you are proposing?

Also, are you saying that I need to have the exact OS code you listed or are you saying that the code version I am running needs to be at least that? Thanks again for the help.

Hello,

That's not gonna do the trick, l2tp clients are kindda picky you know so if they dont hit the correct policy first they just stop trying it. Do the following:

no crypto dynamic-map company-ras 1 match address company-dynamic

no crypto dynamic-map company-ras 1 set pfs

no crypto dynamic-map company-ras 1 set transform-set ESP-3DES-SHA ESP-3DES-MD5 company-ras

crypto dynamic-map company-ras 1 set transform-set company-l2tp ESP-3DES-SHA ESP-3DES-MD5 company-ras

The above will not affect the existing IPsec clients at all, those clients will not use the pfs statement and will connect even if the match address is not configured (that is optional) besides Cisco IPsec clients will hit first the transport mode policy and fail however these will continue trying it and succesfully hit the other PH2 policy.

Regarding your last question, I was reffering specifically to the l2tp support for android, and yes you need to be running one of those versions.

http://www.cisco.com/en/US/docs/security/asa/asa82/release/notes/asarn82.html#wp431562

--Tavo

Man these versions are getting so specific. I am running this current version because it was the only one that supports a specific feature I needed.

Thanks for the suggestion. I'll try and book some time tomorrow night to correct this and report back on how it goes. Thanks again for the help.

-Bob

OK I configured things like you suggested. Now I get along much further than before. I am authenticating users via IAS/RADIUS/AD and now I can see authentication attempts in IAS log. User auth is failing however. Its possible that this is because of my mis-matched code but I am working through troubleshooting that now. Thanks very much for all the help here.

Hello,

that's nice, now I'm wondering:

Are you trying it from a windows PC or from an Android device?

what are the debugs for authentication telling us?

if you test the authentication from the ASA itself, is it successful for that same user? 

On the IAS are you allowing PAP or just mschap?

Regards,

Sorry for the late reply here. I got the authentication thing figured out. It was the authentication type I had configured so I got that cleaned up. Now I can authenticate and am able to establish the VPN. I am NOT however able to send traffic over the tunnel. Traffic just seems to blackhole somewhere.

I am trying this using both a Windows PC (Windows XP) and an Android phone. Niether one seem to be able to get traffic across the tunnel. I figured the android phone might be having issues because of the OS version I had on here but the fact that the Windows PC is also having issues leads me to believe I still have something wrong in my configuration. When I look at the established session the pkts encaps and pkts encrypt never incremement. The pkts decaps and decrypt do. I am using 'tunnelall' in the group config just to make it easier.

I should not need to allow for the UDP 1701 ports in my inbound ACL on the PIX should I? VPN traffic is not configured to bypass ACL checking currently but I thought the PIX would handle the session traffic without this. Am I wrong there?

Thanks again for the help. Almost there.

-Bob

Hello Bob,

So the clients are connected now, that's a big step. Since you are telling me you see decaps on the ASA but no encaps then the problem is either on the ASA or behind it. Can I take a look at your NAT configuration?

And you are right, you don't need to allow those packets in the access-group, if you have the "sysopt connection permit-vpn" the VPN traffic will bypass that ACL. On the version you are running is there by default, you can double check it with a "sh run all sysopt"

A few tests you can do to find out what is going on:

1-)

On the ASA:

management-access inside (or whatever the name is for your internal interface)

Connect the client and start a ping to the inside interface itself.

Was that sucessful?

2-)

If you are able to ping the inside interface but not able to reach nothing behind it then do this:

access-list CAP permit ip host 10.10.90.X host Y.Y.Y.Y

access-list CAP permit ip host Y.Y.Y.Y host 10.10.90.X

where 10.10.90.X is the ip address the connected client received from the ASA and Y.Y.Y.Y is the host behind the ASA you are trying to ping from the client.

cap cap access-list cap interface inside (again, if you have a different nameif for your inside interface please use it here)

Start the ping from the client and the do a:

"sh cap cap" on the ASA.

that will show us wheter the packets are leaving the ASA and making it back or not.

3-)

packet-tracer input inside icmp Y.Y.Y.Y 8 0 10.10.90.X det

*that will simulate a packet and show you what the ASA is going to do with a packet like that.

4-)

If you want to know if the ASA is dropping any of those packets:

cap asp type asp-drop all

start the same ping you already did and now:

sh cap asp | inc 10.10.90.X

or

sh cap asp | inc Y.Y.Y.Y

Regards,


OK Followed your advice here (I think). Getting mixed results on the Android phone so I am going to focus on the PC for just a bit. From the PC I can ping the inside interface of the PIX FW. Nothing past it though. I did verify the sysopt command:

C515-A# sh run all sysopt

sysopt connection timewait

sysopt connection tcpmss 1380

sysopt connection tcpmss minimum 0

sysopt connection permit-vpn

sysopt connection reclassify-vpn

no sysopt connection preserve-vpn-flows

no sysopt nodnsalias inbound

no sysopt nodnsalias outbound

no sysopt radius ignore-secret

no sysopt noproxyarp outside

no sysopt noproxyarp inside

Next here is the current NAT config:

access-list no-nat extended permit ip 10.10.0.0 255.255.0.0 10.10.90.0 255.255.255.0
access-list no-nat extended permit ip 10.10.0.0 255.255.0.0 10.20.0.0 255.255.0.0

nat-control
global (outside) 10 x.x.x.10
global (outside) 20 x.x.x.20
global (outside) 30 x.x.x.30
global (outside) 40 x.x.x.40
global (outside) 60 x.x.x.60
global (outside) 70 x.x.x.70
global (outside) 80 x.x.x.80
global (outside) 50 x.x.x.50
global (outside) 101 x.x.x.101
nat (inside) 0 access-list no-nat
nat (inside) 10 10.10.10.0 255.255.255.0
nat (inside) 20 10.10.20.0 255.255.255.0
nat (inside) 30 10.10.30.0 255.255.255.0
nat (inside) 50 10.10.50.0 255.255.255.0
nat (inside) 60 10.10.60.0 255.255.255.0
nat (inside) 70 10.10.70.0 255.255.255.0
nat (inside) 80 10.10.80.0 255.255.255.0
nat (inside) 101 10.10.101.0 255.255.255.0
nat (inside) 40 10.10.40.0 255.255.252.0

There are some statics here but nothing which should interfere with this.

OK here is the cap stuff:

C515-A#  conf t
C515-A(config)# access-list CAP permit ip host 10.10.90.136 host 10.10.10.20
C515-A(config)# access-list CAP permit ip host 10.10.10.20 host 10.10.90
C515-A(config)# cap VPN access-list CAP interface inside
C515-A(config)# sh cap VPN
C515-A(config)# sh cap VPN

0 packet captured
0 packet shown
C515-A(config)# sh cap VPN

0 packet captured
0 packet shown
C515-A(config)# sh cap VPN

0 packet captured
0 packet shown
C515-A(config)# sh cap VPN

0 packet captured
0 packet shown
C515-A(config)# sh cap VPN

0 packet captured
0 packet shown
C515-A(config)# sh cap VPN

0 packet captured
0 packet shown

packet-tracer input inside icmp 10.10.10.20 8 0 10.10.90.136 det

Phase: 13
Type: L2TP-PPP
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x60d1108, priority=70, domain=l2tp-ppp, deny=false
        hits=3, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=10.10.90.136, mask=255.255.255.255, port=0, dscp=0x0

Phase: 14
Type: PPP
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x3ba57f0, priority=70, domain=ppp, deny=false
        hits=3, user_data=0x2302cd8, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=10.10.90.136, mask=255.255.255.255, port=0, dscp=0x0

Phase: 15
Type: ACCESS-LIST
Subtype: aaa-user
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x3acb748, priority=11, domain=aaa-user, deny=true
        hits=0, user_data=0x3b799b8, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=10.10.90.136, mask=255.255.255.255, port=0, dscp=0x0

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

C515-A(config)# cap asp type asp-drop all

C515-A(config)# sh cap asp | include 10.10.90.136

28: 18:09:10.669246 10.10.90.136 > 10.10.10.20: icmp: echo request

I checked my ACLs and I do not see anything in here that would be blocking this traffic. I am using IPs from the same pool as my normal VPN users and all that works fine. Let me know if it might be helpful to see the entire output of the packet-tracer command.

Thanks again.

Hi again Bob,

Based on the output it seems you are hitting CSCsi27903

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsi27903

try the following and see how it goes:

group-policy l2tp attributes

nac-settings none

--Tavo

Yes that was it. Doing some additional testing but it seems to be working now. You are my hero.

Thanks again for all the help.

-Bob.

Glad to hear that we got it Bob!

Please remember to rate all the answers that helped you resolved your issue so it can help others with similar problems.

If you have any question let me know.

Regards,

OK after some testing here a couple of issues have come up. I am seeing problems with the windows client accepting some of the group policy configuration, namely the split tunneling configuration and the DNS suffix configuration. I switched to a split tunneling configuration now that I have things working OK. See config for the group policy I am using for the L2TP VPNs here:

access-list VPN-SPLIT-TUNNEL-ACL standard permit 10.10.0.0 255.255.0.0

group-policy l2tp internal

group-policy l2tp attributes

dns-server value 10.10.10.20 10.10.10.21

vpn-tunnel-protocol l2tp-ipsec

pfs disable

split-tunnel-policy tunnelspecified

split-tunnel-network-list value VPN-SPLIT-TUNNEL-ACL

default-domain value domain.int

nac-settings none

On the windows client I uncheck the "use default gateway on remote network" in the advanced TCP/IP settings. It does configure the routes but only seems to be able to use classful masks which means that it sets the route in the route table for the VPN traffic to 10.0.0.0/8 instead of 10.10.0.0/16. Do you happen to know if this is just a limitation of the Windows client? Just want to make sure the PIX stuff is correct here.

Also that change you suggested from yesterday fixed the android issues I was seeing. The split tunneling configuration does not seem to work though at all on the Droid client. The built in client does not seem to have a way to ignore the remote network gateway like the Windows client does. Any chance you might have experience getting the split tunnel to work with the Android clients?

We are veering off a little into non cisco stuff here so really I wanted to see if there was anything wrong with the PIX side and if not I'll just research the other on my own.  I am also going to recap everything done here to get this working so folks can have a known good configuration to refer too down the road. Thanks for all the time here. Very very helpful.

-Bob

Hey Bob,

Let's split this up a little bit, first let's get into the split-tunneling:

You are completely right,  this split-tunnel issue with L2TP has more to do with the client itself. Although we can get it to work:

Here is our first option which is the one you tried to implement already:

We can use the same classful network for both corporate network, which is  accessed by L2TP/PPTP client, and a pool, which isused for IP address  assignment.

For example, use 10.x.y.0/24 for corporate subnets and  10.a.b.0/24 for a pool.

Uncheck the following checkbox on a client:

TCP/IP Properties > Advanced > Use default gateway on remote network

In this case PPTP/L2TP client will add the following route into the routing table instead of adding default route via tunnel server:

10.0.0.0/8 via

This works for all versions of Windows. You don't need to configure anything special on your VPN server.

You might wanna take a look at this:

http://support.microsoft.com/kb/254231/en-us

Now our second option would be to use ASA Intercept DHCP Feature:

The ASA will intercept the DHCPINFORM message from a client and responds with the

parameters documented here:

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/i3.html#wp1886194

This is what we need to do:

group-policy DfltGrpPolicy attributes 

wins-server value 1.2.3.4 

dns-server value 5.6.7.8 

vpn-tunnel-protocol IPSec l2tp-ipsec  

split-tunnel-policy tunnelspecified 

split-tunnel-network-list value SPLIT 

default-domain value does.not.work.com 

split-dns value this.works.com  

intercept-dhcp 255.255.255.128 enable

address-pools value VPDN1

**(You already noticed that the default-domain doesnot get injected on the client, I'll expand on that later).

ip local pool VPDN1 192.168.2.2-192.168.2.126 mask 255.255.255.128

access-list SPLIT standard permit 192.168.1.0 255.255.255.0

access-list SPLIT standard permit 192.168.0.0 255.255.255.0

With such configuration ASA will send the following DHCP options to L2TP/IPSEC clients:

1   Subnet Mask (from "intercept-dhcp 255.255.255.128 enable")

15  DNS Domain Name (from "split-dns value this.works.com")

249 Classless Static Route (Microsoft) (from SPLIT ACL)

IP-address, DNS Server IP and WINS Server IP are assigned via IPCP.

The "this.works.com, " (yes, with a comma and a blank) domain  name will be put into the DNS Suffix Search List and to the  Connection-specific DNS Suffix. So, this has nothing to do with Split-DNS that is used by Cisco VPN Client.

Note that ASA always uses assigned IP address as the next-hop IP address in routes sent to clients.

Ok, now let's talk about the default-domain limitation, this is a PPP IPCP  protocol limitation.

This protocol does not support dns  suffix option, so it is not possible to provide L2TP, PPTP or any  other PPP client with default domain.

As per RFC 1877, only DNS server and WINS server IP addresses are supported by IPCP for name resolution:

http://www.ietf.org/rfc/rfc1877.txt

If you find any answer helpful don't forget to rate it as this will help others.

Regards.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: