[Openswan Users] Not passing the "STATE_QUICK_I1: initiate"

[Oliver Schulze L.]

Many thanks Andy and Paul for answering,
I think I'n getting closer and closer

Looking in the logs, I get this:
$ ipsec barf
...
Nov  5 01:16:01 server01 pluto[7045]: "ipsec01" #1588: initiating Quick 
Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1587}
Nov  5 01:16:01 server01 pluto[7045]: "ipsec01" #1587: ignoring 
informational payload, type NO_PROPOSAL_CHOSEN
Nov  5 01:16:01 server01 pluto[7045]: "ipsec01" #1587: received and 
ignored informational message
Nov  5 01:16:38 server01 pluto[7045]: "ipsec01": terminating SAs using 
this connection
Nov  5 01:16:38 server01 pluto[7045]: "ipsec01" #1588: deleting state 
(STATE_QUICK_I1)
Nov  5 01:16:38 server01 pluto[7045]: "ipsec01" #1587: deleting state 
(STATE_MAIN_I4)

$ ipsec auto --verbose --up ipsec01
...
 031 "ipsec01" #1604: max number of retransmissions (2) reached 
STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: 
perhaps peer likes no proposal
000 "ipsec01" #1604: starting keying attempt 2 of an unlimited number, 
but releasing whack

I think I have a problem with: "NO_PROPOSAL_CHOSEN" or "peer likes no 
proposal"

I will talk to the Cisco guy if he knows something about this.
If I can get this ipsec to start, will write a mini-howto to the wiki ;)

Thanks
Oliver


Paul Wouters wrote:

>On Mon, 7 Nov 2005, Oliver Schulze L. wrote:
>
>  
>
>>{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
>>group=modp1536}
>>002 "ipsec01" #1588: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using
>>isakmp#1587}
>>117 "ipsec01" #1588: STATE_QUICK_I1: initiate
>>010 "ipsec01" #1588: STATE_QUICK_I1: retransmission; will wait 20s for
>>response
>>
>>1. You have set 3DES/MD5 at one end and 3DES/SHA1 at the other, or some
>>similar misconfiguration.
>>    
>>
>
>Can can explicitely set:
>	ike=3des-md5
>	esp=3des-md5
>
>or exchange md5 for sha1 in the above lines
>
>  
>
>>2. Your access lists are set up wrong on the PIX. For example, access-list
>>FREESWAN-VPN permit ip 10.7.3.0 255.255.255.0 10.69.1.0 255.255.255.0 will
>>work, where access-list FREESWAN-VPN permit ip 10.7.3.0 255.255.255.0 host
>>202.0.45.170 while it appears to do to the same thing, will cause problems at
>>this point when the ?
>><http://wiki.openswan.org/index.php/ISAKMP?action=create>_ISAKMP_ phase has
>>finished, and the actual establishing of the tunnel begins.
>>    
>>
>
>For this you will need the logs on the other end. As suggested by Andy, you
>can also try pfs=no.
>
>Paul
>  
>

-- 
Oliver Schulze L.
<oliver at samera.com.py>