Update XenMyWay for PCI Delegation

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4352 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-08-14 14:53:53 +00:00
parent 3bc36199e5
commit e2de913e89
6 changed files with 515 additions and 743 deletions

View File

@ -99,7 +99,7 @@
</listitem>
</orderedlist>
<para>Most of the Linux systems run SUSE 10.0; my personal Linux desktop
<para>Most of the Linux systems run SUSE 10.1; my personal Linux desktop
system and our Linux Laptop run Ubuntu "Dapper Drake".</para>
<para>If you are unfamiliar with Xen networking, I recommend that you read
@ -134,7 +134,7 @@
</listitem>
</itemizedlist>
<para>There are four Xen domains.</para>
<para>There are three Xen domains.</para>
<orderedlist>
<listitem>
@ -145,26 +145,17 @@
<listitem>
<para>The first DomU (Dom name <emphasis
role="bold">firewall</emphasis>, DNS name gateway.shorewall.net) is
used as our main firewall.</para>
used as our main firewall and wireless gateway.</para>
</listitem>
<listitem>
<para>The second DomU (Dom name <emphasis
role="bold">lists</emphasis>, DNS name lists.shorewall.net) is used as
a public Web/FTP/Mail/DNS server.</para>
</listitem>
<listitem>
<para>The third DomU (Dom name <emphasis
role="bold">wireless</emphasis>, DNS name wireless.shorewall.net) is
used as a gateway to our wireless network.</para>
a public Web/FTP/Mail/DNS serv</para>
</listitem>
</orderedlist>
<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>
<para>Shorewall runs in Dom0 and in the firewall domain.</para>
<caution>
<para>As the developer of Shorewall, I have enough experience to be very
@ -189,10 +180,8 @@
<section id="Domains">
<title>Domain Configuration</title>
<para>Below are the relevant configuration files for the four domains.
The "loopback.nloopbacks=..." entries are used to restrict the number of
"veth<emphasis>n</emphasis>" devices that the Xen kernel creates. I use
partitions on my hard drives for DomU storage devices.</para>
<para>Below are the relevant configuration files for the turee domains.
I use partitions on my hard drives for DomU storage devices.</para>
<blockquote>
<para><filename>/boot/grub/menu.lst</filename> — here is the entry
@ -201,9 +190,19 @@
<programlisting>title XEN
root (hd0,1)
kernel /boot/xen.gz dom0_mem=458752 sched=bvt
module /boot/vmlinuz-xen root=/dev/hda2 vga=0x31a selinux=0 resume=/dev/hda1 splash=silent showopts loopback.nloopbacks=1
module /boot/vmlinuz-xen root=/dev/hda2 vga=0x31a selinux=0 resume=/dev/hda1 splash=silent showopts
module /boot/initrd-xen</programlisting>
<para><filename>/etc/modprobe.conf.local</filename></para>
<para>See <ulink
url="http://wiki.xensource.com/xenwiki/Assign_hardware_to_DomU_with_PCIBack_as_module">http://wiki.xensource.com/xenwiki/Assign_hardware_to_DomU_with_PCIBack_as_module</ulink>
The SuSE 10.1 Xen kernel compiles pciback as a module.</para>
<programlisting>options pciback hide=(00:09.0)(00:0a.0)
install tulip /sbin/modprobe pciback ; /sbin/modprobe --first-time --ignore-install tulip
options netloop nloopbacks=1</programlisting>
<para><filename>/etc/xen/auto/01-firewall</filename> — configuration
file for the firewall domain</para>
@ -216,18 +215,20 @@ name = "firewall"
memory = 256
# kernel and initrd:
kernel = "/boot/vmlinuz-xen"
ramdisk = "/boot/initrd-xen"
kernel = "/xen2/vmlinuz-xen"
ramdisk = "/xen2/initrd-xen"
# boot device:
root = "/dev/hdb2"
# boot to run level:
extra = "loopback.nloopbacks=0 3"
extra = "3"
# network interface:
vif = [ 'mac=aa:cc:00:00:00:02, bridge=xenbr0', 'mac=aa:cc:00:00:00:03, bridge=xenbr1' , 'mac=00:a0:cc:63:66:89, bridge=xenbr2' ]
vif = [ 'mac=aa:cc:00:00:00:02, bridge=xenbr0', 'mac=aa:cc:00:00:00:03, bridge=xenbr1' ]
dhcp = 'dhcp'
hostname = name
pci=[ '00:09.0' , '00:0a.0' ]
# storage devices:
disk = [ 'phy:hdb2,hdb2,w' ]</programlisting>
@ -244,14 +245,14 @@ name = "lists"
memory = 512
# kernel and initrd:
kernel = "/boot/vmlinuz-xen"
ramdisk = "/boot/initrd-xen"
kernel = "/xen2/vmlinuz-xen"
ramdisk = "/xen2/initrd-xen"
# boot device:
root = "/dev/hda3"
# boot to run level:
extra = "loopback.nloopbacks=0 3"
extra = "3"
# network interface:
vif = [ 'mac=aa:cc:00:00:00:01, bridge=xenbr1' ]
@ -259,43 +260,14 @@ hostname = name
# storage devices:
disk = [ 'phy:hda3,hda3,w' ]</programlisting>
<para>/etc/xen/auto/03-wireless — configuration file for the wireless
domain.</para>
<programlisting># -*- mode: python; -*-
# configuration name:
name = "wireless"
# usable ram:
memory = 256
# kernel and initrd:
kernel = "/boot/vmlinuz-xen"
ramdisk = "/boot/initrd-xen"
# boot device:
root = "/dev/hdb4"
# boot to run level:
extra = "loopback.nloopbacks=0 3"
# network interface:
vif = [ 'mac=aa:cc:00:00:00:04, bridge=xenbr0', 'mac=00:a0:cc:d1:db:12, bridge=xenbr3' ]
dhcp = 'dhcp'
hostname = name
# storage devices:
disk = [ 'phy:hdb4,hdb4,w' ]</programlisting>
</blockquote>
<para>With all four Xen domains up and running, the system looks as
<para>With all three Xen domains up and running, the system looks as
shown in the following diagram.</para>
<graphic align="center" fileref="images/Xen4.png" />
<para>The zones correspond to the Shorewall zones in the Dom0
<para>The zones correspond to the Shorewall zones in the firewall DomU
configuration.</para>
<caution>
@ -313,40 +285,19 @@ disk = [ 'phy:hdb4,hdb4,w' ]</programlisting>
<para><command>ethtool -K eth0 tx off</command></para>
</caution>
<para>SuSE 10.0 includes Xen 3.0 which does not support PCI
delegation<footnote>
<para>PCI delegation was a feature of Xen 2.0 but that capability
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.</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>
<para>SuSE 10.1 includes Xen 3.0.2 which supports PCI delegation. The
network interfaces that connect to the net and wifi zones are delegated
to the firewall DomU.</para>
<para>When Shorewall starts during bootup of Dom0, it creates the two
bridges using this <filename>/etc/shorewall/init</filename> extension
script:</para>
<blockquote>
<programlisting>for bridge in xenbr0 xenbr1 xenbr2 xenbr3; do
<programlisting>for bridge in xenbr0 xenbr1; do
if [ -z "$(/sbin/brctl show 2&gt; /dev/null | fgrep $bridge)" ]; then
/sbin/brctl addbr $bridge
case $bridge in
xenbr2)
mac=`ip link show eth1 | grep 'link\/ether' | sed -e 's/.*ether \(..:..:..:..:..:..\).*/\1/'`
[ "$mac" = "fe:ff:ff:ff:ff:ff" ] || /sbin/ip link set dev eth1 addr fe:ff:ff:ff:ff:ff
/sbin/ip link set dev eth1 up
/sbin/brctl addif xenbr2 eth1
;;
xenbr3)
mac=`ip link show eth2 | grep 'link\/ether' | sed -e 's/.*ether \(..:..:..:..:..:..\).*/\1/'`
[ "$mac" = "fe:ff:ff:ff:ff:ff" ] || /sbin/ip link set dev eth2 addr fe:ff:ff:ff:ff:ff
/sbin/ip link set dev eth2 up
/sbin/brctl addif xenbr3 eth2
;;
esac
/sbin/ip link set dev $bridge up
/sbin/ip link set dev $bridge up
fi
done</programlisting>
</blockquote>
@ -360,7 +311,7 @@ done</programlisting>
<itemizedlist>
<listitem>
<para>Allow traffic to flow unrestricted through the four bridges.
<para>Allow traffic to flow unrestricted through the two bridges.
This is done by configuring the hosts connected to each bridge as a
separate zone and relying on Shorewall's implicit intra-zone ACCEPT
policy to permit traffic through the bridge.</para>
@ -381,10 +332,8 @@ done</programlisting>
<programlisting>#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
Wifi ipv4
loc ipv4
dmz ipv4
net ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
</programlisting>
@ -393,22 +342,16 @@ net ipv4
<programlisting>#SOURCE DEST POLICY LOG LIMIT:BURST
# LEVEL
Wifi all REJECT info
all Wifi REJECT info
dmz all REJECT info
all dmz REJECT info
net all REJECT info
all net REJECT info
all all ACCEPT
#LAST LINE -- DO NOT REMOVE</programlisting>
<para><filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
Wifi xenbr3 - routeback
loc xenbr0 192.168.1.255 dhcp,routeback
dmz xenbr1 - routeback
net xenbr2 - routeback
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para><filename>/etc/shorewall/rules</filename>:</para>
@ -428,18 +371,19 @@ SECTION NEW
<para>In the firewall DomU, I run a conventional three-interface
firewall with Proxy ARP DMZ -- it is very similar to the firewall
described in the <ulink url="shorewall_setup_guide.htm">Shorewall Setup
Guide</ulink>. The firewall runs a routed <ulink
Guide</ulink> with the exception that I've added a fourth interface for
our wireless network. The firewall runs a routed <ulink
url="OPENVPN.html">OpenVPN server</ulink> to provide roadwarrior access
for our two laptops. Here is the firewall's view of the network:</para>
for our two laptops and a bridged OpenVPN server for our wireless
network. Here is the firewall's view of the network:</para>
<graphic align="center" fileref="images/network4.png" />
<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; 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>
or they can be attached wirelessly -- their IP addresses are the 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
@ -506,8 +450,9 @@ TCP_FLAGS_DISPOSITION=DROP</programlisting>
fw firewall
net ipv4 #Internet
loc ipv4 #Local wired Zone
dmz:loc ipv4 #DMZ -- server running in virtual machine at 206.124.146.177
dmz ipv4 #DMZ
vpn ipv4 #Open VPN clients
wifi ipv4 #Local Wireless Zone
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
</programlisting>
@ -523,8 +468,12 @@ vpn net ACCEPT
vpn loc ACCEPT
loc vpn ACCEPT
$FW loc ACCEPT
wifi all REJECT $LOG
loc $FW REJECT $LOG
net all DROP $LOG 10/sec:40
net $FW DROP $LOG 1/sec:2
net loc DROP $LOG 2/sec:4
net dmz DROP $LOG 8/sec:30
net vpn DROP $LOG
all all REJECT $LOG
#LAST LINE -- DO NOT REMOVE</programlisting>
@ -541,6 +490,7 @@ LOG=info
INT_IF=eth0
DMZ_IF=eth1
EXT_IF=eth3
WIFI_IF=eth4
OMAK=&lt;IP address at our second home&gt;
@ -556,6 +506,7 @@ OMAK=&lt;IP address at our second home&gt;
net $EXT_IF 206.124.146.255 dhcp,norfc1918,logmartians,blacklist,tcpflags,nosmurfs
dmz $DMZ_IF 192.168.0.255 logmartians
loc $INT_IF 192.168.1.255 dhcp,routeback,logmartians
wifi $WIFI_IF 192.168.3.255 dhcp,maclist
vpn tun+ -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
@ -589,6 +540,7 @@ $EXT_IF 192.168.0.0/22 206.124.146.179
<programlisting>#TYPE ZONE GATEWAY GATEWAY
# ZONE
openvpnserver:udp net 0.0.0.0/0
openvpnserver:udp wifi 192.168.3.0/24
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para><filename>/etc/shorewall/actions</filename>:</para>
@ -790,37 +742,11 @@ $EXT_IF 30 6*full/10 6*full/10 3
#Shorewall Mirrors.
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting></para>
</blockquote>
</section>
<section id="Wireless">
<title>Wireless Gateway DomU Configuration</title>
<para>The Shorewall configuration in the 'wireless' DomU is very simple.
It's sole purpose is to protect the local network from the Wireless net
by restricting wireless access to clients that have established an
<ulink url="OPENVPN.html">OpenVPN</ulink> Bridged connection. This
configuration illustrates that you can use any system on your internal
LAN as a wireless gateway -- it doesn't have to be your main firewall
(and it doesn't have to run in a Xen domain either and it doesn't even
have to run Linux). Our wireless gateway runs a DHCP server that assigns
wireless hosts an IP address in 192.168.3.0/24 -- The OpenVPN server
running on the gateway assigns its clients an IP address in
192.168.1.0/24 so, thanks to bridging, these clients appear to be
physically attached to the LAN). That allows our two laptops to have the
same IP address in 192.168.1.0/24 regardless of whether they are
connected to the LAN directly or are connected via the wireless
network.</para>
<graphic align="center" fileref="images/Xen6.png" />
<para>The 'tap0' device used by OpenVPN is bridged to eth2 using this
SUSE-specific startup script (see the <ulink url="bridge.html">Shorewall
Bridge Documentation</ulink> for scripts that work on other
distributions):</para>
<para>The tap0 device used by the bridged OpenVPN server is bridged to
eth0 using a SuSE-specific SysV init script:</para>
<blockquote>
<para><filename>/etc/init.d/bridge</filename>:</para>
<programlisting>#!/bin/sh
#
# The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V3.0
@ -871,9 +797,9 @@ $EXT_IF 30 6*full/10 6*full/10 3
### END INIT INFO
################################################################################
# Interfaces to be bridged -- may be listed by device name or by MAC address
# Interfaces to be bridged -- may be listed by device name or by MAC
#
INTERFACES="eth2"
INTERFACES="eth0"
#
# Tap Devices
@ -925,7 +851,7 @@ get_interfaces() {
INTERFACES="$interfaces"
}
################################################################################
# Configure the Bridge -- IP configuration is left to the SUSE network scripts
# Start the Bridge
################################################################################
do_start()
{
@ -988,187 +914,8 @@ case "$command" in
*)
usage
;;
esac</programlisting>
<para>As mentioned in the comments in the above script, IP
configuration of the bridge is done through the normal SUSE network
scripts. Here's the config file:</para>
<programlisting>BOOTPROTO='static'
BROADCAST=''
IPADDR='192.168.1.7'
MTU=''
NAME='Ethernet Network Card'
NETMASK='255.255.255.0'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
_nm_name='br0'</programlisting>
<para>Since there is no requirement to restrict connections through
the bridge, I set BRIDGING=No in
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
<para><filename>/etc/shorewall/zones</filename>:</para>
<programlisting>#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
Wifi ipv4
loc ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
<para><filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
Wifi eth4 192.168.3.255 dhcp,maclist
loc br0 192.168.1.255 dhcp,routeback
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
esac
</programlisting>
<para><filename>/etc/shorewall/policy</filename> (again, note the use
of an ACCEPT all-&gt;all policy):</para>
<programlisting>#SOURCE DEST POLICY LOG LIMIT:BURST
# LEVEL
Wifi all REJECT info
all all ACCEPT
#LAST LINE -- DO NOT REMOVE</programlisting>
<para><filename>/etc/shorewall/tunnels</filename>:</para>
<programlisting>#TYPE ZONE GATEWAY GATEWAY
# ZONE
openvpnserver Wifi 192.168.3.0/24
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para><filename>/etc/shorewall/maclist (Note that this system runs
Shorewall 3.2 so there is an additional 'TARGET'
column)</filename>:</para>
<programlisting>#TARGET INTERFACE MAC IP ADDRESSES (Optional)
ACCEPT eth4 00:04:5a:0e:85:b9 #WAP11
ACCEPT eth4 00:06:25:45:33:3c #WET11
ACCEPT eth4 00:0b:cd:53:cc:97 192.168.3.8 #TIPPER
ACCEPT eth4 00:0f:66:ef:b6:f6 192.168.3.8 #TIPPER1
ACCEPT eth4 00:12:79:3d:fe:2e 192.168.3.6 #Work Laptop
ACCEPT eth4 - 192.168.3.254 #Broadcast/Multicast from us
DROP:info eth4 - 192.168.3.0/24
DROP:info eth4 - 169.254.0.0/16 #Stop autoconfigured hosts.
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
<para>The routing table on the wireless gateway is as follows:</para>
<blockquote>
<programlisting>192.168.3.0/24 dev eth4 proto kernel scope link src 192.168.3.254
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.7
169.254.0.0/16 dev eth4 scope link
127.0.0.0/8 dev lo scope link
default via 192.168.1.254 dev br0</programlisting>
</blockquote>
<para>The route to 169.254.0.0/16 is automatically generated by the
SUSE network scripts so I include that network in the
<filename>/etc/shorewall/maclist</filename> file for
completeness.</para>
<para><filename>/etc/shorewall/rules</filename>:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT PORT(S) DEST LIMIT GROUP
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW
ACCEPT Wifi loc:192.168.1.5 udp 123 #Allow NTP before OpenVPN is up.
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
<para>Here is the configuration of OpenVPN on this system:</para>
<blockquote>
<para><filename>/etc/openvpn/server-bridge</filename> (Note that I
prefer to push two /1 routes rather than to use the <emphasis
role="bold">redirect-gateway</emphasis> directive on the client
systems; I find that <emphasis role="bold">redirect-gateway</emphasis>
occasionally leaves a client system with <emphasis
role="bold">no</emphasis> default gateway):</para>
<programlisting>dev tap0
local 192.168.3.254
server-bridge 192.168.1.7 255.255.255.0 192.168.1.64 192.168.1.71
client-to-client
dh dh1024.pem
ca /etc/certs/cacert.pem
crl-verify /etc/certs/crl.pem
cert /etc/certs/wireless.pem
key /etc/certs/wireless_key.pem
port 1194
comp-lzo
user nobody
group nogroup
keepalive 15 45
ping-timer-rem
persist-tun
persist-key
client-config-dir /etc/openvpn/bridge-clients
ccd-exclusive
verb 3
push "route 0.0.0.0 128.0.0.0 192.168.1.254"
push "route 128.0.0.0 128.0.0.0 192.168.1.254"</programlisting>
<para><filename>/etc/bridge-clients/tipper.shorewall.net</filename>
(used to assign a fixed IP address to clients -- there are other
similar files in this directory):</para>
<programlisting>ifconfig-push 192.168.1.8 255.255.255.0</programlisting>
</blockquote>
<para>Finally, here's a copy of the OpenVPN configuration file on
tipper, one of the laptops:</para>
<blockquote>
<programlisting>dev tap
remote 192.168.3.254
tls-remote wireless.shorewall.net
client
tls-client
explicit-exit-notify
ca /etc/certs/cacert.pem
cert /etc/certs/tipper.pem
key /etc/certs/tipper_key.pem
port 1194
comp-lzo
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
mute-replay-warnings
verb 3</programlisting>
</blockquote>
</section>
</section>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 15 KiB

File diff suppressed because one or more lines are too long

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 19 KiB

File diff suppressed because one or more lines are too long

View File

@ -821,6 +821,38 @@ gateway:~ #</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>export (Shorewall 3.2.3 and later - Not supported by Shorewall
Lite)</term>
<listitem>
<para><command>export [ &lt;directory1&gt; ]
[&lt;user&gt;@]&lt;system&gt;:[&lt;directory2&gt;]</command></para>
<para>If &lt;directory1&gt; is omitted, the current working
directory is assumed.</para>
<para>Allows a non-root user to compile a shorewall script and stage
it on a system (provided that the user has access to the system via
ssh). The command is equivalent to:</para>
<simplelist>
<member><command>/sbin/shorewall compile -e &lt;directory1&gt;
&lt;directory1&gt;/firewall &amp;&amp;\</command></member>
<member><command>scp &lt;directory1&gt;/firewall
&lt;directory1&gt;/firewall.conf
[&lt;user&gt;@]&lt;system&gt;:[&lt;directory2&gt;]</command></member>
</simplelist>
<para>In other words, the configuration in the specified (or
defaulted) directory is compiled to a file called
<filename>firewall</filename> in that directory. If compilation
succeeds, then <filename>firewall and firewall.conf</filename> are
copied to &lt;system&gt; using scp.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>forget</term>
@ -912,6 +944,7 @@ gateway:~ #</programlisting>
&lt;directory&gt;/firewall &amp;&amp;\</command></member>
<member><command>scp &lt;directory&gt;/firewall
&lt;directory&gt;/firewall.conf
root@&lt;system&gt;:/var/lib/shorewall-lite/
&amp;&amp;\</command></member>
@ -1049,6 +1082,7 @@ gateway:~ #</programlisting>
&lt;directory&gt;/firewall &amp;&amp;\</command></member>
<member><command>scp &lt;directory&gt;/firewall
&lt;directory&gt;/firewall
root@&lt;system&gt;:/var/lib/shorewall-lite/
&amp;&amp;\</command></member>
@ -1437,8 +1471,8 @@ gateway:~ #</programlisting>
<para>The only time that a program other than
<command>/usr/share/shorewall[-lite[/firewall</command> performs a state
transition itself is when it executes the <command>shorewall[-lite]
restore</command> command is executed. In that case, the
transition itself is when the <command>shorewall[-lite] restore</command>
command is executed. In that case, the
<command>/var/lib/shorewall[-lite]/restore</command> program sets the
state to "Started".</para>