1SHOREWALL.CONF(5) Configuration Files SHOREWALL.CONF(5)
2
3
4
6 shorewall.conf - Shorewall global configuration file
7
9 /etc/shorewall/shorewall.conf
10
11 /etc/shorewall6/shorewall6.conf
12
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
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
1855 /etc/shorewall/shorewall.conf
1856
1857 /etc/shorewall6/shorewall6.conf
1858
1860 shorewall(8)
1861
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)