Hello,

I checked the arcive, and this topic brought up in June 2001, but I 
still didn't
convince why ipfilter should be place to look at the on wire packet.

OK, first of all, my sample network:

internal home                 Home Gateway                       VPN 
Server                internal company
network (X/8)     ---->        (G/32)                    ---->         
(S/32)          ----->     network (Y/8)

Between G/32 and S/32 is public network. IPFitler is running on G/32

To access Y/8, I have setup a IPSEC tunnel "Gy/32 <--> Y/8 tunnel G/32 
S/32",
it works fine that I can access Y on G/32 (though Gy).

I understand I can do subnet based IPSEC tunnel (make the X/8 to a Gy/24 
or sth),
so all internal box could access Y, unfortunatly, this can be done (the 
company VPN
server don't like to give everybody a subnet).

So my goal is share the "Gy/32 <--> Y/8 tunnel G/32 S/32"tunnel. 
However, this
can't be done with the current "IPFitler for on wire packet" settings.

Just for fun, I modified the stack, so on outbound, (ip_output), it goes 
NAT/Filter
first, and then IPSEC; on inbound, just took off the "if 
(ipsec_gethist() != NULL) goto nofil"
everything works out nicely !

Now, it seems everybody suggest Filter has to look at packet on wire, 
but why ?
In my modified case, outbound is NAT'ed the IPSEC'd, which will work 
with any
IPSEC requets; in case inbound, non-ipsec packet hit filter first; ipsec 
packet
(to my understanding) hit filter twice, first the on wire ipsec packet, 
then the
real packet, and NAT kick in at second hit, which NAT the packet back to
internal network X.

Is this dangrous (or any hole) ? Can we at least have a sysctl or sth to 
let people
change be behaver (IPSEC first or NAT first) ?

-Xiaodan Tang