Racoon(8) Deleting SPD Entries

[Alex Hayward]

On Sat, 29 Nov 2003, Crist J. Clark wrote:

> Versions: Racoon(8) from ports racoon-20030826a. FreeBSD kernel
> 4.8-RELEASE-p13. Running with net.key.prefered_oldsa=1, but flipping
> to 0 does not seem to make a difference.

I've never quite seen the point of this option; surely using the old SA
just can't possibly work properly?

> I am having some problems with racoon(8). Everything works fine for
> the lifetime of the initial SA, but then things die. When the initial
> SA is removed, racoon(8) seems to be clearing out the corresponding
> entry in the SPD. However, when we had reached the soft timeout
> earlier, racoon(8) had established new SAs. Since we have good SAs,
> racoon(8) doesn't try to do new negotiations. Both ends have a good
> SAD, but the responder no longer has SPD entries for the pair.

I've come across this, too. It appears to be a bug in Racoon; I've
submitted a bug report to KAME - bug fbsd4/530. When Racoon creates the
security policy it gives it a timeout equal to the timeout on the SA.
It doesn't renew this timeout when a new SA is negotiated and will only
create a new SP if the existing SP has already timed out.

My solution was to statically configure the security policies. This works
OK for us because the clients have static IP addresses - but it means that
their dial-up fallback won't work because their IP addresses will change.

It looks like the SP timeout could be left unset as a quick fix. Ideally,
though, I'd prefer to have some sort of 'security policy template'
database which would allow clients with particular IDs to establish SPs
tunnelling to/from only particular networks but with the remote tunnel
endpoints being whatever IP addresses they have at the time.

There is a possibility I'll get the chance to work on doing this. On the
other hand we might just use Linux and FreeSWAN instead.