forked from extern/shorewall_code
510 lines
16 KiB
XML
510 lines
16 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<article id="OPENVPN">
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>OpenVPN Tunnels and Bridges</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Simon</firstname>
|
|
|
|
<surname>Matter</surname>
|
|
</author>
|
|
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2003</year>
|
|
|
|
<year>2004</year>
|
|
|
|
<year>2005</year>
|
|
|
|
<year>2006</year>
|
|
|
|
<holder>Simon Mater</holder>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>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
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<caution>
|
|
<para><emphasis role="bold">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.</emphasis></para>
|
|
</caution>
|
|
|
|
<para>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 <ulink
|
|
url="http://openvpn.sourceforge.net/license.html">licensed under the
|
|
GPL</ulink>. OpenVPN can be downloaded from <ulink
|
|
url="http://openvpn.net/">http://openvpn.net/</ulink>.</para>
|
|
|
|
<para>Unless there are interoperability issues (the remote systems do not
|
|
support OpenVPN), OpenVPN is my choice any time that I need a VPN.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>It is widely supported -- I run it on both Linux and Windows
|
|
XP.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>It requires no kernel patching.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>It is very easy to configure.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>It just works!</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<section id="Prelim">
|
|
<title>Preliminary Reading</title>
|
|
|
|
<para>I recommend reading the <ulink url="VPNBasics.html">VPN
|
|
Basics</ulink> article if you plan to implement any type of VPN.</para>
|
|
</section>
|
|
|
|
<section id="Routed">
|
|
<title>Bridging two Masqueraded Networks</title>
|
|
|
|
<para>Suppose that we have the following situation:</para>
|
|
|
|
<graphic fileref="images/TwoNets1.png" />
|
|
|
|
<para>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
|
|
<filename>/etc/shorewall/tunnels</filename> file and the
|
|
<filename>/etc/shorewall/policy file</filename> and OpenVPN.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>On each firewall, you will need to declare a zone to represent the
|
|
remote subnet. We'll assume that this zone is called <quote>vpn</quote>
|
|
and declare it in <filename>/etc/shorewall/zones</filename> on both
|
|
systems as follows.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/zones</filename> — Systems A &
|
|
B</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN OUT
|
|
# OPTIONS OPTIONS
|
|
vpn ipv4</programlisting>
|
|
</blockquote>
|
|
|
|
<para>On system A, the 10.0.0.0/8 will comprise the <emphasis
|
|
role="bold">vpn</emphasis> zone.</para>
|
|
|
|
<blockquote>
|
|
<para>In <filename>/etc/shorewall/interfaces</filename> on system
|
|
A:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
vpn tun0</programlisting>
|
|
</blockquote>
|
|
|
|
<para>In <filename>/etc/shorewall/tunnels</filename> on system A, we need
|
|
the following:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpn net 134.28.54.2</programlisting>
|
|
</blockquote>
|
|
|
|
<para>This entry in <filename>/etc/shorewall/tunnels</filename> 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:</para>
|
|
|
|
<blockquote>
|
|
<para>/etc/shorewall/tunnels with port 7777:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpn:7777 net 134.28.54.2</programlisting>
|
|
</blockquote>
|
|
|
|
<para>Similarly, if you want to use TCP for your tunnel rather than UDP
|
|
(the default), then you can define /etc/shorewall/tunnels like
|
|
this:</para>
|
|
|
|
<blockquote>
|
|
<para>/etc/shorewall/tunnels using TCP:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpn:tcp net 134.28.54.2</programlisting>
|
|
</blockquote>
|
|
|
|
<para>Finally, if you want to use TCP and port 7777:</para>
|
|
|
|
<blockquote>
|
|
<para>/etc/shorewall/tunnels using TCP port 7777:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpn:tcp:7777 net 134.28.54.2</programlisting>
|
|
</blockquote>
|
|
|
|
<para>This is the OpenVPN config on system A:</para>
|
|
|
|
<blockquote>
|
|
<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</programlisting>
|
|
</blockquote>
|
|
|
|
<para>Similarly, On system B the 192.168.1.0/24 subnet will comprise the
|
|
<emphasis role="bold">vpn</emphasis> zone</para>
|
|
|
|
<blockquote>
|
|
<para>In <filename>/etc/shorewall/interfaces</filename> on system
|
|
B:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
vpn tun0 </programlisting>
|
|
</blockquote>
|
|
|
|
<para>In <filename>/etc/shorewall/tunnels</filename> on system B, we
|
|
have:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpn net 206.191.148.9</programlisting>
|
|
</blockquote>
|
|
|
|
<para>And in the OpenVPN config on system B:</para>
|
|
|
|
<blockquote>
|
|
<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</programlisting>
|
|
</blockquote>
|
|
|
|
<para>You will need to allow traffic between the <quote>vpn</quote> zone
|
|
and the <quote>loc</quote> zone on both systems -- if you simply want to
|
|
admit all traffic in both directions, you can use the policy file:</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/policy </filename>on systems A &
|
|
B</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOG LEVEL
|
|
loc vpn ACCEPT
|
|
vpn loc ACCEPT</programlisting>
|
|
</blockquote>
|
|
|
|
<para>On both systems, restart Shorewall and start OpenVPN. The systems in
|
|
the two masqueraded subnetworks can now talk to each other.</para>
|
|
</section>
|
|
|
|
<section id="RoadWarrior">
|
|
<title>Roadwarrior</title>
|
|
|
|
<para>OpenVPN 2.0 provides excellent support for roadwarriors. Consider
|
|
the setup in the following diagram:</para>
|
|
|
|
<graphic fileref="images/Mobile.png" />
|
|
|
|
<para>On the gateway system (System A), we need a zone to represent the
|
|
remote clients — we'll call that zone <quote>road</quote>.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/zones</filename> — System A:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN OUT
|
|
# OPTIONS OPTIONS
|
|
road ipv4</programlisting>
|
|
</blockquote>
|
|
|
|
<para>On system A, the remote clients will comprise the <emphasis
|
|
role="bold">road</emphasis> zone.</para>
|
|
|
|
<blockquote>
|
|
<para>In <filename>/etc/shorewall/interfaces</filename> on system
|
|
A:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
road tun+</programlisting>
|
|
</blockquote>
|
|
|
|
<para>In <filename>/etc/shorewall/tunnels</filename> on system A, we need
|
|
the following:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpn:1194 net 0.0.0.0/0</programlisting>
|
|
</blockquote>
|
|
|
|
<para>If you are running Shorewall 2.4.3 or later, you might prefer the
|
|
following in <filename>/etc/shorewall/tunnels</filename> 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.</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpnserver:1194 net 0.0.0.0/0</programlisting>
|
|
</blockquote>
|
|
|
|
<para>We want the remote systems to have access to the local LAN — we do
|
|
that with an entry in <filename>/etc/shorewall/policy</filename> (assume
|
|
that the local LAN comprises the zone <quote>loc</quote>).</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#SOURCE DESTINATION POLICY
|
|
road loc ACCEPT</programlisting>
|
|
</blockquote>
|
|
|
|
<para>The OpenVPN configuration file on system A is something like the
|
|
following:</para>
|
|
|
|
<blockquote>
|
|
<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</programlisting>
|
|
</blockquote>
|
|
|
|
<para>Configuration on the remote clients follows a similar line. We
|
|
define a zone to represent the remote LAN:</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/zones</filename> — System B:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN OUT
|
|
# OPTIONS OPTIONS
|
|
home ipv4</programlisting>
|
|
</blockquote>
|
|
|
|
<para>On system A, the hosts accessible through the tunnel will comprise
|
|
the <emphasis role="bold">home</emphasis> zone.</para>
|
|
|
|
<blockquote>
|
|
<para>In <filename>/etc/shorewall/interfaces</filename> on system
|
|
B:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
home tun0</programlisting>
|
|
</blockquote>
|
|
|
|
<para>In <filename>/etc/shorewall/tunnels</filename> on system B, we need
|
|
the following:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpn:1194 net 206.162.148.9</programlisting>
|
|
</blockquote>
|
|
|
|
<para>Again, if you are running Shorewall 2.4.3 or later, in
|
|
<filename>/etc/shorewall/tunnels</filename> on system B you might
|
|
prefer:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
openvpnclient:1194 net 206.162.148.9</programlisting>
|
|
</blockquote>
|
|
|
|
<para>We want the remote client to have access to the local LAN — we do
|
|
that with an entry in <filename>/etc/shorewall/policy</filename>.</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#SOURCE DESTINATION POLICY
|
|
$FW home ACCEPT</programlisting>
|
|
</blockquote>
|
|
|
|
<para>The OpenVPN configuration on the remote clients is along the
|
|
following line:</para>
|
|
|
|
<blockquote>
|
|
<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</programlisting>
|
|
</blockquote>
|
|
|
|
<para>If you want multiple remote clients to be able to communicate openly
|
|
with each other then you must:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Include the <emphasis role="bold">client-to-client</emphasis>
|
|
directive in the server's OpenVPN configuration; and</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Specify the <emphasis role="bold">routeback</emphasis> option on
|
|
the <filename class="devicefile">tun+</filename> device in <ulink
|
|
url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If you want to selectively allow communication between the clients,
|
|
then see <ulink
|
|
url="http://marc.zonzon.free.fr/public_html/home.php?section=WRTMemo&subsec=vpnwithshorewall">this
|
|
article</ulink> by Marc Zonzon</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Bridging Two Networks</title>
|
|
|
|
<para>Occasionally, the need arises to have a single LAN span two
|
|
different geographical locations. OpenVPN allows that to be done
|
|
easily.</para>
|
|
|
|
<para>Consider the following case:</para>
|
|
|
|
<graphic align="center" fileref="images/bridge4.png" />
|
|
|
|
<para>Part of the 192.168.1.0/24 network is in one location and part in
|
|
another. The two LANs can be bridged with OpenVPN as described in this
|
|
section. This example uses a fixed shared key for encryption.</para>
|
|
|
|
<para>OpenVPN configuration on left-hand firewall:</para>
|
|
|
|
<programlisting>remote 130.252.100.109
|
|
dev tap0
|
|
secret /etc/openvpn/bridgekey</programlisting>
|
|
|
|
<para>OpenVPN configuration on right-hand firewall:</para>
|
|
|
|
<programlisting>remote 206.124.146.176
|
|
dev tap0
|
|
secret /etc/openvpn/bridgekey</programlisting>
|
|
|
|
<para>The bridges can be created by manually making the tap device tap0
|
|
and bridgeing it with the local ethernet interface. Assuming that the
|
|
local interface on both sides is eth1, the following stanzas in
|
|
/etc/network/interfaces (Debian and derivatives) will create the bridged
|
|
interfaces.</para>
|
|
|
|
<para>/etc/network/interfaces on the left-hand firewall:</para>
|
|
|
|
<programlisting>iface br0 inet static
|
|
pre-up /usr/sbin/openvpn --mktun --dev tap0
|
|
pre-up /usr/sbin/brctl addbr br1
|
|
address 192.168.1.254
|
|
network 192.168.1.0
|
|
broadcast 192.168.1.255
|
|
netmask 255.255.255.0
|
|
post-up /sbin/ip link set tap0 up
|
|
post-up /usr/sbin/brctl addif br0 tap0
|
|
post-up /sbin/ip link set eth1 up
|
|
post-up /usr/sbin/brctl addif br0 eth1
|
|
post-down /usr/sbin/brctl delbr br0
|
|
post-down /usr/sbin/tunctl -d tap0
|
|
post-down /sbin/ip link set eth1 down </programlisting>
|
|
|
|
<para>/etc/network/interfaces on the right-hand firewall:</para>
|
|
|
|
<programlisting>iface br0 inet static
|
|
pre-up /usr/sbin/openvpn --mktun --dev tap0
|
|
pre-up /usr/sbin/brctl addbr br1
|
|
address 192.168.1.253
|
|
network 192.168.1.0
|
|
broadcast 192.168.1.255
|
|
netmask 255.255.255.0
|
|
post-up /sbin/ip link set tap0 up
|
|
post-up /usr/sbin/brctl addif br0 tap0
|
|
post-up /sbin/ip link set eth1 up
|
|
post-up /usr/sbin/brctl addif br0 eth1
|
|
post-down /usr/sbin/brctl delbr br0
|
|
post-down /usr/sbin/tunctl -d tap0
|
|
post-down /sbin/ip link set eth1 down </programlisting>
|
|
|
|
<para>The Shorewall configuration is just a <ulink
|
|
url="SimpleBridge.html">Simple Bridge</ulink>.</para>
|
|
</section>
|
|
</article>
|