From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 17:03:49 2014 Return-Path: Delivered-To: svn-doc-head@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 26970A06; Tue, 18 Feb 2014 17:03:49 +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 6A01C1BC7; Tue, 18 Feb 2014 17:03:48 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IH3mMH050659; Tue, 18 Feb 2014 17:03:48 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IH3mTl050658; Tue, 18 Feb 2014 17:03:48 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402181703.s1IH3mTl050658@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 17:03:48 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43977 - 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: Tue, 18 Feb 2014 17:03:49 -0000 Author: dru Date: Tue Feb 18 17:03:47 2014 New Revision: 43977 URL: http://svnweb.freebsd.org/changeset/doc/43977 Log: Make the section on PF NAT clearer. 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 Tue Feb 18 03:59:30 2014 (r43976) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 17:03:47 2014 (r43977) @@ -628,57 +628,64 @@ pass proto udp to any port $udp_services A Simple Gateway with NAT This section demonstrates how to configure a &os; system - which is running PF and also acts + running PF to act as a gateway for at least one other machine. The gateway - has at least two network interfaces, each connected to a - separate network. For example, one connection is to the - Internet and the other is to the internal network. - - It is reasonable to think that for stateful traffic to - pass from the network connected to xl1 - to hosts on the network connected to - xl0, a rule like this is needed: + needs at least two network interfaces, each connected to a + separate network. In this example, xl1 is connected to the + Internet and xl0 is connected to the internal network. + + First, enable the gateway in order to let the + machine forward the network traffic it receives on one + interface to another interface. This sysctl + setting will forward IPv4 packets: + + &prompt.root; sysctl net.inet.ip.forwarding=1 + + To forward IPv6 traffic, use: + + &prompt.root; sysctl net.inet6.ip6.forwarding=1 + + To enable these settings at system boot, add the following + to + /etc/rc.conf: + + gateway_enable="YES" #for ipv4 +ipv6_gateway_enable="YES" #for ipv6 + + Verify with ifconfig that + both of the interfaces are up and + running. + + Next, create the PF rules to + allow the gateway to pass traffic. While the following rule allows stateful traffic to + pass from the Internet + to hosts on the network, the to keyword does not + guarantee passage all the way from source to destination: pass in on xl1 from xl1:network to xl0:network port $ports keep state - However, the to keyword does not - guarantee passage all the way from source to destination. - This rule only lets the traffic pass in to the gateway on + That rule only lets the traffic pass in to the gateway on the internal interface. To let the packets go further, a matching rule is needed: pass out on xl0 from xl1:network to xl0:network port $ports keep state - These rules will work, but they will not necessarily - achieve the desired effect. - - Rules this specific are rarely needed. A better rule - says: + While these two rules will work, rules this specific are + rarely needed. For a busy network admin, a readable ruleset is a safer + ruleset. The remainder of this section demonstrates how to + keep the rules as simple as possible + for readability. For example, those two rules could be + replaced with one rule: pass from xl1:network to any port $ports keep state - This provides local network access to the Internet and - leaves the detective work to the - antispoof and - scrub code. - - For a busy network admin, a readable ruleset is a safer - ruleset. For the remainder of this section, with some - exceptions, we will keep the rules as simple as possible - for readability. - - Above, we introduced the - interface:network notation. That is a - nice piece of shorthand, but the ruleset can be made even - more readable and maintainable by taking the macro use a - tiny bit further. - - For example, a $localnet macro could - be defined as the network directly attached to your - internal interface ($xl1:network in the - examples above). - - Alternatively, the definition of + The + interface:network notation can be + replaced with a macro to make the ruleset even + more readable. For example, a $localnet macro could + be defined as the network directly attached to the + internal interface ($xl1:network). + Alternatively, the definition of $localnet could be changed to an IP address/netmask notation to denote a network, such as 192.168.100.1/24 for @@ -686,55 +693,26 @@ pass proto udp to any port $udp_services If required, $localnet could even be defined as a list of networks. Whatever the specific needs, - a sensible $localnet definition and a - typical pass rule of the type + a sensible $localnet definition could be + used in a + typical pass rule as follows: pass from $localnet to any port $ports keep state - could end up saving you a few headaches. We will stick - to that convention from here on. - - First, we need to turn on gatewaying in order to let the - machine forward the network traffic it receives on one - interface to other networks via a separate interface. - Initially we will do this on the command line with - &man.sysctl.8;, for traditional IP version - four. - - &prompt.root; sysctl net.inet.ip.forwarding=1 - - If we need to forward IP version - six traffic, the command is - - &prompt.root; sysctl net.inet6.ip6.forwarding=1 - - In order for this to continue working after the - computer has been restarted at some time in the future, - enter these settings into - /etc/rc.conf: - - gateway_enable="YES" #for ipv4 -ipv6_gateway_enable="YES" #for ipv6 - - Use ifconfig -a, or - ifconfig interface_name to find out if - both of the interfaces to be used are up and - running. - - If all traffic initiated by machines on the inside is to - be allowed, /etc/pf.conf could look - roughly like this - - For dialup users, the external interface is the - tun0 pseudo-device. Broadband - users such as ADSL subscribers tend to have an - Ethernet interface to play with, however for a - significant subset of ADSL users, specifically those - using PPP over Ethernet (PPPoE), the correct external - interface will be the tun0 - pseudo-device, not the physical Ethernet + The following sample ruleset allows all traffic initiated by + machines on the internal network. It first defines two + macros to represent the external and internal 3COM interfaces of + the gateway. + + + For dialup users, the external interface will use + tun0. For an + ADSL connection, specifically those + using PPP over Ethernet (PPPoE), the correct external + interface is tun0, + not the physical Ethernet interface. - : + ext_if = "xl0" # macro for external interface - use tun0 for PPPoE int_if = "xl1" # macro for internal interface @@ -744,77 +722,56 @@ nat on $ext_if from $localnet to any -&g block all pass from { lo0, $localnet } to any keep state - Note the use of macros to assign logical names to the - network interfaces. Here 3Com cards are used, but this is - the last time during this tutorial we will find this of - any interest whatsoever. In truly simple setups like this - one, we may not gain very much by using macros like these, - but once the rulesets grow somewhat larger, you will - learn to appreciate the readability this provides. - - Also note the nat rule. This is - where we handle the network address translation from the - non-routable address inside the local net to the sole - official address we assume has been assigned. - - The parentheses surrounding the last part of the nat - rule ($ext_if) are there to compensate - for the possibility that the IP address of the external - interface may be dynamically assigned. This detail will - ensure that network traffic runs without serious - interruptions even if the external IP address + This ruleset introduces the nat rule which is used to + handle the network address translation from the + non-routable addresses inside the internal network to the IP address + assigned to the external interface. The parentheses surrounding the last part of the nat + rule ($ext_if) is included + when the IP address of the external + interface is dynamically assigned. It + ensures that network traffic runs without serious + interruptions even if the external IP address changes. - On the other hand, this ruleset probably allows more - traffic to pass out of the network than actually desired. - One reasonable setup could contain the macro + Note that this ruleset probably allows more + traffic to pass out of the network than is needed. + One reasonable setup could create this macro: client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ https, cvspserver, 2628, 5999, 8000, 8080 }" - and the main pass rule + to use in the main pass rule: pass inet proto tcp from $localnet to any port $client_out \ flags S/SA keep state - In addition, we have a few other pass rules. One pass - rule which is useful for administering machines remotely - is: + A few other pass rules may be needed. This one enables + SSH on the external interface:: pass in inet proto tcp to $ext_if port ssh - Lastly we need to make the name service work for our + This macro definition and rule allows + DNS and NTP for internal clients: - udp_services = "{ domain, ntp }" - - This is supplemented with a rule which passes the - traffic we want through our firewall: - - pass quick inet proto { tcp, udp } to any port $udp_services keep state + udp_services = "{ domain, ntp }" +pass quick inet proto { tcp, udp } to any port $udp_services keep state Note the quick keyword in this - rule. We have started writing rulesets which consist of - several rules, and it is time to take a look at the - relationships between the rules in a ruleset. The rules + rule. Since the ruleset consists of + several rules, it is important to understand the + relationships between the rules in a ruleset. Rules are evaluated from top to bottom, in the sequence they are - written in the configuration file. For each packet or + written. For each packet or connection evaluated by PF, - the last matching rule in the rule - set is the one which is applied. The - quick keyword offers an escape from the - ordinary sequence. When a packet matches a quick rule, - the packet is treated according to the present rule. The - rule processing stops without considering any further - rules which might have matched the packet. This is very - useful when a few isolated exceptions to the general rules - are needed. - - This rule also takes care of NTP, - which is used for time synchronization. One thing common - to both protocols is that they may under certain - circumstances communicate alternately over TCP and - UDP. + the last matching rule in the ruleset + is the one which is applied. However, + when a packet matches a rule which + contains the quick keyword, + the rule processing stops and the packet is treated + according to that rule. This is very + useful when an exception to the general rules + is needed.