From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 19 08:50:03 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF1B01065684 for ; Wed, 19 Mar 2008 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCEB8FC17 for ; Wed, 19 Mar 2008 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2J8o3x0081588 for ; Wed, 19 Mar 2008 08:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2J8o3Pw081587; Wed, 19 Mar 2008 08:50:03 GMT (envelope-from gnats) Date: Wed, 19 Mar 2008 08:50:03 GMT Message-Id: <200803190850.m2J8o3Pw081587@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Vadim Goncharov Cc: Subject: Re: kern/121807: Sugestion: TCP and UDP port_table in ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vadim Goncharov List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 08:50:03 -0000 The following reply was made to PR kern/121807; it has been noted by GNATS. From: Vadim Goncharov To: Joao Rocha Braga Filho Cc: bug-followup@freebsd.org Subject: Re: kern/121807: Sugestion: TCP and UDP port_table in ipfw Date: Wed, 19 Mar 2008 14:47:01 +0600 Hi Joao Rocha Braga Filho! On Mon, 17 Mar 2008 20:15:12 GMT; Joao Rocha Braga Filho wrote: > Why not exist a TCP/UDP port_table for IPFW? It can solve 30 itens limit in ipfw rule. It is good to use in QoS. > Example > ipfw add allow { tcp or udp } from any port_table(10) to any > ipfw port_table 10 add 20,21,25,110,443,993,995,1025-65535 > # Deny bad ports > ipfw add deny { tcp or udp } from any to any port_table(11) > ipfw port_table 11 add 135,137-139,445 > ipfw add queue 100 udp from any port_table(20) to any > ipfw port_table(20) add 123,53 For what puprose should it _really_ serve? Limit-upping? Per-packet speed optimisation? More handy config preapring? Should that tables serve as a collection-only, or do have tableargs, and for what practical purpose that tableargs would be useful? If it is simply annoying to put long list in config several times, then it is correctly solved by shell vars: good_ports="20,21,25,110,443,993,995,1025-65535" ipfw add allow { tcp or udp } from any $good_ports to any ipfw add allow { tcp or udp } from ant to $my_server $good_ports If you care about both value-repeating, limit of 30 items and slightly about speed of packet processing, then you'd better classify your traffic with or-blocks on start of ruleset with tags: ipfw add 1 count tag 1 { src-port 20,21,25,110,443,993,995,1025-65535 \ or src-port 1,2,3,4,5,6,7,8,9,10,11,12,13,...long-list2...,29,30 \ or src-port ...list3... } // can have up to 8 full 30-port blocks per rule ipfw add 2 count tag 2 dst-port 135,137-139,445 // and so on Packet can have more than one tag at a time, so then you can write like: ipfw add queue 100 udp from any to any tagged 3 ipfw add allow { tcp or udp } from any to any tagged 1,2 And if your suggested port table is concerned on a per-packet performance, like our IP tables do, then how do you suggest it to be implemented in-kernel? Current tables for IP are radix trees, they consume a lot of kernel memory (which is a scarce resource) and process in term of mask - but it is not handy to specify ports in form like "128/8". And any form of tree will consume to a lot of memory per entry. It can be thought as a bit set, one bit for every port, very fast, but will consume 8K per one table - 1 meg for 128 such tables, unacceptable, again. So, I think it is best to use tags for your purposes. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]