IPsec with NAT-T in transport mode dropping all packets?
David Murray
freebsd-questions at davidmurray.name
Thu Aug 7 12:28:10 UTC 2008
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
More information about the freebsd-questions
mailing list