IIRC, the problem occurs when racoon(8) is set to "create policy" on the fly. What happens is that when the SA gets stale, but before it expires, racoon(8) creates a new SA. But since there is an existing entry in the SPD, a new one is cannot made. When the old SA times out, the its accompanying SPD entry is killed, leaving no SPD entry at all.
Yes, that would appear to describe exactly the behaviour we are seeing. Would it be better to turn off policy generation and manually add the SPD entries at the remote end?
We have also had one or two other intermittent niggles which would appear to be caused by one or other of the racoon daemons entering a state from which it cannot gracefully recover (i.e. trying to remove something which is no longer there etc). This bears the all hallmarks of a program whose internal state is not explicitly controlled by a FSM,
and is this supposition is further supported by the fact that the timing and behaviour appears to be affected by turning on debugging.
I do however, like racoon's configuration syntax and the fact we got it up and running very quickly, so we may well come back to racoon again, and try the more
comprehensive fix that Helge suggested but in the meantime we are also going to spend a couple of days evaluating OpenS/WAN to see how it compares.
Thanks
Chris
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
