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.