1SHOREWALL.CONF(5) [FIXME: manual] SHOREWALL.CONF(5)
2
6 shorewall.conf - Shorewall global configuration file
7
9 /etc/shorewall/shorewall.conf
10
12 This file sets options that apply to Shorewall as a whole.
13 The file consists of Shell comments (lines beginning with '#'), blank
15 lines and assignment statements (variable=value). If the value contains
16 shell metacharacters or white-space, then it must be enclosed in
17 quotes. Example: MACLIST_LOG_LEVEL="NFLOG(1,0,1)".
18
20 Many options have as their value a log-level. Log levels are a method
21 of describing to syslog (8) the importance of a message and a number of
22 parameters in this file have log levels as their value.
23 These levels are defined by syslog and are used to determine the
25 destination of the messages through entries in /etc/syslog.conf (5).
26 The syslog documentation refers to these as "priorities"; Netfilter
27 calls them "levels" and Shorewall also uses that term.
28 Valid levels are:
30 7 debug
32 6 info
33 5 notice
34 4 warning
35 3 err
36 2 crit
37 1 alert
38 0 emerg
39 For most Shorewall logging, a level of 6 (info) is appropriate.
41 Shorewall log messages are generated by NetFilter and are logged using
42 facility 'kern' and the level that you specify. If you are unsure of
43 the level to choose, 6 (info) is a safe bet. You may specify levels by
44 name or by number.
45 If you have built your kernel with ULOG and/or NFLOG target support,
47 you may also specify a log level of ULOG and/or NFLOG (must be all
48 caps). Rather than log its messages to syslogd, Shorewall will direct
49 netfilter to log the messages via the ULOG or NFLOG target which will
50 send them to a process called 'ulogd'. ulogd is available with most
51 Linux distributions (although it probably isn't installed by default).
52 Ulogd is also available from
53 http://www.netfilter.org/projects/ulogd/index.html and can be
54 configured to log all Shorewall messages to their own log file.
55 Beginning with Shorewall 4.4.22, LOGMARK is also a valid level which
57 logs the packet's mark value along with the other usual information.
58 The syntax is:
59 LOGMARK[(priority)]
60 where priority is one of the levels listed in the list above. If
62 omitted, the default is info (6).
63 The following options may be set in shorewall.conf.
65 ACCEPT_DEFAULT={action|none}
67 DROP_DEFAULT={action|none}
69 NFQUEUE_DEFAULT={action|none}
71 QUEUE_DEFAULT={action|none}
73 REJECT_DEFAULT={action|none}
75 In earlier Shorewall versions, a "default action" for DROP and
76 REJECT policies was specified in the file
77 /usr/share/shorewall/actions.std.
78 To allow for default rules to be applied when USE_ACTIONS=No, the
80 DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT, QUEUE_DEFAULT and
81 NFQUEUE_DEFAULT options have been added.
82 DROP_DEFAULT describes the rules to be applied before a connection
84 request is dropped by a DROP policy; REJECT_DEFAULT describes the
85 rules to be applied if a connection request is rejected by a REJECT
86 policy. The other three are similar for ACCEPT, QUEUE and NFQUEUE
87 policies.
88 The value applied to these may be:
90 a) The name of an
91 action.
92 b) None or none
93 The default values are:
94 DROP_DEFAULT="Drop"
95 REJECT_DEFAULT="Reject"
96 ACCEPT_DEFAULT="none"
97 QUEUE_DEFAULT="none"
98 NFQUEUE_DEFAULT="None"
99 If USE_ACTIONS=Yes, then these values refer to action.Drop and
100 action.Reject respectively. If USE_ACTIONS=No, then these values
101 refer to macro.Drop and macro.Reject.
102 If you set the value of either option to "None" then no default
104 action will be used and the default action or macro must be
105 specified in shorewall-policy[1](5).
106 ACCOUNTING=[Yes|No]
108 Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is
109 enabled (see shorewall-accounting[2](5)). If not specified or set
110 to the empty value, ACCOUNTING=Yes is assumed.
111 ACCOUNTING_TABLE=[filter|mangle]
113 Added in Shorewall 4.4.20. This setting determines which Netfilter
114 table the accounting rules are added in. By default,
115 ACCOUNTING_TABLE=filter is assumed. See also
116 shorewall-accounting[2](5).
117 ADD_IP_ALIASES=[Yes|No]
119 This parameter determines whether Shorewall automatically adds the
120 external address(es) in shorewall-nat[3](5). If the variable is set
121 to Yes or yes then Shorewall automatically adds these aliases. If
122 it is set to No or no, you must add these aliases yourself using
123 your distribution's network configuration tools.
124 If this variable is not set or is given an empty value
126 (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.
127 Warning
129 Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
130 during shorewall restart. As a consequence, connections using
131 those addresses may be severed.
132 ADD_SNAT_ALIASES=[Yes|No]
134 This parameter determines whether Shorewall automatically adds the
135 SNAT ADDRESS in shorewall-masq[4](5). If the variable is set to Yes
136 or yes then Shorewall automatically adds these addresses. If it is
137 set to No or no, you must add these addresses yourself using your
138 distribution's network configuration tools.
139 If this variable is not set or is given an empty value
141 (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.
142 Warning
144 Addresses added by ADD_SNAT_ALIASES=Yes are deleted and
145 re-added during shorewall restart. As a consequence,
146 connections using those addresses may be severed.
147 ADMINISABSENTMINDED=[Yes|No]
149 The value of this variable affects Shorewall's stopped state. When
150 ADMINISABSENTMINDED=No, only traffic to/from those addresses listed
151 in shorewall-routestopped[5](5) is accepted when Shorewall is
152 stopped. When ADMINISABSENTMINDED=Yes, in addition to traffic
153 to/from addresses in shorewall-routestopped[5](5), connections that
154 were active when Shorewall stopped continue to work and all new
155 connections from the firewall system itself are allowed. If this
156 variable is not set or is given the empty value then
157 ADMINISABSENTMINDED=No is assumed.
158 AUTO_COMMENT=[Yes|No]
160 If set, if there is not a current comment when a macro is invoked,
161 the behavior is as if the first line of the macro file was "COMMENT
162 <macro name>". The AUTO_COMMENT option has a default value of
163 'Yes'.
164 The setting of the AUTOMAKE option is ignored if the start or
166 restart command includes a directory name (e.g., shorewall restart
167 /etc/shorewall.new).
168 AUTOMAKE=[Yes|No]
170 If set, the behavior of the 'start' command is changed; if no files
171 in /etc/shorewall have been changed since the last successful start
172 or restart command, then the compilation step is skipped and the
173 compiled script that executed the last start or restart command is
174 used. The default is AUTOMAKE=No.
175 BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
177 This parameter determines the disposition of packets from
178 blacklisted hosts. It may have the value DROP if the packets are to
179 be dropped or REJECT if the packets are to be replied with an ICMP
180 port unreachable reply or a TCP RST (tcp only). If you do not
181 assign a value or if you assign an empty value then DROP is
182 assumed.
183 A_DROP and A_REJECT are audited versions of DROP and REJECT
185 respectively and were added in Shorewall 4.4.20. They require
186 AUDIT_TARGET in the kernel and iptables.
187 BLACKLIST_LOGLEVEL=[log-level]
189 This parameter determines if packets from blacklisted hosts are
190 logged and it determines the syslog level that they are to be
191 logged at. Its value is a syslog level (Example:
192 BLACKLIST_LOGLEVEL=debug). If you do not assign a value or if you
193 assign an empty value then packets from blacklisted hosts are not
194 logged.
195 BLACKLISTNEWONLY={Yes|No}
197 When set to Yes or yes, blacklists are only consulted for new
198 connections. When set to No or no, blacklists are consulted for
199 every packet (will slow down your firewall noticably if you have
200 large blacklists). If the BLACKLISTNEWONLY option is not set or is
201 set to the empty value then BLACKLISTNEWONLY=No is assumed.
202 Note
204 BLACKLISTNEWONLY=No is incompatible with FASTACCEPT=Yes.
205 CLAMPMSS=[Yes|No|value]
207 This parameter enables the TCP Clamp MSS to PMTU feature of
208 Netfilter and is usually required when your internet connection is
209 through PPPoE or PPTP. If set to Yes or yes, the feature is
210 enabled. If left blank or set to No or no, the feature is not
211 enabled.
212 Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your
214 kernel.
215 You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400).
217 This will set the MSS field in TCP SYN packets going through the
218 firewall to the value that you specify.
219 CLEAR_TC=[Yes|No]
221 If this option is set to No then Shorewall won't clear the current
222 traffic control rules during [re]start. This setting is intended
223 for use by people who prefer to configure traffic shaping when the
224 network interfaces come up rather than when the firewall is
225 started. If that is what you want to do, set TC_ENABLED=Yes and
226 CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
227 way, your traffic shaping rules can still use the “fwmark”
228 classifier based on packet marking defined in
229 shorewall-tcrules[6](5). If not specified, CLEAR_TC=Yes is assumed.
230 COMPLETE=[Yes|No]
232 Added in Shorewall 4.4.12. When you set this option to Yes, you are
233 asserting that the configuration is complete so that your set of
234 zones encompasses any hosts that can send or receive traffic
235 to/from/through the firewall. This causes Shorewall to omit the
236 rules that catch packets in which the source or destination IP
237 address is outside of any of your zones. Default is No. It is
238 recommended that this option only be set to Yes if:
239 · You have defined an interface whose effective physical setting
241 is '+'.
242 · That interface is assigned to a zone.
244 · You have no CONTINUE policies or rules.
246 CONFIG_PATH=[directory[:directory]...]
248 Specifies where configuration files other than shorewall.conf may
249 be found. CONFIG_PATH is specifies as a list of directory names
250 separated by colons (":"). When looking for a configuration file
251 other than shorewall.conf:
252 · If the command is "try" or a "<configuration directory>" was
254 specified in the command (e.g., shorewall check ./gateway) then
255 the directory given in the command is searched first.
256 · Next, each directory in the CONFIG_PATH setting is searched in
258 sequence.
259 If CONFIG_PATH is not given or if it is set to the empty value then
261 the contents of /usr/share/shorewall/configpath are used. As
262 released from shorewall.net, that file sets the CONFIG_PATH to
263 /etc/shorewall:/usr/share/shorewall but your particular
264 distribution may set it differently. See the output of shorewall
265 show config for the default on your system.
266 Note that the setting in /usr/share/shorewall/configpath is always
268 used to locate shorewall.conf.
269 DELETE_THEN_ADD={Yes|No}
271 If set to Yes (the default value), entries in the
272 /etc/shorewall/route_stopped files cause an 'ip rule del' command
273 to be generated in addition to an 'ip rule add' command. Setting
274 this option to No, causes the 'ip rule del' command to be omitted.
275 DETECT_DNAT_IPADDRS=[Yes|No]
277 If set to Yes or yes, Shorewall will detect the first IP address of
278 the interface to the source zone and will include this address in
279 DNAT rules as the original destination IP address. If set to No or
280 no, Shorewall will not detect this address and any destination IP
281 address will match the DNAT rule. If not specified or empty,
282 “DETECT_DNAT_IPADDRS=Yes” is assumed.
283 DISABLE_IPV6=[Yes|No]
285 If set to Yes or yes, IPv6 traffic to, from and through the
286 firewall system is disabled. If set to No or no, Shorewall will
287 take no action with respect to allowing or disallowing IPv6
288 traffic. If not specified or empty, “DISABLE_IPV6=No” is assumed.
289 DONT_LOAD=[module[,module]...]
291 Causes Shorewall to not load the listed kernel modules.
292 DYNAMIC_BLACKLIST={Yes|No}
294 Added in Shorewall 4.4.7. When set to No or no, dynamic
295 blacklisting using the shorewall drop, shorewall reject, shorewall
296 logdrop and shorewall logreject is disabled. Default is Yes.
297 EXPAND_POLICIES={Yes|No}
299 Normally, when the SOURCE or DEST columns in shorewall-policy(5)
300 contains 'all', a single policy chain is created and the policy is
301 enforced in that chain. For example, if the policy entry is
302 #SOURCE DEST POLICY LOG
304 # LEVEL
305 net all DROP info
306 then the chain name is 'net2all' which is also the chain named in
308 Shorewall log messages generated as a result of the policy. If
309 EXPAND_POLICIES=Yes, then Shorewall will create a separate chain
310 for each pair of zones covered by the policy. This makes the
311 resulting log messages easier to interpret since the chain in the
312 messages will have a name of the form 'a2b' where 'a' is the SOURCE
313 zone and 'b' is the DEST zone.
314 EXPORTMODULES=[Yes|No]
316 Added in Shorewall 4.4.17. When set to Yes when compiling for use
317 by Shorewall Lite (shorewall load, shorewall reload or shorewall
318 export commands), the compiler will copy the modules or helpers
319 file from the administrative system into the script. When set to No
320 or not specified, the compiler will not copy the modules or helpers
321 file from /usr/share/shorewall but will copy the found in another
322 location on the CONFIG_PATH.
323 When compiling for direct use by Shorewall, causes the contents of
325 the local module or helpers file to be copied into the compiled
326 script. When set to No or not set, the compiled script reads the
327 file itself.
328 EXPORTPARAMS={Yes|No}
330 Deprecated in Shorewall 4.4.17.
331 Beginning with Shorewall 4.4.17, the variables set in the 'params'
333 file at compile time are available at run time with
334 EXPORTPARAMS=No. As a consequence, beginning with that version the
335 recommended setting is EXPORTPARAMS=No.
336 It is quite difficult to code a 'params' file that assigns other
338 than constant values such that it works correctly with Shorewall
339 Lite. The EXPORTPARAMS option works around this problem. When
340 EXPORTPARAMS=No, the 'params' file is not copied to the compiler
341 output.
342 With EXPORTPARAMS=No, if you need to set environmental variables on
344 the firewall system for use by your extension scripts, then do so
345 in the init extension script.
346 The default is EXPORTPARAMS=Yes which is the recommended setting
348 unless you are using Shorewall Lite.
349 FASTACCEPT={Yes|No}
351 Normally, Shorewall defers accepting ESTABLISHED/RELATED packets
352 until these packets reach the chain in which the original
353 connection was accepted. So for packets going from the 'loc' zone
354 to the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the
355 'loc2net' chain.
356 If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are
358 accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
359 FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or
360 RELATED sections of shorewall-rules[7](5).
361 Note
363 FASTACCEPT=Yes is incompatible with BLACKLISTNEWONLY=No.
364 FORWARD_CLEAR_MARK={Yes|No}
366 Added in Shorewall 4.4.11 Beta 3. Traditionally, Shorewall has
367 cleared the packet mark in the first rule in the mangle FORWARD
368 chain. This behavior is maintained with the default setting of this
369 option (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to
370 'No', packet marks set in the mangle PREROUTING chain are retained
371 in the FORWARD chains.
372 HIGH_ROUTE_MARKS={Yes|No}
374 Prior to version 3.2.0, it was not possible to use connection
375 marking in shorewall-tcrules[6](5) if you had a multi-ISP
376 configuration that uses the track option.
377 You may set HIGH_ROUTE_MARKS=Yes in to effectively divide the
379 packet mark and connection mark into two mark fields.
380 The width of the fields are determined by the setting of
382 WIDE_TC_MARKS. If WIDE_TC_MARKS=No (the default):
383 1. The MARK field in the providers file must have a value that is
385 less than 65536 and that is a multiple of 256 (using hex
386 representation, the values are 0x0100-0xFF00 with the low-order
387 8 bits being zero).
388 2. You may only set those mark values in the PREROUTING chain.
390 3. Marks used for traffic shaping must still be in the range of
392 1-255 and may still not be set in the PREROUTING chain.
393 When WIDE_TC_MARKS=Yes:
395 1. The MARK field in the providers file must have a value that is
397 a multiple of 65536 (using hex representation, the values are
398 0x010000-0xFF0000 with the low-order 16 bits being zero).
399 2. You may only set those mark values in the PREROUTING chain.
401 3. Marks used for traffic shaping must be in the range of 1-16383
403 and may still not be set in the PREROUTING chain.
404 Regardless of the setting of WIDE_TC_MARKS, when you SAVE or
406 RESTORE in tcrules, only the TC mark value is saved or restored.
407 Shorewall handles saving and restoring the routing (provider)
408 marks.
409 IMPLICIT_CONTINUE={Yes|No}
411 When this option is set to Yes, it causes subzones to be treated
412 differently with respect to policies.
413 Subzones are defined by following their name with ":" and a list of
415 parent zones (in shorewall-zones[8](5)). Normally, you want to have
416 a set of special rules for the subzone and if a connection doesn't
417 match any of those subzone-specific rules then you want the parent
418 zone rules and policies to be applied; see shorewall-nesting[9](5).
419 With IMPLICIT_CONTINUE=Yes, that happens automatically.
420 If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
422 subzones are not subject to this special treatment. With
423 IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be
424 overridden by including an explicit policy (one that does not
425 specify "all" in either the SOURCE or the DEST columns).
426 IP=[pathname]
428 If specified, gives the pathname of the 'ip' executable. If not
429 specified, 'ip' is assumed and the utility will be located using
430 the current PATH setting.
431 IP_FORWARDING=[On|Off|Keep]
433 This parameter determines whether Shorewall enables or disables
434 IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible
435 values are:
436 On or on
438 packet forwarding will be enabled.
439 Off or off
441 packet forwarding will be disabled.
442 Keep or keep
444 Shorewall will neither enable nor disable packet forwarding.
445 If this variable is not set or is given an empty value
448 (IP_FORWARD="") then IP_FORWARD=On is assumed.
449 IPSECFILE=zones
451 This option indicates that zone-related ipsec information is found
452 in the zones file (shorewall-zones[8](5)). The option indicates to
453 the compiler that this is not a legacy configuration where the
454 ipsec information was contained in a separate file. The value of
455 this option must not be changed and the option must not be deleted.
456 IPSET=[pathname]
458 If specified, gives the pathname of the 'ipset' executable. If not
459 specified, 'ipset' is assumed and the utility will be located using
460 the current PATH setting.
461 IPTABLES=[pathname]
463 This parameter names the iptables executable to be used by
464 Shorewall. If not specified or if specified as a null value, then
465 the iptables executable located using the PATH option is used.
466 Regardless of how the IPTABLES utility is located (specified via
468 IPTABLES= or located via PATH), Shorewall uses the iptables-restore
469 and iptables-save utilities from that same directory.
470 KEEP_RT_TABLES={Yes|No}
472 When set to Yes, this option prevents generated scripts from
473 altering the /etc/iproute2/rt_tables database when there are
474 entries in /etc/shorewall/providers. If you set this option to Yes
475 while Shorewall (Shorewall-lite) is running, you should remove the
476 file /var/lib/shorewall/rt_tables
477 (/var/lib/shorewall-lite/rt_tables) before your next stop, refresh,
478 restore on restart command.
479 The default is KEEP_RT_TABLES=No.
481 LEGACY_FASTSTART={Yes|No}
483 Added in Shorewall 4.4.20. If not specified, the default is Yes
484 which preserves the legacy behavior of start -f (the modification
485 times of the files in /etc/shorewall are compare with that of
486 /var/lib/shorewall/restore). If set to No, then the times are
487 compared with that of /var/lib/shorewall/firewall, which is
488 consistant with the way that restart -f works.
489 LOAD_HELPERS_ONLY={Yes|No}
491 Added in Shorewall 4.4.7. When set to Yes, restricts the set of
492 modules loaded by shorewall to those listed in
493 /var/lib/shorewall/helpers and those that are actually used. When
494 not set, or set to the empty value, LOAD_HELPERS_ONLY=No is
495 assumed.
496 LOG_MARTIANS=[Yes|No|Keep]
498 If set to Yes or yes, sets /proc/sys/net/ipv4/conf/*/log_martians
499 to 1 with the exception of /proc/sys/net/ipv4/conf/all/log_martians
500 which is set to 0. The default value is Yes which sets both of the
501 above to one. If you do not enable martian logging for all
502 interfaces, you may still enable it for individual interfaces using
503 the logmartians interface option in shorewall-interfaces[10](5).
504 The value Keep causes Shorewall to ignore the option. If the option
506 is set to Yes, then martians are logged on all interfaces. If the
507 option is set to No, then martian logging is disabled on all
508 interfaces except those specified in shorewall-interfaces[10](5).
509 LOG_VERBOSITY=[number]
511 This option controls the amount of information logged to the file
512 specified in the STARTUP_LOG option.
513 Values are:
515 -1 - Logging is disabled
516 0 - Silent. Only error messages are logged.
517 1 - Major progress messages logged.
518 2 - All progress messages logged
519 If not specified, then -1 is assumed.
520 LOGALLNEW=[log-level]
522 This option is intended for use as a debugging aid. When set to a
523 log level, this option causes Shorewall to generate a logging rule
524 as the first rule in each builtin chain.
525 · The table name is used as the chain name in the log prefix.
527 · The chain name is used as the target in the log prefix.
529 For example, using the default LOGFORMAT, the log prefix for
532 logging from the nat table's PREROUTING chain is:
533 Shorewall:nat:PREROUTING
535 Important
539 To help insure that all packets in the NEW state are logged,
540 rate limiting (LOGBURST and LOGRATE) should be disabled when
541 using LOGALLNEW. Use LOGALLNEW at your own risk; it may cause
542 high CPU and disk utilization and you may not be able to
543 control your firewall after you enable this option.
544 Caution
546 Do not use this option if the resulting log messages will be
547 sent to another system.
548 LOGFILE=[pathname]
550 This parameter tells the /sbin/shorewall program where to look for
551 Shorewall messages when processing the dump, logwatch, show log,
552 and hits commands. If not assigned or if assigned an empty value,
553 /var/log/messages is assumed. For further information, see
554 http://www.shorewall.net/shorewall_logging.html.
555 LOGFORMAT=["formattemplate"]
557 The value of this variable generate the --log-prefix setting for
558 Shorewall logging rules. It contains a “printf” formatting template
559 which accepts three arguments (the chain name, logging rule number
560 (optional) and the disposition). To use LOGFORMAT with fireparse,
561 set it as:
562 LOGFORMAT="fp=%s:%d a=%s "
564 If the LOGFORMAT value contains the substring “%d” then the logging
566 rule number is calculated and formatted in that position; if that
567 substring is not included then the rule number is not included. If
568 not supplied or supplied as empty (LOGFORMAT="") then
569 “Shorewall:%s:%s:” is assumed.
570 Note
572 The setting of LOGFORMAT has an effect of the permitted length
573 of zone names. See shorewall-zones[8] (5).
574 LOGLIMIT=[[{s|d}:]rate/{sec|min|hour|day}[:burst]]
576 Added in Shorewall 4.4.12. Limits the logging rate, either overall,
577 or by source or destination IP address.
578 If the value starts with 's:' then logging is limited per source
580 IP. If the value starts with 'd:', then logging is limited per
581 destination IP. Otherwise, the overall logging rate is limited.
582 If burst is not specified, then a value of 5 is assumed.
584 LOGBURST=[burst]
586 Deprecated in Shorewall 4.4.12.
587 LOGRATE=[rate/{minute|second}]
589 Deprecated in Shorewall 4.4.12. These options are ignored when
590 LOGLIMIT is specified.
591 These parameters set the match rate and initial burst size for
593 logged packets. Please see iptables(8) for a description of the
594 behavior of these parameters (the iptables option --limit is set by
595 LOGRATE and --limit-burst is set by LOGBURST). If both parameters
596 are set empty, no rate-limiting will occur. If you supply one of
597 these, then you should also supply the other.
598 Example:
600 LOGRATE=10/minute
602 LOGBURST=5
603 For each logging rule, the first time the rule is reached, the
605 packet will be logged; in fact, since the burst is 5, the first
606 five packets will be logged. After this, it will be 6 seconds (1
607 minute divided by the rate of 10) before a message will be logged
608 from the rule, regardless of how many packets reach it. Also, every
609 6 seconds, one of the bursts will be regained; if no packets hit
610 the rule for 30 seconds, the burst will be fully recharged; back
611 where we started.
612 LOGTAGONLY=[Yes|No]
614 Using the default LOGFORMAT, chain names may not exceed 11
615 characters or truncation of the log prefix may occur. Longer chain
616 names may be used with log tags if you set LOGTAGONLY=Yes. With
617 LOGTAGONLY=Yes, if a log tag is specified then the tag is included
618 in the log prefix in place of the chain name.
619 MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
621 Determines the disposition of connections requests that fail MAC
622 Verification and must have the value ACCEPT (accept the connection
623 request anyway), REJECT (reject the connection request) or DROP
624 (ignore the connection request). If not set or if set to the empty
625 value (e.g., MACLIST_DISPOSITION="") then
626 MACLIST_DISPOSITION=REJECT is assumed.
627 A_DROP and A_REJECT are audited versions of DROP and REJECT
629 respectively and were added in Shorewall 4.4.20. They require
630 AUDIT_TARGET in the kernel and iptables.
631 MACLIST_LOG_LEVEL=[log-level]
633 Determines the syslog level for logging connection requests that
634 fail MAC Verification. The value must be a valid syslogd log level.
635 If you don't want to log these connection requests, set to the
636 empty value (e.g., MACLIST_LOG_LEVEL="").
637 MACLIST_TABLE=[filter|mangle]
639 Normally, MAC verification occurs in the filter table (INPUT and
640 FORWARD) chains. When forwarding a packet from an interface with
641 MAC verification to a bridge interface, that doesn't work.
642 This problem can be worked around by setting MACLIST_TABLE=mangle
644 which will cause Mac verification to occur out of the PREROUTING
645 chain. Because REJECT isn't available in that environment, you may
646 not specify MACLIST_DISPOSITION=REJECT or
647 MACLIST_DISPOSITION=A_REJECT with MACLIST_TABLE=mangle.
648 MACLIST_TTL=[number]
650 The performance of configurations with a large numbers of entries
651 in shorewall-maclist[11](5) can be improved by setting the
652 MACLIST_TTL variable in shorewall.conf[12](5).
653 If your iptables and kernel support the "Recent Match" (see the
655 output of "shorewall check" near the top), you can cache the
656 results of a 'maclist' file lookup and thus reduce the overhead
657 associated with MAC Verification.
658 When a new connection arrives from a 'maclist' interface, the
660 packet passes through then list of entries for that interface in
661 shorewall-maclist[11](5). If there is a match then the source IP
662 address is added to the 'Recent' set for that interface. Subsequent
663 connection attempts from that IP address occurring within
664 $MACLIST_TTL seconds will be accepted without having to scan all of
665 the entries. After $MACLIST_TTL from the first accepted connection
666 request from an IP address, the next connection request from that
667 IP address will be checked against the entire list.
668 If MACLIST_TTL is not specified or is specified as empty (e.g,
670 MACLIST_TTL="" or is specified as zero then 'maclist' lookups will
671 not be cached).
672 MANGLE_ENABLED=[Yes|No]
674 Determines whether Shorewall will generate rules in the Netfilter
675 mangle table. Setting MANGLE_ENABLED=No disables all Shorewall
676 features that require the mangle table. The default is
677 MANGLE_ENABLED=Yes.
678 MAPOLDACTIONS=[Yes|No]
680 This option is included for compatibility with old Shorewall
681 configuration. New installs should always have MAPOLDACTIONS=No.
682 MARK_IN_FORWARD_CHAIN=[Yes|No]
684 If your kernel has a FORWARD chain in the mangle table, you may set
685 MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the
686 tcrules file to occur in that chain rather than in the PREROUTING
687 chain. This permits you to mark inbound traffic based on its
688 destination address when DNAT is in use. To determine if your
689 kernel has a FORWARD chain in the mangle table, use the
690 /sbin/shorewall show mangle command; if a FORWARD chain is
691 displayed then your kernel will support this option. If this option
692 is not specified or if it is given the empty value (e.g.,
693 MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
694 MODULE_SUFFIX=["extension ..."]
696 The value of this option determines the possible file extensions of
697 kernel modules. The default value is "ko ko.gz o o.gz gz".
698 MODULESDIR=[pathname[:pathname]...]
700 This parameter specifies the directory/directories where your
701 kernel netfilter modules may be found. If you leave the variable
702 empty, Shorewall will supply the value "/lib/modules/`uname
703 -r`/kernel/net/ipv4/netfilter" in versions of Shorewall prior to
704 3.2.4 and "/lib/modules/`uname
705 -r`/kernel/net/ipv4/netfilter:/lib/modules/`uname
706 -r`/kernel/net/ipv4/netfilter" in later versions.
707 MULTICAST=[Yes|No]
709 This option will normally be set to 'No' (the default). It should
710 be set to 'Yes' under the following circumstances:
711 1. You have an interface that has parallel zones defined via
713 /etc/shorewall/hosts.
714 2. You want to forward multicast packets to two or more of those
716 parallel zones.
717 In such cases, you will configure a destonly network on each zone
719 receiving multicasts.
720 MUTEX_TIMEOUT=[seconds]
722 The value of this variable determines the number of seconds that
723 programs will wait for exclusive access to the Shorewall lock file.
724 After the number of seconds corresponding to the value of this
725 variable, programs will assume that the last program to hold the
726 lock died without releasing the lock.
727 If not set or set to the empty value, a value of 60 (60 seconds) is
729 assumed.
730 An appropriate value for this parameter would be twice the length
732 of time that it takes your firewall system to process a shorewall
733 restart command.
734 NULL_ROUTE_RFC1918=[Yes|No]
736 When set to Yes, causes Shorewall to null-route the IPv4 address
737 ranges reserved by RFC1918. The default value is 'No'.
738 When combined with route filtering (ROUTE_FILTER=Yes or routefilter
740 in shorewall-interfaces[10](5)), this option ensures that packets
741 with an RFC1918 source address are only accepted from interfaces
742 having known routes to networks using such addresses.
743 OPTIMIZE=[value]
745 The specified value enables certain optimizations. Each
746 optimization category is associated with a power of two. To enable
747 multiple optimization categories, simply add their corresponding
748 numbers together.
749 · Optimization category 1 - Traditionally, Shorewall has created
751 rules for the complete matrix of host groups defined by the
752 zones, interfaces and hosts files[13]. Any traffic that didn't
753 correspond to an element of that matrix was rejected in one of
754 the built-in chains. When the matrix is sparse, this results in
755 lots of largely useless rules.
756 These extra rules can be eliminated by setting the 1 bit in
758 OPTIMIZE.
759 The 1 bit setting also controls the suppression of redundant
761 wildcard rules (those specifying "all" in the SOURCE or DEST
762 column). A wildcard rule is considered to be redundant when it
763 has the same ACTION and Log Level as the applicable policy.
764 · Optimization category 2 - Added in Shorewall 4.4.7. When set,
766 suppresses superfluous ACCEPT rules in a policy chain that
767 implements an ACCEPT policy. Any ACCEPT rules that immediately
768 preceed the final blanket ACCEPT rule in the chain are now
769 omitted.
770 · Optimization category 4 - Added in Shorewall 4.4.7. When set,
772 causes short chains (those with less than 2 rules) to be
773 optimized away. The following chains are excluded from
774 optimization:
775 · accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
777 · action chains (user-defined)
779 · 'blacklst' chain
781 · dynamic
783 · forwardUPnP
785 · UPnP (nat table)
787 Additionally:
789 · If a built-in chain has a single rule that branches to a
791 second chain, then the rules from the second chain are
792 moved to the built-in chain and the target chain is
793 omitted.
794 · Chains with no references are deleted.
796 · Accounting chains are subject to optimization if the
798 OPTIMIZE_ACCOUNTING option is set to 'Yes'.
799 · If a chain ends with an unconditional branch to a second
801 chain (other than to 'reject'), then the branch is deleted
802 from the first chain and the rules from the second chain
803 are appended to it.
804 · Optimization category 8 - Added in Shorewall 4.4.9. When set,
806 causes chains with duplicate rules to be collapsed into a
807 single chain.
808 Caution
810 Optimization category 8 adds significantly to the time
811 required to compile a large ruleset.
812 The default value is zero which disables all optimizations.
814 OPTIMIZE_ACCOUNTING=[Yes|No]
816 Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
817 changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not
818 specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is
819 assumed.
820 PATH=pathname[:pathname]...
822 Determines the order in which Shorewall searches directories for
823 executable files.
824 PERL=pathname
826 Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
827 executable. Default is /usr/bin/perl. If the pathname specified by
828 this option does not exist or the named file is not executable,
829 then Shorewall falls back to /usr/bin/perl/
830 RCP_COMMAND="command"
832 RSH_COMMAND="command"
834 Eariler generations of Shorewall Lite required that remote root
835 login via ssh be enabled in order to use the load and reload
836 commands. Beginning with release 3.9.5, you may define an
837 alternative means for accessing the remote firewall system. In that
838 release, two new options were added to shorewall.conf:.RS 4
839 RSH_COMMAND
840 RCP_COMMAND
841 The default values for these are as follows:.RS 4 RSH_COMMAND: ssh
842 ${root}@${system} ${command}
843 RCP_COMMAND: scp ${files}
844 ${root}@${system}:${destination}
845 Shell variables that will be set when the commands are envoked are as
846 follows:.RS 4 root - root user. Normally
847 root but may be overridden using the '-r'
848 option.
849 system - The name/IP address
850 of the remote firewall system.
851 command - For RSH_COMMAND,
852 the command to be executed on the firewall system.
853 files - For RCP_COMMAND, a
854 space-separated list of files to be copied to the
855 remote
856 firewall system.
857 destination - The directory
858 on the remote system that the files are to be copied
859 into.
860 REQUIRE_INTERFACE=[Yes|No]
862 Added in Shorewall 4.4.10. The default is No. If set to Yes, at
863 least one optional interface must be up in order for the firewall
864 to be in the started state. Intended to be used with the Shorewall
865 Init Package[14].
866 RESTORE_DEFAULT_ROUTE=[Yes|No]
868 This option determines whether to restore the default route saved
869 when here are 'balance' providers defined but all of them are down.
870 The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
872 pre-4.2.6 behavior.
873 RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
875 default route in the main table (USE_DEFAULT_RT=No) or in the
876 default table (USE_DEFAULT_RT=Yes) when there are no balance
877 providers available. In that case, RESTORE_DEFAULT_ROUTE=No will
878 cause any default route in the relevant table to be deleted.
879 RESTOREFILE=filename
881 Specifies the simple name of a file in /var/lib/shorewall to be
882 used as the default restore script in the shorewall save, shorewall
883 restore, shorewall forget and shorewall -f start commands.
884 RETAIN_ALIASES={Yes|No}
886 During shorewall start, IP addresses to be added as a consequence
887 of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted
888 when shorewall-nat[3](5) and shorewall-masq[4](5) are processed
889 then are re-added later. This is done to help ensure that the
890 addresses can be added with the specified labels but can have the
891 undesirable side effect of causing routes to be quietly deleted.
892 When RETAIN_ALIASES is set to Yes, existing addresses will not be
893 deleted. Regardless of the setting of RETAIN_ALIASES, addresses
894 added during shorewall start are still deleted at a subsequent
895 shorewall stop or shorewall restart.
896 ROUTE_FILTER=[Yes|No|Keep]
898 If this parameter is given the value Yes or yes then route
899 filtering (anti-spoofing) is enabled on all network interfaces
900 which are brought up while Shorewall is in the started state. The
901 default value is no.
902 The value Keep causes Shorewall to ignore the option. If the option
904 is set to Yes, then route filtering occurs on all interfaces. If
905 the option is set to No, then route filtering is disabled on all
906 interfaces except those specified in shorewall-interfaces[10](5).
907 SAVE_IPSETS={Yes|No}
909 Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
910 contents of your ipsets will be saved by the shorewall stop and
911 shorewall save commands and restored by the shorewall start and
912 shorewall restore commands.
913 SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
915 Added in Shorewall 4.4.20. Determines the disposition of packets
916 matching the filter option (see shorewall-interfaces[10](5)) and of
917 hairpin packets on interfaces without the routeback option.[15]
918 interfaces without the routeback option.
919 SFILTER_LOG_LEVEL=log-level
921 Added on Shorewall 4.4.20. Determines the logging of packets
922 matching the filter option (see shorewall-interfaces[10](5)) and of
923 hairpin packets on interfaces without the routeback option.[16]
924 interfaces without the routeback option. The default is info. If
925 you don't wish for these packets to be logged, use
926 SFILTER_LOG_LEVEL=none.
927 SHOREWALL_SHELL=[pathname]
929 This option is used to specify the shell program to be used to run
930 the Shorewall compiler and to interpret the compiled script. If not
931 specified or specified as a null value, /bin/sh is assumed. Using a
932 light-weight shell such as ash or dash can significantly improve
933 performance.
934 SMURF_DISPOSITION=[DROP|A_DROP]
936 Added in Shorewall 4.4.20. The default setting is DROP which causes
937 smurf packets (see the nosmurfs option in
938 shorewall-interfaces[10](5)) to be dropped. A_DROP causes the
939 packets to be audited prior to being dropped and requires
940 AUDIT_TARGET support in the kernel and iptables.
941 SMURF_LOG_LEVEL=[log-level]
943 Specifies the logging level for smurf packets (see the nosmurfs
944 option in shorewall-interfaces[10](5)). If set to the empty value (
945 SMURF_LOG_LEVEL="" ) then smurfs are not logged.
946 STARTUP_ENABLED={Yes|No}
948 Determines if Shorewall is allowed to start. As released from
949 shorewall.net, this option is set to No. When set to Yes or yes,
950 Shorewall may be started. Used as a guard against Shorewall being
951 accidentally started before it has been configured.
952 STARTUP_LOG=[pathname]
954 If specified, determines where Shorewall will log the details of
955 each start, restart and refresh command. Logging verbosity is
956 determined by the setting of LOG_VERBOSITY above.
957 SUBSYSLOCK=[pathname]
959 This parameter should be set to the name of a file that the
960 firewall should create if it starts successfully and remove when it
961 stops. Creating and removing this file allows Shorewall to work
962 with your distribution's initscripts. For RedHat and OpenSuSE, this
963 should be set to /var/lock/subsys/shorewall. For Debian, the value
964 is /var/lock/shorewall and in LEAF it is /var/run/shorwall.
965 TC=[pathname]
967 If specified, gives the pathname of the 'tc' executable. If not
968 specified, 'tc' is assumed and the utility will be located using
969 the current PATH setting.
970 TC_ENABLED=[Yes|No|Internal|Simple|Shared]
972 If you say Yes or yes here, Shorewall will use a script that you
973 supply to configure traffic shaping. The script must be named
974 'tcstart' and must be placed in a directory on your CONFIG_PATH.
975 If you say No or no then traffic shaping is not enabled.
977 If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple
979 traffic shaping using shorewall-tcinterfaces[17](5) and
980 shorewall-tcpri[18](5) is enabled.
981 If you set TC_ENABLED=Internal or internal or leave the option
983 empty then Shorewall will use its builtin traffic shaper
984 (tc4shorewall written by Arne Bernin.
985 Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared.
987 This allows you to configure the tcdevices and tcclasses in your
988 Shorewall6 configuration yet make them available to the compiler
989 when compiling your Shorewall configuration. In addition to setting
990 TC_ENABLED=Shared, you need to create symbolic links from your
991 Shorewall configuration directory (normally /etc/shorewall/) to the
992 tcdevices and tcclasses files in your Shorewall6 configuration
993 directory (normally /etc/shorewall6/).
994 TC_EXPERT={Yes|No}
996 Normally, Shorewall tries to protect users from themselves by
997 preventing PREROUTING and OUTPUT tcrules from being applied to
998 packets that have been marked by the 'track' option in
999 shorewall-providers[19](5).
1000 If you know what you are doing, you can set TC_EXPERT=Yes and
1002 Shorewall will not include these cautionary checks.
1003 TC_PRIOMAP=map
1005 Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS
1006 field to priority bands. See shorewall-tcpri[18](5). The map
1007 consists of 16 space-separated digits with values 1, 2 or 3. A
1008 value of 1 corresponds to Linux priority 0, 2 to Linux priority 1,
1009 and 3 to Linux Priority 2. The first entry gives the priority of
1010 TOS value 0, the second of TOS value 1, and so on. See tc-prio(8)
1011 for additional information.
1012 The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2
1014 2".
1015 TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
1017 Determines the disposition of TCP packets that fail the checks
1018 enabled by the tcpflags interface option (see
1019 shorewall-interfaces[10](5)) and must have a value of ACCEPT
1020 (accept the packet), REJECT (send an RST response) or DROP (ignore
1021 the packet). If not set or if set to the empty value (e.g.,
1022 TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is
1023 assumed.
1024 A_DROP and A_REJECT are audited versions of DROP and REJECT
1026 respectively and were added in Shorewall 4.4.20. They require
1027 AUDIT_TARGET in the kernel and iptables.
1028 TCP_FLAGS_LOG_LEVEL=[log-level]
1030 Determines the syslog level for logging packets that fail the
1031 checks enabled by the tcpflags interface option. The value must be
1032 a valid syslogd log level. If you don't want to log these packets,
1033 set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
1034 TRACK_PROVIDERS={Yes|No}
1036 Added in Shorewall 4.4.3. When set to Yes, causes the track option
1037 to be assumed on all providers defined in
1038 shorewall-providers[19](5). May be overridden on an individual
1039 provider through use of the notrack option. The default value is
1040 'No'.
1041 Beginning in Shorewall 4.4.6, setting this option to 'Yes' also
1043 simplifies PREROUTING rules in shorewall-tcrules[6](5). Previously,
1044 when TC_EXPERT=No, packets arriving through 'tracked' provider
1045 interfaces were unconditionally passed to the PREROUTING tcrules.
1046 This was done so that tcrules could reset the packet mark to zero,
1047 thus allowing the packet to be routed using the 'main' routing
1048 table. Using the main table allowed dynamic routes (such as those
1049 added for VPNs) to be effective. The route_rules file was created
1050 to provide a better alternative to clearing the packet mark. As a
1051 consequence, passing these packets to PREROUTING complicates things
1052 without providing any real benefit. Beginning with Shorewall 4.4.6,
1053 when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through
1054 'tracked' interfaces will not be passed to the PREROUTING rules.
1055 Since TRACK_PROVIDERS was just introduced in 4.4.3, this change
1056 should be transparent to most, if not all, users.
1057 USE_DEFAULT_RT=[Yes|No]
1059 When set to 'Yes', this option causes the Shorewall multi-ISP
1060 feature to create a different set of routing rules which are
1061 resilient to changes in the main routing table. Such changes can
1062 occur for a number of reasons, VPNs going up and down being an
1063 example. The idea is to send packets through the main table prior
1064 to applying any of the Shorewall-generated routing rules. So
1065 changes to the main table will affect the routing of packets by
1066 default.
1067 When USE_DEFAULT_RT=Yes:
1069 1. Both the DUPLICATE and the COPY columns in providers[19](5)
1071 file must remain empty (or contain "-").
1072 2. The default route is added to the the 'default' table rather
1074 than to the main table.
1075 3. balance is assumed unless loose is specified.
1077 4. Packets are sent through the main routing table by a rule with
1079 priority 999. In routing_rules[20](5), the range 1-998 may be
1080 used for inserting rules that bypass the main table.
1081 5. All provider gateways must be specified explicitly in the
1083 GATEWAY column. detect may not be specified..if n .sp
1084 Note
1085 detect may be specified for interfaces whose configuration
1086 is managed by dhcpcd. Shorewall will use dhcpcd's database
1087 to find the interfaces's gateway.
1088 6. You should disable all default route management outside of
1090 Shorewall. If a default route is added to the main table while
1091 Shorewall is started, then all policy routing will stop working
1092 (except for those routing rules in the priority range 1-998).
1093 If USE_DEFAULT_RT is not set or if it is set to the empty string
1095 then USE_DEFAULT_RT=No is assumed.
1096 VERBOSITY=[number]
1098 Shorewall has traditionally been very noisy (produced lots of
1099 output). You may set the default level of verbosity using the
1100 VERBOSITY OPTION.
1101 Values are:
1103 0 - Silent. You may make it more verbose using the -v
1104 option
1105 1 - Major progress messages displayed
1106 2 - All progress messages displayed (pre Shorewall-3.2.0
1107 behavior)
1108 If not specified, then 2 is assumed.
1109 WIDE_TC_MARKS={Yes|No}
1111 When set to No (the default), traffic shaping marks are 8 bytes
1112 wide (possible values are 1-255). When WIDE_TC_MARKS=Yes, traffic
1113 shaping marks are 14 bytes wide (values 1-16383). The setting of
1114 WIDE_TC_MARKS also has an effect on the HIGH_ROUTE_MARKS option
1115 (see above).
1116 ZONE2ZONE={2|-}
1118 Added in Shorewall 4.4.4. This option determines how Shorewall
1119 constructs chain names involving zone names and/or 'all'. The
1120 default is '2' (e.g., fw2net).
1121
1123 /etc/shorewall/shorewall.conf
1124
1126 shorewall(8), shorewall-accounting(5), shorewall-actions(5),
1127 shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
1128 shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
1129 shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
1130 shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
1131 shorewall-route_rules(5), shorewall-routestopped(5),
1132 shorewall-rules(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
1133 shorewall-tcinterfaces(5), shorewall-tcpri(5), shorewall-tcrules(5),
1134 shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
1135
1137 1. shorewall-policy
1138 http://www.shorewall.net/manpages/shorewall-policy.html
1139 2. shorewall-accounting
1141 http://www.shorewall.net/manpages/shorewall-accounting.html
1142 3. shorewall-nat
1144 http://www.shorewall.net/manpages/shorewall-nat.html
1145 4. shorewall-masq
1147 http://www.shorewall.net/manpages/shorewall-masq.html
1148 5. shorewall-routestopped
1150 http://www.shorewall.net/manpages/shorewall-routestopped.html
1151 6. shorewall-tcrules
1153 http://www.shorewall.net/manpages/shorewall-tcrules.html
1154 7. shorewall-rules
1156 http://www.shorewall.net/manpages/shorewall-rules.html
1157 8. shorewall-zones
1159 http://www.shorewall.net/manpages/shorewall-zones.html
1160 9. shorewall-nesting
1162 http://www.shorewall.net/manpages/shorewall-nesting.html
1163 10. shorewall-interfaces
1165 http://www.shorewall.net/manpages/shorewall-interfaces.html
1166 11. shorewall-maclist
1168 http://www.shorewall.net/manpages/shorewall-maclist.html
1169 12. shorewall.conf
1171 http://www.shorewall.net/manpages/shorewall.conf.html
1172 13. the complete matrix of host groups defined by the zones, interfaces
1174 and hosts files
1175 http://www.shorewall.net/manpages/../ScalabilityAndPerformance.html
1176 14. Shorewall Init Package
1178 http://www.shorewall.net/manpages/shorewall-init.html
1179 15. Hairpin packets are packets that are routed out of the same
1181 interface that they arrived on.
1182 16. Hairpin packets are packets that are routed out of the same
1184 interface that they arrived on.
1185 17. shorewall-tcinterfaces
1187 http://www.shorewall.net/manpages/shorewall-tcinterfaces.html
1188 18. shorewall-tcpri
1190 http://www.shorewall.net/manpages/shorewall-tcpri.html
1191 19. shorewall-providers
1193 http://www.shorewall.net/manpages/shorewall-providers.html
1194 20. routing_rules
1196 http://www.shorewall.net/manpages/shorewall-routing_rules.html
1197[FIXME: source] 09/16/2011 SHOREWALL.CONF(5)