[Openswan Users] perhaps peer likes no proposal

simon charles charlessimon at hotmail.com
Wed Nov 26 13:01:38 EST 2008 

Tudor , please check your esp parameters / {right|left}subnet / nat-traversal on the Watchguard. 

> localhost pluto[27033]: "myvpn" #3: max number of retransmissions (2)
reached STATE_QUICK_I1.  No acceptable > > response to our first Quick Mode
message: perhaps peer likes no proposal

  Your connection is failing at STATE_QUICK_I1 - which hints at dis-similar esp parameters / {right|left} subnets or nat traversal issues with some equipments

- Simon Charles - 




Date: Wed, 26 Nov 2008 08:01:30 +0000
From: Tudor.Georgescu at aardman.com
To: users at openswan.org
Subject: Re: [Openswan Users] perhaps peer likes no proposal

RE: [Openswan Users] perhaps peer likes no proposal











Simon, its not a typo, its how you specify your Diffie Hellman group. It uses the same one as the ike, but you can specify. esp=aes256-sha1-modp1024 would report an error, leaving it blank would work exactly the same, getting stuck in the same place.



No matter what I put in esp, it gets stuck in the same place. I change my ike, it complains "Informational Exchange message must be encrypted". Definitely having problems at a later stage. Phase1 and Phase2 protocols at the other end are identical.



Could it be tunnel problems? Or would the tunnel cause it to fail at another stage? What exactly is STATE_AGGR_I2 trying to achieve?



Cheers guys.



-----Original Message-----

From: simon charles [mailto:charlessimon at hotmail.com]

Sent: Wed 11/26/2008 3:08 AM

To: Tudor Georgescu; bzhang at sonicwall.com; users-bounces at openswan.org

Subject: RE: [Openswan Users] perhaps peer likes no proposal





Tudor - is that a typo in esp parameter ? shouldn't it be esp=aes256-sha1-modp1024



conn myvpn



        pfs=yes



        authby=secret



        type=tunnel



        aggrmode=yes



        keyexchange=ike



        auth=esp



        ike=aes256-sha1-modp1024



        esp=aes256-sha1;modp1024



        left=10.0.0.128



        leftsubnet=10.0.0.0/24



        leftnexthop=10.0.0.138



        leftid=my at id.com



        right=<vpn.public.ip>



        #rightnexthop=a.b.c.d



        rightsubnet=w.x.y.z/24



        rightid=<vpn.public.ip>



        auto=start





- Simon Charles -









Subject: RE: [Openswan Users] perhaps peer likes no proposal

Date: Wed, 26 Nov 2008 01:47:13 +0000

From: Tudor.Georgescu at aardman.com

To: bzhang at sonicwall.com; charlessimon at hotmail.com; users-bounces at openswan.org

















RE: [Openswan Users] perhaps peer likes no proposal









Many thanks for the input.







Aaron, the other end has pfs enabled, that is why it was=yes. Setting it to 'no' makes no difference to how far the connection gets.







Simon, the other end is indeed expecting aggressive mode as this is a roadwarrior setup.







Cheers folks,







Tudor











-----Original Message-----



From: Aaron Zhang [mailto:bzhang at sonicwall.com]



Sent: Wed 11/26/2008 1:24 AM



To: simon charles; Tudor Georgescu; users at openswan.org



Subject: RE: [Openswan Users] perhaps peer likes no proposal







I  think the phase1 has been established successfully , so it  does not result from the aggressive mode.







Could you disable the pfs=no and have a try ?















Thanks!







Aaron (Bo) Zhang







________________________________







From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On Behalf Of simon charles



Sent: 2008?11?26? 3:28



To: tudor.georgescu at aardman.com; users at openswan.org



Subject: Re: [Openswan Users] perhaps peer likes no proposal















Hi !



    From the logs - openswan is trying to connect using 'aggressive mode' - is the watchguard expecting to connect using aggresive mode ?. Aggressive mode is less secure than main mode - unless you are using a roadwarrior configuration - i would recommend that you use main mode.



      Thanks !







________________________________







Date: Tue, 25 Nov 2008 17:33:16 +0000



From: Tudor.Georgescu at aardman.com



To: users at openswan.org



Subject: [Openswan Users] perhaps peer likes no proposal







Hey guys,



I have been struggling with this for a few days now. I've become thoroughly stuck on this on what I believe may be phase2.







I am trying to connect openswan-2.6.19 [left] (and openswan-2.6.19 upto the .19 release) to a WatchGuard Firebox [right].







Many releases ago, this was once possible: http://wiki.openswan.org/index.php/Interop/InteroperatingWatchguard







Unfortunately following many tutorials and the Paul and Ken book has still left me in the dark.







I have been on the #openswan irc channel and they suggested that "perhaps peer likes no proposal" means I'm not matching IKE or ESP properly. I've checked, double checked, and thrice checked both ends, but I'm still getting stuck.







Settings-wise what is still a mystery to me is the tunnel settings. On the Watchguard end, its configured to give me the virtual IP of a.b.c.d, which puts me on the network w.x.y.z/24. I've tried various rightnexthop/rightsubnet settings, but that does not appear to make any changes to the connection. Am I barking up the wrong tree? Does the tunnel have anything to do with "perhaps peer likes no proposal"?







Any explinations of what the following means would also be much appreciated. I.e. what is STATE_AGGR_I2 trying to achieve?



localhost pluto[27033]: "myvpn" #1: retransmitting in response to duplicate packet; already STATE_AGGR_I2



localhost pluto[27033]: "myvpn" #1: discarding duplicate packet -- exhausted retransmission; already STATE_AGGR_I2







Thank you in advance guys and gals.







Tudor







# /etc/ipsec.conf - Openswan IPsec configuration file



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







config setup



        interfaces=%defaultroute



        nat_traversal=yes



        OE=off



        protostack=netkey



        uniqueids=yes







conn myvpn



        pfs=yes



        authby=secret



        type=tunnel



        aggrmode=yes



        keyexchange=ike



        auth=esp



        ike=aes256-sha1-modp1024



        esp=aes256-sha1;modp1024



        left=10.0.0.128



        leftsubnet=10.0.0.0/24



        leftnexthop=10.0.0.138



        leftid=my at id.com



        right=<vpn.public.ip>



        #rightnexthop=a.b.c.d



        rightsubnet=w.x.y.z/24



        rightid=<vpn.public.ip>



        auto=start







The output was from rel 2.6.18, but I get the same from 2.6.19.







/var/log/messages







localhost pluto[26477]: shutting down



localhost pluto[26477]: forgetting secrets



localhost pluto[26477]: "myvpn": deleting connection



localhost pluto[26477]: "myvpn" #1: deleting state (STATE_AGGR_I2)



localhost pluto[26477]: "myvpn": request to delete a unrouted policy with netkey kernel --- experimental



localhost pluto[26477]: shutting down interface lo/lo ::1:500



localhost pluto[26477]: shutting down interface lo/lo 127.0.0.1:4500



localhost pluto[26477]: shutting down interface lo/lo 127.0.0.1:500



localhost pluto[26477]: shutting down interface eth0/eth0 10.0.0.128:4500



localhost pluto[26477]: shutting down interface eth0/eth0 10.0.0.128:500



localhost ipsec__plutorun: Starting Pluto subsystem...



localhost pluto[27033]: Starting Pluto (Openswan Version 2.6.18; Vendor ID OE}ZvZ at M[OWD) pid:27033



localhost pluto[27033]: Setting NAT-Traversal port-4500 floating to on



localhost pluto[27033]:    port floating activation criteria nat_t=1/port_float=1



localhost pluto[27033]:    including NAT-Traversal patch (Version 0.6c)



localhost pluto[27033]: using /dev/urandom as source of random entropy



localhost pluto[27033]: ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)



localhost pluto[27033]: ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)



localhost pluto[27033]: ike_alg_register_enc(): Activating OAKLEY_SERPENT_CBC: Ok (ret=0)



localhost pluto[27033]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)



localhost pluto[27033]: ike_alg_register_enc(): Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)



localhost pluto[27033]: ike_alg_register_hash(): Activating OAKLEY_SHA2_512: Ok (ret=0)



localhost pluto[27033]: ike_alg_register_hash(): Activating OAKLEY_SHA2_256: Ok (ret=0)



localhost pluto[27033]: starting up 1 cryptographic helpers



localhost pluto[27034]: using /dev/urandom as source of random entropy



localhost pluto[27033]: started helper pid=27034 (fd:7)



localhost pluto[27033]: Using Linux 2.6 IPsec interface code on 2.6.26.5-28.fc8 (experimental code)



localhost pluto[27033]: ike_alg_register_enc(): WARNING: enc alg=0 not found in constants.c:oakley_enc_names



localhost pluto[27033]: ike_alg_register_enc(): Activating <NULL>: Ok (ret=0)



localhost pluto[27033]: ike_alg_register_enc(): WARNING: enc alg=0 not found in constants.c:oakley_enc_names



localhost pluto[27033]: ike_alg_add(): ERROR: Algorithm already exists



localhost pluto[27033]: ike_alg_register_enc(): Activating <NULL>: FAILED (ret=-17)



localhost pluto[27033]: ike_alg_register_enc(): WARNING: enc alg=0 not found in constants.c:oakley_enc_names



localhost pluto[27033]: ike_alg_add(): ERROR: Algorithm already exists



localhost pluto[27033]: ike_alg_register_enc(): Activating <NULL>: FAILED (ret=-17)



localhost pluto[27033]: ike_alg_register_enc(): WARNING: enc alg=0 not found in constants.c:oakley_enc_names



localhost pluto[27033]: ike_alg_add(): ERROR: Algorithm already exists



localhost pluto[27033]: ike_alg_register_enc(): Activating <NULL>: FAILED (ret=-17)



localhost pluto[27033]: ike_alg_register_enc(): WARNING: enc alg=0 not found in constants.c:oakley_enc_names



localhost pluto[27033]: ike_alg_add(): ERROR: Algorithm already exists



localhost pluto[27033]: ike_alg_register_enc(): Activating <NULL>: FAILED (ret=-17)



localhost pluto[27033]: ike_alg_register_enc(): WARNING: enc alg=0 not found in constants.c:oakley_enc_names



localhost pluto[27033]: ike_alg_add(): ERROR: Algorithm already exists



localhost pluto[27033]: ike_alg_register_enc(): Activating <NULL>: FAILED (ret=-17)



localhost pluto[27033]: Changed path to directory '/etc/ipsec.d/cacerts'



localhost pluto[27033]: Changed path to directory '/etc/ipsec.d/aacerts'



localhost pluto[27033]: Changed path to directory '/etc/ipsec.d/ocspcerts'



localhost pluto[27033]: Changing to directory '/etc/ipsec.d/crls'



localhost pluto[27033]:   Warning: empty directory



localhost pluto[27033]: Changing back to directory '/tmp' failed - (2 No such file or directory)



localhost pluto[27033]: Changing back to directory '/tmp' failed - (2 No such file or directory)



localhost pluto[27033]: added connection description "myvpn"



localhost pluto[27033]: listening for IKE messages



localhost pluto[27033]: adding interface eth0/eth0 10.0.0.128:500



localhost pluto[27033]: adding interface eth0/eth0 10.0.0.128:4500



localhost pluto[27033]: adding interface lo/lo 127.0.0.1:500



localhost pluto[27033]: adding interface lo/lo 127.0.0.1:4500



localhost pluto[27033]: adding interface lo/lo ::1:500



localhost pluto[27033]: loading secrets from "/etc/ipsec.secrets"



localhost pluto[27033]: "myvpn": request to add a prospective erouted policy with netkey kernel --- experimental



localhost pluto[27033]: "myvpn" #1: initiating Aggressive Mode #1, connection "myvpn"



localhost pluto[27033]: | setting sec: 1



localhost pluto[27033]: "myvpn" #1: received Vendor ID payload [Dead Peer Detection]



localhost pluto[27033]: "myvpn" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106



localhost pluto[27033]: "myvpn" #1: Aggressive mode peer ID is ID_IPV4_ADDR: '<vpn.public.ip>'



localhost pluto[27033]: "myvpn" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed



localhost pluto[27033]: "myvpn" #1: Aggressive mode peer ID is ID_IPV4_ADDR: '<vpn.public.ip>'



localhost pluto[27033]: "myvpn" #1: transition from state STATE_AGGR_I1 to state STATE_AGGR_I2



localhost pluto[27033]: "myvpn" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established  {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}



localhost pluto[27033]: "myvpn" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEv2ALLOW {using isakmp#1 msgid:131f6317 proposal=AES(12)_256-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1024}



localhost pluto[27033]: "myvpn" #1: retransmitting in response to duplicate packet; already STATE_AGGR_I2



localhost pluto[27033]: "myvpn" #1: retransmitting in response to duplicate packet; already STATE_AGGR_I2



localhost pluto[27033]: "myvpn" #1: discarding duplicate packet -- exhausted retransmission; already STATE_AGGR_I2



localhost pluto[27033]: "myvpn" #2: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal



localhost pluto[27033]: "myvpn" #2: starting keying attempt 2 of at most 3



Nov 21 18:02:42 localhost pluto[27033]: "myvpn" #3: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEv2ALLOW to replace #2 {using isakmp#1 msgid:bd4d55d2 proposal=AES(12)_256-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1024}



localhost pluto[27033]: "myvpn" #3: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal



localhost pluto[27033]: "myvpn" #3: starting keying attempt 3 of at most 3



localhost pluto[27033]: "myvpn" #4: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEv2ALLOW to replace #3 {using isakmp#1 msgid:947f04f5 proposal=AES(12)_256-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1024}



localhost pluto[27033]: "myvpn" #4: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal







- --------------------------------------------------------------------



http://www.aardman.com







______________________________________________________________________



This message has been checked for all known viruses by the MessageLabs











__________________________________________________________________



This message has been checked for all known viruses by MessageLabs























- --------------------------------------------------------------------



http://www.aardman.com







______________________________________________________________________



This message has been checked for all known viruses by the MessageLabs



__________________________________________________________________

This message has been checked for all known viruses by MessageLabs











- --------------------------------------------------------------------

http://www.aardman.com



______________________________________________________________________

This message has been checked for all known viruses by the MessageLabs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20081126/46fffd2c/attachment-0001.html

More information about the Users mailing list