<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>Hi Tobias,</span></div><div><br><span></span></div><div><span>Thank you so much for your quick response. It is good to know that there is a reason for charon to</span></div><div><span>know about IKEv1 connections. But the problem I am facing is not over yet.<br></span></div><div><span><br></span></div><div><span>Apparently root cause of my mistaken identity problem is "right=%any". Ordering ikev2 tunnels ahead of</span></div><div><span>ikev1 helped only because there are 2 conns in ipsec.conf. Get rid of pluto conn leave behind only 1 conn <br></span></div><div><span>so there is no chance for confusion. Normally I have 1000 tunnels and they are all</span><span> "right=%any". <br></span></div><div><span>I get the NO_PROPOSAL_CHOSEN problem easily with two IKEv2 conns that have different</span></div><div><span>cipher suites.
E.g. first one use sha1 and second one use md5:<br></span></div><div><br><span></span></div><div><span>conn first</span></div><div><span> left=192.168.3.193</span></div><div><span> right=%any</span></div><div><span> rightid=@1000-1</span></div><div><span> ike=aes128-sha1-modp1536!</span></div><div><span> keyexchange=ikev2<br></span></div><div> ...</div><div><br><span></span></div><div><span>conn second<br></span></div><div><span> left=192.168.3.193</span></div>
<div><span> right=%any</span></div>
<div><span> rightid=@1000-2</span></div>
<div><span> ike=aes128-md5-modp1536!</span></div><div><span> keyexchange=ikev2</span></div><div> ...</div><div><br><span></span></div><div><span>Here is the syslog:</span></div><div><span>charon: 11[NET] received packet: from 192.168.3.195[500] to 192.168.3.193[500]<br>charon: 11[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]<br>charon: 11[CFG] looking for an ike config for 192.168.3.193...192.168.3.195<br>charon: 11[CFG] candidate: 192.168.3.193...%any, prio 5<br>charon: 11[CFG] candidate: 192.168.3.193...%any, prio 5<br>charon: 11[CFG] found matching ike config: 192.168.3.193...%any with prio 5<br>charon: 11[IKE] 192.168.3.195 is initiating an IKE_SA<br>charon: 11[IKE] IKE_SA (unnamed)[3] state change: CREATED => CONNECTING<br>charon: 01[JOB] next event in 29s 999ms, waiting<br>charon: 11[CFG] selecting proposal:<br>charon: 11[CFG] no acceptable
INTEGRITY_ALGORITHM found <br>charon: 11[CFG] received proposals: IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536<br>charon: 11[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536<br>charon: 11[LIB] size of DH secret exponent: 1534 bits<br>charon: 11[IKE] received proposals inacceptable<br>charon: 11[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ] </span></div><div><br><span></span></div><div><span>From the syslog, it would seem once a possible candidate is picked (by their order in ipsec.conf), the proposal</span></div><div><span>selection would not look at the other conns that are also 192.168.3.193...%any. Is this true?</span></div><div>If true, any suggestion how I can get tunnels with different ciphers co-exist? Ideally modify the code to go back and pick another <my_ip>...%any candiate is best for my application. Or perhaps I ban strict mode when right=%any?</div><div>
<br><span></span></div><div><span>Thank you again for your help.</span></div><div><span>Simon</span></div><div><span><br></span></div>
<div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"> <div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight: bold;">From:</span></b> Tobias Brunner <tobias@strongswan.org><br> <b><span style="font-weight: bold;">To:</span></b> Simon Chan <simon.chan3@yahoo.ca> <br><b><span style="font-weight: bold;">Cc:</span></b> "users@lists.strongswan.org" <users@lists.strongswan.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, February 8, 2012 2:35:33 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [strongSwan] NO_PROPOSAL_CHOSEN error when IKEv1 and IKEv2 has closely resemble but not exact suites<br> </font> </div> <br>Hi Simon,<br><br>> Is it possible that charon is searching for matches from pluto's<br>> connections? Why should charon have knowledge
of<br>> pluto's connections?<br><br>Yes, that's exactly what's happening here. By default, charon loads all<br>connections whether they have keyexchange set to ikev2 or not. But it<br>uses IKEv1 connections only as responder (the reason for this was<br>probably to simplify configuration on gateways, as only one config would<br>be necessary). If you don't want this you could apply the attached patch.<br><br>> In another attempt to debug the problem, we arranged the order of the<br>> tunnels in ipsec.conf so that IKEv2 conn is ahead of the IKEv1 conn.<br>> Then connection is established. And the IKEv1 which is now second in<br>> /etc/ipsec.conf still works.<br><br>Yep, that works too, as charon simply uses the first matching connection.<br><br>Regards,<br>Tobias<br><br><br> </div> </div> </div></body></html>