Matthew Braithwaite wrote:>
> On Sun, 23 Feb 2003 09:47:05 -0800, "Sam Leffler"
<sam@errno.com> said:
> >
> >> Add a new config option IPSEC_FILTERGIF to control whether or not
> >> packets coming out of a GIF tunnel are re-processed by ipfw,
> >> et. al. By default they are not reprocessed. With the option
they
> >> are.
> >
> > This may affect your ipfw/ipf rules. If you are happy with the
> > current behaviour then add IPSEC_FILTERGIF to your kernel config
> > file.
>
> I'm sure this was discussed to death somewhere, since it's a
reversion
> of an earlier change, but just to beat a dead horse ... I encountered
> this change in a surprising way:
>
> Being new to IPSec, I started by setting up a gif tunnel (without
> IPSec) between my singly-homed host, fred, running FreeBSD:
>
> ep0 192.168.0.2/24
> gif0 ${mynet}.27 -> ${mynet}.17
> tunnel 192.168.0.2 -> 192.168.0.1
>
> and a dual-homed host, bob, running NetBSD:
>
> tlp0 ${mynet}.24/28
> tlp1 192.168.0.1/24
> gif0 ${mynet}.24 -> ${mynet}.27
> tunnel 192.168.0.1 -> 192.168.0.2
>
> I did this so I could test the tunneling and the firewalling, and then
> introduce IPSec after I knew all that was working. Fred's firewall at
> this point would pass only ipencap packets over ep0, and I filtered
> the untunneled traffic on gif0. That worked just fine; fred's
> firewall saw both incoming and outgoing traffic on gif0 and filtered
> it.
>
> But then I turned on IPSec AH between 192.168.0.1 and 192.168.0.2, and
> changed fred's firewall to pass ah instead of ipencap on ep0. When I
> made this change, fred's firewall continued seeing outbound packets on
> gif0, but stopped seeing inbound packets. The inbound packets on gif0
> started bypassing the firewall entirely!
>
> Setting IPSEC_FILTERGIF fixed this, of course. But it seemed (and
> still seems) quite unintuitive: why should the presence or absence of
> IPSec over a tunnel determine whether firewall rules get applied? And
> what sense does it make to firewall outbound packets on gif0 but not
> incoming packets?
>
> I'm sure it makes sense from some perspective; I just wanted to
> contribute my confused little experience. :-)
You don't really need the gif tunnels for ipsec. Gif is more geared
towards ipv4 <=> ipv6 type tunnels. A few of ipsec how-to's mention
using gif tunnels and I've been tripped up by it, too.
ipsec is much easier without the gif tunnels. The ipsec policy
definition is explained in the setkey man page. Basically for tunnels
it is: spdadd ${remote net} ${local net} any -P in ipsec
esp/tunnel/${remote gateway}-${local gateway}/unqiue; and spdadd ${local
net} ${remote net} any -P out ipsec esp/tunnel/${local gateway}-${remote
gateway}/unique;
In your example above it looks like you just want to encrypt traffic
between two hosts in the same subnet. So, you would just use transport
mode instead of tunnel. Something like: (for fred)
spdadd 192.168.0.1 192.168.0.2 any -P in esp/transport//unique;
spdadd 192.168.0.2 192.168.0.1 any -P out esp/transport//unique;
greg