Subject: NAT-T in IKE believed working?
To: None <tech-kern@netbsd.org>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-kern
Date: 12/13/2006 14:27:31
[On tech-kern because I'm pretty sure I'm not doing anything confused
and I suspect some subtle bugs.]

Do people believe that NAT-T just plain works in -current and
netbsd-3?  From my recent experiences it seems that it does not.


I'm trying to set up IPsec with NAT-T between two machines.  One is
-current about a month old, and the other similarly up-to-date
netbsd-3.   The NAT box is also month-old current.

I use transport-mode IPsec with SPD entries to require it for certain
ports.  I use finger to test, and have SPD entries for port 79 that
match the entries for the services I really want in IPsec.

on the "server":

# gdt fios
spdadd {{global subnet of nat}}/24[any] {{global addr of server}}/32[any] any
        -P in ipsec esp/transport//use;
spdadd {{global addr of server}}/32[any] {{global subnet of nat}}/24[any] any
        -P out ipsec esp/transport//use;

## FINGER
# finger to us
spdadd 0.0.0.0/0[any] 0.0.0.0/0[79] tcp
        -P in ipsec esp/transport//require ;
# finger replies from us
spdadd 0.0.0.0/0[79] 0.0.0.0/0[any] tcp
        -P out ipsec esp/transport//require ;

on the "client" (that's natted):

spdadd 0.0.0.0/0[any] {{global addr of server}}/32[any] any
        -P out ipsec esp/transport//use;
spdadd {{global addr of server}}/32[any] 0.0.0.0/0[any] any
        -P in ipsec esp/transport//use;

### generic part for all hosts - transport mode
## FINGER
# finger from us
spdadd 0.0.0.0/0[any] 0.0.0.0/0[79] tcp
        -P out ipsec esp/transport//require ;
spdadd 0.0.0.0/0[79] 0.0.0.0/0[any] tcp
        -P in ipsec esp/transport//require ;


I have "nat_traversal on;" in racoon.conf, and IPSEC_NAT_T in both
kernels.  racoon says it's doing NAT-T when it starts, and the racoon
logs show nat detection and creation of NAT-T mode SAs.  I did not add
any listen statement; the man page seems not to match what the code
wants.

On doing "finger @{{global addr of server}}", a phase 1 and then phase
2 SA is created (with [4500] on the addrs as shown by setkey -D on the
server and client).  I see packets arrive at the server with port 4500
src/dst.  Before putting in the "use" entries above, there would be no
replies.  Looking at counters, I couldn't find anything being
incremented that shouldn't be.  netstat -s -p ipsec shows inbound
packets processed succesfully, and I see the count go up on the SA as
shown by 'setkey -D -P'.  But I don't usually see output packets and
don't see errors there.

I suspected that somehow the inner port number wasn't properly
matching the SPD (because I think most people using NAT-T are doing
tunnel mode w/o matching any upperspec).

With the 'use entries', I was able to get finger to run sometimes, but
only immediately after SA negotiation, and not reliably.  Additional
finger packets (what I'm pretty sure are NAT-T/IPSEC/TCP-SYN packets
arriving) don't cause a response from the server.

IP transport is Verizon FiOS; I haven't observed them doing anything
bad in this regard.

I also tried this with another current box as the server, minus the
'use' entries'.

Can anyone tell me if they're doing anything similar that works
reliably or doesn't work?  Any clues appreciated.

    Greg