On Mon, 2004-09-27 at 17:17, Fred Wright wrote:
> Exactly. And it's not guaranteed to happen at an effective time. Until
> racoon is up enough to have registered with PF_KEY, pings fall on deaf
> ears. Although doing it "after" starting recoon would appear to be
> adequate, in reality racoon (like just about any active daemon) forks
> itself off soon after starting, and thus creates a race between its
> startup and the continued execution of the script. PHP's slothfulness may
> not be sufficient to insure that the ping comes late enough. :-)
Few things here. First, I knew that the race condition could become an
issue, but it worked every time for me on my net4501, which should be
slow enough hardware-wise to bank that racoon's forking would finish
before the ping executed. The one condition I didn't test was loading
the racoon.conf file up with a bunch of different tunnels, which I would
assume would slow racoon down a bit.
Also, there is some terminology confusion here. Auto-establish means
just that, when racoon is started, the tunnel is automatically
established. Auto-establish and keepalive are two completely different
things. To be honest, I created it to fix the problem of a m0n0wall
getting rebooted and having the SA issue that your kernel patch seems to
fix. Am I correct in that assumption? Before, if you have network A
with an IPSec tunnel to network B, and network B's m0n0wall was power
cycled, the only way to re-establish the tunnel was by sending a packet
from B to A. Packets sent from A to B would fail to bring up the new
tunnel. If your kernel patch fixes this, then my patch more than likely
is not needed.
> The other problem with the ping approach is that it's permissible to
> create a tunnel that doesn't contain any of the m0n0wall's IPs, but it's
> not possible for m0n0wall to send a ping with such a source address.
Manuel and I were talking about this issue earlier today. I originally
thought that netcat could send packets without binding to an address,
but my test proved otherwise. Manuel's response:
"Mmmm, I guess there are some "hacker" tools around that can send
arbitrary IP packets (ipsend from ipfilter?). I can't help feeling
that this is an ugly solution and really something that should be
dealt with in racoon though."
My gut feeling is that we're trying to kill a fly with a sheet of
plywood. We might fix the immediate problem, but who knows what else
might get mucked up in the process.
I think this is where I have to show my newbness with racoon/FreeBSD:
1) Surely we can't be the only people fighting this - are the racoon
folks working on the problem?
2) Is racoon the most mature keying daemon for FreeBSD? There's an
ISAKMPD in ports - is that any better?
I'm all ears...
Justin Ellison <justin at techadvise dot com>