From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:08:21 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13DC716A41F for ; Wed, 28 Dec 2005 15:08:21 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from skippyii.compar.com (mail.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14E4743D7C for ; Wed, 28 Dec 2005 15:08:14 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM0011e6ede298.cpe.net.cable.rogers.com [70.28.254.189]) by skippyii.compar.com (8.13.1/8.13.1) with ESMTP id jBSF9PaC036331; Wed, 28 Dec 2005 10:09:29 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Brian Candler" , References: <20051228143817.GA6898@uk.tiscali.com> Date: Wed, 28 Dec 2005 10:08:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Cc: Subject: Re: IPSEC documentation 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, 28 Dec 2005 15:08:21 -0000 > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > > This is a really strange approach which is almost guaranteed not to > interoperate with other IPSEC gateways. (It might be useful if you were > using etherip encapsulation and attempting to bridge two remote networks, > but that's not what it's doing either. In any case, if you're encapsulating > with a different protocol then you only need IPSEC transport mode, not > tunnel mode) While correct, note the scenario for which the configuration is describing: 14.10.3 The Scenario: Two networks, connected to the Internet, to behave as one. This is something I do all the time to connect retail outlets to the server at the head office. This double-encapsulation ensures that nobody can sniff my packets, which contain sensitive information such as credit card data (which is already encrypted via HTTPS, but you can't be too safe!) > ISTM that this chapter should be rewritten to use IPSEC tunnel mode solely. > Do people here generally agree? If so I'll try to find the time to modify > it. This perhaps would be a good _addition_ to the existing documentation -- it's likely a configuration that many would want to set up, especially to inter-operate with corporate networks (using commercial IPSec solutions) -- or for those who don't need the double-encapsulation. -- Matt Emmerton