Date: Tue, 14 Dec 2004 13:12:31 -0500 From: James <james@towardex.com> To: Andre Oppermann <andre@freebsd.org> Cc: Max Laier <max@love2party.net> Subject: Re: per-interface packet filters [summary] Message-ID: <20041214181231.GA80817@scylla.towardex.com> In-Reply-To: <41BF07A3.8F1F505E@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> <41BF07A3.8F1F505E@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 14, 2004 at 04:32:51PM +0100, Andre Oppermann wrote: > See below. > > > > Wouldn't it be even better to have per-interface and global rules > > > after each other? This way your problem with the general rule > > > synching can be solved. > > > > this is what gleb suggested later today, but i don't think > > this solves the problem because sometimes you want the common > > processing to be at the beginning, sometimes at the end of the > > chain... Plus there is the issue of namespace -- when you do > > 'skipto 1000' is this a rule number in the global or the > > private chain ? Having only *one* chain (either public or > > private) solves the problem although at the price of some > > extra copies of the firewall code. > > I've got something in mind marrying the global/interface approach > based on my experience of managing large Cisco per-interface ACL's > (which is a royal pain to get right). The big problem of the per- > interface approach is the protection of the host itself (control > plane in Cisco speak). They have fixed it in newest IOS with so > called infrastructure ACL's but that is making life only a little > better. Yes, it's called receive path ACL. Even if you are using global approach (the way we are now), you still have to deal with receive path to protect your own router-destined traffic. The idea of receive path is to mainly increase the performance and ease the configuration -- there is *no* reason a transit traffic should go thru every rules of a global ruleset like the way it is now (yes, you can avoid this by using bunch of tricks in ipfw, but that is makeshift hack than "doing it right in the beginning" approach). The way we have approached this in the past is to install /32 host routes for each interface addr's and respective subnet and broadcast /32 addresses into the kernel RIB, destined to lo0 interface. Place your per-interface filter on 'lo0' interface and packets destined to router iteslf will be subject to loopback filter before making it onto upper layer protocol. Also, by creating a receive adjacency, you can completely get rid of the unnecessary hash lookups in ip_fastforward() that determine whether packet is destined to us or not. We are already doing an expensive radix lookup on the kernel RIB -- that alone is well enough to give us the information we need with respect to what needs to be done to the packet. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041214181231.GA80817>