Right, well, it appears that there are deeper problems than I thought in
the relationship between IPSec and ipfilter.

Just to review, the machines are connected like this: A -- B == C --
D, with just standard IP between A/B and C/D, and running IPSec in
transport mode between B and C, with originally a gif tunnel, but now a
gre tunnel.

With a gif tunnel and without IPSec, everything was fine. When I turned
on IPSec in transport mode between B and C, however, the gif interface
on C no longer saw the packets from B. Thor suggested to me that
this was because the IPSec code was decapsulating the packets after
decrypting them, rather than just re-queuing the gif packets to be
decapsulated by the gif interface. This seemed plausable until I looked
at the code: in sys/netinet6/ipsec.c the ipsec4_tunnel_validate function
checks to see if the "SA" (I assume the comment really means the SPD) is
for transport mode only and returns false if it, so the packet should be
requeued and later processed by the gif interface code. Why this doesn't
appear to happen is still a mystery to be solved.

Anyway, Thor's suggestion was that switching to a gre tunnel should
solve all of this. So I did so, and found a bug related to gre needing
to do an m_pullup. (Without this, ESP-encrypted packets pushed the gre
and following IP header too far back into the packet and it wasn't
usually all in the first mbuf in the chain, causing decapsulation to
fail. Itojun fixed this yesterday and commited it to current, and
requested a 1.6-branch pullup.)

Unfortunately, though the tunnel now works with IPSec ESP, and bpf sees
the packets going both ways, inbound packets are still not seen by
ipfilter. (I checked the incoming stats for the rules on that interface,
and they remain at zero hits for all rules, no matter what traffic I
send through.) Anybody know what could be going on here? How about a fix?

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC