Hello Swetha, sorry for the delay in anwering your post but I had to run some tests first. The IKEv1 pluto daemon is just not able to install multiple eroutes with the same rightsubnet, in your case 0.0.0.0/0. And this even though leftsubnet=left are different for each connection. Only the destination counts.
Regards Andreas On 02/22/2011 05:02 AM, Swetha RK wrote: > Hello Andreas, > Here are the definitions for other connetions: > conn conn92 > type=tunnel > leftsubnet=10.46.155.211/32 <http://10.46.155.211/32> > rightsubnet=0.0.0.0/0 <http://0.0.0.0/0> > left=10.46.155.211 > right=192.168.13.12 > keyexchange=ikev1 > ike=aes128-sha1-modp1024! > ikelifetime=85992s > esp=null-sha1! > authby=pubkey > rightid=%any > keylife=86400s > dpdaction=restart > dpddelay=300 > dpdtimeout=120 > conn conn93 > type=tunnel > leftsubnet=10.46.155.219/32 <http://10.46.155.219/32> > rightsubnet=0.0.0.0/0 <http://0.0.0.0/0> > left=10.46.155.219 > right=192.168.13.20 > keyexchange=ikev1 > ike=aes128-sha1-modp1024! > ikelifetime=85992s > esp=null-sha1! > authby=pubkey > rightid=%any > keylife=86400s > dpdaction=restart > dpddelay=300 > dpdtimeout=120 > conn conn94 > type=tunnel > leftsubnet=10.46.155.227/32 <http://10.46.155.227/32> > rightsubnet=0.0.0.0/0 <http://0.0.0.0/0> > left=10.46.155.227 > right=192.168.13.28 > keyexchange=ikev1 > ike=aes128-sha1-modp1024! > ikelifetime=85992s > esp=null-sha1! > authby=pubkey > rightid=%any > keylife=86400s > dpdaction=restart > dpddelay=300 > dpdtimeout=120 > 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: > > /* If there is already a route for peer's client subnet > * and it disagrees about interface or nexthop, we cannot steal it. > * Note: if this connection is already routed (perhaps for another > * state object), the route will agree. > * This is as it should be -- it will arise during rekeying. > */ > if (ro != NULL && !routes_agree(ro, c)) > { > loglog(RC_LOG_SERIOUS, "cannot route -- route already in use for \"%s\"" > , ro->name); > return route_impossible; /* another connection already > using the eroute */ > } > Do you want us to try modifying any configurations? > Thanks, > Swetha > > > On Mon, Feb 21, 2011 at 5:08 PM, Andreas Steffen > <[email protected] <mailto:[email protected]>> > wrote: > > Hello Swetha, > > it would be helpful to also have the definitions of > conn92, conn93, and conn94. Which of the parameters > > leftsubnet=10.46.155.203/32 <http://10.46.155.203/32> > rightsubnet=0.0.0.0/0 <http://0.0.0.0/0> > left=10.46.155.203 ( Vlan tunnel endpoint) > right=192.168.13.4 > > are different? Your log shows an erouting problem. > This means that an IPsec policy can only be installed > for the conn91 tunnel. For the remaining three tunnels > Quick Mode fails because no eroute could be installed. > > Regards > > Andreas > > On 21.02.2011 05:17, Swetha RK wrote: > > Hi, > > > > I'm using strongswan version 4.4.1 & I have 4 IKEV1 Host-to-any > > connections with each as the below configurations: > > > > conn conn91 > > type=tunnel > > leftsubnet=10.46.155.203/32 <http://10.46.155.203/32> > > rightsubnet=0.0.0.0/0 <http://0.0.0.0/0> > > left=10.46.155.203 ( Vlan tunnel endpoint) > > right=192.168.13.4 > > keyexchange=ikev1 > > ike=aes128-sha1-modp1024! > > ikelifetime=85992s > > esp=null-sha1! > > authby=pubkey > > rightid=%any > > keylife=86400s > > dpdaction=restart > > dpddelay=300 > > dpdtimeout=120 > > > > conn conn92 > > ...... > > > > conn conn93 > > ...... > > > > conn conn94 > > ....... > > > > I see that the first connections 94,93, 92 are established & while > > for connections 91 fails with this error: > > > > 18669 WAR 01:06:45 140ms syslogd.c(134) "pluto[2146]: "conn94" > #24: > > certificate status unknown" > > 18671 WAR 01:06:45 148ms syslogd.c(134) "pluto[2146]: > "conn94" #24: > > we require peer to have ID '192.168.13.28', but peer declares > > '[email protected] <mailto:[email protected]>' > <mailto:'[email protected] <mailto:[email protected]>'>" > > 18673 WAR 01:06:45 148ms syslogd.c(134) "pluto[2146]: > "conn94" #24: > > ISAKMP SA established" > > 18675 WAR 01:06:45 149ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+UP {using isakmp#24}" > > 18677 WAR 01:06:45 152ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME" > > 18679 WAR 01:06:45 152ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > You should NOT use insecure ESP algorithms [NULL (0)]!" > > 18681 WAR 01:06:45 153ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > cannot route -- route already in use for "conn91"" > > 18724 WAR 01:06:50 153ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME" > > 18726 WAR 01:06:50 154ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > You should NOT use insecure ESP algorithms [NULL (0)]!" > > 18728 WAR 01:06:50 154ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > cannot route -- route already in use for "conn91"" > > 18843 WAR 01:07:09 843ms syslogd.c(134) "pluto[2146]: > "conn93" #22: > > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME" > > 18845 WAR 01:07:09 845ms syslogd.c(134) "pluto[2146]: > "conn93" #22: > > You should NOT use insecure ESP algorithms [NULL (0)]!" > > 18847 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: > "conn93" #22: > > cannot route -- route already in use for "conn91"" > > 18849 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: > "conn92" #23: > > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME" > > 18851 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: > "conn92" #23: > > You should NOT use insecure ESP algorithms [NULL (0)]!" > > 18853 WAR 01:07:09 846ms syslogd.c(134) "pluto[2146]: > "conn92" #23: > > cannot route -- route already in use for "conn91"" > > 18871 WAR 01:07:14 226ms syslogd.c(134) "pluto[2146]: > "conn93" #21: > > received Delete SA payload: deleting ISAKMP State #21" > > 18873 WAR 01:07:14 228ms syslogd.c(134) "pluto[2146]: > "conn92" #20: > > received Delete SA payload: deleting ISAKMP State #20" > > 18890 WAR 01:07:15 222ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > ignoring informational payload, type IPSEC_RESPONDER_LIFETIME" > > 18892 WAR 01:07:15 223ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > You should NOT use insecure ESP algorithms [NULL (0)]!" > > 18894 WAR 01:07:15 223ms syslogd.c(134) "pluto[2146]: > "conn94" #25: > > cannot route -- route already in use for "conn91"" > > 18917 WAR 01:07:19 228ms syslogd.c(134) "pluto[2146]: > "conn94" #24: > > received Delete SA payload: deleting ISAKMP State #24" > > > > I see that the SA's are getting deleted & re-establish each time with > > this error. This is the ipsec status: > > > > 000 > > 000 #4: "conn91" STATE_QUICK_I2 (sent QI2, IPsec SA established); > > EVENT_SA_REPLACE in 85133s; newest IPSEC; eroute owner > > 000 #4: "conn91" [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> (0 bytes) > [email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> (896 bytes, 34s ago); tunnel > > 000 #1: "conn91" STATE_MAIN_I4 (ISAKMP SA established); > EVENT_SA_REPLACE > > in 84701s; newest ISAKMP; DPD active > > 000 #28: "conn92" STATE_QUICK_I1 (sent QI1, expecting QR1); > > EVENT_RETRANSMIT in 14s > > 000 #26: "conn92" STATE_MAIN_I4 (ISAKMP SA established); > > EVENT_SA_REPLACE in 84922s; newest ISAKMP; DPD active > > 000 #29: "conn93" STATE_QUICK_I1 (sent QI1, expecting QR1); > > EVENT_RETRANSMIT in 14s > > 000 #27: "conn93" STATE_MAIN_I4 (ISAKMP SA established); > > EVENT_SA_REPLACE in 84942s; newest ISAKMP; DPD active > > 000 #31: "conn94" STATE_QUICK_I1 (sent QI1, expecting QR1); > > EVENT_RETRANSMIT in 0s > > 000 #30: "conn94" STATE_MAIN_I4 (ISAKMP SA established); > > EVENT_SA_REPLACE in 85099s; newest ISAKMP; DPD active > > 000 > > > > This is happening only in IKEV1 with more than 3 connections. Please > > suggest. > > > > Thanks, > > Swetha > ====================================================================== Andreas Steffen [email protected] strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
