1SHOREWALL.CONF(5)             Configuration Files            SHOREWALL.CONF(5)
2
3
4

NAME

6       shorewall.conf - Shorewall global configuration file
7

SYNOPSIS

9       /etc/shorewall/shorewall.conf
10
11       /etc/shorewall6/shorewall6.conf
12

DESCRIPTION

14       The IPv4 and IPv6 environments each have their own configuration. The
15       IPv4 configuration resides in /etc/shorewall/ while the IPv6
16       configuration resides in /etc/shorewall6/.
17
18       The .conf files set options that apply to Shorewall and Shorewall6 as a
19       whole.
20
21       The .conf files consist of Shell comments (lines beginning with '#'),
22       blank lines and assignment statements (variable=value). If the value
23       contains shell meta characters or white-space, then it must be enclosed
24       in quotes. Example: MACLIST_LOG_LEVEL="NFLOG(1,0,1)".
25

OPTIONS

27       Many options have as their value a log-level. Log levels are a method
28       of describing to syslog (8) the importance of a message and a number of
29       parameters in this file have log levels as their value.
30
31       These levels are defined by syslog and are used to determine the
32       destination of the messages through entries in /etc/syslog.conf (5).
33       The syslog documentation refers to these as "priorities"; Netfilter
34       calls them "levels" and Shorewall also uses that term.
35
36       Valid levels are:
37
38                  7       debug
39                  6       info
40                  5       notice
41                  4       warning
42                  3       err
43                  2       crit
44                  1       alert
45                  0       emerg
46
47       For most Shorewall logging, a level of 6 (info) is appropriate.
48       Shorewall log messages are generated by NetFilter and are logged using
49       facility 'kern' and the level that you specify. If you are unsure of
50       the level to choose, 6 (info) is a safe bet. You may specify levels by
51       name or by number.
52
53       If you have built your kernel with ULOG (IPv4 only) and/or NFLOG target
54       support, you may also specify a log level of ULOG and/or NFLOG (must be
55       all caps). Rather than log its messages to syslogd, Shorewall will
56       direct netfilter to log the messages via the ULOG or NFLOG target which
57       will send them to a process called 'ulogd'. ulogd is available with
58       most Linux distributions (although it probably isn't installed by
59       default).
60
61           Note
62           If you want to specify parameters to ULOG or NFLOG (e.g.,
63           NFLOG(1,0,1)), then you must quote the setting.
64
65           Example:
66
67               LOG_LEVEL="NFLOG(1,0,1)"
68
69       Beginning with Shorewall 5.0.0, the log level may be followed by a
70       colon (":") and a log tag. The log tag normally follows the packet
71       disposition in Shorewall-generated Netfilter log messages, separated
72       from the disposition by a colon (e.g, "DROP:mytag"). See LOGTAGONLY
73       below for additional information.
74
75       Beginning with Shorewall 4.4.22, LOGMARK is also a valid level which
76       logs the packet's mark value along with the other usual information.
77       The syntax is:
78           LOGMARK[(priority)]
79
80       where priority is one of the levels listed in the list above. If
81       omitted, the default is info (6).
82
83       The following options may be set in shorewall.conf.
84
85       ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none}
86
87       BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
88
89       DROP_DEFAULT={action[(parameters)][:level][,...]|none}
90
91       NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
92
93       QUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
94
95       REJECT_DEFAULT={action[(parameters)][:level][,...]|none}
96           In earlier Shorewall versions, a "default action" for DROP and
97           REJECT policies was specified in the file
98           /usr/share/shorewall/actions.std.
99
100           In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT,
101           ACCEPT_DEFAULT, QUEUE_DEFAULT and NFQUEUE_DEFAULT options were
102           added.
103
104           DROP_DEFAULT describes the rules to be applied before a connection
105           request is dropped by a DROP policy; REJECT_DEFAULT describes the
106           rules to be applied if a connection request is rejected by a REJECT
107           policy. The other three are similar for ACCEPT, QUEUE and NFQUEUE
108           policies.
109
110           The value applied to these may be:
111               a) The name of an action. The
112                           name may optionally be followed by a
113               comma-separated list of
114                           parameters enclosed in parentheses if the specified
115               action accepts
116                           parameters (e.g., 'Drop(audit)').
117               c) None or none
118           Prior to Shorewall 5.1.2, the default values are:
119               DROP_DEFAULT="Drop"
120               REJECT_DEFAULT="Reject"
121               BLACKLIST_DEFAULT="Drop" (added in Shorewall
122                           5.1.1)
123               ACCEPT_DEFAULT="none"
124               QUEUE_DEFAULT="none"
125               NFQUEUE_DEFAULT="none"
126           Beginning with Shorewall 5.1.2, the default value is 'none' for all
127           of these. Note that the sample configuration files do, however,
128           provide settings for DROP_DEFAULT, BLACKLIST_DEFAULT and
129           REJECT_DEFAULT.
130
131           If you set the value of either option to "None" then no default
132           action will be used and the default action or macro must be
133           specified in shorewall-policy[1](5).
134
135           You can pass parameters to the specified action (e.g.,
136           myaction(audit,DROP)).
137
138           Beginning with Shorewall 4.5.10, the action name can be followed
139           optionally by a colon and a log level. The level will be applied to
140           each rule in the action or body that does not already have a log
141           level.
142
143           Beginning with Shorewall 5.1.2, multiple
144           action[(parameters)][:level] specifications may be listed,
145           separated by commas.
146
147       ACCOUNTING=[Yes|No]
148           Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is
149           enabled (see shorewall-accounting[2](5)). If not specified or set
150           to the empty value, ACCOUNTING=Yes is assumed.
151
152       ACCOUNTING_TABLE=[filter|mangle]
153           Added in Shorewall 4.4.20. This setting determines which Netfilter
154           table the accounting rules are added in. By default,
155           ACCOUNTING_TABLE=filter is assumed. See also
156           shorewall-accounting[2](5).
157
158       ADD_IP_ALIASES=[Yes|No]
159           This parameter determines whether Shorewall automatically adds the
160           external address(es) in shorewall-nat[3](5), and is only available
161           in IPv4 configurations. If the variable is set to Yes or yes then
162           Shorewall automatically adds these aliases. If it is set to No or
163           no, you must add these aliases yourself using your distribution's
164           network configuration tools.
165
166           If this variable is not set or is given an empty value
167           (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.
168
169               Warning
170               Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
171               during shorewall reload and shorewall restart. As a
172               consequence, connections using those addresses may be severed.
173
174       ADD_SNAT_ALIASES=[Yes|No]
175           This parameter determines whether Shorewall automatically adds the
176           SNAT ADDRESS in shorewall-masq[4](5), and is only available in IPv4
177           configurations. If the variable is set to Yes or yes then Shorewall
178           automatically adds these addresses. If it is set to No or no, you
179           must add these addresses yourself using your distribution's network
180           configuration tools.
181
182           If this variable is not set or is given an empty value
183           (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.
184
185               Warning
186               Addresses added by ADD_SNAT_ALIASES=Yes are deleted and
187               re-added during shorewall reload and shorewall restart. As a
188               consequence, connections using those addresses may be severed.
189
190       ADMINISABSENTMINDED=[Yes|No]
191           The value of this variable affects Shorewall's stopped state. The
192           behavior differs depending on whether shorewall-routestopped[5](5)
193           or shorewall-stoppedrules[6](5) is used:
194
195           routestopped
196               When ADMINISABSENTMINDED=No, only traffic to/from those
197               addresses listed in routestopped is accepted when Shorewall is
198               stopped. When ADMINISABSENTMINDED=Yes, in addition to traffic
199               to/from addresses in routestopped, connections that were active
200               when Shorewall stopped continue to work and all new connections
201               from the firewall system itself are allowed.
202
203               Note that the routestopped file is not supported in Shorewall
204               5.0 and later versions.
205
206           stoppedrules
207               All existing connections continue to work. To sever all
208               existing connections when the firewall is stopped, install the
209               conntrack utility and place the command conntrack -F in the
210               stopped user exit (/etc/shorewall/stopped).
211
212               If ADMINISABSENTMINDED=No, only new connections matching
213               entries in stoppedrules are accepted when Shorewall is stopped.
214               Response packets and related connections are automatically
215               accepted.
216
217               If ADMINISABSENTMINDED=Yes, in addition to connections matching
218               entries in stoppedrules, all new connections from the firewall
219               system itself are allowed when the firewall is stopped.
220               Response packets and related connections are automatically
221               accepted.
222
223           If this variable is not set or is given the empty value then
224           ADMINISABSENTMINDED=No is assumed.
225
226       ARPTABLES=[pathname]
227           Added in Shorewall 4.5.12 and available in IPv4 only. This
228           parameter names the arptables executable to be used by Shorewall.
229           If not specified or if specified as a null value, then the
230           arptables executable located using the PATH option is used.
231
232           Regardless of how the arptables utility is located (specified via
233           arptables= or located via PATH), Shorewall uses the
234           arptables-restore and arptables-save utilities from that same
235           directory.
236
237       AUTOCOMMENT=[Yes|No]
238           Formerly named AUTO_COMMENT. If set, if there is not a current
239           comment when a macro is invoked, the behavior is as if the first
240           line of the macro file was "COMMENT <macro name>". If not
241           specified, the AUTO_COMMENT option has a default value of 'Yes'.
242
243       AUTOHELPERS=[Yes|No]
244           Added in Shorewall 4.5.7. When set to Yes (the default), the
245           generated ruleset will automatically associate helpers with
246           applications that require them (FTP, IRC, etc.). When configuring
247           your firewall on systems running kernel 3.5 or later, it is
248           recommended that you:
249
250            1. Set AUTOHELPERS=No.
251
252            2. Modify the HELPERS setting (see below) to list the helpers that
253               you need.
254
255            3. Either:
256
257                1. Modify shorewall-conntrack[7] (5) to only apply helpers
258                   where they are required; or
259
260                2. Specify the appropriate helper in the HELPER column in
261                   shorewall-rules[8] (5).
262
263                       Note
264                       The macros for those applications requiring a helper
265                       automatically specify the appropriate HELPER where
266                       required.
267
268       AUTOMAKE=[Yes|No|recursive|depth]
269           If set, the behavior of the start, reload and restart commands are
270           changed; if no files in CONFIG_PATH (see below) have been changed
271           since the last successful start, reload or restart command, then
272           the compilation step is skipped and the compiled script that
273           executed the last start, reload or restart command is used. If not
274           specified, the default is AUTOMAKE=No.
275
276           The setting of the AUTOMAKE option is ignored if the start, reload
277           or restart command includes a directory name (e.g., shorewall
278           restart /etc/shorewall.new).
279
280           When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
281           searched recursively for files newer than the compiled script. That
282           was changed in Shorewall 5.1.10.2 such that only the listed
283           directories themselves were searched. That broke some
284           configurations that played tricks with embedded SHELL such as
285           "SHELL cat /etc/shorewall/rules.d/loc/*.rules".  Prior to 5.1.10.2,
286           a change to a file in or adding a file to
287           /etc/shorewall/rules.d/loc/ would trigger recompilation. Beginning
288           with 5.1.10.2, such changes would not trigger recompilation.
289           Beginning with Shorewall 5.2.0, the pre-5.1.10.2 behavior can be
290           obtained by setting AUTOMAKE=recursive.
291
292           Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a
293           numeric depth which specifies how deeply each listed directory is
294           to be searched. AUTOMAKE=1 only searches each directory itself and
295           is equivalent to AUTOMAKE=Yes. AUTOMAKE=2 will search each
296           directory and its immediate sub-directories; AUTOMAKE=3 will search
297           each directory, each of its immediate sub-directories, and each of
298           their immediate sub-directories, etc.
299
300       BALANCE_PROVIDERS=[Yes|No]
301           Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option
302           determines whether the balance provider option (see
303           shorewall-providers(5)[9]) is the default. When
304           BALANCE_PROVIDERS=Yes, then the balance option is assumed unless
305           the fallback, loose, load or tproxy option is specified. If this
306           option is not set or is set to the empty value, then the default
307           value is the value of USE_DEFAULT_RT.
308
309       BASIC_FILTERS=[Yes|No]
310           Added in Shorewall-4.6.0. When set to Yes, causes entries in
311           shorewall-tcfilters(5)[10] to generate a basic filter rather than a
312           u32 filter. This setting requires the Basic Ematch capability in
313           your kernel and iptables.
314
315               Note
316               One of the advantages of basic filters is that ipset matches
317               are supported in newer iproute2 and kernel versions. Because
318               Shorewall cannot reliably detect this capability, use of basic
319               filters is controlled by this option.
320           The default value is No which causes u32 filters to be generated.
321
322       BLACKLIST=[{ALL|state[,...]}]
323           where state is one of NEW, ESTABLISHED, RELATED, INVALID,or
324           UNTRACKED.
325
326           Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option.
327           Specifies the connection tracking states that are to be subject to
328           blacklist screening. If BLACKLIST is not specified then the states
329           subject to blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.
330
331           ALL sends all packets through the blacklist chains.
332
333           Note: The ESTABLISHED state may not be specified if FASTACCEPT=Yes
334           is specified.
335
336       BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
337           This parameter determines the disposition of packets from
338           blacklisted hosts. It may have the value DROP if the packets are to
339           be dropped or REJECT if the packets are to be replied with an ICMP
340           port unreachable reply or a TCP RST (tcp only). If you do not
341           assign a value or if you assign an empty value then DROP is
342           assumed.
343
344           A_DROP and A_REJECT are audited versions of DROP and REJECT
345           respectively and were added in Shorewall 4.4.20. They require
346           AUDIT_TARGET in the kernel and iptables.
347
348           The BLACKLIST_DISPOSITION setting determines the disposition of
349           packets sent to the blacklog target of shorewall-blrules[11](5),
350           but otherwise does not affect entries in that file.
351
352       BLACKLIST_LOG_LEVEL=[log-level[:log-tag]]
353           Formerly named BLACKLIST_LOGLEVEL. This parameter determines if
354           packets from blacklisted hosts are logged and it determines the
355           syslog level that they are to be logged at. Its value is a syslog
356           level (Example: BLACKLIST_LOG_LEVEL=debug). If you do not assign a
357           value or if you assign an empty value then packets from blacklisted
358           hosts are not logged. The setting determines the log level of
359           packets sent to the blacklog target of shorewall-blrules[11](5).
360
361       CLAMPMSS=[Yes|No|value]
362           This parameter enables the TCP Clamp MSS to PMTU feature of
363           Netfilter and is usually required when your internet connection is
364           through PPPoE or PPTP. If set to Yes or yes, the feature is
365           enabled. If left blank or set to No or no, the feature is not
366           enabled.
367
368           Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your
369           kernel.
370
371           You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400).
372           This will set the MSS field in TCP SYN packets going through the
373           firewall to the value that you specify.
374
375       CLEAR_TC=[Yes|No]
376           If this option is set to No then Shorewall won't clear the current
377           traffic control rules during [re]start or reload. This setting is
378           intended for use by people who prefer to configure traffic shaping
379           when the network interfaces come up rather than when the firewall
380           is started. If that is what you want to do, set TC_ENABLED=Yes and
381           CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
382           way, your traffic shaping rules can still use the “fwmark”
383           classifier based on packet marking defined in
384           shorewall-tcrules[12](5). If not specified, CLEAR_TC=Yes is
385           assumed.
386
387               Warning
388               When you specify TC_ENABLED=shared (see below), then you should
389               also specify CLEAR_TC=No.
390
391       COMPLETE=[Yes|No]
392           Added in Shorewall 4.4.12. When you set this option to Yes, you are
393           asserting that the configuration is complete so that your set of
394           zones encompasses any hosts that can send or receive traffic
395           to/from/through the firewall. This causes Shorewall to omit the
396           rules that catch packets in which the source or destination IP
397           address is outside of any of your zones. Default is No. It is
398           recommended that this option only be set to Yes if:
399
400           ·   You have defined an interface whose effective physical setting
401               is '+'.
402
403           ·   That interface is assigned to a zone.
404
405           ·   You have no CONTINUE policies or rules.
406
407       CONFIG_PATH=[[:]directory[:directory]...]
408           Specifies where configuration files other than shorewall[6].conf
409           may be found. CONFIG_PATH is specifies as a list of directory names
410           separated by colons (":"). When looking for a configuration file:
411
412           ·   If the command is "try" or a "<configuration directory>" was
413               specified in the command (e.g., shorewall [-6] check ./gateway)
414               then the directory given in the command is searched first.
415
416           ·   Next, each directory in the CONFIG_PATH setting is searched in
417               sequence.
418
419           If CONFIG_PATH is not given or if it is set to the empty value then
420           the contents of /usr/share/shorewall/configpath are used. As
421           released from shorewall.net, that file sets the CONFIG_PATH to
422           /etc/shorewall:/usr/share/shorewall but your particular
423           distribution may set it differently. See the output of shorewall
424           show config for the default on your system.
425
426           Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin
427           with a colon (":"), to signal that the first directory listed will
428           be skipped if the user performing a compilation is not root or if
429           the configuration is being compiled for export (-e option specified
430           or if running one of the remote-* commands) . This prevents the
431           compiler from looking in /etc/shorewall[6]/ when compilation is
432           being done by a non-root user or if the generated script is to be
433           sent to a remote firewall system.
434
435       DEFER_DNS_RESOLUTION=[Yes|No]
436           Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS
437           names are validated in the compiler and then passed on to the
438           generated script where they are resolved by ip[6]tables-restore.
439           This is an advantage if you use AUTOMAKE=Yes and the IP address
440           associated with the DNS name is subject to change. When
441           DEFER_DNS_RESOLUTION=No, DNS names are converted into IP addresses
442           by the compiler. This has the advantage that when AUTOMAKE=Yes, the
443           start, reload and restart commands will succeed even if no DNS
444           server is reachable (assuming that the configuration hasn't changed
445           since the compiled script was last generated).
446
447               Important
448               When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change
449               makes it necessary to recompile an existing firewall script,
450               the -c option must be used with the reload or restart command
451               to force recompilation.
452
453       DELETE_THEN_ADD={Yes|No}
454           If set to Yes (the default value), entries in the
455           /etc/shorewall[6]/rtrules files cause an 'ip rule del' command to
456           be generated in addition to an 'ip rule add' command. Setting this
457           option to No, causes the 'ip rule del' command to be omitted.
458
459       DETECT_DNAT_IPADDRS=[Yes|No]
460           IPv4 only.
461
462           If set to Yes or yes, Shorewall will detect the first IP address of
463           the interface to the source zone and will include this address in
464           DNAT rules as the original destination IP address. If set to No or
465           no, Shorewall will not detect this address and any destination IP
466           address will match the DNAT rule. If not specified or empty,
467           “DETECT_DNAT_IPADDRS=Yes” is assumed.
468
469       DISABLE_IPV6=[Yes|No]
470           IPv4 only.
471
472           If set to Yes or yes, IPv6 traffic to, from and through the
473           firewall system is disabled. If set to No or no, Shorewall will
474           take no action with respect to allowing or disallowing IPv6
475           traffic. If not specified or empty, “DISABLE_IPV6=No” is assumed.
476
477           It is important to note that changing DISABLE_IPV6=Yes to
478           DISABLE_IPV6=No does not enable IPV6. The recommended approach for
479           enabling IPv6 on your system is:
480
481           ·   Install, configure and start Shorewall6[13].
482
483           ·   Change DISABLE_IPV6=Yes to DISABLE_IPV6=No in
484               /etc/shorewall/shorewall.conf.
485
486           ·   Reload Shorewall
487
488       DOCKER=[Yes|No]
489           Added in Shorewall 5.0.6; IPv4 only. When set to Yes, the generated
490           script will save Docker-generated rules before and restore them
491           after executing the start, stop, reload and restart commands. If
492           set to No (the default), the generated script will delete any
493           Docker-generated rules when executing those commands.
494           Seehttps://shorewall.org/Docker.html[14] for additional
495           information.
496
497       DOCKER_BRIDGE=[bridgename]
498           Added in Shorewall 5.2.4; IPv4 only. Specifies the name of the
499           default Docker bridge. If not specified, the value 'docker0' is
500           assumed.
501
502       DONT_LOAD=[module[,module]...]
503           Causes Shorewall to not load the listed kernel modules.
504
505       DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:log_tag]]]}
506           Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
507           blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l]
508           reject, shorewall logdrop and shorewall [-6] [-l] logreject is
509           disabled. Default is Yes. Beginning with Shorewall 5.0.8,
510           ipset-based dynamic blacklisting using the shorewall blacklist
511           command is also supported. The name of the set (setname) and the
512           level (log_level), if any, at which blacklisted traffic is to be
513           logged may also be specified. The default IPv4 set name is SW_DBL4
514           and the default IPv6 set name is SW_DBL6. The default log level is
515           none (no logging). If ipset-only is given, then chain-based dynamic
516           blacklisting is disabled just as if DYNAMIC_BLACKLISTING=No had
517           been specified.
518
519           Possible options are:
520
521           src-dst
522               Normally, only packets whose source address matches an entry in
523               the ipset are dropped. If src-dst is included, then packets
524               whose destination address matches an entry in the ipset are
525               also dropped.
526
527           disconnect
528               The disconnect option was added in Shorewall 5.0.13 and
529               requires that the conntrack utility be installed on the
530               firewall system. When an address is blacklisted using the
531               blacklist command, all connections originating from that
532               address are disconnected. if the src-dst option was also
533               specified, then all connections to that address are also
534               disconnected.
535
536           timeout=seconds
537               Added in Shorewall 5.0.13. Normally, Shorewall creates the
538               dynamic blacklisting ipset with timeout 0 which means that
539               entries are permanent. If you want entries in the set that are
540               not accessed for a period of time to be deleted from the set,
541               you may specify that period using this option. Note that the
542               blacklist command can override the ipset's timeout setting.
543
544                   Important
545                   Once the dynamic blacklisting ipset has been created,
546                   changing this option setting requires a complete restart of
547                   the firewall; shorewall [-6] restart if RESTART=restart,
548                   otherwise shorewall [-6] [-l] stop && shorewall [-6] [-l]
549                   start
550
551           log
552               Added in Shorewall 5.2.5. When specified, successful
553               'blacklist' and 'allow' commands will log a message to the
554               system log.
555
556           noupdate
557               Added in Shorewall 5.2.5. Normally, once an address has been
558               blacklisted, each time that a packet is received from the
559               packet, the ipset's entry for the address is updated to reset
560               the timeout to the value specifyed in the timeout option above.
561               Setting the noupdate option, inhibits this resetting of the
562               entry's timeout. This option is ignored when the timeout option
563               is not specified.
564
565           When ipset-based dynamic blacklisting is enabled, the contents of
566           the blacklist will be preserved over stop/reboot/start sequences.
567
568       EXPAND_POLICIES={Yes|No}
569           Normally, when the SOURCE or DEST columns in shorewall-policy(5)
570           contains 'all', a single policy chain is created and thes policy is
571           enforced in that chain. For example, if the policy entry is
572
573               #SOURCE DEST POLICY LOG
574               #                   LEVEL
575               net     all  DROP   info
576
577           then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is
578           also the chain named in Shorewall log messages generated as a
579           result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will
580           create a separate chain for each pair of zones covered by the
581           policy. This makes the resulting log messages easier to interpret
582           since the chain in the messages will have a name of the form 'a2b'
583           where 'a' is the SOURCE zone and 'b' is the DEST zone.
584
585       EXPORTMODULES=[Yes|No]
586           Added in Shorewall 4.4.17. When set to Yes when compiling for use
587           by Shorewall Lite (shorewall [-6] remote-start, shorewall [-6]
588           remote-reload, shorewall [-6] remote-restart or shorewall [-6]
589           export commands), the compiler will copy the modules or helpers
590           file from the administrative system into the script. When set to No
591           or not specified, the compiler will not copy the modules or helpers
592           file from /usr/share/shorewall[6] but will copy those found in
593           another location on the CONFIG_PATH.
594
595           When compiling for direct use by Shorewall, causes the contents of
596           the local module or helpers file to be copied into the compiled
597           script. When set to No or not set, the compiled script reads the
598           file itself.
599
600       FASTACCEPT={Yes|No}
601           Normally, Shorewall defers accepting ESTABLISHED/RELATED packets
602           until these packets reach the chain in which the original
603           connection was accepted. So for packets going from the 'loc' zone
604           to the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the
605           'loc-net' or 'loc2net' chain, depending on the setting of ZONE2ZONE
606           (see below).
607
608           If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets are
609           accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
610           FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or
611           RELATED sections of shorewall-rules[8](5).
612
613       FIREWALL=[dnsname-or-ip-address]
614           This option was added in Shorewall 5.0.13 and may be used on an
615           administrative system in directories containing the configurations
616           of remote firewalls. The contents of the variable are the default
617           value for the system parameter to the remote-start, remote-reload
618           and remote-restart commands.
619
620       FORWARD_CLEAR_MARK={Yes|No}
621           Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the
622           packet mark in the first rule in the mangle FORWARD chain. This
623           behavior is maintained with the default setting of this option
624           (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to 'No',
625           packet marks set in the mangle PREROUTING chain are retained in the
626           FORWARD chains.
627
628       GEOIPDIR=[pathname]
629           Added in Shorewall 4.5.4. Specifies the pathname of the directory
630           containing the GeoIP Match database. See
631           https://shorewall.org/ISO-3661.html[15]. If not specified, the
632           default value is /usr/share/xt_geoip/LE which is the default
633           location of the little-endian database.
634
635       HELPERS=[helper[,helper...]]
636           Added in Shorewall 4.5.7. This option specifies a comma-separated
637           list naming the Netfilter application helpers that are to be
638           enabled. If not specified, the default is to enable all helpers.
639
640           Possible values for helper are:
641
642           ·   amanda
643
644           ·   ftp
645
646           ·   h323
647
648           ·   irc
649
650           ·   netbios-ns
651
652           ·   none - This special value was added in Shorewall 4.5.16 and
653               indicates that no helpers are to be enabled. It also prevents
654               the compiler for probing for helper support; such probing
655               generates messages on the system log of the form "xt_CT: No
656               such helper XXX" where XXX is the helper name. When used, none
657               must be the only helper specified.
658
659           ·   pptp
660
661           ·   sane
662
663           ·   sip
664
665           ·   snmp
666
667           ·   tftp
668
669           When HELPERS is specified on a system running Kernel 3.5.0 or
670           later, automatic association of helpers to connections is disabled.
671
672       IGNOREUNKNOWNVARIABLES=[Yes|No]
673           Added in Shorewall 4.5.11. Normally, if an unknown shell variable
674           is encountered in a configuration file (except in ?IF and ?ELSIF
675           directives), the compiler raises a fatal error. If
676           IGNOREUNKNOWNVARIABLES is set to Yes, then such variables simply
677           expand to an empty string. Default is No.
678
679       IMPLICIT_CONTINUE={Yes|No}
680           When this option is set to Yes, it causes subzones to be treated
681           differently with respect to policies.
682
683           Subzones are defined by following their name with ":" and a list of
684           parent zones (in shorewall-zones[16](5)). Normally, you want to
685           have a set of special rules for the subzone and if a connection
686           doesn't match any of those subzone-specific rules then you want the
687           parent zone rules and policies to be applied; see
688           shorewall-nesting[17](5). With IMPLICIT_CONTINUE=Yes, that happens
689           automatically.
690
691           If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
692           subzones are not subject to this special treatment. With
693           IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be
694           overridden by including an explicit policy (one that does not
695           specify "all" in either the SOURCE or the DEST columns).
696
697       INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
698           Added in Shorewall 4.5.13. Shorewall has traditionally passed
699           INVALID packets through the NEW section of shorewall-rules[8] (5).
700           When a packet in INVALID state fails to match any rule in the
701           INVALID section, the packet is disposed of based on this setting.
702           The default value is CONTINUE for compatibility with earlier
703           versions.
704
705       INVALID_LOG_LEVEL=log-level[:log-tag]
706           Added in Shorewall 4.5.13. Packets in the INVALID state that do not
707           match any rule in the INVALID section of shorewall-rules[8] (5) are
708           logged at this level. The default value is empty which means no
709           logging is performed.
710
711       IP=[pathname]
712           If specified, gives the pathname of the 'ip' executable. If not
713           specified, 'ip' is assumed and the utility will be located using
714           the current PATH setting.
715
716       IP_FORWARDING=[On|Off|Keep]
717           This IPv4 parameter determines whether Shorewall enables or
718           disables IPv4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In
719           an IPv6 configuration, this parameter determines the setting of
720           /proc/sys/net/ipv6/config/all/ip_forwarding.
721
722           Possible values are:
723
724           On or on
725               packet forwarding will be enabled.
726
727           Off or off
728               packet forwarding will be disabled.
729
730           Keep or keep
731               Shorewall will neither enable nor disable packet forwarding.
732
733           If this variable is not set or is given an empty value
734           (IP_FORWARD="") then IP_FORWARD=On is assumed.
735
736       IPSET=[pathname]
737           If specified, gives the pathname of the 'ipset' executable. If not
738           specified, 'ipset' is assumed and the utility will be located using
739           the current PATH setting.
740
741       IPSET_WARNINGS={Yes|No}
742           Added in Shorewall 4.5.2. Default is Yes. When set, causes the
743           rules compiler to issue a warning when:
744
745           ·   The compiler is being run by root and an ipset specified in the
746               configuration does not exists. Only one warning is issued for
747               each missing ipset.
748
749           ·   When [src] is specified in a destination column and when [dst]
750               is specified in a source column.
751
752       IPTABLES=[pathname]
753           IPv4 only.
754
755           This parameter names the iptables executable to be used by
756           Shorewall. If not specified or if specified as a null value, then
757           the iptables executable located using the PATH option is used.
758
759           Regardless of how the iptables utility is located (specified via
760           IPTABLES= or located via PATH), Shorewall uses the iptables-restore
761           and iptables-save utilities from that same directory.
762
763       IP6TABLES=[pathname]
764           IPv6 only.
765
766           This parameter names the ip6tables executable to be used by
767           Shorewall6. If not specified or if specified as a null value, then
768           the ip6tables executable located using the PATH option is used.
769
770           Regardless of how the ip6tables utility is located (specified via
771           IP6TABLES= or located via PATH), Shorewall6 uses the
772           ip6tables-restore and ip6tables-save utilities from that same
773           directory.
774
775       KEEP_RT_TABLES={Yes|No}
776           IPv4: When set to Yes, this option prevents generated scripts from
777           altering the /etc/iproute2/rt_tables database when there are
778           entries in /etc/shorewall/providers. If you set this option to Yes
779           while Shorewall (Shorewall-lite) is running, you should remove the
780           file /var/lib/shorewall/rt_tables
781           (/var/lib/shorewall-lite/rt_tables) before your next stop, restore,
782           reload or restart command.  IPv6: When set to Yes, this option
783           prevents scripts generated by Shorewall6 from altering the
784           /etc/iproute2/rt_tables database when there are entries in
785           /etc/shorewall6/providers. If you set this option to Yes while
786           Shorewall6 (Shorewall6-lite) is running, you should remove the file
787           /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
788           before your next stop, restore, reload or restart command.
789
790               Important
791               When both IPv4 and IPv6 Shorewall configurations are present,
792               KEEP_RT_TABLES=No should be specified in only one of the two
793               configurations unless the two provider configurations are
794               identical with respect to interface and provider names and
795               numbers.
796           The default is KEEP_RT_TABLES=No.
797
798       LOAD_HELPERS_ONLY={Yes|No}
799           Added in Shorewall 4.4.7. When set to Yes, restricts the set of
800           modules loaded by shorewall to those listed in
801           /var/lib/shorewall[6]/helpers and those that are actually used.
802           When not set, or set to the empty value, LOAD_HELPERS_ONLY=No is
803           assumed in Shorewall versions 5.2.2 and earlier. Beginning with
804           Shorewall 5.2.3, the LOAD_HELPERS_ONLY option is removed, and the
805           behavior is as if LOAD_HELPERS_ONLY=Yes had been specified.
806
807       LOCKFILE=[pathname]
808           Specifies the name of the Shorewall[6] lock file, used to prevent
809           simultaneous state-changing commands. If not specified,
810           ${VARDIR}/shorewall[6]/lock is assumed (${VARDIR} is normally
811           /var/lib but can be changed when Shorewall-core is installed -- see
812           the output of shorewall show vardir).
813
814       LOG_BACKEND=[backend]
815           Added in Shorewall 4.6.4. LOG_BACKEND determines the logging
816           backend to be used for the iptrace command (see shorewall(8)[18]).
817
818           backend is one of:
819
820           LOG
821               Use standard kernel logging.
822
823           ULOG
824               IPv4 only.
825
826               Use ULOG logging to ulogd.
827
828           netlink
829               Use netlink logging to ulogd version 2 or later.
830
831       LOG_ZONE=[src|dst|both]
832           Added in Shorewall 5.2.0. When a log message is issued from a chain
833           that relates to a pair of zones (e.g, 'fw-net'), the chain name
834           normally appears in the log message (unless LOGTAGONLY=Yes and a
835           log tag is specified). This can prevent OPTIMIZE category 8 from
836           combining chains which are identical except for the names of the
837           zones involved. LOG_ZONE allows for only the source or destination
838           zone to appear in the messages by setting LOG_ZONE to src or dest
839           respectively. If LOG_ZONE=both (the default), then the full chain
840           name is included in log messages.
841
842       LOG_LEVEL=log-level[:log-tag]
843           Added in Shorewall 5.1.2. Beginning with that release, the sample
844           configurations use this as the default log level and changing it
845           will change all packet logging done by the configuration. In any
846           configuration file (except shorewall-params(5)[19]), $LOG_LEVEL
847           will expand to this value.
848
849       LOG_MARTIANS=[Yes|No|Keep]
850           IPv4 only.
851
852           If set to Yes or yes, sets /proc/sys/net/ipv4/conf/*/log_martians
853           to 1 with the exception of /proc/sys/net/ipv4/conf/all/log_martians
854           which is set to 0. The default value is Yes which sets both of the
855           above to one. If you do not enable martian logging for all
856           interfaces, you may still enable it for individual interfaces using
857           the logmartians interface option in shorewall-interfaces[20](5).
858
859           The value Keep causes Shorewall to ignore the option. If the option
860           is set to Yes, then martians are logged on all interfaces. If the
861           option is set to No, then martian logging is disabled on all
862           interfaces except those specified in shorewall-interfaces[20](5).
863
864       LOG_VERBOSITY=[number]
865           This option controls the amount of information logged to the file
866           specified in the STARTUP_LOG option.
867
868           Values are:
869               -1 - Logging is disabled
870               0 - Silent. Only error messages are logged.
871               1 - Major progress messages logged.
872               2 - All progress messages logged
873           If not specified, then -1 is assumed.
874
875       LOGALLNEW=[log-level]
876           This option is intended for use as a debugging aid. When set to a
877           log level, this option causes Shorewall to generate a logging rule
878           as the first rule in each builtin chain.
879
880           ·   The table name is used as the chain name in the log prefix.
881
882           ·   The chain name is used as the target in the log prefix.
883
884           For example, using the default LOGFORMAT, the log prefix for
885           logging from the nat table's PREROUTING chain is as follows in
886           versions prior to 5.1.0:
887
888                   Shorewall:nat:PREROUTING
889
890
891           In Shorewall 5.1.0 and later releases, the log prefix is:
892
893                   nat:PREROUTING
894
895
896
897               Important
898               To help insure that all packets in the NEW state are logged,
899               rate limiting (LOGLIMIT) should be disabled when using
900               LOGALLNEW. Use LOGALLNEW at your own risk; it may cause high
901               CPU and disk utilization and you may not be able to control
902               your firewall after you enable this option.
903
904               Caution
905               Do not use this option if the resulting log messages will be
906               sent to another system.
907
908       LOGFILE=[pathname|systemd]
909           This parameter tells the /sbin/shorewall program where to look for
910           Shorewall messages when processing the dump, logwatch, show log,
911           and hits commands. If not assigned or if assigned an empty value,
912           /var/log/messages is assumed. For further information, see
913           shorewall-logging(8)[21]. Beginning with Shorewall 5.0.10.1, you
914           may specify systemd to use journelctl -r to read the log.
915
916       LOGFORMAT=["formattemplate"]
917           The value of this variable generate the --log-prefix setting for
918           Shorewall logging rules. It contains a “printf” formatting template
919           which accepts three arguments (the chain name, logging rule number
920           (optional) and the disposition). To use LOGFORMAT with fireparse,
921           set it as:
922
923                   LOGFORMAT="fp=%s:%d a=%s "
924
925           If the LOGFORMAT value contains the substring “%d” then the logging
926           rule number is calculated and formatted in that position; if that
927           substring is not included then the rule number is not included. If
928           not supplied or supplied as empty (LOGFORMAT="") then
929           “Shorewall:%s:%s:” is assumed.
930
931               Note
932               The setting of LOGFORMAT has an effect of the permitted length
933               of zone names. See shorewall-zones[16] (5).
934
935               Caution
936               Beginning with Shorewall 5.1.0, the default and sample
937               shorewall[6].conf files set LOGFORMAT="%s %s ".
938
939               Regardless of the LOGFORMAT setting, Shorewall IPv4 log
940               messages that use this LOGFORMAT can be uniquely identified
941               using the following regular expression:
942                   'IN=.* OUT=.* SRC=.*\..* DST='
943               and Shorewall IPv6 log messages can be uniquely identified
944               using the following regular expression:
945                   'IN=.* OUT=.* SRC=.*:.* DST='
946               To match all Netfilter log messages (Both IPv4 and IPv6 and
947               regardless of the LOGFORMAT setting), use:
948                   'IN=.* OUT=.* SRC=.* DST='
949
950       LOGLIMIT=[[{s|d}:]rate/{sec|second|min|minute|hour|day}[:burst]]
951           Added in Shorewall 4.4.12. Limits the logging rate, either overall,
952           or by source or destination IP address.
953
954           If the value starts with 's:' then logging is limited per source
955           IP. If the value starts with 'd:', then logging is limited per
956           destination IP. Otherwise, the overall logging rate is limited.
957
958           If burst is not specified, then a value of 5 is assumed.
959
960           The keywords second and minute are accepted beginning with
961           Shorewall 4.6.13.
962
963       LOGTAGONLY=[Yes|No]
964           Using LOGFORMAT=“Shorewall:%s:%s:”, chain names may not exceed 5
965           characters or truncation of the log prefix may occur. Longer chain
966           names may be used with log tags if you set LOGTAGONLY=Yes. With
967           LOGTAGONLY=Yes, if a log tag is specified then the tag is included
968           in the log prefix in place of the chain name.
969
970           Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more
971           control over the generated log prefix. Beginning with that release,
972           the tag is interpreted as a chain name and a disposition separated
973           by a comma. So this rule:
974
975               #ACTION                                SOURCE         DEST
976               LOG:info:foo,bar                       net            fw
977
978           would generate the following log prefix when using
979           LOGFORMAT=“Shorewall:%s:%s:”:
980               Shorewall:foo:bar:
981           Similarly,
982
983               #ACTION                               SOURCE            DEST
984               LOG:info:,bar                        net                    fw
985
986           would generate
987               Shorewall:net2fw:bar:
988
989       MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
990           Determines the disposition of connections requests that fail MAC
991           Verification and must have the value ACCEPT (accept the connection
992           request anyway), REJECT (reject the connection request) or DROP
993           (ignore the connection request). If not set or if set to the empty
994           value (e.g., MACLIST_DISPOSITION="") then
995           MACLIST_DISPOSITION=REJECT is assumed.
996
997           A_DROP and A_REJECT are audited versions of DROP and REJECT
998           respectively and were added in Shorewall 4.4.20. They require
999           AUDIT_TARGET in the kernel and ip[6]tables.
1000
1001       MACLIST_LOG_LEVEL=[log-level[:log-tag]]
1002           Determines the syslog level for logging connection requests that
1003           fail MAC Verification. The value must be a valid syslogd log level.
1004           If you don't want to log these connection requests, set to the
1005           empty value (e.g., MACLIST_LOG_LEVEL="").
1006
1007       MACLIST_TABLE=[filter|mangle]
1008           Normally, MAC verification occurs in the filter table (INPUT and
1009           FORWARD) chains. When forwarding a packet from an interface with
1010           MAC verification to a bridge interface, that doesn't work.
1011
1012           This problem can be worked around by setting MACLIST_TABLE=mangle
1013           which will cause Mac verification to occur out of the PREROUTING
1014           chain. Because REJECT isn't available in that environment, you may
1015           not specify MACLIST_DISPOSITION=REJECT or
1016           MACLIST_DISPOSITION=A_REJECT with MACLIST_TABLE=mangle.
1017
1018       MACLIST_TTL=[number]
1019           The performance of configurations with a large numbers of entries
1020           in shorewall-maclist[22](5) can be improved by setting the
1021           MACLIST_TTL variable in shorewall[6].conf[23](5).
1022
1023           If your iptables and kernel support the "Recent Match" (see the
1024           output of "shorewall check" near the top), you can cache the
1025           results of a 'maclist' file lookup and thus reduce the overhead
1026           associated with MAC Verification.
1027
1028           When a new connection arrives from a 'maclist' interface, the
1029           packet passes through then list of entries for that interface in
1030           shorewall-maclist[22](5). If there is a match then the source IP
1031           address is added to the 'Recent' set for that interface. Subsequent
1032           connection attempts from that IP address occurring within
1033           $MACLIST_TTL seconds will be accepted without having to scan all of
1034           the entries. After $MACLIST_TTL from the first accepted connection
1035           request from an IP address, the next connection request from that
1036           IP address will be checked against the entire list.
1037
1038           If MACLIST_TTL is not specified or is specified as empty (e.g,
1039           MACLIST_TTL="" or is specified as zero then 'maclist' lookups will
1040           not be cached).
1041
1042       MANGLE_ENABLED=[Yes|No]
1043           Determines whether Shorewall will generate rules in the Netfilter
1044           mangle table. Setting MANGLE_ENABLED=No disables all Shorewall
1045           features that require the mangle table. The default is
1046           MANGLE_ENABLED=Yes.
1047
1048       MINIUPNPD=[Yes|No]
1049           Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a
1050           chain in the nat table named MINIUPNPD-POSTROUTING and will add
1051           jumps from POSTROUTING to that chain for each interface with the
1052           upnpd option specified. Default is No.
1053
1054       MARK_IN_FORWARD_CHAIN=[Yes|No]
1055           If your kernel has a FORWARD chain in the mangle table, you may set
1056           MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the
1057           tcrules file to occur in that chain rather than in the PREROUTING
1058           chain. This permits you to mark inbound traffic based on its
1059           destination address when DNAT is in use. To determine if your
1060           kernel has a FORWARD chain in the mangle table, use the shorewall
1061           [-6] show mangle command; if a FORWARD chain is displayed then your
1062           kernel will support this option. If this option is not specified or
1063           if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="")
1064           then MARK_IN_FORWARD_CHAIN=No is assumed.
1065
1066       MASK_BITS=[number]
1067           Added in Shorewall 4.4.26. Number of bits on the right of the
1068           32-bit packet mark to be masked when clearing the traffic shaping
1069           mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET
1070           > 0). Prior to Shorewall 5.0.0, default value and the default
1071           values of the other mark layout options is determined as follows:
1072
1073           Table 1. Default Packet Mark Layout
1074           WIDE_TC_MARKS=No,      TC_BITS=8,
1075           HIGH_ROUTE_MARKS=No    PROVIDER_BITS=8,
1076                                  PROVIDER_OFFSET=0,
1077                                                    MASK_BITS=8
1078           WIDE_TC_MARKS=No,      TC_BITS=8, PROVIDER_BITS=8,
1079           HIGH_ROUTE_MARKS=Yes   PROVIDER_OFFSET=8,
1080                                                    MASK_BITS=8
1081           WIDE_TC_MARKS=Yes,     TC_BITS=14, PROVIDER_BITS=8,
1082           HIGH_ROUTE_MARKS=No    PROVIDER_OFFSET=0,
1083                                                    MASK_BITS=16
1084           WIDE_TC_MARKS=Yes,     TC_BITS=14, PROVIDER_BITS=8,
1085           HIGH_ROUTE_MARKS=Yes   PROVIDER_OFFSET=16,
1086                                                    MASK_BITS=16
1087
1088           From 5.0.0 onward, the default value of MASK_BITS is 8, the default
1089           value of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is
1090           8.
1091
1092       MODULESDIR=[[+]pathname[:pathname]...]
1093           This parameter specifies the directory/directories where your
1094           kernel netfilter modules may be found. If you leave the variable
1095           empty, Shorewall will supply the value
1096           "/lib/modules/$uname/kernel/net/ipv${g_family}/netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
1097           where uname holds the output of 'uname -r' and g_family holds '4'
1098           in IPv4 configurations and '6' in IPv6 configurations.
1099
1100           The option plus sign ('+') was added in Shorewall 5.0.3 and causes
1101           the listed pathnames to be appended to the default list above.
1102
1103       MULTICAST=[Yes|No]
1104           IPv4 only.
1105
1106           This option will normally be set to 'No' (the default). It should
1107           be set to 'Yes' under the following circumstances:
1108
1109            1. You have an interface that has parallel zones defined via
1110               /etc/shorewall/hosts.
1111
1112            2. You want to forward multicast packets to two or more of those
1113               parallel zones.
1114
1115           In such cases, you will configure a destonly network on each zone
1116           receiving multicasts.
1117
1118       MUTEX_TIMEOUT=[seconds]
1119           The value of this variable determines the number of seconds that
1120           programs will wait for exclusive access to the Shorewall[6] lock
1121           file. After the number of seconds corresponding to the value of
1122           this variable, programs will assume that the last program to hold
1123           the lock died without releasing the lock.
1124
1125           If not set or set to the empty value, a value of 60 (60 seconds) is
1126           assumed.
1127
1128           An appropriate value for this parameter would be twice the length
1129           of time that it takes your firewall system to process a shorewall
1130           [-6] restart command.
1131
1132       NFACCT=[pathname]
1133           Added in Shorewall 4.5.7. Specifies the pathname of the nfacct
1134           utility. If not specified, Shorewall will use the PATH setting to
1135           find the program.
1136
1137       NULL_ROUTE_RFC1918=[Yes|No|blackhole|unreachable|prohibit]
1138           IPv4 only.
1139
1140           When set to Yes, causes Shorewall to null-route the IPv4 address
1141           ranges reserved by RFC1918. The default value is 'No'.
1142
1143           When combined with route filtering (ROUTE_FILTER=Yes or routefilter
1144           in shorewall-interfaces[20](5)), this option ensures that packets
1145           with an RFC1918 source address are only accepted from interfaces
1146           having known routes to networks using such addresses.
1147
1148           Beginning with Shorewall 4.5.15, you may specify blackhole,
1149           unreachable or prohibit to set the type of route to be created. See
1150           https://shorewall.org/MultiISP.html#null_routing[24].
1151
1152       OPTIMIZE=[value]
1153           The specified value enables certain optimizations. Each
1154           optimization category is associated with a power of two. To enable
1155           multiple optimization categories, simply add their corresponding
1156           numbers together.
1157
1158           Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to
1159           enable all optimization categories, and you may also specify
1160           OPTIMIZE=None to disable optimization.
1161
1162           ·   Optimization category 1 - Traditionally, Shorewall has created
1163               rules for the complete matrix of host groups defined by the
1164               zones, interfaces and hosts files. Any traffic that didn't
1165               correspond to an element of that matrix was rejected in one of
1166               the built-in chains. When the matrix is sparse, this results in
1167               lots of largely useless rules.
1168
1169               These extra rules can be eliminated by setting the 1 bit in
1170               OPTIMIZE.
1171
1172               The 1 bit setting also controls the suppression of redundant
1173               wildcard rules (those specifying "all" in the SOURCE or DEST
1174               column). A wildcard rule is considered to be redundant when it
1175               has the same ACTION and Log Level as the applicable policy.
1176
1177                   Note
1178                   Optimization level 1 is ignored when optimization level 4
1179                   is also selected, since level 4 performs similar
1180                   optimizations in a more robust way.
1181
1182           ·   Optimization category 2 - Added in Shorewall 4.4.7. When set,
1183               suppresses superfluous ACCEPT rules in a policy chain that
1184               implements an ACCEPT policy. Any ACCEPT rules that immediately
1185               precede the final blanket ACCEPT rule in the chain are now
1186               omitted.
1187
1188           ·   Optimization category 4 - Added in Shorewall 4.4.7. When set,
1189               causes short chains (those with less than 2 rules) to be
1190               optimized away. The following chains are excluded from
1191               optimization:
1192
1193               ·   accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
1194
1195               ·   action chains (user-defined)
1196
1197               ·   'blacklst' chain
1198
1199               ·   dynamic
1200
1201               ·   forwardUPnP
1202
1203               ·   UPnP (nat table)
1204
1205               Additionally:
1206
1207               ·   If a built-in chain has a single rule that branches to a
1208                   second chain, then the rules from the second chain are
1209                   moved to the built-in chain and the target chain is
1210                   omitted.
1211
1212               ·   Chains with no references are deleted.
1213
1214               ·   Accounting chains are subject to optimization if the
1215                   OPTIMIZE_ACCOUNTING option is set to 'Yes'.
1216
1217               ·   If a chain ends with an unconditional branch to a second
1218                   chain (other than to 'reject'), then the branch is deleted
1219                   from the first chain and the rules from the second chain
1220                   are appended to it.
1221
1222               An additional optimization was added in Shorewall 4.5.4. If the
1223               last rule in a chain is an unqualified jump to a simple target,
1224               then all immediately preceding rules with the same simple
1225               target are omitted.
1226
1227               For example, consider this chain:
1228
1229                        -A fw-net -p udp --dport 67:68 -j ACCEPT
1230                        -A fw-net -p udp --sport 1194 -j ACCEPT
1231                        -A fw-net -p 41 -j ACCEPT
1232                        -A fw-net -j ACCEPT
1233
1234               Since all of the rules are jumps to the simple target ACCEPT,
1235               this chain is totally optimized away and jumps to the chain are
1236               replace with jumps to ACCEPT.
1237
1238           ·   Optimization category 8 - Added in Shorewall 4.4.9. When set,
1239               causes chains with identical rules to be collapsed into a
1240               single chain.
1241
1242                   Warning
1243                   While Optimization category 8 can significantly reduce the
1244                   size of the generated iptables ruleset, it can also take
1245                   significant system resources during compilation. If you
1246                   find that compilation takes an unreasonably long time, try
1247                   disabling this category by setting OPTIMIZE=23.
1248
1249           ·   Optimization category 16 - Added in Shorewall 4.4.26. When set,
1250               causes sequences of compatible rules to be combined into a
1251               single rule. Rules are considered compatible if they differ
1252               only in their destination ports and comments.
1253
1254               A sequence of compatible rules is often generated when macros
1255               are invoked in sequence.
1256
1257               The ability to combine adjacent rules is limited by two
1258               factors:
1259
1260               ·   Destination port lists may only be combined up to a maximum
1261                   of 15 ports, where a port-pair counts as two ports.
1262
1263               ·   Rules may only be combined until the length of their
1264                   concatenated comment reaches 255 characters.
1265
1266               When either of these limits would be exceeded, the current
1267               combined rule is emitted and the compiler attempts to combine
1268               rules beginning with the one that would have exceeded the
1269               limit. Adjacent combined comments are separated by ', '. Empty
1270               comments at the front of a group of combined comments are
1271               replaced by 'Others and'. Empty comments at the end of a group
1272               of combined comments are replaced by 'and others'.
1273
1274               Beginning in Shorewall 4.5.10, this option also suppresses
1275               duplicate adjacent rules and duplicate non-adjacent rules that
1276               don't include mark, connmark, dscp, ecn, set, tos or u32
1277               matches.
1278
1279               Example 1:
1280                   Rules with comments "FOO", <empty> and "BAR" would result
1281                   in the combined comment "FOO and others, BAR".
1282
1283               Example 2:
1284                   Rules with comments <empty>, "FOO" and "BAR" would result
1285                   in the combined comment "Others and FOO, BAR". Note:
1286                   Optimize level 16 requires "Extended Multi-port Match" in
1287                   your iptables and kernel.
1288
1289           In versions prior to 5.1.0, the default value is zero which
1290           disables all optimizations. Beginning with Shorewall 5.1.0, the
1291           default value is All which enables all optimizations.
1292
1293       OPTIMIZE_ACCOUNTING=[Yes|No]
1294           Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
1295           changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not
1296           specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is
1297           assumed.
1298
1299       PAGER=pathname
1300           Added in Shorewall 5.0.6. Specifies a path name of a pager program
1301           like less or more. When PAGER is given, the output of verbose
1302           status commands and the dump command are piped through the named
1303           program when the output file is a terminal.
1304
1305           Beginning with Shorewall 5.0.12, the default value of this option
1306           is the DEFAULT_PAGER setting in shorewallrc.
1307
1308       PATH=pathname[:pathname]...
1309           Determines the order in which Shorewall searches directories for
1310           executable files.
1311
1312       PERL=pathname
1313           Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
1314           executable. Default is /usr/bin/perl. If the pathname specified by
1315           this option does not exist or the named file is not executable,
1316           then Shorewall falls back to /usr/bin/perl
1317
1318       PERL_HASH_SEED=seed|random
1319           Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in
1320           the range 0-99999) when running the Shorewall rules compiler. If
1321           not specified, the value 0 is assumed. If random is specified, a
1322           random seed will be chosed by Perl. See perlsec(1) for additional
1323           information.
1324
1325       PROVIDER_BITS=[number]
1326           Added in Shorewall 4.4.26. The number of bits in the 32-bit packet
1327           mark to be used for provider numbers. May be zero. See MASK_BITS
1328           above for default value.
1329
1330       PROVIDER_OFFSET=[number]If
1331           Added in Shorewall 4.4.26. The offset from the right (low-order
1332           end) of the provider number field in the 32-bit packet mark. If
1333           non-zero, must be >= TC_BITS (Shorewall automatically adjusts
1334           PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS +
1335           ZONE_BITS must be < 32. See MASK_BITS above for default value.
1336
1337       RCP_COMMAND="command"
1338
1339       RSH_COMMAND="command"
1340           Earlier generations of Shorewall Lite required that remote root
1341           login via ssh be enabled in order to use the load and reload
1342           commands. Beginning with release 3.9.5, you may define an
1343           alternative means for accessing the remote firewall system. In that
1344           release, two new options were added to shorewall.conf:
1345               RSH_COMMAND
1346               RCP_COMMAND
1347           The default values for these are as follows:
1348
1349               RSH_COMMAND: ssh ${root}@${system} ${command}
1350               RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
1351
1352           Shell variables that will be set when the commands are invoked are
1353           as follows:
1354
1355               root        - root user. Normally root but may be overridden using the '-r' option.
1356               system      - The name/IP address of the remote firewall system.
1357               command     - For RSH_COMMAND, the command to be executed on the firewall system.
1358               files       - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
1359               destination - The directory on the remote system that the files are to be copied into.
1360
1361       RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
1362           Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed
1363           RELATED packets that don't match any rule in the RELATED section of
1364           shorewall-rules[8] (5). Concern about the safety of this practice
1365           resulted in the addition of this option. When a packet in RELATED
1366           state fails to match any rule in the RELATED section, the packet is
1367           disposed of based on this setting. The default value is ACCEPT for
1368           compatibility with earlier versions.
1369
1370       RELATED_LOG_LEVEL=log-level[:log-tag]
1371           Added in Shorewall 4.4.27. Packets in the related state that do not
1372           match any rule in the RELATED section of shorewall-rules[8] (5) are
1373           logged at this level. The default value is empty which means no
1374           logging is performed.
1375
1376       REJECT_ACTION=action
1377           Added in Shorewall 4.5.21. When a REJECT target is specified,
1378           Shorewall normally handles the response as follows:
1379
1380           ·   If the destination address of the packet is a broadcast or
1381               multicast address, the packet is dropped.
1382
1383           ·   if the protocol is ICMP (2) then the packet is dropped.
1384
1385           ·   if the protocol is TCP (6) then the packet is rejected with an
1386               RST.
1387
1388           ·   if the protocol is UDP (17) then the packet is rejected with an
1389               'port-unreachable' ICMP.
1390
1391           ·   if the protocol is ICMP (1) then the packet is rejected with a
1392               'host-unreachable' ICMP.
1393
1394           ·   if the protocol is ICMP6 (1) then the packet is rejected with a
1395               'icmp6-addr-unreachable' ICMP6.
1396
1397           ·   otherwise, the packet is rejected with a 'host-prohibited'
1398               ICMP.
1399
1400           You can modify this behavior by implementing your own action that
1401           handles REJECT and specifying it's name in this option. The nolog
1402           and noinline options will automatically be assumed for the
1403           specified action.
1404
1405           The following action implements the default reject action:
1406
1407               ?format 2
1408               #TARGET         SOURCE  DEST    PROTO
1409               Broadcast(DROP) -       -       -
1410               DROP            -       -       2
1411               INLINE          -       -       6       ;; -j REJECT --reject-with tcp-reset
1412               ?if __ENHANCED_REJECT
1413               INLINE          -       -       17      ;; -j REJECT
1414               ?if __IPV4
1415               INLINE          -       -       1       ;; -j REJECT --reject-with icmp-host-unreachable
1416               INLINE          -       -       -       ;; -j REJECT --reject-with icmp-host-prohibited
1417               ?else
1418               INLINE          -       -       58      ;; -j REJECT --reject-with icmp6-addr-unreachable
1419               INLINE          -       -       -       ;; -j REJECT --reject-with icmp6-adm-prohibited
1420               ?endif
1421               ?else
1422               INLINE          -       -       -       ;; -j REJECT
1423               ?endif
1424
1425       RENAME_COMBINED=[Yes|No]
1426           Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8
1427           is enabled, identical chains are combined under a name beginning
1428           with '~comb' or '~blacklist'. This behavior is maintained under the
1429           default setting RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the
1430           chains are combined under the original name of one of the chains.
1431
1432       REQUIRE_INTERFACE=[Yes|No]
1433           Added in Shorewall 4.4.10. The default is No. If set to Yes, at
1434           least one optional interface must be up in order for the firewall
1435           to be in the started state. Intended to be used with the Shorewall
1436           Init Package[25].
1437
1438       RESTART=[restart|reload]
1439           Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added
1440           in Shorewall 5.0.0. In that release, the reload command was
1441           redefined to do what restart had done in earlier releases and
1442           restart became a true restart (equivalent to stop followed by
1443           start). When RESTART=reload, the restart command performs the same
1444           operation as the reload command making it compatible with earlier
1445           releases. If not specified, RESTART=reload is assumed.
1446
1447       RESTORE_DEFAULT_ROUTE=[Yes|No]
1448           This option determines whether to restore the default route saved
1449           when here are 'balance' providers defined but all of them are down.
1450
1451           The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
1452           pre-4.2.6 behavior.
1453
1454           RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
1455           default route in the main table (USE_DEFAULT_RT=No) or in the
1456           default table (USE_DEFAULT_RT=Yes) when there are no balance
1457           providers available. In that case, RESTORE_DEFAULT_ROUTE=No will
1458           cause any default route in the relevant table to be deleted.
1459
1460       RESTORE_ROUTEMARKS=[Yes|No]
1461           Added in Shorewall 4.5.9. When set to Yes (the default), provider
1462           marks are restored unconditionally at the top of the mangle OUTPUT
1463           and PREROUTING chains, even if the saved mark is zero. When this
1464           option is set to No, the mark is restored only if it is non-zero.
1465           If you have problems with IPSEC ESP packets not being routed
1466           correctly on output, try setting this option to No.
1467
1468       RESTOREFILE=filename
1469           Specifies the simple name of a file in /var/lib/shorewall to be
1470           used as the default restore script in the shorewall [-6] save,
1471           shorewall [-6] restore, shorewall [-6] forget and shorewall [6] -f
1472           start commands.
1473
1474       RETAIN_ALIASES={Yes|No}
1475           IPv4 only.
1476
1477           During shorewall start, IP addresses to be added as a consequence
1478           of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted
1479           when shorewall-nat[3](5) and shorewall-masq[4](5) are processed
1480           then are re-added later. This is done to help ensure that the
1481           addresses can be added with the specified labels but can have the
1482           undesirable side effect of causing routes to be quietly deleted.
1483           When RETAIN_ALIASES is set to Yes, existing addresses will not be
1484           deleted. Regardless of the setting of RETAIN_ALIASES, addresses
1485           added during shorewall start are still deleted at a subsequent
1486           shorewall [stop, shorewall reload or shorewall restart.
1487
1488       ROUTE_FILTER=[Yes|No|Keep]
1489           If this parameter is given the value Yes or yes then route
1490           filtering (anti-spoofing) is enabled on all network interfaces
1491           which are brought up while Shorewall is in the started state. The
1492           default value is no.
1493
1494           The value Keep causes Shorewall to ignore the option. If the option
1495           is set to Yes, then route filtering occurs on all interfaces. If
1496           the option is set to No, then route filtering is disabled on all
1497           interfaces except those specified in shorewall-interfaces[20](5).
1498
1499               Important
1500               If you need to disable route filtering on any interface, then
1501               you must set ROUTE_FILTER=No then set routefilter=1 or
1502               routefilter=2 on those interfaces where you want route
1503               filtering. See shorewall-interfaces[20](5) for additional
1504               details.
1505
1506       RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
1507           Added in Shorewall 4.5.7. Determines the disposition of packets
1508           entering from interfaces the rpfilter option (see
1509           shorewall-interfaces[20](5)). Packets disposed of by this option
1510           are those whose response packets would not be sent through the same
1511           interface receiving the packet.
1512
1513       RPFILTER_LOG_LEVEL=log-level[:log-tag]
1514           Added in shorewall 4.5.7. Determines the logging of packets
1515           disposed via the RPFILTER_DISPOSITION. The default value is info.
1516
1517       SAVE_ARPTABLES={Yes|No}
1518           Added in Shorewall 4.5.12. If SAVE_ARPTABLES=Yes, then the current
1519           arptables contents will be saved by shorewall save command and
1520           restored by shorewall restore command. Default value is No.
1521
1522       SAVE_IPSETS={Yes|No|ipv4|setlist}
1523           Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
1524           contents of your ipsets will be saved by the shorewall stop and
1525           shorewall save commands and restored by the shorewall start and
1526           shorewall restore commands.
1527
1528           Beginning with Shorewall 4.6.4, you can restrict the set of ipsets
1529           saved by specifying a setlist (a comma-separated list of ipv4 ipset
1530           names). You may also restrict the saved sets to just the ipv4 ones
1531           by specifying ipv4.
1532
1533       SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
1534           Added in Shorewall 4.4.20. Determines the disposition of packets
1535           matching the sfilter option (see shorewall-interfaces[20](5)) and
1536           of hairpin packets on interfaces without the routeback option.[26]
1537
1538       SFILTER_LOG_LEVEL=log-level[:log-tag]
1539           Added on Shorewall 4.4.20. Determines the logging of packets
1540           matching the sfilter option (see shorewall-interfaces[20](5)) and
1541           of hairpin packets on interfaces without the routeback option.[27]
1542           The default is info. If you don't wish for these packets to be
1543           logged, use SFILTER_LOG_LEVEL=none.
1544
1545       SHOREWALL_SHELL=[pathname]
1546           This option is used to specify the shell program to be used to
1547           interpret the compiled script. If not specified or specified as a
1548           null value, /bin/sh is assumed. Using a light-weight shell such as
1549           ash or dash can significantly improve performance.
1550
1551       SMURF_DISPOSITION=[DROP|A_DROP]
1552           Added in Shorewall 4.4.20. The default setting is DROP which causes
1553           smurf packets (see the nosmurfs option in
1554           shorewall-interfaces[20](5)) to be dropped. A_DROP causes the
1555           packets to be audited prior to being dropped and requires
1556           AUDIT_TARGET support in the kernel and iptables.
1557
1558       SMURF_LOG_LEVEL=[log-level[:log-tag]]
1559           Specifies the logging level for smurf packets (see the nosmurfs
1560           option in shorewall-interfaces[20](5)). If set to the empty value (
1561           SMURF_LOG_LEVEL="" ) then smurfs are not logged.
1562
1563       STARTUP_ENABLED={Yes|No}
1564           Determines if Shorewall is allowed to start. As released from
1565           shorewall.net, this option is set to No. When set to Yes or yes,
1566           Shorewall may be started. Used as a guard against Shorewall being
1567           accidentally started before it has been configured.
1568
1569       STARTUP_LOG=[pathname]
1570           If specified, determines where Shorewall will log the details of
1571           each start, reload, restart, try, and safe-* command. Logging
1572           verbosity is determined by the setting of LOG_VERBOSITY above.
1573
1574       SUBSYSLOCK=[pathname]
1575           This parameter should be set to the name of a file that the
1576           firewall should create if it starts successfully and remove when it
1577           stops. Creating and removing this file allows Shorewall to work
1578           with your distribution's initscripts. For OpenSuSE, this should be
1579           set to /var/lock/subsys/shorewall (var/lock/subsys/shorewall-lite
1580           if building for export). For Gentoo, it should be set to
1581           /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat and
1582           derivatives as well as Debian and derivatives, the pathname should
1583           be omitted.
1584
1585               Important
1586               Beginning with Shorewall 5.1.0, this setting is ignored when
1587               SERVICEDIR is non-empty in ${SHAREDIR}/shorewall/shorewallrc
1588               (usually /usr/share/shorewall/shorewallrc).
1589
1590       TC=[pathname]
1591           If specified, gives the pathname of the 'tc' executable. If not
1592           specified, 'tc' is assumed and the utility will be located using
1593           the current PATH setting.
1594
1595       TC_BITS=[number]
1596           The number of bits at the low end of the 32-bit packet mark to be
1597           used for traffic shaping marking. May be zero. See MASK_BITS above
1598           for default value.
1599
1600       TC_ENABLED=[Yes|No|Internal|Simple|Shared]
1601           If you say Yes or yes here, Shorewall will use a script that you
1602           supply to configure traffic shaping. The script must be named
1603           'tcstart' and must be placed in a directory on your CONFIG_PATH.
1604
1605           If you say No or no then traffic shaping is not enabled.
1606
1607           If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple
1608           traffic shaping using shorewall-tcinterfaces[28](5) and
1609           shorewall-tcpri[29](5) is enabled.
1610
1611           If you set TC_ENABLED=Internal or internal or leave the option
1612           empty then Shorewall will use its builtin traffic shaper
1613           (tc4shorewall written by Arne Bernin.
1614
1615           Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared.
1616           This allows you to configure the tcdevices and tcclasses in your
1617           Shorewall6 configuration yet make them available to the compiler
1618           when compiling your Shorewall configuration. In addition to setting
1619           TC_ENABLED=Shared, you need to create symbolic links from your
1620           Shorewall configuration directory (normally /etc/shorewall/) to the
1621           tcdevices and tcclasses files in your Shorewall6 configuration
1622           directory (normally /etc/shorewall6/).
1623
1624       TC_EXPERT={Yes|No}
1625           Normally, Shorewall tries to protect users from themselves by
1626           preventing PREROUTING and OUTPUT tcrules from being applied to
1627           packets that have been marked by the 'track' option in
1628           shorewall-providers[9](5).
1629
1630           If you know what you are doing, you can set TC_EXPERT=Yes and
1631           Shorewall will not include these cautionary checks.
1632
1633       TC_PRIOMAP=map
1634           Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS
1635           field to priority bands. See shorewall-tcpri[29](5). The map
1636           consists of 16 space-separated digits with values 1, 2 or 3. A
1637           value of 1 corresponds to Linux priority 0, 2 to Linux priority 1,
1638           and 3 to Linux Priority 2. The first entry gives the priority of
1639           TOS value 0, the second of TOS value 1, and so on. See tc-prio(8)
1640           for additional information.
1641
1642           The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2
1643           2".
1644
1645       TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
1646           Determines the disposition of TCP packets that fail the checks
1647           enabled by the tcpflags interface option (see
1648           shorewall-interfaces[20](5)) and must have a value of ACCEPT
1649           (accept the packet), REJECT (send an RST response) or DROP (ignore
1650           the packet). If not set or if set to the empty value (e.g.,
1651           TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is
1652           assumed.
1653
1654           A_DROP and A_REJECT are audited versions of DROP and REJECT
1655           respectively and were added in Shorewall 4.4.20. They require
1656           AUDIT_TARGET in the kernel and iptables.
1657
1658       TCP_FLAGS_LOG_LEVEL=[log-level[:log-tag]]
1659           Determines the syslog level for logging packets that fail the
1660           checks enabled by the tcpflags interface option. The value must be
1661           a valid syslogd log level. If you don't want to log these packets,
1662           set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
1663
1664       TRACK_PROVIDERS={Yes|No}
1665           Added in Shorewall 4.4.3. When set to Yes, causes the track option
1666           to be assumed on all providers defined in
1667           shorewall-providers[9](5). May be overridden on an individual
1668           provider through use of the notrack option. The default value is
1669           'No'.
1670
1671           Beginning in Shorewall 4.4.6, setting this option to 'Yes' also
1672           simplifies PREROUTING rules in shorewall-tcrules[12](5).
1673           Previously, when TC_EXPERT=No, packets arriving through 'tracked'
1674           provider interfaces were unconditionally passed to the PREROUTING
1675           tcrules. This was done so that tcrules could reset the packet mark
1676           to zero, thus allowing the packet to be routed using the 'main'
1677           routing table. Using the main table allowed dynamic routes (such as
1678           those added for VPNs) to be effective. The rtrules file was created
1679           to provide a better alternative to clearing the packet mark. As a
1680           consequence, passing these packets to PREROUTING complicates things
1681           without providing any real benefit. Beginning with Shorewall 4.4.6,
1682           when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through
1683           'tracked' interfaces will not be passed to the PREROUTING rules.
1684           Since TRACK_PROVIDERS was just introduced in 4.4.3, this change
1685           should be transparent to most, if not all, users.
1686
1687       TRACK_RULES={Yes|No|File}
1688           Added in Shorewall 4.5.20. If set to Yes, causes the compiler to
1689           add a comment to iptables rules to indicate the file name and line
1690           number of the configuration entry that generated the rule. If set
1691           to No (the default), then no such comments are added.
1692
1693           Setting this option to Yes requires the Comments capability in
1694           iptables and kernel.
1695
1696           Beginning with Shorewall 5.0.5, the option may also be set to File.
1697           That setting causes similar comments to be added to the
1698           .iptables-restore-input file, which is normally created in
1699           /var/lib/shorewall.
1700
1701       UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
1702           Added in Shorewall 4.5.13. Shorewall has traditionally passed
1703           UNTRACKED packets through the NEW section of shorewall-rules[8]
1704           (5). When a packet in UNTRACKED state fails to match any rule in
1705           the UNTRACKED section, the packet is disposed of based on this
1706           setting. The default value is CONTINUE for compatibility with
1707           earlier versions.
1708
1709       UNTRACKED_LOG_LEVEL=log-level[:log-tag]
1710           Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do
1711           not match any rule in the UNTRACKED section of shorewall-rules[8]
1712           (5) are logged at this level. The default value is empty which
1713           means no logging is performed.
1714
1715       USE_DEFAULT_RT=[Yes|No]
1716           When set to 'Yes', this option causes the Shorewall multi-ISP
1717           feature to create a set of routing rules which are resilient to
1718           changes in the main routing table. Such changes can occur for a
1719           number of reasons, VPNs going up and down being an example. The
1720           idea is to send packets through the main table prior to applying
1721           any of the Shorewall-generated routing rules. So changes to the
1722           main table will affect the routing of packets by default.
1723
1724           When USE_DEFAULT_RT=Yes:
1725
1726            1. Both the DUPLICATE and the COPY columns in providers[9](5) file
1727               must remain empty (or contain "-").
1728
1729            2. The default route is added to the the 'default' table rather
1730               than to the main table.
1731
1732            3. If running Shorewall 5.1.0 or earlier or if
1733               BALANCE_PROVIDERS=Yes (Shorewall 5.1.1 or later), then the
1734               balance provider option is assumed unless the fallback, loose,
1735               load or tproxy option is specified.
1736
1737            4. Packets are sent through the main routing table by a rule with
1738               priority 999. In shorewall-rtrules[30](5), the range 1-998 may
1739               be used for inserting rules that bypass the main table.
1740
1741            5. All provider gateways must be specified explicitly in the
1742               GATEWAY column.  detect may not be specified..if n .sp
1743                   Note
1744                   detect may be specified for interfaces whose configuration
1745                   is managed by dhcpcd. Shorewall will use dhcpcd's database
1746                   to find the interface's gateway.
1747
1748            6. You should disable all default route management outside of
1749               Shorewall. If a default route is added to the main table while
1750               Shorewall is started, then all policy routing will stop working
1751               (except for those routing rules in the priority range 1-998).
1752
1753           Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it
1754           was set to the empty string then USE_DEFAULT_RT=No was assumed.
1755           Beginning with Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes
1756           and use of USE_DEFAULT_RT=No is deprecated.
1757
1758               Warning
1759               The enable, disable and reenable commands do not work correctly
1760               when USE_DEFAULT_RT=No.
1761
1762       USE_NFLOG_SIZE=[Yes|No]
1763           Added in Shorewall 5.1.5. The second parameter to the NFLOG target
1764           specifies how many bytes of the packet to copy to the log; if
1765           omitted or if supplied as zero, the entire packet is copied. This
1766           feature has traditionally been implemented using the --nflog-range
1767           option to the NFLOG iptables target. Unfortuntely, the
1768           --nflog-range option never worked (the entire packet was always
1769           copied). To deal with this issue, the Netfilter team:
1770
1771           ·   Added a warning message when --nflog-range is used
1772
1773           ·   Added --nflog-size which works like --nflog-range was intended
1774               to work.
1775
1776           When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new
1777           --nflog-size feature. If that feature is not available in the
1778           running kernel and ip[6]tables, an error is raised.
1779
1780           When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed.
1781           When USE_NFLOG_SIZE is added by shorewall update, it is added with
1782           setting No.
1783
1784       USE_PHYSICAL_NAMES=[Yes|No]
1785           Added in Shorewall 4.4.27. Normally, when Shorewall creates a
1786           Netfilter chain that relates to an interface, it uses the
1787           interface's logical name as the base of the chain name. For
1788           example, if the logical name for an interface is OAKLAND, then the
1789           input chain for traffic arriving on that interface would be
1790           'OAKLAND_in'. If this option is set to Yes, then the physical name
1791           of the interface will be used the base of the chain name.
1792
1793       USE_RT_NAMES=[Yes|No]
1794           Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use
1795           routing table (provider) names in the generated script rather than
1796           table numbers. When set to 'No' (the default), routing table
1797           numbers will be used.
1798
1799               Caution
1800               If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you
1801               must insure that all of your providers have entries in
1802               /etc/iproute2/rt_tables as well as the following entries:
1803                   255 local
1804                   254 main
1805                   253 default
1806                   250 balance
1807                   0 unspec
1808               Without these entries, the firewall will fail to start.
1809
1810       VERBOSE_MESSAGES=[Yes|No]
1811           Added in Shorewall 5.0.9. When Yes (the default), messages produced
1812           by the ?INFO and ?WARNING directives include the filename and
1813           linenumber of the directive. When set to No, that additional
1814           information is omitted. The setting may be overridden on a
1815           directive by directive basis by following ?INFO or ?WARNING with
1816           '!' (no intervening white space).
1817
1818       VERBOSITY=[number]
1819           Shorewall has traditionally been very noisy (produced lots of
1820           output). You may set the default level of verbosity using the
1821           VERBOSITY OPTION.
1822
1823           Values are:
1824               0 - Silent. You may make it more verbose using the -v
1825                           option
1826               1 - Major progress messages displayed
1827               2 - All progress messages displayed (pre Shorewall-3.2.0
1828                           behavior)
1829           If not specified, then 2 is assumed.
1830
1831       WARNOLDCAPVERSION=[Yes|No]
1832           Added in Shorewall 4.5.12. When set to Yes (the default), the
1833           compiler issues a warning when it finds a capabilities file that
1834           doesn't specify all of the capabilities supported by the compiler.
1835           When WARNOLDCAPVERSION is set to No, no warning is issued.
1836
1837       WORKAROUNDS=[Yes|No]
1838           Added in Shorewall 4.6.11. Over time, there have been a number of
1839           changes in Shorewall that work around defects in other products
1840           such as iptables and ipset. When WORKAROUNDS=Yes, these workarounds
1841           are enabled; when WORKAROUNDS=No, they are disabled. If not
1842           specified or if specified as empty, WORKAROUNDS=Yes is assumed.
1843
1844               Warning
1845               Do not set WORKAROUNDS=Yes if you need to be able to use
1846               Shorewall-generated scripts (such as created by the save
1847               command) built by Shorewall 4.4.7 or older.
1848
1849       ZERO_MARKS=[Yes|No]
1850           Added in Shorewall 5.0.12, this is a workaround for an issue where
1851           packet marks are not zeroed by the kernel. It should be set to No
1852           (the default) unless you find that incoming packets are being
1853           mis-routed for no apparent reasons.
1854
1855               Caution
1856               Do not set this option to Yes if you have IPSEC software
1857               running on the firewall system.
1858
1859       ZONE_BITS=[number]
1860           Added in Shorewall 4.4.26. When non-zero, enables automatic packet
1861           marking by source zone and determines the number of bits in the
1862           32-bit packet mark to be used for the zone mark. Default value is
1863           0.
1864
1865       ZONE2ZONE=[2|-]
1866           Added in Shorewall 4.4.4. This option determines how Shorewall
1867           constructs chain names involving zone names and/or 'all'. Beginning
1868           with Shorewall 4.6.0, the default is '-' (e.g., fw-net); prior to
1869           that release, the default was '2' (e.g., fw2net).
1870

FILES

1872       /etc/shorewall/shorewall.conf
1873
1874       /etc/shorewall6/shorewall6.conf
1875

SEE ALSO

1877       shorewall(8)
1878

NOTES

1880        1. shorewall-policy
1881           https://shorewall.org/manpages/shorewall-policy.html
1882
1883        2. shorewall-accounting
1884           https://shorewall.org/manpages/shorewall-accounting.html
1885
1886        3. shorewall-nat
1887           https://shorewall.org/manpages/shorewall-nat.html
1888
1889        4. shorewall-masq
1890           https://shorewall.org/manpages/shorewall-masq.html
1891
1892        5. shorewall-routestopped
1893           https://shorewall.org/manpages/shorewall-routestopped.html
1894
1895        6. shorewall-stoppedrules
1896           https://shorewall.org/manpages/shorewall-stoppedrules.html
1897
1898        7. shorewall-conntrack
1899           https://shorewall.org/manpages/shorewall-conntrack.html
1900
1901        8. shorewall-rules
1902           https://shorewall.org/manpages/shorewall-rules.html
1903
1904        9. shorewall-providers(5)
1905           https://shorewall.org/manpages/shorewall-providers.html
1906
1907       10. shorewall-tcfilters(5)
1908           https://shorewall.org/manpages/shorewall-tcfilters.html
1909
1910       11. shorewall-blrules
1911           https://shorewall.org/manpages/shorewall-blrules.html
1912
1913       12. shorewall-tcrules
1914           https://shorewall.org/manpages/shorewall-tcrules.html
1915
1916       13. Shorewall6
1917           https://shorewall.org/IPv6Support.html
1918
1919       14. https://shorewall.org/Docker.html
1920           https://shorewall.org/Docker.html
1921
1922       15. https://shorewall.org/ISO-3661.html
1923           https://shorewall.org/ISO-3661.html
1924
1925       16. shorewall-zones
1926           https://shorewall.org/manpages/shorewall-zones.html
1927
1928       17. shorewall-nesting
1929           https://shorewall.org/manpages/shorewall-nesting.html
1930
1931       18. shorewall(8)
1932           https://shorewall.org/manpages/shorewall.html
1933
1934       19. shorewall-params(5)
1935           https://shorewall.org/manpages/shorewall-params.html
1936
1937       20. shorewall-interfaces
1938           https://shorewall.org/manpages/shorewall-interfaces.html
1939
1940       21. shorewall-logging(8)
1941           https://shorewall.org/manpages/shorewall-logging.html
1942
1943       22. shorewall-maclist
1944           https://shorewall.org/manpages/shorewall-maclist.html
1945
1946       23. shorewall[6].conf
1947           https://shorewall.org/manpages/shorewall.conf.html
1948
1949       24. https://shorewall.org/MultiISP.html#null_routing
1950           https://shorewall.org/MultiISP.html#null_routing
1951
1952       25. Shorewall Init Package
1953           https://shorewall.org/manpages/shorewall-init.html
1954
1955       26. Hairpin packets are packets that are routed out of the same
1956           interface that they arrived on.
1957
1958       27. Hairpin packets are packets that are routed out of the same
1959           interface that they arrived on.
1960
1961       28. shorewall-tcinterfaces
1962           https://shorewall.org/manpages/shorewall-tcinterfaces.html
1963
1964       29. shorewall-tcpri
1965           https://shorewall.org/manpages/shorewall-tcpri.html
1966
1967       30. shorewall-rtrules
1968           https://shorewall.org/manpages/shorewall-rtrules.html
1969
1970
1971
1972Configuration Files               07/29/2020                 SHOREWALL.CONF(5)
Impressum