Date: Fri, 22 Nov 2002 17:11:23 +0100 (CET) From: Helge Oldach <freebsd-stable-21nov02@oldach.net> To: mcambria@avaya.com (Cambria Mike) 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 Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION A ND QUESTIONS Message-ID: <200211221611.gAMGBO9j093412@sep.oldach.net> In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D7E4EF56@rerun.avayactc.com> from "Cambria, Mike" at "Nov 22, 2002 9:53:18 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211221611.gAMGBO9j093412>