Hi!

I've been trying to look at the source code to see why kern/25796
occurs, and even with my *very limited* understanding of the inner
workings of the IP stack, I think tcpdump (and friends) is not allowed
to see any traffic that used to be IPSEC encapsulated.

The part of code that I've been looking at is src/sys/netinet/ip_input.c,
specifically this part:

#ifdef PFIL_HOOKS
        /*
         * Run through list of hooks for input packets.  If there are any
         * filters which require that additional packets in the flow are
         * not fast-forwarded, they must clear the M_CANFASTFWD flag.
         * Note that filters must _never_ set this flag, as another filter
         * in the list may have previously cleared it.
         */
        /*
         * let ipfilter look at packet on the wire,
         * not the decapsulated packet.
         */
#ifdef IPSEC
        if (!ipsec_getnhist(m))
#elif defined(FAST_IPSEC)
        if (!ipsec_indone(m))
#else
        if (1)
#endif

which was introduced on revision 1.127 on January 24th, 2001, so it is
not new. It may be related to threads 'ipsec after nat', 'ipsec/tunnel for
private spaces' on tech-net on January 2001. Message by itojun on
tech-net announced it in 'ipsec/ipf interaction change'. I also
understand, that the change was done to fix some real problem, so I'm not
too keen to try to locally reverse that, either. What could I expect to
break if I tried it the old way?

I then read the following web page, that confirmed my interpretation
at least partially:
http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction

So, since the traffic was at some point IPSEC-protected, it may not
be shown to tcpdump, and friends? Sounds weird, but it explains
this PR, so I guess this is not a bug, and this PR could be changed
to a feature request. I think one should be able to see the traffic
one receives. :)

Personally, I can't figure out why ipf should not be allowed to mess
with decapsulated data, provided that it shows up on another interface,
like gif. That would allow one to write rules to filter the traffic
properly, yet it would also guarantee that the packet was not spoofed,
since to make it to gif, it would have had to be properly processed
by the IPSEC stage (provided that the gif tunnel was properly configured).
Or am I just missing something obvious?

Of course, it would be much better if ipfilter (and friends) were
ipsec-aware, so they could be allowed access to the packets just as
they were prior to January 24th, 2001. Or, something like
http://mail-index.netbsd.org/tech-net/2001/01/13/0008.html might
take place?

A totally separate issue is the gif interface incoming statistics.
I can't understand why they don't get updated. Should that be filed
as a separate PR, or is it related to the same design that caused
kern/25796 ?


Artsi
-- 
#######======------  http://www.selonen.org/arto/  --------========########
Everstinkuja 5 B 35                               Don't mind doing it.
FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
Finland              tel +358 50 560 4826     Don't know anything about it.