<div>Hello Andreas,</div>
<div> </div>
<div>Here are the definitions for other connetions:</div>
<div> </div>
<div>conn conn92<br>  type=tunnel<br>  leftsubnet=<a href="http://10.46.155.211/32">10.46.155.211/32</a><br>  rightsubnet=<a href="http://0.0.0.0/0">0.0.0.0/0</a><br>  left=10.46.155.211<br>  right=192.168.13.12<br>  keyexchange=ikev1<br>
  ike=aes128-sha1-modp1024!<br>  ikelifetime=85992s<br>  esp=null-sha1!<br>  authby=pubkey<br>  rightid=%any<br>  keylife=86400s<br>  dpdaction=restart<br>  dpddelay=300<br>  dpdtimeout=120</div>
<div> </div>
<div>conn conn93<br>  type=tunnel<br>  leftsubnet=<a href="http://10.46.155.219/32">10.46.155.219/32</a><br>  rightsubnet=<a href="http://0.0.0.0/0">0.0.0.0/0</a><br>  left=10.46.155.219<br>  right=192.168.13.20<br>  keyexchange=ikev1<br>
  ike=aes128-sha1-modp1024!<br>  ikelifetime=85992s<br>  esp=null-sha1!<br>  authby=pubkey<br>  rightid=%any<br>  keylife=86400s<br>  dpdaction=restart<br>  dpddelay=300<br>  dpdtimeout=120</div>
<div> </div>
<div>conn conn94<br>  type=tunnel<br>  leftsubnet=<a href="http://10.46.155.227/32">10.46.155.227/32</a><br>  rightsubnet=<a href="http://0.0.0.0/0">0.0.0.0/0</a><br>  left=10.46.155.227<br>  right=192.168.13.28<br>  keyexchange=ikev1<br>
  ike=aes128-sha1-modp1024!<br>  ikelifetime=85992s<br>  esp=null-sha1!<br>  authby=pubkey<br>  rightid=%any<br>  keylife=86400s<br>  dpdaction=restart<br>  dpddelay=300<br>  dpdtimeout=120</div>
<div> </div>
<div>Here the left/right subnet are different for each of the connections, you think eroute with different subnet? Is this related to rekeying by any chance? I see this comment in the codebase which i couldnt get much:</div>

<div> </div>
<div><br> /* If there is already a route for peer's client subnet<br>  * and it disagrees about interface or nexthop, we cannot steal it.<br>  * Note: if this connection is already routed (perhaps for another<br>  * state object), the route will agree.<br>
  * This is as it should be -- it will arise during rekeying.<br>  */<br> if (ro != NULL && !routes_agree(ro, c))<br> {<br>  loglog(RC_LOG_SERIOUS, "cannot route -- route already in use for \"%s\""<br>
   , ro->name);<br>  return route_impossible;  /* another connection already<br>          using the eroute */<br> }</div>
<div> </div>
<div>Do you want us to try modifying any configurations? </div>
<div> </div>
<div> </div>
<div>Thanks,</div>
<div>Swetha</div>
<div> </div>
<div> </div>
<div><br><br> </div>
<div class="gmail_quote">On Mon, Feb 21, 2011 at 5:08 PM, Andreas Steffen <span dir="ltr"><<a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.org</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hello Swetha,<br><br>it would be helpful to also have the definitions of<br>conn92, conn93, and conn94. Which of the parameters<br>

<div class="im"><br>  leftsubnet=<a href="http://10.46.155.203/32" target="_blank">10.46.155.203/32</a><br>  rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>  left=10.46.155.203  ( Vlan tunnel endpoint)<br>
  right=192.168.13.4<br><br></div>are different? Your log shows an erouting problem.<br>This means that an IPsec policy can only be installed<br>for the conn91 tunnel. For the remaining three tunnels<br>Quick Mode fails because no eroute could be installed.<br>
<br>Regards<br><br>Andreas<br>
<div>
<div></div>
<div class="h5"><br>On 21.02.2011 05:17, Swetha RK wrote:<br>> Hi,<br>><br>> I'm using strongswan version 4.4.1 & I have 4 IKEV1 Host-to-any<br>> connections with each as the below configurations:<br>
><br>> conn conn91<br>>   type=tunnel<br>>   leftsubnet=<a href="http://10.46.155.203/32" target="_blank">10.46.155.203/32</a><br>>   rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>
>   left=10.46.155.203  ( Vlan tunnel endpoint)<br>>   right=192.168.13.4<br>>   keyexchange=ikev1<br>>   ike=aes128-sha1-modp1024!<br>>   ikelifetime=85992s<br>>   esp=null-sha1!<br>>   authby=pubkey<br>
>   rightid=%any<br>>   keylife=86400s<br>>   dpdaction=restart<br>>   dpddelay=300<br>>   dpdtimeout=120<br>><br>> conn conn92<br>> ......<br>><br>> conn conn93<br>> ......<br>><br>> conn conn94<br>
> .......<br>><br>> I see that the first connections 94,93, 92 are established & while<br>> for connections 91 fails with this error:<br>><br>>    18669 WAR 01:06:45 140ms syslogd.c(134) "pluto[2146]: "conn94" #24:<br>
> certificate status unknown"<br>>     18671 WAR 01:06:45 148ms syslogd.c(134) "pluto[2146]: "conn94" #24:<br>> we require peer to have ID '192.168.13.28', but peer declares<br></div></div>
> '<a href="mailto:cisco_move_cert@nsn.com">cisco_move_cert@nsn.com</a>' <mailto:'<a href="mailto:cisco_move_cert@nsn.com">cisco_move_cert@nsn.com</a>'>"<br>
<div>
<div></div>
<div class="h5">>     18673 WAR 01:06:45 148ms syslogd.c(134) "pluto[2146]: "conn94" #24:<br>> ISAKMP SA established"<br>>     18675 WAR 01:06:45 149ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>
> initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+UP {using isakmp#24}"<br>>     18677 WAR 01:06:45 152ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>> ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
>     18679 WAR 01:06:45 152ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>> You should NOT use insecure ESP algorithms [NULL (0)]!"<br>>     18681 WAR 01:06:45 153ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>
> cannot route -- route already in use for "conn91""<br>>     18724 WAR 01:06:50 153ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>> ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
>     18726 WAR 01:06:50 154ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>> You should NOT use insecure ESP algorithms [NULL (0)]!"<br>>     18728 WAR 01:06:50 154ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>
> cannot route -- route already in use for "conn91""<br>>     18843 WAR 01:07:09 843ms syslogd.c(134) "pluto[2146]: "conn93" #22:<br>> ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
>     18845 WAR 01:07:09 845ms syslogd.c(134) "pluto[2146]: "conn93" #22:<br>> You should NOT use insecure ESP algorithms [NULL (0)]!"<br>>     18847 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: "conn93" #22:<br>
> cannot route -- route already in use for "conn91""<br>>     18849 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: "conn92" #23:<br>> ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
>     18851 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: "conn92" #23:<br>> You should NOT use insecure ESP algorithms [NULL (0)]!"<br>>     18853 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: "conn92" #23:<br>
> cannot route -- route already in use for "conn91""<br>>     18871 WAR 01:07:14 226ms syslogd.c(134) "pluto[2146]: "conn93" #21:<br>> received Delete SA payload: deleting ISAKMP State #21"<br>
>     18873 WAR 01:07:14 228ms syslogd.c(134) "pluto[2146]: "conn92" #20:<br>> received Delete SA payload: deleting ISAKMP State #20"<br>>     18890 WAR 01:07:15 222ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>
> ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>>     18892 WAR 01:07:15 223ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>> You should NOT use insecure ESP algorithms [NULL (0)]!"<br>
>     18894 WAR 01:07:15 223ms syslogd.c(134) "pluto[2146]: "conn94" #25:<br>> cannot route -- route already in use for "conn91""<br>>     18917 WAR 01:07:19 228ms syslogd.c(134) "pluto[2146]: "conn94" #24:<br>
> received Delete SA payload: deleting ISAKMP State #24"<br>><br>> I see that the SA's are getting deleted & re-establish each time with<br>> this error.  This is the ipsec status:<br>><br>> 000<br>
> 000 #4: "conn91" STATE_QUICK_I2 (sent QI2, IPsec SA established);<br>> EVENT_SA_REPLACE in 85133s; newest IPSEC; eroute owner<br>> 000 #4: "conn91" <a href="mailto:esp.16012697@192.168.13.4">esp.16012697@192.168.13.4</a><br>
</div></div>> <mailto:<a href="mailto:esp.16012697@192.168.13.4">esp.16012697@192.168.13.4</a>> (0 bytes) <a href="mailto:esp.fdb38409@10.46.155.203">esp.fdb38409@10.46.155.203</a><br>> <mailto:<a href="mailto:esp.fdb38409@10.46.155.203">esp.fdb38409@10.46.155.203</a>> (896 bytes, 34s ago); tunnel<br>

<div class="im">> 000 #1: "conn91" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE<br>> in 84701s; newest ISAKMP; DPD active<br>> 000 #28: "conn92" STATE_QUICK_I1 (sent QI1, expecting QR1);<br>
> EVENT_RETRANSMIT in 14s<br>> 000 #26: "conn92" STATE_MAIN_I4 (ISAKMP SA established);<br>> EVENT_SA_REPLACE in 84922s; newest ISAKMP; DPD active<br>> 000 #29: "conn93" STATE_QUICK_I1 (sent QI1, expecting QR1);<br>
> EVENT_RETRANSMIT in 14s<br>> 000 #27: "conn93" STATE_MAIN_I4 (ISAKMP SA established);<br>> EVENT_SA_REPLACE in 84942s; newest ISAKMP; DPD active<br>> 000 #31: "conn94" STATE_QUICK_I1 (sent QI1, expecting QR1);<br>
> EVENT_RETRANSMIT in 0s<br>> 000 #30: "conn94" STATE_MAIN_I4 (ISAKMP SA established);<br>> EVENT_SA_REPLACE in 85099s; newest ISAKMP; DPD active<br>> 000<br>><br>> This is happening only in IKEV1 with more than 3 connections. Please<br>
> suggest.<br>><br>> Thanks,<br>> Swetha<br><br></div>======================================================================<br><font color="#888888">Andreas Steffen                         <a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.org</a><br>
strongSwan - the Linux VPN Solution!                <a href="http://www.strongswan.org/" target="_blank">www.strongswan.org</a><br>Institute for Internet Technologies and Applications<br>University of Applied Sciences Rapperswil<br>
CH-8640 Rapperswil (Switzerland)<br>===========================================================[ITA-HSR]==<br></font></blockquote></div><br>