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


_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to