Sophie

Sophie

distrib > Mandriva > mes5 > x86_64 > by-pkgid > 45723c51178a73df679c2a8284d8eeff > files > 32

shorewall-doc-4.0.15-0.2mdvmes5.noarch.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>OpenVPN Tunnels and Bridges</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="OPENVPN"></a>OpenVPN Tunnels and Bridges</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Simon</span> <span class="surname">Matter</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2003, 2004, 2005, 2006 Simon Mater, Thomas M. Eastep</p></div><div><div class="legalnotice"><a id="id284642"></a><p>Permission is granted to copy, distribute and/or modify this
      document under the terms of the GNU Free Documentation License, Version
      1.2 or any later version published by the Free Software Foundation; with
      no Invariant Sections, with no Front-Cover, and with no Back-Cover
      Texts. A copy of the license is included in the section entitled
      “<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
      License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Prelim">Preliminary Reading</a></span></dt><dt><span class="section"><a href="#Routed">Bridging two Masqueraded Networks</a></span></dt><dt><span class="section"><a href="#RoadWarrior">Roadwarrior</a></span></dt><dt><span class="section"><a href="#Bridge">Securing a Home Wireless Network with OpenVPN (OpenVPN
    Bridge)</a></span></dt><dd><dl><dt><span class="section"><a href="#bridge">Configuring the Bridge</a></span></dt><dt><span class="section"><a href="#openvpn">Configuring OpenVPN</a></span></dt><dd><dl><dt><span class="section"><a href="#server">Firewall (Server) configuration.</a></span></dt><dt><span class="section"><a href="#tipper">Tipper Configuration</a></span></dt><dt><span class="section"><a href="#XP">Eastepnc6000 (Windows XP) Configuration</a></span></dt><dt><span class="section"><a href="#Linux">Eastepnc6000 (SUSE 10.0) Configuration</a></span></dt><dt><span class="section"><a href="#id302390">Ursa (Windows Vista) Configuration</a></span></dt></dl></dd><dt><span class="section"><a href="#Shorewall">Configuring Shorewall</a></span></dt><dd><dl><dt><span class="section"><a href="#FW">Firewall</a></span></dt><dt><span class="section"><a href="#Tipper">Tipper</a></span></dt></dl></dd></dl></dd></dl></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span class="bold"><strong>This article applies to Shorewall 3.0 and
    later and to OpenVPN 2.0 and later. If you are running a version of
    Shorewall earlier than Shorewall 3.0.0 then please see the documentation
    for that release.</strong></span></p></div><p>OpenVPN is a robust and highly configurable VPN (Virtual Private
  Network) daemon which can be used to securely link two or more private
  networks using an encrypted tunnel over the Internet. OpenVPN is an Open
  Source project and is <a class="ulink" href="http://openvpn.sourceforge.net/license.html" target="_self">licensed under the
  GPL</a>. OpenVPN can be downloaded from <a class="ulink" href="http://openvpn.net/" target="_self">http://openvpn.net/</a>.</p><p>Unless there are interoperability issues (the remote systems do not
  support OpenVPN), OpenVPN is my choice any time that I need a VPN.</p><div class="orderedlist"><ol type="1"><li><p>It is widely supported -- I run it on both Linux and Windows
      XP.</p></li><li><p>It requires no kernel patching.</p></li><li><p>It is very easy to configure.</p></li><li><p>It just works!</p></li></ol></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Prelim"></a>Preliminary Reading</h2></div></div></div><p>I recommend reading the <a class="ulink" href="VPNBasics.html" target="_self">VPN
    Basics</a> article if you plan to implement any type of VPN.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Routed"></a>Bridging two Masqueraded Networks</h2></div></div></div><p>Suppose that we have the following situation:</p><div><img src="images/TwoNets1.png" /></div><p>We want systems in the 192.168.1.0/24 subnetwork to be able to
    communicate with the systems in the 10.0.0.0/8 network. This is
    accomplished through use of the
    <code class="filename">/etc/shorewall/tunnels</code> file and the
    <code class="filename">/etc/shorewall/policy file</code> and OpenVPN.</p><p>While it was possible to use the Shorewall start and stop script to
    start and stop OpenVPN, I decided to use the init script of OpenVPN to
    start and stop it.</p><p>On each firewall, you will need to declare a zone to represent the
    remote subnet. We'll assume that this zone is called “<span class="quote">vpn</span>”
    and declare it in <code class="filename">/etc/shorewall/zones</code> on both
    systems as follows.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/zones</code> — Systems A &amp;
      B</p><pre class="programlisting">#ZONE   TYPE   OPTIONS                 IN                      OUT
#                                      OPTIONS                 OPTIONS
vpn     ipv4</pre></blockquote></div><p>On system A, the 10.0.0.0/8 will comprise the <span class="bold"><strong>vpn</strong></span> zone.</p><div class="blockquote"><blockquote class="blockquote"><p>In <code class="filename">/etc/shorewall/interfaces</code> on system
      A:</p><pre class="programlisting">#ZONE      INTERFACE        BROADCAST     OPTIONS
vpn        tun0</pre></blockquote></div><p>In <code class="filename">/etc/shorewall/tunnels</code> on system A, we need
    the following:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#TYPE         ZONE           GATEWAY        GATEWAY ZONE
openvpn       net            134.28.54.2</pre></blockquote></div><p>This entry in <code class="filename">/etc/shorewall/tunnels</code> opens the
    firewall so that OpenVPN traffic on the default port 1194/udp will be
    accepted to/from the remote gateway. If you change the port used by
    OpenVPN to 7777, you can define /etc/shorewall/tunnels like this:</p><div class="blockquote"><blockquote class="blockquote"><p>/etc/shorewall/tunnels with port 7777:</p><pre class="programlisting">#TYPE             ZONE           GATEWAY         GATEWAY ZONE
openvpn:7777      net            134.28.54.2</pre></blockquote></div><p>Similarly, if you want to use TCP for your tunnel rather than UDP
    (the default), then you can define /etc/shorewall/tunnels like
    this:</p><div class="blockquote"><blockquote class="blockquote"><p>/etc/shorewall/tunnels using TCP:</p><pre class="programlisting">#TYPE             ZONE           GATEWAY         GATEWAY ZONE
openvpn:tcp       net            134.28.54.2</pre></blockquote></div><p>Finally, if you want to use TCP and port 7777:</p><div class="blockquote"><blockquote class="blockquote"><p>/etc/shorewall/tunnels using TCP port 7777:</p><pre class="programlisting">#TYPE             ZONE           GATEWAY         GATEWAY ZONE
openvpn:tcp:7777  net            134.28.54.2</pre></blockquote></div><p>This is the OpenVPN config on system A:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">dev tun
local 206.162.148.9
remote 134.28.54.2
ifconfig 192.168.99.1 192.168.99.2
route 10.0.0.0 255.0.0.0 192.168.99.2
tls-server
dh dh1024.pem
ca ca.crt
cert my-a.crt
key my-a.key
comp-lzo
verb 5</pre></blockquote></div><p>Similarly, On system B the 192.168.1.0/24 subnet will comprise the
    <span class="bold"><strong>vpn</strong></span> zone</p><div class="blockquote"><blockquote class="blockquote"><p>In <code class="filename">/etc/shorewall/interfaces</code> on system
      B:</p><pre class="programlisting">#ZONE      INTERFACE        BROADCAST     OPTIONS
vpn        tun0 </pre></blockquote></div><p>In <code class="filename">/etc/shorewall/tunnels</code> on system B, we
    have:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#TYPE         ZONE           GATEWAY        GATEWAY ZONE
openvpn       net            206.191.148.9</pre></blockquote></div><p>And in the OpenVPN config on system B:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">dev tun
local 134.28.54.2
remote 206.162.148.9
ifconfig 192.168.99.2 192.168.99.1
route 192.168.1.0 255.255.255.0 192.168.99.1
tls-client
ca ca.crt
cert my-b.crt
key my-b.key
comp-lzo
verb 5</pre></blockquote></div><p>You will need to allow traffic between the “<span class="quote">vpn</span>” zone
    and the “<span class="quote">loc</span>” zone on both systems -- if you simply want to
    admit all traffic in both directions, you can use the policy file:</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/policy </code>on systems A &amp;
      B</p><pre class="programlisting">#SOURCE        DEST          POLICY          LOG LEVEL
loc            vpn           ACCEPT
vpn            loc           ACCEPT</pre></blockquote></div><p>On both systems, restart Shorewall and start OpenVPN. The systems in
    the two masqueraded subnetworks can now talk to each other.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="RoadWarrior"></a>Roadwarrior</h2></div></div></div><p>OpenVPN 2.0 provides excellent support for roadwarriors. Consider
    the setup in the following diagram:</p><div><img src="images/Mobile.png" /></div><p>On the gateway system (System A), we need a zone to represent the
    remote clients — we'll call that zone “<span class="quote">road</span>”.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/zones</code> — System A:</p><pre class="programlisting">#ZONE   TYPE   OPTIONS                 IN                      OUT
#                                      OPTIONS                 OPTIONS
road    ipv4</pre></blockquote></div><p>On system A, the remote clients will comprise the <span class="bold"><strong>road</strong></span> zone.</p><div class="blockquote"><blockquote class="blockquote"><p>In <code class="filename">/etc/shorewall/interfaces</code> on system
      A:</p><pre class="programlisting">#ZONE      INTERFACE        BROADCAST     OPTIONS
road       tun+</pre></blockquote></div><p>In <code class="filename">/etc/shorewall/tunnels</code> on system A, we need
    the following:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#TYPE         ZONE           GATEWAY        GATEWAY ZONE
openvpn:1194  net            0.0.0.0/0</pre></blockquote></div><p>If you are running Shorewall 2.4.3 or later, you might prefer the
    following in <code class="filename">/etc/shorewall/tunnels</code> on system A.
    Specifying the tunnel type as openvpnserver has the advantage that the VPN
    connection will still work if the client is behind a gateway/firewall that
    uses NAT.</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#TYPE               ZONE           GATEWAY        GATEWAY ZONE
openvpnserver:1194  net            0.0.0.0/0</pre></blockquote></div><p>We want the remote systems to have access to the local LAN — we do
    that with an entry in <code class="filename">/etc/shorewall/policy</code> (assume
    that the local LAN comprises the zone “<span class="quote">loc</span>”).</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#SOURCE      DESTINATION        POLICY
road         loc                ACCEPT</pre></blockquote></div><p>The OpenVPN configuration file on system A is something like the
    following:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">dev tun

server 192.168.2.0 255.255.255.0

dh dh1024.pem

ca /etc/certs/cacert.pem

crl-verify /etc/certs/crl.pem

cert /etc/certs/SystemA.pem
key /etc/certs/SystemA_key.pem

port 1194

comp-lzo

user nobody

group nogroup

ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key

verb 3</pre></blockquote></div><p>Configuration on the remote clients follows a similar line. We
    define a zone to represent the remote LAN:</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/zones</code> — System B:</p><pre class="programlisting">#ZONE   TYPE   OPTIONS                 IN                      OUT
#                                      OPTIONS                 OPTIONS
home    ipv4</pre></blockquote></div><p>On system A, the hosts accessible through the tunnel will comprise
    the <span class="bold"><strong>home</strong></span> zone.</p><div class="blockquote"><blockquote class="blockquote"><p>In <code class="filename">/etc/shorewall/interfaces</code> on system
      B:</p><pre class="programlisting">#ZONE      INTERFACE        BROADCAST     OPTIONS
home       tun0</pre></blockquote></div><p>In <code class="filename">/etc/shorewall/tunnels</code> on system B, we need
    the following:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#TYPE         ZONE           GATEWAY        GATEWAY ZONE
openvpn:1194  net            206.162.148.9</pre></blockquote></div><p>Again in you are running Shorewall 2.4.3 or later, in
    <code class="filename">/etc/shorewall/tunnels</code> on system B you might
    prefer:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#TYPE               ZONE           GATEWAY        GATEWAY ZONE
openvpnclient:1194  net            206.162.148.9</pre></blockquote></div><p>We want the remote client to have access to the local LAN — we do
    that with an entry in <code class="filename">/etc/shorewall/policy</code>.</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#SOURCE      DESTINATION        POLICY
$FW          home               ACCEPT</pre></blockquote></div><p>The OpenVPN configuration on the remote clients is along the
    following line:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">dev tun
remote 206.162.148.9
up /etc/openvpn/home.up

tls-client
pull

ca /etc/certs/cacert.pem

cert /etc/certs/SystemB.pem
key /etc/certs/SystemB_key.pem

port 1194

user nobody
group nogroup

comp-lzo

ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key

verb 3</pre></blockquote></div><p>If you want multiple remote clients to be able to communicate openly
    with each other then you must:</p><div class="orderedlist"><ol type="1"><li><p>Include the <span class="bold"><strong>client-to-client</strong></span>
        directive in the server's OpenVPN configuration; and</p></li><li><p>Specify the <span class="bold"><strong>routeback</strong></span> option on
        the <code class="filename">tun+</code> device in <a class="ulink" href="manpages/shorewall-interfaces.html" target="_self">/etc/shorewall/interfaces</a>.</p></li></ol></div><p>If you want to selectively allow communication between the clients,
    then see <a class="ulink" href="http://marc.zonzon.free.fr/public_html/home.php?section=WRTMemo&amp;subsec=vpnwithshorewall" target="_self">this
    article</a> by Marc Zonzon</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Bridge"></a>Securing a Home Wireless Network with OpenVPN (OpenVPN
    Bridge)</h2></div></div></div><p>This section will describe how we once secured our home wireless
    network using OpenVPN. Our network as it was then<sup>[<a id="id302205" href="#ftn.id302205" class="footnote">1</a>]</sup> is as shown in the following diagram.</p><div><img src="images/network3.png" /></div><p>The Wireless network is in the lower right of the diagram and
    consists of two laptops: Eastepnc6000 (Dual Boot Windows XP - SP1, SUSE
    10.0) and Tipper (SUSE 10.0). We used OpenVPN to bridge those two laptops
    with the local LAN shown in the lower left hand corner. The laptops were
    configured with addresses in the 192.168.3.0/24 network connected to the
    firewall's <code class="filename">eth0</code> interface which
    places them in the firewall's <span class="bold"><strong>Wifi</strong></span> zone.
    OpenVPN bridging allowed them to be assigned an additional IP address from
    the 192.168.1.0/24 network and to be securely bridged to the LAN on the
    lower left.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Eastepnc6000 is shown in both the local LAN and in the Wifi zone
      with IP address 192.168.1.6 -- clearly, the computer could only be in
      one place or the other. Tipper could also be in either place and would
      have the IP address 192.168.1.8 regardless.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="bridge"></a>Configuring the Bridge</h3></div></div></div><p>The firewall ran Debian Sarge so the bridge was defined in
      <code class="filename">/etc/network/interfaces</code>.</p><pre class="programlisting"># LAN interface
auto br0
iface br0 inet static
        address 192.168.1.254
        netmask 255.255.255.0
        pre-up /usr/sbin/openvpn --mktun --dev tap0
        pre-up /sbin/ip link set tap0 up
        pre-up /sbin/ip link set eth3 up
        pre-up /usr/sbin/brctl addbr br0
        pre-up /usr/sbin/brctl addif br0 eth3
        pre-up /usr/sbin/brctl addif br0 tap0
        pre-down /usr/sbin/brctl delif br0 eth3
        pre-down /sbin/ip link set eth3 down
        pre-down /usr/sbin/brctl delif br0 tap0
        pre-down /sbin/ip link set tap0 down
        post-down /usr/sbin/brctl delbr br0
        post-down /usr/sbin/openvpn --rmtun --dev tap0</pre><p>Note that the IP address assigned to the bridge is 192.168.1.254
      -- that was the default gateway address for hosts in the local
      zone.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="openvpn"></a>Configuring OpenVPN</h3></div></div></div><p>We used X.509 certificates for authentication.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="server"></a>Firewall (Server) configuration.</h4></div></div></div><p>/etc/openvpn/server-bridge.conf defined a bridge and reserved IP
        addresses 192.168.1.64-192.168.1.71 for VPN clients. Note that the
        bridge server only used local IP address 192.168.3.254. We ran two
        instances of OpenVPN; this one and a second tunnel-mode instance for
        remote access.</p><pre class="programlisting">dev tap0

local 192.168.3.254

server-bridge 192.168.1.254 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/gateway.pem
key /etc/certs/gateway_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</pre><p>The files in <code class="filename">/etc/openvpn/bridge-clients</code>
        were used to assign a fixed IP address to each laptop. For example,
        tipper.shorewall.net:</p><pre class="programlisting">ifconfig-push 192.168.1.8 255.255.255.0</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="tipper"></a>Tipper Configuration</h4></div></div></div><p>/etc/openvpn/wireless.conf:</p><pre class="programlisting">dev tap

remote 192.168.3.254
tls-remote gateway.shorewall.net

client

redirect-gateway

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</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="XP"></a>Eastepnc6000 (Windows XP) Configuration</h4></div></div></div><p>C:\Program Files\Openvpn\config\homewireless.ovpn:</p><pre class="programlisting">dev tap
remote 192.168.3.254
tls-remote gateway.shorewall.net

tls-client
pull

ca "/Program Files/OpenVPN/certs/cacert.pem"

cert "/Program Files/OpenVPN/certs/eastepnc6000.pem"
key "/Program Files/OpenVPN/certs/eastepnc6000_key.pem"

redirect-gateway

port 1194

comp-lzo

ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key

verb 3</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="Linux"></a>Eastepnc6000 (SUSE 10.0) Configuration</h4></div></div></div><p>The configuration was the same as shown above only with
        "/Program Files/OpenVPN" replaced with "/etc/openvpn" (I love
        OpenVPN).</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id302390"></a>Ursa (Windows Vista) Configuration</h4></div></div></div><p>In December 2007, I acquired a new laptop that runs Windows
        Vista. After a frustrating effort, I managed to get it working. The
        keys to getting it working were:</p><div class="orderedlist"><ol type="1"><li><p>You must run a version of OpenVPN that is "Vista Ready" -- I
            used Matias Sundman's combined OpenVPN 2.1_rc4/OpenVPN GUI 1.0.3
            installer (see <a class="ulink" href="http://openvpn.se/" target="_self">http://openvpn.se/</a>).</p></li><li><p>OpenVPN GUI must be run as the Administrator. In the
            Explorer, right click on the OpenVPN GUI binary and select
            Properties-&gt;Compatibility and select "Run this program as an
            administrator".</p></li><li><p>If you encounter problems where everything looks correct but
            it doesn't work, reboot and try it again.</p></li></ol></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Shorewall"></a>Configuring Shorewall</h3></div></div></div><p>In this configuration, we didn't need any firewalling between the
      laptops and the local LAN so we set BRIDGING=No in shorewall.conf. The
      configuration of the bridge then became as described in the <a class="ulink" href="SimpleBridge.html" target="_self">Simple Bridge documentation</a>. If you need
      to control the traffic allowed through the VPN bridge then you will want
      to configure Shorewall as shown in the <a class="ulink" href="bridge-Shorewall-perl.html" target="_self">Bridge/Firewall
      documentation</a>.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="FW"></a>Firewall</h4></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="interfaces"></a>/etc/shorewall/interfaces</h5></div></div></div><p>Note that the bridge (br0) is defined as the interface to the
          local zone and has the <span class="bold"><strong>routeback</strong></span>
          option.</p><pre class="programlisting">#ZONE   INTERFACE       BROADCAST               OPTIONS
net     eth2            206.124.146.255         dhcp,norfc1918,logmartians,blacklist,tcpflags,nosmurfs
loc     br0             192.168.1.255           dhcp,<span class="bold"><strong>routeback</strong></span>
dmz     eth1            -                       logmartians
Wifi    eth0            192.168.3.255           dhcp,maclist
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="tunnels"></a>/etc/shorewall/tunnels</h5></div></div></div><pre class="programlisting">#TYPE                   ZONE    GATEWAY         GATEWAY
#                                               ZONE
openvpnserver:1194      Wifi    192.168.3.0/24
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="Tipper"></a>Tipper</h4></div></div></div><p>Wireless networks pose a threat to all systems that are
        connected to them and we therefore ran Firewalls on the two Laptops.
        Eastepnc6000 ran <span class="trademark">Sygate</span>™ Security Agent and
        Tipper ran a Shorewall-based Netfilter firewall.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="zones"></a>/etc/shorewall/zones</h5></div></div></div><pre class="programlisting">#ZONE   TYPE    OPTIONS                 IN                      OUT
#                                       OPTIONS                 OPTIONS
<span class="bold"><strong>lan     ipv4</strong></span>    #Wired LAN at our home
net     ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="interfaces1"></a>/etc/shorewall/interfaces</h5></div></div></div><pre class="programlisting">#ZONE    INTERFACE      BROADCAST       OPTIONS
#
net      eth0           detect          routefilter,dhcp,tcpflags
<span class="bold"><strong>lan      tap0           192.168.1.255</strong></span>
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="policy"></a>/etc/shorewall/policy</h5></div></div></div><p>Since we didn't expect any traffic between the <span class="bold"><strong>net</strong></span> zone and the <span class="bold"><strong>lan</strong></span> zone, we used NONE policies for that
          traffic. If any such traffic would have occurred, it would have been
          handled according to the all-&gt;all policy.</p><pre class="programlisting">#SOURCE         DEST            POLICY          LOG             LIMIT:BURST
#                                               LEVEL
fw              net             ACCEPT
<span class="bold"><strong>fw              lan             ACCEPT
lan             fw              ACCEPT
net             lan             NONE
lan             net             NONE</strong></span>
net             all             DROP            info
# The FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info
#LAST LINE -- DO NOT REMOVE</pre></div></div></div></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id302205" href="#id302205" class="para">1</a>] </sup>Our current network uses a similar technique -- see the <a class="ulink" href="XenMyWay.html" target="_self">Xen My Way</a> article.</p></div></div></div></body></html>