Minor document updates

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

docs/MultiISP.xml

@@ -15,7 +15,7 @@
       </author>
     </authorgroup>
 
-    <pubdate>2006-03-27</pubdate>
+    <pubdate>2006-04-02</pubdate>
 
     <copyright>
       <year>2005</year>
@@ -392,18 +392,71 @@
         permanently alter your firewall/gateway's routing; that is, the effect
         of these changes is not reversed by <command>shorewall stop</command>
         or <command>shorewall clear</command>. To restore routing to its
-        original state, you will have to restart your network. This can
+        original state, you may have to restart your network. This can usually
-        usually be done by <command>/etc/init.d/network restart</command> or
+        be done by <command>/etc/init.d/network restart</command> or
         <command>/etc/init.d/networking restart</command>. Check your
         distribution's networking documentation.</para>
 
-        <para>You can mitigate the effect of the Shorewall-generated changes
+        <para>Here are some additional things to consider:</para>
-        to your routing table by specifying a <emphasis>metric</emphasis> for
+
-        each default route that you configure. Shorewall will generate a
+        <itemizedlist>
-        load-balancing default route (assuming that <emphasis
+          <listitem>
-        role="bold">balance</emphasis> has been specified for some of the
+            <para>You can mitigate the effect of the Shorewall-generated
-        providers) that does not include a metric and that will therefore not
+            changes to your routing table by specifying a
-        replace any existing route that has a non-zero metric.</para>
+            <emphasis>metric</emphasis> for each default route that you
+            configure. Shorewall will generate a load-balancing default route
+            (assuming that <emphasis role="bold">balance</emphasis> has been
+            specified for some of the providers) that does not include a
+            metric and that will therefore not replace any existing route that
+            has a non-zero metric.</para>
+          </listitem>
+
+          <listitem>
+            <para>The <command>-n</command> option to <command>shorewall
+            restart</command> and <command>shorewall restore</command> can be
+            used to prevent the command from changing your routing.</para>
+          </listitem>
+
+          <listitem>
+            <para>The <filename>/etc/shorewall/stopped</filename> file can
+            also be used to restore routing when you stop Shorewall. With your
+            firewall in it's normal (single-table) routing configuration, you
+            can capture the contents as follows:</para>
+
+            <programlisting>ip route ls &gt; routes</programlisting>
+
+            <para>Here's what the <filename>routes</filename> file looked like
+            after I did that on my firewall:</para>
+
+            <programlisting>192.168.1.1 dev eth3  scope link
+206.124.146.177 dev eth1  scope link
+192.168.2.2 dev tun0  proto kernel  scope link  src 192.168.2.1
+192.168.2.0/24 via 192.168.2.2 dev tun0
+192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.254
+206.124.146.0/24 dev eth3  proto kernel  scope link  src 206.124.146.176
+169.254.0.0/16 dev eth0  scope link
+127.0.0.0/8 dev lo  scope link
+default via 206.124.146.254 dev eth3</programlisting>
+
+            <para>Now edit the file as shown below:</para>
+
+            <programlisting><command>ip route flush table main
+ip route add</command> 192.168.1.1 dev eth3  scope link
+<command>ip route add </command>206.124.146.177 dev eth1  scope link
+<command>ip route add </command>192.168.2.2 dev tun0  proto kernel  scope link  src 192.168.2.1
+<command>ip route add </command>192.168.2.0/24 via 192.168.2.2 dev tun0
+<command>ip route add </command>192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.254
+<command>ip route add </command>206.124.146.0/24 dev eth3  proto kernel  scope link  src 206.124.146.176
+<command>ip route add </command>169.254.0.0/16 dev eth0  scope link
+<command>ip route add </command>127.0.0.0/8 dev lo  scope link
+<command>ip route add </command>default via 206.124.146.254 dev eth3
+<command>ip route flush cache</command>
+</programlisting>
+
+            <para>Now paste the contents of that file into
+            <filename>/etc/shorewall/stopped</filename>.</para>
+          </listitem>
+        </itemizedlist>
       </warning>
     </section>
 

docs/XenMyWay.xml

@@ -15,7 +15,7 @@
       </author>
     </authorgroup>
 
-    <pubdate>2006-03-26</pubdate>
+    <pubdate>2006-04-10</pubdate>
 
     <copyright>
       <year>2006</year>
@@ -78,8 +78,9 @@
 
     <orderedlist>
       <listitem>
-        <para>Combination Firewall/Public Server/Private Server using Xen
+        <para>Combination Firewall/Public Server/Private Server/Wireless
-        (created by building out my Linux desktop system).</para>
+        Gateway using Xen (created by building out my Linux desktop
+        system).</para>
       </listitem>
 
       <listitem>
@@ -126,17 +127,37 @@
       </listitem>
     </itemizedlist>
 
-    <para>There are four Xen domains. Dom0 (ursa.shorewall.net) is used as a
+    <para>There are four Xen domains.</para>
-    file server (NFS and Samba). The first DomU (Dom name <emphasis
+
+    <orderedlist>
+      <listitem>
+        <para>Dom0 (ursa.shorewall.net) is used as a local file server (NFS
+        and Samba).</para>
+      </listitem>
+
+      <listitem>
+        <para>The first DomU (Dom name <emphasis
         role="bold">firewall</emphasis>, gateway.shorewall.net) is used as our
-    main firewall; the second DomU (Dom name <emphasis
+        main firewall.</para>
+      </listitem>
+
+      <listitem>
+        <para>The second DomU (Dom name <emphasis
         role="bold">lists</emphasis>, lists.shorewall.net) is used as a public
-    Web/FTP/Mail/DNS server while the third DomU (Dom name <emphasis
+        Web/FTP/Mail/DNS server.</para>
+      </listitem>
+
+      <listitem>
+        <para>The third DomU (Dom name <emphasis
         role="bold">wireless</emphasis>, wireless.shorewall.net) is used as a
-    gateway to our wireless network. A seperate wireless gateway is necessary
+        gateway to our wireless network.</para>
-    because Xen 3 only supports three virtual interfaces per DomU and the
+      </listitem>
-    firewall DomU already has three interfaces. Shorewall runs in Dom0, in the
+    </orderedlist>
-    firewall domain and in the wireless gateway.</para>
+
+    <para>A seperate wireless gateway is necessary because Xen 3.0 only
+    supports three virtual interfaces per DomU and the firewall DomU already
+    has three interfaces. Shorewall runs in Dom0, in the firewall domain and
+    in the wireless gateway.</para>
 
     <section id="Domains">
       <title>Domain Configuration</title>
@@ -250,10 +271,13 @@ disk     = [ 'phy:hdb4,hdb4,w' ]</programlisting>
       <para>The zones correspond to the Shorewall zones in the Dom0
       configuration.</para>
 
-      <para>SuSE 10.0 includes Xen 3.0 which does not support PCI delegation;
+      <para>SuSE 10.0 includes Xen 3.0 which does not support PCI
-      I therefore use a bridged configuration with four bridges (one for each
+      delegation<footnote>
-      network interface). When Shorewall starts during bootup of Dom0, it
+          <para>PCI delegation was a feature of Xen 2.0 but that capability
-      creates the four bridges using this
+          was dropped in 3.0. It has been restore in Xen 3.0.2.</para>
+        </footnote>; I therefore use a bridged configuration with four bridges
+      (one for each network interface). When Shorewall starts during bootup of
+      Dom0, it creates the four bridges using this
       <filename>/etc/shorewall/init</filename> extension script:</para>
 
       <blockquote>
@@ -367,7 +391,9 @@ SECTION NEW
       <para>The two laptops can be directly attached to the LAN as shown above
       or they can be attached wirelessly through the <link
       linkend="Wireless">wireless gateway</link> -- their IP addresses are the
-      same in either case.</para>
+      same in either case; when they are directly attached, the IP address is
+      assigned by the DHCP server running on the firewall and when they are
+      attached wirelessly, the IP address is assigned by OpenVPN.</para>
 
       <para>The Shorewall configuration files are shown below. All routing and
       secondary IP addresses are handled in the SuSE network