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>