RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1163422 - L2TP tunnels no longer work after openswan upgrade
Summary: L2TP tunnels no longer work after openswan upgrade
Keywords:
Status: CLOSED DUPLICATE of bug 1114683
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-12 16:45 UTC by MikeH
Modified: 2016-04-08 06:43 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-07 20:51:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
ignore isakmp_next_sak as it is (ab)used by OSX for NAT-T payload (666 bytes, patch)
2014-11-25 17:02 UTC, Paul Wouters 		no flags Details | Diff
View All

Description MikeH 2014-11-12 16:45:09 UTC 
Description of problem:

The upgrade from openswan-2.6.32-27.2.el6_5.i686 to openswan-2.6.32-27.4.el6_5.i686 appears to have broken L2TP tunnels (at least in my configuration) from a Mac OS X VPN client.  I upgraded to the latest openswan (openswan-2.6.32-37.el6.i686), but that has the same issue.  I upgraded from Red Hat 6.5 to 6.6, but that also has the same problem.  Prior to upgrading to 6.6, I downgraded to openswan-2.6.32-27.2.el6_5.i686 and I was able to establish L2TP tunnels with the client; upgrade to openswan-2.6.32-27.4.el6_5.i686 and the tunnels don't work and I get this error in /var/log/secure:

Nov 12 11:20:25 <HOST> pluto[1538]: "l2tp-psk"[1] <IP> #11: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_SAK) at the outermost level

From what I can tell, this difference seems related to the fix for BZ 1070356.

Site-to-site IPSEC tunnels work fine (and I only use L2TP tunnels occasionally, which is why I didn't see this issue for some time).

Version-Release number of selected component (if applicable):

openswan-2.6.32-27.4.el6_5.i686 is the first release that exhibits the problem.

How reproducible:

Always.

Steps to Reproduce:
1. Use Mac OS X VPN client to connect to Linux VPN using L2TP

Actual results:

After a minute or so, the Mac OS X client reports "The L2TP-VPN server did not respond..." and this error appears in /var/log/secure:

Nov 12 11:20:25 <HOST> pluto[1538]: "l2tp-psk"[1] <IP> #11: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_SAK) at the outermost level


Expected results:

L2TP VPN tunnel established (as it had been prior to openswan-2.6.32-27.4.el6_5.i686 being installed).

Additional info:

Googling around seemed to indicate that others have had similar problems, but mostly on Debian (see https://bugs.launchpad.net/raspbian/+bug/1304674 where a proposed patch is given).  I didn't see anything on the openswan mailing list (and tried to post there, but it looks defunct).

l2tp-psk config looks like:

conn l2tp-psk
	authby=secret
	pfs=no
	auto=add
	rekey=no
	type=transport
	left=<IP-address-goes-here>
	leftprotoport=17/%any
	right=%any
	rightprotoport=17/%any
	rightsubnet=vhost:%priv,%no
Comment 2 Paul Wouters 2014-11-12 23:33:48 UTC 
For reference, could you try this with libreswan-3.12 ? Upstream has signed rpms at download.libreswan.org/binaries/ 

ISAKMP_NEXT_SAK has the value that used to be assigned a LONG time ago to the NAT-T drafts. We called it BAD_NAT_DRAFTS. Support for it was removed and then re-added. It seems that perhaps openswan is missing part of a backport for this.
Comment 3 MikeH 2014-11-15 14:35:22 UTC 
I tried it with libreswan-3.12 (though I had to use rpm --nodeps to remove openswan because I have a package that depends on it -- any way around that?) and it worked just fine (i.e., IPSEC tunnels were established and an L2TP connection from Mac OS X worked).  I've re-installed openswan (so my RPM database isn't corrupted) and will await an updated openswan version.

Thanks!
Comment 4 Paul Wouters 2014-11-25 17:02:43 UTC 
Created attachment 961301 [details]
ignore isakmp_next_sak as it is (ab)used by OSX for NAT-T payload
Comment 5 Paul Wouters 2014-11-25 17:59:46 UTC 
I created a scratch build for you to test:

ftp://ftp.nohats.ca/openswan-2.6.32-37.el6_6.i686.rpm

Let me know if that fixes your issue?
Comment 6 MikeH 2014-11-25 18:10:56 UTC 
Thanks, but unfortunately that hasn't solved the issue.  I now see:

...
Nov 25 13:07:41 <HOST> pluto[12472]: "l2tp-psk"[1] <IP> #10: message with unsupported payload ISAKMP_NEXT_SAK (as ISAKMP_NEXT_NATD_BADDRAFTS) ignored
Nov 25 13:07:41 <HOST> pluto[12472]: "l2tp-psk"[1] <IP> #10: ASSERTION FAILED at /builddir/build/BUILD/openswan-2.6.32/programs/pluto/ikev1.c:1782: sd != NULL
...

I'm guessing that assertion failure is a deal breaker (the Mac OS X client fails to connect).
Comment 7 Petr_P 2014-12-09 03:51:00 UTC 
The iphones and ipads are unable to connect too. Please try to solve this as soon as possible. Thanks a lot.
Comment 8 Vincent S. Cojot 2014-12-14 21:40:34 UTC 
Hi,
I started digging into VPN's on EL6.6 just a few weeks ago.
After struggling to work with OSX clients, I found this thread and I can confirm that the openswan downgrade makes it work (been trying for days).

Here's more information:

- RHEL6.6, fully patched (as of 2014/12/12).
sure enough, with the latest openswan rpm ( openswan-2.6.32-37.el6 ), OSX clients cannot connect and I see this in pluto.log:

"L2TP-PSK-noNAT"[2] A.B.C.D #3: sending notification INVALID_PAYLOAD_TYPE to X.Y.Z.D:500
"L2TP-PSK-noNAT"[2] A.B.C.D #3: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_SAK) at the outermost level

- Workaround:
yum_rhel.sh downgrade -y openswan-2.6.32-27.2.el6_5

@RH: Should we open a case with RH support?

NB: Android phones can connect just fine with either version.
Comment 9 Vincent S. Cojot 2014-12-15 22:12:16 UTC 
@MikeH: I stumbled on this debian-related discussion where a simple patch was provided:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744717

I'm currently rebuilding the latest RH rpm with that patch and I'll see how it goes..

I've posted my rpms there:
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/i386
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/i386/openswan-2.6.32-37.1.el6.i686.rpm
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/i386/openswan-debuginfo-2.6.32-37.1.el6.i686.rpm
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/i386/openswan-doc-2.6.32-37.1.el6.i686.rpm
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/noarch
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/SRPMS
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/SRPMS/openswan-2.6.32-37.1.el6.src.rpm
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/x86_64
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/x86_64/openswan-2.6.32-37.1.el6.x86_64.rpm
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/x86_64/openswan-debuginfo-2.6.32-37.1.el6.x86_64.rpm
http://step.polymtl.ca/~coyote/dist/openswan/openswan-2.6.32/RHEL6/x86_64/openswan-doc-2.6.32-37.1.el6.x86_64.rpm

I can only test this later as I don't have an OSX box handy today..
Regards,

Vincent
Comment 10 MikeH 2014-12-17 16:09:29 UTC 
@Vincent: I downloaded and tested the RPM that you built and verified that an L2TP tunnel can be established from OSX.  Thanks.
Comment 11 MikeH 2015-01-13 18:23:57 UTC 
Any chance we can get that patch into an official release?

Thanks,

Mike.
Comment 12 Kenneth Heal 2015-11-07 10:07:12 UTC 
Have also faced the same issue with CentOS 6.7 and Max OS X 10.11.1.
Vincents rpm fixed the issue -- many thanks for this.
I'd also like to voice my support for bringing this change into the standard release as I fear many other admins will be sent grey by this issue otherwise.
Comment 15 Paul Wouters 2016-04-07 20:51:25 UTC 
this was merged in via a revised #1114683

*** This bug has been marked as a duplicate of bug 1114683 ***
Comment 16 Kenneth Heal 2016-04-08 06:43:29 UTC 
The errata provided package has the bug described here.
It is thus not a fix for this issue.
Note You need to log in before you can comment on or make changes to this bug.