On Mon, 2 Aug 2004, John Auld wrote:
> An alternative to rebooting the machines is to reset the SAD's and SPD's
> In http:/m0n0wall/exec.php run the command below - copy all of the text
> below and paste it as a whole line.
> /usr/sbin/setkey -FP; /usr/sbin/setkey -F
I think disabling and reenabling IPsec may accomplish the same thing.
On Tue, 3 Aug 2004, John Auld wrote:
> From http://www.onlamp.com/lpt/a/3009
> "It is your job to ensure both peers are configured with the same lifetimes.
> If they are not, it is possible for the tunnel to be established initially,
> but then cease to work when one of the mis-matched lifetime periods
I think this is probably BS.
At first I had the impression that the lifetime was one of the parameters
that need to be "matched" in order for the tunnel to work, and indeed I
saw a case where a tunnel stopped working when I changed it at one end but
not the other. But now I tend to think that was a coincidence, having
seen numerous cases where legal changes to the tunnel configuration kill
it until it's more agressively reset.
The quote above seems to imply that some kind of synchronization is needed
between the expirations of the two half-tunnels, but there are some
problems with that theory:
1) Each SA is fully visible (including its lifetime) to each peer, so it's
not as if one peer would be "surprised" by an SA expiration.
2) The author seems to be assuming that the lifetimes specified by the two
ends are to be applied to the two SAs separately, but I don't believe
that's the case, especially since the "quick mode" used in phase 2
negotiates both SAs simultaneously.
3) If such synchronization were really needed, it's likely that things
would fail even with equal lifetimes, due to time drift.
> I would still be grateful if anyone can answer the question in my post
> below. Is the setting of SA lifetimes on the client and the server a totally
> manual process - or can you safely leave it unset on the client and rely on
> the client detecting the expiration of a SA lifetime?
I think the real answer is "it's complicated". :-) And worse,
implementation-dependent. There are a number of issues:
1) An implementation may not even make the parameter visible but
nevertheless have a value for it (e.g. the P1 lifetime on the SnapGear).
2) An implementation may or may not accept a value that differs from its
own, and this behavior may itself be configurable.
3) The protocol imposes a severe asymmetry on the "negotiation", while
being symmetric with respect to either peer's being able to be either the
initiator or the responder. Unlike PPP parameters, where there's true
"negotiation" involved, IKE negotiations are basically "take it or leave
it". I.e., the responder either accepts the initiator's proposal as is or
doesn't, but it's not allowed to modify it. The only flexibility is that
multiple proposals can be sent simultaneously, but this scales really
horribly with multiple parameters each having multiple values. Now
consider that either peer can be the initiator, depending on who starts,
and there may be a "coin flip" effect as to whether things work.
> -----Original Message-----
> From: John Auld [mailto:jxa at minervaplc dot com]
> Sent: 03 August 2004 10:49
> When I reported the problem with racoon causing problems, by not cleaning up
> stale SAD's and SPD's, I had set the timeout on the phase 1 and 2 IPSec
> options to 5 minutes.
That's an *awfully* short lifetime, considering that each negotiation
takes a significant number of seconds.
> I have tried leaving the lifetime field unset and this seems to avoid the
> problem with IPSec clients being unable to re-connect. I am not yet
> convinced that this has fixed the problem, but it seems to be fixed or to
> occur less often when the lifetime on phase 1 and 2 is unset.
I would expect leaving everything at default settings would always work
when both peers use the same code. It may or may not work in
> If a lifetime is set, the keys used to encrypt the traffic are changed once
> per lifetime, and it is necessary for both the client and the server to use
> the same settings, so that both change keys at the correct time. On the
I believe "changing keys at the correct time" is never a problem as long
as the negotiations succeed. Any given SA can only have one lifetime, and
I don't even think the two IPsec SAs negotiated in phase 2 can have
On Tue, 3 Aug 2004, Thomas Hertz wrote:
> I find this statement quite strange, as the lifetimes are supposed to be
> negotiated during phase 1. I do know that I've experienced problems when
> letting racoon proposing lifetimes different than those of windows default.
Only the ISAKMP-SA lifetime is negotiated in P1. IPsec SA lifetimes are
negotiated in P2.
Windows may be unwilling to accept mismatched proposals - see above.
More info on P1 vs. P2 lifetimes (now that I've read the IKE RFC):
For PFS (perfect forward secrecy) of just keys, it's permissible to reuse
a longer-lived ISAKMP-SA for P2 rekeying. But for PFS of both keys and
"identities", a given ISAKMP-SA should only be used once for a single P2
and then discarded (thus defeating the whole two-level scheme
:-)). Configurations that set the P1 lifetime shorter than the P2
lifetime may be trying to accomplish this without an explicit feature for
it. Note that "identity" does not mean the PSK itself, and in fact the
combination of aggressive mode and PSKs sends the identity in the clear,
anyway. See RFC2409.
BTW, the SnapGear SOHO+ seems to have the P1 lifetime fixed at 1 hour,
with no option to change it. But it works with the m0n0wall's value set
to 1 day, at least in the SnapGear-as-initiator case. The only real
"conflict" I had setting this up was that the SnapGear doesn't accept MD5
as the P1 hash.
On Tue, 3 Aug 2004, Vincent Fleuranceau wrote:
> The problem is back again :-(
> I've rebooted the local m0n0wall and tried to ping a machine on the
> remote network to get the tunnel running again.
> But the tunnel is down. Once again, I get:
> racoon: ERROR: isakmp.c:1786:isakmp_chkph1there(): phase2 negotiation
> failed due to time up waiting for phase1.
> The remote m0n0wall may not properly update its SAD and SPD information.
You need to look at the remote log as well. It sounds like there was a
difference of opinion as to whether there was a valid ISAKMP-SA in place
at the time the IPsec-SAs expired. Naturally you need a means other than
the tunnel to access the remote. :-)
> So, would it be possible to make the remote m0n0wall test the tunnel on
> a regular basis and delete the "poisoned" SAD and SPD entries by itself?
> I know, this is not clean at all, this is just an idea.
> Is there something that could tell Racoon: "Hey, you know what? Your SAD
> and SPD must be deleted because they have not been used for xx seconds".
Better to figure out what the inconsistent state really is, and *then*
figure out how to fix it. :-)
> More, I've notice the racoon.conf file does not includes timer
> information, I mean something like:
> # These value can be changed per remote node.
> counter 5; # maximum trying count to send.
> interval 20 sec; # maximum interval to resend.
> persend 1; # the number of packets per a send.
> # timer for waiting to complete each phase.
> phase1 30 sec;
> phase2 15 sec;
> Are there default built-in values for this? May the use of well chosen
> values resolve our current problems?
As I think I already mentioned privately, these all look like parameters
relating to the IKE exchanges themselves, and since they don't look
uneasonably picky, I doubt that that's the problem.