From owner-freebsd-questions@FreeBSD.ORG Thu Aug 7 12:28:10 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAEED1065672 for ; Thu, 7 Aug 2008 12:28:10 +0000 (UTC) (envelope-from freebsd-questions@davidmurray.name) Received: from queueout02-winn.ispmail.ntl.com (queueout02-winn.ispmail.ntl.com [81.103.221.56]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1218FC24 for ; Thu, 7 Aug 2008 12:28:09 +0000 (UTC) (envelope-from freebsd-questions@davidmurray.name) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080807120134.ISQQ777.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Thu, 7 Aug 2008 13:01:34 +0100 Received: from davidmurray.name ([82.16.99.99]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080807120134.CEIC5827.aamtaout01-winn.ispmail.ntl.com@davidmurray.name> for ; Thu, 7 Aug 2008 13:01:34 +0100 Received: from [192.168.89.2] by davidmurray.name with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR4BM-000KAT-GP for freebsd-questions@freebsd.org; Thu, 07 Aug 2008 13:01:28 +0100 Message-ID: <489AE41C.1070504@davidmurray.name> Date: Thu, 07 Aug 2008 13:01:32 +0100 From: David Murray User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: IPsec with NAT-T in transport mode dropping all packets? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Murray List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2008 12:28:10 -0000 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