Add a qualification to FAQ 30

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4586 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb

docs/Actions.xml

@@ -74,8 +74,8 @@
         class="directory">/usr/share/shorewall</filename>. Each
         <filename>action.*</filename> file has a comment at the beginning of
         the file that describes what the action does. As an example, here is
-        the definition of the <firstterm>AllowSMB</firstterm> standard
-        action.</para>
+        the definition of the <firstterm>AllowSMB</firstterm> standard action
+        from Shorewall version 2.2.</para>
 
         <programlisting>#
 # Shorewall 2.2 /usr/share/shorewall/action.AllowSMB
@@ -96,6 +96,10 @@ ACCEPT   -              -               tcp     135,139,445
         the definition in /usr/share/shorewall. Rather, copy the file to
         <filename class="directory">/etc/shorewall</filename> (or somewhere
         else on your CONFIG_PATH) and modify the copy.</para>
+
+        <para>Standard Actions have been largely replaced by <ulink
+        url="Macros.html">macros</ulink> in Shorewall 3.0 and later major
+        versions.</para>
       </listitem>
 
       <listitem>

docs/Documentation.xml

@@ -3699,6 +3699,35 @@ LOGBURST=5</programlisting>
   <section id="TOS" xreflabel="/etc/shorewall/tos">
     <title>/etc/shorewall/tos Configuration</title>
 
+    <warning>
+      <para>This Shorewall feature is somewhat broken -- while it shouldn't
+      hurt anything to use it, it may not do what you want either.</para>
+
+      <para>In versions of Shorewall prior to 3.2.4, it is only safe to
+      specify "all" in the SOURCE and DEST columns. In 3.2.4 and later
+      versions:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para>It continues to work fine if you specify "all" in both the
+          SOURCE and DEST columns.</para>
+        </listitem>
+
+        <listitem>
+          <para>It mostly works when you specify zone names in either column
+          (provided that you have Mangle table FORWARD chain support in your
+          kernel) but it doesn't work with dynamic zones and it doesn't work
+          with IPSEC zones.</para>
+        </listitem>
+
+        <listitem>
+          <para>If you specify a zone name together with an address in the
+          SOURCE or DEST column, the generated rule ignores the zone name and
+          simply matches on the source or destination address.</para>
+        </listitem>
+      </itemizedlist>
+    </warning>
+
     <para>The <filename>/etc/shorewall/tos</filename> file allows you to set
     the Type of Service field in packet headers based on packet source, packet
     destination, protocol, source port and destination port. In order for this
@@ -3728,9 +3757,8 @@ LOGBURST=5</programlisting>
         <listitem>
           <para>The destination zone. May be qualified by following the zone
           name with a colon (<quote>:</quote>) and either an IP address or an
-          IP subnet. Because packets are marked prior to routing, you may not
-          specify the name of an interface. This column may also contain
-          <quote>all</quote> to indicate any destination.</para>
+          IP subnet. This column may also contain <quote>all</quote> to
+          indicate any destination.</para>
         </listitem>
       </varlistentry>
 

docs/FAQ.xml

@@ -342,9 +342,11 @@ DNAT    net     fw:192.168.1.1:22       tcp     4104</programlisting>
       to go the opposite direction from SNAT/MASQUERADE. So if you masquerade
       or use SNAT from your local network to the internet then you will need
       to use DNAT rules to allow connections from the internet to your local
-      network. In all other cases, you use ACCEPT unless you need to hijack
-      connections as they go through your firewall and handle them on the
-      firewall box itself; in that case, you use a REDIRECT rule.</para>
+      network. You also want to use DNAT rules when you intentionally want to
+      rewrite the destination IP address or port number. In all other cases,
+      you use ACCEPT unless you need to hijack connections as they go through
+      your firewall and handle them on the firewall box itself; in that case,
+      you use a REDIRECT rule.</para>
     </section>
 
     <section>