On Mon, 27 Sep 2004, Chris Buechler wrote:
> On Mon, 27 Sep 2004 03:36:47 -0400, Chris Buechler <cbuechler at gmail dot com> wrote:
> > >
> > > I've found several (similar) entries in your log that make me think that
> > > both racoon and PIX do not use *exactly* the same settings:
> > >
> > > pfs group mismatched: my:2 peer:0
0 isn't a valid choice. I wonder if the PIX was really sending that, or
if it's just a bug in the logging.
> > > It would be interesting to get the PIX's log, too.
> > >
> > I just noticed that. Never did it before 1.2. Interesting. I did
> > notice one difference between the two on lifetime, and fixed that.
> > Maybe this version is more picky with mismatched settings? I don't
> > know, it's been as it is now for more than 5 months, and just now
> > breaks?
> Since changing the one mismatched lifetime, and the one mismatched PFS
> setting, it has yet to go down. It's been about 8 hours. Still
> scratching my head as to why my screw up worked for 5 months and just
> now broke.
> I'll post back if it craps out again, but for now it seems to be fine.
I think it was a combination of the mismatched PFS group and the change to
the proposal_check setting in racoon.conf. With respect to lifetimes, the
difference between "obey" and "claim" is that the latter causes it (as
responder) to inform the initiator when it uses a shorter lifetime than
offered, in order to keep the two ends consistent even when configured
asymmetrically. This is why I recommended the change. However, with
respect to the PFS key group, "claim" is pickier than "obey". Apparently
the PIX tolerates the PFS mismatch, which is why the SAs could be
established when the m0n0wall was the initiator, but no longer could when
it was the responder.
The real crock here is that a setting that reduces problems with one type
of mismatch increases problems with another. Though mismatching the PFS
group probably makes less sense than mismatching the lifetime.
It's not clear whether racoon pays proper attention to the
RESPONDER-LIFETIME notification or not. In spite of the verbosity of the
log messages, many things are not clearly reported. :-) Each successful
negotiation with the PIX was first claiming to ignore the notification,
and then claiming to have modified some attribute, which may not have been
the lifetime, but it's not clear what else it would have been changing.
Although it appears that your trouble was caused by the new treatment of
the PFS mismatch, before that was determined I was trying to think of ways
that the "prefer newer" policy might cause trouble. There's a comment in
the code suggesting that that behavior needs to be matched between the two
ends, although I discounted that on the basis that the receive-side SA
selection should be based purely on the SPI, without regard for
"age". However, it's not impossible that some implementation might decide
to enforce a preference order on the receive side purely out of
paranoia. And "paranoia over usefulness" seems to be a recurring theme in
IPsec. :-) So it might be necessary to make the "prefer newer" behavior
optional, even though "prefer older" has serious issues with
reboots. Ideally that setting would be per-SP, although with the current
code it can only be a global setting.
There's a subtle issue with "prefer newer" when non-time lifetimes are in
use. Although m0n0wall doesn't currently support that, there's nothing to
stop the peer from imposing limits based on byte or packet counts. With
multiple usable SAs, the preference order affects which SA gets "charged"
for the traffic. But if rekeying is triggered by reaching a soft limit,
then I wouldn't expect "prefer newer" to actually lose connectivity; it
would just increase the frequency of rekeying.
I believe "prefer older" is the "officially correct" behavior according to
one of the RFCs, but without some other means to insure that nonfunctional
SAs can be superseded prior to expiration, it's more problematic than the