Sophie: shorewall-ipv6-5.2.3.3-1.mga7 noarch

shorewall-ipv6-5.2.3.3-1.mga7.noarch.rpm

#
# Shorewall6 version 5 - Sample Rules File for one-interface configuration.
# Copyright (C) 2006-2015 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 on 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 is silently bypassed instead. The packet will
# move on to the next rule. 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
# Drop packets in the INVALID state
Invalid(DROP) net $FW tcp
# Drop Ping from the "bad" net zone.. and prevent your log from being flooded..
Ping(DROP) net $FW
# Permit all ICMP traffic FROM the firewall TO the net zone
ACCEPT $FW net ipv6-icmp