openswan 2.6.38 in raring is broken for l2tp. 2.6.37 works.

[AJ Slater]

Upgrading to ubuntu 13.04 broke the l2tp VPN hosted on my Ubuntu server.

Downgrading from openswan 2.6.38 to 2.6.37 fixes it.

connecting to the l2tp VPN from an OSX or iOS client in 2.6.38 yeilds the following pluto log:

00]
packet from 67.188.104.170:500: received Vendor ID payload [Dead Peer Detection]
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: responding to Main Mode from unknown peer 67.188.104.170
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: STATE_MAIN_R1: sent MR1, expecting MI2
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: STATE_MAIN_R2: sent MR2, expecting MI3
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: Main mode peer ID is ID_IPV4_ADDR: '10.0.1.5'
"L2TP-PSK-NAT"[1] 67.188.104.170 #1: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: deleting connection "L2TP-PSK-NAT" instance with peer 67.188.104.170 {isakmp=#0/ipsec=#0}
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: new NAT mapping for #1, was 67.188.104.170:500, now 67.188.104.170:32769
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: Dead Peer Detection (RFC 3706): enabled
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: Applying workaround for Mac OS X NAT-OA bug, ignoring proposed subnet
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: the peer proposed: 173.230.145.84/32:17/1701 -> 67.188.104.170/32:17/0
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: peer proposal was reject in a virtual connection policy because:
"L2TP-PSK-NAT"[2] 67.188.104.170 #1: a private network virtual IP was required, but the proposed IP did not match our list (virtual_private=)
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: responding to Quick Mode proposal {msgid:ca8077f1}
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: us: 173.230.145.84<173.230.145.84>[+S=C]:17/1701
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: them: 67.188.104.170[10.0.1.5,+S=C]:17/61510
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: Dead Peer Detection (RFC 3706): enabled
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
"L2TP-PSK-noNAT"[1] 67.188.104.170 #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x017b6567 <0x338f5415 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=67.188.104.170:32769 DPD=enabled}

     YAY! CONNECTED HOORAY! But then after a quick 5-10 sec timeout it just dies. It never talks to xl2tp. xl2tp logs show nothing. The very next thing that happens is:

"L2TP-PSK-NAT"[2] 67.188.104.170 #1: received Delete SA(0x017b6567) payload: deleting IPSEC State #2
2TP-PSK-NAT"[2] 67.188.104.170 #1: received Delete SA payload: deleting ISAKMP State #1
"L2TP-PSK-NAT"[2] 67.188.104.170: deleting connection "L2TP-PSK-NAT" instance with peer 67.188.104.170 {isakmp=#0/ipsec=#0}

it shuts down the connection. boo. yuck. Downgrading to 2.6.37 lets it talk to xl2tp. Why? I don't know.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[AJ Slater (aj-slater)]

FYI it looks like this bug persists in openswan-2.6.41 in the openswan testing ppa at https://launchpad.net/~openswan/+archive/openswan-testing

[Simon Déziel (sdeziel)]

AJ Slater, could you please attach your OpenSwan and xl2tpd configs to this ticket for further investigation?

[AJ Slater (aj-slater)]

I'm by no means an expert with l2tp/pptp configuration. I'd love to hear that I have a simple config error.
Attached is my xl2pd.conf that exhibits the mentioned bug.

[Simon Déziel (sdeziel)]

Can you try to reproduce the issue on a supported Ubuntu version (Precise, Saucy or Trusty)? Raring is out of support and misses a fix for xl2tpd which *could* be what you are hitting.

[AJ Slater (aj-slater)]

I'm currently using Trusty and have tested the issue on Precise & Saucy in
the past.

On Tue, Apr 22, 2014 at 12:09 PM, Simon Déziel
<email address hidden>wrote:

> Can you try to reproduce the issue on a supported Ubuntu version
> (Precise, Saucy or Trusty)? Raring is out of support and misses a fix
> for xl2tpd which *could* be what you are hitting.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1174903
>
> Title:
> openswan 2.6.38 in raring is broken for l2tp. 2.6.37 works.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/1174903/+subscriptions
>

[AJ Slater (aj-slater)]

I'm currently using Trusty and have replicated the bug on Saucy in the past.

[AJ Slater (aj-slater)]

The bug persists with Trusty using openswan 1:2.6.41-0xelerance1

[Benjamin Lauret (ben-lauretland)]

I can confirm. Same issue here. I wonder if there's a new feature which we miss in the openswan config file.

[Launchpad Janitor (janitor)]

[Expired for openswan (Ubuntu) because there has been no activity for 60 days.]

[AJ Slater (aj-slater)]

This issue persists.

[AJ Slater (aj-slater)]

Though its likely upstream's problem.