mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-21 23:23:13 +01:00
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:
parent
3bc36199e5
commit
e2de913e89
@ -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> /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=<IP address at our second home>
|
||||
|
||||
@ -556,6 +506,7 @@ OMAK=<IP address at our second home>
|
||||
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->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
@ -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 [ <directory1> ]
|
||||
[<user>@]<system>:[<directory2>]</command></para>
|
||||
|
||||
<para>If <directory1> 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 <directory1>
|
||||
<directory1>/firewall &&\</command></member>
|
||||
|
||||
<member><command>scp <directory1>/firewall
|
||||
<directory1>/firewall.conf
|
||||
[<user>@]<system>:[<directory2>]</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 <system> using scp.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>forget</term>
|
||||
|
||||
@ -912,6 +944,7 @@ gateway:~ #</programlisting>
|
||||
<directory>/firewall &&\</command></member>
|
||||
|
||||
<member><command>scp <directory>/firewall
|
||||
<directory>/firewall.conf
|
||||
root@<system>:/var/lib/shorewall-lite/
|
||||
&&\</command></member>
|
||||
|
||||
@ -1049,6 +1082,7 @@ gateway:~ #</programlisting>
|
||||
<directory>/firewall &&\</command></member>
|
||||
|
||||
<member><command>scp <directory>/firewall
|
||||
<directory>/firewall
|
||||
root@<system>:/var/lib/shorewall-lite/
|
||||
&&\</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>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user