From owner-freebsd-stable Fri Nov 22 8:12:28 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37E0937B401 for ; Fri, 22 Nov 2002 08:12:26 -0800 (PST) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5161A43EAF for ; Fri, 22 Nov 2002 08:12:24 -0800 (PST) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.12.6/8.12.6/hmo29jun02) with ESMTP id gAMGBOgm093413 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Fri, 22 Nov 2002 17:11:29 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.6/8.12.6/Submit) id gAMGBO9j093412; Fri, 22 Nov 2002 17:11:24 +0100 (CET) (envelope-from hmo) Message-Id: <200211221611.gAMGBO9j093412@sep.oldach.net> Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION A ND QUESTIONS In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D7E4EF56@rerun.avayactc.com> from "Cambria, Mike" at "Nov 22, 2002 9:53:18 am" To: mcambria@avaya.com (Cambria Mike) Date: Fri, 22 Nov 2002 17:11:23 +0100 (CET) Cc: freebsd-stable-21nov02@oldach.net, archie@dellroad.org, larse@isi.edu, guido@gvr.org, dkelly@hiwaay.net, hausen@punkt.de, sullrich@CRE8.COM, greg.panula@dolaninformation.com, FreeBSD-stable@FreeBSD.ORG From: Helge Oldach MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cambria, Mike: > > From: Helge Oldach [mailto:freebsd-stable-21nov02@oldach.net] > > Perhaps worth mentioning: ESP transport mode over a gif tunnel is > > *not* the same as ESP tunnel mode. Having a FreeBSD box with transport > > mode/gif work against a non-FreeBSD machine in ESP tunnel > > mode will not > > work. > > If you are referring to IPIP tunnels (e.g. gif) then applying IPsec > transport mode to the outer IP, then see > http://www.isi.edu/larse/papers/draft-touch-ipsec-vpn-04.txt or the IETF ID > site on how this works. Interesting paper! OK, I should have been more precise in stating the assumption of an IKE framework (racoon). IKE should be taught that gif+transport == tunnel. :-) That's where it breaks. It will however work fine with static keys. What isn't mentioned there is that the IPIP/transport mode also makes IPSec supporting multicast. (Note that most dynamic routing protocols require multicasts, in contrast to the fact that the draft addresses dynamic routing issues.) The other possible concern is that IPSec has "built-in" PMTUD and fragmentation/defragmentation, so effectively the end stations do not notice that a smaller MTU (caused by the IPSec headers) is used on the path during transit of the IPSec link. With IPIP there is a requirement for explicit PMTUD for the end stations. > Now, if you are referring to using gif+and IPsec _tunnel_ mode .... why > would one want to even do this? Most examples on the net for setting up IPSec using racoon or isakmpd do it like this, for both tunnel and transport mode. Looking at the details in the tunnel mode case one can see that the gif holds more like a "routing placeholder" to get the routing table for the encapsulated network correct. That's the only purpose I can see. A loopback interface could do the same (doesn't work on FreeBSD for some reason), as could static ARP entries using the MAC address of the encapsulating network's default gateway. In practice the problem presented in the paper is commonly solved in a different fashion: By using GRE or IPIP encapsulation *plus* tunnel mode. Seems a bit awkward and doesn't alleviate MTU problems, but that's what people do when they have, say, an enterprise network with EIGRP or OSPF with RFC 1918 addresses on transit links. (Again, explicit PMTUD for the end stations, and that causes a lot of issues in practice.) Helge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message