From owner-freebsd-net@FreeBSD.ORG Thu May 12 09:17:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA4C106564A for ; Thu, 12 May 2011 09:17:56 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id E74778FC18 for ; Thu, 12 May 2011 09:17:55 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 950402798BD for ; Thu, 12 May 2011 11:02:21 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 84D6F1701A; Thu, 12 May 2011 11:02:21 +0200 (CEST) Date: Thu, 12 May 2011 11:02:21 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20110512090221.GA647@zeninc.net> References: <042051F4-D309-4317-BBE5-5DF9DEEB342C@cyclaero.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <042051F4-D309-4317-BBE5-5DF9DEEB342C@cyclaero.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: multiple clients behind the same NAT connecting a L2TP/IPsec VPN server behind another NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 09:17:56 -0000 Hi. On Wed, May 11, 2011 at 09:43:35PM -0300, Dr. Rolf Jansen wrote: > I have setup a VPN-Server on my FreeBSD 8.2 Release i386 machine, using the following requisites: > > - customized GENERIC Kernel builded with the following > additional options and devices: > IPSEC, IPSEC_FILTERTUNNEL, IPSEC_NAT_T, crypto, enc > > - ports/security/ipsec-tools (v0.8.0) > compiled with NATT enabled and NATTF disabled On a FreeBSD 8.2, NATTF enabled/disabled will change nothing, it is just here to ensure NAT-T support is available and break compilation if it is not. > - ports/net/mpd5 (v5.5) > > > The server sits in the DMZ behind a SOHO router. Everything is > working fine so far. I can establish connections from multiple > external clients at the same time. Even connections from within a > NAT'ed local network via the internet to my L2TP/IPsec server do > work. Which is already good news, as no one AFAIK really worked hard on such setups... > The only remaining problem is, that from behind the same NAT only > one client works well. As soon as a connection between a second > client and the server has been established, the communication of > both break down. The racoon log shows nothing noticeable here, and > according to the log both connections are established successfully, > anyhow, the communication is blocked. Sounds like something (racoon ? kernel ? both ?) handles ports in a bad way in transport mode.... Could you send an example of such generated policies/SAs ? Be careful to use setkey from ipsec-tools (/usr/local/sbin) and NOT from system (/sbin/setkey) to have all NAT-T related informations. > racoon is configured to generate unique policies. A bit more strange.... SAs should be really hard linked with SPDs, and even with a confusion with ports, they should be considered as NOT be for the same tunnel..... > When a client disconnects from the server, racoon usually purges 2 > IPsec-SA shortly after. The interesting thing in the case of 2 > clients from the same NAT is, that it purges one IPsec-SA from the > client just disconnected, and 1 belonging to the client that is > still connected. So, it seems that the internal SA house holding of > racoon got confused. See in racoon's debug (-dd to have more verbose) if decision comes from racoon, from peer (I don't think so) or from the kernel (via a PFKey message). Be careful if you send such output to the ML, as it includes some confidential datas (IPs, PSKs, etc....). > I am investigating this already for some days, and finally I would > like to ask to the experts, whether this is perhaps an issue of the > ipsec-tools (racoon/setkey), and not with my setup. I am willing to > spent more time on this only if there is some chance that this can > be resolved. There is "some chance", but this may involve userland and/or kernel patching... > > So, is there anybody out there, who can successfully establish VPN > connections from multiple clients behind the same NAT to a > L2TP/IPsec Server running ipsec-tools and mpd5? I know that multiple NAT-T behind the same peer will work in *TUNNEL* mode, but I never tested that in TRANSPORT mode. > BTW: Using only mpd5, I setup also a PPTP-VPN server running in > parallel to the L2TP/IPsec one. Multiple PPTP-VPN clients behind the > same NAT work perfectly well with my server - So, I tend to believe > that it is really an issue with the IPsec part and not with the L2TP > (mpd5) part of my setup. I don't know MPD so much, but it really does look like an IPsec related issue. Yvan.