nat-t on fc2

Michael H. Warfield mhw at
Fri Jun 25 14:12:37 UTC 2004

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.

 Michael H. Warfield    |  (770) 985-6132   |  mhw at
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <>

More information about the fedora-list mailing list