---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
Created attachment 302685 [details] Logs from eal3 (responder)
Created attachment 302686 [details] Logs from eal5 (initiator)
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 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. :)
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.
Any progress on this bug? Setting state to "needinfo."
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.
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
Closing bug since testing seems to indicate its fixed. Please reopen if this turns out to wrong. Thanks.