FYI, I am using a Draytek Vigor 2850 Series router and hit this problem yesterday, after a couple of months of working without issue.

I originally acquired my Chromebook a couple of months ago and soon discovered that the VPN functionality was not working on the Dev channel version of Chrome OS that was current at the time.  Reverting to the Stable channel solved the problem but, not being familiar with the Chrome OS forums and bug reporting facilities at that time, I assumed the issue would be picked up in QA, before general release of the affected version/s.  I now regret not having reported it back then.

Let me know if you need any Draytek configuration information or diagnostic logs etc.

Hello,  All of my chromebooks will not connect to the VPN server.  I reverted back to version 56 and it connects perfectly to the VPN.  Can not get on VPN in v57 or v58.  It gives an error.  "Internal Error"

Precisely the same experiences as the above on my HP Chromebook G4 on stable V57 and dev V58 (working fine on V56).  My company is operating a Vigor 2960. 

I run a Meraki vpn at work.  Can not connect with chrome v57.  Have earlier versions of chrome working fine

I have been having the same problem recently. Used to connect perfectly well to my Astrill VPN service. Now, with the latest ChromeOS version, it doesn't.  Same experience on two different Chromebooks.

Also having this issue.  With v.56 and below, could connect to Witopia's l2tp servers, no problem.  Since updating to v.57, can no longer connect.  Using the stable channel.  

Have tested this on all three machines that we own with same result:

Acer Chromebook 11 (newer flip version)
Acer Chromebook 11 (older non-touchscreen version)
LG Chromebase

Dear all,

I have now shared our ASA config with cernekee@chromium.org. I hope that the Chromium team can identify the problem.

V57/58/59 no longer having a functional L2TP VPN.  System reports "internal error" when trying to connect.    I have verified the VPN server with Android devices and they work fine.      

This is on a Hisense ChromeBook - 

precisely the same experiences as the above on my Chromebook pixel(2013) on stable V57.

Same for the Samsung Chromebook Plus

Same issue with HP Chromebook 14 (falco)

Version 57.0.2987.148 (64-bit)
Platform 9202.66.0 (Official Build) stable-channel falco
Firmware Google_Falco.4389.92.0

Connecting to University of Minnesota VPN worked fine before V57.  Now it doesn't.

Having the same issue with PureVPN on ChromeOS 58 with Samsung Chromebook Plus.

I set up Sophos UTM 9.412-2.1 in a VM and enabled L2TP/IPsec VPN.  I was able to reproduce the issue connecting from a Chromebook running an M59 test build.

Here is what I see on the Sophos:


sophos:/var/log # ipsec version
Linux strongSwan U4.4.1git20100610/K3.12.58-0.247785862.g17c1041.rb7-smp64
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.


/var/sec/chroot-ipsec/etc/ipsec.conf:


config setup
	#metric="0"
	charonstart="no"
	plutodebug="none"
	uniqueids="no"
	nocrsend="yes"
	nat_traversal="yes"
	keep_alive="60"
	crlcheckinterval="0"
	strictcrlpolicy="no"
	probe_psk="no"

conn %default
	rekeyfuzz="100%"
	keyingtries="0"
	leftsendcert="always"
	dpddelay="30"
	dpdtimeout="120"
	dpdaction="restart"

conn L_REF_IpsL2tForUsernam_0
        [not shown]

conn L_REF_IpsL2tForUsernam_1
	authby="psk"
	auto="add"
	compress="no"
	esp="aes128-sha2_256_96"
	ike="aes128-sha2_256-modp2048"
	ikelifetime="28800"
	keyexchange="ike"
	keyingtries="3"
	keylife="3600"
	left="100.107.3.100"
	leftid="100.107.3.100"
	leftprotoport="17/0"
	leftupdown="/usr/libexec/ipsec/updown strict"
	pfs="no"
	rekey="no"
	rekeymargin="540"
	right="0.0.0.0"
	rightid="%any"
	rightprotoport="17/%any"
	rightsubnetwithin="0.0.0.0/0"
	type="transport"


After enabling plutodebug="all" on the Sophos VM, this is the part of the negotiation that fails:


2017:04:25-17:30:12 sophos pluto[10446]: | ****parse ISAKMP Proposal Payload:
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_NONE
2017:04:25-17:30:12 sophos pluto[10446]: |    length: 228
2017:04:25-17:30:12 sophos pluto[10446]: |    proposal number: 0
2017:04:25-17:30:12 sophos pluto[10446]: |    protocol ID: PROTO_ISAKMP
2017:04:25-17:30:12 sophos pluto[10446]: |    SPI size: 0
2017:04:25-17:30:12 sophos pluto[10446]: |    number of transforms: 7
2017:04:25-17:30:12 sophos pluto[10446]: | *****parse ISAKMP Transform Payload (ISAKMP):
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_T
2017:04:25-17:30:12 sophos pluto[10446]: |    length: 24
2017:04:25-17:30:12 sophos pluto[10446]: |    transform number: 1
2017:04:25-17:30:12 sophos pluto[10446]: |    transform ID: KEY_IKE
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_GROUP_DESCRIPTION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 15
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_AUTHENTICATION_METHOD
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_TYPE
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_DURATION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 10800
2017:04:25-17:30:12 sophos pluto[10446]: | *****parse ISAKMP Transform Payload (ISAKMP):
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_T
2017:04:25-17:30:12 sophos pluto[10446]: |    length: 36
2017:04:25-17:30:12 sophos pluto[10446]: |    transform number: 2
2017:04:25-17:30:12 sophos pluto[10446]: |    transform ID: KEY_IKE
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_ENCRYPTION_ALGORITHM
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 7
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_KEY_LENGTH
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 128
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_HASH_ALGORITHM
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 4
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_GROUP_DESCRIPTION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 15
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_AUTHENTICATION_METHOD
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_TYPE
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_DURATION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 10800
2017:04:25-17:30:12 sophos pluto[10446]: | *****parse ISAKMP Transform Payload (ISAKMP):
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_T
2017:04:25-17:30:12 sophos pluto[10446]: |    length: 36
2017:04:25-17:30:12 sophos pluto[10446]: |    transform number: 3
2017:04:25-17:30:12 sophos pluto[10446]: |    transform ID: KEY_IKE

[snipped mostly redundant transforms]

2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_DURATION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 10800
2017:04:25-17:30:12 sophos pluto[10446]: | *****parse ISAKMP Transform Payload (ISAKMP):
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_NONE
2017:04:25-17:30:12 sophos pluto[10446]: |    length: 24
2017:04:25-17:30:12 sophos pluto[10446]: |    transform number: 7
2017:04:25-17:30:12 sophos pluto[10446]: |    transform ID: KEY_IKE
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_GROUP_DESCRIPTION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 19
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_AUTHENTICATION_METHOD
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_TYPE
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_DURATION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 10800
2017:04:25-17:30:12 sophos pluto[10446]: | preparse_isakmp_policy: peer requests PSK authentication
2017:04:25-17:30:12 sophos pluto[10446]: | instantiated "L_REF_IpsL2tForUsernam_1" for 100.107.3.236
2017:04:25-17:30:12 sophos pluto[10446]: | creating state object #1 at 0x827dd10
2017:04:25-17:30:12 sophos pluto[10446]: | ICOOKIE:  44 ad 91 ee  d0 67 c6 fa
2017:04:25-17:30:12 sophos pluto[10446]: | RCOOKIE:  8a 04 a0 70  ac ae ae 50
2017:04:25-17:30:12 sophos pluto[10446]: | peer:  64 6b 03 ec
2017:04:25-17:30:12 sophos pluto[10446]: | state hash entry 25
2017:04:25-17:30:12 sophos pluto[10446]: | inserting event EVENT_SO_DISCARD, timeout in 0 seconds for #1
2017:04:25-17:30:12 sophos pluto[10446]: "L_REF_IpsL2tForUsernam_1"[1] 100.107.3.236 #1: responding to Main Mode from unknown peer 100.107.3.236
2017:04:25-17:30:12 sophos pluto[10446]: | **emit ISAKMP Message:
2017:04:25-17:30:12 sophos pluto[10446]: |    initiator cookie:
2017:04:25-17:30:12 sophos pluto[10446]: |   44 ad 91 ee  d0 67 c6 fa
2017:04:25-17:30:12 sophos pluto[10446]: |    responder cookie:
2017:04:25-17:30:12 sophos pluto[10446]: |   8a 04 a0 70  ac ae ae 50
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_SA
2017:04:25-17:30:12 sophos pluto[10446]: |    ISAKMP version: ISAKMP Version 1.0
2017:04:25-17:30:12 sophos pluto[10446]: |    exchange type: ISAKMP_XCHG_IDPROT
2017:04:25-17:30:12 sophos pluto[10446]: |    flags: none
2017:04:25-17:30:12 sophos pluto[10446]: |    message ID:  00 00 00 00
2017:04:25-17:30:12 sophos pluto[10446]: | ***emit ISAKMP Security Association Payload:
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_VID
2017:04:25-17:30:12 sophos pluto[10446]: |    DOI: ISAKMP_DOI_IPSEC
2017:04:25-17:30:12 sophos pluto[10446]: | *****parse ISAKMP Transform Payload (ISAKMP):
2017:04:25-17:30:12 sophos pluto[10446]: |    next payload type: ISAKMP_NEXT_T
2017:04:25-17:30:12 sophos pluto[10446]: |    length: 24
2017:04:25-17:30:12 sophos pluto[10446]: |    transform number: 1
2017:04:25-17:30:12 sophos pluto[10446]: |    transform ID: KEY_IKE
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_GROUP_DESCRIPTION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 15
2017:04:25-17:30:12 sophos pluto[10446]: |    [15 is MODP_3072]
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_AUTHENTICATION_METHOD
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: |    [1 is pre-shared key]
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_TYPE
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 1
2017:04:25-17:30:12 sophos pluto[10446]: |    [1 is OAKLEY_LIFE_SECONDS]
2017:04:25-17:30:12 sophos pluto[10446]: | ******parse ISAKMP Oakley attribute:
2017:04:25-17:30:12 sophos pluto[10446]: |    af+type: OAKLEY_LIFE_DURATION
2017:04:25-17:30:12 sophos pluto[10446]: |    length/value: 10800
2017:04:25-17:30:12 sophos pluto[10446]: "L_REF_IpsL2tForUsernam_1"[1] 100.107.3.236 #1: missing mandatory attribute(s) OAKLEY_HASH_ALGORITHM+OAKLEY_AUTHENTICATION_METHOD in Oakley Transform 1
2017:04:25-17:30:12 sophos pluto[10446]: "L_REF_IpsL2tForUsernam_1"[1] 100.107.3.236 #1: sending notification BAD_PROPOSAL_SYNTAX to 100.107.3.236:500


Sniffing the LAN, I only see two IKE packets in the whole exchange:
 - ISAKMP Identity Protection (Main Mode)
 - ISAKMP Informational - BAD-PROPOSAL-SYNTAX notification

Looking inside the first packet I see:

SA -> Proposal -> 7 Transforms
 1: modp3072 [no encryption algo or hash algo]
 2: aes128-sha256-modp3072
 3: aes128-sha1-modp2048
 4: 3des-sha1-modp1536
 5: 3des-sha1-modp1024
 6: aes128-sha256-ecp256
 7: ecp256 [no encryption algo or hash algo]

ipsec.conf from the Chromebook is using these parameters:

  ike="aes128gcm16-modp3072,aes128-sha256-modp3072,aes128-sha1-modp2048,3des-sha1-modp1536,3des-sha1-modp1024"

RFC 2409 section 4 says that these four attributes are mandatory:

 - encryption algorithm
 - hash algorithm
 - authentication method
 - information about a group over which to do Diffie-Hellman.

So, per the log, it looks like our client is missing the OAKLEY_HASH_ALGORITHM and OAKLEY_AUTHENTICATION_METHOD for "aes128gcm16-modp3072" and for another unknown ciphersuite that uses ecp256.  When this was tested locally with a modern version of strongSwan running on the gateway, the omission was ignored.  But this old version of strongSwan, using pluto for IKEv1, is more strict.

The first thing we'll want to do is fix the IKE proposal so that it works with the older strongSwan peer, and make sure that solves the problem.  The second action item is to ensure that we have a similar test setup that would catch this problem if it is re-introduced in the future.

Deleted: ike.pcap 520 bytes

ike.pcap 520 bytes Download

My company has maintained it's own L2TP/IPsec server for several years.  We use Openswan running on a Ubuntu Linux server.  We began to get complaints from our Chromebook users about two weeks ago.  During the last two weeks, connections have been few and random.  The last known successful connection was last Friday.

I am posting logs from my Chromebook from this morning.

I monitored the IP traffic using tcpdump while I tried to connect.  I see no inbound traffic on port 1701 after the IPsec connection is complete.  The log entries on the server also do not show any l2tp traffic, but does record a sucessful IPsec connection.

I will be happy to assist with trouble shooting since I can monitor both ends of the connection being attempted.

Deleted: debug-logs_20170427-094034.tgz 803 KB

debug-logs_20170427-094034.tgz 803 KB Download

I have two patches in the CQ for this bug.  Will request merges to M58/M59 once they land.  With these two patches applied I am able to connect to a Sophos UTM gateway again, same as M56.

The first issue (ciphersuite negotiation) was described at length in c#21.

The second issue is that the strongSwan unity plugin is enabled in the upstream 5.5.0 Gentoo ebuild.  This plugin is designed to support a Cisco-specific method of split tunneling when the gateway provides Split-Include attributes.  It does this by narrowing the negotiated traffic selectors.  However, when this plugin is loaded, it appears to have side effects even when the other side is not a Cisco gateway and is not sending Split-Include attributes.  This is a known issue documented here:

https://wiki.strongswan.org/issues/1068

The net effect is that the Chromebook side improperly rejects the gateway's (legitimate) TS proposal:

Aug 17 12:15:57 Peer1 info  charon: [  ENC] generating QUICK_MODE request 1928624787 [ HASH SA No KE ID ID ]
Aug 17 12:15:57 Peer1 info  charon: [  NET] sending packet: from 172.16.0.4[500] to 172.16.0.24[500] (372 bytes)
Aug 17 12:15:57 Peer1 info  charon: [  NET] received packet: from 172.16.0.24[500] to 172.16.0.4[500] (372 bytes)
Aug 17 12:15:57 Peer1 info  charon: [  ENC] parsed QUICK_MODE response 1928624787 [ HASH SA No KE ID ID ]
Aug 17 12:15:57 Peer1 info  charon: [  IKE] no acceptable traffic selectors found
Aug 17 12:15:57 Peer1 info  charon: [  ENC] generating INFORMATIONAL_V1 request 3524574942 [ HASH N(NO_PROP) ]
Aug 17 12:15:57 Peer1 info  charon: [  NET] sending packet: from 172.16.0.4[500] to 172.16.0.24[500] (76 bytes)

Sniffing and decrypting the Quick Mode exchange shows reasonable-looking IP addresses in both sides' proposals.

Since we don't use tunnel mode with L2TP, I'm just going to disable the unity plugin in the ebuild.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/c48ff6b7ff70a14e3538d7742ab25401ebcc5935

commit c48ff6b7ff70a14e3538d7742ab25401ebcc5935
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Thu Apr 27 18:15:46 2017

vpn: Only use AES GCM for Phase 2

Per [1] this does not seem to be supported in IKEv1 Phase 1.  Specifying
it causes strongSwan to quietly send a malformed proposal, which breaks
interop with older clients.

[1] https://wiki.strongswan.org/projects/1/wiki/CipherSuiteExamples

BUG= chromium:707139 
TEST=manually connect to Sophos VPN

Change-Id: I6a7dff956659cccab53ca8a78f43852fbdfe8e4b
Reviewed-on: https://chromium-review.googlesource.com/487738
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>

[modify] https://crrev.com/c48ff6b7ff70a14e3538d7742ab25401ebcc5935/vpn-manager/l2tpipsec_vpn.cc

c#22:
> I am posting logs from my Chromebook from this morning.

This looks like a different issue.

The two issues I saw on Sophos UTM were:

1) BAD_PROPOSAL_SYNTAX notification in response to the Main Mode negotiation: the two sides could not even negotiate an initial SA to use for subsequent key exchanges.

2) Once (1) was fixed and the IKE exchange is successful, the Quick Mode negotiation fails with "no acceptable traffic selectors found."  This prevented setting up the SA for ESP.

By contrast, this log says:

2017-04-27T09:38:23.184800-05:00 INFO charon[7000]: 11[ENC] parsed QUICK_MODE response 2187629446 [ HASH SA No ID ID ]
2017-04-27T09:38:23.186386-05:00 INFO charon[7000]: 11[IKE] CHILD_SA managed{1} established with SPIs c93abb99_i f9ba039e_o and TS 192.168.1.2/32[udp/l2tp] === 12.0.231.14/32[udp/l2tp]
2017-04-27T09:38:23.186405-05:00 INFO charon[7000]: 11[IKE] CHILD_SA managed{1} established with SPIs c93abb99_i f9ba039e_o and TS 192.168.1.2/32[udp/l2tp] === 12.0.231.14/32[udp/l2tp]
2017-04-27T09:38:23.192274-05:00 INFO charon[7000]: 11[ENC] generating QUICK_MODE request 2187629446 [ HASH ]
2017-04-27T09:38:23.192527-05:00 INFO charon[7000]: 11[NET] sending packet: from 192.168.1.2[4500] to 12.0.231.14[4500] (60 bytes)
2017-04-27T09:38:23.916424-05:00 INFO l2tpipsec_vpn[6988]: IPsec connection now up
2017-04-27T09:38:23.920012-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: setsockopt recvref[22]: Protocol not available
2017-04-27T09:38:23.920047-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: This binary does not support kernel L2TP.
2017-04-27T09:38:23.920144-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: xl2tpd version xl2tpd-1.3.0 started on localhost PID:7019
2017-04-27T09:38:23.920158-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
2017-04-27T09:38:23.920169-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Forked by Scott Balmos and David Stipp, (C) 2001
2017-04-27T09:38:23.920212-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Inherited by Jeff McAdams, (C) 2002
2017-04-27T09:38:23.920225-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Forked again by Xelerance (www.xelerance.com) (C) 2006
2017-04-27T09:38:23.920236-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Listening on IP address 0.0.0.0, port 1701
2017-04-27T09:38:23.920422-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Connecting to host 12.0.231.14, port 1701
2017-04-27T09:38:28.926018-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Maximum retries exceeded for tunnel 54191.  Closing.
2017-04-27T09:38:28.926064-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Connection 0 closed to 12.0.231.14, port 1701 (Timeout)
2017-04-27T09:38:33.930494-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Unable to deliver closing message for tunnel 54191. Destroying anyway.
2017-04-27T09:38:33.930518-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Will redial in 2 seconds

[...]

2017-04-27T09:39:21.976532-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Unable to deliver closing message for tunnel 43626. Destroying anyway.
2017-04-27T09:39:21.976559-05:00 INFO l2tpipsec_vpn[6988]: xl2tpd[7019]: Will redial in 2 seconds
2017-04-27T09:39:22.822231-05:00 INFO shill[874]: [INFO:vpn_driver.cc(297)] VPN connect timeout.
2017-04-27T09:39:22.822351-05:00 DEBUG shill[874]: [VERBOSE2:process_manager.cc(184)] process_manager StopProcess(6988)
2017-04-27T09:39:22.822372-05:00 DEBUG shill[874]: [VERBOSE2:process_manager.cc(351)] process_manager TerminateProcess(pid: 6988, use_sigkill: 0)
2017-04-27T09:39:22.822386-05:00 DEBUG shill[874]: [VERBOSE2:process_manager.cc(263)] process_manager KillProcess(pid: 6988)
2017-04-27T09:39:22.822440-05:00 INFO shill[874]: [INFO:rpc_task.cc(42)] RPCTask 1 destroyed.
2017-04-27T09:39:22.822459-05:00 DEBUG shill[874]: [VERBOSE1:dbus_object.cc(255)] Unregistering D-Bus object '/task/1'.
2017-04-27T09:39:22.822632-05:00 INFO shill[874]: [INFO:service.cc(404)] Service 15: state Configuring -> Failure


So charon/strongSwan was able to negotiate an ESP SA for traffic between the hosts, but for some reason, the L2TP layer cannot connect on top of the SA.  It tries for a little while but never gets anywhere, and eventually times out.

Once the fixes from this bug land in the tree, you may want to retest using canary channel, and file a new bug if there is still a problem.

> I monitored the IP traffic using tcpdump while I tried to connect.  I see no inbound traffic on port 1701 after the IPsec connection is complete.

Since L2TP itself has to run on top of ESP in this configuration, tcpdump alone generally will not show traffic on port 1701.  Instead, you'll see packets with IP type ESP, or 4500/udp packets.  In order to sniff the L2TP traffic I usually have to run `ip xfrm state` on one of the endpoints while the connection is up, then enter the parameters into wireshark under Edit -> Preferences -> Protocols -> ESP so that wireshark can decrypt the ESP payload.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/0bf488737471f7c09249ebdd3252474ed90115a7

commit 0bf488737471f7c09249ebdd3252474ed90115a7
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Thu Apr 27 22:02:21 2017

Disable USE flag for strongSwan unity plugin

During the 5.5.0 upgrade, the unity plugin got enabled because it
is on by default in new strongSwan builds.  But this plugin has a
known issue that breaks transport mode, resulting in a regression when
interoperating with certain VPN gateways.  Disable the unity plugin
until this is fixed.  We never need Split-Include for transport mode
anyway, and we do not currently support tunnel mode.

BUG= chromium:707139 
TEST=manually connect to Sophos UTM test VPN and verify ping
TEST=run autotests: network_VPNConnect.l2tpipsec_{psk,cert,xauth}

Change-Id: Ie317522b3cf4d1f488e3d225d013d305f4ea3c4c
Reviewed-on: https://chromium-review.googlesource.com/489082
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/0bf488737471f7c09249ebdd3252474ed90115a7/profiles/targets/chromeos/package.use

Retested with 9503.0.0 canary and everything looks good.  Requesting merge to M58/M59.

LGTM for 58 for a one line change that seems well known and tested, once this lands in 59 feel free to merge to 58.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/017f7332adcdd31936b17d92e35e57ab7ed89dcb

commit 017f7332adcdd31936b17d92e35e57ab7ed89dcb
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Fri Apr 28 22:41:07 2017

Disable USE flag for strongSwan unity plugin

During the 5.5.0 upgrade, the unity plugin got enabled because it
is on by default in new strongSwan builds.  But this plugin has a
known issue that breaks transport mode, resulting in a regression when
interoperating with certain VPN gateways.  Disable the unity plugin
until this is fixed.  We never need Split-Include for transport mode
anyway, and we do not currently support tunnel mode.

BUG= chromium:707139 
TEST=manually connect to Sophos UTM test VPN and verify ping
TEST=run autotests: network_VPNConnect.l2tpipsec_{psk,cert,xauth}

Change-Id: Ie317522b3cf4d1f488e3d225d013d305f4ea3c4c
Reviewed-on: https://chromium-review.googlesource.com/489082
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
(cherry picked from commit 0bf488737471f7c09249ebdd3252474ed90115a7)
Reviewed-on: https://chromium-review.googlesource.com/490849
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/017f7332adcdd31936b17d92e35e57ab7ed89dcb/profiles/targets/chromeos/package.use

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/e6ac76ddaffb7fe7f6a3833a02119c30791f758b

commit e6ac76ddaffb7fe7f6a3833a02119c30791f758b
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Fri Apr 28 22:41:05 2017

vpn: Only use AES GCM for Phase 2

Per [1] this does not seem to be supported in IKEv1 Phase 1.  Specifying
it causes strongSwan to quietly send a malformed proposal, which breaks
interop with older clients.

[1] https://wiki.strongswan.org/projects/1/wiki/CipherSuiteExamples

BUG= chromium:707139 
TEST=manually connect to Sophos VPN

Change-Id: I6a7dff956659cccab53ca8a78f43852fbdfe8e4b
Reviewed-on: https://chromium-review.googlesource.com/487738
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
(cherry picked from commit c48ff6b7ff70a14e3538d7742ab25401ebcc5935)
Reviewed-on: https://chromium-review.googlesource.com/490692
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/e6ac76ddaffb7fe7f6a3833a02119c30791f758b/vpn-manager/l2tpipsec_vpn.cc

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/071afec15fe9ded6e4ebd8aa78b244949a39df25

commit 071afec15fe9ded6e4ebd8aa78b244949a39df25
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Sun Apr 30 01:34:42 2017

vpn: Only use AES GCM for Phase 2

Per [1] this does not seem to be supported in IKEv1 Phase 1.  Specifying
it causes strongSwan to quietly send a malformed proposal, which breaks
interop with older clients.

[1] https://wiki.strongswan.org/projects/1/wiki/CipherSuiteExamples

BUG= chromium:707139 
TEST=manually connect to Sophos VPN

Change-Id: I6a7dff956659cccab53ca8a78f43852fbdfe8e4b
Reviewed-on: https://chromium-review.googlesource.com/487738
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
(cherry picked from commit c48ff6b7ff70a14e3538d7742ab25401ebcc5935)
Reviewed-on: https://chromium-review.googlesource.com/490691
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/071afec15fe9ded6e4ebd8aa78b244949a39df25/vpn-manager/l2tpipsec_vpn.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/e53e4cae7b172eb179d8c92e5714d0b6354868a1

commit e53e4cae7b172eb179d8c92e5714d0b6354868a1
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Sun Apr 30 01:34:43 2017

Disable USE flag for strongSwan unity plugin

During the 5.5.0 upgrade, the unity plugin got enabled because it
is on by default in new strongSwan builds.  But this plugin has a
known issue that breaks transport mode, resulting in a regression when
interoperating with certain VPN gateways.  Disable the unity plugin
until this is fixed.  We never need Split-Include for transport mode
anyway, and we do not currently support tunnel mode.

BUG= chromium:707139 
TEST=manually connect to Sophos UTM test VPN and verify ping
TEST=run autotests: network_VPNConnect.l2tpipsec_{psk,cert,xauth}

Change-Id: Ie317522b3cf4d1f488e3d225d013d305f4ea3c4c
Reviewed-on: https://chromium-review.googlesource.com/490712
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/e53e4cae7b172eb179d8c92e5714d0b6354868a1/profiles/targets/chromeos/package.use

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8bfe0d1a29db25dfb5a272e3ce486c585851b263

commit 8bfe0d1a29db25dfb5a272e3ce486c585851b263
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Tue May 02 04:54:07 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490656
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>

[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/mips/common.config
[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/i386/common.config
[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/armel/chromiumos-arm.flavour.config
[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/armel/chromiumos-armada38x.flavour.config
[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/arm64/common.config
[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/base.config
[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/armel/chromiumos-ipq40xx.flavour.config
[modify] https://crrev.com/8bfe0d1a29db25dfb5a272e3ce486c585851b263/chromeos/config/x86_64/common.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/654f15a642d4f4413a419639fdf29113b6146923

commit 654f15a642d4f4413a419639fdf29113b6146923
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Tue May 02 04:54:04 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/491086
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>

[modify] https://crrev.com/654f15a642d4f4413a419639fdf29113b6146923/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/af8a89005af75ddd5cb86b537c4df469a0dee5c2

commit af8a89005af75ddd5cb86b537c4df469a0dee5c2
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Tue May 02 04:54:11 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490655
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>

[modify] https://crrev.com/af8a89005af75ddd5cb86b537c4df469a0dee5c2/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/771ea78b59ce7aabfe5ab09ac9af33587fccc1e2

commit 771ea78b59ce7aabfe5ab09ac9af33587fccc1e2
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Tue May 02 04:54:09 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490702
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>

[modify] https://crrev.com/771ea78b59ce7aabfe5ab09ac9af33587fccc1e2/chromeos/config/base.config

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/942f9bf28e0f0a13c01b9f2c1ef2287ea3a6c19b

commit 942f9bf28e0f0a13c01b9f2c1ef2287ea3a6c19b
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 00:45:18 2017

CHROMIUM: xfrm: Fix struct packing for arm64 netlink messages

Several of these structs are incorrect, so setting an IPsec policy
silently fails.  Test case:

    ip xfrm policy flush
    ip xfrm policy add src 100.107.2.11 dst 1.2.3.4 \
        dir out tmpl src 100.107.2.11 dst 1.2.3.4 \
        proto esp reqid 0x1 mode transport
    ip xfrm policy

On kevin, the final command will return an error instead of reading back
the new policy, due to the ABI mismatch.  This patch fixes it.

BUG= chromium:707139 
TEST=IPsec autotests (which don't notice if L2TP traffic bypasses IPsec)
TEST=connect to a PureVPN gateway (which does notice)

Change-Id: I38dab01991d4ac4945ddd9e1cadd337bca279b54
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/492426
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>

[modify] https://crrev.com/942f9bf28e0f0a13c01b9f2c1ef2287ea3a6c19b/include/uapi/linux/xfrm.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4c2550260e9a8034af34dd22cd6fc1334208cb38

commit 4c2550260e9a8034af34dd22cd6fc1334208cb38
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:05:49 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490656
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit 8bfe0d1a29db25dfb5a272e3ce486c585851b263)
Reviewed-on: https://chromium-review.googlesource.com/495106

[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/mips/common.config
[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/i386/common.config
[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/armel/chromiumos-arm.flavour.config
[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/armel/chromiumos-armada38x.flavour.config
[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/arm64/common.config
[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/base.config
[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/armel/chromiumos-ipq40xx.flavour.config
[modify] https://crrev.com/4c2550260e9a8034af34dd22cd6fc1334208cb38/chromeos/config/x86_64/common.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/35b98c18f24d30748d0a93c7b5a09eb37622b927

commit 35b98c18f24d30748d0a93c7b5a09eb37622b927
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:06:12 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/491086
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit 654f15a642d4f4413a419639fdf29113b6146923)
Reviewed-on: https://chromium-review.googlesource.com/495107

[modify] https://crrev.com/35b98c18f24d30748d0a93c7b5a09eb37622b927/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c831935f68316b54caaef6853992f88e523233b8

commit c831935f68316b54caaef6853992f88e523233b8
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:06:14 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490655
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit af8a89005af75ddd5cb86b537c4df469a0dee5c2)
Reviewed-on: https://chromium-review.googlesource.com/495108

[modify] https://crrev.com/c831935f68316b54caaef6853992f88e523233b8/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3c6c9e2db2b15b69bbc360b85d166bee9dd0e242

commit 3c6c9e2db2b15b69bbc360b85d166bee9dd0e242
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:06:14 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490702
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit 771ea78b59ce7aabfe5ab09ac9af33587fccc1e2)
Reviewed-on: https://chromium-review.googlesource.com/495110

[modify] https://crrev.com/3c6c9e2db2b15b69bbc360b85d166bee9dd0e242/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/51d17b29c9ab7c4768f23a28a37dfdefc5d79d76

commit 51d17b29c9ab7c4768f23a28a37dfdefc5d79d76
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:06:15 2017

CHROMIUM: xfrm: Fix struct packing for arm64 netlink messages

Several of these structs are incorrect, so setting an IPsec policy
silently fails.  Test case:

    ip xfrm policy flush
    ip xfrm policy add src 100.107.2.11 dst 1.2.3.4 \
        dir out tmpl src 100.107.2.11 dst 1.2.3.4 \
        proto esp reqid 0x1 mode transport
    ip xfrm policy

On kevin, the final command will return an error instead of reading back
the new policy, due to the ABI mismatch.  This patch fixes it.

BUG= chromium:707139 
TEST=IPsec autotests (which don't notice if L2TP traffic bypasses IPsec)
TEST=connect to a PureVPN gateway (which does notice)

Change-Id: I38dab01991d4ac4945ddd9e1cadd337bca279b54
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/492426
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit 942f9bf28e0f0a13c01b9f2c1ef2287ea3a6c19b)
Reviewed-on: https://chromium-review.googlesource.com/495109

[modify] https://crrev.com/51d17b29c9ab7c4768f23a28a37dfdefc5d79d76/include/uapi/linux/xfrm.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2f486a6029051feb5ad6e9814f8d622aaec4aef9

commit 2f486a6029051feb5ad6e9814f8d622aaec4aef9
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:11:13 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490656
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit 8bfe0d1a29db25dfb5a272e3ce486c585851b263)
Reviewed-on: https://chromium-review.googlesource.com/495126

[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/mips/common.config
[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/i386/common.config
[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/armel/chromiumos-arm.flavour.config
[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/armel/chromiumos-armada38x.flavour.config
[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/arm64/common.config
[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/base.config
[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/armel/chromiumos-ipq40xx.flavour.config
[modify] https://crrev.com/2f486a6029051feb5ad6e9814f8d622aaec4aef9/chromeos/config/x86_64/common.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/55ceeb2a8be1be4da6ab7c0c41468db83b98c13e

commit 55ceeb2a8be1be4da6ab7c0c41468db83b98c13e
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:11:14 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490655
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit af8a89005af75ddd5cb86b537c4df469a0dee5c2)
Reviewed-on: https://chromium-review.googlesource.com/495112

[modify] https://crrev.com/55ceeb2a8be1be4da6ab7c0c41468db83b98c13e/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/55ceeb2a8be1be4da6ab7c0c41468db83b98c13e

commit 55ceeb2a8be1be4da6ab7c0c41468db83b98c13e
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:11:14 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490655
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit af8a89005af75ddd5cb86b537c4df469a0dee5c2)
Reviewed-on: https://chromium-review.googlesource.com/495112

[modify] https://crrev.com/55ceeb2a8be1be4da6ab7c0c41468db83b98c13e/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0810ae6df88942097fb30444a90ecf5a3225c718

commit 0810ae6df88942097fb30444a90ecf5a3225c718
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed May 03 21:11:14 2017

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490702
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>
(cherry picked from commit 771ea78b59ce7aabfe5ab09ac9af33587fccc1e2)
Reviewed-on: https://chromium-review.googlesource.com/495113

[modify] https://crrev.com/0810ae6df88942097fb30444a90ecf5a3225c718/chromeos/config/base.config

HP Chromebook 14
I just switched back to the stable channel which included a complete powerwash:

Version 58.0.3029.112 (64-bit)
Platform 9334.69.0 (Official Build) stable-channel falco
Firmware Google_Falco.4389.92.0

1. Created new L2TP/IPSec + pre-shared key VPN connection using exact same info as OpenVPN client config that is working fine on a macbook. 

Tried to connect, got error: "Internal error" 
Deleted and recreated the VPN config with IP address, same error: "Internal error"


2. Created new L2TP/IPSec + pre-shared key VPN with expressvpn, it works fine.


3. Noticed I now have an OpenVPN provider type option, tried to recreate same connection as in #1 using OpenVPN instead of L2TP/IPSec + pre-shared key. It won't let me set the pre-shared key and Server CA Certificate is set to Default.

Tried to connect, got error: "Connect failed"

Just received the latest beta update:
Version:  59.0.3071.47 (Official Build) beta (32-bit)
Platform:  9460.34.0 (Official Build) beta-channel kevin
Firmware:  Google_Kevin.8785.178.0

PureVPN now running fine over L2TP/IPSec + pre-shared key

c#54:
> Created new L2TP/IPSec + pre-shared key VPN connection using exact same info as OpenVPN client config that is working fine on a macbook

These two protocols (L2TP/IPsec and OpenVPN) do not use all of the same connection parameters.  OpenVPN generally wants to use a CA cert rather than a PSK to authenticate the gateway.  You can import a CA cert through chrome://settings/certificates and then it should be available in the VPN configuration dropdown.

I would suggest using beta channel to test the L2TP/IPsec changes from this bug, and dev channel to test the recent OpenVPN upgrade (2.3.2->2.4.1).  If the newer Chrome OS versions are malfunctioning, it would be helpful to know more about the VPN provider so that the problem can be reproduced here.

I switched to the beta channel, tried again with L2TP/IPSec + pre-shared key, same error.

VPN provider:
Created a Google VM machine (Debian default), used this to set up the VPN: https://github.com/hwdsl2/setup-ipsec-vpn
Made sure UDP ports 500 and 4500 are open on the firewall.

Can connect with a macbook no problem, chromebook still returns internal error.

I was able to reproduce the issue.  I am seeing two problems with the Libreswan configuration created by the "setup-ipsec-vpn" scripts:

1) It specifies "phase2alg=3des-sha1,aes-sha1,aes-sha2,aes256-sha2_512" for the ESP quick mode negotiation.  Many of these are compatible with the proposals made by the Chrome OS client.  However, Libreswan only seems to check them against Chrome OS' first proposal when the phase2alg option is specified.  I believe this failure is due to unnecessarily strict behavior on Libreswan's part.

2) It enables support for the SHA2 truncation bug: https://libreswan.org/wiki/FAQ#Using_SHA2_256_for_ESP_connection_establishes_but_no_traffic_passes_.28especially_Android_6.0.29

Chrome OS implements proper, standards-compliant (128 bit) truncation when the peers negotiate HMAC-SHA-256.  It looks like some other OSes implement 96-bit truncation to allow interop with old broken clients (Linux kernels older than 2.6.33 from 2011), so that mode was enabled by default.  The truncation setting needs to match on both sides, or else the L2TP traffic will be silently dropped after the SA is negotiated.

If problem (2) is widespread enough, perhaps we should avoid proposing sha256 at all.  What a mess. :-(

To work around both of these problems, edit /etc/ipsec.conf on the Debian host and change the phase2alg line to say:

  phase2alg=aes_gcm-null

Then run `systemctl restart ipsec`.

I am running:
Version 57.0.2987.146
Platform 9202.64.0 (Official Build) stable-channel daisy
Firmware Google_Snow.2695.132.0

I used https://github.com/hwdsl2/setup-ipsec-vpn on DigitalOcean to create a VPN server.

I changed /etc/ipsec.conf to:
  ike=3des-sha1,3des-sha1;modp1024,aes-sha1,aes-sha1;modp1024,aes-sha2,aes-sha2;modp1024,aes256-sha2_512
  phase2alg=aes_gcm-null

My iphone can connect to the server, but my Chromebook still cannot connect.  

c#59: The fixes went into M58, not M57.  9334.69.0 (mentioned in c#54) should have everything committed so far.

Hello guys,

I hereby confirm that with M59 (59.0.3071.47) the VPN connection to our Cisco ASA works again.

I am on Version 60.0.3112.26 (Official Build) beta (64-bit) and my OpenVPN connection fails with Internal Error.

We have a report from another customer indicating the issue is still happening on version 59. The error message is the same. However, they can connect fine on Windows and on Chrome OS using the Cisco Anyconnect extension. More details about found in the following shared folder (google.com sign in required): https://drive.google.com/open?id=0B7ntI3exdCzYUDczdDJDamRRQ1E

c#63: This log shows that the two sides could not agree on crypto parameters:

2017-06-08T16:37:30.662843+00:00 INFO charon[4095]: 12[ENC] parsed INFORMATIONAL_V1 request 2097172694 [ HASH N(NO_PROP) ]
2017-06-08T16:37:30.662917+00:00 INFO charon[4095]: 12[IKE] received NO_PROPOSAL_CHOSEN error notify

I would suggest looking at the gateway's "esp=" configuration to see what it is trying to do.

Thank you to everyone who worked to resolve this issue, and to all who work
to provide this operating system! You are doing great work.

On comment 64, it says the log shows that the two sides could not agree on crypto parameters...what should the gateway's "esp=" configuration be set to in order to resolve this issue for the Cisco ASA?

Google's instructions on setting up VPN on a Cisco ASA device for chromebooks:  
https://support.google.com/chromebook/answer/2382577?hl=en

See step 1.2:  Setup the Crypto map

Deleted: EditCryptoMap.jpg 80.4 KB

	EditCryptoMap.jpg 80.4 KB View Download

@cernekee could you help us address our customer's concerns about the "esp=" configuration in c#66?

Hi,

I first commented on this case back in April and I have just noticed the case is now closed so, presumably, everything should now be fixed.  However, I'm still seeing the problem on my Chromebook, so I'm not sure if it's because the fix has not yet filtered through to the Stable Channel.  I'm still a bit 'green' on Chrome OS matters, so could somebody explain to me whether or not the patch should be included within my version of Chrome OS?

Below are the details of my version/build.  I'm wondering if the "B" in "merge-merged-release-R59-9460.B-chromeos-3.10" means 'Beta'?  Any assistance would be very much appreciated.

My Version - 59.0.3071.134 (Official Build) (64-bit)
Platform - 9460.73.1 (official Build) stable channel terra
Firmware - Google_Terra.7287.154.80
Channel  - Curently on stable

Just started tinkering with Nordvpn and getting this same issue on dev channel:  Version 61.0.3163.51 (Official Build) dev (32-bit)

Asus Flip which supports Android.  The Nordvpn Android app works fine on the same platform. 

This bug is clearly not fixed at all - how can we reopen it?

Hi, I am with 'adr...@sutherlandonline.org' on this one.  There are clearly people who had working VPN connections using Chrome OS V56, but as soon as the V57 update was installed they no longer worked and are still not working!

Either this case needs to be re-opened, or some clarity needs to be provided on what suddenly caused these connections to stop working under the version 57 and, if this is not considered to be due to a bug in the OS, then to provide clear and definitive information as to what was changed in the OS (and why), which led to this situation.  Those of us still affected by the issue might at least have something with which to approach the vendors of our VPN endpoint servers, in order to get some support on what we need to do to our configurations to get our connections working again under the current version of Chrome OS.

If, on the other hand, this issue IS still down to a generic bug in the OS, please re-open the case and get some people working on it.  I offered have a go at providing relevant Draytek configuration information or diagnostic logs etc. back on 6th April, but no-one casked for anything so, at the time, I figured this had to be a generic VPN issue within the OS.

Can we have some meaningful, helpful information from someone please (without it getting too technical)?

Thanks

A few suggestions:

1) Please enable verbose logging on both sides to help track down the source of the failure, and email me the logs.

2) Do not assume that every L2TP/IPsec interop problem has the same root cause.  As you can see upthread, several different issues have been identified and corrected.  There many ways for the setup to break; some are easier to fix than others.  In certain cases the gateway side is misbehaving and may need to be updated.

3) After a specific problem is identified from (1) and the root cause is understood, let's use a new bug to track it.  Ideally, a user who sees <some error> in the logs will be able to search for that term and quickly find out how to solve it.

I'm still having this issue on the latest chromeos version 61.0.3163.70 (Official Build) beta (64-bit)

This is a failed connection from Chromebook.

 2017-09-03 23:36:50	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-03 23:36:50	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-03 23:36:50	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-03 23:36:50	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-03 23:36:50	 Matching General Setup key for dynamic ip client...
 2017-09-03 23:36:50	 Find Phase1 proposal: SHA2_256
 2017-09-03 23:36:50	 Responding to Main Mode from XX.XX.XXX.XXX
 2017-09-03 23:36:50	 [IPSEC/IKE][Local][34:-][@XX.XX.XXX.XXX] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-03 23:36:50	 [IPSEC/IKE][Local][34:-][@XX.XX.XXX.XXX] state transition fail: STATE_QUICK_R0
 2017-09-03 23:36:50	 sent MR3, ISAKMP SA established with XX.XX.XXX.XXX. In/Out Index: 34/0
 2017-09-03 23:36:50	 Matching General Setup key for dynamic ip client...
 2017-09-03 23:36:50	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-03 23:36:50	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-03 23:36:50	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-03 23:36:50	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-03 23:36:50	 Matching General Setup key for dynamic ip client...
 2017-09-03 23:36:50	 Find Phase1 proposal: SHA2_256
 2017-09-03 23:36:50	 Responding to Main Mode from XX.XX.XXX.XXX


Using the same credentials from an android phone, connected with no issue.

2017-09-03 23:44:43	 [H2L][UP][L2TP/IPsec][@1:username]
 2017-09-03 23:44:43	 [L2TP][Radius/LDAP][0:username][@XX.XX.XXX.XXX] LCP REJ: authentication fail, ask retry
 2017-09-03 23:44:35	 IPsec SA established with XX.XX.XXX.XXX. In/Out Index: 34/0
 2017-09-03 23:44:35	 IPsec SA #805 will be replaced after 23982 seconds
 2017-09-03 23:44:35	 Responding to Quick Mode from XX.XX.XXX.XXX
 2017-09-03 23:44:35	 [IPSEC/IKE][Local][34:-][@XX.XX.XXX.XXX] quick_inI1_outR1: match network
 2017-09-03 23:44:35	 Receive client L2L remote network setting is 81.149.93.44/32
 2017-09-03 23:44:35	 Accept ESP prorosal ENCR ESP_AES, HASH AUTH_ALGORITHM_HMAC_SHA1
 2017-09-03 23:44:34	 sent MR3, ISAKMP SA established with XX.XX.XXX.XXX. In/Out Index: 34/0
 2017-09-03 23:44:34	 Matching General Setup key for dynamic ip client...
 2017-09-03 23:44:34	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-03 23:44:34	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-03 23:44:34	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-03 23:44:34	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-03 23:44:34	 Matching General Setup key for dynamic ip client...
 2017-09-03 23:44:34	 Responding to Main Mode from XX.XX.XXX.XXX

c#74:

> Find Phase1 proposal: SHA2_256

Any time you see the two sides negotiate SHA256, check for  bug 724475 .  Android Oreo and later will also use sha2_truncbug=no so VPN gateways should ensure that they are implementing RFC-compliant behavior.

I don't see an error in this log snippet, so it might help to look at the context and at the Chromebook log (file:///var/log/net.log).

> ls: cannot access 'strongswan.conf': No such file or directory

This is normal.  /etc contains symlinks that point to dynamically created strongSwan configuration files under /run.  The files under /run are deleted by vpn_manager after the connection attempt fails.

Sorry for the multiple posts:

And if it helps:

chronos@localhost /etc $ ls -L
ls: cannot access 'strongswan.conf': No such file or directory
ls: cannot access 'ipsec.secrets': No such file or directory
ls: cannot access 'ipsec.conf': No such file or directory


2017-09-03T23:37:54.262655+01:00 ERR l2tpipsec_vpn[11861]: IPsec connection timed out
2017-09-03T23:37:55.273762+01:00 ERR l2tpipsec_vpn[11861]: Unable to send signal to 11863: No such process
2017-09-03T23:37:55.273943+01:00 ERR l2tpipsec_vpn[11861]: Unable to send signal to 11874: No such process


2017-09-03T23:32:19.293127+01:00 ERR l2tpipsec_vpn[11203]: IPsec connection timed out
2017-09-03T23:32:20.304299+01:00 ERR l2tpipsec_vpn[11203]: Unable to send signal to 11204: No such process
2017-09-03T23:32:20.304421+01:00 ERR l2tpipsec_vpn[11203]: Unable to send signal to 11215: No such process
2017-09-03T23:32:49.832828+01:00 ERR shill[1296]: [ERROR:l2tp_ipsec_driver.cc(148)] Not implemented reached in virtual bool shill::L2TPIPSecDriver::ClaimInterface(const std::string &, int)
2017-09-03T23:32:49.832842+01:00 ERR shill[1296]: [ERROR:l2tp_ipsec_driver.cc(148)] Not implemented reached in virtual bool shill::L2TPIPSecDriver::ClaimInterface(const std::string &, int)
2017-09-03T23:32:49.841046+01:00 INFO kernel: [ 2151.491469] IPv6: ADDRCONF(NETDEV_UP): tun0: link is not ready
2017-09-03T23:33:30.228227+01:00 INFO kernel: [ 2191.878828] IPv6: ADDRCONF(NETDEV_UP): tun0: link is not ready
2017-09-03T23:33:30.226887+01:00 ERR shill[1296]: [ERROR:l2tp_ipsec_driver.cc(148)] Not implemented reached in virtual bool shill::L2TPIPSecDriver::ClaimInterface(const std::string &, int)
2017-09-03T23:33:30.226908+01:00 ERR shill[1296]: [ERROR:l2tp_ipsec_driver.cc(148)] Not implemented reached in virtual bool shill::L2TPIPSecDriver::ClaimInterface(const std::string &, int)

> l2tpipsec_vpn[11203]: IPsec connection timed out

The charon, xl2tpd, and pppd log messages might shed more light on why the timeout occurred (there are many, many possible reasons).

Where do I find those log files?

file:///var/log/net.log

BTW, if you want to see the strongSwan configuration that Chrome OS is using, the files under /etc (like ipsec.conf) should be accessible during the connection process prior to the timeout.

Here's my net.log file. I can't see anything that explains why its not working. Looking at the log it looks like it connects, but then disconnects.

Deleted: net.log.txt 207 KB

net.log.txt 207 KB View Download

Looks like phase 1 is successful, then right at the start of phase 2, the VPN_IP sends a DELETE message that tells the Chromebook to restart the sequence.  This repeats over and over for ~30s, then the timeout fires:

2017-09-03T23:37:24.231829+01:00 INFO charon[11874]: 09[IKE] initiating Main Mode IKE_SA managed[1] to VPN_IP
2017-09-03T23:37:24.231837+01:00 INFO charon[11874]: 09[IKE] initiating Main Mode IKE_SA managed[1] to VPN_IP
2017-09-03T23:37:24.231922+01:00 INFO charon[11874]: 09[ENC] generating ID_PROT request 0 [ SA V V V V V ]
2017-09-03T23:37:24.232023+01:00 INFO charon[11874]: 09[NET] sending packet: from 192.168.0.22[500] to VPN_IP[500] (340 bytes)
2017-09-03T23:37:24.255279+01:00 INFO charon[11874]: 10[NET] received packet: from VPN_IP[500] to 192.168.0.22[500] (124 bytes)
2017-09-03T23:37:24.255328+01:00 INFO charon[11874]: 10[ENC] parsed ID_PROT response 0 [ SA V V ]
2017-09-03T23:37:24.255343+01:00 INFO charon[11874]: 10[IKE] received DPD vendor ID
2017-09-03T23:37:24.255349+01:00 INFO charon[11874]: 10[IKE] received NAT-T (RFC 3947) vendor ID
2017-09-03T23:37:24.258987+01:00 INFO charon[11874]: 10[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
2017-09-03T23:37:24.259016+01:00 INFO charon[11874]: 10[NET] sending packet: from 192.168.0.22[500] to VPN_IP[500] (372 bytes)
2017-09-03T23:37:24.579546+01:00 INFO charon[11874]: 11[NET] received packet: from VPN_IP[500] to 192.168.0.22[500] (356 bytes)
2017-09-03T23:37:24.579692+01:00 INFO charon[11874]: 11[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
2017-09-03T23:37:24.594580+01:00 INFO charon[11874]: 11[IKE] local host is behind NAT, sending keep alives
2017-09-03T23:37:24.594784+01:00 INFO charon[11874]: 11[ENC] generating ID_PROT request 0 [ ID HASH ]
2017-09-03T23:37:24.594975+01:00 INFO charon[11874]: 11[NET] sending packet: from 192.168.0.22[4500] to VPN_IP[4500] (76 bytes)
2017-09-03T23:37:24.618845+01:00 INFO charon[11874]: 12[NET] received packet: from VPN_IP[4500] to 192.168.0.22[4500] (76 bytes)
2017-09-03T23:37:24.619047+01:00 INFO charon[11874]: 12[ENC] parsed ID_PROT response 0 [ ID HASH ]
2017-09-03T23:37:24.619348+01:00 INFO charon[11874]: 12[IKE] IKE_SA managed[1] established between 192.168.0.22[192.168.0.22]...VPN_IP[VPN_IP]
2017-09-03T23:37:24.619384+01:00 INFO charon[11874]: 12[IKE] IKE_SA managed[1] established between 192.168.0.22[192.168.0.22]...VPN_IP[VPN_IP]
2017-09-03T23:37:24.619430+01:00 INFO charon[11874]: 12[IKE] scheduling reauthentication in 9878s
2017-09-03T23:37:24.619457+01:00 INFO charon[11874]: 12[IKE] maximum IKE_SA lifetime 10418s
2017-09-03T23:37:24.620150+01:00 INFO charon[11874]: 12[ENC] generating QUICK_MODE request 1215737414 [ HASH SA No ID ID NAT-OA NAT-OA ]
2017-09-03T23:37:24.620535+01:00 INFO charon[11874]: 12[NET] sending packet: from 192.168.0.22[4500] to VPN_IP[4500] (348 bytes)
2017-09-03T23:37:24.651160+01:00 INFO charon[11874]: 13[NET] received packet: from VPN_IP[4500] to 192.168.0.22[4500] (92 bytes)
2017-09-03T23:37:24.651408+01:00 INFO charon[11874]: 13[ENC] parsed INFORMATIONAL_V1 request 1128613447 [ HASH D ]
2017-09-03T23:37:24.651504+01:00 INFO charon[11874]: 13[IKE] received DELETE for IKE_SA managed[1]
2017-09-03T23:37:24.651554+01:00 INFO charon[11874]: 13[IKE] deleting IKE_SA managed[1] between 192.168.0.22[192.168.0.22]...VPN_IP[VPN_IP]
2017-09-03T23:37:24.651569+01:00 INFO charon[11874]: 13[IKE] deleting IKE_SA managed[1] between 192.168.0.22[192.168.0.22]...VPN_IP[VPN_IP]

2017-09-03T23:37:55.263857+01:00 INFO l2tpipsec_vpn[11861]: Shutting down...
2017-09-03T23:37:55.264447+01:00 INFO charon[11874]: 00[DMN] signal of type SIGINT received. Shutting down
2017-09-03T23:37:55.264748+01:00 INFO charon[11874]: 00[IKE] destroying IKE_SA in state CONNECTING without notification
2017-09-03T23:37:55.273762+01:00 ERR l2tpipsec_vpn[11861]: Unable to send signal to 11863: No such process
2017-09-03T23:37:55.273943+01:00 ERR l2tpipsec_vpn[11861]: Unable to send signal to 11874: No such process


I would suggest enabling verbose logging on the VPN_IP side to figure out why it is sending the DELETE message.

The VPN is a draytek router. This is all I get from it's logs:

2017-09-04 23:19:43	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:43	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:43	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:43	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:43	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:43	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:43	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:43	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:43	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:43	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:43	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:43	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:43	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:43	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:43	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:43	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:43	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:43	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:43	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:42	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:42	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:42	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:42	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:42	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:42	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:42	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:42	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:42	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:42	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:42	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:42	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:42	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:42	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:42	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:42	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:42	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:41	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:41	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:41	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:41	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:41	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:41	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:41	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:41	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:41	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:41	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:41	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0
 2017-09-04 23:19:41	 sent MR3, ISAKMP SA established with CHROMEBOOK_PUBLIC_IP. In/Out Index: 34/0
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
 2017-09-04 23:19:41	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-04 23:19:41	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
 2017-09-04 23:19:41	 Matching General Setup key for dynamic ip client...
 2017-09-04 23:19:41	 Find Phase1 proposal: SHA2_256
 2017-09-04 23:19:41	 Responding to Main Mode from CHROMEBOOK_PUBLIC_IP


When I use the exact same credentials from an android device the logs look like this and the connection succeeds.

2017-09-04 23:22:36	 [H2L][UP][L2TP/IPsec][@1:username]
2017-09-04 23:22:36	 [L2TP][Radius/LDAP][0:username][@ANDROID_PUBLIC_IP] LCP REJ: authentication fail, ask retry
2017-09-04 23:22:28	 IPsec SA established with ANDROID_PUBLIC_IP. In/Out Index: 34/0
2017-09-04 23:22:28	 IPsec SA #1026 will be replaced after 23925 seconds
2017-09-04 23:22:28	 Responding to Quick Mode from ANDROID_PUBLIC_IP
2017-09-04 23:22:28	 [IPSEC/IKE][Local][34:-][@ANDROID_PUBLIC_IP] quick_inI1_outR1: match network
2017-09-04 23:22:28	 Receive client L2L remote network setting is VPN_IP/32
2017-09-04 23:22:28	 Accept ESP prorosal ENCR ESP_AES, HASH AUTH_ALGORITHM_HMAC_SHA1
2017-09-04 23:22:27	 sent MR3, ISAKMP SA established with ANDROID_PUBLIC_IP. In/Out Index: 34/0
2017-09-04 23:22:26	 Matching General Setup key for dynamic ip client...
2017-09-04 23:22:26	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
2017-09-04 23:22:26	 Get error size of IKE buffer:2394, from:__tmp_alloc. Try malloc...
2017-09-04 23:22:26	 NAT-Traversal: Using RFC 3947, peer is NATed
2017-09-04 23:22:26	 Accept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
2017-09-04 23:22:26	 Matching General Setup key for dynamic ip client...
2017-09-04 23:22:26	 Responding to Main Mode from ANDROID_PUBLIC_IP



From the chromebook it looks like the error is around here:

 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] may be security method/sbunet setting/GRE setting unmatched?
 2017-09-04 23:19:41	 [IPSEC/IKE][Local][34:-][@CHROMEBOOK_PUBLIC_IP] state transition fail: STATE_QUICK_R0

> From the chromebook it looks like the error is around here:

I agree.  So it looks like something in the Phase 2 negotiation is making the VPN gateway unhappy.

Searching around for a few of these log messages, I could not determine what IPsec implementation is being used on the Draytek side.  Perhaps it is a custom solution.  If you can find out more about this software, maybe you could enable verbose logging or see if a newer version of the firmware fixes the issue.

> The VPN is a draytek router.

I'm still getting an 'internal error' when connecting to the VPN on our work draytek 2960.  I know that the firmware was patched to the latest version 2 weeks ago as I had hoped this would resolve the issue but it didn't.

Surely if other devices can connect to the draytek router fine and the chromebook cannot, we can agree that this is an issue with the chromebook, not the draytek vpn.

I can't get any more logs and I'm at a bit of a loss now. Draytek offers IPSEC L2TP vPN or SSL VPN. They even have a SSL VPN app for android. This runs on my chromebook fine, but only tunnels traffic for android apps, not the whole chrome os.

Anyone have any ideas on what we can try next? Is there some way I can play with the swann connection or ipsec files? Or does chromeos create them on the fly and we have no option to manipulate them?

> They even have a SSL VPN app for android. This runs on my chromebook fine, but only tunnels traffic for android apps, not the whole chrome os.

This is being addressed in  bug 696865 

> Is there some way I can play with the swann connection or ipsec files?

You can make a copy of the ipsec config files during the connection attempt, and then manually invoke strongSwan from the command line.  Or run it from a Linux VM where you'll have more control.

I also can confirm a problem when trying to connect from a Chromebook to Draytek L2TP/IPSEC vpn. It works from a Windows client.
Vigor 2925, Firmware 3.8.4.2.
Chrome 60.0.3112.114 / Platform 9592.96.0

Error logged by Draytek: see attachment. Last error is:

[IPSEC/IKE][Local][66:-][@83.232.62.53] may be security method/sbunet setting/GRE setting unmatched?

 [IPSEC/IKE][Local][66:-][@83.232.62.53] state transition fail: STATE_QUICK_R0

Deleted: DrayTek Vigor2925 Error log.png 96.0 KB

	DrayTek Vigor2925 Error log.png 96.0 KB View Download

Hi,

Following on from my previous post, apologies for not having submitted my Draytek Vigor 2850vn log sooner. I couldn't find any verbose configuration setting for the log, so I guess below is all that is available (apologies if I'm wrong about that).  I also had do do a Power Wash on my Chromebook recently, so my original VPN connection set up (which was tried and tested, prior to the introduction of the issue) was unfortunately deleted.  I believe I have re-created the VPN connection set up with exactly the same settings, as far as I can be sure.  Not suprisingly, it still doesn't connect but, interestingly, my Draytek log doesn't actually list any errors during the connection attempt, not as such.  It would appear to retry and retry until it times out.  I have included the logs of two connection attempts, the first that fails, using my Chromebook, followed by the one that works, using my Windows Phone.  There is only one log entry for the connection made from my phone, so if there IS a verbose log setting for the Draytek that I have missed, any advice on how to enable it would be much appreciated, at which point I'll re-submit the logs:

Draytek Vigor 2850vn Log (in Reverse Chroological Order) From Chromebook VPN Connection Attempt (which fails after 10 seconds)

 Time	                 Message
 2017-09-19 14:54:10	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:10	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:10	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:10	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:10	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:09	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:09	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:08	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:08	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:08	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:08	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:07	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:07	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:07	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:07	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:07	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:07	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:07	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:06	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:06	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:06	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:06	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:06	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:06	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:06	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:06	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:06	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:06	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:05	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:05	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:05	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:05	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:05	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:05	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:05	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:05	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:05	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:05	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:04	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:04	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:04	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:04	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:04	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:04	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:04	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:04	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:04	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:03	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:03	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:03	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:03	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:03	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:03	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:03	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:03	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:03	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:03	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:02	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:02	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:02	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:02	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:02	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:02	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:02	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:02	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:02	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:01	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:01	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:01	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:01	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:01	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:01	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:01	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:01	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:01	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:01	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:01	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:01	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:01	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:01	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:01	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:00	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:00	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:00	 Matching General Setup key for dynamic ip client...


Draytek Vigor 2850vn Log from Windows Phone VPN Connection (which succeeds, instantly)

 Time	                 Message
 2017-09-19 15:10:09	 [H2L][UP][L2TP][@2:SteveT]

Thanks for everyone's on-going activity on this.  Should one of the bug site administrators be changing the Status of this issue back to 'Open' again, as opposed to 'Fixed', which it clearly isn't?

Kind regards,

Steve

I wanted to add that my Chromebook works with the L2TP/IPSEC implementation of Synology, just not with Draytek's. However, Windows works with both.

Because most problems refer to ChromeOS connecting to Draytek it could also be a Draytek problem. 

I would like to try if ChromeOS v.56 worked with Draytek (because this thread started with an issue with v.57 and later). Does anybody know if it's possible to rollback to v.56 when you already are on 60.0.3112.114?

Hi Robert,

Firstly, regarding your question about rolling back the OS.  Whilst I think you will probably find references on the web suggesting this is possible (or at least to roll back to the immediately, previous installed version) all I can tell you is that my research/attempts to roll back to a spcific version ended up being a fruitless exercise.

Moving on to your comment:

"Because most problems refer to ChromeOS connecting to Draytek it could also be a Draytek problem."

You are quite correct, of course, that this could be an issue with the Draytek implememtation of L2TP/IPSEC, but we shouldn't forget that everything was working fine for everyone, before V.57 was released, and then it broke for a wide range of different VPN endpoint servers, all at the same time, hence this issue being opened.  It's still not clear to me (maybe becuase I am not familiar enough with intepreting the information provided on this site) if the problem was fixed for the majority of those affected as the result of an OS patch, or by them working around the issue by changing configurational settings on their VPN endpoint servers.  As far as I am aware, Draytek do not provide the same level of configuration facilities as some of the bigger, commercial solutions, which could explain why the Draytek community are still out in the cold on this.

Here is a relevant extract from one of my earlier posts on this case, which touched on the same topic as yours:

"Either this case needs to be re-opened, or some clarity needs to be provided on what suddenly caused these connections to stop working under the version 57 and, if this is not considered to be due to a bug in the OS, then to provide clear and definitive information as to what was changed in the OS (and why), which led to this situation.  Those of us still affected by the issue might at least have something with which to approach the vendors of our VPN endpoint servers, in order to get some support on what we need to do to our configurations to get our connections working again under the current version of Chrome OS.

If, on the other hand, this issue IS still down to a generic bug in the OS, please re-open the case and get some people working on it.  I offered to have a go at providing relevant Draytek configuration information or diagnostic logs etc. back on 6th April, but no-one asked for anything so, at the time, I figured this had to be a generic VPN issue within the OS."

I guess this case is now back at the stage of people trying to understand what is the cause of the issue with the Draytek routers, but why the site Administrator/s have not bothered to re-open the case remains a mystery to me.  Trouble is, everyone currently appears to be attempting to reverse engineer the cause of this problem, with limited resources available to them.  I'd have thought the Chrome OS developers, however, should have everything they need at their disposal to debug this problem quite quickly and easily.

Let's come back to your topic of rolling back the OS for a moment.  Presumably, the Chrome OS developers can build a Chromebook with any version of the OS they choose.  Even if they couldn't easily document the changes that were introduced within the VPN client in V.57 for us, I would have thought that all they need to do is to take two chromebooks, one with V.56 and one with the current version, configure a VPN client connection to a Draytek router on each of them, then use a sniffer to compare the two different VPN connection negotiations and see what's different.  That should immediatly lead them to the root cause of this problem and would give us something with which to go to Draytek, if they think the Chrome OS is not to blame here.

Someone please tell me, being a mere pseudo techie, am I over simplifying what needs to be done here?

I'd be happy to allow my Draytek router to be used by the Chrome OS developers for testing/debugging Draytek VPN connectivity, if that would help!

I'd welcome any comments on what I have said above, whether they be positive or negative.

Thanks for your reply. I largely agree on what your are saying. 

I have just created an support-request at Draytek with a link to this bug. Their first response was "that if it works with Windows, it should be a ChromeOS problem", but I requested a small test. For Draytek it should be easy to test a VPN from a Chromebook. If that doesn't work we have two major products (ChromeOS and Draytek) that somehow are incompatible now. That should be enough to reopen this ticket, create a new one or get Draytek to check what is going wrong. I hope.

That's a coincidence Robert, I'd just done exactly the same thing, i.e. raised a tech support case with Draytek UK Support (as opposed to International Support)! Let's see what they come back with. Keep you posted.

Kind regards,

Steve

Hi guys, thanks for raising this with Draytek.  If you could have them get in touch with me directly or reply on this bug, we can continue debugging the interop problem.

The first thing to investigate is: why is the Draytek unit sending back a DELETE message here?

2017-09-03T23:37:24.620150+01:00 INFO charon[11874]: 12[ENC] generating QUICK_MODE request 1215737414 [ HASH SA No ID ID NAT-OA NAT-OA ]
2017-09-03T23:37:24.620535+01:00 INFO charon[11874]: 12[NET] sending packet: from 192.168.0.22[4500] to VPN_IP[4500] (348 bytes)
2017-09-03T23:37:24.651160+01:00 INFO charon[11874]: 13[NET] received packet: from VPN_IP[4500] to 192.168.0.22[4500] (92 bytes)
2017-09-03T23:37:24.651408+01:00 INFO charon[11874]: 13[ENC] parsed INFORMATIONAL_V1 request 1128613447 [ HASH D ]
2017-09-03T23:37:24.651504+01:00 INFO charon[11874]: 13[IKE] received DELETE for IKE_SA managed[1]

I believe this is what causes the repeated attempts seen in c#89.

Hi Cernekee,

Thanks for you input here, I'm optomistic that there will now be some real progress made.

I have forwarded your invitation for Draytek to liaise with you directly on this case and brought their attention to your query about the DELETE command.

The Draytek case reference that has been assigned to this issue is #DQ377476.

If Draytek do agree to hook up with you directly, I think it would be really useful if you were all to continue to liaise with one another via this case on the site, as it will mean that all the affected Draytek users will be able to monitor the progress on the case and perhaps contribute to testing.

A request for Robert, in the Netherlands, re Comment 93.  Could you please let us know your Draytek case reference?  There is no point in Draytek duplicating effort on this and it could end up being counter productive.  I guess you may have raised your case with Dratek International Support, whilst I raised it with Draytek UK Technical Support.  Once we have both case references, we can highlight these to Draytek and they can then decide for themselves as to which case they want to run with, whether that be in the UK or elsewhere.

Kind regards,

Steve

Hi

I note this case is still sitting with a Status of 'Fixed' which could be very misleading to people visiting the site. Could one of the site Administaors please re-open the case?

Thanks, Steve

Hi Steve,

Thanks for your effort. I got only disappointing messages from Draytek saying first that it must be a Chromium problem because Windows had no problems and then saying that they didn't have any Chromebook to test with. 

Now, I do understand that they receive a lot of VPN-problems and almost all of them are user related mis-configurations, but I hoped for a little more support, especially because this thread has detailed information about the problem and Cernekee offered to help from the Chromium side. 

Maybe they will pick it up but for now it looks like the case is not opened by Draytek in The Netherlands.

Hi Robert,

No worries and thanks for letting me know.  Although this is an issue that is affecting me personally, I own a little IT consulting/support business and, whilst we don't focus on selling hardware, it just so happens that we are a Draytek reseller in the UK.

Hopefully, we will be able this leverage this relationship to get Draytek UK Support to take this case a little more seriously than the experience you've just had with them.  If cernekee@chromium.org is going to be working with them, it shouldn't matter whether or not they have access to a Chromebook.

Keep you posted.

Kind regards,

Steve

All, 

I'm glad this issue is still alive. I too am a draytek user. As mentioned in my previous posts, I have other devices successfully connecting to the draytek VPN. Including an android device. It's funny, an android app on the chromebook can connect to the draytek, but the chromeOS natively cannot.

This could have been a solution, however android app VPN only covers android apps, not all traffic from the chromebook.

I think the fact that windows/android devices can connect successfully points to something not quite right in ChromeOS. Even more so that it used to work for users before and then stopped. I think this may be an issue with the strongswan config, but I don't have knowledge on how to play with this on the chromeos.

I'm also happy to help with testing / offer use of my router to assist.

Looking forward to updates.

> Should one of the bug site administrators be changing the Status of this issue back to 'Open' again, as opposed to 'Fixed', which it clearly isn't?

Hi guys, thanks for getting in touch with Draytek and helping to move things along.  I have created  bug 767549  to track the Draytek interop problem, so if you're involved in this effort, go ahead and star that bug to receive updates.

> This could have been a solution, however android app VPN only covers android apps, not all traffic from the chromebook.

This is tracked in  bug 696865 .  The Chrome OS / Android VPN integration feature is expected to land in canary channel in the next couple of days.  Stable release for M63 is mid-December.

Oops, bug number did not get linkified for some reason.  Link:  http://crbug.com/767549 

Hi Kevin (cernekee@chromium.org)

Yep, I'd tried using the Draytek Android VPN client right back at the outset of this issue arising and, whilst it connected fine, it didn't really suprise me that the connection was not accesible down at the OS level.

Thanks for opening the new case ( http://crbug.com/767549 ), I'll divert my attention to that case from now on.

Just two final questions from me, on this case, if you don't mind.  Apologies if the answers to these questions are already staring me in the face, within the details of the case, but I'm just not seeing/understanding the info, if that is the case.

First question. With exception to the Draytek community, which of the following scenarios provided the solution on this case for all the other affected users? Was it:
       1) A bug fix/patch was applied to the Chrome OS.
       2) The affected organisations changed their VPN endpoint server configs.
       3) A combination of 1) and 2)
       4) Something else (and if so, what)
?

Second question. In simple layman's terms, what was it that was changed in the Chrome OS VPN client in V.57 to cause these issues and what was the reason for it being changed?

If these two questions could be answered in 'For Dummies' terms, I shall be able to put this case behind me as a happy man!

Kind regards,

Steve

I've had problems connecting to any VPN servers but have found that by switching off WiFi and connecting with an ethernet network cable and then connecting to the VPN server it all works. I've no explanation for why but it works on my Dell chromebook. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3c710f5b4a173d9c8eccd96adad5d49b16e66b4e

commit 3c710f5b4a173d9c8eccd96adad5d49b16e66b4e
Author: Hugo Benichi <hugobenichi@google.com>
Date: Fri Aug 17 23:14:24 2018

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490656
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>

(cherry picked from commit 8bfe0d1a29db25dfb5a272e3ce486c585851b263)

BUG=b:111767229
BUG=b:77556895
TEST=Android's atest android.net.cts.IpSecManagerTest on grunt.
Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Hugo Benichi <hugobenichi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170150
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Hugo Benichi <hugobenichi@google.com>
Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org>

[modify] https://crrev.com/3c710f5b4a173d9c8eccd96adad5d49b16e66b4e/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2cef945c8cb8dc86d0455eda8d18e6bdc1d296c3

commit 2cef945c8cb8dc86d0455eda8d18e6bdc1d296c3
Author: Hugo Benichi <hugobenichi@google.com>
Date: Wed Aug 29 13:27:13 2018

CHROMIUM: config: Enable AES-GCM mode for IPsec

CONFIG_CRYPTO_AES=y by itself does not enable GCM mode on non-x86
platforms, so if strongSwan negotiates aes128gcm16 for ESP, ARM kernels
with CONFIG_CRYPTO_GCM disabled will return -ENOSYS.  Enabling
CONFIG_CRYPTO_GCM fixes this.

BUG= chromium:707139 
TEST=manually connect to a Sophos UTM gateway on veyron_minnie

Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490656
Reviewed-by: Abhishek Bhardwaj <abhishekbh@google.com>

(cherry picked from commit 8bfe0d1a29db25dfb5a272e3ce486c585851b263)

BUG=b:111767229
BUG=b:77556895
TEST=Android's atest android.net.cts.IpSecManagerTest on eve-arcnext.
Change-Id: I5b8014439d422dabb050b5feba448e8883d2c6a3
Signed-off-by: Hugo Benichi <hugobenichi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170148
Commit-Ready: Hugo Benichi <hugobenichi@google.com>
Tested-by: Hugo Benichi <hugobenichi@google.com>
Reviewed-by: Grant Grundler <grundler@chromium.org>

[modify] https://crrev.com/2cef945c8cb8dc86d0455eda8d18e6bdc1d296c3/chromeos/config/base.config