On Tue, Apr 13, 2004 at 08:50:27AM +1000, Daniel Carosone wrote:
>On Fri, Apr 09, 2004 at 04:20:11PM +0200, Martin Husemann wrote:
>> And you can get at the complete ethernet frames easily by running
>> tcpdump on the raw ethernet interface instead of on pppoe0.
>
>This, to me, indicates part of the "problem" with the ipsec case: it
>would be very handy to have decrypted packets appear again on another
>virtual interface. A number of interface-oriented tools can then work
>with those packets as normal, including tcpdump, ipf and others.
>
>It can be simulated, if you have control and the right capabilities at
>both ends of the connection - by using gre(4) or gif(4) tunnels and
>transport-mode IPsec on the gif/gre packets, rather than IPsec
>tunnels.  I have found this to be much more convenient, for the above
>reasons, and also for working around some PMTU cases, but it's
>somewhat hackish - certainly not applicable generally.

eg...ipsec0?  it'd sure be handy if natted traffic could be looked at
before and after as well.  and if filters could be applied before and
after nat....but i digress.

i can't imagine it would be too hard to make a network interface into
which traffic can be copied (via "dup-to" in ipf or something) but
which then goes nowhere.  like...a null interface?  didn't someone say
something about one of those recently?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."