[Openswan Users] pluto segfaults when using SHA2 256 hash

[Abhinav Bhagwat]

Thanks Paul. That works. However, I see another issue. If I connect two linux boxes it works fine. Simiarly if I connect two windows boxes, it works fine. However, if I try to connect to a windows 2K8 box to a linux box, it does not work. Phase 1 and phase 2 SAs are both successfully established. But, when I telnet to windows box, the ESP packet reaches the windows box but there is not reply back. If I replace sha256 with sha1, it all works fine.



commands on windows to setup main mode and quick mode:

C:\Users\Administrator>netsh advfirewall mainmode add rule name="test" endpoint1=10.1.3.18 endpoint2=any enable=yes profile=any type=static auth1=computerpsk auth1psk=secret mmsecmethods=dhgroup2:aes128-sha256

C:\Users\Administrator>netsh advfirewall consec add rule name="test" endpoint1=10.1.3.18 endpoint2=any action=requireinrequireout mode=transport enable=yes profile=any type=static protocol=tcp interfacetype=any auth1=computerpsk auth1psk=secret qmpfs=dhgroup2 qmsecmethods=esp:sha256-aes128 port1=any port2=23

On linux, ipsec.conf:-
conn test
        type=transport
        right=10.1.3.18
        rightprotoport=tcp/any
        left=10.1.2.48
        leftprotoport=tcp/23
        pfs=yes
        phase2=esp
        phase2alg=aes128-sha2_256;modp1024
        ike=aes128-sha2_256;modp1024
        authby=secret
        auto=add

Output of ipsec auto --up test

104 "test" #1: STATE_MAIN_I1: initiate
003 "test" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
003 "test" #1: received Vendor ID payload [RFC 3947] method set to=109 
003 "test" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
003 "test" #1: ignoring Vendor ID payload [FRAGMENTATION]
003 "test" #1: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
003 "test" #1: ignoring Vendor ID payload [IKE CGA version 1]
106 "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "test" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
108 "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "test" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=OAKLEY_SHA2_256 group=modp1024}
117 "test" #2: STATE_QUICK_I1: initiate
003 "test" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME msgid=26808dab
004 "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP=>0xd7189d14 <0xf75f4f17 xfrm=AES_128-HMAC_SHA2_256 NATOA=none NATD=none DPD=none}
104 "test" #1: STATE_MAIN_I1: initiate
003 "test" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
003 "test" #1: received Vendor ID payload [RFC 3947] method set to=109 
003 "test" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
003 "test" #1: ignoring Vendor ID payload [FRAGMENTATION]
003 "test" #1: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
003 "test" #1: ignoring Vendor ID payload [IKE CGA version 1]
106 "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "test" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
108 "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "test" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=OAKLEY_SHA2_256 group=modp1024}
117 "test" #2: STATE_QUICK_I1: initiate
003 "test" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME msgid=bb7a6e24
004 "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP=>0x0bbe8772 <0x4a76db0b xfrm=AES_128-HMAC_SHA2_256 NATOA=none NATD=none DPD=none}

Is this a known issue? Is there any solution for this?
 
 

________________________________
 Sent: Thursday, February 2, 2012 8:18 PM
Subject: Re: [Openswan Users] pluto segfaults when using SHA2 256 hash
 
On Wed, 1 Feb 2012, Abhinav Bhagwat wrote:

> Hi when I use sha2 hash to connect using openswan 2.6.37 the pluto daemon
> seg faults with a message 

> Am I missing something here or this is a bug?

It's a fixed bug, but we haven't had a release yet to fix it.

If you recompile with USE_EXTRACRYPTO=true set it will work properly.
Otherwise, see:

http://git.openswan.org/cgi-bin/cgit/openswan/commit/?id=33aea96b36ff282f64bc9cc2a69f89ffa908826c
http://git.openswan.org/cgi-bin/cgit/openswan/commit/?id=d9c6bad2e2ab5bdafc07cb948c8af85711076f67
http://git.openswan.org/cgi-bin/cgit/openswan/commit/?id=3203cd13660e0e5f09c83fb4343cf784a42c6192

We will try to get a release out next week.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20120202/d44c0f1e/attachment-0001.html>