IPsec with NAT-T in transport mode dropping all packets?

[David Murray]

Greetings All,

I'm having a bit of trouble getting IPsec working in transport mode with 
NAT-T.  I wonder if any experts out there might be able to point me in 
the right direction.

Briefly, the background is that I'm trying to configure a FreeBSD box to 
provide to remote Windows clients with VPN access to the network it sits 
on.  It seemed that L2TP/IPsec was a sensible approach, since then no 
additional software is required on the clients.  To that end, I've been 
trying to construct a solution with the following:

  1)  FreeBSD (RELENG_7_0), kernel built with options IPSEC and 
IPSEC_NAT_T, and patched with
  2)  the NAT-T patch at 
http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff,
  3)  ipsec-tools (0.7.0) for racoon for key exchange, and
  4)  mpd (5.1) for L2TP.

My understanding is that I need IPsec to operate in transport mode 
(tunnelling will be provided by L2TP).  I need NAT-T, since the clients 
will likely be behind NAT gateways.  I can't seem to find much 
documentation on this configuration (so maybe I'm going about this the 
wrong way?).

Anyhow, I have two security policy entries in ipsec.conf, intended to 
encrypt L2TP traffic:

  spdadd 82.16.99.99[1701] 0.0.0.0/0 udp -P out ipsec 
esp/transport//require;
  spdadd 0.0.0.0/0 82.16.99.99[1701] udp -P in  ipsec 
esp/transport//require;

The tricky key negotiation all seems to be working; when I initiate a 
connection from a Windows client, racoon negotiates security 
associations (I'm using certificates):

  racoon: INFO: IPsec-SA established: ESP/Transport 
195.248.102.183[4500]->82.16.99.99[4500] spi=73448711(0x460bd07)
  racoon: INFO: IPsec-SA established: ESP/Transport 
82.16.99.99[4500]->195.248.102.183[4500] spi=2159874738(0x80bd12b2)

However, mpd's log doesn't show any evidence of a single packet arriving 
(and the client eventually gives up), and, with net.inet.ipsec.debug=1, 
the kernel issues the single line:

  kernel: ipsec_common_input: no key association found for SA 
82.16.99.99[4500]/460bd07/50

I'm guessing, therefore, that the kernel is discarding packets because 
it doesn't think it has the correct security associations to deal with 
them (can I check this?).

I'm wondering if this is NAT-T related.  I'm a bit suspicious that the 
security associations are in terms of port 4500, the NAT-T port, and not 
1701, the L2TP port.  I notice the NAT-T patch adds checking of port 
numbers to the security association lookup.

I'd be very grateful if anyone can spot any stupid mistakes I've made, 
or can suggest what I might do to diagnose further.  I'll happily 
provide any more info required.

Many thanks!


-- 
David Murray