~ubuntu-branches/ubuntu/precise/shorewall6/precise

« back to all changes in this revision

Viewing changes to configfiles/shorewall6.conf.annotated

  • Committer: Bazaar Package Importer
  • Author(s): Roberto C. Sanchez
  • Date: 2011-06-07 20:42:53 UTC
  • mfrom: (1.3.21 upstream)
  • Revision ID: james.westby@ubuntu.com-20110607204253-shuyx4o2yvc7v9my
Tags: 4.4.20.1-1
* New Upstream Version
* New debconf translation, Brazilian Portugese, thanks to Eder L. Marques
  (Closes: #629115)

Show diffs side-by-side

added added

removed removed

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