Provided by: shorewall-common_4.0.12-1_all bug

NAME

       rules - Shorewall rules file

SYNOPSIS

       /etc/shorewall/rules

DESCRIPTION

       Entries  in  this  file  govern  connection  establishment  by defining
       exceptions   to   the   policies   layed   out   in    shorewall-policy
       〈shorewall-policy.html〉   (5).  By  default,  subsequent  requests  and
       responses are automatically allowed using connection tracking. For  any
       particular  (source,dest) pair of zones, the rules are evaluated in the
       order in which they appear in this file and the first terminating match
       is  the  one  that determines the disposition of the request. All rules
       are terminating except LOG and QUEUE rules.
              Warning

              If you masquerade or  use  SNAT  from  a  local  system  to  the
              internet,  you  cannot  use an ACCEPT rule to allow traffic from
              the internet to that system. You must use a DNAT rule instead.

       The rules file is divided into sections. Each section is introduced  by
       a  "Section Header" which is a line beginning with SECTION and followed
       by the section name.

       Sections are as follows and must appear in the order listed:

       ESTABLISHED
              Packets in the ESTABLISHED state are processed by rules in  this
              section.

              The  only  ACTIONs  allowed  in  this  section are ACCEPT, DROP,
              REJECT, LOG and QUEUE

              There is an implicit ACCEPT rule inserted at  the  end  of  this
              section.

       RELATED
              Packets  in  the  RELATED  state  are processed by rules in this
              section.

              The only ACTIONs allowed  in  this  section  are  ACCEPT,  DROP,
              REJECT, LOG and QUEUE

              There  is  an  implicit  ACCEPT rule inserted at the end of this
              section.

       NEW    Packets in the NEW and INVALID states are processed by rules  in
              this section.
              Note

              If  you  are  not familiar with Netfilter to the point where you
              are  comfortable  with  the  differences  between  the   various
              connection  tracking  states, then it is suggested that you omit
              the ESTABLISHED and RELATED sections and place all of your rules
              in  the  NEW  section  (That’s after the line that reads SECTION
              NEW’).
              Warning

              If    you    specify    FASTACCEPT=Yes     in     shorewall.conf
              〈shorewall.conf.html〉  (5)  then  the  ESTABLISHED  and  RELATED
              sections must be empty.

       You may omit any section that you don’t need.  If  no  Section  Headers
       appear in the file then all rules are assumed to be in the NEW section.

       When defining rules that rewrite the destination IP address and/or port
       number  (namely  DNAT  and  REDIRECT  rules),  it  is important to keep
       straight which columns in the file specify the packet before  rewriting
       and which specify how the packet will look after rewriting.

       · The  DEST column specifies the final destination for the packet after
         rewriting and can include the final IP address and/or port number.

       · The remaining columns specify characteristics of  the  packet  before
         rewriting. In particular, the ORIGINAL DEST column gives the original
         destination IP address of the packet and the DEST PORT(S) column give
         the original destination port(s).

       The columns in the file are as follows.

       ACTION                                                                —
       {ACCEPT[+|!]|NONAT|DROP[!]|REJECT[!]|DNAT[-]|SAME[-]|REDIRECT[-]|CONTINUE[!]|LOG|QUEUE[!]|NFQUEUE[/queuenumber]|COMMENT|action|macro[/target]}[:{log-
       level|none}[!][:tag]]
              Specifies  the  action  to  be  taken  if the connection request
              matches the rule. Must be one of the following.

              ACCEPT Allow the connection request.

              ACCEPT+
                     like ACCEPT but also excludes  the  connection  from  any
                     subsequent matching DNAT[-] or REDIRECT[-] rules

              ACCEPT!
                     like ACCEPT but exempts the rule from being suppressed by
                     OPTIMIZE=1 in shorewall.conf 〈shorewall.conf.html〉 (5).

              NONAT  Excludes the connection from any  subsequent  DNAT[-]  or
                     REDIRECT[-]  rules  but doesn’t generate a rule to accept
                     the traffic.

              DROP   Ignore the request.

              DROP!  like DROP but exempts the rule from being  suppressed  by
                     OPTIMIZE=1 in shorewall.conf 〈shorewall.conf.html〉 (5).

              REJECT disallow the request and return an icmp-unreachable or an
                     RST packet.

              REJECT!
                     like REJECT but exempts the rule from being suppressed by
                     OPTIMIZE=1 in shorewall.conf 〈shorewall.conf.html〉 (5).

              DNAT   Forward  the  request  to  another system (and optionally
                     another port).

              DNAT-  Advanced users only.

                     Like DNAT but only generates the DNAT iptables  rule  and
                     not the companion ACCEPT rule.

              SAME   Similar  to DNAT except that the port may not be remapped
                     and  when  multiple  server  addresses  are  listed,  all
                     requests  from  a  given  remote  system  go  to the same
                     server.
                     Warning

                     Support for SAME is scheduled for removal from the  Linux
                     kernel in 2008.

              SAME-  Advanced users only.

                     Like  SAME  but  only generates the nat iptables rule and
                     not the companion ACCEPT rule.

              REDIRECT
                     Redirect the request to a server running on the firewall.

              REDIRECT-
                     Advanced users only.

                     Like  REDIRECT  but  only generates the REDIRECT iptables
                     rule and not the companion ACCEPT rule.

              CONTINUE
                     For experts only.

                     Do not process  any  of  the  following  rules  for  this
                     (source  zone,destination  zone).  If  the  source and/or
                     destination IP address falls into a zone defined later in
                     shorewall-zones 〈shorewall-zones.html〉 (5) or in a parent
                     zone of  the  source  or  destination  zones,  then  this
                     connection  request  will  be passed to the rules defined
                     for   that   (those)   zone(s).   See   shorewall-nesting
                     〈shorewall-nesting.html〉  (5) for additional information.

              CONTINUE!
                     like CONTINUE but exempts the rule from being  suppressed
                     by  OPTIMIZE=1  in  shorewall.conf  〈shorewall.conf.html〉
                     (5).

              LOG    Simply log the packet and continue with the next rule.

              QUEUE  Queue the packet to  a  user-space  application  such  as
                     ftwall   (http://p2pwall.sf.net).   The  application  may
                     reinsert the packet for further processing.

              QUEUE! like QUEUE but exempts the rule from being suppressed  by
                     OPTIMIZE=1 in shorewall.conf 〈shorewall.conf.html〉 (5).

              NFQUEUE
                     Only supported by Shorewall-perl >= 4.0.3.

                     Queues  the  packet to a user-space application using the
                     nfnetlink_queue  mechanism.  If  a  queuenumber  is   not
                     specified, queue zero (0) is assumed.

              NFQUEUE!
                     like  NFQUEUE  but exempts the rule from being suppressed
                     by  OPTIMIZE=1  in  shorewall.conf  〈shorewall.conf.html〉
                     (5).

              COMMENT
                     the rest of the line will be attached as a comment to the
                     Netfilter rule(s) generated by the following entries. The
                     comment  will  appear  delimited  by  "/*  ... */" in the
                     output of "shorewall show <chain>". To stop  the  comment
                     from  being  attached  to  further  rules, simply include
                     COMMENT on a line by itself.

              action The name  of  an  action  declared  in  shorewall-actions
                     〈shorewall-actions.html〉         (5)         or        in
                     /usr/share/shorewall/actions.std.

              macro  The name of a macro defined in a file named  macro.macro.
                     If  the  macro  accepts  an action parameter (Look at the
                     macro source to see if it has PARAM in the TARGET column)
                     then  the  macro  name  is followed by "/" and the target
                     (ACCEPT, DROP, REJECT, ...) to  be  substituted  for  the
                     parameter.

                     Example: FTP/ACCEPT.

              The  ACTION  may  optionally be followed by ":" and a syslog log
              level (e.g, REJECT:info or DNAT:debug). This causes  the  packet
              to  be  logged  at  the specified level. Note that if the ACTION
              involves  destination   network   address   translation   (DNAT,
              REDIRECT,  SAME,  etc.)  then  the  packet  is logged before the
              destination address is rewritten.

              If the ACTION names  an  action  declared  in  shorewall-actions
              〈shorewall-actions.html〉           (5)           or           in
              /usr/share/shorewall/actions.std then:

                     · If the log level is followed by "!’ then all  rules  in
                       the action are logged at the log level.

                     · If the log level is not followed by "!" then only those
                       rules in the action that do  not  specify  logging  are
                       logged at the specified level.

                     · The  special  log level none! suppresses logging by the
                       action.

              You may also specify ULOG (must be  in  upper  case)  as  a  log
              level.This will log to the ULOG target for routing to a separate
              log           through           use           of           ulogd
              (〈http://www.netfilter.org/projects/ulogd/index.html〉).

              Actions  specifying  logging  may  be  followed  by a log tag (a
              string of alphanumeric characters)  which  is  appended  to  the
              string   generated   by   the   LOGPREFIX   (in   shorewall.conf
              〈shorewall.conf.html〉 (5)).

              Example: ACCEPT:info:ftp would include ’ftp ’ at the end of  the
              log prefix generated by the LOGPREFIX setting.

       SOURCE  —  {zone|all[+][-]}[:interface][:{address-or-range[,address-or-
       range]...[exclusion]|exclusion|+ipset}
              Source  hosts  to which the rule applies. May be a zone declared
              in /etc/shorewall/zones, $FW to indicate  the  firewall  itself,
              all, all+, all-, all+- or none.

              When  none is used either in the SOURCE or DEST column, the rule
              is ignored.

              all means "All Zones", including the firewall itself. all- means
              "All  Zones,  except  the  firewall itself". When all[-] is used
              either in the SOURCE or DEST column intra-zone  traffic  is  not
              affected. When all+[-] is "used, intra-zone traffic is affected.

              Except when all[+][-]  is  specified,  clients  may  be  further
              restricted  to  a list of networks and/or hosts by appending ":"
              and a comma-separated list of  network  and/or  host  addresses.
              Hosts  may be specified by IP or MAC address; mac addresses must
              begin with "~" and must use "-" as a separator.

              Hosts may also be specified as an IP  address  range  using  the
              syntax  lowaddress-highaddress.   This requires that your kernel
              and iptables contain iprange match support. If your  kernel  and
              iptables  have ipset match support then you may give the name of
              an ipset prefaced by "+".  The  ipset  name  may  be  optionally
              followed  by  a  number  from 1 to 6 enclosed in square brackets
              ([]) to indicate the number of levels of source bindings  to  be
              matched.

              You  may  exclude  certain  hosts  from  the set already defined
              through   use   of   an   exclusion   (see   shorewall-exclusion
              〈shorewall-exclusion.html〉 (5)).

              Examples:

              dmz:192.168.2.2
                     Host 192.168.2.2 in the DMZ

              net:155.186.235.0/24
                     Subnet 155.186.235.0/24 on the Internet

              loc:192.168.1.1,192.168.1.2
                     Hosts 192.168.1.1 and 192.168.1.2 in the local zone.

              loc:~00-A0-C9-15-39-78
                     Host    in    the    local    zone   with   MAC   address
                     00:A0:C9:15:39:78.

              net:192.0.2.11-192.0.2.17
                     Hosts 192.0.2.11-192.0.2.17 in the net zone.

              net:!192.0.2.11-192.0.2.17
                     All    hosts    in    the    net    zone    except    for
                     192.0.2.11-192.0.2.17.

              net:155.186.235.0/24!155.186.235.16/28
                     Subnet   155.186.235.0/24  on  the  Internet  except  for
                     155.186.235.16/28
              Alternatively,  clients  may  be  specified  by   interface   by
              appending  ":"  to the zone name followed by the interface name.
              For example, loc:eth1 specifies a client that communicates  with
              the  firewall  system  through  eth1.   This  may  be optionally
              followed by another colon (":") and an IP/MAC/subnet address  as
              described above (e.g., loc:eth1:192.168.1.5).

              It  is  important  to  note  that when using Shorewall-shell and
              specifying an address list that will be  split  (i.e.,  a  comma
              separated  list),  there  is  a  subtle  behavior  which has the
              potential to cause confusion. Consider the two examples below:

       Examples:

              loc:eth1:192.168.1.3,192.168.1.5
                     Hosts 192.168.1.3 and 192.168.1.5 in the Local zone, with
                     192.168.1.3  coming from eth1 and 192.168.1.5 originating
                     from any interface in the zone.

              loc:eth1:192.168.1.3,eth1:192.168.1.5
                     Hosts 192.168.1.3 and 192.168.1.5 in the Local zone, with
                     both originating from eth1.
              That  is,  the interface name must be explicitly stated for each
              member of the comma separated list. Again, this  distinction  in
              behavior only occurs when using Shorewall-shell.

       DEST    —    {zone|all[+][-]}[:{interface|address-or-range[,address-or-
       range]...[exclusion]|exclusion|+ipset}][:port[:random]]
              Location  of  Server.  May be a zone declared in shorewall-zones
              〈shorewall-zones.html〉 (5), $FW to indicate the firewall itself,
              all. all+ or none.

              When  none is used either in the SOURCE or DEST column, the rule
              is ignored.

              When all is used either in the SOURCE or DEST column  intra-zone
              traffic  is  not affected. When all+ is used, intra-zone traffic
              is affected.

              If the DEST zone is a bport zone, then either:

              1.  the SOURCE must be all[+][-], or

              2.  the SOURCE zone must be another bport zone  associated  with
                  the same bridge, or

              3.  the SOURCE zone must be an ipv4 zone that is associated with
                  only the same bridge.

              Except when all[+]|[-] is specified, the server may  be  further
              restricted  to  a  particular  network,  host  or  interface  by
              appending ":" and the network, host  or  interface.  See  SOURCE
              above.

              You  may  exclude  certain  hosts  from  the set already defined
              through   use   of   an   exclusion   (see   shorewall-exclusion
              〈shorewall-exclusion.html〉 (5)).

              Restrictions:

              1.   MAC   addresses  are  not  allowed  (this  is  a  Netfilter
              restriction).

              2. In DNAT rules, only IP addresses are  allowed;  no  FQDNs  or
              subnet addresses are permitted.

              3. You may not specify both an interface and an address.

              Like  in  the  SOURCE  column,  you  may  specify  a range of IP
              addresses using the  syntax  lowaddress-highaddress.   When  the
              ACTION  is  DNAT  or  DNAT-, the connections will be assigned to
              addresses in the range in a round-robin fashion.

              If you kernel and iptables have ipset match support then you may
              give the name of an ipset prefaced by "+". The ipset name may be
              optionally followed by a number from 1 to 6 enclosed  in  square
              brackets  ([])  to  indicate the number of levels of destination
              bindings to be matched. Only one of the SOURCE and DEST  columns
              may specify an ipset name.

              The  port  that  the  server is listening on may be included and
              separated from the server’s IP address by ":". If  omitted,  the
              firewall  will  not  modifiy the destination port. A destination
              port may only be included if the ACTION is DNAT or REDIRECT.

                     Example:
                             loc:192.168.1.3:3128 specifies a local server  at
                             IP  address  192.168.1.3  and  listening  on port
                             3128.

              If  you  are  using  Shorewall-shell  or  Shorewall-perl  before
              version  4.0.5,  then  the  port  number MUST be specified as an
              integer and not as a name from services(5). Shorewall-perl 4.0.5
              and  later  permit  the  port to be specified as a service name.
              Additionally, Shorewall-perl 4.0.5 and later permit specifying a
              port  range in the form lowport-highport to cause connections to
              be assigned to ports in the range in round-robin fashion. When a
              port  range  is specified, lowport and highport must be given as
              integers;  service  names  are  not  permitted.  Beginning  with
              Shorewall  4.0.6,  the  port range may be optionally followed by
              :random which causes assignment to  ports  in  the  list  to  be
              random.

              If  the  ACTION is REDIRECT or REDIRECT-, this column needs only
              to contain the port number on  the  firewall  that  the  request
              should  be  redirected  to.  That  is  equivalent  to specifying
              $FW::port.

       PROTO   (Optional)   —   {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-
       number|protocol-name|all}
              Protocol - ipp2p* requires ipp2p match support  in  your  kernel
              and  iptables. tcp:syn implies tcp plus the SYN flag must be set
              and the RST,ACK and FIN flags must be reset.

       DEST  PORT(S)  (Optional)  —   {-|port-name-number-or-range[,port-name-
       number-or-range]...}
              Destination Ports. A comma-separated list of  Port  names  (from
              services(5)),  port  numbers  or port ranges; if the protocol is
              icmp, this  column  is  interpreted  as  the  destination  icmp-
              type(s).

              If the protocol is ipp2p, this column is interpreted as an ipp2p
              option without the leading "--" (example bit  for  bit-torrent).
              If no port is given, ipp2p is assumed.

              A port range is expressed as lowport:highport.

              This column is ignored if PROTO = all but must be entered if any
              of the following columns are  supplied.  In  that  case,  it  is
              suggested that this field contain a dash (-).

              If  your  kernel  contains multi-port match support, then only a
              single Netfilter rule will be generated if in this list and  the
              CLIENT PORT(S) list below:

              1. There are 15 or less ports listed.

              2.  No  port  ranges  are  included  or your kernel and iptables
              contain extended multiport match support.

              Otherwise,    unless    you     are     using     Shorewall-perl
              〈../Shorewall-perl.html〉 , a separate rule will be generated for
              each port. Shorewall-perl does not automatically break up  lists
              into individual rules.

       SOURCE  PORT(S)  (Optional)  — {-|port-name-number-or-range[,port-name-
       number-or-range]...}
              Port(s)  used  by  the  client.  If  omitted, any source port is
              acceptable. Specified as a comma- separated list of port  names,
              port numbers or port ranges.
              Warning

              Unless  you  really  understand IP, you should leave this column
              empty or place a dash (-) in the column. Most people who try  to
              use this column get it wrong.
              If  you  don’t want to restrict client ports but need to specify
              an ORIGINAL DEST in the next column,  then  place  "-"  in  this
              column.

              If  your  kernel  contains multi-port match support, then only a
              single Netfilter rule will be generated if in this list and  the
              DEST PORT(S) list above:

              1. There are 15 or less ports listed.

              2.  No  port  ranges  are  included  or your kernel and iptables
              contain extended multiport match support.

              Otherwise,    unless    you     are     using     Shorewall-perl
              〈../Shorewall-perl.html〉 , a separate rule will be generated for
              each port. Shorewall-perl does not automatically break up  lists
              into individual rules.

       ORIGINAL                DEST                (Optional)                —
       [-|address[,address]...[exclusion]|exclusion]
              If  ACTION  is  DNAT[-]  or  REDIRECT[-]  then if this column is
              included and is different from  the  IP  address  given  in  the
              SERVER  column,  then connections destined for that address will
              be forwarded to the IP and port specified in the DEST column.

              A comma-separated list of addresses may also be  used.  This  is
              most  useful with the REDIRECT target where you want to redirect
              traffic destined for particular set of hosts.  Finally,  if  the
              list  of  addresses  begins  with "!"  (exclusion) then the rule
              will be followed only if the original destination address in the
              connection request does not match any of the addresses listed.

              For  other  actions, this column may be included and may contain
              one or more addresses (host or  network)  separated  by  commas.
              Address  ranges  are  not allowed. When this column is supplied,
              rules are generated that require that the  original  destination
              address  matches  one  of  the listed addresses. This feature is
              most useful when  you  want  to  generate  a  filter  rule  that
              corresponds  to  a  DNAT-  or REDIRECT- rule. In this usage, the
              list of addresses should not begin with "!".

              It is also possible to specify a set of addresses  then  exclude
              part       of       those      addresses.      For      example,
              192.168.1.0/24!192.168.1.16/28    specifies    the     addresses
              192.168.1.0-182.168.1.15  and  192.168.1.32-192.168.1.255.   See
              shorewall-exclusion 〈shorewall-exclusion.html〉 (5).

              See                       http://shorewall.net/PortKnocking.html
              〈../PortKnocking.html〉  for an example of using an entry in this
              column with a user-defined action rule.

       RATE LIMIT (Optional) — [-|rate/{sec|min}[:burst]
              You may rate-limit the rule by placing a value in this column:

              rate is the number of connections per interval (sec or min)  and
              burst  is  the  largest burst permitted. If no burst is given, a
              value of 5 is assumed. There may be no no whitespace embedded in
              the specification.

              Example: 10/sec:20

       USER/GROUP    (Optional)   —   [!][user-name-or-number][:group-name-or-
       number][+program-name]
              This  column may only be non-empty if the SOURCE is the firewall
              itself.

              When this column is non-empty, the  rule  applies  only  if  the
              program  generating  the  output  is running under the effective
              user and/or group specified (or is NOT running under that id  if
              "!" is given).

              Examples:

              joe    program must be run by joe

              :kids  program must be run by a member of the ’kids’ group

              !:kids program must not be run by a member of the ’kids’ group

              +upnpd #program named upnpd
                     Important

                     The  ability  to  specify a program name was removed from
                     Netfilter in kernel version 2.6.14.

       MARK — [!]value[/mask][:C]
              Defines a test on the existing packet or  connection  mark.  The
              rule will match only if the test returns true.

              If  you don’t want to define a test but need to specify anything
              in the following columns, place a "-" in this field.

              !      Inverts the test (not equal)

              value  Value of the packet or connection mark.

              mask   A mask to be applied to the mark before testing.

              :C     Designates a connection  mark.  If  omitted,  the  packet
                     mark’s  value is tested. This option is only supported by
                     Shorewall-perl.

RESTRICTIONS

       Unless you are using Shorewall-perl 〈../Shorewall-perl.html〉  and  your
       iptables/kernel  have Repeat Match support (see the output of shorewall
       show capabilities), if you specify a list of DEST PORT(S), then you may
       not specify SOURCE PORT(S) and vice versa.

EXAMPLE

       Example 1:
              Accept SMTP requests from the DMZ to the internet

                       #ACTION SOURCE  DEST PROTO      DEST    SOURCE  ORIGINAL
                       #                               PORT    PORT(S) DEST
                       ACCEPT  dmz     net       tcp   smtp

       Example 2:
              Forward  all  ssh and http connection requests from the internet
              to local system 192.168.1.3

                      #ACTION SOURCE  DEST            PROTO   DEST    SOURCE  ORIGINAL
                      #                                       PORT    PORT(S) DEST
                      DNAT    net     loc:192.168.1.3 tcp     ssh,http

       Example 3:
              Forward all http connection requests from the internet to  local
              system  192.168.1.3  with  a limit of 3 per second and a maximum
              burst of 10

                      #ACTION SOURCE DEST            PROTO  DEST  SOURCE  ORIGINAL RATE
                      #                                     PORT  PORT(S) DEST     LIMIT
                      DNAT    net    loc:192.168.1.3 tcp    http  -       -        3/sec:10

       Example 4:
              Redirect all locally-originating www connection requests to port
              3128  on  the  firewall  (Squid  running on the firewall system)
              except when the destination address is 192.168.2.2

                      #ACTION  SOURCE DEST      PROTO DEST    SOURCE  ORIGINAL
                      #                               PORT    PORT(S) DEST
                      REDIRECT loc    3128      tcp   www      -      !192.168.2.2

       Example 5:
              All http requests from the internet  to  address  130.252.100.69
              are to be forwarded to 192.168.1.3

                      #ACTION  SOURCE DEST            PROTO   DEST    SOURCE  ORIGINAL
                      #                                       PORT    PORT(S) DEST
                      DNAT      net   loc:192.168.1.3 tcp     80      -       130.252.100.69

       Example 6:
              You  want  to  accept SSH connections to your firewall only from
              internet IP addresses 130.252.100.69 and 130.252.100.70

                      #ACTION  SOURCE DEST            PROTO   DEST    SOURCE  ORIGINAL
                      #                                       PORT    PORT(S) DEST
                      ACCEPT   net:130.252.100.69,130.252.100.70 $FW \
                                                      tcp     22

       Example 7:
              You wish  to  accept  connections  from  the  internet  to  your
              firewall  on  port  2222  and  you want to forward them to local
              system 192.168.1.3, port 22

                      #ACTION  SOURCE DEST                PROTO   DEST    SOURCE  ORIGINAL
                      #                                           PORT    PORT(S) DEST
                      DNAT     net    loc:192.168.1.3:22  tcp     2222

       Example 8:
              You want to redirect connection requests to port 80 randomly  to
              the port range 81-90.

                      #ACTION  SOURCE DEST                PROTO DEST    SOURCE  ORIGINAL
                      #                                         PORT    PORT(S) DEST
                      REDIRECT net    $FW::81-90:random   tcp   www

       Example 9:
              Shorewall  does  not  impose  as much structure on the Netfilter
              rules in the ’nat’ table as it  does  on  those  in  the  filter
              table.  As a consequence, care must be exercised when using DNAT
              and REDIRECT rules with zones defined with  wildcard  interfaces
              (those ending with ’+’. Here is an example:

              shorewall-zones 〈shorewall-zones.html〉 (8):

                      #ZONE       TYPE    OPTIONS
                      fw          firewall
                      net         ipv4
                      dmz         ipv4
                      loc         ipv4

              shorewall-interfaces 〈shorewall-interfaces.html〉 (8):

                      #ZONE       INTERFACE       BROADCAST      OPTIONS
                      net         ppp0
                      loc         eth1            detect
                      dmz         eth2            detect
                      -           ppp+                           # Addresses are assigned from 192.168.3.0/24

              shorewall-host 〈shorewall-hosts.html〉 (8):

                      #ZONE       HOST(S)              OPTIONS
                      loc         ppp+:192.168.3.0/24

              rules:

                      #ACTION     SOURCE          DEST       PROTO       DEST
                      #                                                  PORT(S)
                      REDIRECT    loc             3128       tcp         80

              Note  that  it would have been tempting to simply define the loc
              zone entirely in shorewall-interfaces(8):

                      #******************* INCORRECT *****************
                      #ZONE       INTERFACE       BROADCAST      OPTIONS
                      net         ppp0
                      loc         eth1            detect
                      loc         ppp+
                      dmz         eth2

              This would have made it impossible to run a  internet-accessible
              web  server  in  the  DMZ  because  all  traffic  entering  ppp+
              interfaces would have  been  redirected  to  port  3128  on  the
              firewall  and  there  would have been no net->fw ACCEPT rule for
              that traffic.

FILES

       /etc/shorewall/rules

SEE ALSO

       shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-
       blacklist(5),  shorewall-hosts(5),  shorewall-interfaces(5), shorewall-
       ipsec(5),  shorewall-maclist(5),  shorewall-masq(5),  shorewall-nat(5),
       shorewall-netmap(5),      shorewall-params(5),     shorewall-policy(5),
       shorewall-providers(5),        shorewall-proxyarp(5),        shorewall-
       route_routes(5),      shorewall-routestopped(5),     shorewall.conf(5),
       shorewall-tcclasses(5),  shorewall-tcdevices(5),  shorewall-tcrules(5),
       shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)

                                 24 June 2008               shorewall-rules(5)