holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Bring 4.4.6 Lenny->Squeeze in sync with the 4.5.3 version

Browse Source 
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
Tom Eastep 2010-01-06 09:09:36 -08:00
parent 83c2473d78
commit bbce309791
1 changed files with 18 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
docs/LennyToSqueeze.xml
View File

@ -354,7 +354,7 @@
<term>SAVE_IPSETS</term> <term>SAVE_IPSETS</term>
<listitem> <listitem>
<para>Shorewall 4.4 will issue a warning if you set <para>Shorewall 4.4.0-4.4.5 will issue a warning if you set
SAVE_IPSETS=Yes in <filename>shorewall.conf</filename>:</para> SAVE_IPSETS=Yes in <filename>shorewall.conf</filename>:</para>
<para><emphasis role="bold">WARNING SAVE_IPSETS=Yes is not <para><emphasis role="bold">WARNING SAVE_IPSETS=Yes is not
@ -896,57 +896,32 @@ insert_rule $filter_table-&gt;{OUTPUT}, 1, "-p udp --sport 1701 -j ACCEPT";
Shorewall configuration file, the name must be preceded by a plus sign Shorewall configuration file, the name must be preceded by a plus sign
(+) as with the shell-based compiler.</para> (+) as with the shell-based compiler.</para>
<para>Shorewall 4.4 is out of the ipset load/reload business with the <para>Shorewall 4.4.6 re-introduced SAVE_IPSETS=Yes with slightly
exception of ipsets used for dynamic zones. With scripts generated by different semantics:</para>
Shorwall 4.4, the Netfilter rule set is never cleared. That means that
there is no opportunity for Shorewall to load/reload your ipsets since
that cannot be done while there are any current rules using
ipsets.</para>
<para>So:</para> <itemizedlist>
<orderedlist numeration="upperroman">
<listitem> <listitem>
<para>Your ipsets must be loaded before Shorewall starts. You are <para>The contents of the ipsets are saved during processing of the
free to try to do that with the following code in <command>stop</command> command in addition to during processing of
<filename>/etc/shorewall/init (it works for me; your mileage may the <command>save</command> command.</para>
vary)</filename>:</para>
<programlisting>if [ "$COMMAND" = start ]; then
ipset -U :all: :all:
ipset -U :all: :default:
ipset -F
ipset -X
ipset -R &lt; /etc/shorewall/ipsets
fi</programlisting>
<para>The file <filename>/etc/shorewall/ipsets</filename> will
normally be produced using the <command>ipset -S</command> command.
I have this in my<filename> /etc/shorewall/stop</filename>
file:</para>
<programlisting>if ipset -S &gt; /etc/shorewall/ipsets.tmp; then
mv -f /etc/shorewall/ipsets /etc/shorewall/ipsets.bak
mv /etc/shorewall/ipsets.tmp /etc/shorewall/ipsets
fi</programlisting>
<para>The above extension scripts will work most of the time but
will fail in a <command>shorewall stop</command> -
<command>shorewall start</command> sequence if you use ipsets in
your routestopped file (see <link
linkend="routestopped">below</link>).</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Your ipsets may not be reloaded until Shorewall is stopped or <para>The contents of the ipsets are restored during processing of
cleared.</para> the <command>start</command> command in addition to during
processing of the <command>restore</command> command. When
<command>restore</command> is being run when Shorewall is not in the
stopped state (such as when it is run to recover from a failed
<command>start</command>, <command>restart</command> or
<command>refresh</command>) ipsets are not restored.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>If you specify ipsets in your routestopped file then Shorewall <para>Specifying an ipset in <ulink
must be cleared in order to reload your ipsets.</para> url="manpages/shorewall-routestopped.html">shorewall-routestopped
</ulink>(5) is prohibited when SAVE_IPSETS=Yes.</para>
</listitem> </listitem>
</orderedlist> </itemizedlist>
</section> </section>
</section> </section>