Date: Mon, 31 Jul 2000 08:01:17 +0300 From: "Ari Suutari" <ari@suutari.iki.fi> To: "Eric J. Schwertfeger" <ejs@bfd.com> Cc: <freebsd-ipfw@FreeBSD.ORG> Subject: Re: IPSEC tunnel mode & ipfw Message-ID: <003f01bffaac$5cfd3440$0e05a8c0@intranet.syncrontech.com> References: <Pine.BSF.4.21.0007280739190.2119-100000@harlie.bfd.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> On Fri, 28 Jul 2000, Ari Suutari wrote:
>
> > However, I'm a little bit worried, since this last rule
> > would also allow packets through if someone pretends
> > to be 192.168.1.xxx since there is no way to tell ipfw
> > that the rule is valid only if the packet being examined
> > has arrived through IPsec tunnel.
> >
> > I solved this temporarily by using pipsecd - now I can
> > trust that packets coming from interface tun0 have
> > gone through IPsec checks. However, I would like
> > to use the functionality available in kernel.
>
> I've tackled that problem as well, and came up with two possible
> solutions.
>
> 1) KAME sets a bitflag in the memory buffer of the packet. If IPFW had
> the ability to branch on that flag, then you could tell if the packet had
> gone through KAME or not. Having the ability to set that flag as well
> could allow IPSEC/natd on the same box, even to the same target. This
> could be done by changing only ipfw and its kernel module.
Yes, I think this would be nice. However, when having multiple
IPsec tunnels, one might also be interested in from which tunnel
the packet originated. This would require some changes in KAME
also.
>
> 2) change the way KAME works, so that there's an ipfw rule that states
> "apply KAME now" and then continues with the next rule, rather than having
> KAME reinject the packet as if it had just come in. I like this idea
> better on a theoretical level, but the problem is that it would be a major
> divergence from KAME, so we would probably loose any future KAME
> improvements.
I think I would prefer the first approach provided that there would
be some kind of 'tunnel-id'...
> In fact, I wrote a user-land IPSECd that used ipfw and divert sockets, but
> it had too many other problems. It did solve the IPSEC/ipfw problem quite
> nicely, however.
I wonder how many different IPsec implementations there have been.
I had also my own (which ran very well for many years, but I lost source
code for it!). Well, luckily the pipsecd is now around so I can use it
for the time being.
Ari S.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003f01bffaac$5cfd3440$0e05a8c0>