[Openswan Users] Vista Rekeying solution available yet?

[Julien DELEAN]

I found a **dirty** way to workaround this issue :

In first, you can change ike and key lifetime in your ipsec.conf :
       ikelifetime=8h
       keylife=24h

But with these values, you will probably reach volume transfer limitation on
Windows Vista side.
Normally, you can change default values of transfer limit on Vista. (editing
Security Policy)

But I can't do this for several reasons in my case (why ? it's out of scope
;) ).

So in order to force a connection renewal (and not rekeying), I shutdown the
ipsec connection every X minutes.
X depends on your bandwith usage. Default transfer volume limitation on
Vista is about 100Mo (if I remember correctly...).
If you need a speed of 500kb/s (during a long time : ie > 4mn), you need to
do this every 2-3 minutes...

If you don't have a lot of data transfer volume through the ipsec
connection, you can do this every 30-45mn...
The important is : Before rekeying !

I do this with a crontab :
*/2 * * * *     /usr/local/sbin/ipsec auto --down roadwarrior-l2tp

But in some cases (with a lot of connected Vista roadwarriors), it doesn't
work and provoke disconnections. :(

I hope that it will be helpful for you, James... It's not perfect but it
could be better ;)

Julien
(Sorry for my "rough" English ;))

2008/6/12 James <james at nttmcl.com>:

> Yeah that's the exact same problem I have.
>
> I have one user here that has been able to minimize their rekeying by doing
> a split tunnel and manual routing but there's problems with that obviously.
> don't want everyone split tunneling.
>
> -James
>
> Julien DELEAN wrote:
>
>> I tried your patch on openswan 2.4.12 but it doesn't seem to prevent Vista
>> deconnections.
>>
>> In order to quickly provoke this behavior, I download a large file, on
>> Vista client, to reach transfer volume limitations on Windows side and to
>> force rekeying.
>>
>> I still have the same error message :
>> Jun 12 11:56:02 xxx pluto[6962]: "roadwarrior-l2tp"[1] xx.xx.xx.xx #1:
>> responding to Main Mode from unknown peer xx.xx.xx.xx
>> ...
>> Jun 12 11:56:03 xxx pluto[6962]: "roadwarrior-l2tp"[2] xx.xx.xx.xx #2:
>> STATE_QUICK_R2: IPsec SA established {ESP=>0xfb7982a1 <0xf516b8d0
>> xfrm=AES_128-HMAC_SHA1 NATD=xx.xx.xx.xx:4500 DPD=none}
>> Jun 12 12:18:18 xxx pluto[6962]: "roadwarrior-l2tp"[3] xx.xx.xx.xx #3:
>> responding to Quick Mode {msgid:02000000}
>> Jun 12 12:18:18 xxx pluto[6962]: "roadwarrior-l2tp"[3] xx.xx.xx.xx #3:
>> cannot install eroute -- it is in use for "roadwarrior-l2tp"[2] xx.xx.xx.xx
>> #2
>>
>> James, are we talking about the same problem ?
>>
>> I think that the only solution is, as you said Paul, to write a patch that
>> allows rekeys to happen to "the same ip/port as currently used". Am I right
>> ?
>>
>> I could try to write this patch but I really don't know how begin to study
>> Pluto's source code. Could anybody help me ?
>>
>> --
>> Julien
>>
>>
>>
>> 2008/6/11 Paul Wouters <paul at xelerance.com <mailto:paul at xelerance.com>>:
>>
>>    On Wed, 11 Jun 2008, James wrote:
>>
>>        How would i configure ipsec.conf to do that?
>>
>>
>>    the workaround is a hack, not a config option. diff against
>>    2.6.14. <http://2.6.14.>..
>>
>>    Might require tweaking for 2.4.x
>>
>>    diff --git a/programs/pluto/ikev1_main.c b/programs/pluto/ikev1_main.c
>>    index e7dbe4f..64a9c00 100644
>>    --- a/programs/pluto/ikev1_main.c
>>    +++ b/programs/pluto/ikev1_main.c
>>    @@ -2948,11 +2948,27 @@ accept_delete(struct state *st, struct
>>    msg_digest *md, struct payload_digest *p)
>>                   }
>>                   else
>>                   {
>>    +
>>    +               /*
>>    +                * attempt at workaround bug 888. If we're in
>>    STATE_QUICK_R2, and
>>    +                * we receive a Delete AND Rekey, we will hit
>>    +                * the passert(sr->eroute_owner == SOS_NOBODY) in
>>    state.c
>>    +                * Workaround: don't delete IPsec SA now, let it
>>    linger
>>    +                */
>>    +                if(dst->st_state == STATE_QUICK_R2) {
>>    +                   loglog(RC_LOG_SERIOUS, "BUG 888 workaround
>>    triggered\n. Received and "
>>    +                          "ignored Delete SA(0x%08lx) payload:
>>    keeping IPSEC state #%lu"
>>    +                          , (unsigned long)ntohl((unsigned
>>    long)*(ipsec_spi_t *)spi)
>>    +                          , dst->st_serialno);
>>    +                }
>>    +                else
>>    +                {
>>                       loglog(RC_LOG_SERIOUS, "received Delete
>>    SA(0x%08lx) payload: "
>>                              "deleting IPSEC State #%lu"
>>                              , (unsigned long)ntohl((unsigned
>>    long)*(ipsec_spi_t *)spi)
>>                              , dst->st_serialno);
>>                       delete_state(dst);
>>    +                 }
>>                   }
>>
>>                   /* reset connection */
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080613/dc101662/attachment.html