[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-tech
Subject:    Re: isakmpd: SA
From:       Hakan Olsson <ho () crt ! se>
Date:       2002-10-24 21:59:28
[Download RAW message or body]

On Thu, 24 Oct 2002 AMozhar@SPIRIT21.de wrote:
...
> Hashmask: 31, policy entries: 0
> SPI = 279baba8, Destination = 10.128.0.21, Sproto = 50
>       Established 53 seconds ago
>       Source = 10.128.0.22
>       Flags (00000012) = <invalid>
>       Crypto ID: 0
>       0 bytes processed by this SA
>       Expirations:
>             Hard expiration(1) in 7 seconds
>
> As You see,  the SA lives 60 seconds! BUT at the very end of isakmpd.conf I
> do have 600 seconds - I think it is enough time for isakmpd!

It works like this:

When negotiating the SAs for the VPN, each side sends (among other things)
a SPI number to the other side, this SPI is part of the SA.

This SPI number is needs to be unique (per host), and as we have the IPsec
processing in the kernel, the isakmpd daemon itself cannot just "guess" a
new such number, it will have to ask the kernel for a free SPI value.

When the kernel gets this request, it allocates the new SPI in the form of
a data structure called a 'tdb', or simply: an "SA". This embryonic, or
placeholder, SA is marked "invalid" and has a lifetime of 60 seconds. (See
your output above. :)

At this point, as far as then kernel is concerned, one of two things can
happen; either

  the IKE negotiations complete successfully, in which case
  isakmpd will *update* this SA with the cryptokeys etc, and also set the
  expiration times (600 seconds in your case).

or

  the IKE negotiations does not complete, in which case nothing is sent to
  the kernel (isakmpd will retry the negotiations in a while), and this
  embryonic SA will silently expire and vanish after the 60 seconds has
  passed.

With that in mind, you seem to be in the latter category, and you should
start looking at why the negotiations fail. Your phase 1 negotiations work
fine, otherwise you wouldn't even get this far, this is a problem in phase
2. I'm guessing bad algorithms, wrong DH group, PFS enabled or not, etc.
You probably get some indication of it in the logs.

/H

--
Håkan Olsson <ho@crt.se>        (+46) 708 437 337     Carlstedt Research
Unix, Networking, Security      (+46) 31 701 4264        & Technology AB

[prev in list] [next in list] [prev in thread] [next in thread]