kern/53624: patches for ipfw2 to support ipsec packet filtering

Christian Kratzer ck-lists at cksoft.de
Tue Aug 5 04:22:28 PDT 2003


Hi,

On Tue, 5 Aug 2003, Luigi Rizzo wrote:

> Ari,
> maybe the problem was with FAST_IPSEC, i seem to remember a related
> MFC recently...
>
> [Sam, this is about the 'ipsec' dummynet option which was reported
> as not working with RELENG_4...]

ok looks like problem solved for me.  The problem we had seemed to be
the ipsec option not working. We have since been able to build a case
where this works for us.

We have also discoverd in which cases ipsec_filtergif does not work
in which cases the ipsec flag can of course not be checked either.

I feel comfortable with the facts now so here's the situation.

Case1 (this is working)
-----------------------

We have setup ipsec/racoon on a freebsd box and w2k and xp clients
using the micorosft l2tp/ipsec client to connect to it.  The windows clients do
transport mode ipsec to the freebsd 4.8 box and then build a ppptp connection
to the l2tpd daemon on the freebsd box.  The l2tp traffic to udp/1701 on the
freebsd box is protected by ipsec.

We now needed to ensure that udp/1701 on the vpn gateway is only avaiable
to the windows clients that are connecting over the ipsec connection.

This is working fine with

	# l2tpd
	${fwcmd} add pass log udp from any to me 1701 ipsec

This allows udp/1701 packaets coming in from to external interface if ipsec
has been properly setup.

This also means that my initial diagnosis was not correct.  IPSEC_FILTERGIF
and the ipsec patch work fine on FreeBSD stable and also on 5.1-RELEASE
I have tested the setup with both boxes.

Sorry for stirring everything up.

We are also not using FAST_IPSEC

Case2:
------

In my original rules I was trying to build the nat rules on a box so that
only packets not destined for the ipsec vpn would be natted.  This would
have simplified our nat configuration to just

   ${fwcmd} add divert natd all from any to any via ${oif} ipsec

The problem with this seemed to be that outgoing packets would pass through
the divert rules before having ipsec applied if originating from the local
host. Also returning packets did not alway get tagged early enough.

The were also other issues with the ways we had setup our ipfw rules like
filtering some things with "${oif} in" and "${oif} out".   I will have to
do more thinking about that.

I still do not fully understand at which point the kernel encrypts and
decrypts ipsec packets in relation to when ipfw rules are handled and
if the current setup causes problems with filtering outgoing packets ...

Thanks for the help and again sorry for stirring up everything.

Greetings
Christian

-- 
CK Software GmbH
Christian Kratzer,         Schwarzwaldstr. 31, 71131 Jettingen
Email: ck at cksoft.de
Phone: +49 7452 889-135    Open Software Solutions, Network Security
Fax:   +49 7452 889-136    FreeBSD spoken here!


More information about the freebsd-ipfw mailing list