Date: Thu, 21 Nov 2002 09:52:54 +0100 (CET) From: "Patrick M. Hausen" <hausen@punkt.de> To: Helge Oldach <freebsd-stable-21nov02@oldach.net> Cc: "Patrick M. Hausen" <hausen@punkt.de>, 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: <200211210852.gAL8qscD076629@hugo10.ka.punkt.de> In-Reply-To: <200211210837.gAL8b4Se080747@sep.oldach.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all! Helge Odach wrote: > > 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. Correct. > 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. Personally, I think the "locally connected subnet" method with a gif interface is simpler and better to recognise, but that's just my opinion ;-) > 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. Well, in this case - what would you suggest to differentiate packets that come in for the first time and packets that have been decrypted and come in again? If I have a setup with two LANs with RFC 1918 addresses coupled via two VPN boxes over the Internet, I need to: - deny packets with RFC 1918 addresses, when they come in from the Internet - but pass ESP and AH in when coming from the peer - divert everything else that is explicitely allowed to natd This part is quite easy. - at the same time pass RFC 1918 to RFC 1918 _without_ NAT if it _is_ a decrypted packet coming from the remote LAN This part is impossible at the moment with tunnel mode and ipfw. So you end up passing everything from private to private and cross your fingers - or use two machines on each side. The main point is - packet already seen and decrypted or not? I think I need to be able to check for this fact in ipfw rules. A separate interface for decrypted traffic would be _one_ possible method. Got a better one? Regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100 76135 Karlsruhe http://punkt.de 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?200211210852.gAL8qscD076629>