Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 132832

Summary: ipsec malformed packet in tunnel mode with ah and esp
Product: Red Hat Enterprise Linux 3 Reporter: benoit rovera <benoit.rovera-c>
Component: kernelAssignee: David Miller <davem>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: ckjohnson, petrides, riel
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:18:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ethereal trace of attempted tunnelled connection to a web server
none
Output of setkey -DP none

Description benoit rovera 2004-09-17 16:26:36 UTC 
From Bugzilla Helper:

Description of problem:
Hi,

Thanks to the ipsec backport in the 2.4 kernel, we are using the
ipsec-tools package.

We noticed that in tunnel mode with ah and esp, the packets are malformed.

The packets are like : 
IP header | AH header | IP header | ESP |
and we should get :
IP header | AH header | ESP |

We found a description a similar bug on : 
http://www.ussg.iu.edu/hypermail/linux/kernel/0302.1/1087.html 

Thanks in advance for your help,

Benoit



Version-Release number of selected component (if applicable):
kernel-2.4.21-15.0.3.EL

How reproducible:
Always

Steps to Reproduce:
1.setup an ipsec tunnel with ah and esp between 2 gateway.
    

Actual Results:  The packets are like : 
IP header | AH header | IP header | ESP |

Expected Results:  The packets should be :
IP header | AH header | ESP |

Additional info:
Comment 1 Christopher Johnson 2004-09-27 00:48:38 UTC 
This is also true of FC2 kernel 2.6.8-1.521 for ipsec tunnel mode.  I
have a packet trace and ipsec configuration if that would be helpful.
Furthermore, I have proven with the packet trace that some packets are
misaddressed.  Specifically for a packet of the form:
 IP header1 | AH header | IP header2 | ESP
The IP header1 has an incorrect destination address of the host in the
remote tunneled subnet instead of the remote vpn partner, whereas IP
header2 has the correct destination address of the remote vpn partner.
For an host in local ipsec subnet contacting a web server in remote
ipsec subnet the initial syn and response of syn,ack are tunnelled
successfuly, but the encrypted ack goes out malformed, thus is never
delivered.
Comment 2 Christopher Johnson 2004-09-27 00:52:39 UTC 
Created attachment 104342 [details]
ethereal trace of attempted tunnelled connection to a web server

Packet 11 exhibits the ipsec bug. Note the icmp response in packet 12 from
router due to the mis-addressed packet.
Comment 3 Christopher Johnson 2004-09-27 00:58:00 UTC 
Created attachment 104343 [details]
Output of setkey -DP

Note VPN partner addresses of 169.244.85.2 and 169.244.32.130, and their
tunneled subnet scopes of 10.6.18.0/24 and 192.168.0.0/16 respectively.
Comment 4 RHEL Program Management 2007-10-19 19:18:09 UTC 
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.