Chrombook L2TP/IPSec to ASA 5510

[RyanJohnstone]

Hello,

i am having trouble getting a chromebook to establish a Remote Access VPN connection using L2TP/IPsec to a Cisco ASA 5510 running 7.2(5)12.

Running a debug crypto isakmp 5 i am seeing the following logs (ip's changed...)

Jan 06 09:58:06 [IKEv1 DEBUG]: IP = 1.1.1.1, Oakley proposal is acceptable

Jan 06 09:58:06 [IKEv1 DEBUG]: IP = 1.1.1.1, IKE SA Proposal # 1, Transform # 1 acceptable  Matches global IKE entry # 4

Jan 06 09:58:06 [IKEv1]: IP = 1.1.1.1, Connection landed on tunnel_group DefaultRAGroup

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, Automatic NAT Detection Status:     Remote end   IS   behind a NAT device     This   end is NOT behind a NAT device

Jan 06 09:58:06 [IKEv1]: IP = 1.1.1.1, Connection landed on tunnel_group DefaultRAGroup

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, Freeing previously allocated memory for authorization-dn-attributes

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, PHASE 1 COMPLETED

Jan 06 09:58:06 [IKEv1]: IP = 1.1.1.1, Keep-alive type for this connection: DPD

Jan 06 09:58:06 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 1.1.1.1, Starting P1 rekey timer: 8100 seconds.

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, PHASE 1 COMPLETED

Jan 06 09:58:06 [IKEv1]: IP = 1.1.1.1, Keep-alive type for this connection: DPD

Jan 06 09:58:06 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 1.1.1.1, Starting P1 rekey timer: 8100 seconds.

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, Received remote Proxy Host data in ID Payload:  Address 3.3.3.3, Protocol 17, Port 1701

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, Received local Proxy Host data in ID Payload:  Address 2.2.2.2, Protocol 17, Port 1701

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, L2TP/IPSec session detected.

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, QM IsRekeyed old sa not found by addr

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, Static Crypto Map check, checking map = outside_map, seq = 1...

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, Static Crypto Map check, map = outside_map, seq = 1, ACL does not match proxy IDs src:1.1.1.1 dst:2.2.2.2

Jan 06 09:58:06 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 1.1.1.1, Selecting only UDP-Encapsulated-Tunnel and  UDP-Encapsulated-Transport modes defined by NAT-Traversal

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, IKE Remote Peer configured for crypto map: outside_dyn_map0

Jan 06 09:58:06 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 1.1.1.1, processing IPSec SA payload

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, All IPSec SA proposals found unacceptable!

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, QM FSM error (P2 struct &0x3d48800, mess id 0xce12c3dc)!

Jan 06 09:58:06 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 1.1.1.1, IKE QM Responder FSM error history (struct &0x3d48800)  <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

Jan 06 09:58:06 [IKEv1]: Group = DefaultRAGroup, IP = 1.1.1.1, Removing peer from correlator table failed, no match!

1.1.1.1 = Remote NAT address for chromebook

2.2.2.2 = ASA 5510 acting as Remote Access termintaion point

3.3.3.3 = Chromebook private address

i noticed that the Chromebook is appearing as the remote proxy ID but later on it is looking for the NAT address applied to the Chromebook.  Not sure if this is the cause or how to fix it if it is.

Can someone advise please

Thanks

Ryan

[Jim Pliss]

Same exact error that I'm getting Ryan.

[Peter Davis · Accepted solution]

7.2 is ancient code.  You may want to re-test with 9.0.x or 9.1.x.

https://support.google.com/chromebook/answer/1282338?hl=en

[rossellamariotti]

same problem as Ryan as well, and we're running 8.2.5 code.

[Peter Davis]

Unfortunately neither 7.2.x nor 8.2.x are current and therefore are missing a lot of code changes. We have resolved numerous L2TP/IPsec compatibility issues with Android (which were also present in Chrome) and these changes are present in 9.0.x and 9.1.x (we recommend the latest MRs of either). You can probably get away with the latest and greatest 8.4.x as well since most of these changes also went in to 8.4.x, but you can't get away with older ASA code.

[Jim Pliss]

Peter, we are on 8.4.11 and still having the same issue.  We will upgrde to 9.0 sometime this week, I will let you know what the outcome is.

[RyanJohnstone]

hey here, just to let you know I stepped our ASA up to release 9.1 and hey presto works fine, hopefully will for you too.

good luck

ryan

[brian.wolf]

Ryan, what specific release of 9.1 did you use?  I upgraded my pair of 5585-X from 8.4.7.15 to 9.1.5 yesterday, and I still get the "All IKE SA proposals found unacceptable!" result.  Debug shows the Chromebook sends two proposals-

3DES-CBC / SHA1 / DH-2 / Preshared key      and

AES-CBC-128 / MD5 / DH-Unknown / Preshared key.  

One of my IKEv1 policies is 

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

It seems like that should match the first proposal.  Or if it's talking about the transform sets, I think I have that covered, too:

crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec ikev1 transform-set L2TP esp-3des esp-sha-hmac
crypto ipsec ikev1 transform-set L2TP mode transport

crypto dynamic-map sfDYN-MAP 5 set ikev1 transform-set ESP-3DES-SHA sfSET AES-SHA L2TP 3DES-MD5 3DES-MD5-TSPT

And that dynamic map is incorporated into the static map.

I'm using a specific tunnel-group instead of the DefaultRAGroup, but the log shows that the connection is landing on the correct group.

Any suggestions?

[RyanJohnstone]

Hi Brian, apologies for late reply, Christmas etc

we are running 9.1(3) and all is ok, I am pretty sure I tried 9.1(4) and it did not go well, from what I remember it only allowed a single L2TP connection....

let me know if you need any other info

thanks

Ryan

[brian.wolf]

Thanks.  I can't even get one session working with 9.1.5.  Do the ikev1 policy and transform set I posted look similar to yours?  Your initial post shows that you are using the DefaultRAGroup.  Have you tried using a non-default group?  

FWIW, recovery from failover seems to be broken in 9.1.5.  Transition from secondary back to primary used to be seamless.  I've tried it twice since the upgrade, and it dropped some, but not all, connections and VPN sessions both times.  The initial failover is okay, as far as I can tell.  

Unfortunately, there is some problem with our support contract status between Cisco, our reseller, and us, so I'll have to wait until my manager gets that sorted out before I can download 9.1.3 to try it.

[RyanJohnstone]

I will check policy and transform sets when next in office and let you know. 

I vaguley remember when setting this up that it was dictated you had to use the DefaultRAGroup.  I have had a look round though and cant find any reference to this now, not sure if this has changed or my memory is playing tricks on me.  The link i followed is as below

https://support.google.com/chromebook/answer/2382577

Will let you know once i have reviews policy etc

[RyanJohnstone]

really sorry for late reply but not been around too much to check config, not sure if you still have issue but we have no reference to LT2P in any Transform Set or Dynamic map, clearly later code release must set it up differently.  Let me know if you are still having issues and I will post up our policies, sets and maps

Ryan

[brian.wolf]

I was able to get a session connected using DefaultRAGroup.   But then I ran into the same problem I get with other L2TP connections (Mac/Android) ever since I upgraded from 8.4.(4)5- the tunnel connects, but I can't access anything behind the firewall.  "capture asp type asp-drop"  shows packets from the client being dropped.  I've had a TAC case open about this for over a year.  IPSec and AnyConnect connections work fine, so I can use those for Macs and Androids, but those aren't options for Chromebooks.

Do you use IPSec as well as L2TP on the same interface?

BTW, I tried to connect a second CB session, and it failed, just like you found with 9.1(4).  I haven't tried downgrading to 9.1(2) yet.

[RyanJohnstone]

The ASA we have for the Chrome devices is purley used for L2TP, no IPsec configured at all.

[RyanJohnstone]

hey here, stepped our ASA up to release 9.1 and hey presto works fine..