Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 08 Apr 2001 05:10:46 +0000
From:      Gunther Schadow <>
Subject:   Consolidating KAME SPD rules and IPFW / IPfilter.
Message-ID:  <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

Itojun says this has been discussed before and that the solution
is almost ready to go. I can take some time of my dayjob work to
help this, which is why I want to know exactly the status and 

This is my proposal, not knowing what folks at Kame and FreeBSD
have been cooking:

> [VPN application] In practice I will almost always end up combining
> IPFW and IPsec in my security solutions with *BSD/kame. And I find
> it kind of odd that IPFW and IPsec shouldn't work together better
> than they do now. [...]
> I think that the separate IPsec policy management in setkey is 
> somewhat superflous. It could all very well be handled by IPFW 
> rules such as something like this:
> ipfw add 1000 divert ipsecd 1010 all from <here> to <there> out
> ipfw add 1001 divert ipsecd 1020 50 from <there> to <here> in
> ipfw add 1001 divert ipsecd 1022 51 from <there> to <here> in
> this means, an IPsec daemon (ipsecd) would listen on a divert
> socket (like natd does) and do its thing on the packets. I 
> understand that the SPD contains more data, and that's what
> my numbers 1010, 1020, 1022 would refer to (an SPD identifier). 
> The SPD would now simply contain the parameters of the IPsec mode 
> (ESP vs. AH, transport vs. tunnel, tunnel endpoints, etc.) but not 
> the matching rule stuff. I think that ipfw does a pretty good job 
> with the matching rules, so why doing the same thing in two places?

Itojun wrote in response:
>         this is the tricky part.  IPsec policy and ipfw/ipfilter/divert/
>         whatever is doing almost the same thing, and conflict in very difficult
>         ways.  I'm trying to improve NetBSD situation, as shown in 
>         NetBSD 1.5.1/1.6 should be a lot better than before.
>         for FreeBSD, there was a discussion on one of FreeBSD mailing lists.
>         not sure the particular change got committed to the FreeBSD tree or not.
>         the ultimate solution would be to integrate packet filter and ipsec
>         policy engine into one, there's an ongoing effort on that direction.

And obviously I fully agree. But the problem for the Kame folks seems 
to be that the *BSD are disparate and moving targets for consolidating
packet filtering and IPsec policy management.
Shoichi Sakane wrote:

> [...] I am not sure all *bsd have same method to hook a ip packet.
> Do all *bsd have ipfw in this case ?  I know IPFilter is implemented
> to FreeBSD, NetBSD and OpenBSD.  But it cannot handle a ipv6 packet
> accurately.
> I like to use a general useful pakcet filter function in order to process
> IPSec if it is implemented to all *bsd.

And he also mentions:

> First, KAME IPSec stack is not friendly with NAT.  We don't live in NAT
> environment, so we haven't ever considered about being with NAT.
> If you want to use NAT with IPSec, you have to consider the changing IP
> address in IP packet and the processing order.

To which I can only say that in IPv4 world and VPN, NAT is almost
mandatory. For me, using NAT allows me to set up VPN specific 
routing for my special project within a corporate network without
bothering the network administrator with using FreeBSD instead of
their Cisco stuff for routing. FreeBSD/KAME needs NAT for allowing
it to being used in production environments today. NAT comes with
IPFW, which is where the circle closes.

I would prefer combining IPsec policy with IPFW rather than IPfilter.
But I may not have the full scoop about IPfilter. What's FreeBSD's
direction? I would also rather see one way, IPFW or IPfilter being
mainstream on FreeBSD and NetBSD (for very selfish reasons, i.e.,
once I need to deploy my stuff on a StrongARM board, I must switch
to NetBSD.) I like IPFW a lot and my understanding is that it can
do more than IPfilter, but I may be wrong?
I am tempted to "outsource" the IPsec functionality away from the
kernel using a demon on a divert socket, just like NATD. This would
be more modular and keeps the kernel from panicing because of bugs
in IPsec -- I did have embarrassing kernel crashes, just when I bragged
about FreeBSD running rock solid :0(.

I have read about pipsecd, but would like to stand by the excellent
work of the Kame people. 


Gunther Schadow, M.D., Ph.D.          
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistent Professor        Indiana University School of Medicine

To Unsubscribe: send mail to
with "unsubscribe freebsd-ipfw" in the body of the message

Want to link to this message? Use this URL: <>