From: Andreas Steffen (andreas.steffen_at_strongsec.net)
Date: Wed Jul 31 2002 - 23:10:58 CEST
Well, if you have set keylife=24h then it is just normal behaviour
to keep the eroute for at least this time frame. The problem
will always occur when a different user logs in with an IP
for which an eroute is still in use. The only solution is
either to reduce the keylife sufficiently so that the probability
of another user getting the lease of the same IP before the
IPsec SA expires becomes small enough or as an alternative to
implement support of delete notifications (if the VPN client
generates them) so that the IPsec SA and the corresponding eroute
is automatically deleted when the client disconnects.
Regards
Andreas
Norbert Wegener wrote:
> Hello,
> here some addtional greps from the logs.
> as you can see, the error occurs really often. All Ipsec SAs, which
> cause problems, have been established a day earlier.(keylife=24.0h)
> Maybe the problem occurs, because our customers use an Ippool of a
> relative small ippool from a certain provider?
> grep "cannot install eroute" messages
> Jul 31 15:24:25 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #759: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.141 #215
> Jul 31 15:25:39 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #761: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.141 #215
> Jul 31 15:27:43 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #764: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.141 #215
> Jul 31 15:32:38 lnxe Pluto[13561]: "rest" xxx.yyy.100.142 #771: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.142 #252
> Jul 31 15:35:24 lnxe Pluto[13561]: "rest" xxx.yyy.100.142 #782: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.142 #252
> Jul 31 15:36:58 lnxe Pluto[13561]: "rest" xxx.yyy.100.142 #787: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.142 #252
> Jul 31 16:12:15 lnxe Pluto[13561]: "rest" xxx.yyy.100.148 #812: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.148 #524
> Jul 31 16:16:10 lnxe Pluto[13561]: "rest" xxx.yyy.100.148 #815: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.148 #524
> Jul 31 16:17:36 lnxe Pluto[13561]: "rest" xxx.yyy.100.148 #820: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.148 #524
> Jul 31 16:18:03 lnxe Pluto[13561]: "rest" xxx.yyy.100.148 #822: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.148 #524
> Jul 31 16:37:29 lnxe Pluto[13561]: "rest" xxx.yyy.100.155 #845: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.155 #598
> Jul 31 16:44:27 lnxe Pluto[13561]: "rest" xxx.yyy.100.129 #861: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.129 #672
> Jul 31 16:46:00 lnxe Pluto[13561]: "rest" xxx.yyy.100.129 #863: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.129 #672
> Jul 31 16:50:24 lnxe Pluto[13561]: "rest" xxx.yyy.100.129 #869: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.129 #672
>
> lnxe:/var/log # grep "#215" messages
> Jul 31 15:24:25 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #759: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.141 #215
> Jul 31 15:25:39 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #761: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.141 #215
> Jul 31 15:27:43 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #764: cannot
> install eroute -- it is in use for "rest" xxx.yyy.100.141 #215
> Jul 31 16:48:17 lnxe Pluto[13561]: "rest" #215: deleting state
> (STATE_QUICK_R2)
>
> lnxe:/var/log # grep "#215" messages-20020731
> Jul 30 18:01:04 lnxe Pluto[13561]: | creating state object #215 at
> 0x80b07f0
> Jul 30 18:01:04 lnxe Pluto[13561]: | inserting event EVENT_SO_DISCARD,
> timeout in 0 seconds for #215
> Jul 30 18:01:04 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #215:
> responding to Quick Mode
> Jul 30 18:01:04 lnxe Pluto[13561]: | inserting event EVENT_RETRANSMIT,
> timeout in 10 seconds for #215
> Jul 30 18:01:04 lnxe Pluto[13561]: | next event EVENT_RETRANSMIT in 10
> seconds for #215
> Jul 30 18:01:05 lnxe Pluto[13561]: | state object #215 found, in
> STATE_QUICK_R1
> Jul 30 18:01:05 lnxe Pluto[13561]: | inserting event EVENT_SA_REPLACE,
> timeout in 86130 seconds for #215
> Jul 30 18:01:05 lnxe Pluto[13561]: "rest" xxx.yyy.100.141 #215: IPsec SA
> established
>
> lnxe:/var/log # grep "#252" messages-20020731
> Jul 30 18:51:54 lnxe Pluto[13561]: | creating state object #252 at
> 0x80bfcb0
> Jul 30 18:51:54 lnxe Pluto[13561]: | inserting event EVENT_SO_DISCARD,
> timeout in 0 seconds for #252
> Jul 30 18:51:54 lnxe Pluto[13561]: "rest" xxx.yyy.100.142 #252:
> responding to Quick Mode
> Jul 30 18:51:54 lnxe Pluto[13561]: | inserting event EVENT_RETRANSMIT,
> timeout in 10 seconds for #252
> Jul 30 18:51:54 lnxe Pluto[13561]: | state object #252 found, in
> STATE_QUICK_R1
> Jul 30 18:51:54 lnxe Pluto[13561]: "rest" xxx.yyy.100.142 #252:
> up-client output:
> Jul 30 18:51:54 lnxe Pluto[13561]: | inserting event EVENT_SA_REPLACE,
> timeout in 86130 seconds for #252
> Jul 30 18:51:54 lnxe Pluto[13561]: "rest" xxx.yyy.100.142 #252: IPsec SA
> established
>
> lnxe:/var/log # grep "#524" messages-20020731
> Jul 30 11:45:48 lnxe Pluto[16164]: | creating state object #524 at
> 0x80ea2f0
> Jul 30 11:45:48 lnxe Pluto[16164]: | inserting event EVENT_SO_DISCARD,
> timeout in 0 seconds for #524
> Jul 30 11:45:48 lnxe Pluto[16164]: "rest" xxx.yyy.100.129 #524:
> responding to Quick Mode
> Jul 30 11:45:48 lnxe Pluto[16164]: | inserting event EVENT_RETRANSMIT,
> timeout in 10 seconds for #524
> Jul 30 11:45:48 lnxe Pluto[16164]: | next event EVENT_RETRANSMIT in 10
> seconds for #524
> Jul 30 11:45:48 lnxe Pluto[16164]: | state object #524 found, in
> STATE_QUICK_R1
> Jul 30 11:45:48 lnxe Pluto[16164]: | inserting event EVENT_SA_REPLACE,
> timeout in 86130 seconds for #524
> Jul 30 11:45:48 lnxe Pluto[16164]: "rest" xxx.yyy.100.129 #524: IPsec SA
> established
> Jul 30 13:59:42 lnxe Pluto[16164]: "rest" #524: deleting state
> (STATE_QUICK_R2)
>
> Regards
> Norbert
>
>
> Andreas Steffen schrieb:
>
>>How does the rekeying history of the owner of IPsec SA #122 look like?
>>Did FreeS/WAN try to renew the IPSec SA when #122 was about to expire?
>>Had the user already logged off by that time? Usually FreeS/WAN
>>tries to renew the IPsec SA a certain number of times depending
>>on the keyingtries parameter and when all these trials fail the
>>connection is unrouted. Using Mathieu Lafon's delete notification
>>patch a delete notification sent e.g. by SSH Sentinel when it is
>>properly shut down is heeded by FreeS/WAN and leads to an
>>automatic unrouting as soon as the remote client goes down.
>>
>>Regards
>>
>>Andreas
>
>
-- ====================================================================== Andreas Steffen e-mail: andreas.steffen_at_strongsec.com strongSec GmbH phone: +41 76 340 25 56 Alter Zürichweg 20 home: http://www.strongsec.com CH-8952 Schlieren (Switzerland) ==========================================[strong internet security]==_______________________________________________ Users mailing list Users_at_lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.4 : Mon Aug 05 2002 - 21:01:35 CEST