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. When set to Yes, the generated script
490           will save Docker-generated rules before and restore them after
491           executing the start, stop, reload and restart commands. If set to
492           No (the default), the generated script will delete any
493           Docker-generated rules when executing those commands.
494           Seehttp://www.shorewall.net/Docker.html[14] for additional
495           information.
496
497       DONT_LOAD=[module[,module]...]
498           Causes Shorewall to not load the listed kernel modules.
499
500       DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:log_tag]]]}
501           Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
502           blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l]
503           reject, shorewall logdrop and shorewall [-6] [-l] logreject is
504           disabled. Default is Yes. Beginning with Shorewall 5.0.8,
505           ipset-based dynamic blacklisting using the shorewall blacklist
506           command is also supported. The name of the set (setname) and the
507           level (log_level), if any, at which blacklisted traffic is to be
508           logged may also be specified. The default IPv4 set name is SW_DBL4
509           and the default IPv6 set name is SW_DBL6. The default log level is
510           none (no logging). If ipset-only is given, then chain-based dynamic
511           blacklisting is disabled just as if DYNAMIC_BLACKLISTING=No had
512           been specified.
513
514           Possible options are:
515
516           src-dst
517               Normally, only packets whose source address matches an entry in
518               the ipset are dropped. If src-dst is included, then packets
519               whose destination address matches an entry in the ipset are
520               also dropped.
521
522           disconnect
523               The disconnect option was added in Shorewall 5.0.13 and
524               requires that the conntrack utility be installed on the
525               firewall system. When an address is blacklisted using the
526               blacklist command, all connections originating from that
527               address are disconnected. if the src-dst option was also
528               specified, then all connections to that address are also
529               disconnected.
530
531           timeout=seconds
532               Added in Shorewall 5.0.13. Normally, Shorewall creates the
533               dynamic blacklisting ipset with timeout 0 which means that
534               entries are permanent. If you want entries in the set that are
535               not accessed for a period of time to be deleted from the set,
536               you may specify that period using this option. Note that the
537               blacklist command can override the ipset's timeout setting.
538
539                   Important
540                   Once the dynamic blacklisting ipset has been created,
541                   changing this option setting requires a complete restart of
542                   the firewall; shorewall [-6] restart if RESTART=restart,
543                   otherwise shorewall [-6] [-l] stop && shorewall [-6] [-l]
544                   start
545
546           When ipset-based dynamic blacklisting is enabled, the contents of
547           the blacklist will be preserved over stop/reboot/start sequences if
548           SAVE_IPSETS=Yes, SAVE_IPSETS=ipv4 or if setname is included in the
549           list of sets to be saved in SAVE_IPSETS.
550
551       EXPAND_POLICIES={Yes|No}
552           Normally, when the SOURCE or DEST columns in shorewall-policy(5)
553           contains 'all', a single policy chain is created and thes policy is
554           enforced in that chain. For example, if the policy entry is
555
556               #SOURCE DEST POLICY LOG
557               #                   LEVEL
558               net     all  DROP   info
559
560           then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is
561           also the chain named in Shorewall log messages generated as a
562           result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will
563           create a separate chain for each pair of zones covered by the
564           policy. This makes the resulting log messages easier to interpret
565           since the chain in the messages will have a name of the form 'a2b'
566           where 'a' is the SOURCE zone and 'b' is the DEST zone.
567
568       EXPORTMODULES=[Yes|No]
569           Added in Shorewall 4.4.17. When set to Yes when compiling for use
570           by Shorewall Lite (shorewall [-6] remote-start, shorewall [-6]
571           remote-reload, shorewall [-6] remote-restart or shorewall [-6]
572           export commands), the compiler will copy the modules or helpers
573           file from the administrative system into the script. When set to No
574           or not specified, the compiler will not copy the modules or helpers
575           file from /usr/share/shorewall[6] but will copy those found in
576           another location on the CONFIG_PATH.
577
578           When compiling for direct use by Shorewall, causes the contents of
579           the local module or helpers file to be copied into the compiled
580           script. When set to No or not set, the compiled script reads the
581           file itself.
582
583       FASTACCEPT={Yes|No}
584           Normally, Shorewall defers accepting ESTABLISHED/RELATED packets
585           until these packets reach the chain in which the original
586           connection was accepted. So for packets going from the 'loc' zone
587           to the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the
588           'loc-net' or 'loc2net' chain, depending on the setting of ZONE2ZONE
589           (see below).
590
591           If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets are
592           accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
593           FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or
594           RELATED sections of shorewall-rules[8](5).
595
596       FIREWALL=[dnsname-or-ip-address]
597           This option was added in Shorewall 5.0.13 and may be used on an
598           administrative system in directories containing the configurations
599           of remote firewalls. The contents of the variable are the default
600           value for the system parameter to the remote-start, remote-reload
601           and remote-restart commands.
602
603       FORWARD_CLEAR_MARK={Yes|No}
604           Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the
605           packet mark in the first rule in the mangle FORWARD chain. This
606           behavior is maintained with the default setting of this option
607           (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to 'No',
608           packet marks set in the mangle PREROUTING chain are retained in the
609           FORWARD chains.
610
611       GEOIPDIR=[pathname]
612           Added in Shorewall 4.5.4. Specifies the pathname of the directory
613           containing the GeoIP Match database. See
614           http://www.shorewall.net/ISO-3661.html[15]. If not specified, the
615           default value is /usr/share/xt_geoip/LE which is the default
616           location of the little-endian database.
617
618       HELPERS=[helper[,helper...]]
619           Added in Shorewall 4.5.7. This option specifies a comma-separated
620           list naming the Netfilter application helpers that are to be
621           enabled. If not specified, the default is to enable all helpers.
622
623           Possible values for helper are:
624
625           ·   amanda
626
627           ·   ftp
628
629           ·   h323
630
631           ·   irc
632
633           ·   netbios-ns
634
635           ·   none - This special value was added in Shorewall 4.5.16 and
636               indicates that no helpers are to be enabled. It also prevents
637               the compiler for probing for helper support; such probing
638               generates messages on the system log of the form "xt_CT: No
639               such helper XXX" where XXX is the helper name. When used, none
640               must be the only helper specified.
641
642           ·   pptp
643
644           ·   sane
645
646           ·   sip
647
648           ·   snmp
649
650           ·   tftp
651
652           When HELPERS is specified on a system running Kernel 3.5.0 or
653           later, automatic association of helpers to connections is disabled.
654
655       IGNOREUNKNOWNVARIABLES=[Yes|No]
656           Added in Shorewall 4.5.11. Normally, if an unknown shell variable
657           is encountered in a configuration file (except in ?IF and ?ELSIF
658           directives), the compiler raises a fatal error. If
659           IGNOREUNKNOWNVARIABLES is set to Yes, then such variables simply
660           expand to an empty string. Default is No.
661
662       IMPLICIT_CONTINUE={Yes|No}
663           When this option is set to Yes, it causes subzones to be treated
664           differently with respect to policies.
665
666           Subzones are defined by following their name with ":" and a list of
667           parent zones (in shorewall-zones[16](5)). Normally, you want to
668           have a set of special rules for the subzone and if a connection
669           doesn't match any of those subzone-specific rules then you want the
670           parent zone rules and policies to be applied; see
671           shorewall-nesting[17](5). With IMPLICIT_CONTINUE=Yes, that happens
672           automatically.
673
674           If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
675           subzones are not subject to this special treatment. With
676           IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be
677           overridden by including an explicit policy (one that does not
678           specify "all" in either the SOURCE or the DEST columns).
679
680       INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
681           Added in Shorewall 4.5.13. Shorewall has traditionally passed
682           INVALID packets through the NEW section of shorewall-rules[8] (5).
683           When a packet in INVALID state fails to match any rule in the
684           INVALID section, the packet is disposed of based on this setting.
685           The default value is CONTINUE for compatibility with earlier
686           versions.
687
688       INVALID_LOG_LEVEL=log-level[:log-tag]
689           Added in Shorewall 4.5.13. Packets in the INVALID state that do not
690           match any rule in the INVALID section of shorewall-rules[8] (5) are
691           logged at this level. The default value is empty which means no
692           logging is performed.
693
694       IP=[pathname]
695           If specified, gives the pathname of the 'ip' executable. If not
696           specified, 'ip' is assumed and the utility will be located using
697           the current PATH setting.
698
699       IP_FORWARDING=[On|Off|Keep]
700           This IPv4 parameter determines whether Shorewall enables or
701           disables IPv4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In
702           an IPv6 configuration, this parameter determines the setting of
703           /proc/sys/net/ipv6/config/all/ip_forwarding.
704
705           Possible values are:
706
707           On or on
708               packet forwarding will be enabled.
709
710           Off or off
711               packet forwarding will be disabled.
712
713           Keep or keep
714               Shorewall will neither enable nor disable packet forwarding.
715
716           If this variable is not set or is given an empty value
717           (IP_FORWARD="") then IP_FORWARD=On is assumed.
718
719       IPSET=[pathname]
720           If specified, gives the pathname of the 'ipset' executable. If not
721           specified, 'ipset' is assumed and the utility will be located using
722           the current PATH setting.
723
724       IPSET_WARNINGS={Yes|No}
725           Added in Shorewall 4.5.2. Default is Yes. When set, causes the
726           rules compiler to issue a warning when:
727
728           ·   The compiler is being run by root and an ipset specified in the
729               configuration does not exists. Only one warning is issued for
730               each missing ipset.
731
732           ·   When [src] is specified in a destination column and when [dst]
733               is specified in a source column.
734
735       IPTABLES=[pathname]
736           IPv4 only.
737
738           This parameter names the iptables executable to be used by
739           Shorewall. If not specified or if specified as a null value, then
740           the iptables executable located using the PATH option is used.
741
742           Regardless of how the iptables utility is located (specified via
743           IPTABLES= or located via PATH), Shorewall uses the iptables-restore
744           and iptables-save utilities from that same directory.
745
746       IP6TABLES=[pathname]
747           IPv6 only.
748
749           This parameter names the ip6tables executable to be used by
750           Shorewall6. If not specified or if specified as a null value, then
751           the ip6tables executable located using the PATH option is used.
752
753           Regardless of how the ip6tables utility is located (specified via
754           IP6TABLES= or located via PATH), Shorewall6 uses the
755           ip6tables-restore and ip6tables-save utilities from that same
756           directory.
757
758       KEEP_RT_TABLES={Yes|No}
759           IPv4: When set to Yes, this option prevents generated scripts from
760           altering the /etc/iproute2/rt_tables database when there are
761           entries in /etc/shorewall/providers. If you set this option to Yes
762           while Shorewall (Shorewall-lite) is running, you should remove the
763           file /var/lib/shorewall/rt_tables
764           (/var/lib/shorewall-lite/rt_tables) before your next stop, restore,
765           reload or restart command.  IPv6: When set to Yes, this option
766           prevents scripts generated by Shorewall6 from altering the
767           /etc/iproute2/rt_tables database when there are entries in
768           /etc/shorewall6/providers. If you set this option to Yes while
769           Shorewall6 (Shorewall6-lite) is running, you should remove the file
770           /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
771           before your next stop, restore, reload or restart command.
772
773               Important
774               When both IPv4 and IPv6 Shorewall configurations are present,
775               KEEP_RT_TABLES=No should be specified in only one of the two
776               configurations unless the two provider configurations are
777               identical with respect to interface and provider names and
778               numbers.
779           The default is KEEP_RT_TABLES=No.
780
781       LOAD_HELPERS_ONLY={Yes|No}
782           Added in Shorewall 4.4.7. When set to Yes, restricts the set of
783           modules loaded by shorewall to those listed in
784           /var/lib/shorewall[6]/helpers and those that are actually used.
785           When not set, or set to the empty value, LOAD_HELPERS_ONLY=No is
786           assumed in Shorewall versions 5.2.2 and earlier. Beginning with
787           Shorewall 5.2.3, the LOAD_HELPERS_ONLY option is removed, and the
788           behavior is as if LOAD_HELPERS_ONLY=Yes had been specified.
789
790       LOCKFILE=[pathname]
791           Specifies the name of the Shorewall[6] lock file, used to prevent
792           simultaneous state-changing commands. If not specified,
793           ${VARDIR}/shorewall[6]/lock is assumed (${VARDIR} is normally
794           /var/lib but can be changed when Shorewall-core is installed -- see
795           the output of shorewall show vardir).
796
797       LOG_BACKEND=[backend]
798           Added in Shorewall 4.6.4. LOG_BACKEND determines the logging
799           backend to be used for the iptrace command (see shorewall(8)[18]).
800
801           backend is one of:
802
803           LOG
804               Use standard kernel logging.
805
806           ULOG
807               IPv4 only.
808
809               Use ULOG logging to ulogd.
810
811           netlink
812               Use netlink logging to ulogd version 2 or later.
813
814       LOG_ZONE=[src|dst|both]
815           Added in Shorewall 5.2.0. When a log message is issued from a chain
816           that relates to a pair of zones (e.g, 'fw-net'), the chain name
817           normally appears in the log message (unless LOGTAGONLY=Yes and a
818           log tag is specified). This can prevent OPTIMIZE category 8 from
819           combining chains which are identical except for the names of the
820           zones involved. LOG_ZONE allows for only the source or destination
821           zone to appear in the messages by setting LOG_ZONE to src or dest
822           respectively. If LOG_ZONE=both (the default), then the full chain
823           name is included in log messages.
824
825       LOG_LEVEL=log-level[:log-tag]
826           Added in Shorewall 5.1.2. Beginning with that release, the sample
827           configurations use this as the default log level and changing it
828           will change all packet logging done by the configuration. In any
829           configuration file (except shorewall-params(5)[19]), $LOG_LEVEL
830           will expand to this value.
831
832       LOG_MARTIANS=[Yes|No|Keep]
833           IPv4 only.
834
835           If set to Yes or yes, sets /proc/sys/net/ipv4/conf/*/log_martians
836           to 1 with the exception of /proc/sys/net/ipv4/conf/all/log_martians
837           which is set to 0. The default value is Yes which sets both of the
838           above to one. If you do not enable martian logging for all
839           interfaces, you may still enable it for individual interfaces using
840           the logmartians interface option in shorewall-interfaces[20](5).
841
842           The value Keep causes Shorewall to ignore the option. If the option
843           is set to Yes, then martians are logged on all interfaces. If the
844           option is set to No, then martian logging is disabled on all
845           interfaces except those specified in shorewall-interfaces[20](5).
846
847       LOG_VERBOSITY=[number]
848           This option controls the amount of information logged to the file
849           specified in the STARTUP_LOG option.
850
851           Values are:
852               -1 - Logging is disabled
853               0 - Silent. Only error messages are logged.
854               1 - Major progress messages logged.
855               2 - All progress messages logged
856           If not specified, then -1 is assumed.
857
858       LOGALLNEW=[log-level]
859           This option is intended for use as a debugging aid. When set to a
860           log level, this option causes Shorewall to generate a logging rule
861           as the first rule in each builtin chain.
862
863           ·   The table name is used as the chain name in the log prefix.
864
865           ·   The chain name is used as the target in the log prefix.
866
867           For example, using the default LOGFORMAT, the log prefix for
868           logging from the nat table's PREROUTING chain is as follows in
869           versions prior to 5.1.0:
870
871                   Shorewall:nat:PREROUTING
872
873
874           In Shorewall 5.1.0 and later releases, the log prefix is:
875
876                   nat:PREROUTING
877
878
879
880               Important
881               To help insure that all packets in the NEW state are logged,
882               rate limiting (LOGLIMIT) should be disabled when using
883               LOGALLNEW. Use LOGALLNEW at your own risk; it may cause high
884               CPU and disk utilization and you may not be able to control
885               your firewall after you enable this option.
886
887               Caution
888               Do not use this option if the resulting log messages will be
889               sent to another system.
890
891       LOGFILE=[pathname|systemd]
892           This parameter tells the /sbin/shorewall program where to look for
893           Shorewall messages when processing the dump, logwatch, show log,
894           and hits commands. If not assigned or if assigned an empty value,
895           /var/log/messages is assumed. For further information, see
896           shorewall-logging(8)[21]. Beginning with Shorewall 5.0.10.1, you
897           may specify systemd to use journelctl -r to read the log.
898
899       LOGFORMAT=["formattemplate"]
900           The value of this variable generate the --log-prefix setting for
901           Shorewall logging rules. It contains a “printf” formatting template
902           which accepts three arguments (the chain name, logging rule number
903           (optional) and the disposition). To use LOGFORMAT with fireparse,
904           set it as:
905
906                   LOGFORMAT="fp=%s:%d a=%s "
907
908           If the LOGFORMAT value contains the substring “%d” then the logging
909           rule number is calculated and formatted in that position; if that
910           substring is not included then the rule number is not included. If
911           not supplied or supplied as empty (LOGFORMAT="") then
912           “Shorewall:%s:%s:” is assumed.
913
914               Note
915               The setting of LOGFORMAT has an effect of the permitted length
916               of zone names. See shorewall-zones[16] (5).
917
918               Caution
919               Beginning with Shorewall 5.1.0, the default and sample
920               shorewall[6].conf files set LOGFORMAT="%s %s ".
921
922               Regardless of the LOGFORMAT setting, Shorewall IPv4 log
923               messages that use this LOGFORMAT can be uniquely identified
924               using the following regular expression:
925                   'IN=.* OUT=.* SRC=.*\..* DST='
926               and Shorewall IPv6 log messages can be uniquely identified
927               using the following regular expression:
928                   'IN=.* OUT=.* SRC=.*:.* DST='
929               To match all Netfilter log messages (Both IPv4 and IPv6 and
930               regardless of the LOGFORMAT setting), use:
931                   'IN=.* OUT=.* SRC=.* DST='
932
933       LOGLIMIT=[[{s|d}:]rate/{sec|second|min|minute|hour|day}[:burst]]
934           Added in Shorewall 4.4.12. Limits the logging rate, either overall,
935           or by source or destination IP address.
936
937           If the value starts with 's:' then logging is limited per source
938           IP. If the value starts with 'd:', then logging is limited per
939           destination IP. Otherwise, the overall logging rate is limited.
940
941           If burst is not specified, then a value of 5 is assumed.
942
943           The keywords second and minute are accepted beginning with
944           Shorewall 4.6.13.
945
946       LOGTAGONLY=[Yes|No]
947           Using LOGFORMAT=“Shorewall:%s:%s:”, chain names may not exceed 5
948           characters or truncation of the log prefix may occur. Longer chain
949           names may be used with log tags if you set LOGTAGONLY=Yes. With
950           LOGTAGONLY=Yes, if a log tag is specified then the tag is included
951           in the log prefix in place of the chain name.
952
953           Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more
954           control over the generated log prefix. Beginning with that release,
955           the tag is interpreted as a chain name and a disposition separated
956           by a comma. So this rule:
957
958               #ACTION                                SOURCE         DEST
959               LOG:info:foo,bar                       net            fw
960
961           would generate the following log prefix when using
962           LOGFORMAT=“Shorewall:%s:%s:”:
963               Shorewall:foo:bar:
964           Similarly,
965
966               #ACTION                               SOURCE            DEST
967               LOG:info:,bar                        net                    fw
968
969           would generate
970               Shorewall:net2fw:bar:
971
972       MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
973           Determines the disposition of connections requests that fail MAC
974           Verification and must have the value ACCEPT (accept the connection
975           request anyway), REJECT (reject the connection request) or DROP
976           (ignore the connection request). If not set or if set to the empty
977           value (e.g., MACLIST_DISPOSITION="") then
978           MACLIST_DISPOSITION=REJECT is assumed.
979
980           A_DROP and A_REJECT are audited versions of DROP and REJECT
981           respectively and were added in Shorewall 4.4.20. They require
982           AUDIT_TARGET in the kernel and ip[6]tables.
983
984       MACLIST_LOG_LEVEL=[log-level[:log-tag]]
985           Determines the syslog level for logging connection requests that
986           fail MAC Verification. The value must be a valid syslogd log level.
987           If you don't want to log these connection requests, set to the
988           empty value (e.g., MACLIST_LOG_LEVEL="").
989
990       MACLIST_TABLE=[filter|mangle]
991           Normally, MAC verification occurs in the filter table (INPUT and
992           FORWARD) chains. When forwarding a packet from an interface with
993           MAC verification to a bridge interface, that doesn't work.
994
995           This problem can be worked around by setting MACLIST_TABLE=mangle
996           which will cause Mac verification to occur out of the PREROUTING
997           chain. Because REJECT isn't available in that environment, you may
998           not specify MACLIST_DISPOSITION=REJECT or
999           MACLIST_DISPOSITION=A_REJECT with MACLIST_TABLE=mangle.
1000
1001       MACLIST_TTL=[number]
1002           The performance of configurations with a large numbers of entries
1003           in shorewall-maclist[22](5) can be improved by setting the
1004           MACLIST_TTL variable in shorewall[6].conf[23](5).
1005
1006           If your iptables and kernel support the "Recent Match" (see the
1007           output of "shorewall check" near the top), you can cache the
1008           results of a 'maclist' file lookup and thus reduce the overhead
1009           associated with MAC Verification.
1010
1011           When a new connection arrives from a 'maclist' interface, the
1012           packet passes through then list of entries for that interface in
1013           shorewall-maclist[22](5). If there is a match then the source IP
1014           address is added to the 'Recent' set for that interface. Subsequent
1015           connection attempts from that IP address occurring within
1016           $MACLIST_TTL seconds will be accepted without having to scan all of
1017           the entries. After $MACLIST_TTL from the first accepted connection
1018           request from an IP address, the next connection request from that
1019           IP address will be checked against the entire list.
1020
1021           If MACLIST_TTL is not specified or is specified as empty (e.g,
1022           MACLIST_TTL="" or is specified as zero then 'maclist' lookups will
1023           not be cached).
1024
1025       MANGLE_ENABLED=[Yes|No]
1026           Determines whether Shorewall will generate rules in the Netfilter
1027           mangle table. Setting MANGLE_ENABLED=No disables all Shorewall
1028           features that require the mangle table. The default is
1029           MANGLE_ENABLED=Yes.
1030
1031       MINIUPNPD=[Yes|No]
1032           Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a
1033           chain in the nat table named MINIUPNPD-POSTROUTING and will add
1034           jumps from POSTROUTING to that chain for each interface with the
1035           upnpd option specified. Default is No.
1036
1037       MARK_IN_FORWARD_CHAIN=[Yes|No]
1038           If your kernel has a FORWARD chain in the mangle table, you may set
1039           MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the
1040           tcrules file to occur in that chain rather than in the PREROUTING
1041           chain. This permits you to mark inbound traffic based on its
1042           destination address when DNAT is in use. To determine if your
1043           kernel has a FORWARD chain in the mangle table, use the shorewall
1044           [-6] show mangle command; if a FORWARD chain is displayed then your
1045           kernel will support this option. If this option is not specified or
1046           if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="")
1047           then MARK_IN_FORWARD_CHAIN=No is assumed.
1048
1049       MASK_BITS=[number]
1050           Added in Shorewall 4.4.26. Number of bits on the right of the
1051           32-bit packet mark to be masked when clearing the traffic shaping
1052           mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET
1053           > 0). Prior to Shorewall 5.0.0, default value and the default
1054           values of the other mark layout options is determined as follows:
1055
1056           Table 1. Default Packet Mark Layout
1057           WIDE_TC_MARKS=No,      TC_BITS=8,
1058           HIGH_ROUTE_MARKS=No    PROVIDER_BITS=8,
1059                                  PROVIDER_OFFSET=0,
1060                                                    MASK_BITS=8
1061           WIDE_TC_MARKS=No,      TC_BITS=8, PROVIDER_BITS=8,
1062           HIGH_ROUTE_MARKS=Yes   PROVIDER_OFFSET=8,
1063                                                    MASK_BITS=8
1064           WIDE_TC_MARKS=Yes,     TC_BITS=14, PROVIDER_BITS=8,
1065           HIGH_ROUTE_MARKS=No    PROVIDER_OFFSET=0,
1066                                                    MASK_BITS=16
1067           WIDE_TC_MARKS=Yes,     TC_BITS=14, PROVIDER_BITS=8,
1068           HIGH_ROUTE_MARKS=Yes   PROVIDER_OFFSET=16,
1069                                                    MASK_BITS=16
1070
1071           From 5.0.0 onward, the default value of MASK_BITS is 8, the default
1072           value of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is
1073           8.
1074
1075       MODULESDIR=[[+]pathname[:pathname]...]
1076           This parameter specifies the directory/directories where your
1077           kernel netfilter modules may be found. If you leave the variable
1078           empty, Shorewall will supply the value
1079           "/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"
1080           where uname holds the output of 'uname -r' and g_family holds '4'
1081           in IPv4 configurations and '6' in IPv6 configurations.
1082
1083           The option plus sign ('+') was added in Shorewall 5.0.3 and causes
1084           the listed pathnames to be appended to the default list above.
1085
1086       MULTICAST=[Yes|No]
1087           IPv4 only.
1088
1089           This option will normally be set to 'No' (the default). It should
1090           be set to 'Yes' under the following circumstances:
1091
1092            1. You have an interface that has parallel zones defined via
1093               /etc/shorewall/hosts.
1094
1095            2. You want to forward multicast packets to two or more of those
1096               parallel zones.
1097
1098           In such cases, you will configure a destonly network on each zone
1099           receiving multicasts.
1100
1101       MUTEX_TIMEOUT=[seconds]
1102           The value of this variable determines the number of seconds that
1103           programs will wait for exclusive access to the Shorewall[6] lock
1104           file. After the number of seconds corresponding to the value of
1105           this variable, programs will assume that the last program to hold
1106           the lock died without releasing the lock.
1107
1108           If not set or set to the empty value, a value of 60 (60 seconds) is
1109           assumed.
1110
1111           An appropriate value for this parameter would be twice the length
1112           of time that it takes your firewall system to process a shorewall
1113           [-6] restart command.
1114
1115       NFACCT=[pathname]
1116           Added in Shorewall 4.5.7. Specifies the pathname of the nfacct
1117           utility. If not specified, Shorewall will use the PATH setting to
1118           find the program.
1119
1120       NULL_ROUTE_RFC1918=[Yes|No|blackhole|unreachable|prohibit]
1121           IPv4 only.
1122
1123           When set to Yes, causes Shorewall to null-route the IPv4 address
1124           ranges reserved by RFC1918. The default value is 'No'.
1125
1126           When combined with route filtering (ROUTE_FILTER=Yes or routefilter
1127           in shorewall-interfaces[20](5)), this option ensures that packets
1128           with an RFC1918 source address are only accepted from interfaces
1129           having known routes to networks using such addresses.
1130
1131           Beginning with Shorewall 4.5.15, you may specify blackhole,
1132           unreachable or prohibit to set the type of route to be created. See
1133           http://www.shorewall.net/MultiISP.html#null_routing[24].
1134
1135       OPTIMIZE=[value]
1136           The specified value enables certain optimizations. Each
1137           optimization category is associated with a power of two. To enable
1138           multiple optimization categories, simply add their corresponding
1139           numbers together.
1140
1141           Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to
1142           enable all optimization categories, and you may also specify
1143           OPTIMIZE=None to disable optimization.
1144
1145           ·   Optimization category 1 - Traditionally, Shorewall has created
1146               rules for the complete matrix of host groups defined by the
1147               zones, interfaces and hosts files. Any traffic that didn't
1148               correspond to an element of that matrix was rejected in one of
1149               the built-in chains. When the matrix is sparse, this results in
1150               lots of largely useless rules.
1151
1152               These extra rules can be eliminated by setting the 1 bit in
1153               OPTIMIZE.
1154
1155               The 1 bit setting also controls the suppression of redundant
1156               wildcard rules (those specifying "all" in the SOURCE or DEST
1157               column). A wildcard rule is considered to be redundant when it
1158               has the same ACTION and Log Level as the applicable policy.
1159
1160                   Note
1161                   Optimization level 1 is ignored when optimization level 4
1162                   is also selected, since level 4 performs similar
1163                   optimizations in a more robust way.
1164
1165           ·   Optimization category 2 - Added in Shorewall 4.4.7. When set,
1166               suppresses superfluous ACCEPT rules in a policy chain that
1167               implements an ACCEPT policy. Any ACCEPT rules that immediately
1168               precede the final blanket ACCEPT rule in the chain are now
1169               omitted.
1170
1171           ·   Optimization category 4 - Added in Shorewall 4.4.7. When set,
1172               causes short chains (those with less than 2 rules) to be
1173               optimized away. The following chains are excluded from
1174               optimization:
1175
1176               ·   accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
1177
1178               ·   action chains (user-defined)
1179
1180               ·   'blacklst' chain
1181
1182               ·   dynamic
1183
1184               ·   forwardUPnP
1185
1186               ·   UPnP (nat table)
1187
1188               Additionally:
1189
1190               ·   If a built-in chain has a single rule that branches to a
1191                   second chain, then the rules from the second chain are
1192                   moved to the built-in chain and the target chain is
1193                   omitted.
1194
1195               ·   Chains with no references are deleted.
1196
1197               ·   Accounting chains are subject to optimization if the
1198                   OPTIMIZE_ACCOUNTING option is set to 'Yes'.
1199
1200               ·   If a chain ends with an unconditional branch to a second
1201                   chain (other than to 'reject'), then the branch is deleted
1202                   from the first chain and the rules from the second chain
1203                   are appended to it.
1204
1205               An additional optimization was added in Shorewall 4.5.4. If the
1206               last rule in a chain is an unqualified jump to a simple target,
1207               then all immediately preceding rules with the same simple
1208               target are omitted.
1209
1210               For example, consider this chain:
1211
1212                        -A fw-net -p udp --dport 67:68 -j ACCEPT
1213                        -A fw-net -p udp --sport 1194 -j ACCEPT
1214                        -A fw-net -p 41 -j ACCEPT
1215                        -A fw-net -j ACCEPT
1216
1217               Since all of the rules are jumps to the simple target ACCEPT,
1218               this chain is totally optimized away and jumps to the chain are
1219               replace with jumps to ACCEPT.
1220
1221           ·   Optimization category 8 - Added in Shorewall 4.4.9. When set,
1222               causes chains with identical rules to be collapsed into a
1223               single chain.
1224
1225                   Warning
1226                   While Optimization category 8 can significantly reduce the
1227                   size of the generated iptables ruleset, it can also take
1228                   significant system resources during compilation. If you
1229                   find that compilation takes an unreasonably long time, try
1230                   disabling this category by setting OPTIMIZE=23.
1231
1232           ·   Optimization category 16 - Added in Shorewall 4.4.26. When set,
1233               causes sequences of compatible rules to be combined into a
1234               single rule. Rules are considered compatible if they differ
1235               only in their destination ports and comments.
1236
1237               A sequence of compatible rules is often generated when macros
1238               are invoked in sequence.
1239
1240               The ability to combine adjacent rules is limited by two
1241               factors:
1242
1243               ·   Destination port lists may only be combined up to a maximum
1244                   of 15 ports, where a port-pair counts as two ports.
1245
1246               ·   Rules may only be combined until the length of their
1247                   concatenated comment reaches 255 characters.
1248
1249               When either of these limits would be exceeded, the current
1250               combined rule is emitted and the compiler attempts to combine
1251               rules beginning with the one that would have exceeded the
1252               limit. Adjacent combined comments are separated by ', '. Empty
1253               comments at the front of a group of combined comments are
1254               replaced by 'Others and'. Empty comments at the end of a group
1255               of combined comments are replaced by 'and others'.
1256
1257               Beginning in Shorewall 4.5.10, this option also suppresses
1258               duplicate adjacent rules and duplicate non-adjacent rules that
1259               don't include mark, connmark, dscp, ecn, set, tos or u32
1260               matches.
1261
1262               Example 1:
1263                   Rules with comments "FOO", <empty> and "BAR" would result
1264                   in the combined comment "FOO and others, BAR".
1265
1266               Example 2:
1267                   Rules with comments <empty>, "FOO" and "BAR" would result
1268                   in the combined comment "Others and FOO, BAR". Note:
1269                   Optimize level 16 requires "Extended Multi-port Match" in
1270                   your iptables and kernel.
1271
1272           In versions prior to 5.1.0, the default value is zero which
1273           disables all optimizations. Beginning with Shorewall 5.1.0, the
1274           default value is All which enables all optimizations.
1275
1276       OPTIMIZE_ACCOUNTING=[Yes|No]
1277           Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
1278           changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not
1279           specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is
1280           assumed.
1281
1282       PAGER=pathname
1283           Added in Shorewall 5.0.6. Specifies a path name of a pager program
1284           like less or more. When PAGER is given, the output of verbose
1285           status commands and the dump command are piped through the named
1286           program when the output file is a terminal.
1287
1288           Beginning with Shorewall 5.0.12, the default value of this option
1289           is the DEFAULT_PAGER setting in shorewallrc.
1290
1291       PATH=pathname[:pathname]...
1292           Determines the order in which Shorewall searches directories for
1293           executable files.
1294
1295       PERL=pathname
1296           Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
1297           executable. Default is /usr/bin/perl. If the pathname specified by
1298           this option does not exist or the named file is not executable,
1299           then Shorewall falls back to /usr/bin/perl
1300
1301       PERL_HASH_SEED=seed|random
1302           Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in
1303           the range 0-99999) when running the Shorewall rules compiler. If
1304           not specified, the value 0 is assumed. If random is specified, a
1305           random seed will be chosed by Perl. See perlsec(1) for additional
1306           information.
1307
1308       PROVIDER_BITS=[number]
1309           Added in Shorewall 4.4.26. The number of bits in the 32-bit packet
1310           mark to be used for provider numbers. May be zero. See MASK_BITS
1311           above for default value.
1312
1313       PROVIDER_OFFSET=[number]If
1314           Added in Shorewall 4.4.26. The offset from the right (low-order
1315           end) of the provider number field in the 32-bit packet mark. If
1316           non-zero, must be >= TC_BITS (Shorewall automatically adjusts
1317           PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS +
1318           ZONE_BITS must be < 32. See MASK_BITS above for default value.
1319
1320       RCP_COMMAND="command"
1321
1322       RSH_COMMAND="command"
1323           Earlier generations of Shorewall Lite required that remote root
1324           login via ssh be enabled in order to use the load and reload
1325           commands. Beginning with release 3.9.5, you may define an
1326           alternative means for accessing the remote firewall system. In that
1327           release, two new options were added to shorewall.conf:
1328               RSH_COMMAND
1329               RCP_COMMAND
1330           The default values for these are as follows:
1331
1332               RSH_COMMAND: ssh ${root}@${system} ${command}
1333               RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
1334
1335           Shell variables that will be set when the commands are invoked are
1336           as follows:
1337
1338               root        - root user. Normally root but may be overridden using the '-r' option.
1339               system      - The name/IP address of the remote firewall system.
1340               command     - For RSH_COMMAND, the command to be executed on the firewall system.
1341               files       - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
1342               destination - The directory on the remote system that the files are to be copied into.
1343
1344       RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
1345           Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed
1346           RELATED packets that don't match any rule in the RELATED section of
1347           shorewall-rules[8] (5). Concern about the safety of this practice
1348           resulted in the addition of this option. When a packet in RELATED
1349           state fails to match any rule in the RELATED section, the packet is
1350           disposed of based on this setting. The default value is ACCEPT for
1351           compatibility with earlier versions.
1352
1353       RELATED_LOG_LEVEL=log-level[:log-tag]
1354           Added in Shorewall 4.4.27. Packets in the related state that do not
1355           match any rule in the RELATED section of shorewall-rules[8] (5) are
1356           logged at this level. The default value is empty which means no
1357           logging is performed.
1358
1359       REJECT_ACTION=action
1360           Added in Shorewall 4.5.21. When a REJECT target is specified,
1361           Shorewall normally handles the response as follows:
1362
1363           ·   If the destination address of the packet is a broadcast or
1364               multicast address, the packet is dropped.
1365
1366           ·   if the protocol is ICMP (2) then the packet is dropped.
1367
1368           ·   if the protocol is TCP (6) then the packet is rejected with an
1369               RST.
1370
1371           ·   if the protocol is UDP (17) then the packet is rejected with an
1372               'port-unreachable' ICMP.
1373
1374           ·   if the protocol is ICMP (1) then the packet is rejected with a
1375               'host-unreachable' ICMP.
1376
1377           ·   if the protocol is ICMP6 (1) then the packet is rejected with a
1378               'icmp6-addr-unreachable' ICMP6.
1379
1380           ·   otherwise, the packet is rejected with a 'host-prohibited'
1381               ICMP.
1382
1383           You can modify this behavior by implementing your own action that
1384           handles REJECT and specifying it's name in this option. The nolog
1385           and noinline options will automatically be assumed for the
1386           specified action.
1387
1388           The following action implements the default reject action:
1389
1390               ?format 2
1391               #TARGET         SOURCE  DEST    PROTO
1392               Broadcast(DROP) -       -       -
1393               DROP            -       -       2
1394               INLINE          -       -       6       ;; -j REJECT --reject-with tcp-reset
1395               ?if __ENHANCED_REJECT
1396               INLINE          -       -       17      ;; -j REJECT
1397               ?if __IPV4
1398               INLINE          -       -       1       ;; -j REJECT --reject-with icmp-host-unreachable
1399               INLINE          -       -       -       ;; -j REJECT --reject-with icmp-host-prohibited
1400               ?else
1401               INLINE          -       -       58      ;; -j REJECT --reject-with icmp6-addr-unreachable
1402               INLINE          -       -       -       ;; -j REJECT --reject-with icmp6-adm-prohibited
1403               ?endif
1404               ?else
1405               INLINE          -       -       -       ;; -j REJECT
1406               ?endif
1407
1408       RENAME_COMBINED=[Yes|No]
1409           Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8
1410           is enabled, identical chains are combined under a name beginning
1411           with '~comb' or '~blacklist'. This behavior is maintained under the
1412           default setting RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the
1413           chains are combined under the original name of one of the chains.
1414
1415       REQUIRE_INTERFACE=[Yes|No]
1416           Added in Shorewall 4.4.10. The default is No. If set to Yes, at
1417           least one optional interface must be up in order for the firewall
1418           to be in the started state. Intended to be used with the Shorewall
1419           Init Package[25].
1420
1421       RESTART=[restart|reload]
1422           Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added
1423           in Shorewall 5.0.0. In that release, the reload command was
1424           redefined to do what restart had done in earlier releases and
1425           restart became a true restart (equivalent to stop followed by
1426           start). When RESTART=reload, the restart command performs the same
1427           operation as the reload command making it compatible with earlier
1428           releases. If not specified, RESTART=reload is assumed.
1429
1430       RESTORE_DEFAULT_ROUTE=[Yes|No]
1431           This option determines whether to restore the default route saved
1432           when here are 'balance' providers defined but all of them are down.
1433
1434           The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
1435           pre-4.2.6 behavior.
1436
1437           RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
1438           default route in the main table (USE_DEFAULT_RT=No) or in the
1439           default table (USE_DEFAULT_RT=Yes) when there are no balance
1440           providers available. In that case, RESTORE_DEFAULT_ROUTE=No will
1441           cause any default route in the relevant table to be deleted.
1442
1443       RESTORE_ROUTEMARKS=[Yes|No]
1444           Added in Shorewall 4.5.9. When set to Yes (the default), provider
1445           marks are restored unconditionally at the top of the mangle OUTPUT
1446           and PREROUTING chains, even if the saved mark is zero. When this
1447           option is set to No, the mark is restored only if it is non-zero.
1448           If you have problems with IPSEC ESP packets not being routed
1449           correctly on output, try setting this option to No.
1450
1451       RESTOREFILE=filename
1452           Specifies the simple name of a file in /var/lib/shorewall to be
1453           used as the default restore script in the shorewall [-6] save,
1454           shorewall [-6] restore, shorewall [-6] forget and shorewall [6] -f
1455           start commands.
1456
1457       RETAIN_ALIASES={Yes|No}
1458           IPv4 only.
1459
1460           During shorewall start, IP addresses to be added as a consequence
1461           of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted
1462           when shorewall-nat[3](5) and shorewall-masq[4](5) are processed
1463           then are re-added later. This is done to help ensure that the
1464           addresses can be added with the specified labels but can have the
1465           undesirable side effect of causing routes to be quietly deleted.
1466           When RETAIN_ALIASES is set to Yes, existing addresses will not be
1467           deleted. Regardless of the setting of RETAIN_ALIASES, addresses
1468           added during shorewall start are still deleted at a subsequent
1469           shorewall [stop, shorewall reload or shorewall restart.
1470
1471       ROUTE_FILTER=[Yes|No|Keep]
1472           If this parameter is given the value Yes or yes then route
1473           filtering (anti-spoofing) is enabled on all network interfaces
1474           which are brought up while Shorewall is in the started state. The
1475           default value is no.
1476
1477           The value Keep causes Shorewall to ignore the option. If the option
1478           is set to Yes, then route filtering occurs on all interfaces. If
1479           the option is set to No, then route filtering is disabled on all
1480           interfaces except those specified in shorewall-interfaces[20](5).
1481
1482               Important
1483               If you need to disable route filtering on any interface, then
1484               you must set ROUTE_FILTER=No then set routefilter=1 or
1485               routefilter=2 on those interfaces where you want route
1486               filtering. See shorewall-interfaces[20](5) for additional
1487               details.
1488
1489       RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
1490           Added in Shorewall 4.5.7. Determines the disposition of packets
1491           entering from interfaces the rpfilter option (see
1492           shorewall-interfaces[20](5)). Packets disposed of by this option
1493           are those whose response packets would not be sent through the same
1494           interface receiving the packet.
1495
1496       RPFILTER_LOG_LEVEL=log-level[:log-tag]
1497           Added in shorewall 4.5.7. Determines the logging of packets
1498           disposed via the RPFILTER_DISPOSITION. The default value is info.
1499
1500       SAVE_ARPTABLES={Yes|No}
1501           Added in Shorewall 4.5.12. If SAVE_ARPTABLES=Yes, then the current
1502           arptables contents will be saved by shorewall save command and
1503           restored by shorewall restore command. Default value is No.
1504
1505       SAVE_IPSETS={Yes|No|ipv4|setlist}
1506           Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
1507           contents of your ipsets will be saved by the shorewall stop and
1508           shorewall save commands and restored by the shorewall start and
1509           shorewall restore commands.
1510
1511           Beginning with Shorewall 4.6.4, you can restrict the set of ipsets
1512           saved by specifying a setlist (a comma-separated list of ipv4 ipset
1513           names). You may also restrict the saved sets to just the ipv4 ones
1514           by specifying ipv4.
1515
1516       SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
1517           Added in Shorewall 4.4.20. Determines the disposition of packets
1518           matching the sfilter option (see shorewall-interfaces[20](5)) and
1519           of hairpin packets on interfaces without the routeback option.[26]
1520
1521       SFILTER_LOG_LEVEL=log-level[:log-tag]
1522           Added on Shorewall 4.4.20. Determines the logging of packets
1523           matching the sfilter option (see shorewall-interfaces[20](5)) and
1524           of hairpin packets on interfaces without the routeback option.[27]
1525           The default is info. If you don't wish for these packets to be
1526           logged, use SFILTER_LOG_LEVEL=none.
1527
1528       SHOREWALL_SHELL=[pathname]
1529           This option is used to specify the shell program to be used to
1530           interpret the compiled script. If not specified or specified as a
1531           null value, /bin/sh is assumed. Using a light-weight shell such as
1532           ash or dash can significantly improve performance.
1533
1534       SMURF_DISPOSITION=[DROP|A_DROP]
1535           Added in Shorewall 4.4.20. The default setting is DROP which causes
1536           smurf packets (see the nosmurfs option in
1537           shorewall-interfaces[20](5)) to be dropped. A_DROP causes the
1538           packets to be audited prior to being dropped and requires
1539           AUDIT_TARGET support in the kernel and iptables.
1540
1541       SMURF_LOG_LEVEL=[log-level[:log-tag]]
1542           Specifies the logging level for smurf packets (see the nosmurfs
1543           option in shorewall-interfaces[20](5)). If set to the empty value (
1544           SMURF_LOG_LEVEL="" ) then smurfs are not logged.
1545
1546       STARTUP_ENABLED={Yes|No}
1547           Determines if Shorewall is allowed to start. As released from
1548           shorewall.net, this option is set to No. When set to Yes or yes,
1549           Shorewall may be started. Used as a guard against Shorewall being
1550           accidentally started before it has been configured.
1551
1552       STARTUP_LOG=[pathname]
1553           If specified, determines where Shorewall will log the details of
1554           each start, reload, restart, try, and safe-* command. Logging
1555           verbosity is determined by the setting of LOG_VERBOSITY above.
1556
1557       SUBSYSLOCK=[pathname]
1558           This parameter should be set to the name of a file that the
1559           firewall should create if it starts successfully and remove when it
1560           stops. Creating and removing this file allows Shorewall to work
1561           with your distribution's initscripts. For OpenSuSE, this should be
1562           set to /var/lock/subsys/shorewall (var/lock/subsys/shorewall-lite
1563           if building for export). For Gentoo, it should be set to
1564           /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat and
1565           derivatives as well as Debian and derivatives, the pathname should
1566           be omitted.
1567
1568               Important
1569               Beginning with Shorewall 5.1.0, this setting is ignored when
1570               SERVICEDIR is non-empty in ${SHAREDIR}/shorewall/shorewallrc
1571               (usually /usr/share/shorewall/shorewallrc).
1572
1573       TC=[pathname]
1574           If specified, gives the pathname of the 'tc' executable. If not
1575           specified, 'tc' is assumed and the utility will be located using
1576           the current PATH setting.
1577
1578       TC_BITS=[number]
1579           The number of bits at the low end of the 32-bit packet mark to be
1580           used for traffic shaping marking. May be zero. See MASK_BITS above
1581           for default value.
1582
1583       TC_ENABLED=[Yes|No|Internal|Simple|Shared]
1584           If you say Yes or yes here, Shorewall will use a script that you
1585           supply to configure traffic shaping. The script must be named
1586           'tcstart' and must be placed in a directory on your CONFIG_PATH.
1587
1588           If you say No or no then traffic shaping is not enabled.
1589
1590           If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple
1591           traffic shaping using shorewall-tcinterfaces[28](5) and
1592           shorewall-tcpri[29](5) is enabled.
1593
1594           If you set TC_ENABLED=Internal or internal or leave the option
1595           empty then Shorewall will use its builtin traffic shaper
1596           (tc4shorewall written by Arne Bernin.
1597
1598           Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared.
1599           This allows you to configure the tcdevices and tcclasses in your
1600           Shorewall6 configuration yet make them available to the compiler
1601           when compiling your Shorewall configuration. In addition to setting
1602           TC_ENABLED=Shared, you need to create symbolic links from your
1603           Shorewall configuration directory (normally /etc/shorewall/) to the
1604           tcdevices and tcclasses files in your Shorewall6 configuration
1605           directory (normally /etc/shorewall6/).
1606
1607       TC_EXPERT={Yes|No}
1608           Normally, Shorewall tries to protect users from themselves by
1609           preventing PREROUTING and OUTPUT tcrules from being applied to
1610           packets that have been marked by the 'track' option in
1611           shorewall-providers[9](5).
1612
1613           If you know what you are doing, you can set TC_EXPERT=Yes and
1614           Shorewall will not include these cautionary checks.
1615
1616       TC_PRIOMAP=map
1617           Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS
1618           field to priority bands. See shorewall-tcpri[29](5). The map
1619           consists of 16 space-separated digits with values 1, 2 or 3. A
1620           value of 1 corresponds to Linux priority 0, 2 to Linux priority 1,
1621           and 3 to Linux Priority 2. The first entry gives the priority of
1622           TOS value 0, the second of TOS value 1, and so on. See tc-prio(8)
1623           for additional information.
1624
1625           The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2
1626           2".
1627
1628       TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
1629           Determines the disposition of TCP packets that fail the checks
1630           enabled by the tcpflags interface option (see
1631           shorewall-interfaces[20](5)) and must have a value of ACCEPT
1632           (accept the packet), REJECT (send an RST response) or DROP (ignore
1633           the packet). If not set or if set to the empty value (e.g.,
1634           TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is
1635           assumed.
1636
1637           A_DROP and A_REJECT are audited versions of DROP and REJECT
1638           respectively and were added in Shorewall 4.4.20. They require
1639           AUDIT_TARGET in the kernel and iptables.
1640
1641       TCP_FLAGS_LOG_LEVEL=[log-level[:log-tag]]
1642           Determines the syslog level for logging packets that fail the
1643           checks enabled by the tcpflags interface option. The value must be
1644           a valid syslogd log level. If you don't want to log these packets,
1645           set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
1646
1647       TRACK_PROVIDERS={Yes|No}
1648           Added in Shorewall 4.4.3. When set to Yes, causes the track option
1649           to be assumed on all providers defined in
1650           shorewall-providers[9](5). May be overridden on an individual
1651           provider through use of the notrack option. The default value is
1652           'No'.
1653
1654           Beginning in Shorewall 4.4.6, setting this option to 'Yes' also
1655           simplifies PREROUTING rules in shorewall-tcrules[12](5).
1656           Previously, when TC_EXPERT=No, packets arriving through 'tracked'
1657           provider interfaces were unconditionally passed to the PREROUTING
1658           tcrules. This was done so that tcrules could reset the packet mark
1659           to zero, thus allowing the packet to be routed using the 'main'
1660           routing table. Using the main table allowed dynamic routes (such as
1661           those added for VPNs) to be effective. The rtrules file was created
1662           to provide a better alternative to clearing the packet mark. As a
1663           consequence, passing these packets to PREROUTING complicates things
1664           without providing any real benefit. Beginning with Shorewall 4.4.6,
1665           when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through
1666           'tracked' interfaces will not be passed to the PREROUTING rules.
1667           Since TRACK_PROVIDERS was just introduced in 4.4.3, this change
1668           should be transparent to most, if not all, users.
1669
1670       TRACK_RULES={Yes|No|File}
1671           Added in Shorewall 4.5.20. If set to Yes, causes the compiler to
1672           add a comment to iptables rules to indicate the file name and line
1673           number of the configuration entry that generated the rule. If set
1674           to No (the default), then no such comments are added.
1675
1676           Setting this option to Yes requires the Comments capability in
1677           iptables and kernel.
1678
1679           Beginning with Shorewall 5.0.5, the option may also be set to File.
1680           That setting causes similar comments to be added to the
1681           .iptables-restore-input file, which is normally created in
1682           /var/lib/shorewall.
1683
1684       UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
1685           Added in Shorewall 4.5.13. Shorewall has traditionally passed
1686           UNTRACKED packets through the NEW section of shorewall-rules[8]
1687           (5). When a packet in UNTRACKED state fails to match any rule in
1688           the UNTRACKED section, the packet is disposed of based on this
1689           setting. The default value is CONTINUE for compatibility with
1690           earlier versions.
1691
1692       UNTRACKED_LOG_LEVEL=log-level[:log-tag]
1693           Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do
1694           not match any rule in the UNTRACKED section of shorewall-rules[8]
1695           (5) are logged at this level. The default value is empty which
1696           means no logging is performed.
1697
1698       USE_DEFAULT_RT=[Yes|No]
1699           When set to 'Yes', this option causes the Shorewall multi-ISP
1700           feature to create a set of routing rules which are resilient to
1701           changes in the main routing table. Such changes can occur for a
1702           number of reasons, VPNs going up and down being an example. The
1703           idea is to send packets through the main table prior to applying
1704           any of the Shorewall-generated routing rules. So changes to the
1705           main table will affect the routing of packets by default.
1706
1707           When USE_DEFAULT_RT=Yes:
1708
1709            1. Both the DUPLICATE and the COPY columns in providers[9](5) file
1710               must remain empty (or contain "-").
1711
1712            2. The default route is added to the the 'default' table rather
1713               than to the main table.
1714
1715            3. If running Shorewall 5.1.0 or earlier or if
1716               BALANCE_PROVIDERS=Yes (Shorewall 5.1.1 or later), then the
1717               balance provider option is assumed unless the fallback, loose,
1718               load or tproxy option is specified.
1719
1720            4. Packets are sent through the main routing table by a rule with
1721               priority 999. In shorewall-rtrules[30](5), the range 1-998 may
1722               be used for inserting rules that bypass the main table.
1723
1724            5. All provider gateways must be specified explicitly in the
1725               GATEWAY column.  detect may not be specified..if n .sp
1726                   Note
1727                   detect may be specified for interfaces whose configuration
1728                   is managed by dhcpcd. Shorewall will use dhcpcd's database
1729                   to find the interface's gateway.
1730
1731            6. You should disable all default route management outside of
1732               Shorewall. If a default route is added to the main table while
1733               Shorewall is started, then all policy routing will stop working
1734               (except for those routing rules in the priority range 1-998).
1735
1736           Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it
1737           was set to the empty string then USE_DEFAULT_RT=No was assumed.
1738           Beginning with Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes
1739           and use of USE_DEFAULT_RT=No is deprecated.
1740
1741               Warning
1742               The enable, disable and reenable commands do not work correctly
1743               when USE_DEFAULT_RT=No.
1744
1745       USE_NFLOG_SIZE=[Yes|No]
1746           Added in Shorewall 5.1.5. The second parameter to the NFLOG target
1747           specifies how many bytes of the packet to copy to the log; if
1748           omitted or if supplied as zero, the entire packet is copied. This
1749           feature has traditionally been implemented using the --nflog-range
1750           option to the NFLOG iptables target. Unfortuntely, the
1751           --nflog-range option never worked (the entire packet was always
1752           copied). To deal with this issue, the Netfilter team:
1753
1754           ·   Added a warning message when --nflog-range is used
1755
1756           ·   Added --nflog-size which works like --nflog-range was intended
1757               to work.
1758
1759           When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new
1760           --nflog-size feature. If that feature is not available in the
1761           running kernel and ip[6]tables, an error is raised.
1762
1763           When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed.
1764           When USE_NFLOG_SIZE is added by shorewall update, it is added with
1765           setting No.
1766
1767       USE_PHYSICAL_NAMES=[Yes|No]
1768           Added in Shorewall 4.4.27. Normally, when Shorewall creates a
1769           Netfilter chain that relates to an interface, it uses the
1770           interface's logical name as the base of the chain name. For
1771           example, if the logical name for an interface is OAKLAND, then the
1772           input chain for traffic arriving on that interface would be
1773           'OAKLAND_in'. If this option is set to Yes, then the physical name
1774           of the interface will be used the base of the chain name.
1775
1776       USE_RT_NAMES=[Yes|No]
1777           Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use
1778           routing table (provider) names in the generated script rather than
1779           table numbers. When set to 'No' (the default), routing table
1780           numbers will be used.
1781
1782               Caution
1783               If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you
1784               must insure that all of your providers have entries in
1785               /etc/iproute2/rt_tables as well as the following entries:
1786                   255 local
1787                   254 main
1788                   253 default
1789                   250 balance
1790                   0 unspec
1791               Without these entries, the firewall will fail to start.
1792
1793       VERBOSE_MESSAGES=[Yes|No]
1794           Added in Shorewall 5.0.9. When Yes (the default), messages produced
1795           by the ?INFO and ?WARNING directives include the filename and
1796           linenumber of the directive. When set to No, that additional
1797           information is omitted. The setting may be overridden on a
1798           directive by directive basis by following ?INFO or ?WARNING with
1799           '!' (no intervening white space).
1800
1801       VERBOSITY=[number]
1802           Shorewall has traditionally been very noisy (produced lots of
1803           output). You may set the default level of verbosity using the
1804           VERBOSITY OPTION.
1805
1806           Values are:
1807               0 - Silent. You may make it more verbose using the -v
1808                           option
1809               1 - Major progress messages displayed
1810               2 - All progress messages displayed (pre Shorewall-3.2.0
1811                           behavior)
1812           If not specified, then 2 is assumed.
1813
1814       WARNOLDCAPVERSION=[Yes|No]
1815           Added in Shorewall 4.5.12. When set to Yes (the default), the
1816           compiler issues a warning when it finds a capabilities file that
1817           doesn't specify all of the capabilities supported by the compiler.
1818           When WARNOLDCAPVERSION is set to No, no warning is issued.
1819
1820       WORKAROUNDS=[Yes|No]
1821           Added in Shorewall 4.6.11. Over time, there have been a number of
1822           changes in Shorewall that work around defects in other products
1823           such as iptables and ipset. When WORKAROUNDS=Yes, these workarounds
1824           are enabled; when WORKAROUNDS=No, they are disabled. If not
1825           specified or if specified as empty, WORKAROUNDS=Yes is assumed.
1826
1827               Warning
1828               Do not set WORKAROUNDS=Yes if you need to be able to use
1829               Shorewall-generated scripts (such as created by the save
1830               command) built by Shorewall 4.4.7 or older.
1831
1832       ZERO_MARKS=[Yes|No]
1833           Added in Shorewall 5.0.12, this is a workaround for an issue where
1834           packet marks are not zeroed by the kernel. It should be set to No
1835           (the default) unless you find that incoming packets are being
1836           mis-routed for no apparent reasons.
1837
1838               Caution
1839               Do not set this option to Yes if you have IPSEC software
1840               running on the firewall system.
1841
1842       ZONE_BITS=[number]
1843           Added in Shorewall 4.4.26. When non-zero, enables automatic packet
1844           marking by source zone and determines the number of bits in the
1845           32-bit packet mark to be used for the zone mark. Default value is
1846           0.
1847
1848       ZONE2ZONE=[2|-]
1849           Added in Shorewall 4.4.4. This option determines how Shorewall
1850           constructs chain names involving zone names and/or 'all'. Beginning
1851           with Shorewall 4.6.0, the default is '-' (e.g., fw-net); prior to
1852           that release, the default was '2' (e.g., fw2net).
1853

FILES

1855       /etc/shorewall/shorewall.conf
1856
1857       /etc/shorewall6/shorewall6.conf
1858

SEE ALSO

1860       shorewall(8)
1861

NOTES

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