<div>Hello Andreas,</div>
<div> </div>
<div>Thanks for your analysis..</div>
<div> </div>
<div>Is it fine to have this hack in our system to avoid such eroute error? (dont check for routes_agree() check at all) </div>
<div> </div>
<div>//if (ro != NULL && !routes_agree(ro, c))</div>
<div>if (ro != NULL )<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>Or does any of the strongswan version latest than 4.4.1 solve this issue? Pleas suggest.</div>
<div> </div>
<div> </div>
<div>Thanks,</div>
<div>Swetha</div>
<div> </div>
<div><br><br> </div>
<div class="gmail_quote">On Fri, Feb 25, 2011 at 12:57 AM, 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>sorry for the delay in anwering your post but I had to run some<br>tests first. The IKEv1 pluto daemon is just not able to install<br>
multiple eroutes with the same rightsubnet, in your case <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>.<br>And this even though leftsubnet=left are different for each<br>connection. Only the destination counts.<br>
<br>Regards<br><br>Andreas
<div class="im"><br><br>On 02/22/2011 05:02 AM, Swetha RK wrote:<br></div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">Hello Andreas,<br>Here are the definitions for other connetions:<br>conn conn92<br> type=tunnel<br></div> leftsubnet=<a href="http://10.46.155.211/32" target="_blank">10.46.155.211/32</a> <<a href="http://10.46.155.211/32" target="_blank">http://10.46.155.211/32</a>><br>
rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>>
<div class="im"><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<br>conn conn93<br> type=tunnel<br></div> leftsubnet=<a href="http://10.46.155.219/32" target="_blank">10.46.155.219/32</a> <<a href="http://10.46.155.219/32" target="_blank">http://10.46.155.219/32</a>><br>
rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>>
<div class="im"><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<br>conn conn94<br> type=tunnel<br></div> leftsubnet=<a href="http://10.46.155.227/32" target="_blank">10.46.155.227/32</a> <<a href="http://10.46.155.227/32" target="_blank">http://10.46.155.227/32</a>><br>
rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>>
<div>
<div></div>
<div class="h5"><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<br>Here the left/right subnet are different for each of the connections,<br>you think eroute with different subnet? Is this related to rekeying by<br>any chance? I see this comment in the codebase which i couldnt get much:<br>
<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> }<br>Do you want us to try modifying any configurations?<br>Thanks,<br>Swetha<br><br><br>On Mon, Feb 21, 2011 at 5:08 PM, Andreas Steffen<br>
</div></div><<a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a> <mailto:<a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a>>>
<div class="im"><br>wrote:<br><br> Hello Swetha,<br><br> it would be helpful to also have the definitions of<br> conn92, conn93, and conn94. Which of the parameters<br><br></div> leftsubnet=<a href="http://10.46.155.203/32" target="_blank">10.46.155.203/32</a> <<a href="http://10.46.155.203/32" target="_blank">http://10.46.155.203/32</a>><br>
rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>>
<div class="im"><br> left=10.46.155.203 ( Vlan tunnel endpoint)<br> right=192.168.13.4<br><br> 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><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>
</div> > leftsubnet=<a href="http://10.46.155.203/32" target="_blank">10.46.155.203/32</a> <<a href="http://10.46.155.203/32" target="_blank">http://10.46.155.203/32</a>><br> > rightsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>>
<div class="im"><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"<br> #24:<br> > certificate status unknown"<br> > 18671 WAR 01:06:45 148ms syslogd.c(134) "pluto[2146]:<br>
"conn94" #24:<br> > we require peer to have ID '192.168.13.28', but peer declares<br> > '<a href="mailto:cisco_move_cert@nsn.com" target="_blank">cisco_move_cert@nsn.com</a> <mailto:<a href="mailto:cisco_move_cert@nsn.com" target="_blank">cisco_move_cert@nsn.com</a>>'<br>
</div> <mailto:'<a href="mailto:cisco_move_cert@nsn.com" target="_blank">cisco_move_cert@nsn.com</a> <mailto:<a href="mailto:cisco_move_cert@nsn.com" target="_blank">cisco_move_cert@nsn.com</a>>'>"
<div>
<div></div>
<div class="h5"><br> > 18673 WAR 01:06:45 148ms syslogd.c(134) "pluto[2146]:<br> "conn94" #24:<br> > ISAKMP SA established"<br> > 18675 WAR 01:06:45 149ms syslogd.c(134) "pluto[2146]:<br>
"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]:<br> "conn94" #25:<br> > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
> 18679 WAR 01:06:45 152ms syslogd.c(134) "pluto[2146]:<br> "conn94" #25:<br> > You should NOT use insecure ESP algorithms [NULL (0)]!"<br> > 18681 WAR 01:06:45 153ms syslogd.c(134) "pluto[2146]:<br>
"conn94" #25:<br> > cannot route -- route already in use for "conn91""<br> > 18724 WAR 01:06:50 153ms syslogd.c(134) "pluto[2146]:<br> "conn94" #25:<br> > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
> 18726 WAR 01:06:50 154ms syslogd.c(134) "pluto[2146]:<br> "conn94" #25:<br> > You should NOT use insecure ESP algorithms [NULL (0)]!"<br> > 18728 WAR 01:06:50 154ms syslogd.c(134) "pluto[2146]:<br>
"conn94" #25:<br> > cannot route -- route already in use for "conn91""<br> > 18843 WAR 01:07:09 843ms syslogd.c(134) "pluto[2146]:<br> "conn93" #22:<br> > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
> 18845 WAR 01:07:09 845ms syslogd.c(134) "pluto[2146]:<br> "conn93" #22:<br> > You should NOT use insecure ESP algorithms [NULL (0)]!"<br> > 18847 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]:<br>
"conn93" #22:<br> > cannot route -- route already in use for "conn91""<br> > 18849 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]:<br> "conn92" #23:<br> > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br>
> 18851 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]:<br> "conn92" #23:<br> > You should NOT use insecure ESP algorithms [NULL (0)]!"<br> > 18853 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]:<br>
"conn92" #23:<br> > cannot route -- route already in use for "conn91""<br> > 18871 WAR 01:07:14 226ms syslogd.c(134) "pluto[2146]:<br> "conn93" #21:<br> > received Delete SA payload: deleting ISAKMP State #21"<br>
> 18873 WAR 01:07:14 228ms syslogd.c(134) "pluto[2146]:<br> "conn92" #20:<br> > received Delete SA payload: deleting ISAKMP State #20"<br> > 18890 WAR 01:07:15 222ms syslogd.c(134) "pluto[2146]:<br>
"conn94" #25:<br> > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME"<br> > 18892 WAR 01:07:15 223ms syslogd.c(134) "pluto[2146]:<br> "conn94" #25:<br> > You should NOT use insecure ESP algorithms [NULL (0)]!"<br>
> 18894 WAR 01:07:15 223ms syslogd.c(134) "pluto[2146]:<br> "conn94" #25:<br> > cannot route -- route already in use for "conn91""<br> > 18917 WAR 01:07:19 228ms syslogd.c(134) "pluto[2146]:<br>
"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" target="_blank">esp.16012697@192.168.13.4</a><br>
<mailto:<a href="mailto:esp.16012697@192.168.13.4" target="_blank">esp.16012697@192.168.13.4</a>><br> > <mailto:<a href="mailto:esp.16012697@192.168.13.4" target="_blank">esp.16012697@192.168.13.4</a><br>
<mailto:<a href="mailto:esp.16012697@192.168.13.4" target="_blank">esp.16012697@192.168.13.4</a>>> (0 bytes)<br> <a href="mailto:esp.fdb38409@10.46.155.203" target="_blank">esp.fdb38409@10.46.155.203</a> <mailto:<a href="mailto:esp.fdb38409@10.46.155.203" target="_blank">esp.fdb38409@10.46.155.203</a>><br>
> <mailto:<a href="mailto:esp.fdb38409@10.46.155.203" target="_blank">esp.fdb38409@10.46.155.203</a><br> <mailto:<a href="mailto:esp.fdb38409@10.46.155.203" target="_blank">esp.fdb38409@10.46.155.203</a>>> (896 bytes, 34s ago); tunnel<br>
> 000 #1: "conn91" STATE_MAIN_I4 (ISAKMP SA established);<br> 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></div></blockquote>
<div>
<div></div>
<div class="h5">======================================================================<br>Andreas Steffen <a href="mailto:andreas.steffen@strongswan.org" target="_blank">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></div></div></blockquote></div><br>