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