Re: IPSEC documentation
- From: Brian Candler <B.Candler@xxxxxxxxx>
- Date: Wed, 28 Dec 2005 16:06:01 +0000
On Wed, Dec 28, 2005 at 04:04:04PM +0100, Phil Regnauld wrote:
> > This is a really strange approach which is almost guaranteed not to
> > interoperate with other IPSEC gateways.
> It's probably for FreeBSD <-> FreeBSD setups, where it might make sense
> to have an interface endpoint, rather than the "transparent" IPsec
> approach -- otherwise it's not possible to route via the remote
> endpoint, or apply filters at interface level before leaving the
If it's done that way purely as a workaround for limitations of the FreeBSD
IPSEC architecture then that's OK, but I think it should be explicitly
documented as such. Otherwise the rationale is unclear.
(Presumably by "transparent" IPSEC you mean that the kernel takes care of
IPSEC policy independently of ipfw/pf filtering; you're not talking about a
transparent IPSEC gateway such as
It's a shame that this workaround means that you actually have to change the
data format on the wire, as this will reduce interoperability. ISTM what you
really want is to be able to have IPSEC tunnels each appear as separate
interfaces, e.g. ipsec0 or tun0, so that firewall policy can be associated
with each one. The old userland IPSEC implementations had this benefit, of
course. Are any of these still maintained and usable? If so then perhaps
they should also be documented as an alternative.
Actually, I did come across a paper which discussed extending the socket API
so that application decisions could be made on the basis of the IPSEC
attributes by which the data was delivered; ah yes, here it is.
Integrating something like that with ipfw/pf would also give the flexibility
to associate packets with their IPSEC flows. But I digress.
freebsd-net@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
- Prev by Date: 5.4 / 6.0 wi0 and dhcp with closed network
- Next by Date: Re: IPSEC documentation
- Previous by thread: Re: IPSEC documentation
- Next by thread: Re: IPSEC documentation