Date: Thu, 21 Nov 2002 13:52:23 +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: <200211211252.gALCqNj2083276@hugo10.ka.punkt.de> In-Reply-To: <200211211228.gALCSPn4082102@sep.oldach.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Helge! > > 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? > > I'd say this is the wrong question... The issue really is at which > point in time the ipfw rules catch in. The FreeBSD paradigm (actually, > KAME) is that a packet is being "pushed back onto the IP stack" after > de-capsulation, which causes the ipfw rules catch the packets *twice*. > This is an interface-centric approach. > Other implemenations follow a packet-centric approach, that is: they > define a flow of operations which are applied to the packets as they > travel through the stack. Again, for example Cisco, the flow for a > packet coming into the router and leaving it through another interface: > [...] OK - I understand. So now we are at the point of reconsidering the design. ;-) Let me rephrase that last question: Given the interface centric approach of ipfw and KAME and considering the nature of the -stable branch and POLA, what would be the most reasonable way to improve the situation now? Obviously Cisco's design is superior - I didn't know the details but it was clear from my experience using Cisco equipment that it had to be that way. You can run NAT, IPSec, other sorts of tunnels, FW feature set - all in parallel without one interfering with the other (if configured properly ;-) In FreeBSD it took me considerable thinking and tweaking of rules to get IPSec and NAT working together - the rules look quite simple now that they are done, but at the time it was quite a bit of work. When I tried to add strict ingress filters to the same box, I finally opted out and deployed a second system. But after all, I don't think FreeBSD's design in this area isn't really bad. Limited, maybe, but not bad. Seeing filtering as an action that takes place on a per interface basis does make sense. Ipfw has been in production for quite a while and people seem to understand (!) and to like it. This is important in security relevant subsystems. Doing NAT in an external program with packets passing through divert sockets is a bitch, though. BTW: last time I checked, ipf didn't look any better than ipfw whith respect to this problem. Now I know that it's inherent to the BSD IP stack's interface/queue centric design. Thanks for clearing things up a bit. Regards, Patrick M. Hausen Technical Director -- 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?200211211252.gALCqNj2083276>