Subject: IPSEC and IPFilter ... again
To: None <firstname.lastname@example.org>
From: Xiaodan Tang <email@example.com>
Date: 03/25/2002 10:09:34
I checked the arcive, and this topic brought up in June 2001, but I
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
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
so all internal box could access Y, unfortunatly, this can be done (the
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.
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
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
IPSEC requets; in case inbound, non-ipsec packet hit filter first; ipsec
(to my understanding) hit filter twice, first the on wire ipsec packet,
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
change be behaver (IPSEC first or NAT first) ?