From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 07:43:09 2010 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 59D941065674 for ; Wed, 23 Jun 2010 07:43:09 +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 109A88FC12 for ; Wed, 23 Jun 2010 07:43:08 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id BBF4F2798BC; Wed, 23 Jun 2010 09:43:04 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 9266C17063; Wed, 23 Jun 2010 09:43:04 +0200 (CEST) Date: Wed, 23 Jun 2010 09:43:04 +0200 From: VANHULLEBUS Yvan To: Maciej Suszko Message-ID: <20100623074304.GA74166@zeninc.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100622190819.270aaa74@gda-arsenic> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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: Wed, 23 Jun 2010 07:43:09 -0000 Hi. On Tue, Jun 22, 2010 at 07:08:19PM +0200, Maciej Suszko wrote: [....] > Set up a gif tunnel in rc.conf: > > cloned_interfaces="gif0" > ifconfig_gif0="tunnel 78.x.x.x 95.x.x.x" > ifconfig_gif0_alias0="10.20.0.1 netmask 255.255.255.255 10.10.1.90" > > 10.20.0.1 is your internal end of the tunnel, so use any address from > beyond the net 10.10.1.90 is in. Using such extra encapsulation generates different kind of IPsec tunnels, which are sometimes used by some commercial devices (I guess at least juniper will use a variant of that), but this is NOT the usual way of setting up IPsec tunnels, and, afaik, this is probably completely useless here (no extra feature provided, and I don't think cisco devices uses such extra encapsulation). Btw, his issue occurs with first phase1 exchange, so actually has NOTHING to do with that part of negociation... > in racoon.conf something like this: > > remote 95.x.x.x [500] > { > exchange_mode main,aggressive; [....] > proposal_check obey; This is a quite perfect example of what should NOT exist in a correct IPsec configuration: Once again, aggressive mode is NOT as secure as main mode, and should be avoided as most as possible. And proposal_check obey is really one of the worst idea people can have when adding things to their racoon.conf, as it just disables proposal check when we are responder !!!! Yvan.