Skip site navigation (1)Skip section navigation (2)
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>