Date: Thu, 07 Aug 2008 13:01:32 +0100 From: David Murray <freebsd-questions@davidmurray.name> To: freebsd-questions@freebsd.org Subject: IPsec with NAT-T in transport mode dropping all packets? Message-ID: <489AE41C.1070504@davidmurray.name>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?489AE41C.1070504>