Bug 132832 - ipsec malformed packet in tunnel mode with ah and esp
Summary: ipsec malformed packet in tunnel mode with ah and esp
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: David Miller
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-17 16:26 UTC by benoit rovera
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:18:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ethereal trace of attempted tunnelled connection to a web server (4.69 KB, application/octet-stream)
2004-09-27 00:52 UTC, Christopher Johnson
no flags Details
Output of setkey -DP (1.56 KB, text/plain)
2004-09-27 00:58 UTC, Christopher Johnson
no flags Details

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

Description of problem:

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 : 

Thanks in advance for your help,


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

How reproducible:

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

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 and, and their
tunneled subnet scopes of and respectively.

Comment 4 RHEL Product and 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:
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.

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