[strongSwan] More than 3 Host-to-any connections fails in IKEV1
Swetha RK
rkswetech at gmail.com
Sun Feb 27 16:07:13 CET 2011
Hello Andreas,
Thanks for your analysis..
Is it fine to have this hack in our system to avoid such eroute error? (dont
check for routes_agree() check at all)
//if (ro != NULL && !routes_agree(ro, c))
if (ro != NULL )
{
loglog(RC_LOG_SERIOUS, "cannot route -- route already in use for \"%s\""
, ro->name);
return route_impossible; /* another connection already
using the eroute */
}
Or does any of the strongswan version latest than 4.4.1 solve this issue?
Pleas suggest.
Thanks,
Swetha
On Fri, Feb 25, 2011 at 12:57 AM, Andreas Steffen <
andreas.steffen at strongswan.org> wrote:
> 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
>> <andreas.steffen at strongswan.org <mailto:andreas.steffen at strongswan.org>>
>>
>> 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
>> > 'cisco_move_cert at nsn.com <mailto:cisco_move_cert at nsn.com>'
>> <mailto:'cisco_move_cert at nsn.com <mailto:cisco_move_cert at nsn.com>'>"
>>
>> > 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" esp.16012697 at 192.168.13.4
>> <mailto:esp.16012697 at 192.168.13.4>
>> > <mailto:esp.16012697 at 192.168.13.4
>> <mailto:esp.16012697 at 192.168.13.4>> (0 bytes)
>> esp.fdb38409 at 10.46.155.203 <mailto:esp.fdb38409 at 10.46.155.203>
>> > <mailto:esp.fdb38409 at 10.46.155.203
>> <mailto:esp.fdb38409 at 10.46.155.203>> (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 andreas.steffen at strongswan.org
> 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]==
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110227/66066512/attachment.html>
More information about the Users
mailing list