[strongSwan] More than 3 Host-to-any connections fails in IKEV1
Swetha RK
rkswetech at gmail.com
Tue Feb 22 05:02:42 CET 2011
Hello Andreas,
Here are the definitions for other connetions:
conn conn92
type=tunnel
leftsubnet=10.46.155.211/32
rightsubnet=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
rightsubnet=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
rightsubnet=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> 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
> rightsubnet=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
> > rightsubnet=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'>"
> > 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> (0 bytes) 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/20110222/77f52630/attachment.html>
More information about the Users
mailing list