diff --git a/docs/XenMyWay.xml b/docs/XenMyWay.xml
index e8e3512da..b0f4a1956 100644
--- a/docs/XenMyWay.xml
+++ b/docs/XenMyWay.xml
@@ -15,7 +15,7 @@
- 2006-04-10
+ 2006-04-15
2006
@@ -131,26 +131,26 @@
- Dom0 (ursa.shorewall.net) is used as a local file server (NFS
- and Samba).
+ Dom0 (DNS name ursa.shorewall.net) is used as a local file
+ server (NFS and Samba).
The first DomU (Dom name firewall, gateway.shorewall.net) is used as our
- main firewall.
+ role="bold">firewall, DNS name gateway.shorewall.net) is
+ used as our main firewall.
The second DomU (Dom name lists, lists.shorewall.net) is used as a public
- Web/FTP/Mail/DNS server.
+ role="bold">lists, DNS name lists.shorewall.net) is used as
+ a public Web/FTP/Mail/DNS server.
The third DomU (Dom name wireless, wireless.shorewall.net) is used as a
- gateway to our wireless network.
+ role="bold">wireless, DNS name wireless.shorewall.net) is
+ used as a gateway to our wireless network.
@@ -159,6 +159,26 @@
has three interfaces. Shorewall runs in Dom0, in the firewall domain and
in the wireless gateway.
+
+ As the developer of Shorewall, I have enough experience to be very
+ comfortable with Linux networking and Shorewall/iptables. I arrived at
+ this configuration after a lot of trial and error experimentation (see
+ Xen and Shorewall). If you are a Linux
+ networking novice, I recommend that you do not attempt a configuration
+ like this one for your first Shorewall installation. You are very likely
+ to frustrate both yourself and the Shorewall support team. Rather I
+ suggest that you start with something simple like a standalone installation in a domU; once you
+ are comfortable with that then you will be ready to try something more
+ substantial.
+
+ As Paul Gear says: Shorewall might make iptables easy,
+ but it doesn't make understanding fundamental networking principles,
+ traffic shaping, or multi-ISP routing any easier.
+
+ The same goes for Xen networking.
+
+
Domain Configuration
@@ -274,7 +294,11 @@ disk = [ 'phy:hdb4,hdb4,w' ]
SuSE 10.0 includes Xen 3.0 which does not support PCI
delegation
PCI delegation was a feature of Xen 2.0 but that capability
- was dropped in 3.0. It has been restore in Xen 3.0.2.
+ was dropped in 3.0. It has been restored in Xen 3.0.2 and once I
+ upgrade this system to SuSE 10.1 (which includes Xen 3.0.2), I
+ intend to implement PCI delegation and remove three of the four
+ bridges. I will probably combine the wireless and firewall domains
+ at that time as well.
; 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
@@ -687,7 +711,7 @@ Trcrt/ACCEPT loc dmz
###############################################################################################################################################################################
# DMZ to Local
#
-ACCEPT dmz net:192.168.1.254 udp 123
+ACCEPT dmz loc:192.168.1.5 udp 123
ACCEPT dmz loc:192.168.1.5 tcp 21
Ping/ACCEPT dmz loc
diff --git a/docs/starting_and_stopping_shorewall.xml b/docs/starting_and_stopping_shorewall.xml
index e54ab681d..d3db61a9c 100644
--- a/docs/starting_and_stopping_shorewall.xml
+++ b/docs/starting_and_stopping_shorewall.xml
@@ -15,7 +15,7 @@
- 2006-03-24
+ 2006-04-10
2004
@@ -888,11 +888,12 @@
shorewall [ -q ] refresh
The rules involving the broadcast addresses of firewall
- interfaces, the black list, traffic control rules and ECN control
- rules are recreated to reflect any changes made to your
- configuration files. Existing connections are untouched If -q is
- specified, less detain is displayed making it easier to spot
- warnings.
+ interfaces, the black list and ECN control rules are recreated to
+ reflect any changes made to your configuration files. Shorewall
+ versions prior to 3.2.0 Beta 5 also recreate the traffic shaping
+ rules as part of processing the refresh command.
+ Existing connections are untouched. If -q is specified, less detail
+ is displayed making it easier to spot warnings.