From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 17:08:29 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 195D142E for ; Sun, 23 Mar 2014 17:08:29 +0000 (UTC) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D565EE0D for ; Sun, 23 Mar 2014 17:08:28 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wp18so4671594obc.21 for ; Sun, 23 Mar 2014 10:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fhjBBYS/iRr2NrfvnzgMR1UIxfkUaQVV/5CTVNdkF9I=; b=kHwpA5NBACJBHiGSWHyV+E0wgteIfww/DK6WLiPb560HwWDYO6wuK7UnqHrMJpRy9i hNl0BCg6zXbszsLXp9yKybGBqlVi4pYGn+R3UxNVzecPk5gM7aYTj+zhWC+0iY4YlgSX /GY0k8gijegqKhXBk+OrJ+h5AMhnv8VuTRfg9PQmEThATydCdBReWYvktWNM9bq1Mdcs gJCaBJNtGQKxFIv1QBMOpgQYGzK/U1tWWnR54y6TlT0IId2MFwGpdeTkm0AYsDTI95Qe PB0drgr36yFC3zObmljlJVLxcs+B44De/icRDTxWjatt9wREXx1gNsBUtwC0pkqw0nZ2 3CdQ== X-Gm-Message-State: ALoCoQm5852uP/ByOCDrq48HYvoNJBoEvnT4TRUHBqrpFpJUtKGEl8mt/xmyNsc6x0hPbD9vMnDV MIME-Version: 1.0 X-Received: by 10.182.22.135 with SMTP id d7mr22460248obf.1.1395594501839; Sun, 23 Mar 2014 10:08:21 -0700 (PDT) Received: by 10.60.17.33 with HTTP; Sun, 23 Mar 2014 10:08:21 -0700 (PDT) In-Reply-To: <532EF401.80506@freebsd.org> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> <532EF401.80506@freebsd.org> Date: Sun, 23 Mar 2014 10:08:21 -0700 Message-ID: Subject: Re: ipfw dynamic rules From: Michael Sierchio To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:08:29 -0000 Thanks, Julian, this is sort of independent confirmation of something I've been doing. I've heard folks complain about efficiency of NAT (more so when using natd/DIVERT), and then saw that they matched every packet on a nat rule - 2 or 4 times. Some things I abstract from this: Use tables for lists of addresses where there's more than 5 or so. Use skipto (judiciously) Use stateless and stateful rules appropriately Stick to some convention for tables - 13 for bogons, 0 for whitelist RFC1918 addrs, 1 for whitelist public addrs, etc. Separate processing of packets coming in versus going out I have a function in the shell script that loads tables from named files - the contents of tables change without changing the ruleset Packets not destined for "me" will be processed again when they're headed out - you can "allow ip from any to any in" after filtering for the things you do/don't want for "me" - which is the norm for a firewall router protecting internal nets. This is, of course, after early drop for traffic that is obviously "bad" Use rulesets and matching tables to permit atomic table replacement with rule swap I also do policy-based routing with setfib and table arg, which means that as conditions change, I can send traffic from a particular net out a different interface. /sbin/ipfw add set 1 05000 setfib tablearg ip from table\(1\) to any in lookup src-ip 1 NAT is something that should happen first on all packets incoming on an if and last on packets headed out an if - with few exceptions. "Last" except for a final decision to pass or deny the traffic. - M