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. 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 DONT_LOAD=[module[,module]...]
498 Causes Shorewall to not load the listed kernel modules.
499 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 Possible options are:
515 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 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 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 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 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 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 #SOURCE DEST POLICY LOG
557 # LEVEL
558 net all DROP info
559 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 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 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 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 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 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 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 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 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 Possible values for helper are:
624 · amanda
626 · ftp
628 · h323
630 · irc
632 · netbios-ns
634 · 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 · pptp
643 · sane
645 · sip
647 · snmp
649 · tftp
651 When HELPERS is specified on a system running Kernel 3.5.0 or
653 later, automatic association of helpers to connections is disabled.
654 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 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 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 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 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 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 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 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 Possible values are:
706 On or on
708 packet forwarding will be enabled.
709 Off or off
711 packet forwarding will be disabled.
712 Keep or keep
714 Shorewall will neither enable nor disable packet forwarding.
715 If this variable is not set or is given an empty value
717 (IP_FORWARD="") then IP_FORWARD=On is assumed.
718 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 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 · 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 · When [src] is specified in a destination column and when [dst]
733 is specified in a source column.
734 IPTABLES=[pathname]
736 IPv4 only.
737 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 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 IP6TABLES=[pathname]
747 IPv6 only.
748 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 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 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 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 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.
787 LOCKFILE=[pathname]
789 Specifies the name of the Shorewall[6] lock file, used to prevent
790 simultaneous state-changing commands. If not specified,
791 ${VARDIR}/shorewall[6]/lock is assumed (${VARDIR} is normally
792 /var/lib but can be changed when Shorewall-core is installed -- see
793 the output of shorewall show vardir).
794 LOG_BACKEND=[backend]
796 Added in Shorewall 4.6.4. LOG_BACKEND determines the logging
797 backend to be used for the iptrace command (see shorewall(8)[18]).
798 backend is one of:
800 LOG
802 Use standard kernel logging.
803 ULOG
805 IPv4 only.
806 Use ULOG logging to ulogd.
808 netlink
810 Use netlink logging to ulogd version 2 or later.
811 LOG_ZONE=[src|dst|both]
813 Added in Shorewall 5.2.0. When a log message is issued from a chain
814 that relates to a pair of zones (e.g, 'fw-net'), the chain name
815 normally appears in the log message (unless LOGTAGONLY=Yes and a
816 log tag is specified). This can prevent OPTIMIZE category 8 from
817 combining chains which are identical except for the names of the
818 zones involved. LOG_ZONE allows for only the source or destination
819 zone to appear in the messages by setting LOG_ZONE to src or dest
820 respectively. If LOG_ZONE=both (the default), then the full chain
821 name is included in log messages.
822 LOG_LEVEL=log-level[:log-tag]
824 Added in Shorewall 5.1.2. Beginning with that release, the sample
825 configurations use this as the default log level and changing it
826 will change all packet logging done by the configuration. In any
827 configuration file (except shorewall-params(5)[19]), $LOG_LEVEL
828 will expand to this value.
829 LOG_MARTIANS=[Yes|No|Keep]
831 IPv4 only.
832 If set to Yes or yes, sets /proc/sys/net/ipv4/conf/*/log_martians
834 to 1 with the exception of /proc/sys/net/ipv4/conf/all/log_martians
835 which is set to 0. The default value is Yes which sets both of the
836 above to one. If you do not enable martian logging for all
837 interfaces, you may still enable it for individual interfaces using
838 the logmartians interface option in shorewall-interfaces[20](5).
839 The value Keep causes Shorewall to ignore the option. If the option
841 is set to Yes, then martians are logged on all interfaces. If the
842 option is set to No, then martian logging is disabled on all
843 interfaces except those specified in shorewall-interfaces[20](5).
844 LOG_VERBOSITY=[number]
846 This option controls the amount of information logged to the file
847 specified in the STARTUP_LOG option.
848 Values are:
850 -1 - Logging is disabled
851 0 - Silent. Only error messages are logged.
852 1 - Major progress messages logged.
853 2 - All progress messages logged
854 If not specified, then -1 is assumed.
855 LOGALLNEW=[log-level]
857 This option is intended for use as a debugging aid. When set to a
858 log level, this option causes Shorewall to generate a logging rule
859 as the first rule in each builtin chain.
860 · The table name is used as the chain name in the log prefix.
862 · The chain name is used as the target in the log prefix.
864 For example, using the default LOGFORMAT, the log prefix for
866 logging from the nat table's PREROUTING chain is as follows in
867 versions prior to 5.1.0:
868 Shorewall:nat:PREROUTING
870 In Shorewall 5.1.0 and later releases, the log prefix is:
873 nat:PREROUTING
875 Important
879 To help insure that all packets in the NEW state are logged,
880 rate limiting (LOGLIMIT) should be disabled when using
881 LOGALLNEW. Use LOGALLNEW at your own risk; it may cause high
882 CPU and disk utilization and you may not be able to control
883 your firewall after you enable this option.
884 Caution
886 Do not use this option if the resulting log messages will be
887 sent to another system.
888 LOGFILE=[pathname|systemd]
890 This parameter tells the /sbin/shorewall program where to look for
891 Shorewall messages when processing the dump, logwatch, show log,
892 and hits commands. If not assigned or if assigned an empty value,
893 /var/log/messages is assumed. For further information, see
894 shorewall-logging(8)[21]. Beginning with Shorewall 5.0.10.1, you
895 may specify systemd to use journelctl -r to read the log.
896 LOGFORMAT=["formattemplate"]
898 The value of this variable generate the --log-prefix setting for
899 Shorewall logging rules. It contains a “printf” formatting template
900 which accepts three arguments (the chain name, logging rule number
901 (optional) and the disposition). To use LOGFORMAT with fireparse,
902 set it as:
903 LOGFORMAT="fp=%s:%d a=%s "
905 If the LOGFORMAT value contains the substring “%d” then the logging
907 rule number is calculated and formatted in that position; if that
908 substring is not included then the rule number is not included. If
909 not supplied or supplied as empty (LOGFORMAT="") then
910 “Shorewall:%s:%s:” is assumed.
911 Note
913 The setting of LOGFORMAT has an effect of the permitted length
914 of zone names. See shorewall-zones[16] (5).
915 Caution
917 Beginning with Shorewall 5.1.0, the default and sample
918 shorewall[6].conf files set LOGFORMAT="%s %s ".
919 Regardless of the LOGFORMAT setting, Shorewall IPv4 log
921 messages that use this LOGFORMAT can be uniquely identified
922 using the following regular expression:
923 'IN=.* OUT=.* SRC=.*\..* DST='
924 and Shorewall IPv6 log messages can be uniquely identified
925 using the following regular expression:
926 'IN=.* OUT=.* SRC=.*:.* DST='
927 To match all Netfilter log messages (Both IPv4 and IPv6 and
928 regardless of the LOGFORMAT setting), use:
929 'IN=.* OUT=.* SRC=.* DST='
930 LOGLIMIT=[[{s|d}:]rate/{sec|second|min|minute|hour|day}[:burst]]
932 Added in Shorewall 4.4.12. Limits the logging rate, either overall,
933 or by source or destination IP address.
934 If the value starts with 's:' then logging is limited per source
936 IP. If the value starts with 'd:', then logging is limited per
937 destination IP. Otherwise, the overall logging rate is limited.
938 If burst is not specified, then a value of 5 is assumed.
940 The keywords second and minute are accepted beginning with
942 Shorewall 4.6.13.
943 LOGTAGONLY=[Yes|No]
945 Using LOGFORMAT=“Shorewall:%s:%s:”, chain names may not exceed 5
946 characters or truncation of the log prefix may occur. Longer chain
947 names may be used with log tags if you set LOGTAGONLY=Yes. With
948 LOGTAGONLY=Yes, if a log tag is specified then the tag is included
949 in the log prefix in place of the chain name.
950 Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more
952 control over the generated log prefix. Beginning with that release,
953 the tag is interpreted as a chain name and a disposition separated
954 by a comma. So this rule:
955 #ACTION SOURCE DEST
957 LOG:info:foo,bar net fw
958 would generate the following log prefix when using
960 LOGFORMAT=“Shorewall:%s:%s:”:
961 Shorewall:foo:bar:
962 Similarly,
963 #ACTION SOURCE DEST
965 LOG:info:,bar net fw
966 would generate
968 Shorewall:net2fw:bar:
969 MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
971 Determines the disposition of connections requests that fail MAC
972 Verification and must have the value ACCEPT (accept the connection
973 request anyway), REJECT (reject the connection request) or DROP
974 (ignore the connection request). If not set or if set to the empty
975 value (e.g., MACLIST_DISPOSITION="") then
976 MACLIST_DISPOSITION=REJECT is assumed.
977 A_DROP and A_REJECT are audited versions of DROP and REJECT
979 respectively and were added in Shorewall 4.4.20. They require
980 AUDIT_TARGET in the kernel and ip[6]tables.
981 MACLIST_LOG_LEVEL=[log-level[:log-tag]]
983 Determines the syslog level for logging connection requests that
984 fail MAC Verification. The value must be a valid syslogd log level.
985 If you don't want to log these connection requests, set to the
986 empty value (e.g., MACLIST_LOG_LEVEL="").
987 MACLIST_TABLE=[filter|mangle]
989 Normally, MAC verification occurs in the filter table (INPUT and
990 FORWARD) chains. When forwarding a packet from an interface with
991 MAC verification to a bridge interface, that doesn't work.
992 This problem can be worked around by setting MACLIST_TABLE=mangle
994 which will cause Mac verification to occur out of the PREROUTING
995 chain. Because REJECT isn't available in that environment, you may
996 not specify MACLIST_DISPOSITION=REJECT or
997 MACLIST_DISPOSITION=A_REJECT with MACLIST_TABLE=mangle.
998 MACLIST_TTL=[number]
1000 The performance of configurations with a large numbers of entries
1001 in shorewall-maclist[22](5) can be improved by setting the
1002 MACLIST_TTL variable in shorewall[6].conf[23](5).
1003 If your iptables and kernel support the "Recent Match" (see the
1005 output of "shorewall check" near the top), you can cache the
1006 results of a 'maclist' file lookup and thus reduce the overhead
1007 associated with MAC Verification.
1008 When a new connection arrives from a 'maclist' interface, the
1010 packet passes through then list of entries for that interface in
1011 shorewall-maclist[22](5). If there is a match then the source IP
1012 address is added to the 'Recent' set for that interface. Subsequent
1013 connection attempts from that IP address occurring within
1014 $MACLIST_TTL seconds will be accepted without having to scan all of
1015 the entries. After $MACLIST_TTL from the first accepted connection
1016 request from an IP address, the next connection request from that
1017 IP address will be checked against the entire list.
1018 If MACLIST_TTL is not specified or is specified as empty (e.g,
1020 MACLIST_TTL="" or is specified as zero then 'maclist' lookups will
1021 not be cached).
1022 MANGLE_ENABLED=[Yes|No]
1024 Determines whether Shorewall will generate rules in the Netfilter
1025 mangle table. Setting MANGLE_ENABLED=No disables all Shorewall
1026 features that require the mangle table. The default is
1027 MANGLE_ENABLED=Yes.
1028 MINIUPNPD=[Yes|No]
1030 Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a
1031 chain in the nat table named MINIUPNPD-POSTROUTING and will add
1032 jumps from POSTROUTING to that chain for each interface with the
1033 upnpd option specified. Default is No.
1034 MARK_IN_FORWARD_CHAIN=[Yes|No]
1036 If your kernel has a FORWARD chain in the mangle table, you may set
1037 MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the
1038 tcrules file to occur in that chain rather than in the PREROUTING
1039 chain. This permits you to mark inbound traffic based on its
1040 destination address when DNAT is in use. To determine if your
1041 kernel has a FORWARD chain in the mangle table, use the shorewall
1042 [-6] show mangle command; if a FORWARD chain is displayed then your
1043 kernel will support this option. If this option is not specified or
1044 if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="")
1045 then MARK_IN_FORWARD_CHAIN=No is assumed.
1046 MASK_BITS=[number]
1048 Added in Shorewall 4.4.26. Number of bits on the right of the
1049 32-bit packet mark to be masked when clearing the traffic shaping
1050 mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET
1051 > 0). Prior to Shorewall 5.0.0, default value and the default
1052 values of the other mark layout options is determined as follows:
1053 Table 1. Default Packet Mark Layout
1055 WIDE_TC_MARKS=No, TC_BITS=8,
1056 HIGH_ROUTE_MARKS=No PROVIDER_BITS=8,
1057 PROVIDER_OFFSET=0,
1058 MASK_BITS=8
1059 WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8,
1060 HIGH_ROUTE_MARKS=Yes PROVIDER_OFFSET=8,
1061 MASK_BITS=8
1062 WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8,
1063 HIGH_ROUTE_MARKS=No PROVIDER_OFFSET=0,
1064 MASK_BITS=16
1065 WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8,
1066 HIGH_ROUTE_MARKS=Yes PROVIDER_OFFSET=16,
1067 MASK_BITS=16
1068 From 5.0.0 onward, the default value of MASK_BITS is 8, the default
1070 value of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is
1071 8.
1072 MODULESDIR=[[+]pathname[:pathname]...]
1074 This parameter specifies the directory/directories where your
1075 kernel netfilter modules may be found. If you leave the variable
1076 empty, Shorewall will supply the value
1077 "/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"
1078 where uname holds the output of 'uname -r' and g_family holds '4'
1079 in IPv4 configurations and '6' in IPv6 configurations.
1080 The option plus sign ('+') was added in Shorewall 5.0.3 and causes
1082 the listed pathnames to be appended to the default list above.
1083 MULTICAST=[Yes|No]
1085 IPv4 only.
1086 This option will normally be set to 'No' (the default). It should
1088 be set to 'Yes' under the following circumstances:
1089 1. You have an interface that has parallel zones defined via
1091 /etc/shorewall/hosts.
1092 2. You want to forward multicast packets to two or more of those
1094 parallel zones.
1095 In such cases, you will configure a destonly network on each zone
1097 receiving multicasts.
1098 MUTEX_TIMEOUT=[seconds]
1100 The value of this variable determines the number of seconds that
1101 programs will wait for exclusive access to the Shorewall[6] lock
1102 file. After the number of seconds corresponding to the value of
1103 this variable, programs will assume that the last program to hold
1104 the lock died without releasing the lock.
1105 If not set or set to the empty value, a value of 60 (60 seconds) is
1107 assumed.
1108 An appropriate value for this parameter would be twice the length
1110 of time that it takes your firewall system to process a shorewall
1111 [-6] restart command.
1112 NFACCT=[pathname]
1114 Added in Shorewall 4.5.7. Specifies the pathname of the nfacct
1115 utility. If not specified, Shorewall will use the PATH setting to
1116 find the program.
1117 NULL_ROUTE_RFC1918=[Yes|No|blackhole|unreachable|prohibit]
1119 IPv4 only.
1120 When set to Yes, causes Shorewall to null-route the IPv4 address
1122 ranges reserved by RFC1918. The default value is 'No'.
1123 When combined with route filtering (ROUTE_FILTER=Yes or routefilter
1125 in shorewall-interfaces[20](5)), this option ensures that packets
1126 with an RFC1918 source address are only accepted from interfaces
1127 having known routes to networks using such addresses.
1128 Beginning with Shorewall 4.5.15, you may specify blackhole,
1130 unreachable or prohibit to set the type of route to be created. See
1131 http://www.shorewall.net/MultiISP.html#null_routing[24].
1132 OPTIMIZE=[value]
1134 The specified value enables certain optimizations. Each
1135 optimization category is associated with a power of two. To enable
1136 multiple optimization categories, simply add their corresponding
1137 numbers together.
1138 Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to
1140 enable all optimization categories, and you may also specify
1141 OPTIMIZE=None to disable optimization.
1142 · Optimization category 1 - Traditionally, Shorewall has created
1144 rules for the complete matrix of host groups defined by the
1145 zones, interfaces and hosts files. Any traffic that didn't
1146 correspond to an element of that matrix was rejected in one of
1147 the built-in chains. When the matrix is sparse, this results in
1148 lots of largely useless rules.
1149 These extra rules can be eliminated by setting the 1 bit in
1151 OPTIMIZE.
1152 The 1 bit setting also controls the suppression of redundant
1154 wildcard rules (those specifying "all" in the SOURCE or DEST
1155 column). A wildcard rule is considered to be redundant when it
1156 has the same ACTION and Log Level as the applicable policy.
1157 Note
1159 Optimization level 1 is ignored when optimization level 4
1160 is also selected, since level 4 performs similar
1161 optimizations in a more robust way.
1162 · Optimization category 2 - Added in Shorewall 4.4.7. When set,
1164 suppresses superfluous ACCEPT rules in a policy chain that
1165 implements an ACCEPT policy. Any ACCEPT rules that immediately
1166 precede the final blanket ACCEPT rule in the chain are now
1167 omitted.
1168 · Optimization category 4 - Added in Shorewall 4.4.7. When set,
1170 causes short chains (those with less than 2 rules) to be
1171 optimized away. The following chains are excluded from
1172 optimization:
1173 · accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
1175 · action chains (user-defined)
1177 · 'blacklst' chain
1179 · dynamic
1181 · forwardUPnP
1183 · UPnP (nat table)
1185 Additionally:
1187 · If a built-in chain has a single rule that branches to a
1189 second chain, then the rules from the second chain are
1190 moved to the built-in chain and the target chain is
1191 omitted.
1192 · Chains with no references are deleted.
1194 · Accounting chains are subject to optimization if the
1196 OPTIMIZE_ACCOUNTING option is set to 'Yes'.
1197 · If a chain ends with an unconditional branch to a second
1199 chain (other than to 'reject'), then the branch is deleted
1200 from the first chain and the rules from the second chain
1201 are appended to it.
1202 An additional optimization was added in Shorewall 4.5.4. If the
1204 last rule in a chain is an unqualified jump to a simple target,
1205 then all immediately preceding rules with the same simple
1206 target are omitted.
1207 For example, consider this chain:
1209 -A fw-net -p udp --dport 67:68 -j ACCEPT
1211 -A fw-net -p udp --sport 1194 -j ACCEPT
1212 -A fw-net -p 41 -j ACCEPT
1213 -A fw-net -j ACCEPT
1214 Since all of the rules are jumps to the simple target ACCEPT,
1216 this chain is totally optimized away and jumps to the chain are
1217 replace with jumps to ACCEPT.
1218 · Optimization category 8 - Added in Shorewall 4.4.9. When set,
1220 causes chains with identical rules to be collapsed into a
1221 single chain.
1222 Warning
1224 While Optimization category 8 can significantly reduce the
1225 size of the generated iptables ruleset, it can also take
1226 significant system resources during compilation. If you
1227 find that compilation takes an unreasonably long time, try
1228 disabling this category by setting OPTIMIZE=23.
1229 · Optimization category 16 - Added in Shorewall 4.4.26. When set,
1231 causes sequences of compatible rules to be combined into a
1232 single rule. Rules are considered compatible if they differ
1233 only in their destination ports and comments.
1234 A sequence of compatible rules is often generated when macros
1236 are invoked in sequence.
1237 The ability to combine adjacent rules is limited by two
1239 factors:
1240 · Destination port lists may only be combined up to a maximum
1242 of 15 ports, where a port-pair counts as two ports.
1243 · Rules may only be combined until the length of their
1245 concatenated comment reaches 255 characters.
1246 When either of these limits would be exceeded, the current
1248 combined rule is emitted and the compiler attempts to combine
1249 rules beginning with the one that would have exceeded the
1250 limit. Adjacent combined comments are separated by ', '. Empty
1251 comments at the front of a group of combined comments are
1252 replaced by 'Others and'. Empty comments at the end of a group
1253 of combined comments are replaced by 'and others'.
1254 Beginning in Shorewall 4.5.10, this option also suppresses
1256 duplicate adjacent rules and duplicate non-adjacent rules that
1257 don't include mark, connmark, dscp, ecn, set, tos or u32
1258 matches.
1259 Example 1:
1261 Rules with comments "FOO", <empty> and "BAR" would result
1262 in the combined comment "FOO and others, BAR".
1263 Example 2:
1265 Rules with comments <empty>, "FOO" and "BAR" would result
1266 in the combined comment "Others and FOO, BAR". Note:
1267 Optimize level 16 requires "Extended Multi-port Match" in
1268 your iptables and kernel.
1269 In versions prior to 5.1.0, the default value is zero which
1271 disables all optimizations. Beginning with Shorewall 5.1.0, the
1272 default value is All which enables all optimizations.
1273 OPTIMIZE_ACCOUNTING=[Yes|No]
1275 Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
1276 changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not
1277 specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is
1278 assumed.
1279 PAGER=pathname
1281 Added in Shorewall 5.0.6. Specifies a path name of a pager program
1282 like less or more. When PAGER is given, the output of verbose
1283 status commands and the dump command are piped through the named
1284 program when the output file is a terminal.
1285 Beginning with Shorewall 5.0.12, the default value of this option
1287 is the DEFAULT_PAGER setting in shorewallrc.
1288 PATH=pathname[:pathname]...
1290 Determines the order in which Shorewall searches directories for
1291 executable files.
1292 PERL=pathname
1294 Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
1295 executable. Default is /usr/bin/perl. If the pathname specified by
1296 this option does not exist or the named file is not executable,
1297 then Shorewall falls back to /usr/bin/perl
1298 PERL_HASH_SEED=seed|random
1300 Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in
1301 the range 0-99999) when running the Shorewall rules compiler. If
1302 not specified, the value 0 is assumed. If random is specified, a
1303 random seed will be chosed by Perl. See perlsec(1) for additional
1304 information.
1305 PROVIDER_BITS=[number]
1307 Added in Shorewall 4.4.26. The number of bits in the 32-bit packet
1308 mark to be used for provider numbers. May be zero. See MASK_BITS
1309 above for default value.
1310 PROVIDER_OFFSET=[number]If
1312 Added in Shorewall 4.4.26. The offset from the right (low-order
1313 end) of the provider number field in the 32-bit packet mark. If
1314 non-zero, must be >= TC_BITS (Shorewall automatically adjusts
1315 PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS +
1316 ZONE_BITS must be < 32. See MASK_BITS above for default value.
1317 RCP_COMMAND="command"
1319 RSH_COMMAND="command"
1321 Earlier generations of Shorewall Lite required that remote root
1322 login via ssh be enabled in order to use the load and reload
1323 commands. Beginning with release 3.9.5, you may define an
1324 alternative means for accessing the remote firewall system. In that
1325 release, two new options were added to shorewall.conf:
1326 RSH_COMMAND
1327 RCP_COMMAND
1328 The default values for these are as follows:
1329 RSH_COMMAND: ssh ${root}@${system} ${command}
1331 RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
1332 Shell variables that will be set when the commands are invoked are
1334 as follows:
1335 root - root user. Normally root but may be overridden using the '-r' option.
1337 system - The name/IP address of the remote firewall system.
1338 command - For RSH_COMMAND, the command to be executed on the firewall system.
1339 files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
1340 destination - The directory on the remote system that the files are to be copied into.
1341 RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
1343 Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed
1344 RELATED packets that don't match any rule in the RELATED section of
1345 shorewall-rules[8] (5). Concern about the safety of this practice
1346 resulted in the addition of this option. When a packet in RELATED
1347 state fails to match any rule in the RELATED section, the packet is
1348 disposed of based on this setting. The default value is ACCEPT for
1349 compatibility with earlier versions.
1350 RELATED_LOG_LEVEL=log-level[:log-tag]
1352 Added in Shorewall 4.4.27. Packets in the related state that do not
1353 match any rule in the RELATED section of shorewall-rules[8] (5) are
1354 logged at this level. The default value is empty which means no
1355 logging is performed.
1356 REJECT_ACTION=action
1358 Added in Shorewall 4.5.21. When a REJECT target is specified,
1359 Shorewall normally handles the response as follows:
1360 · If the destination address of the packet is a broadcast or
1362 multicast address, the packet is dropped.
1363 · if the protocol is ICMP (2) then the packet is dropped.
1365 · if the protocol is TCP (6) then the packet is rejected with an
1367 RST.
1368 · if the protocol is UDP (17) then the packet is rejected with an
1370 'port-unreachable' ICMP.
1371 · if the protocol is ICMP (1) then the packet is rejected with a
1373 'host-unreachable' ICMP.
1374 · if the protocol is ICMP6 (1) then the packet is rejected with a
1376 'icmp6-addr-unreachable' ICMP6.
1377 · otherwise, the packet is rejected with a 'host-prohibited'
1379 ICMP.
1380 You can modify this behavior by implementing your own action that
1382 handles REJECT and specifying it's name in this option. The nolog
1383 and noinline options will automatically be assumed for the
1384 specified action.
1385 The following action implements the default reject action:
1387 ?format 2
1389 #TARGET SOURCE DEST PROTO
1390 Broadcast(DROP) - - -
1391 DROP - - 2
1392 INLINE - - 6 ;; -j REJECT --reject-with tcp-reset
1393 ?if __ENHANCED_REJECT
1394 INLINE - - 17 ;; -j REJECT
1395 ?if __IPV4
1396 INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable
1397 INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited
1398 ?else
1399 INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable
1400 INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited
1401 ?endif
1402 ?else
1403 INLINE - - - ;; -j REJECT
1404 ?endif
1405 RENAME_COMBINED=[Yes|No]
1407 Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8
1408 is enabled, identical chains are combined under a name beginning
1409 with '~comb' or '~blacklist'. This behavior is maintained under the
1410 default setting RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the
1411 chains are combined under the original name of one of the chains.
1412 REQUIRE_INTERFACE=[Yes|No]
1414 Added in Shorewall 4.4.10. The default is No. If set to Yes, at
1415 least one optional interface must be up in order for the firewall
1416 to be in the started state. Intended to be used with the Shorewall
1417 Init Package[25].
1418 RESTART=[restart|reload]
1420 Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added
1421 in Shorewall 5.0.0. In that release, the reload command was
1422 redefined to do what restart had done in earlier releases and
1423 restart became a true restart (equivalent to stop followed by
1424 start). When RESTART=reload, the restart command performs the same
1425 operation as the reload command making it compatible with earlier
1426 releases. If not specified, RESTART=reload is assumed.
1427 RESTORE_DEFAULT_ROUTE=[Yes|No]
1429 This option determines whether to restore the default route saved
1430 when here are 'balance' providers defined but all of them are down.
1431 The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
1433 pre-4.2.6 behavior.
1434 RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
1436 default route in the main table (USE_DEFAULT_RT=No) or in the
1437 default table (USE_DEFAULT_RT=Yes) when there are no balance
1438 providers available. In that case, RESTORE_DEFAULT_ROUTE=No will
1439 cause any default route in the relevant table to be deleted.
1440 RESTORE_ROUTEMARKS=[Yes|No]
1442 Added in Shorewall 4.5.9. When set to Yes (the default), provider
1443 marks are restored unconditionally at the top of the mangle OUTPUT
1444 and PREROUTING chains, even if the saved mark is zero. When this
1445 option is set to No, the mark is restored only if it is non-zero.
1446 If you have problems with IPSEC ESP packets not being routed
1447 correctly on output, try setting this option to No.
1448 RESTOREFILE=filename
1450 Specifies the simple name of a file in /var/lib/shorewall to be
1451 used as the default restore script in the shorewall [-6] save,
1452 shorewall [-6] restore, shorewall [-6] forget and shorewall [6] -f
1453 start commands.
1454 RETAIN_ALIASES={Yes|No}
1456 IPv4 only.
1457 During shorewall start, IP addresses to be added as a consequence
1459 of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted
1460 when shorewall-nat[3](5) and shorewall-masq[4](5) are processed
1461 then are re-added later. This is done to help ensure that the
1462 addresses can be added with the specified labels but can have the
1463 undesirable side effect of causing routes to be quietly deleted.
1464 When RETAIN_ALIASES is set to Yes, existing addresses will not be
1465 deleted. Regardless of the setting of RETAIN_ALIASES, addresses
1466 added during shorewall start are still deleted at a subsequent
1467 shorewall [stop, shorewall reload or shorewall restart.
1468 ROUTE_FILTER=[Yes|No|Keep]
1470 If this parameter is given the value Yes or yes then route
1471 filtering (anti-spoofing) is enabled on all network interfaces
1472 which are brought up while Shorewall is in the started state. The
1473 default value is no.
1474 The value Keep causes Shorewall to ignore the option. If the option
1476 is set to Yes, then route filtering occurs on all interfaces. If
1477 the option is set to No, then route filtering is disabled on all
1478 interfaces except those specified in shorewall-interfaces[20](5).
1479 Important
1481 If you need to disable route filtering on any interface, then
1482 you must set ROUTE_FILTER=No then set routefilter=1 or
1483 routefilter=2 on those interfaces where you want route
1484 filtering. See shorewall-interfaces[20](5) for additional
1485 details.
1486 RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
1488 Added in Shorewall 4.5.7. Determines the disposition of packets
1489 entering from interfaces the rpfilter option (see
1490 shorewall-interfaces[20](5)). Packets disposed of by this option
1491 are those whose response packets would not be sent through the same
1492 interface receiving the packet.
1493 RPFILTER_LOG_LEVEL=log-level[:log-tag]
1495 Added in shorewall 4.5.7. Determines the logging of packets
1496 disposed via the RPFILTER_DISPOSITION. The default value is info.
1497 SAVE_ARPTABLES={Yes|No}
1499 Added in Shorewall 4.5.12. If SAVE_ARPTABLES=Yes, then the current
1500 arptables contents will be saved by shorewall save command and
1501 restored by shorewall restore command. Default value is No.
1502 SAVE_IPSETS={Yes|No|ipv4|setlist}
1504 Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
1505 contents of your ipsets will be saved by the shorewall stop and
1506 shorewall save commands and restored by the shorewall start and
1507 shorewall restore commands.
1508 Beginning with Shorewall 4.6.4, you can restrict the set of ipsets
1510 saved by specifying a setlist (a comma-separated list of ipv4 ipset
1511 names). You may also restrict the saved sets to just the ipv4 ones
1512 by specifying ipv4.
1513 SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
1515 Added in Shorewall 4.4.20. Determines the disposition of packets
1516 matching the sfilter option (see shorewall-interfaces[20](5)) and
1517 of hairpin packets on interfaces without the routeback option.[26]
1518 SFILTER_LOG_LEVEL=log-level[:log-tag]
1520 Added on Shorewall 4.4.20. Determines the logging of packets
1521 matching the sfilter option (see shorewall-interfaces[20](5)) and
1522 of hairpin packets on interfaces without the routeback option.[27]
1523 The default is info. If you don't wish for these packets to be
1524 logged, use SFILTER_LOG_LEVEL=none.
1525 SHOREWALL_SHELL=[pathname]
1527 This option is used to specify the shell program to be used to
1528 interpret the compiled script. If not specified or specified as a
1529 null value, /bin/sh is assumed. Using a light-weight shell such as
1530 ash or dash can significantly improve performance.
1531 SMURF_DISPOSITION=[DROP|A_DROP]
1533 Added in Shorewall 4.4.20. The default setting is DROP which causes
1534 smurf packets (see the nosmurfs option in
1535 shorewall-interfaces[20](5)) to be dropped. A_DROP causes the
1536 packets to be audited prior to being dropped and requires
1537 AUDIT_TARGET support in the kernel and iptables.
1538 SMURF_LOG_LEVEL=[log-level[:log-tag]]
1540 Specifies the logging level for smurf packets (see the nosmurfs
1541 option in shorewall-interfaces[20](5)). If set to the empty value (
1542 SMURF_LOG_LEVEL="" ) then smurfs are not logged.
1543 STARTUP_ENABLED={Yes|No}
1545 Determines if Shorewall is allowed to start. As released from
1546 shorewall.net, this option is set to No. When set to Yes or yes,
1547 Shorewall may be started. Used as a guard against Shorewall being
1548 accidentally started before it has been configured.
1549 STARTUP_LOG=[pathname]
1551 If specified, determines where Shorewall will log the details of
1552 each start, reload, restart, try, and safe-* command. Logging
1553 verbosity is determined by the setting of LOG_VERBOSITY above.
1554 SUBSYSLOCK=[pathname]
1556 This parameter should be set to the name of a file that the
1557 firewall should create if it starts successfully and remove when it
1558 stops. Creating and removing this file allows Shorewall to work
1559 with your distribution's initscripts. For OpenSuSE, this should be
1560 set to /var/lock/subsys/shorewall (var/lock/subsys/shorewall-lite
1561 if building for export). For Gentoo, it should be set to
1562 /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat and
1563 derivatives as well as Debian and derivatives, the pathname should
1564 be omitted.
1565 Important
1567 Beginning with Shorewall 5.1.0, this setting is ignored when
1568 SERVICEDIR is non-empty in ${SHAREDIR}/shorewall/shorewallrc
1569 (usually /usr/share/shorewall/shorewallrc).
1570 TC=[pathname]
1572 If specified, gives the pathname of the 'tc' executable. If not
1573 specified, 'tc' is assumed and the utility will be located using
1574 the current PATH setting.
1575 TC_BITS=[number]
1577 The number of bits at the low end of the 32-bit packet mark to be
1578 used for traffic shaping marking. May be zero. See MASK_BITS above
1579 for default value.
1580 TC_ENABLED=[Yes|No|Internal|Simple|Shared]
1582 If you say Yes or yes here, Shorewall will use a script that you
1583 supply to configure traffic shaping. The script must be named
1584 'tcstart' and must be placed in a directory on your CONFIG_PATH.
1585 If you say No or no then traffic shaping is not enabled.
1587 If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple
1589 traffic shaping using shorewall-tcinterfaces[28](5) and
1590 shorewall-tcpri[29](5) is enabled.
1591 If you set TC_ENABLED=Internal or internal or leave the option
1593 empty then Shorewall will use its builtin traffic shaper
1594 (tc4shorewall written by Arne Bernin.
1595 Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared.
1597 This allows you to configure the tcdevices and tcclasses in your
1598 Shorewall6 configuration yet make them available to the compiler
1599 when compiling your Shorewall configuration. In addition to setting
1600 TC_ENABLED=Shared, you need to create symbolic links from your
1601 Shorewall configuration directory (normally /etc/shorewall/) to the
1602 tcdevices and tcclasses files in your Shorewall6 configuration
1603 directory (normally /etc/shorewall6/).
1604 TC_EXPERT={Yes|No}
1606 Normally, Shorewall tries to protect users from themselves by
1607 preventing PREROUTING and OUTPUT tcrules from being applied to
1608 packets that have been marked by the 'track' option in
1609 shorewall-providers[9](5).
1610 If you know what you are doing, you can set TC_EXPERT=Yes and
1612 Shorewall will not include these cautionary checks.
1613 TC_PRIOMAP=map
1615 Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS
1616 field to priority bands. See shorewall-tcpri[29](5). The map
1617 consists of 16 space-separated digits with values 1, 2 or 3. A
1618 value of 1 corresponds to Linux priority 0, 2 to Linux priority 1,
1619 and 3 to Linux Priority 2. The first entry gives the priority of
1620 TOS value 0, the second of TOS value 1, and so on. See tc-prio(8)
1621 for additional information.
1622 The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2
1624 2".
1625 TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
1627 Determines the disposition of TCP packets that fail the checks
1628 enabled by the tcpflags interface option (see
1629 shorewall-interfaces[20](5)) and must have a value of ACCEPT
1630 (accept the packet), REJECT (send an RST response) or DROP (ignore
1631 the packet). If not set or if set to the empty value (e.g.,
1632 TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is
1633 assumed.
1634 A_DROP and A_REJECT are audited versions of DROP and REJECT
1636 respectively and were added in Shorewall 4.4.20. They require
1637 AUDIT_TARGET in the kernel and iptables.
1638 TCP_FLAGS_LOG_LEVEL=[log-level[:log-tag]]
1640 Determines the syslog level for logging packets that fail the
1641 checks enabled by the tcpflags interface option. The value must be
1642 a valid syslogd log level. If you don't want to log these packets,
1643 set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
1644 TRACK_PROVIDERS={Yes|No}
1646 Added in Shorewall 4.4.3. When set to Yes, causes the track option
1647 to be assumed on all providers defined in
1648 shorewall-providers[9](5). May be overridden on an individual
1649 provider through use of the notrack option. The default value is
1650 'No'.
1651 Beginning in Shorewall 4.4.6, setting this option to 'Yes' also
1653 simplifies PREROUTING rules in shorewall-tcrules[12](5).
1654 Previously, when TC_EXPERT=No, packets arriving through 'tracked'
1655 provider interfaces were unconditionally passed to the PREROUTING
1656 tcrules. This was done so that tcrules could reset the packet mark
1657 to zero, thus allowing the packet to be routed using the 'main'
1658 routing table. Using the main table allowed dynamic routes (such as
1659 those added for VPNs) to be effective. The rtrules file was created
1660 to provide a better alternative to clearing the packet mark. As a
1661 consequence, passing these packets to PREROUTING complicates things
1662 without providing any real benefit. Beginning with Shorewall 4.4.6,
1663 when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through
1664 'tracked' interfaces will not be passed to the PREROUTING rules.
1665 Since TRACK_PROVIDERS was just introduced in 4.4.3, this change
1666 should be transparent to most, if not all, users.
1667 TRACK_RULES={Yes|No|File}
1669 Added in Shorewall 4.5.20. If set to Yes, causes the compiler to
1670 add a comment to iptables rules to indicate the file name and line
1671 number of the configuration entry that generated the rule. If set
1672 to No (the default), then no such comments are added.
1673 Setting this option to Yes requires the Comments capability in
1675 iptables and kernel.
1676 Beginning with Shorewall 5.0.5, the option may also be set to File.
1678 That setting causes similar comments to be added to the
1679 .iptables-restore-input file, which is normally created in
1680 /var/lib/shorewall.
1681 UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
1683 Added in Shorewall 4.5.13. Shorewall has traditionally passed
1684 UNTRACKED packets through the NEW section of shorewall-rules[8]
1685 (5). When a packet in UNTRACKED state fails to match any rule in
1686 the UNTRACKED section, the packet is disposed of based on this
1687 setting. The default value is CONTINUE for compatibility with
1688 earlier versions.
1689 UNTRACKED_LOG_LEVEL=log-level[:log-tag]
1691 Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do
1692 not match any rule in the UNTRACKED section of shorewall-rules[8]
1693 (5) are logged at this level. The default value is empty which
1694 means no logging is performed.
1695 USE_DEFAULT_RT=[Yes|No]
1697 When set to 'Yes', this option causes the Shorewall multi-ISP
1698 feature to create a set of routing rules which are resilient to
1699 changes in the main routing table. Such changes can occur for a
1700 number of reasons, VPNs going up and down being an example. The
1701 idea is to send packets through the main table prior to applying
1702 any of the Shorewall-generated routing rules. So changes to the
1703 main table will affect the routing of packets by default.
1704 When USE_DEFAULT_RT=Yes:
1706 1. Both the DUPLICATE and the COPY columns in providers[9](5) file
1708 must remain empty (or contain "-").
1709 2. The default route is added to the the 'default' table rather
1711 than to the main table.
1712 3. If running Shorewall 5.1.0 or earlier or if
1714 BALANCE_PROVIDERS=Yes (Shorewall 5.1.1 or later), then the
1715 balance provider option is assumed unless the fallback, loose,
1716 load or tproxy option is specified.
1717 4. Packets are sent through the main routing table by a rule with
1719 priority 999. In shorewall-rtrules[30](5), the range 1-998 may
1720 be used for inserting rules that bypass the main table.
1721 5. All provider gateways must be specified explicitly in the
1723 GATEWAY column. detect may not be specified..if n .sp
1724 Note
1725 detect may be specified for interfaces whose configuration
1726 is managed by dhcpcd. Shorewall will use dhcpcd's database
1727 to find the interface's gateway.
1728 6. You should disable all default route management outside of
1730 Shorewall. If a default route is added to the main table while
1731 Shorewall is started, then all policy routing will stop working
1732 (except for those routing rules in the priority range 1-998).
1733 Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it
1735 was set to the empty string then USE_DEFAULT_RT=No was assumed.
1736 Beginning with Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes
1737 and use of USE_DEFAULT_RT=No is deprecated.
1738 Warning
1740 The enable, disable and reenable commands do not work correctly
1741 when USE_DEFAULT_RT=No.
1742 USE_NFLOG_SIZE=[Yes|No]
1744 Added in Shorewall 5.1.5. The second parameter to the NFLOG target
1745 specifies how many bytes of the packet to copy to the log; if
1746 omitted or if supplied as zero, the entire packet is copied. This
1747 feature has traditionally been implemented using the --nflog-range
1748 option to the NFLOG iptables target. Unfortuntely, the
1749 --nflog-range option never worked (the entire packet was always
1750 copied). To deal with this issue, the Netfilter team:
1751 · Added a warning message when --nflog-range is used
1753 · Added --nflog-size which works like --nflog-range was intended
1755 to work.
1756 When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new
1758 --nflog-size feature. If that feature is not available in the
1759 running kernel and ip[6]tables, an error is raised.
1760 When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed.
1762 When USE_NFLOG_SIZE is added by shorewall update, it is added with
1763 setting No.
1764 USE_PHYSICAL_NAMES=[Yes|No]
1766 Added in Shorewall 4.4.27. Normally, when Shorewall creates a
1767 Netfilter chain that relates to an interface, it uses the
1768 interface's logical name as the base of the chain name. For
1769 example, if the logical name for an interface is OAKLAND, then the
1770 input chain for traffic arriving on that interface would be
1771 'OAKLAND_in'. If this option is set to Yes, then the physical name
1772 of the interface will be used the base of the chain name.
1773 USE_RT_NAMES=[Yes|No]
1775 Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use
1776 routing table (provider) names in the generated script rather than
1777 table numbers. When set to 'No' (the default), routing table
1778 numbers will be used.
1779 Caution
1781 If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you
1782 must insure that all of your providers have entries in
1783 /etc/iproute2/rt_tables as well as the following entries:
1784 255 local
1785 254 main
1786 253 default
1787 250 balance
1788 0 unspec
1789 Without these entries, the firewall will fail to start.
1790 VERBOSE_MESSAGES=[Yes|No]
1792 Added in Shorewall 5.0.9. When Yes (the default), messages produced
1793 by the ?INFO and ?WARNING directives include the filename and
1794 linenumber of the directive. When set to No, that additional
1795 information is omitted. The setting may be overridden on a
1796 directive by directive basis by following ?INFO or ?WARNING with
1797 '!' (no intervening white space).
1798 VERBOSITY=[number]
1800 Shorewall has traditionally been very noisy (produced lots of
1801 output). You may set the default level of verbosity using the
1802 VERBOSITY OPTION.
1803 Values are:
1805 0 - Silent. You may make it more verbose using the -v
1806 option
1807 1 - Major progress messages displayed
1808 2 - All progress messages displayed (pre Shorewall-3.2.0
1809 behavior)
1810 If not specified, then 2 is assumed.
1811 WARNOLDCAPVERSION=[Yes|No]
1813 Added in Shorewall 4.5.12. When set to Yes (the default), the
1814 compiler issues a warning when it finds a capabilities file that
1815 doesn't specify all of the capabilities supported by the compiler.
1816 When WARNOLDCAPVERSION is set to No, no warning is issued.
1817 WORKAROUNDS=[Yes|No]
1819 Added in Shorewall 4.6.11. Over time, there have been a number of
1820 changes in Shorewall that work around defects in other products
1821 such as iptables and ipset. When WORKAROUNDS=Yes, these workarounds
1822 are enabled; when WORKAROUNDS=No, they are disabled. If not
1823 specified or if specified as empty, WORKAROUNDS=Yes is assumed.
1824 Warning
1826 Do not set WORKAROUNDS=Yes if you need to be able to use
1827 Shorewall-generated scripts (such as created by the save
1828 command) built by Shorewall 4.4.7 or older.
1829 ZERO_MARKS=[Yes|No]
1831 Added in Shorewall 5.0.12, this is a workaround for an issue where
1832 packet marks are not zeroed by the kernel. It should be set to No
1833 (the default) unless you find that incoming packets are being
1834 mis-routed for no apparent reasons.
1835 Caution
1837 Do not set this option to Yes if you have IPSEC software
1838 running on the firewall system.
1839 ZONE_BITS=[number]
1841 Added in Shorewall 4.4.26. When non-zero, enables automatic packet
1842 marking by source zone and determines the number of bits in the
1843 32-bit packet mark to be used for the zone mark. Default value is
1844 0.
1845 ZONE2ZONE=[2|-]
1847 Added in Shorewall 4.4.4. This option determines how Shorewall
1848 constructs chain names involving zone names and/or 'all'. Beginning
1849 with Shorewall 4.6.0, the default is '-' (e.g., fw-net); prior to
1850 that release, the default was '2' (e.g., fw2net).
1851
1853 /etc/shorewall/shorewall.conf
1854 /etc/shorewall6/shorewall6.conf
1856
1858 shorewall(8)
1859
1861 1. shorewall-policy
1862 http://www.shorewall.net/manpages/shorewall-policy.html
1863 2. shorewall-accounting
1865 http://www.shorewall.net/manpages/shorewall-accounting.html
1866 3. shorewall-nat
1868 http://www.shorewall.net/manpages/shorewall-nat.html
1869 4. shorewall-masq
1871 http://www.shorewall.net/manpages/shorewall-masq.html
1872 5. shorewall-routestopped
1874 http://www.shorewall.net/manpages/shorewall-routestopped.html
1875 6. shorewall-stoppedrules
1877 http://www.shorewall.net/manpages/shorewall-stoppedrules.html
1878 7. shorewall-conntrack
1880 http://www.shorewall.net/manpages/shorewall-conntrack.html
1881 8. shorewall-rules
1883 http://www.shorewall.net/manpages/shorewall-rules.html
1884 9. shorewall-providers(5)
1886 http://www.shorewall.net/manpages/shorewall-providers.html
1887 10. shorewall-tcfilters(5)
1889 http://www.shorewall.net/manpages/shorewall-tcfilters.html
1890 11. shorewall-blrules
1892 http://www.shorewall.net/manpages/shorewall-blrules.html
1893 12. shorewall-tcrules
1895 http://www.shorewall.net/manpages/shorewall-tcrules.html
1896 13. Shorewall6
1898 http://www.shorewall.net/IPv6Support.html
1899 14. http://www.shorewall.net/Docker.html
1901 http://www.shorewall.net/Docker.html
1902 15. http://www.shorewall.net/ISO-3661.html
1904 http://www.shorewall.net/ISO-3661.html
1905 16. shorewall-zones
1907 http://www.shorewall.net/manpages/shorewall-zones.html
1908 17. shorewall-nesting
1910 http://www.shorewall.net/manpages/shorewall-nesting.html
1911 18. shorewall(8)
1913 http://www.shorewall.netmanpages/shorewall.html
1914 19. shorewall-params(5)
1916 http://www.shorewall.net/manpages/shorewall-params.html
1917 20. shorewall-interfaces
1919 http://www.shorewall.net/manpages/shorewall-interfaces.html
1920 21. shorewall-logging(8)
1922 http://www.shorewall.netshorewall-logging.html
1923 22. shorewall-maclist
1925 http://www.shorewall.net/manpages/shorewall-maclist.html
1926 23. shorewall[6].conf
1928 http://www.shorewall.net/manpages/shorewall.conf.html
1929 24. http://www.shorewall.net/MultiISP.html#null_routing
1931 http://www.shorewall.net/MultiISP.html#null_routing
1932 25. Shorewall Init Package
1934 http://www.shorewall.net/manpages/shorewall-init.html
1935 26. Hairpin packets are packets that are routed out of the same
1937 interface that they arrived on.
1938 27. Hairpin packets are packets that are routed out of the same
1940 interface that they arrived on.
1941 28. shorewall-tcinterfaces
1943 http://www.shorewall.net/manpages/shorewall-tcinterfaces.html
1944 29. shorewall-tcpri
1946 http://www.shorewall.net/manpages/shorewall-tcpri.html
1947 30. shorewall-rtrules
1949 http://www.shorewall.net/manpages/shorewall-rtrules.html
1950Configuration Files 01/17/2019 SHOREWALL.CONF(5)