From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 18:39:20 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED11515C; Fri, 21 Feb 2014 18:39:20 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA6E41E11; Fri, 21 Feb 2014 18:39:20 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LIdK7d098462; Fri, 21 Feb 2014 18:39:20 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LIdK7Z098461; Fri, 21 Feb 2014 18:39:20 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402211839.s1LIdK7Z098461@svn.freebsd.org> From: Dru Lavigne Date: Fri, 21 Feb 2014 18:39:20 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44018 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:39:21 -0000 Author: dru Date: Fri Feb 21 18:39:20 2014 New Revision: 44018 URL: http://svnweb.freebsd.org/changeset/doc/44018 Log: This section is reeeeeally out of date. Modernize the first few keywords. Much more to come. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 17:50:51 2014 (r44017) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 18:39:20 2014 (r44018) @@ -1659,7 +1659,7 @@ ipnat_rules="/etc/ipnat.rules" # rule &prompt.root; service ipfilter start - To load the ruleset file, specify the name of the file using ipf. + To load the firewall rules, specify the name of the ruleset file using ipf. The following command can be used to replace the currently running firewall rules: @@ -1691,9 +1691,13 @@ ipnat_rules="/etc/ipnat.rules" # rule This section describes the IPF rule syntax - used to create stateful rules where the first - matching rule wins. Refer to &man.ipf.8; for more details, including the legacy - rule syntax. + used to create stateful rules. When creating rules, keep in + mind that the default way in which filter rules are applied + is for the last matching rule to be + used. Even if the first rule to match a packet is a + pass, if there is a later matching rule + that is a block, the packet will be dropped. + Refer to &man.ipf.5; for more details about rule syntax. When creating rules, a # character is used to mark the start of a comment and may appear at the end of a rule, to explain its function, @@ -1718,38 +1722,51 @@ ipnat_rules="/etc/ipnat.rules" # rule ACTION The action keyword indicates what to do with the - packet if it matches the rest of the filter rule. Each + packet if it matches that rule. Every rule must have an action. The following actions are recognized: - block indicates that the packet - should be dropped if the selection parameters match the - packet. + block: drops the packet. + + pass: allows the packet. + + log: generates a log record. + + count: counts the number of + packets and bytes which can provide an indication of + how often a rule is used. + + auth: queues the packet for + further processing by another program. - pass indicates that the packet - should exit the firewall if the selection parameters - match the packet. + call: provides access to + functions built into IPF that + allow more complex actions. + + decapsulate: removes any headers + in order to process the contents of the packet. IN-OUT - A mandatory requirement is that each filter rule - explicitly state which side of the I/O it is to be used - on. The next keyword must be either - in or out and one - or the other has to be included or the rule will not - pass syntax checks. - - in means this rule is being - applied against an inbound packet which has just been - received on the interface facing the public - Internet. - - out means this rule is being - applied against an outbound packet destined for the - interface facing the public Internet. + Next, each rule must + explicitly state the direction of traffic using one of + these keywords: + + in: the rule is + applied against an inbound packet. + + out: the rule is + applied against an outbound packet. + + all: the rule applies to either + direction. + + If the system has multiple interfaces, the interface + can be specified along with the direction. An example would + be in on fxp0.