-----BEGIN PGP SIGNED MESSAGE-----


For the purposes that Darren is proposing, yes, having a dummy interface is a
good solution. I'd still like to see an additional parameter passed into
pfil_run_hooks that told the hooks which tunnel the packets were emerging
from. This could be the SPI, but that is too ephermeral. I'd rather it was
a number that was provided as part of the policy definition in racoon.conf.

{In FreeSWAN 3.x, still in development, this is called the "SAref", and is
allocated by the kernel and provided to the keying daemon. The keying daemon
then provides it to the firewall configuration scripts}

>>>>> "Darren" == Darren Reed <darrenr@reed.wattle.id.au> writes:
    Darren> * NOW, the other side of this is it might be nice to use tcpdump or
    Darren> similar tools on ipsec_ex0.  If this was felt strongly enough then
    Darren> I'd hope that the solution deployed for the solution of the packet
    Darren> filtering problem could be also applied to interfacing with bpf in
    Darren> some fashion.

Being able to tcpdump on the packets that go in/out of a tunnel is of very
high utility. More important to me than being able to firewal them. If we can
get gif/gre-like behaviour instead, and solve the IPv6 problem, then it is 
really worth doing this.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [







-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPqAfFoqHRg3pndX9AQGIGgQAsP7Mu2fVobBVL14SXfa/knu700RbwiV/
R9cCw54jxxCFXqRXcC7H1hrE2HQ4uXCAFTRg/8ELJiz9Z6xmMxFj+s5VnfgDS1bt
voNhZp2uHrEmCkQ0ad9t5NKGAugZjtzkrDzdxwSCig7PXK8xLrJrwzUASBqsRIqj
6mbKI/HCB3U=
=g3UH
-----END PGP SIGNATURE-----