actions — Shorewall action declaration file
/etc/shorewall[6]/actions 
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:
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.
Added in Shorewall 4.5.10. Available options are:
auditAdded 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).
builtinAdded 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).
inlineCauses 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.
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 | 
logjumpAdded 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.
mangleAdded in Shorewall 5.0.7. Specifies that this action is to be used in shorewall-mangle(5) rather than shorewall-rules(5).
natAdded 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.
noinlineCauses any later inline option for the
                same action to be ignored with a warning.
nologAdded 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=protocolAdded 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.
dport=portorserviceAdded in Shorewall 5.2.6. Requires that the proto option be previously given and
                indicates that this action may only be applied to flows with
                the specified protocol and
                portorservice.
                portorservice may be a valid port
                number or the name of a service defined in /etc/services to be
                usable with the specified protocol.
                If a port or service is specified in the DPORT column of an
                invocation, then it must match the named
                portorservice.
sectionAdded 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.
terminatingAdded 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).