Date: Tue, 2 Aug 2005 20:30:08 +0200 From: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> To: freebsd-net@freebsd.org Subject: Re: RE: NAT-T support for IPSec stack Message-ID: <20050802183007.GA13203@zeninc.net> In-Reply-To: <42EFAEBE.8060905@seton.org> References: <42EFAEBE.8060905@seton.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 02, 2005 at 12:34:54PM -0500, Matthew Grooms wrote: > Woohoo!!! Thanks!!! I was just checking poking around for this last week > and wondering when someone was going to bring this support to FreeBSD. Well, I made at least one guy being happy today, cool :-) > >For some months now, ipsec-tools is now the "official" version of > >racoon, the KAME's isakmp daemon. > > I hope it shows up in ports soon. The racoon port maintainer mentioned > that the most recent import would be the last and the KAME racoon > developer has stated he won't be maintaining the code anymore. A lot of > fixes have shown up in ipsec-tools after the fork from the KAME project > as well as hybrid user authentication support via pam. OpenBSDs isakmpd > supports NAT-T as well. FreeBSD seems to be the straggler here. Yep, we (the Ipsec-tools team) and KAME team agreed a few month ago about that, and about the fact that the new "official" racoon's version was now ipsec-tool's one. > If memory serves me right, KAME IPSEC is still not SMP safe at the > moment. It seems like FAST_IPSEC had a caveat as well like it doesn't > work with IPV6 or something like that. Could it be that there is no > developer that 'owns' these subsystems? Perhaps rrwatson has this on his > list of things to attack with his ninja net hacking skills. I don't think so. KAME stack still uses the splnet() "giant lock", and I have a (probably not complete) list of missing locks, but I guess it should be quite SMP safe (at least when I'll have some time to make a clean patch for the missing locks, but this is not SMP specific). > >Are you interested in it? > > Yes ( as a user ) but I am not a FreeBSD developer. I think there was > initially resistance from open source groups to integrate this support > due to patent issues ( maybe just WRT usage w/ IKEv1 ) but must have > been resolved as both OpenBSD and Linux support this functionality now. Yep. KAME team did not integrate another NAT-T implementation a few years ago for those reasons. More infos about that may be get from Emmanuel Dreyfus, a NetBSD developper and a member of the ipsec-tools team, which made the NetBSD NAT-T support, and told me a few month ago that NetBSD lawyers were looking at that potential IPR issue. But I guess Manu's personnal answer will be something like "most of us live in Europe, so we don't care about such patents" :-) > It would be very cool to get NAT-T + ipsec tools support as it opens the > door for FreeBSD to compete with the big boys in the client based VPN > market at some point down the road and offers an IPSEC alternative to > OpenVPN. Well, I though that OpenVPN was the alternative, and IPSec the standard :-) > >Of course, it would also be interesting to have an ipsec-tools port, > >I'll contact the ports list for such an integration. > > Fantastic! The website states that it compiles cleanly and works well on > FreeBSD so it should be a piece of cake. That has been my first "job" as an ipsec-tools developer, and working Free/NetBSD is now again an official goal of ipsec-tools. > I am in the process of moving but once settled and upgrade to 6 I will > definitely test out your patches and would be willing to test out any > ipsec-tools port as well. Thanks again for your work on this. I already have "something which can be used as a base to make a port", I'll send it to the ports mailing list as soon as I'll have some time to clean it up a little bit. Yvan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050802183007.GA13203>