Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
IPFW(8)                 FreeBSD System Manager's Manual                IPFW(8)

     ipfw - IP firewall and traffic shaper control program

     ipfw [-q] [-p preproc [-D macro[=value]] [-U macro]] pathname
     ipfw [-f | -q] flush
     ipfw [-q] {zero | resetlog | delete} [number ...]
     ipfw [-s [field]] [-adeftN] {list | show} [number ...]
     ipfw [-q] add [number] rule-body
     ipfw pipe number config pipe-config-options
     ipfw pipe {delete | list | show} [number ...]
     ipfw queue number config queue-config-options
     ipfw queue {delete | list | show} [number ...]

     ipfw is the user interface for controlling the ipfirewall(4) and the
     dummynet(4) traffic shaper in FreeBSD.

     A firewall configuration is made of a list of numbered rules, which is
     scanned for each incoming or outgoing IP packet until a match is found
     and the relevant action is performed.  Depending on the action and
     certain system settings, packets can be reinjected into the firewall at
     the rule after the matching one for further processing.  All rules apply
     to all interfaces, so it is responsibility of the system administrator to
     write the ruleset in such a way as to minimize the number of checks.

     A configuration always includes a DEFAULT rule (numbered 65535) which
     cannot be modified, and matches all packets.  The action associated with
     the default rule can be either deny or allow depending on how the kernel
     is configured.

     If the ruleset includes one or more rules with the keep-state or limit
     option, then ipfw assumes a stateful behaviour, i.e. upon a match it will
     create dynamic rules matching the exact parameters (addresses and ports)
     of the matching packet.

     These dynamic rules, which have a limited lifetime, are checked at the
     first occurrence of a check-state or keep-state rule, and are typically
     used to open the firewall on-demand to legitimate traffic only.  See the
     RULE FORMAT and EXAMPLES sections below for more information on the
     stateful behaviour of ipfw.

     All rules (including dynamic ones) have a few associated counters: a
     packet count, a byte count, a log count and a timestamp indicating the
     time of the last match.  Counters can be displayed or reset with ipfw

     Rules can be added with the add command; deleted individually with the
     delete command, and globally with the flush command; displayed,
     optionally with the content of the counters, using the show and list
     commands.  Finally, counters can be reset with the zero and resetlog

     The following options are available:

     -a      While listing, show counter values.  The show command just
             implies this option.

     -d      While listing, show dynamic rules in addition to static ones.

     -e      While listing, if the -d option was specified, also show expired
             dynamic rules.

     -f      Don't ask for confirmation for commands that can cause problems
             if misused, i.e. flush.  Note, if there is no tty associated with
             the process, this is implied.

     -q      While adding, zeroing, resetlogging or flushing, be quiet about
             actions (implies -f).  This is useful for adjusting rules by
             executing multiple ipfw commands in a script (e.g.,
             `sh /etc/rc.firewall'), or by processing a file of many ipfw
             rules, across a remote login session.  If a flush is performed in
             normal (verbose) mode (with the default kernel configuration), it
             prints a message.  Because all rules are flushed, the message
             cannot be delivered to the login session.  This causes the remote
             login session to be closed and the remainder of the ruleset is
             not processed.  Access to the console is required to recover.

     -t      While listing, show last match timestamp.

     -N      Try to resolve addresses and service names in output.

     -s [field]
             While listing pipes, sort according to one of the four counters
             (total and current packets or bytes).

     To ease configuration, rules can be put into a file which is processed
     using ipfw as shown in the first synopsis line.  An absolute pathname
     must be used.  The file will be read line by line and applied as
     arguments to the ipfw utility.

     Optionally, a preprocessor can be specified using -p preproc where
     pathname is to be piped through.  Useful preprocessors include cpp(1) and
     m4(1).  If preproc doesn't start with a slash (`/') as its first
     character, the usual PATH name search is performed.  Care should be taken
     with this in environments where not all filesystems are mounted (yet) by
     the time ipfw is being run (e.g. when they are mounted over NFS).  Once
     -p has been specified, optional -D and -U specifications can follow and
     will be passed on to the preprocessor.  This allows for flexible
     configuration files (like conditionalizing them on the local hostname)
     and the use of macros to centralize frequently required arguments like IP

     The ipfw pipe commands are used to configure the traffic shaper, as shown
     in the TRAFFIC SHAPER CONFIGURATION section below.

     The ipfw rule format is the following:

     [prob match_probability] action [log [logamount number]] proto from src
     to dst [interface-spec] [options]

     Each packet can be filtered based on the following information that is
     associated with it:

           Transmit and receive interface     (by name or address)
           Direction                          (incoming or outgoing)
           Source and destination IP address  (possibly masked)
           Protocol                           (TCP, UDP, ICMP, etc.)
           Source and destination port        (lists, ranges or masks)
           TCP flags
           IP fragment flag
           IP options
           ICMP types
           User/group ID of the socket associated with the packet

     Note that it may be dangerous to filter on the source IP address or
     source TCP/UDP port because either or both could easily be spoofed.

     prob match_probability
             A match is only declared with the specified probability (floating
             point number between 0 and 1).  This can be useful for a number
             of applications such as random packet drop or (in conjunction
             with dummynet(4)) to simulate the effect of multiple paths
             leading to out-of-order packet delivery.


             allow   Allow packets that match rule.  The search terminates.
                     Aliases are pass, permit and accept.

             deny    Discard packets that match this rule.  The search
                     terminates.  drop is an alias for deny.

             reject  (Deprecated).  Discard packets that match this rule, and
                     try to send an ICMP host unreachable notice.  The search

             unreach code
                     Discard packets that match this rule, and try to send an
                     ICMP unreachable notice with code code, where code is a
                     number from 0 to 255, or one of these aliases: net, host,
                     protocol, port, needfrag, srcfail, net-unknown,
                     host-unknown, isolated, net-prohib, host-prohib, tosnet,
                     toshost, filter-prohib, host-precedence or
                     precedence-cutoff.  The search terminates.

             reset   TCP packets only.  Discard packets that match this rule,
                     and try to send a TCP reset (RST) notice.  The search

             count   Update counters for all packets that match rule.  The
                     search continues with the next rule.

                     Checks the packet against the dynamic ruleset.  If a
                     match is found then the search terminates, otherwise we
                     move to the next rule.  If no check-state rule is found,
                     the dynamic ruleset is checked at the first keep-state

             divert port
                     Divert packets that match this rule to the divert(4)
                     socket bound to port port.  The search terminates.

             tee port
                     Send a copy of packets matching this rule to the
                     divert(4) socket bound to port port.  The search
                     terminates and the original packet is accepted (but see
                     section BUGS below).

             fwd ipaddr[,port]
                     Change the next-hop on matching packets to ipaddr, which
                     can be an IP address in dotted quad or a host name.  If
                     ipaddr is not a directly-reachable address, the route as
                     found in the local routing table for that IP is used
                     instead.  If ipaddr is a local address, then on a packet
                     matching a fwd rule, it will be diverted to port on the
                     local machine, keeping the local address of the socket
                     set to the original IP address the packet was destined
                     for.  This makes the netstat(1) entry look rather wierd
                     but is intended for use with transparent proxy servers.
                     If the IP is not a local address then the port number (if
                     specified) is ignored.  This will also map addresses when
                     packets are generated locally.  The search terminates if
                     this rule matches.  If the port number is not given then
                     the port number in the packet is used, so that a packet
                     for an external machine port Y would be forwarded to
                     local port Y.  The kernel must have been compiled with
                     the IPFIREWALL_FORWARD option.  Bridging interferes with
                     forwarding of packets not destined to the local system as
                     they bypass ip_input() and ip_output() where forwarding
                     is implemented.  The fwd action does not change the
                     contents of the packet at all so packets forwarded to
                     another system will usually be rejected by that system
                     unless there is a matching rule on that system to capture

             pipe pipe_nr
                     Pass packet to a dummynet(4) ``pipe'' (for bandwidth
                     limitation, delay, etc.).  See the TRAFFIC SHAPER
                     CONFIGURATION section for further information.  The
                     search terminates; however, on exit from the pipe and if
                     the sysctl(8) variable net.inet.ip.fw.one_pass is not
                     set, the packet is passed again to the firewall code
                     starting from the next rule.

             queue queue_nr
                     Pass packet to a dummynet(4) ``queue'' (for bandwidth
                     limitation using WF2Q).

             skipto number
                     Skip all subsequent rules numbered less than number.  The
                     search continues with the first rule numbered number or

     log [logamount number]
             If the kernel was compiled with IPFIREWALL_VERBOSE, then when a
             packet matches a rule with the log keyword a message will be
             logged to syslogd(8) with a LOG_SECURITY facility.  Note: by
             default, they are appended to the /var/log/security file (see
             syslog.conf(5)).  If the kernel was compiled with the
             IPFIREWALL_VERBOSE_LIMIT option, then by default logging will
             cease after the number of packets specified by the option are
             received for that particular chain entry, and
             net.inet.ip.fw.verbose_limit will be set to that number.
             However, if logamount number is used, that number will be the
             logging limit rather than net.inet.ip.fw.verbose_limit, where the
             value ``0'' removes the logging limit.  Logging may then be re-
             enabled by clearing the logging counter or the packet counter for
             that entry.

             Console logging and the log limit are adjustable dynamically
             through the sysctl(8) interface in the MIB base of

     proto   An IP protocol specified by number or name (for a complete list
             see /etc/protocols).  The ip or all keywords mean any protocol
             will match.

     src and dst:
             any | me | [not] <address/mask> [ports]

             Specifying any makes the rule match any IP address.

             Specifying me makes the rule match any IP address configured on
             an interface in the system.

             The <address/mask> may be specified as:

             ipno       An IP number of the form  Only this exact IP
                        number will match the rule.

             ipno/bits  An IP number with a mask width of the form
                        In this case all IP numbers from to
                        will match.

             ipno:mask  An IP number with a mask of the form
                In this case all IP numbers
                        from to will match.

             The sense of the match can be inverted by preceding an address
             with the not modifier, causing all other addresses to be matched
             instead.  This does not affect the selection of port numbers.

             With the TCP and UDP protocols, optional ports may be specified


             The `-' notation specifies a range of ports (including

             The `:' notation specifies a port and a mask, a match is declared
             if the port number in the packet matches the one in the rule,
             limited to the bits which are set in the mask.

             Service names (from /etc/services) may be used instead of numeric
             port values.  A range may only be specified as the first value,
             and the length of the port list is limited to IP_FW_MAX_PORTS
             ports (as defined in /usr/src/sys/netinet/ip_fw.h).  A backslash
             (`\') can be used to escape the dash (`-') character in a service

                   ipfw add count tcp from any ftp\\-data-ftp to any

             Fragmented packets which have a non-zero offset (i.e. not the
             first fragment) will never match a rule which has one or more
             port specifications.  See the frag option for details on matching
             fragmented packets.

             Some combinations of the following specifiers are allowed:

             in        Only match incoming packets.

             out       Only match outgoing packets.

             via ifX   Packet must be going through interface ifX.

             via if*   Packet must be going through interface ifX, where X is
                       any unit number.

             via any   Packet must be going through some interface.

             via ipno  Packet must be going through the interface having IP
                       address ipno.

             The via keyword causes the interface to always be checked.  If
             recv or xmit is used instead of via, then only the receive or
             transmit interface (respectively) is checked.  By specifying
             both, it is possible to match packets based on both receive and
             transmit interface, e.g.:

                   ipfw add 100 deny ip from any to any out recv ed0 xmit ed1

             The recv interface can be tested on either incoming or outgoing
             packets, while the xmit interface can only be tested on outgoing
             packets.  So out is required (and in is invalid) whenever xmit is
             used.  Specifying via together with xmit or recv is invalid.

             A packet may not have a receive or transmit interface: packets
             originating from the local host have no receive interface, while
             packets destined for the local host have no transmit interface.


                     Upon a match, the firewall will create a dynamic rule,
                     whose default behaviour is to matching bidirectional
                     traffic between source and destination IP/port using the
                     same protocol.  The rule has a limited lifetime
                     (controlled by a set of sysctl(8) variables), and the
                     lifetime is refreshed every time a matching packet is

             limit {src-addr | src-port | dst-addr | dst-port} N
                     The firewall will only allow N connections with the same
                     set of parameters as specified in the rule.  One or more
                     of source and destination addresses and ports can be

                     Matches only bridged packets.  This can be useful for
                     multicast or broadcast traffic, which would otherwise
                     pass through the firewall twice: once during bridging,
                     and a second time when the packet is delivered to the
                     local stack.

                     Apart from a small performance penalty, this would be a
                     problem when using pipes because the same packet would be
                     accounted for twice in terms of bandwidth, queue
                     occupation, and also counters.

             frag    Match if the packet is a fragment and this is not the
                     first fragment of the datagram.  frag may not be used in
                     conjunction with either tcpflags or TCP/UDP port

             ipoptions spec
                     Match if the IP header contains the comma separated list
                     of options specified in spec.  The supported IP options

                     ssrr (strict source route), lsrr (loose source route), rr
                     (record packet route) and ts (timestamp).  The absence of
                     a particular option may be denoted with a `!'.

             tcpoptions spec
                     Match if the TCP header contains the comma separated list
                     of options specified in spec.  The supported TCP options

                     mss (maximum segment size), window (tcp window
                     advertisement), sack (selective ack), ts (rfc1323
                     timestamp) and cc (rfc1644 t/tcp connection count).  The
                     absence of a particular option may be denoted with a `!'.

                     TCP packets only.  Match packets that have the RST or ACK
                     bits set.

             setup   TCP packets only.  Match packets that have the SYN bit
                     set but no ACK bit.

             tcpflags spec
                     TCP packets only.  Match if the TCP header contains the
                     comma separated list of flags specified in spec.  The
                     supported TCP flags are:

                     fin, syn, rst, psh, ack and urg.  The absence of a
                     particular flag may be denoted with a `!'.  A rule which
                     contains a tcpflags specification can never match a
                     fragmented packet which has a non-zero offset.  See the
                     frag option for details on matching fragmented packets.

             icmptypes types
                     ICMP packets only.  Match if the ICMP type is in the list
                     types.  The list may be specified as any combination of
                     ranges or individual types separated by commas.  The
                     supported ICMP types are:

                     echo reply (0), destination unreachable (3), source
                     quench (4), redirect (5), echo request (8), router
                     advertisement (9), router solicitation (10), time-to-live
                     exceeded (11), IP header bad (12), timestamp request
                     (13), timestamp reply (14), information request (15),
                     information reply (16), address mask request (17) and
                     address mask reply (18).

             uid user
                     Match all TCP or UDP packets sent by or received for a
                     user.  A user may be matched by name or identification

             gid group
                     Match all TCP or UDP packets sent by or received for a
                     group.  A group may be matched by name or identification

     The ipfw utility is also the user interface for the dummynet(4) traffic
     shaper.  The shaper operates by dividing packets into flows according to
     a user-specified mask on different fields of the IP header.  Packets
     belonging to the same flow are then passed to two different objects,
     named pipe or queue.

     A pipe emulates a link with given bandwidth, propagation delay, queue
     size and packet loss rate.  Packets transit through the pipe according to
     its parameters.

     A queue is an abstraction used to implement the WF2Q+ policy.  The queue
     associates to each flow a weight and a reference pipe.  Then, all flows
     linked to the same pipe are scheduled at the rate fixed by the pipe
     according to the WF2Q+ policy.

     The ipfw pipe configuration format is the following:

     pipe number config [bw bandwidth | device] [delay ms-delay] [queue {slots
     | size}] [plr loss-probability] [mask mask-specifier] [buckets
     hash-table-size] [red | gred w_q/min_th/max_th/max_p]

     The ipfw queue configuration format is the following:

     queue number config [pipe pipe_nr] [weight weight] [queue {slots | size}]
     [plr loss-probability] [mask mask-specifier] [buckets hash-table-size]
     [red | gred w_q/min_th/max_th/max_p]

     The following parameters can be configured for a pipe:

     bw bandwidth | device
             Bandwidth, measured in [K|M]{bit/s|Byte/s}.

             A value of 0 (default) means unlimited bandwidth.  The unit must
             follow immediately the number, as in

                   ipfw pipe 1 config bw 300Kbit/s queue 50KBytes

             If a device name is specified instead of a numeric value, then
             the transmit clock is supplied by the specified device.  At the
             moment only the tun(4) device supports this functionality, for
             use in conjunction with ppp(8).

     delay ms-delay
             Propagation delay, measured in milliseconds.  The value is
             rounded to the next multiple of the clock tick (typically 10ms,
             but it is a good practice to run kernels with ``options HZ=1000''
             to reduce the granularity to 1ms or less).  Default value is 0,
             meaning no delay.

     queue {slots | sizeKbytes}
             Queue size, in slots or KBytes.  Default value is 50 slots, which
             is the typical queue size for Ethernet devices.  Note that for
             slow speed links you should keep the queue size short or your
             traffic might be affected by a significant queueing delay.  E.g.,
             50 max-sized ethernet packets (1500 bytes) mean 600Kbit or 20s of
             queue on a 30Kbit/s pipe.  Even worse effect can result if you
             get packets from an interface with a much larger MTU, e.g. the
             loopback interface with its 16KB packets.

     plr packet-loss-rate
             Packet loss rate.  Argument packet-loss-rate is a floating-point
             number between 0 and 1, with 0 meaning no loss, 1 meaning 100%
             loss.  The loss rate is internally represented on 31 bits.

     mask mask-specifier
             The dummynet(4) lets you to create per-flow queues.  A flow
             identifier is constructed by masking the IP addresses, ports and
             protocol types as specified in the pipe configuration.  Packets
             with the same identifier after masking fall into the same queue.
             Available mask specifiers are a combination of the following:
             dst-ip mask, src-ip mask, dst-port mask, src-port mask, proto
             mask or all, where the latter means all bits in all fields are
             significant.  When used within a pipe configuration, each flow is
             assigned a rate equal to the rate of the pipe.  When used within
             a queue configuration, each flow is assigned a weight equal to
             the weight of the queue, and all flows insisting on the same pipe
             share bandwidth proportionally to their weight.

     buckets hash-table-size
             Specifies the size of the hash table used for storing the various
             queues.  Default value is 64 controlled by the sysctl(8) variable
             net.inet.ip.dummynet.hash_size, allowed range is 16 to 1024.

     pipe pipe_nr
             Connects a queue to the specified pipe.  Multiple queues (usually
             with different weights) can be connected to the same pipe, which
             specifies the aggregate rate for the set of queues.

     weight weight
             Specifies the weight to be used for flows matching this queue.
             The weight must be in the range 1..100, and defaults to 1.

     red | gred w_q/min_th/max_th/max_p
             Make use of the RED queue management algorithm.  w_q and max_p
             are floating point numbers between 0 and 1 (0 not included),
             while min_th and max_th are integer numbers specifying thresholds
             for queue management (thresholds are computed in bytes if the
             queue has been defined in bytes, in slots otherwise).  The
             dummynet(4) also supports the gentle RED variant (gred).  Three
             sysctl(8) variables can be used to control the RED behaviour:

                     specifies the accuracy in computing the average queue
                     when the link is idle (defaults to 256, must be greater
                     than zero)

                     specifies the expected average packet size (defaults to
                     512, must be greater than zero)

                     specifies the expected maximum packet size, only used
                     when queue thresholds are in bytes (defaults to 1500,
                     must be greater than zero).

     Here are some important points to consider when designing your rules:

     +o   Remember that you filter both packets going in and out.  Most
         connections need packets going in both directions.

     +o   Remember to test very carefully.  It is a good idea to be near the
         console when doing this.  If you cannot be near the console, use an
         auto-recovery script such as the one in

     +o   Don't forget the loopback interface.

     +o   There are circumstances where fragmented datagrams are
         unconditionally dropped.  TCP packets are dropped if they do not
         contain at least 20 bytes of TCP header, UDP packets are dropped if
         they do not contain a full 8 byte UDP header, and ICMP packets are
         dropped if they do not contain 4 bytes of ICMP header, enough to
         specify the ICMP type, code, and checksum.  These packets are simply
         logged as ``pullup failed'' since there may not be enough good data
         in the packet to produce a meaningful log entry.

     +o   Another type of packet is unconditionally dropped, a TCP packet with
         a fragment offset of one.  This is a valid packet, but it only has
         one use, to try to circumvent firewalls.  When logging is enabled,
         these packets are reported as being dropped by rule -1.

     +o   If you are logged in over a network, loading the kld(4) version of
         ipfw is probably not as straightforward as you would think.  I
         recommend the following command line:

               kldload /modules/ipfw.ko && \
               ipfw add 32000 allow ip from any to any

         Along the same lines, doing an

               ipfw flush

         in similar surroundings is also a bad idea.

     +o   The ipfw filter list may not be modified if the system security level
         is set to 3 or higher (see init(8) for information on system security

     A divert(4) socket bound to the specified port will receive all packets
     diverted to that port.  If no socket is bound to the destination port, or
     if the kernel wasn't compiled with divert socket support, the packets are

     A set of sysctl(8) variables controls the behaviour of the firewall.
     These are shown below together with their default value (but always check
     with the sysctl(8) command what value is actually in use) and meaning:

     net.inet.ip.fw.debug: 1
             Controls debugging messages produced by ipfw.

     net.inet.ip.fw.one_pass: 1
             When set, the packet exiting from the dummynet(4) pipe is not
             passed though the firewall again.  Otherwise, after a pipe
             action, the packet is reinjected into the firewall at the next

     net.inet.ip.fw.verbose: 1
             Enables verbose messages.

     net.inet.ip.fw.enable: 1
             Enables the firewall.  Setting this variable to 0 lets you run
             your machine without firewall even if compiled in.

     net.inet.ip.fw.verbose_limit: 0
             Limits the number of messages produced by a verbose firewall.

     net.inet.ip.fw.dyn_buckets: 256

     net.inet.ip.fw.curr_dyn_buckets: 256
             The configured and current size of the hash table used to hold
             dynamic rules.  This must be a power of 2.  The table can only be
             resized when empty, so in order to resize it on the fly you will
             probably have to flush and reload the ruleset.

     net.inet.ip.fw.dyn_count: 3
             Current number of dynamic rules (read-only).

     net.inet.ip.fw.dyn_max: 1000
             Maximum number of dynamic rules.  When you hit this limit, no
             more dynamic rules can be installed until old ones expire.

     net.inet.ip.fw.dyn_ack_lifetime: 300

     net.inet.ip.fw.dyn_syn_lifetime: 20

     net.inet.ip.fw.dyn_fin_lifetime: 1

     net.inet.ip.fw.dyn_rst_lifetime: 1

     net.inet.ip.fw.dyn_udp_lifetime: 5

     net.inet.ip.fw.dyn_short_lifetime: 30
             These variables control the lifetime, in seconds, of dynamic
             rules.  Upon the initial SYN exchange the lifetime is kept short,
             then increased after both SYN have been seen, then decreased
             again during the final FIN exchange or when a RST

     This command adds an entry which denies all tcp packets from to the telnet port of from being
     forwarded by the host:

           ipfw add deny tcp from to telnet

     This one disallows any connection from the entire crackers network to my

           ipfw add deny ip from to

     A first and efficient way to limit access (not using dynamic rules) is
     the use of the following rules:

           ipfw add allow tcp from any to any established
           ipfw add allow tcp from net1 portlist1 to net2 portlist2 setup
           ipfw add allow tcp from net3 portlist3 to net3 portlist3 setup
           ipfw add deny tcp from any to any

     The first rule will be a quick match for normal TCP packets, but it will
     not match the initial SYN packet, which will be matched by the setup
     rules only for selected source/destination pairs.  All other SYN packets
     will be rejected by the final deny rule.

     In order to protect a site from flood attacks involving fake TCP packets,
     it is safer to use dynamic rules:

           ipfw add check-state
           ipfw add deny tcp from any to any established
           ipfw add allow tcp from my-net to any setup keep-state

     This will let the firewall install dynamic rules only for those
     connection which start with a regular SYN packet coming from the inside
     of our network.  Dynamic rules are checked when encountering the first
     check-state or keep-state rule.  A check-state rule should be usually
     placed near the beginning of the ruleset to minimize the amount of work
     scanning the ruleset.  Your mileage may vary.

     To limit the number of connections a user can open you can use the
     following type of rules:

           ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
           ipfw add allow tcp from any to me setup limit src-addr 4

     The former (assuming it runs on a gateway) will allow each host on a /24
     network to open at most 10 TCP connections.  The latter can be placed on
     a server to make sure that a single client does not use more than 4
     simultaneous connections.

     BEWARE: stateful rules can be subject to denial-of-service attacks by a
     SYN-flood which opens a huge number of dynamic rules.  The effects of
     such attacks can be partially limited by acting on a set of sysctl(8)
     variables which control the operation of the firewall.

     Here is a good usage of the list command to see accounting records and
     timestamp information:

           ipfw -at list

     or in short form without timestamps:

           ipfw -a list

     which is equivalent to:

           ipfw show

     Next rule diverts all incoming packets from to divert port

           ipfw divert 5000 ip from to any in

     The following rules show some of the applications of ipfw and dummynet(4)
     for simulations and the like.

     This rule drops random incoming packets with a probability of 5%:

           ipfw add prob 0.05 deny ip from any to any in

     A similar effect can be achieved making use of dummynet pipes:

           ipfw add pipe 10 ip from any to any
           ipfw pipe 10 config plr 0.05

     We can use pipes to artificially limit bandwidth, e.g. on a machine
     acting as a router, if we want to limit traffic from local clients on we do:

           ipfw add pipe 1 ip from to any out
           ipfw pipe 1 config bw 300Kbit/s queue 50KBytes

     note that we use the out modifier so that the rule is not used twice.
     Remember in fact that ipfw rules are checked both on incoming and
     outgoing packets.

     Should we like to simulate a bidirectional link with bandwidth
     limitations, the correct way is the following:

           ipfw add pipe 1 ip from any to any out
           ipfw add pipe 2 ip from any to any in
           ipfw pipe 1 config bw 64Kbit/s queue 10Kbytes
           ipfw pipe 2 config bw 64Kbit/s queue 10Kbytes

     The above can be very useful, e.g. if you want to see how your fancy Web
     page will look for a residential user which is connected only through a
     slow link.  You should not use only one pipe for both directions, unless
     you want to simulate a half-duplex medium (e.g. AppleTalk, Ethernet,
     IRDA).  It is not necessary that both pipes have the same configuration,
     so we can also simulate asymmetric links.

     Should we like to verify network performance with the RED queue
     management algorithm:

           ipfw add pipe 1 ip from any to any
           ipfw pipe 1 config bw 500Kbit/s queue 100 red 0.002/30/80/0.1

     Another typical application of the traffic shaper is to introduce some
     delay in the communication.  This can affect a lot applications which do
     a lot of Remote Procedure Calls, and where the round-trip-time of the
     connection often becomes a limiting factor much more than bandwidth:

           ipfw add pipe 1 ip from any to any out
           ipfw add pipe 2 ip from any to any in
           ipfw pipe 1 config delay 250ms bw 1Mbit/s
           ipfw pipe 2 config delay 250ms bw 1Mbit/s

     Per-flow queueing can be useful for a variety of purposes.  A very simple
     one is counting traffic:

           ipfw add pipe 1 tcp from any to any
           ipfw add pipe 1 udp from any to any
           ipfw add pipe 1 ip from any to any
           ipfw pipe 1 config mask all

     The above set of rules will create queues (and collect statistics) for
     all traffic.  Because the pipes have no limitations, the only effect is
     collecting statistics.  Note that we need 3 rules, not just the last one,
     because when ipfw tries to match IP packets it will not consider ports,
     so we would not see connections on separate ports as different ones.

     A more sophisticated example is limiting the outbound traffic on a net
     with per-host limits, rather than per-network limits:

           ipfw add pipe 1 ip from to any out
           ipfw add pipe 2 ip from any to in
           ipfw pipe 1 config mask src-ip 0x000000ff bw 200Kbit/s queue
           ipfw pipe 2 config mask dst-ip 0x000000ff bw 200Kbit/s queue

     The number of times a packet is processed by ipfw varies -- basically,
     ipfw is invoked every time the kernel functions ip_input(), ip_output()
     and bdg_forward() are invoked.  This means that packets are processed
     once for connections having only one endpoint on the local host, twice
     for connections with both endpoints on the local host, or for packet
     routed by the host (acting as a gateway), and once for packets bridged by
     the host (acting as a bridge).

     cpp(1), m4(1), bridge(4), divert(4), dummynet(4), ip(4), ipfirewall(4),
     protocols(5), services(5), init(8), kldload(8), reboot(8), sysctl(8),

     The syntax has grown over the years and it is not very clean.


     This program can put your computer in rather unusable state.  When using
     it for the first time, work on the console of the computer, and do NOT do
     anything you don't understand.

     When manipulating/adding chain entries, service and protocol names are
     not accepted.

     Incoming packet fragments diverted by divert or tee are reassembled
     before delivery to the socket.

     Packets that match a tee rule should not be immediately accepted, but
     should continue going through the rule list.  This may be fixed in a
     later version.

     Ugen J. S. Antsilevich,
     Poul-Henning Kamp,
     Alex Nash,
     Archie Cobbs,
     Luigi Rizzo.

     API based upon code written by Daniel Boulet for BSDI.

     Work on dummynet(4) traffic shaper supported by Akamba Corp.

     The ipfw utility first appeared in FreeBSD 2.0.  dummynet(4) was
     introduced in FreeBSD 2.2.8.  Stateful extensions were introduced in
     FreeBSD 4.0.

FreeBSD 11.0-PRERELEASE          May 31, 2001          FreeBSD 11.0-PRERELEASE


Want to link to this manual page? Use this URL:

home | help