Date: Thu, 21 Nov 2002 09:37:04 +0100 (CET) From: Helge Oldach <freebsd-stable-21nov02@oldach.net> To: hausen@punkt.de (Patrick M. Hausen) Cc: archie@dellroad.org, guido@gvr.org, dkelly@HiWAAY.net, sullrich@CRE8.COM, greg.panula@dolaninformation.com, FreeBSD-stable@FreeBSD.ORG Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS Message-ID: <200211210837.gAL8b4Se080747@sep.oldach.net> In-Reply-To: <200211200820.gAK8Ki6G041336@hugo10.ka.punkt.de> from "Patrick M. Hausen" at "Nov 20, 2002 9:20:44 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Patrick M. Hausen: > One question to Guido: why would it be necessary to add a new > device - be it called esp0 or fxp_esp0 or similar - to tag the > packets as coming from? Can't the decrypted packets just come > from the already existing gif0 tunnel interface? Essentially because you don't need to use a gif interface at all if you implement ESP tunnel mode. The only purpose for gif is to get the routing straight, which is: You have a route to the remote inside network via the gif interface, and you have a "public" route via the real interface. You can as well implement this by placing the internal route to an IP address which has a static ARP entry with the MAC address of the public default gateway. Been there, it works. Again compared to Cisco IOS, it's even simpler there, as you can create "remote routes" which avoids fiddling with MAC entries, e.g. ! remote (public) via our default gateway ip route 62.12.34.56 255.255.255.255 194.123.123.124 ! remote (internal) ip route 172.16.0.0 255.255.0.0 62.12.34.56 (Note that this isn't possible with the BSD stack. It would simplify things it it would...) The core problem is that we have a single routing table only, and hence we have a mix of internal and public routes. Consequently we will see both internal and external packets on interfaces. Therefore I don't see the need for an extra interface. I regard the gif set-up as confusion already, because this interface isn't used at all. Specifically, a beast such as esp0 would only work for ESP tunnel mode, but again add confusion for ESP transport mode and AH. (What IP addresses do you assign the esp0 interface in transport mode?) Finally, such an implementation would be quite unique in the industry. I would prefer to keep reference to existing implementations. 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?200211210837.gAL8b4Se080747>