Bug 442821 - [IPv6-DoD] openswan ikev2 fails with IPv6 and full pluto debug logging
[IPv6-DoD] openswan ikev2 fails with IPv6 and full pluto debug logging
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openswan (Show other bugs)
5.2
other All
medium Severity low
: rc
: ---
Assigned To: Paul Wouters
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-16 20:40 EDT by IBM Bug Proxy
Modified: 2009-06-19 23:39 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-19 13:01:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs from eal3 (responder) (88.68 KB, text/plain)
2008-04-16 20:40 EDT, IBM Bug Proxy
no flags Details
Logs from eal5 (initiator) (85.40 KB, text/plain)
2008-04-16 20:40 EDT, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 44112 None None None Never

  None (edit)
Description IBM Bug Proxy 2008-04-16 20:40:27 EDT
---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-16 20:40:30 EDT
Created attachment 302685 [details]
Logs from eal3 (responder)
Comment 2 IBM Bug Proxy 2008-04-16 20:40:31 EDT
Created attachment 302686 [details]
Logs from eal5 (initiator)
Comment 3 Paul Wouters 2008-04-22 11:19:17 EDT
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 19:09:09 EDT
------- Comment From tchicks@us.ibm.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 Product and Program Management 2008-06-02 16:05:42 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 6 IBM Bug Proxy 2008-08-06 11:50:57 EDT
Any progress on this bug?  Setting state to "needinfo."
Comment 7 IBM Bug Proxy 2008-08-13 17:50:54 EDT
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 18:00:40 EDT
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 13:01:43 EDT
Closing bug since testing seems to indicate its fixed. Please reopen if this turns out to wrong. Thanks.

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