From owner-svn-doc-head@FreeBSD.ORG Fri Feb 14 21:04:16 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 7CB1AC47; Fri, 14 Feb 2014 21:04:16 +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 668A11717; Fri, 14 Feb 2014 21:04:16 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1EL4G6k034349; Fri, 14 Feb 2014 21:04:16 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1EL4GL6034348; Fri, 14 Feb 2014 21:04:16 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402142104.s1EL4GL6034348@svn.freebsd.org> From: Dru Lavigne Date: Fri, 14 Feb 2014 21:04:16 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43929 - 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, 14 Feb 2014 21:04:16 -0000 Author: dru Date: Fri Feb 14 21:04:15 2014 New Revision: 43929 URL: http://svnweb.freebsd.org/changeset/doc/43929 Log: Initial prep work on NAT gateway section. Still a WIP. 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 14 20:37:25 2014 (r43928) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 14 21:04:15 2014 (r43929) @@ -628,25 +628,14 @@ pass proto udp to any port $udp_services A Simple Gateway with NAT - To most users, a single machine setup will be of limited - interest, and at this point we move on to more realistic or - at least more common setups, concentrating on a machine + This section demonstrates how to configure a &os; system which is running PF and also acts - as a gateway for at least one other machine. + 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. - In the single machine setup, life is relatively - simple. Traffic created on it should either pass out to - the rest of the world or not, and the administrator - decides what to let in from elsewhere. - - On a gateway, the perspective changes from - me versus the network out there to - I am the one who decides what to pass to or from - all the networks I am connected to. The machine - has at least two network interfaces, each connected to a - separate net. - - It is very reasonable to think that for traffic to + 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 @@ -654,46 +643,32 @@ pass proto udp to any port $udp_services pass in on xl1 from xl1:network to xl0:network port $ports keep state - This rule keeps track of states as well. - - However, one of the most common and most - complained-about mistakes in firewall configuration is not - realizing that the to keyword does not in - itself guarantee passage all the way there. The rule we - just wrote only lets the traffic pass in to the gateway on - the internal interface. To let the packets get a bit - further, a matching rule is needed which says + However, the to keyword does + guarantee passage all the way from source to destination. This 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. For the basic - gateway configurations we will be dealing with here, a - better rule says + Rules this specific are rarely needed. A + better rule says: pass from xl1:network to any port $ports keep state - This provides local net access to the Internet and + This provides local network access to the Internet and leaves the detective work to the antispoof and - scrub code. They are both pretty - good these days, and we will get back to them later. For - now we just accept the fact that for simple setups, - interface-bound rules with in/out rules tend to add more - clutter than they are worth to rulesets. + scrub code. For a busy network admin, a readable ruleset is a - safer ruleset. - - For the remainder of this section, with some + safer ruleset. For the remainder of this section, with some exceptions, we will keep the rules as simple as possible for readability. - - What is the Local Network, Anyway? - Above, we introduced the interface:network notation. That is a nice piece of shorthand, but the ruleset can be made even @@ -720,21 +695,6 @@ pass proto udp to any port $udp_services could end up saving you a few headaches. We will stick to that convention from here on. - - - - Setting Up - - We assume that the machine has acquired another - network card or at any rate there is a network - connection from the local network, via PPP or other - means. We will not consider the specific interface - configurations. - - For the discussion and examples below, only the - interface names will differ between a PPP setup and an - Ethernet one, and we will do our best to get rid of the - actual interface names as quickly as possible. First, we need to turn on gatewaying in order to let the machine forward the network traffic it receives on one @@ -820,25 +780,13 @@ pass from { lo0, $localnet } to any keep pass inet proto tcp from $localnet to any port $client_out \ flags S/SA keep state - This may be a somewhat peculiar selection of ports, - but it is based on a real life example. Individual needs - probably differ at least in some specifics, but this - should cover at least some of the more useful - services. - - In addition, we have a few other pass rules. We will - be returning to some of the more interesting ones rather - soon. One pass rule which is useful to those of us who - want the ability to administer our machines from elsewhere - is - - pass in inet proto tcp to port ssh - - or for that matter + In addition, we have a few other pass rules. One pass rule which is useful for + administering machines remotely + is: pass in inet proto tcp to $ext_if port ssh - whichever is preferred. Lastly we need to make the + Lastly we need to make the name service work for our clients: udp_services = "{ domain, ntp }" @@ -870,11 +818,10 @@ pass from { lo0, $localnet } to any keep to both protocols is that they may under certain circumstances communicate alternately over TCP and UDP. - - That Sad Old <acronym>FTP</acronym> Thing + Creating an <acronym>FTP</acronym> Proxy The short list of real life TCP ports above contained, among other things, FTP. @@ -923,10 +870,6 @@ pass from { lo0, $localnet } to any keep program which is written specifically for this purpose. - - <acronym>FTP</acronym> Via Redirect: - <application>ftp-proxy</application> - Enabling FTP transfers through your gateway is amazingly simple, thanks to the FTP proxy program (called @@ -1015,11 +958,10 @@ rdr-anchor "ftp-proxy/*"ftp-proxy in reverse mode (using ), on a separate port with its own redirecting pass rule. - - Easing Troubleshooting + Managing <acronym>ICMP</acronym> Making network troubleshooting friendly is a potentially large subject. At most times, the debugging or @@ -1069,9 +1011,6 @@ rdr-anchor "ftp-proxy/*" - - Then, Do We Let it All Through? - The obvious question then becomes, if ICMP is such a good and useful thing, should we not let it all through, all the time? The @@ -1090,10 +1029,6 @@ rdr-anchor "ftp-proxy/*"ICMP traffic might be found quite harmlessly riding piggyback on keep state rules. - - - - The Easy Way Out: the Buck Stops Here The easiest solution could very well be to let all ICMP traffic from the local net through @@ -1106,7 +1041,6 @@ pass inet proto icmp from any to $ext_if option anyway, but let us have a look at a few other options which will show some of PF's flexibility. - Letting <command>ping</command> Through