On Fri, Jun 25, 2004 at 03:16:23PM +0200, Salvatore Basso wrote: > Hi, the supplied version of kernel 2.6 with fc 2 supports natively ipsec that means that in order to use ipsec I do not have to compile the kernel, but in order to use the nat-t I must compile the kernel or also in this case it is not necessary? (I use openswan). thanks. IPSec NAT-T is built into the 2.6 kernel. But only the newer version of NAT-T (I forget which draft number it is). KLIPS from Super FreeS/WAN supported both newer and older versions. The newer version is suppose to be more versatile vis-a-vis alternate ports. That being said, I was not able to get NAT-T to work using pluto from Super FreeS/WAN or OpenSWAN or StrongSWAN. I WAS able to get it to work perfectly using Racoon, from IPSec-tools. Racoon has several other advantages, as well. NAT-T can be turned on or off on a connection by connection basis and it can be set to "force" (no NAT required) on a connection by connection basis. *SWAN can only enable or disable NAT-T globally and you actually have to recompile pluto in order to set the FORCE option, and then all connections are set to FORCE, you can't set it up on a connection by connection basis. Sigh... I've also been having some problems with *SWAN and NAT-T just talking between themselves (no Racoon players). Seems like after running for a few days with multiple NAT-T links, pluto seems to get confused over the SA's and the NAT-T mappings and I end up with some connections coming up and others not and lots of errors about "duplicate packets on SA" or "packet but no connection authorized". I've not seen this problem at all with Racoon. IPSec NAT-T with Racoon on 2.6 does interoperate perfectly with Open/Strong/Super FreeS/WAN on 2.4 using X509 certs. I have that running right now. It also doesn't seem to suffer from the dain-bramage SA confusion with NAT-T, that seems to be primarily *SWAN to *SWAN so I suspect it's a problem in pluto, maybe with the X509 logic since it seemed to start occuring or got worse when I shifted to X509 certs. Racoon is a bit more of a pain to set up and doesn't, yet, support unadorned RSA keys (I had to shift my *SWAN sites to X509 certs to interoperate with Racoon) but RSA key support is in CVS and should be released shortly (added specifically for *SWAN). I also haven't quite figured out how to force Racoon to build the connections immediately rather than wait for the first packets and have the kernel trigger it. There's a bug in the 2.6 kernel where, if an SPD exists but an SA doesn't exist, it returns and immediate "resource unavailable" rather than wait for Racoon to complete building the SA after talking with the other side. So, the first time you hit a connection, you get that error, but then all following connections work fine. There's a patch circulating to fix that bug in the kernel. My experience at this point for FC2 is to just bit the bullet and make the switch to Racoon and not look back. I spent less time figuring out how to get Racoon set up than I did trying to diagnose the problems with *SWAN and NAT-T on 2.6. > ---------- > Salvatore. Regards, Mike -- Michael H. Warfield | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Attachment:
pgpLdWfqpl78I.pgp
Description: PGP signature
