From owner-freebsd-doc@FreeBSD.ORG Mon May 26 05:20:01 2014 Return-Path: Delivered-To: freebsd-doc@smarthost.ysv.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 55394EA7 for ; Mon, 26 May 2014 05:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3526B2717 for ; Mon, 26 May 2014 05:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4Q5K16x078413 for ; Mon, 26 May 2014 05:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4Q5K1jY078412; Mon, 26 May 2014 05:20:01 GMT (envelope-from gnats) Date: Mon, 26 May 2014 05:20:01 GMT Message-Id: <201405260520.s4Q5K1jY078412@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org Cc: From: venture37 Subject: Re: docs/116588: No IPFW tables or dummynet in Handbook Reply-To: venture37 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 05:20:01 -0000 The following reply was made to PR docs/116588; it has been noted by GNATS. From: venture37 To: bug-followup@FreeBSD.org, cristi@net.utcluj.ro Cc: Subject: Re: docs/116588: No IPFW tables or dummynet in Handbook Date: Mon, 26 May 2014 06:11:45 +0100 This is a multi-part message in MIME format. --------------080201090104010609090803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is an updated diff which adds instructions for dummynet & utilising tables alongside adjustments highlighted by igor. One issue which I was unable to fix was 450:bad tag indent: By default, PF reads its --------------080201090104010609090803 Content-Type: text/plain; charset=UTF-8; name="ipfw.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipfw.txt" Index: en_US.ISO8859-1/books/handbook/firewalls/chapter.xml =================================================================== --- en_US.ISO8859-1/books/handbook/firewalls/chapter.xml (revision 44952) +++ en_US.ISO8859-1/books/handbook/firewalls/chapter.xml (working copy) @@ -398,7 +398,7 @@ - By default, PF reads its - configuration rules from /etc/pf.conf and - modifies, drops, or passes packets according to the rules or - definitions specified in this file. The &os; installation - includes several sample files located in - /usr/share/examples/pf/. Refer to the - PF - FAQ for complete coverage - of PF rulesets. +By default, PF reads its + configuration rules from /etc/pf.conf and + modifies, drops, or passes packets according to the rules or + definitions specified in this file. The &os; installation includes + several sample files located in + /usr/share/examples/pf/. Refer to the PF FAQ for + complete coverage of PF rulesets. - To control PF, use - pfctl. summarizes +To control PF, use + pfctl. summarizes some useful options to this command. Refer to &man.pfctl.8; for a description of all available options: @@ -1702,8 +1701,9 @@ firewall rules. - filename: full path of the file - containing the firewall ruleset. + filename: + full path of the file containing the firewall + ruleset. @@ -2312,7 +2312,7 @@ On the inbound side, the ruleset has to deny bad packets and allow only authorized services. A packet which matches an inbound rule is posted to the dynamic state table and the - packet is released to the LAN. The packet + packet is released to the LAN. The packet generated as a response is recognized by the check-state rule as belonging to an existing session. It is then sent to rule @@ -2614,12 +2614,192 @@ &prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state - - - IPFILTER (IPF) + + Using Dummynet - + &man.dummynet.4; is a traffic shaper, bandwidth manager + and delay emulator which may be used to simulate different + types of physical links. It can also be "misused" + as a traffic shaper. + + &man.dummynet.4; offers two objects. Pipes are an + abstraction of a given link, having a certain bandwidth, delay + and loss. Queues are an abstraction used to implement + weighted fair queuing. In practice, pipes can be used to set + hard limits to the bandwidth that a flow can use, wheres + queues can be used to determine how different flows share that + bandwidth. + + To ensure that &man.dummynet.4; is loaded at boot time add + the following line to + /boot/loader.conf: + + dummynet_load="YES" + + Please note that in order for &man.dummynet.4; to work + correctly, it is highly recommended to increase the system + clock tick rate. This can be accomplished by adding the + following option to kernel configuration files. + + options HZ=1000 + + Use the following command to configure a pipe which has + 4Kbps and a 100ms delay: + + &prompt.root; ipfw pipe 10 config bw 4Kbit/s delay 100 + + To use this pipe, i.e have some traffic go through it, + use the following command: + + &prompt.root; ipfw -q add pipe 10 all from 10.0.0.0/24 to any + + Please note that to properly limit users, one should + create separate pipes for upload and download. + + Using the above pipe configuration, all LAN users compete + for the same bandwidth. If you would like to assign each of + them 4Kbps upload and download, you may create dynamic pipes + based on the source IP (for uplink) or destination IP (for + downlink): + + &prompt.root; ipfw pipe 10 config bw 4Kbit/s src-ip 0xffffffff +&prompt.root; ipfw pipe 11 config bw 4Kbit/s dst-ip 0xffffffff +&prompt.root; ipfw -q add pipe 10 all from any to any recv $if_lan +&prompt.root; ipfw -q add pipe 11 all from any to any xmit $if_lan + + + + Using Tables + + Tables are a way of referring to multiple IP addresses + using a single identifier. They are useful in the following + situations: + + + + you must apply the same rule to a lot of IP + addresses (table lookups are fast) + + + you must apply a lot of rules to some IP addresses + (use tables to add / remove IP addresses from a single + location in the ruleset) + + + + IP addresses stored in a table may also have an optional + 32-bit unsigned value assigned to them. A rule may be written + in such a way that it will only match if the IP found in + a table has been assigned a specific value. + + These are the commands used to manipulate tables from the + shell: + + Clear all IP addresses from a table: + + &prompt.root; ipfw table 10 flush + + Add a single IP address to a table: + + &prompt.root; ipfw table 10 add 172.27.0.1 + + Add a CIDR network to a table: + + &prompt.root; ipfw table 10 add 192.168.0.0/24 + + Add a CIDR network to a table and also assign a value to + it: + + &prompt.root; ipfw table 10 add 192.168.0.0/24 100 + + List the contents of a table: + + &prompt.root; ipfw table 10 list + + To use the table in a firewall rule: + + &prompt.root; ipfw -q add allow tcp from "table(10)" to any + + Or, to use the table and the value in a firewall + rule: + + &prompt.root; ipfw -q add allow tcp from "table(10,100)" to any + + The following listing is an example of how one could use + tables in a ruleset: + + #!/bin/sh +# Flush out the list before we begin. +ipfw -q -f flush + +# Set rules command prefix +cmd="ipfw -q add" +table="ipfw -q table" + +# Create a table with all IPs allowed to connect to SSH +$table 1 flush # required +$table 1 add 172.27.0.1 # single IP address +$table 1 add 192.168.0.0/24 # CIDR network + +# Actual rule which allows SSH +$cmd allow from "table(1)" to me 22 keep-state + +# Deny everything else +$cmd deny from any to any + + Here is another example, in which tables and values are + used to group clients into multiple bandwidth limitations + depending on their subscription: + + #!/bin/sh +# Flush out the list before we begin. +ipfw -q -f flush + +# Set rules command prefix +cmd="ipfw -q add" +table="ipfw -q table" +pipe="ipfw -q pipe" +if_net="em0" + +# +# Pipes +# + +# Please note that dynamic pipes will be created for each client. +# In other words, clients DO NOT compete for the bandwidth. + +# First subscription rate. +$pipe 10 config queue 10 bw 512Kbit/s mask src-ip 0xffffffff # uplink +$pipe 11 config queue 10 bw 512Kbit/s mask dst-ip 0xffffffff # downlink + +# Second subscription rate. +$pipe 20 config queue 10 bw 768Kbit/s mask src-ip 0xffffffff # uplink +$pipe 21 config queue 10 bw 768Kbit/s mask dst-ip 0xffffffff # downlink + +# Create a table with all IPs allowed to have Internet connection. +# Note that although it is not required, values are the same +# as the bandwidth which will be given to the client. +$table 1 flush # required +$table 1 add 172.27.0.2 512 # 512Kbps client +$table 1 add 172.27.0.3 768 # 768Kbps client +$table 1 add 172.27.0.4 512 # 512Kbps client + +# Actual rules which classify the traffic +$cmd pipe 10 all from "table(1,512)" to any xmit $if_net +$cmd pipe 11 all from any to "table(1,512)" recv $if_net +$cmd pipe 20 all from "table(1,768)" to any xmit $if_net +$cmd pipe 21 all from any to "table(1,768)" recv $if_net + +# Deny everything else +$cmd deny all from any to any + + + + + IPFILTER (IPF) + + firewall IPFILTER --------------080201090104010609090803--