Thanks for the background info.  The logs show that the IPsec SA was successfully negotiated, but the l2tp session never starts.  It just redials every 2 sec.

> xfrm=AES_128-HMAC_SHA2_256

This leads me to wonder whether the setup could be hitting the SHA2 truncation bug.  Can you post the output of `ip xfrm state` on the Ubuntu side?  It should show one SA for each direction while the Chromebook is attempting to connect.

> Openswan version is U2.637.K3.2.0-74-generic-pae

I see in the Openswan CHANGES file:

v2.6.38 (March 23, 2012)
[...]
* SHA2: Fix for Linux kernel using bad sha2_256 truncation (96 instead of 128)
  (to get the old behaviour for interop, specify sha2_truncbug=yes) [Paul]

I do not see any reference to "truncbug" in the package sources downloaded from https://launchpad.net/ubuntu/+source/openswan/1:2.6.37-1 so this package may be using the non-compliant protocol.

(Have they really not patched any security bugs since 2011?  If Precise is EOL now, you'll really want to move to a newer distribution, especially for an externally-facing host.)

FYI: Android, Chrome OS, strongSwan, and Openswan are all standardizing on the RFC4868-compliant SHA256_128 truncation (128 bits rather than 96).  Current versions of Android use the broken SHA256_96 truncation, but that will change in the next release.  Chrome OS has never supported SHA256_96 truncation; we expanded the cipher list to support SHA256_128 for the first time in M57.

Here is the output of the command ip xfrm state as requested.

Deleted: google.test 686 bytes

google.test 686 bytes Download

> auth-trunc hmac(sha256) 0x07574b99b77fdb1724537db815b2aa63de8b13b8f057f5ebd18809e22af25fb3 96

Thanks, the "96" at the end confirms that it is the truncation bug.  If you run the same command on a Chromebook or on a newer Linux distribution, it will say "128" instead.

I would suggest updating Openswan to 2.6.38+ (or at least asking Openswan not to propose sha256 for ESP).

I believe this will be resolved with the Openswan upgrade.  If not, please re-open.

Reopening this bug with new details from customer. 
Chrome Version:
Stable -59.0.3071.91
Beta - 60.0.3112.26 

OS: ChromeOs

VPN server is setup on TPLink TL-ER6120.

Connection fails with internal error again.
From the net.log it looks like IKE SA is being established using main mode, but quick mode fails to establish IPsec SA. After few retransmit request IPsec connection timed out. 

Attached logs: 
https://drive.google.com/drive/folders/0By9xEkAUmm_cXy1XNHpuOU8wWE0?usp=sharing

> From the net.log it looks like IKE SA is being established using main mode, but quick mode fails to establish IPsec SA. After few retransmit request IPsec connection timed out.

I agree with this analysis.  The Chromebook sends four Quick Mode requests to 12.x.x.x at 35s, 39s, 46s, and 59s, but the gateway never responds.  I would suggest enabling verbose logging on the remote end to see what is happening when it receives the Quick Mode requests.

This is different from the other failure modes I've seen so far.  It is more common to see either:

a) IPsec SA can't be established because the two sides cannot agree on crypto parameters, so charon gets a NO_PROPOSAL_CHOSEN reply and aborts

or

b) IPsec SA is established, but L2TP negotiation times out because one side uses SHA256_96 to encrypt the data traffic and the other side uses SHA256_128