More manpage updates

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4954 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-11-20 21:57:27 +00:00
parent 3c76296688
commit 0651406b1f

View File

@ -36,6 +36,53 @@
<para>The following options may be set in shorewall.conf.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">ADD_IP_ALIASES=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
<listitem>
<para>This parameter determines whether Shorewall automatically adds
the external address(es) in shorewall.nat(5). If the variable is set
to <emphasis role="bold">Yes</emphasis> or <emphasis
role="bold">yes</emphasis> then Shorewall automatically adds these
aliases. If it is set to <emphasis role="bold">No</emphasis> or
<emphasis role="bold">no</emphasis>, you must add these aliases
yourself using your distribution's network configuration
tools.</para>
<para>If this variable is not set or is given an empty value
(ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.</para>
<warning>
<para> Addresses added by ADD_IP_ALIASES=Yes are deleted and
re-added during shorewall restart. As a consequence, connections
using those addresses may be severed.</para>
</warning>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">ADD_SNAT_ALIASES=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
<listitem>
<para>This parameter determines whether Shorewall automatically adds
the SNAT ADDRESS in /etc/shorewall/masq. If the variable is set to
“Yes” or “yes” then Shorewall automatically adds these addresses. If
it is set to “No” or “no”, you must add these addresses yourself
using your distribution's network configuration tools.</para>
<para>If this variable is not set or is given an empty value
(ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.</para>
<warning>
<para>Addresses added by ADD_SNAT_ALIASES=Yes are deleted and
re-added during shorewall restart. As a consequence, connections
using those addresses may be severed.</para>
</warning>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">ADMINISABSENTMINDED=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
@ -116,6 +163,20 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">DETECT_DNAT_ADDRS=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
<listitem>
<para>If set to “Yes” or “yes”, Shorewall will detect the first IP
address of the interface to the source zone and will include this
address in DNAT rules as the original destination IP address. If set
to “No” or “no”, Shorewall will not detect this address and any
destination IP address will match the DNAT rule. If not specified or
empty, “DETECT_DNAT_ADDRS=Yes” is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">DYNAMIC_ZONES=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
@ -211,6 +272,52 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">IP_FORWARDING=</emphasis>{<emphasis
role="bold">On</emphasis>|<emphasis
role="bold">Off</emphasis>|<emphasis
role="bold">Keep</emphasis>}</term>
<listitem>
<para>This parameter determines whether Shorewall enables or
disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward).
Possible values are:</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">On</emphasis> or <emphasis
role="bold">on</emphasis></term>
<listitem>
<para>packet forwarding will be enabled.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">Off</emphasis> or <emphasis
role="bold">off</emphasis></term>
<listitem>
<para>packet forwarding will be disabled.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">Keep</emphasis> or <emphasis
role="bold">keep</emphasis></term>
<listitem>
<para>Shorewall will neither enable nor disable packet
forwarding.</para>
</listitem>
</varlistentry>
</variablelist>
<para>If this variable is not set or is given an empty value
(IP_FORWARD="") then IP_FORWARD=On is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">IPTABLES=</emphasis><emphasis>pathname</emphasis></term>
@ -223,6 +330,21 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">LOG_MARTIANS=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
<listitem>
<para>If set to Yes or yes, sets
/proc/sys/net/ipv4/conf/all/log_martians and
/proc/sys/net/ipv4/conf/default/log_martians to 1. Default is which
sets both of the above to zero. If you do not enable martian logging
for all interfaces, you may still enable it for individual
interfaces using the logmartians interface option in
shorewall-interfaces(5).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">LOGALLNEW=</emphasis><emphasis>log-level</emphasis></term>
@ -244,11 +366,11 @@
</listitem>
</itemizedlist>
<para>Example: Using the default LOGFORMAT, the log prefix for
<para>For example, using the default LOGFORMAT, the log prefix for
logging from the nat table's PREROUTING chain is:</para>
<programlisting> Shorewall:nat:PREROUTING
</programlisting>
</programlisting>
<important>
<para>There is no rate limiting on these logging rules so use
@ -264,6 +386,21 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">LOGFILE=</emphasis><emphasis>pathname</emphasis></term>
<listitem>
<para>This parameter tells the /sbin/shorewall program where to look
for Shorewall messages when processing the <emphasis
role="bold">dump</emphasis>, <emphasis
role="bold">logwatch</emphasis>, <emphasis role="bold">show
log</emphasis>, and <emphasis role="bold">hits</emphasis> commands.
If not assigned or if assigned an empty value, /var/log/messages is
assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">LOGFORMAT="</emphasis><emphasis>formatstring</emphasis><emphasis
@ -286,6 +423,45 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">LOGBURST=</emphasis><emphasis>burst</emphasis></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">LOGRATE=</emphasis><emphasis>rate</emphasis><emphasis
role="bold">/</emphasis>{<emphasis
role="bold">minute</emphasis>|<emphasis
role="bold">second</emphasis>}</term>
<listitem>
<para>These parameters set the match rate and initial burst size for
logged packets. Please see the iptables man page for a description
of the behavior of these parameters (the iptables option --limit is
set by LOGRATE and --limit-burst is set by LOGBURST). If both
parameters are set empty, no rate-limiting will occur.</para>
<para>Example:</para>
<programlisting> LOGRATE=10/minute
LOGBURST=5</programlisting>
<para>For each logging rule, the first time the rule is reached, the
packet will be logged; in fact, since the burst is 5, the first five
packets will be logged. After this, it will be 6 seconds (1 minute
divided by the rate of 10) before a message will be logged from the
rule, regardless of how many packets reach it. Also, every 6 seconds
which passes without matching a packet, one of the bursts will be
regained; if no packets hit the rule for 30 seconds, the burst will
be fully recharged; back where we started.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">MACLIST_DISPOSITION=</emphasis>{<emphasis
role="bold">ACCEPT</emphasis>|<emphasis
@ -302,6 +478,18 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">MACLIST_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
<listitem>
<para>Determines the syslog level for logging connection requests
that fail MAC Verification. The value must be a valid syslogd log
level. If you don't want to log these connection requests, set to
the empty value (e.g., MACLIST_LOG_LEVEL="").</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">MACLIST_TABLE=</emphasis>{<emphasis
role="bold">mangle</emphasis>|<emphasis
@ -371,7 +559,8 @@
</varlistentry>
<varlistentry>
<term>MODULE_SUFFIX="<emphasis role="bold">suffix</emphasis>
<term><emphasis
role="bold">MODULE_SUFFIX=</emphasis>"<emphasis>suffix</emphasis>
...<emphasis role="bold">"</emphasis></term>
<listitem>
@ -381,6 +570,34 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">MODULESDIR=</emphasis><emphasis>pathname</emphasis>[<emphasis
role="bold">:</emphasis><emphasis>pathname</emphasis>]...</term>
<listitem>
<para>This parameter specifies the directory/directories where your
kernel netfilter modules may be found. If you leave the variable
empty, Shorewall will supply the value "/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter" in versions of Shorewall prior to
3.2.4 and "/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter:/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter" in later versions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">NAT_BEFORE_RULES=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
<listitem>
<para>If set to “No” or “no”, port forwarding rules can override the
contents of the /etc/shorewall/nat file. If set to “Yes” or “yes”,
port forwarding rules cannot override one-to-one NAT. If not set or
set to an empty value, “Yes” is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">PKTTYPE=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
@ -423,6 +640,26 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">RETAIN_ALIASES=</emphasis>{<emphasis
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
<listitem>
<para>During <emphasis role="bold">shorewall star</emphasis>t, IP
addresses to be added as a consequence of ADD_IP_ALIASES=Yes and
ADD_SNAT_ALIASES=Yes are quietly deleted when shorewall-nat(5) and
shorewall-masq(5) are processed then are re-added later. This is
done to help ensure that the addresses can be added with the
specified labels but can have the undesirable side effect of causing
routes to be quietly deleted. When RETAIN_ALIASES is set to Yes,
existing addresses will not be deleted. Regardless of the setting of
RETAIN_ALIASES, addresses added during <emphasis
role="bold">shorewall start</emphasis> are still deleted at a
subsequent <emphasis role="bold">shorewall stop</emphasis> or
<emphasis role="bold">shorewall restart</emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">RFC1918_LOG_LEVEL=</emphasis><emphasis>log-level</emphasis></term>
@ -505,6 +742,20 @@
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">SUBSYSLOCK=</emphasis><emphasis>pathname</emphasis></term>
<listitem>
<para>This parameter should be set to the name of a file that the
firewall should create if it starts successfully and remove when it
stops. Creating and removing this file allows Shorewall to work with
your distribution's initscripts. For RedHat, this should be set to
/var/lock/subsys/shorewall. For Debian, the value is
/var/state/shorewall and in LEAF it is /var/run/shorwall.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">TCP_FLAGS_DISPOSITION=</emphasis>{<emphasis