#
# Shorewall6 version 5.2 - Sample Rules File for three-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-rules"
######################################################################################################################################################################################################
# 
# Entries in this file govern connection establishment by defining exceptions to
# the policies laid out in shorewall-policy(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 COUNT 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:
# 
# ALL
# 
#     This section was added in Shorewall 4.4.23. Rules in this section are
#     applied, regardless of the connection tracking state of the packet and are
#     applied before rules in the other sections.
# 
# 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,
#     NFLOG, NFQUEUE 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,
#     NFLOG, NFQUEUE and QUEUE
# 
#     There is an implicit rule added at the end of this section that invokes the
#     RELATED_DISPOSITION (shorewall.conf(5)).
# 
# INVALID
# 
#     Added in Shorewall 4.5.13. Packets in the INVALID state are processed by
#     rules in this section.
# 
#     The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
#     NFLOG, NFQUEUE and QUEUE.
# 
#     There is an implicit rule added at the end of this section that invokes the
#     INVALID_DISPOSITION (shorewall.conf(5)).
# 
# UNTRACKED
# 
#     Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by
#     rules in this section.
# 
#     The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
#     NFLOG, NFQUEUE and QUEUE.
# 
#     There is an implicit rule added at the end of this section that invokes the
#     UNTRACKED_DISPOSITION (shorewall.conf(5)).
# 
# NEW
# 
#     Packets in the NEW state are processed by rules in this section. If the
#     INVALID and/or UNTRACKED sections are empty or not included, then the
#     packets in the corresponding state(s) are also processed 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 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(5) then the ALL, ESTABLISHED
# and RELATED sections must be empty.
# 
# An exception is made if you are running Shorewall 4.4.27 or later and you have
# specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In
# that case, you may have rules in the RELATED section of this file.
# 
# 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 ORIGDEST column gives the original
#     destination IP address of the packet and the DPORT column give the original
#     destination port(s).
# 
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
# 
# ACTION - target[:{log-level|none}[!][:tag]]
# 
#     Specifies the action to be taken if the connection request matches the
#     rule. target 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. Use with IPv6 requires Shorewall
#         4.5.14 or later.
# 
#     ACCEPT!
# 
#         like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in
#         shorewall.conf(5).
# 
#     action
# 
#         The name of an action declared in shorewall-actions(5) or in /usr/share
#         /shorewall[6]/actions.std.
# 
#     ADD(ipset:flags[:timeout])
# 
#         Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be
#         added to the named ipset. The flags specify the address or tuple to be
#         added to the set and must match the type of ipset involved. For
#         example, for an iphash ipset, either the SOURCE or DESTINATION address
#         can be added using flags src or dst respectively (see the -A command in
#         ipset (8)).
# 
#         Beginning with Shorewall 5.0.3, an optional timeout can be specified.
#         This is the number of seconds that the new entry in the ipset is to
#         remain valid and overrides any timeout specified when the ipset was
#         created.
# 
#         ADD is non-terminating. Even if a packet matches the rule, it is passed
#         on to the next rule.
# 
#     AUDIT[(accept|drop|reject)]
# 
#         Added in Shorewall 4.5.10. Audits the packet with the specified type;
#         if the type is omitted, then drop is assumed. Require AUDIT_TARGET
#         support in the kernel and iptables.
# 
#     A_ACCEPT, A_ACCEPT+ and A_ACCEPT!
# 
#         Added in Shorewall 4.4.20. Audited versions of ACCEPT, ACCEPT+ and
#         ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and
#         iptables. A_ACCEPT+ with IPv6 requires Shorewall 4.5.14 or later.
# 
#     A_DROP and A_DROP!
# 
#         Added in Shorewall 4.4.20. Audited versions of DROP and DROP!
#         respectively. Require AUDIT_TARGET support in the kernel and iptables.
# 
#     A_REJECT AND A_REJECT!
# 
#         Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT!
#         respectively. Require AUDIT_TARGET support in the kernel and iptables.
# 
#     ?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.
# 
#     CONMARK({mark})
# 
#         Added in Shorewall 5.0.7, CONNMARK is identical to MARK with the
#         exception that the mark is assigned to connection to which the packet
#         belongs is marked rather than to the packet itself.
# 
#     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(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(5) for additional information.
# 
#     CONTINUE!
# 
#         like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1
#         in shorewall.conf(5).
# 
#     COUNT
# 
#         Simply increment the rule's packet and byte count and pass the packet
#         to the next rule.
# 
#     DEL(ipset:flags)
# 
#         Added in Shorewall 4.4.12. Causes an entry to be deleted from the named
#         ipset. The flags specify the address or tuple to be deleted from the
#         set and must match the type of ipset involved. For example, for an
#         iphash ipset, either the SOURCE or DESTINATION address can be deleted
#         using flags src or dst respectively (see the -D command in ipset (8)).
# 
#         DEL is non-terminating. Even if a packet matches the rule, it is passed
#         on to the next rule.
# 
#     DNAT
# 
#         Forward the request to another system (and optionally another port).
#         Use with IPv6 requires Shorewall 4.5.14 or later.
# 
#     DNAT-
# 
#         Advanced users only.
# 
#         Like DNAT but only generates the DNAT iptables rule and not the
#         companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
#         later.
# 
#     DROP
# 
#         Ignore the request.
# 
#     DROP!
# 
#         like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in
#         shorewall.conf(5).
# 
#     HELPER
# 
#         Added in Shorewall 4.5.7. This action requires that the HELPER column
#         contains the name of the Netfilter helper to be associated with
#         connections matching this connection. May only be specified in the NEW
#         section and is useful for being able to specify a helper when the
#         applicable policy is ACCEPT. No destination zone should be specified in
#         HELPER rules.
# 
#     INLINE[(action)]
# 
#         Added in Shorewall 4.5.16. This action allows you to construct most of
#         the rule yourself using iptables syntax. The part that you specify must
#         follow two semicolons (';;') and is completely free-form. If the target
#         of the rule (the part following 'j') is something that Shorewall
#         supports in the ACTION column, then you may enclose it in parentheses
#         (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the
#         semicolon(s). In this case, you must declare the target as a builtin
#         action in shorewall-actions(5).
# 
#         Some considerations when using INLINE:
# 
#           ☆ The p, s, d, i, o, policy, and state match (state or conntrack
#             --ctstate) matches will always appear in the front of the rule in
#             that order.
# 
#           ☆ When multiple matches are specified, the compiler will keep them in
#             the order in which they appear (excluding the above listed ones),
#             but they will not necessarily be at the end of the generated rule.
#             For example, if addresses are specified in the SOURCE and/or DEST
#             columns, their generated matches will appear after those specified
#             using ';;' or ';'.
# 
#     IPTABLES({iptables-target [option ...])
# 
#         IPv4 only. This action allows you to specify an iptables target with
#         options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
#         iptables-target is not one recognized by Shorewall, the following error
#         message will be issued:
# 
#             ERROR: Unknown target (iptables-target)
# 
#         This error message may be eliminated by adding the iptables-target as a
#         builtin action in shorewall-actions(5).
# 
#         Important
# 
#         If you specify REJECT as the iptables-target, the target of the rule
#         will be the iptables REJECT target and not Shorewall's builtin 'reject'
#         chain which is used when REJECT (see below) is specified as the target
#         in the ACTION column.
# 
#     IP6TABLES({ip6tables-target [option ...])
# 
#         IPv6 only. This action allows you to specify an ip6tables target with
#         options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
#         ip6tables-target is not one recognized by Shorewall, the following
#         error message will be issued:
# 
#             ERROR: Unknown target (ip6tables-target)
# 
#         This error message may be eliminated by adding the ip6tables-target as
#         a builtin action in shorewall-actions(5).
# 
#         Important
# 
#         If you specify REJECT as the ip6tables-target, the target of the rule
#         will be the i6ptables REJECT target and not Shorewall's builtin
#         'reject' chain which is used when REJECT (see below) is specified as
#         the target in the ACTION column.
# 
#     LOG:level
# 
#         Simply log the packet and continue with the next rule.
# 
#     macro[(macrotarget)]
# 
#         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 the
#         parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted
#         for the parameter.
# 
#         Example: FTP(ACCEPT).
# 
#         The older syntax where the macro name and the target are separated by a
#         slash (e.g. FTP/ACCEPT) is still allowed but is deprecated.
# 
#     MARK({mark})
# 
#         where mark is a packet mark value.
# 
#         Added in Shorewall 5.0.7, MARK requires "Mark in filter table" support
#         in your kernel and iptables.
# 
#         Normally will set the mark value of the current packet. If preceded by
#         a vertical bar ("|"), the mark value will be logically ORed with the
#         current mark value to produce a new mark value. If preceded by an
#         ampersand ("&"), will be logically ANDed with the current mark value to
#         produce a new mark value.
# 
#         Both "|" and "&" require Extended MARK Target support in your kernel
#         and iptables.
# 
#         The mark value may be optionally followed by "/" and a mask value (used
#         to determine those bits of the connection mark to actually be set).
#         When a mask is specified, the result of logically ANDing the mark value
#         with the mask must be the same as the mark value.
# 
#     NFLOG[(nflog-parameters)]
# 
#         Added in Shorewall 4.5.9.3. Queues matching packets to a back end
#         logging daemon via a netlink socket then continues to the next rule.
#         See http://www.shorewall.net/shorewall_logging.html.
# 
#         The nflog-parameters are a comma-separated list of up to 3 numbers:
# 
#           ☆ The first number specifies the netlink group (0-65535). If omitted
#             (e.g., NFLOG(,0,10)) then a value of 0 is assumed.
# 
#           ☆ The second number specifies the maximum number of bytes to copy. If
#             omitted, 0 (no limit) is assumed.
# 
#           ☆ The third number specifies the number of log messages that should
#             be buffered in the kernel before they are sent to user space. The
#             default is 1.
# 
#         NFLOG is similar to LOG:NFLOG[(nflog-parameters)], except that the log
#         level is not changed when this ACTION is used in an action or macro
#         body and the invocation of that action or macro specifies a log level.
# 
#     NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
# 
#         Queues the packet to a user-space application using the nfnetlink_queue
#         mechanism. If a queuenumber1 is not specified, queue zero (0) is
#         assumed. Beginning with Shorewall 4.6.10, the keyword bypass can be
#         given. By default, if no userspace program is listening on an NFQUEUE,
#         then all packets that are to be queued are dropped. When this option is
#         used, the NFQUEUE rule behaves like ACCEPT instead. Also beginning in
#         Shorewall 4.6.10, a second queue number (queuenumber2) may be
#         specified. This specifies a range of queues to use. Packets are then
#         balanced across the given queues. This is useful for multicore systems:
#         start multiple instances of the userspace program on queues x, x+1, ..
#         x+n and use "x:x+n". Packets belonging to the same connection are put
#         into the same nfqueue.
# 
#         Beginning with Shorewall 5.1.0, queuenumber2 may be followed by the
#         letter 'c' to indicate that the CPU ID will be used as an index to map
#         packets to the queues. The idea is that you can improve performance if
#         there's a queue per CPU. Requires the NFQUEUE CPU Fanout capability in
#         your kernel and iptables.
# 
#     NFQUEUE![([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
# 
#         like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1
#         in shorewall.conf(5).
# 
#     NONAT
# 
#         Excludes the connection from any subsequent DNAT[-] or REDIRECT[-]
#         rules but doesn't generate a rule to accept the traffic. Use with IPv6
#         requires Shorewall 4.5.14 or later.
# 
#     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(5).
# 
#     REJECT[(option)]
# 
#         disallow the request and return an icmp-unreachable or an RST packet.
#         If no option is passed, Shorewall selects the appropriate option based
#         on the protocol of the packet.
# 
#         Beginning with Shorewall 5.0.8, the type of reject may be specified in
#         the option paramater. Valid IPv4 option values are:
# 
#         icmp-net-unreachable
#         icmp-host-unreachable
#         icmp-port-unreachable
#         icmp-proto-unreachable
#         icmp-net-prohibited
#         icmp-host-prohibited
#         icmp-admin-prohibited
#         icmp-tcp-reset (the PROTO column must specify TCP). Beginning with
#         Shorewall 5.1.3, this option may also be specified as tcp-reset.
# 
#         Valid IPv6 option values are:
# 
#         icmp6-no-route
#         no-route
#         icmp6-adm-prohibited
#         adm-prohibited
#         icmp6-addr-unreachable
#         addr-unreach
#         icmp6-port-unreachable
#         tcp-reset (the PROTO column must specify TCP)
# 
#     REJECT!
# 
#         like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in
#         shorewall.conf(5).
# 
#     REDIRECT
# 
#         Redirect the request to a server running on the firewall. Use with IPv6
#         requires Shorewall 4.5.14 or later.
# 
#     REDIRECT-
# 
#         Advanced users only.
# 
#         Like REDIRECT but only generates the REDIRECT iptables rule and not the
#         companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
#         later.
# 
#     TARPIT [(tarpit | honeypot | reset)]
# 
#         Added in Shorewall 4.6.6.
# 
#         TARPIT captures and holds incoming TCP connections using no local
#         per-connection resources.
# 
#         TARPIT only works with the PROTO column set to tcp (6), and is totally
#         application agnostic. This module will answer a TCP request and play
#         along like a listening server, but aside from sending an ACK or RST, no
#         data is sent. Incoming packets are ignored and dropped. The attacker
#         will terminate the session eventually. This module allows the initial
#         packets of an attack to be captured by other software for inspection.
#         In most cases this is sufficient to determine the nature of the attack.
# 
#         This offers similar functionality to LaBrea <http://www.hackbusters.net
#         /LaBrea/> but does not require dedicated hardware or IPs. Any TCP port
#         that you would normally DROP or REJECT can instead become a tarpit.
# 
#         The target accepts a single optional parameter:
# 
#         tarpit
# 
#             This mode is the default and completes a connection with the
#             attacker but limits the window size to 0, thus keeping the attacker
#             waiting long periods of time. While he is maintaining state of the
#             connection and trying to continue every 60-240 seconds, we keep
#             none, so it is very lightweight. Attempts to close the connection
#             are ignored, forcing the remote side to time out the connection in
#             12-24 minutes.
# 
#         honeypot
# 
#             This mode completes a connection with the attacker, but signals a
#             normal window size, so that the remote side will attempt to send
#             data, often with some very nasty exploit attempts. We can capture
#             these packets for decoding and further analysis. The module does
#             not send any data, so if the remote expects an application level
#             response, the game is up.
# 
#         reset
# 
#             This mode is handy because we can send an inline RST (reset). It
#             has no other function.
# 
#     ULOG[(ulog-parameters)]
# 
#         IPv4 only. Added in Shorewall 4.5.10. Queues matching packets to a back
#         end logging daemon via a netlink socket then continues to the next
#         rule. See shorewall-logging(5).
# 
#         Similar to LOG:ULOG[(ulog-parameters)], except that the log level is
#         not changed when this ACTION is used in an action or macro body and the
#         invocation of that action or macro specifies a log level.
# 
#     The target may optionally be followed by ":" and a syslog log level (e.g,
#     REJECT:info or Web(ACCEPT):debug). This causes the packet to be logged at
#     the specified level. Note that if the ACTION involves destination network
#     address translation (DNAT, REDIRECT, etc.) then the packet is logged before
#     the destination address is rewritten.
# 
#     If the ACTION names an action declared in shorewall-actions(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 (IPv4 only) or NFLOG (must be in upper case) as a
#     log level.This will log to the ULOG or NFLOG target for routing to a
#     separate log through use of ulogd (shorewall-logging(5)).
# 
#     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(5)).
# 
#     Example: ACCEPT:info:ftp would include 'ftp ' at the end of the log prefix
#     generated by the LOGPREFIX setting.
# 
# SOURCE - source-spec[,...]
# 
#     Source hosts to which the rule applies.
# 
#     source-spec is one of the following:
# 
#     zone[,...[+]]
# 
#         The name of a zone defined in shorewall-zones(5). When only the zone
#         name is specified, the packet source may be any host in that zone.
# 
#         zone may also be one of the following:
# 
#         all[+]
# 
#             all, without the "-" means "All Zones, including the firewall
#             zone". Normally all omits intra-zone traffic, but intra-zone
#             traffic can be included specifying "+".
# 
#         any[+]
# 
#             any is equivalent to all when there are no nested zones. When there
#             are nested zones, any only refers to top-level zones (those with no
#             parent zones). Note that any excludes all vserver zones, since
#             those zones are nested within the firewall zone.
# 
#         none
# 
#             When none is used either in the SOURCE or DEST column, the rule is
#             ignored.
# 
#         Similar to with all and any, intra-zone traffic is normally excluded
#         when multiple zones are listed. Intra-zone traffic may be included by
#         following the list with a plus sign ("+").
# 
#         all and any may be followed by an exclamation point ("!") and a
#         comma-separated list of zone names to be omitted.
# 
#     zone:[!]interface
# 
#         When this form is used, interface must be the name of an interface
#         associated with the named zone in either shorewall-interfaces(5) or
#         shorewall-hosts(5). Only packets from hosts in the zone that arrive
#         through the named interface will match the rule.
# 
#         Beginning with Shorweall 5.2.1, the interface may be preceded with '!'
#         which matches all interfaces associated with the zone except the one
#         specified.
# 
#     zone:address[,...]
# 
#         where address can be:
# 
#           ☆ A host or network IP address. A network address may be followed by
#             exclusion (see shorewall-exclusion(5)).
# 
#           ☆ An address range, specified using the syntax lowaddress-highaddress
#             .
# 
#           ☆ +ipset where ipset is the name of an ipset and must be preceded by
#             a plus sign ("+").
# 
#           ☆ A MAC address in Shorewall format (preceded by a tilde ("~") and
#             with the hex byte values separated by dashes (e.g.,
#             "~00-0a-f6-04-9c-7d").
# 
#           ☆ ^country-code where country-code is a two-character ISO-3661
#             country code preceded by a caret ("^").
# 
#           ☆ ^country-code-list where country-code-list is a comma-separated
#             list of up to 15 ISO-3661 country codes enclosed in square brackets
#             ("[...]").
# 
#           ☆ The primary IP address of a firewall interface can be specified by
#             an ampersand ('&') followed by the logical name of the interface as
#             found in the INTERFACE column of shorewall-interfaces (5).
# 
#     zone:interface:address[,...]
# 
#         This form combines the preceding two and requires that both the
#         incoming interface and source address match.
# 
#     zone:exclusion
# 
#         This form matches if the host IP address does not match any of the
#         entries in the exclusion (see shorewall-exclusion(5)).
# 
#     zone:interface:exclusion
# 
#         This form matches packets from the named zone entering through the
#         specified interface where the source address does not match any entry
#         in the exclusion.
# 
#     Beginning with Shorewall 5.1.0, multiple source-specs may be listed,
#     provided that extended forms of the source-spec are used:
# 
#         zone:(interface)
# 
#         zone:(address[,...])
# 
#         zone:(interface:address[,...])
# 
#         zone:(exclusion)
# 
#         zone:(interface:exclusion)
# 
#     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
# 
#     $FW:&eth0
# 
#         The primary IP address of eth0 in the firewall zone.
# 
#     loc,dmz
# 
#         Both the loc and dmz zones.
# 
#     all!dmz
# 
#         All but the dmz zone.
# 
#     all+!$FW
# 
#         All but the firewall zone and applies to intrazone traffic.
# 
#     net:^CN
# 
#         China.
# 
#     loc:(eth1:1.2.3.4,2.3.4.5),dmz:(eth2:5.6.7.8,9.10.11.12),net
# 
#         Hosts 1.2.3.4 and 2.3.4.5 in the loc zone when the packet arrives
#         through eth1 plus hosts 5.6.7.8 and 9.10.11.12 in the dmz zone when the
#         packet arrives through eth2 plus all of the net zone.
# 
#     dmz:[2002:ce7c:2b4:1::2]
# 
#         Host 2002:ce7c:92b4:1::2 in the DMZ
# 
#     net:2001:4d48:ad51:24::/64
# 
#         Subnet 2001:4d48:ad51:24::/64 on the Internet
# 
#     loc:[2002:cec792b4:1::2],[2002:cec792b4:1::44]
# 
#         Hosts 2002:cec792b4:1::2 and 2002:cec792b4:1::44 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:[2001:4d48:ad51:24::]/64![2001:4d48:ad51:24:6::]/80
# 
#         Subnet 2001:4d48:ad51:24::/64 on the Internet except for
#         2001:4d48:ad51:24:6::/80.
# 
# DEST - dest-spec[,...]
# 
#     Destination hosts to which the rule applies.
# 
#     dest-spec is one of the following:
# 
#     zone[,...[+]]
# 
#         The name of a zone defined in shorewall-zones(5). When only the zone
#         name is specified, the packet destination may be any host in that zone.
# 
#         zone may also be one of the following:
# 
#         all[+]
# 
#             all, without the "-" means "All Zones, including the firewall
#             zone". Normally all omits intra-zone traffic, but intra-zone
#             traffic can be included specifying "+".
# 
#         any[+]
# 
#             any is equivalent to all when there are no nested zones. When there
#             are nested zones, any only refers to top-level zones (those with no
#             parent zones). Note that any excludes all vserver zones, since
#             those zones are nested within the firewall zone.
# 
#         none
# 
#             When none is used either in the SOURCE or DEST column, the rule is
#             ignored.
# 
#         Similar to with all and any, intra-zone traffic is normally excluded
#         when multiple zones are listed. Intra-zone traffic may be included by
#         following the list with a plus sign ("+").
# 
#         all and any may be followed by an exclamation point ("!") and a
#         comma-separated list of zone names to be omitted.
# 
#     zone:[!]interface
# 
#         When this form is used, interface must be the name of an interface
#         associated with the named zone in either shorewall-interfaces(5) or
#         shorewall-hosts(5). Only packets to hosts in the zone that are sent
#         through the named interface will match the rule.
# 
#         Beginning with Shorweall 5.2.1, the interface may be preceded with '!'
#         which matches all interfaces associated with the zone except the one
#         specified.
# 
#     zone:address[,...]
# 
#         where address can be:
# 
#           ☆ A host or network IP address. A network address may be followed by
#             exclusion (see shorewall-exclusion(5)).
# 
#           ☆ An address range, specified using the syntax lowaddress-highaddress
#             .
# 
#           ☆ +ipset where ipset is the name of an ipset and must be preceded by
#             a plus sign ("+").
# 
#           ☆ ^country-code where country-code is a two-character ISO-3661
#             country code preceded by a caret ("^").
# 
#           ☆ ^country-code-list where country-code-list is a comma-separated
#             list of up to 15 ISO-3661 country codes enclosed in square brackets
#             ("[...]").
# 
#           ☆ The primary IP address of a firewall interface can be specified by
#             an ampersand ('&') followed by the logical name of the interface as
#             found in the INTERFACE column of shorewall-interfaces (5).
# 
#     zone:[!]interface:address[,...]
# 
#         This form combines the preceding two and requires that both the
#         outgoing interface and destinationaddress match.
# 
#         Beginning with Shorweall 5.2.1, the interface may be preceded with '!'
#         which matches all interfaces associated with the zone except the one
#         specified.
# 
#     zone:exclusion
# 
#         This form matches if the host IP address does not match any of the
#         entries in the exclusion (see shorewall-exclusion(5)).
# 
#     zone:[!]interface:exclusion
# 
#         This form matches packets to the named zone leaving through the
#         specified interface where the destination address does not match any
#         entry in the exclusion.
# 
#         Beginning with Shorweall 5.2.1, the interface may be preceded with '!'
#         which matches all interfaces associated with the zone except the one
#         specified.
# 
#     [zone]:[server-IP][:port-or-port-range[:random]]
# 
#         This form applies when the ACTION is DNAT[-] or REDIRECT[-]. The zone
#         may be omitted in REDIRECT rules ($FW is assumed) and must be omitted
#         in DNAT-, REDIRECT- and NONAT rules.
# 
#         server-IP is not allowed in REDIRECT rules and may be omitted in DNAT
#         [-] rules provided that port-or-port-range is included.
# 
#           ☆ The IP address of the server to which the packet is to be sent.
# 
#           ☆ A range of IP address with the low and high address separated by a
#             dash (:"-"). Connections are distributed among the IP addresses in
#             the range.
# 
#         If server-IP is omitted in a DNAT[-] rule, only the destination port
#         number is modified by the rule.
# 
#         port-or-port-range may be:
# 
#           ☆ An integer port number in the range 1 - 65535.
# 
#           ☆ The name of a service from /etc/services.
# 
#           ☆ A port range with the low and high integer port numbers separated
#             by a dash ("-"). Connections are distributed among the ports in the
#             range.
# 
#         If random is specified, port mapping will be randomized.
# 
#     If the DEST zone is a bport zone, then either:
# 
#      a. the SOURCE must be all[+], or
# 
#      b. the SOURCE zone must be another bport zone associated with the same
#         bridge, or
# 
#      c. the SOURCE zone must be an ipv4 zone that is associated with only the
#         same bridge.
# 
#     Beginning with Shorewall 5.1.0, multiple dest-specs may be listed, provided
#     that extended forms of the source-spec are used:
# 
#         zone:(interface)
# 
#         zone:(address[,...])
# 
#         zone:(interface:address[,...])
# 
#         zone:(exclusion)
# 
#         zone:(interface:exclusion)
# 
#     Multiple dest-specs are not permitted in DNAT[-] and REDIRECT[-] rules.
# 
#     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.
# 
#     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
# 
#     $FW:&eth0
# 
#         The primary IP address of eth0 in the firewall zone.
# 
#     loc,dmz
# 
#         Both the loc and dmz zones.
# 
#     all!dmz
# 
#         All but the dmz zone.
# 
#     net:^CN
# 
#         China.
# 
#     dmz:192.168.10.4:25
# 
#         Port 25 on server 192.168.10.4 in the dmz zone (DNAT rule).
# 
#     loc:(eth1:1.2.3.4,2.3.4.5),dmz:(eth2:5.6.7.8,9.10.11.12),net
# 
#         Hosts 1.2.3.4 and 2.3.4.5 in the loc zone when the packet arrives
#         through eth1 plus hosts 5.6.7.8 and 9.10.11.12 in the dmz zone when the
#         packet arrives through eth2 plus all of the net zone.
# 
# PROTO- {-|tcp:[!]syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|
#     all}
# 
#     Optional 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. Beginning with Shorewall 5.1.3, you may
#     also specify tcp:!syn, which matches if SYN is not set or if RST, ACK or
#     FIN is set.
# 
#     Beginning with Shorewall 4.4.19, this column can contain a comma-separated
#     list of protocol-numbers and/or protocol names.
# 
# DPORT - {-|port-name-number-or-range[,port-name-number-or-range]...|+ipset}
# 
#     Optional 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). ICMP types may be
#     specified as a numeric type, a numeric type and code separated by a slash
#     (e.g., 3/4), or a typename. See http://www.shorewall.net/
#     configuration_file_basics.htm#ICMP. Note that prior to Shorewall 4.4.19,
#     only a single ICMP type may be listed.
# 
#     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 SPORT list below:
# 
#     1. There are 15 or less ports listed.
# 
#     2. No port ranges are included or your kernel and iptables contain extended
#     multi-port match support.
# 
#     Beginning with Shorewall 4.6.0, an ipset name can be specified in this
#     column. This is intended to be used with bitmap:port ipsets.
# 
#     This column was formerly labelled DEST PORT(S).
# 
# SPORT - {-|port-name-number-or-range[,port-name-number-or-range]...|+ipset}
# 
#     Optional 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.
# 
#     Beginning with Shorewall 4.5.15, you may place '=' in this column, provided
#     that the DPORT column is non-empty. This causes the rule to match when
#     either the source port or the destination port in a packet matches one of
#     the ports specified in DEST PORTS(S). Use of '=' requires multi-port match
#     in your iptables and kernel.
# 
#     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 ORIGDEST
#     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 DPORT list above:
# 
#     1. There are 15 or less ports listed.
# 
#     2. No port ranges are included or your kernel and iptables contain extended
#     multi-port match support.
# 
#     Beginning with Shorewall 4.6.0, an ipset name can be specified in this
#     column. This is intended to be used with bitmap:port ipsets.
# 
#     This column was formerly labelled SOURCE PORT(S).
# 
# ORIGDEST - [-|address[,address]...[exclusion]|exclusion]
# 
#     Optional. If ACTION is DNAT[-] or REDIRECT[-] then if this column is
#     included and is different from the IP address given in the DEST 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.
# 
#     Beginning with Shorewall 4.4.17, the primary IP address of a firewall
#     interface can be specified by an ampersand ('&') followed by the logical
#     name of the interface as found in the INTERFACE column of
#     shorewall-interfaces (5).
# 
#     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(5).
# 
#     See http://www.shorewall.net/PortKnocking.html for an example of using an
#     entry in this column with a user-defined action rule.
# 
#     This column was formerly labelled ORIGINAL DEST.
# 
# RATE - limit
# 
#     where limit is one of:
# 
#     [-|[{s|d}[/vlsm]:[name[(ht-buckets,ht-max)]:]rate/{sec|min|hour|day}[:burst
#     ]
#     [s[/vlsm1]:][name1[(ht-buckets1,ht-max1)]:]rate1/{sec|min|hour|day}[:burst1
#     ],[d[/vlsm2:][name2[(ht-buckets2,ht-max2)]:]rate2/{sec|min|hour|day}[:
#     burst2]
# 
#     You may optionally 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 white-space embedded in the specification.
# 
#     Example: 10/sec:20
# 
#     When s: or d: is specified, the rate applies per source IP address or per
#     destination IP address respectively. The names may be chosen by the user
#     and specify a hash table to be used to count matching connections. If not
#     given, the name shorewallN (where N is a unique integer) is assumed. Where
#     more than one rule or POLICY specifies the same name, the connections
#     counts for the rules are aggregated and the individual rates apply to the
#     aggregated count. Beginning with Shorewall 5.2.1, the s or d may be
#     followed by a slash ("/") and an integer vlsm. When a vlsm is specified,
#     all source or destination addresses encountered will be grouped according
#     to the given prefix length and the so-created subnet will be subject to the
#     rate limit.
# 
#     Example: s/24::10/sec
# 
#     Beginning with Shorewall 4.6.5, two limits may be specified, separated by a
#     comma. In this case, the first limit (name1, rate1, burst1) specifies the
#     per-source IP limit and the second limit specifies the per-destination IP
#     limit.
# 
#     Example: client:10/sec:20,:60/sec:100
# 
#     In this example, the 'client' hash table will be used to enforce the
#     per-source limit and the compiler will pick a unique name for the hash
#     table that tracks the per-destination limit.
# 
#     Beginning with Shorewall 5.2.1, the table name, if any, may be followed by
#     two integers separated by commas and enclosed in parentheses. The first
#     integer (ht-buckets) specifies the number of buckets in the generated hash
#     table. The second integer (ht-max) specifies the maximum number of entries
#     in the hash table.
# 
#     Example: s:netfw(1024,65536):10/sec
# 
#     This column was formerly labelled RATE LIMIT.
# 
# USER - [!][user-name-or-number][:group-name-or-number][,...]
# 
#     This optional 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).
# 
#     Beginning with Shorewall 4.5.8, multiple user or group names/ids separated
#     by commas may be specified.
# 
#     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
# 
#     2001-2099
# 
#         UIDs 2001 through 2099 (Shorewall 4.5.6 and later)
# 
#     This column was formerly labelled USER/GROUP.
# 
# 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.
# 
# CONNLIMIT - [d:][!]limit[:mask]
# 
#     May be used to limit the number of simultaneous connections to/from each
#     individual host or network to limit connections. Requires connlimit match
#     in your kernel and iptables. While the limit is only checked on rules
#     specifying CONNLIMIT, the number of current connections is calculated over
#     all current connections from the SOURCE or DESTINATION host. By default,
#     limiting is done by SOURCE host or net, but if the specification begins
#     with d:, then limiting will be donw by destination host or net.
# 
#     By default, the limit is applied to each host but can be made to apply to
#     networks of hosts by specifying a mask. The mask specifies the width of a
#     VLSM mask to be applied to the source address; the number of current
#     connections is then taken over all hosts in the subnet source-address/mask.
#     When ! is specified, the rule matches when the number of connection exceeds
#     the limit.
# 
# TIME - timeelement[&timeelement...]
# 
#     May be used to limit the rule to a particular time period each day, to
#     particular days of the week or month, or to a range defined by dates and
#     times. Requires time match support in your kernel and iptables.
# 
#     timeelement may be:
# 
#     timestart=hh:mm[:ss]
# 
#         Defines the starting time of day.
# 
#     timestop=hh:mm[:ss]
# 
#         Defines the ending time of day.
# 
#     contiguous
# 
#         Added in Shoreawll 5.0.12. When timestop is smaller than timestart
#         value, match this as a single time period instead of distinct
#         intervals.
# 
#     utc
# 
#         Times are expressed in Greenwich Mean Time.
# 
#     localtz
# 
#         Deprecated by the Netfilter team in favor of kerneltz. Times are
#         expressed in Local Civil Time (default).
# 
#     kerneltz
# 
#         Added in Shorewall 4.5.2. Times are expressed in Local Kernel Time
#         (requires iptables 1.4.12 or later).
# 
#     weekdays=ddd[,ddd]...
# 
#         where ddd is one of Mon, Tue, Wed, Thu, Fri, Sat or Sun
# 
#     monthdays=dd[,dd],...
# 
#         where dd is an ordinal day of the month
# 
#     datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
# 
#         Defines the starting date and time.
# 
#     datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
# 
#         Defines the ending date and time.
# 
# HEADERS - [!][any:|exactly:]header-list (Optional - Added in Shorewall 4.4.15)
# 
#     This column is only used in IPv6. In IPv4, supply "-" in this column if you
#     with to place a value in one of the following columns.
# 
#     The header-list consists of a comma-separated list of headers from the
#     following list.
# 
#     auth, ah, or 51
# 
#         Authentication Headers extension header.
# 
#     esp, or 50
# 
#         Encrypted Security Payload extension header.
# 
#     hop, hop-by-hop or 0
# 
#         Hop-by-hop options extension header.
# 
#     route, ipv6-route or 43
# 
#         IPv6 Route extension header.
# 
#     frag, ipv6-frag or 44
# 
#         IPv6 fragmentation extension header.
# 
#     none, ipv6-nonxt or 59
# 
#         No next header
# 
#     proto, protocol or 255
# 
#         Any protocol header.
# 
#     If any: is specified, the rule will match if any of the listed headers are
#     present. If exactly: is specified, the will match packets that exactly
#     include all specified headers. If neither is given, any: is assumed.
# 
#     If ! is entered, the rule will match those packets which would not be
#     matched when ! is omitted.
# 
# SWITCH - [!]switch-name[={0|1}]
# 
#     Added in Shorewall 4.4.24 and allows enabling and disabling the rule
#     without requiring shorewall restart.
# 
#     The rule is enabled if the value stored in /proc/net/nf_condition/
#     switch-name is 1. The rule is disabled if that file contains 0 (the
#     default). If '!' is supplied, the test is inverted such that the rule is
#     enabled if the file contains 0.
# 
#     Within the switch-name, '@0' and '@{0}' are replaced by the name of the
#     chain to which the rule is a added. The switch-name (after '@...'
#     expansion) must begin with a letter and be composed of letters, decimal
#     digits, underscores or hyphens. Switch names must be 30 characters or less
#     in length.
# 
#     Switches are normally off. To turn a switch on:
# 
#     echo 1 > /proc/net/nf_condition/switch-name
# 
#     To turn it off again:
# 
#     echo 0 > /proc/net/nf_condition/switch-name
# 
#     Switch settings are retained over shorewall restart.
# 
#     Beginning with Shorewall 4.5.10, when the switch-name is followed by =0 or
#     =1, then the switch is initialized to off or on respectively by the start
#     command. Other commands do not affect the switch setting.
# 
# HELPER - [helper]
# 
#     Added in Shorewall 4.5.7.
# 
#     In the NEW section, causes the named conntrack helper to be associated with
#     this connection; the contents of this column are ignored unless ACTION is
#     ACCEPT*, DNAT* or REDIRECT*.
# 
#     In the RELATED section, will only match if the related connection has the
#     named helper associated with it.
# 
#     The helper may be one of:
# 
#     amanda
#     ftp
#     irc
#     netbios-ns
#     pptp
#     Q.931
#     RAS
#     sane
#     sip
#     snmp
#     tftp
# 
#     If the HELPERS option is specified in shorewall.conf(5), then any module
#     specified in this column must be listed in the HELPERS setting.
# 
# Examples
# 
# Example 1:
# 
#     Accept SMTP requests from the DMZ to the internet
# 
#              #ACTION SOURCE  DEST      PROTO      DPORT   SPORT   ORIGDEST
#              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   DPORT   SPORT   ORIGDEST
#             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  DPORT SPORT   ORIGDEST RATE
#             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 DPORT   SPORT   ORIGDEST
#             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   DPORT   SPORT   ORIGDEST
#             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   DPORT   SPORT   ORIGDEST
#             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   DPORT   SPORT   ORIGDEST
#             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 DPORT   SPORT   ORIGDEST
#             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, when
#     using Shorewall versions before 4.1.4, 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(5):
# 
#             #ZONE       TYPE    OPTIONS
#             fw          firewall
#             net         ipv4
#             dmz         ipv4
#             loc         ipv4
# 
#     shorewall-interfaces(5):
# 
#             #ZONE       INTERFACE       BROADCAST      OPTIONS
#             net         ppp0
#             loc         eth1            detect
#             dmz         eth2            detect
#             -           ppp+                           # Addresses are assigned from 192.168.3.0/24
# 
#     shorewall-host(5):
# 
#             #ZONE       HOST(S)              OPTIONS
#             loc         ppp+:192.168.3.0/24
# 
#     rules:
# 
#             #ACTION     SOURCE          DEST       PROTO       DPORT
#             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.
# 
# Example 10:
# 
#     Add the tuple (source IP, dest port, dest IP) of an incoming SSH connection
#     to the ipset S:
# 
#             #ACTION                       SOURCE           DEST           PROTO       DPORT
#             ADD(+S:dst,src,dst)           net              fw             tcp         22
# 
# Example 11:
# 
#     You wish to limit SSH connections from remote systems to 1/min with a burst
#     of three (to allow for limited retry):
# 
#             #ACTION     SOURCE          DEST       PROTO       DPORT        SPORT     ORIGDEST         RATE
#             SSH(ACCEPT) net             all        -           -            -         -                s:1/min:3
# 
# Example 12:
# 
#     Forward port 80 to dmz host $BACKUP if switch 'primary_down' is on.
# 
#             #ACTION     SOURCE          DEST        PROTO       DPORT        SPORT     ORIGDEST   RATE      USER      MARK    CONNLIMIT     TIME     HEADERS    SWITCH
#             DNAT        net             dmz:$BACKUP tcp         80           -         -          -         -         -       -             -        -          primary_down
# 
# Example 13:
# 
#     Drop all email from the Anonymous Proxy and Satellite Provider address
#     ranges:
# 
#             #ACTION                       SOURCE           DEST           PROTO       DPORT
#             DROP                          net:^A1,A2       fw             tcp         25
# 
# Example 14:
# 
#     You want to generate your own rule involving iptables targets and matches
#     not supported by Shorewall.
# 
#             #ACTION                       SOURCE           DEST           PROTO       DPORT
#             INLINE                        $FW              net ; -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3
# 
#     The above will generate the following iptables-restore input:
# 
#             -A fw2net -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3
# 
#     Note that SECCTX must be defined as a builtin action in shorewall-actions
#     (5):
# 
#             #ACTION            OPTIONS
#             SECCTX             builtin
# 
# Example 15:
# 
#     You want to accept SSH connections to your firewall only from internet IP
#     addresses 2002:ce7c::92b4:1::2 and 2002:ce7c::92b4:1::22
# 
#             #ACTION  SOURCE DEST            PROTO   DPORT   SPORT   ORIGDEST
#             ACCEPT   net:<2002:ce7c::92b4:1::2,2002:ce7c::92b4:1::22> \
#                             $FW              tcp     22
# 
######################################################################################################################################################################################################
#ACTION		SOURCE		DEST		PROTO	DEST	SOURCE		ORIGINAL	RATE		USER/	MARK	CONNLIMIT	TIME		HEADERS		SWITCH		HELPER
#							PORT	PORT(S)		DEST		LIMIT		GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW
#       Don't allow connection pickup from the net
#
Invalid(DROP)	net		all		tcp
#
#	Accept DNS connections from the firewall to the Internet
#
DNS(ACCEPT)	$FW		net
#
#
#	Accept SSH connections from the local network to the firewall and DMZ
#
SSH(ACCEPT)     loc             $FW
SSH(ACCEPT)     loc             dmz
#
#	DMZ DNS access to the Internet
#
DNS(ACCEPT)	dmz		net
# Drop Ping from the "bad" net zone.
Ping(DROP)   	net             $FW
#
#       Make ping work bi-directionally between the dmz, net, Firewall and local zone
#       (assumes that the loc-> net policy is ACCEPT).
#
Ping(ACCEPT)    loc             $FW
Ping(ACCEPT)    dmz             $FW
Ping(ACCEPT)    loc             dmz
Ping(ACCEPT)    dmz             loc
Ping(ACCEPT)    dmz             net
ACCEPT		$FW		net		ipv6-icmp
ACCEPT		$FW		loc		ipv6-icmp
ACCEPT		$FW		dmz		ipv6-icmp
# Uncomment this if using Proxy ARP and static NAT and you want to allow ping from
# the net zone to the dmz and loc
#Ping(ACCEPT)    net             dmz
#Ping(ACCEPT)    net             loc