[strongSwan] More than 3 Host-to-any connections fails in IKEV1
Andreas Steffen
andreas.steffen at strongswan.org
Thu Feb 24 20:27:00 CET 2011
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]==
More information about the Users
mailing list