Bug 132832 - ipsec malformed packet in tunnel mode with ah and esp
Summary: ipsec malformed packet in tunnel mode with ah and esp
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Miller
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2007-10-19 19:18:09 UTC
Target Upstream Version:
Embargoed:


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:
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.


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