Subject: Re: racoon/isakmp_natt broken in -current?
To: None <current-users@netbsd.org>
From: Brett Lymn <blymn@baesystems.com.au>
List: current-users
Date: 06/18/2005 13:10:01
Executive summary: I managed to make NAT-T work, the problem was a
configuration error/nit.

This is a sort of a summary just in case someone else hits this
problem.

On Fri, Jun 03, 2005 at 09:57:19PM +0930, Brett Lymn wrote:
> 
> Firstly, let me confess that my userland is a little out of date but I
> did update my sources and build and install a new racoon binary.
> 

I updated my userland completely to no avail...

> 
> 1) setup the SPD so that the remote and local networks should be
> encrypted, I have used the private address on the local end and the
> "correct" public address on the other - these SPD entries used to work
> before I started playing with NATT (except I had my ISP public address
> as the endpoint at the local end)
> 

In actuality, this is what was wrong, I did not have the SPD entries
correct.  The setkey manual sort of hints that you may need to specify
the UDP ports used in NAT-T mode but qualifies this by saying that it
is OS specific.  It appears that in NetBSD you must have the port
numbers otherwise the the SA's fail to match and this is what I was
seeing, the ipsec statistics (I had to resort to building a debug
kernel and use gdb on the running kernel to see these stats) showed
has an out_nosa (no SA on output) counter that was being incremented
for every ipsec packet, this and a bit of a re-read of the setkey man
page lead me to the solution.  I changed my ipsec.conf to add the port
numbers to my spdadd lines like this:

spdadd 192.168.3.1/32[any] work.classB.0.0/16[any] any -P out ipsec esp/tunnel/192.168.3.1[500]-work.firewall.ip.address[500]/require;
spdadd work.classB.0.0/16[any] 192.168.3.1/32[any] any -P in ipsec esp/tunnel/work.firewall.ip.address[500]-192.168.3.1[500]/require;

The important change here is the [500]'s in the tunnel parameters -
this tells ipsec that the NAT-T UDP encapsulated traffic is being
trasferred on UDP port 500 (you don't need to have the same port
number both sides...).  If you increase the debug level on racoon when
it is negotiating the tunnel you will be able to see what ports are
being used to pass the traffic and can adjust your spdadd parameters
to suit.  In my case both sides used port 500, once I added this
information in the SA for the tunnel was found and ESP traffic started
flowing.  There was much rejoicing.

-- 
Brett Lymn