Bug 442821

Summary: [IPv6-DoD] openswan ikev2 fails with IPv6 and full pluto debug logging
Product: Red Hat Enterprise Linux 5 Reporter: IBM Bug Proxy <bugproxy>
Component: openswanAssignee: Paul Wouters <pwouters>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 5.2CC: herbert.xu, lwang, pwouters, sgrubb, tgraf
Target Milestone: rc   
Target Release: ---   
Hardware: other   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-19 17:01:43 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
Logs from eal3 (responder)
none
Logs from eal5 (initiator) none

Description IBM Bug Proxy 2008-04-17 00:40:27 UTC
---Problem Description---
Openswan IKEv2 negotiation fails when using IPv6 addresses and plutodebug="all"
in ipsec.conf
 
---uname output---
Linux eal5.ltc.austin.ibm.com 2.6.18-88.el5 #1 SMP Tue Apr 1 19:01:20 EDT 2008
i686 i686 i386 GNU/Linux
Linux eal3.ltc.austin.ibm.com 2.6.18-87.el5 #1 SMP Tue Mar 25 17:28:02 EDT 2008
i686 i686 i386 GNU/Linux
 
Machine Type = xSeries 335 
  
---Steps to Reproduce---
---IP Addresses---
eal1: fc00:0:0:105::22/64
eal3: fc00:0:0:105::24/64
/etc/ipsec.conf:
------------------------
# /etc/ipsec.conf - Openswan IPsec configuration file
#
# Manual:     ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        plutodebug="all"
        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
        protostack=netkey
        nat_traversal=yes

conn i386-i386-v6
        left=fc00:0:0:105::22
        right=fc00:0:0:105::24
        ikev2=insist
        authby=secret
        auto=add
------------------------

Steps:
------------------------
[root@eal5 ~]# ipsec auto --verbose --up i386-i386-v6
002 "i386-i386-v6" #1: initiating v2 parent SA
133 "i386-i386-v6" #1: STATE_PARENT_I1: initiate
002 "i386-i386-v6" #1: transition from state STATE_IKEv2_START to state
STATE_PARENT_I1
133 "i386-i386-v6" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "i386-i386-v6" #2: transition from state STATE_PARENT_I1 to state
STATE_PARENT_I2
134 "i386-i386-v6" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2
cipher=aes_128 integ=sha1 prf=oakley_sha group=modp1536}

<ctrl-c>
------------------------

Initiator hangs here and never receives the V2R2.

Removing 'plutodebug="all"' in the ipsec.conf allows for the negotiation to
complete successfully.
 
---Security Component Data---
Userspace tool common name: openswan

The userspace tool has the following bit modes: 32

Userspace rpm: openswan-2.6.11-1

Comment 1 IBM Bug Proxy 2008-04-17 00:40:30 UTC
Created attachment 302685 [details]
Logs from eal3 (responder)

Comment 2 IBM Bug Proxy 2008-04-17 00:40:31 UTC
Created attachment 302686 [details]
Logs from eal5 (initiator)

Comment 3 Paul Wouters 2008-04-22 15:19:17 UTC
plutodebug= only logs additionals data. It should not change the behaviour of
pluto at all (except I guess some timings due to the additional logging).

Are you sure this change is what made it work?

Comment 4 IBM Bug Proxy 2008-04-22 23:09:09 UTC
------- Comment From tchicks.com 2008-04-22 19:01 EDT-------
Hey Paul - Yes, this must be a timing issue.  Turning 'plutodebug="all"' on is
definitely the cause.  I tried watching /var/log/secure on both machines by
doing a 'tail -f /var/log/secure' before I brought up the connection but most of
the time it negotiates successfully while tail'ing the log file.  Does this
somehow speed up the writes while logging???

Also, it doesn't seem to be a problem when using IPv4 addresses.  I admit that
I'm a little confused on this one. :)

Comment 5 RHEL Program Management 2008-06-02 20:05:42 UTC
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 6 IBM Bug Proxy 2008-08-06 15:50:57 UTC
Any progress on this bug?  Setting state to "needinfo."

Comment 7 IBM Bug Proxy 2008-08-13 21:50:54 UTC
I've been trying to reproduce this bug with openswan-2.6.14-1.el5_2.1 and
kernel-2.6.18-92.1.10.el5, but the SA negotiation is always successful when
using these updated versions.  I'm assuming a fix, possibly inadvertent, has
slipped into openswan since the 2.6.11-1 release this bug was originally filed
against.

Comment 8 IBM Bug Proxy 2008-08-13 22:00:40 UTC
Rejecting bug, unreproducible with openswan-2.6.14-1.el5_2.1 and
kernel-2.6.18-92.1.10.el5

No known fix was created, but the bug no longer exists.


Marking bug as CLOSED

Comment 9 Steve Grubb 2008-09-19 17:01:43 UTC
Closing bug since testing seems to indicate its fixed. Please reopen if this turns out to wrong. Thanks.