Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2

[Scott Ullrich]

On 8/18/07, VANHULLEBUS Yvan <vanhu_bsd at zeninc.net> wrote:
[snip]
> It really looks like an old "known" (well, at least known by me...)
> problem with PFKey interface: it is quite impossible to set up more
> than 50-100 tunnels on a standard FreeBSD (and probably any other KAME
> based stack), because some kind of socket related problems will happen
> when racoon will try to get the SPD or the SADB entries.
>
> When the problem occurs withe the SPD, racoon won't be able to
> negociate some tunnels (because it doesn't have the SPD entries in
> it's own table), when the problems occurs with the SADB, it can lead
> to the 100% CPU usage you have....
>
> Some workarounds are possible depending on your configuration, you may
> be able to reduce the number of used SAs (merge some phases2 with
> contiguous subnets, use REQUIRE instead of UNIQUE for some tunnels,
> etc...), but if you have 80 peers with each one only ONE phase2,
> that's another problem....
>
> To solve that problem, the only solution we found is to do a big PFKey
> hack, to have only one request/response, and all the SPD/SAD entries
> exchanged via a single buffer shared by kernel and racoon.
>
> I also know an old bug in sbspace macro (found in FreeBSD 4.x), but it
> seems it has been fixed at least in FreeBSD 6.

Thanks for the very detailed response.   We have worked around the
problem for now with a simple shell script that looks for racoon
falling over and simply restarting it.

Does anyone know if this is fixed in 7-CURRENT?  If so we can easily
wait until 7 arrives as we plan on releasing pfSense on the 7 platform
as soon as it is released.

George, would you like me to file a PR for this against 7-CURRENT?

Thanks again for all the responses.

Scott