On Tue, 17 Feb 2009, VANHULLEBUS Yvan wrote:
Hi,
If someone has a magic solution without drawbacks, please tell us !
I am not going to find my posting from a few years back but the
solution is to keep the kernel and libipsec (and setkey) in base in
sync and not install libipsec and setkey from the ipsec-tools port.
Done.
That obviously means that people who patch their kernel need to patch
their user space as well but that should not be a problem as they
rebuild anyway and need to build ipsec-tools racoon etc. on their own
to use the new features as w/o changing the default options it doesn't
work for nat-t.
That also allows other 3rd party utilities using libipsec to continue
to do so and use all "features" w/o needing another fork.
Has anyone had any success using the patched FreeBSD along with racoon2.
I just don't know what's the actual status of racoon2, but nat-t
patchset is public and everyone can send changes if that helps
interaction with other daemons (without breaking again the API if
possible.....).
We have about 3 months left to get that patch in for 8; ideally 6
weeks. Can you update the nat-t patch in a way as discussed here
before so that the extra address is in etc. and we can move forward?
I basically do not care if racoon from ipsec-tools is not going to
work for two weeks of HEAD or four as someone will quickly add a
conditional patch to the port for a __FreeBSD_version > 8xxxxx and
that can be removed once ipsec-tools properly detect the state of the
system.
/bz
--
Bjoern A. Zeeb The greatest risk is not taking one.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
