#
# Shorewall -- /etc/shorewall/actions
#
# For information about entries in this file, type "man shorewall-actions"
#
# Please see http://shorewall.net/Actions.html for additional information.
#
# Place '# ' below the 'C' in COMMENT followed by a comment describing
# the action.
#
###############################################################################
# 
# This file allows you to define new ACTIONS for use in rules (see
# shorewall-rules(5)). You define the iptables rules to be performed in an ACTION
# in /etc/shorewall/action.action-name.
# 
# Columns are:
# 
# NAME
# 
#     The name of the action. ACTION names should begin with an upper-case letter
#     to distinguish them from Shorewall-generated chain names and be composed of
#     letters, digits or numbers. If you intend to log from the action then the
#     name must be no longer than 11 characters in length if you use the standard
#     LOGFORMAT.
# 
# OPTIONS
# 
#     Added in Shorewall 4.5.10. Available options are:
# 
#     audit
# 
#         Added in Shorewall 5.0.7. When this option is specified, the action is
#         expected to have at least two parameters; the first is a target and the
#         second is either 'audit' or omitted. If the second is 'audit', then the
#         first must be an auditable target (ACCEPT, DROP or REJECT).
# 
#     builtin
# 
#         Added in Shorewall 4.5.16. Defines the action as a rule target that is
#         supported by your iptables but is not directly supported by Shorewall.
#         The action may be used as the rule target in an INLINE rule in
#         shorewall-rules(5).
# 
#         Beginning with Shorewall 4.6.0, the Netfilter table(s) in which the 
#         builtin can be used may be specified: filter, nat, mangle and raw. If
#         no table name(s) are given, then filter is assumed. The table names
#         follow builtin and are separated by commas; for example, "FOOBAR
#         builtin,filter,mangle" would specify FOOBAR as a builtin target that
#         can be used in the filter and mangle tables.
# 
#         Beginning with Shorewall 4.6.4, you may specify the terminating option
#         with builtin to indicate to the Shorewall optimizer that the action is
#         terminating (the current packet will not be passed to the next rule in
#         the chain).
# 
#     inline
# 
#         Causes the action body (defined in action.action-name) to be expanded
#         in-line like a macro rather than in its own chain. You can list
#         Shorewall Standard Actions in this file to specify the inline option.
# 
#         Caution
# 
#         Some of the Shorewall standard actions cannot be used in-line and will
#         generate a warning and the compiler will ignore inline if you try to
#         use them that way:
# 
#         DropSmurfs
#         IfEvent
#         Invalid (Prior to Shorewall 4.5.13)
#         NotSyn (Prior to Shorewall 4.5.13)
#         RST (Prior to Shorewall 4.5.13)
#         TCPFlags
# 
#     logjump
# 
#         Added in Shorewall 5.0.8. Performs the same function as nolog (below),
#         with the addition that the jump to the actions chain is logged if a log
#         level is specified on the action invocation. For inline actions, this
#         option is identical to nolog.
# 
#     mangle
# 
#         Added in Shorewall 5.0.7. Specifies that this action is to be used in
#         shorewall-mangle(5) rather than shorewall-rules(5).
# 
#     nat
# 
#         Added in Shorewall 5.0.13. Specifies that this action is to be used in
#         shorewall-snat(5) rather than shorewall-rules(5). The mangle and nat
#         options are mutually exclusive.
# 
#     noinline
# 
#         Causes any later inline option for the same action to be ignored with a
#         warning.
# 
#     nolog
# 
#         Added in Shorewall 4.5.11. When this option is specified, the compiler
#         does not automatically apply the log level and/or tag from the
#         invocation of the action to all rules inside of the action. Rather, it
#         simply sets the $_loglevel and $_logtag shell variables which can be
#         used within the action body to apply those logging options only to a
#         subset of the rules.
# 
#     proto=protocol
# 
#         Added in Shorewall 5.1.10. Specifies that the action is only usable
#         with the specified protocol (name or number). When the action is
#         invoked with no protocol specified in the PROTO column, or if the
#         action is used as a Policy Action, the named protocol will be assumed.
#         If a protocol is specified in the PROTO column of an invocation, then
#         it must match the named protocol.
# 
#         The proto option has no effect if the inline or builtin option is
#         specified. A warning is issued if proto is specified along with
#         builtin.
# 
#     section
# 
#         Added in Shorewall 5.1.1. When specified, this option causes the rules
#         file section name and a comma to be prepended to the parameters passed
#         to the action (if any). Note that this means that the first parameter
#         passed to the action by the user is actually the second parameter to
#         the action. If the action is invoked out of the blrules file,
#         'BLACKLIST' is used as the section name.
# 
#         Given that neither the snat nor the mangle file is sectioned, this
#         parameter has no effect when mangle or nat is specified.
# 
#     state={UNTRACKED|NEW|ESTABLISHED|RELATED|INVALID}
# 
#         Added in Shorewall 5.0.7. Reserved for use by Shorewall in actions.std.
# 
#     terminating
# 
#         Added in Shorewall 4.6.4. When used with builtin, indicates that the
#         built-in action is termiating (i.e., if the action is jumped to, the
#         next rule in the chain is not evaluated).
# 
###############################################################################
#ACTION		OPTIONS		COMMENT