[Openswan Users] Vista Rekeying solution available yet?

[Julien DELEAN]

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>:

> 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...
> 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/20080612/35670a0d/attachment.html