Bug 350281 - IPSec Packet has no Non-ESP marker
IPSec Packet has no Non-ESP marker
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
low Severity high
: ---
: ---
Assigned To: Neil Horman
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-24 07:17 EDT by Alain RICHARD
Modified: 2009-01-20 15:25 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:25:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alain RICHARD 2007-10-24 07:17:09 EDT
Description of problem:

We get on one of our vpn server the following error :

Oct 24 08:09:00 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker
Oct 24 08:09:03 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker
Oct 24 08:09:09 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker
Oct 24 08:09:31 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker
Oct 24 08:09:34 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker
Oct 24 08:09:40 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker
Oct 24 08:09:59 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker
Oct 24 08:10:02 cestiavpn pluto[1099]: packet from 86.212.214.22:4500: recvfrom
86.212.214.22:4500 has no Non-ESP marker

and at the same time the vpn tunnel concerned do not work altough it is up and
running (both phases 1 and 2 are ok).

The problem is a well known problem in kernel ipsec that is triggered when using
e1000 driver and ipsec. It has been corrected in 2.6.19 :

,---[http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.19]-
commit 753eab76a3337863a0d86ce045fa4eb6c3cbeef9
Author: Olaf Kirch <okir@suse.de>
Date:   Wed Nov 22 20:11:42 2006 -0800

    [UDP]: Make udp_encap_rcv use pskb_may_pull
    
    Make udp_encap_rcv use pskb_may_pull
    
    IPsec with NAT-T breaks on some notebooks using the latest e1000 chipset,
    when header split is enabled. When receiving sufficiently large packets, the
    driver puts everything up to and including the UDP header into the header
    portion of the skb, and the rest goes into the paged part. udp_encap_rcv
    forgets to use pskb_may_pull, and fails to decapsulate it. Instead, it
    passes it up it to the IKE daemon.
    
    Signed-off-by: Olaf Kirch <okir@suse.de>
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>


`---

(note that in our case, this is not a notebook, but a Dell 860 with an
additionnal intel ethernet card)

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

kernel-2.6.18-8.1.14.el5

How reproducible:

100% reproductible in our environement (RHEL 5 + kernel 2.6.18-8.1.14.el5 +
openswan + a natted tunnel + intel e1000 driver).


Upgrading to the (non RHEL 5 official) Kernel 2.6.20-1.2320.fc5 correct the
problem as a patch to issue that bug was incorporated in 
kernel 2.6.19.

In order to fix ipsec in natted environement (roadwarriors), you need to
backport this fix in the RHEL5 official kernel.
Comment 2 Neil Horman 2007-11-12 11:10:33 EST
I've placed a test kernel with the backport of this patch here:
http://people.redhat.com/nhorman
could you please test it out and confirm that it solves the problem in your
environment?  Thanks!
Comment 3 RHEL Product and Program Management 2007-11-13 17:25:07 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 4 RHEL Product and Program Management 2008-03-11 15:38:28 EDT
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.
Comment 5 Neil Horman 2008-04-23 15:09:59 EDT
ping, any update here?
Comment 6 RHEL Product and Program Management 2008-04-23 15:10:55 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 7 Neil Horman 2008-06-18 12:43:05 EDT
2nd, ping.  If I don't hear from you in the next few weeks on this, I'll assume
that this patch does fix the problem and move forward with integration
Comment 9 Don Zickus 2008-07-23 14:54:27 EDT
in kernel-2.6.18-99.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 14 errata-xmlrpc 2009-01-20 15:25:15 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-0225.html

Note You need to log in before you can comment on or make changes to this bug.