From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 11:23:27 2004 Return-Path: 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 B37D816A4CE for ; Mon, 27 Sep 2004 11:23:27 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id D51CE43D60 for ; Mon, 27 Sep 2004 11:23:26 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.13.1/8.13.1) with SMTP id i8RBN03E015748; Mon, 27 Sep 2004 12:23:00 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Mon, 27 Sep 2004 12:22:55 +0100 From: Brian Somers To: "Bjoern A. Zeeb" Message-ID: <20040927122255.71d60282@dev.lan.Awfulhak.org> In-Reply-To: References: <20040927113624.4a342952@dev.lan.Awfulhak.org> X-Mailer: Sylpheed-Claws 0.9.12a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org cc: freebsd-net@freebsd.org Subject: Re: ICMP_UNREACH_NEEDFRAG broken in -current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 11:23:27 -0000 On Mon, 27 Sep 2004 10:59:54 +0000 (UTC), "Bjoern A. Zeeb" wrote: > On Mon, 27 Sep 2004, Brian Somers wrote: > > > The outside network segment is an IPSEC configuration with gif interfaces > ... > > Comments/suggestions/flames? > > most likely unrelated but I need input on this so ... > why do you need gif(4) ? With an ipsec-only solution, talking from a gateway box to an internal host on the ``other'' network doesn't work nicely.... especially if the internal host on the other network doesn't have a route for it. In my scenario, some 172.16.10.0/24 machines don't have a default route and therefore can't reach 80.177.173.150. Using gif results in traffic from the gatway box using the gateway boxes internal IP number as the source rather than it's external IP number. This allows a simple security policy: 172.16.10.212 $ cat /etc/ipsec.conf spdadd 80.177.173.150/32 194.242.157.46/32 ip4 -P in ipsec esp/transport//require; spdadd 194.242.157.46/32 80.177.173.150/32 ip4 -P out ipsec esp/transport//require; 172.16.0.1 $ ifconfig -a re0: flags=8843 mtu 1500 options=1b inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 ether 00:40:f4:b1:1c:85 media: Ethernet autoselect (1000baseTX ) status: active gif0: flags=8051 mtu 1280 tunnel inet 80.177.173.150 --> 194.242.157.46 inet 172.16.0.1 --> 172.16.10.212 netmask 0xffffffff tun0: flags=8051 mtu 1500 inet 80.177.173.150 --> 217.47.133.74 netmask 0xffffffff Opened by PID 876 172.16.10.212 $ ifconfig -a bge0: flags=8843 mtu 1500 options=1a inet 194.242.157.46 netmask 0xfffffff8 broadcast 194.242.157.47 ether 00:03:ba:2d:d9:f0 media: Ethernet autoselect (1000baseSX ) status: active bge2: flags=8843 mtu 1500 options=1a inet 172.16.10.212 netmask 0xffffff00 broadcast 172.16.10.255 ether 00:03:ba:2d:d9:f1 media: Ethernet autoselect (1000baseSX ) status: active gif0: flags=8051 mtu 1280 tunnel inet 194.242.157.46 --> 80.177.173.150 inet 172.16.10.212 --> 172.16.0.1 netmask 0xffffffff -- Brian Don't _EVER_ lose your sense of humour !