From owner-freebsd-net@FreeBSD.ORG  Sun Jan  1 20:24:46 2006
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8990416A41F
	for <freebsd-net@freebsd.org>; Sun,  1 Jan 2006 20:24:46 +0000 (GMT)
	(envelope-from nielsen-list@memberwebs.com)
Received: from mail.npubs.com (npubs.com [209.66.100.224])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3550543D48
	for <freebsd-net@freebsd.org>; Sun,  1 Jan 2006 20:24:45 +0000 (GMT)
	(envelope-from nielsen-list@memberwebs.com)
From: Nate Nielsen <nielsen-list@memberwebs.com>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian Candler <B.Candler@pobox.com>
References: <20051228143817.GA6898@uk.tiscali.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20060101204253.3976870DDA9@mail.npubs.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Date: Sun,  1 Jan 2006 20:42:53 +0000 (GMT)
Cc: freebsd-net@freebsd.org
Subject: Re: IPSEC documentation
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: nielsen@memberwebs.com
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Jan 2006 20:24:46 -0000

Brian Candler wrote:
> 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.

<snip>

> 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)

That's what I've found the easiest: Encapsulation with gif tunnels and
then IPSec transport mode encryption.

Due to the way IPSec Tunnel mode is implemented routing protocols don't
work well over it (ie: most routing protocols need an interface and next
hop).

> 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.

I'd suggest adding, not replacing.

Cheers,
Nate