shorewall_code/docs/OPENVPN.xml
Jeremy Sowden c93817f30b Correct GFDL text embedded in document sources
The invariant sections clause doesn't quite match the official text.  It should
read:

  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts

not:

  with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts

Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
2023-01-31 22:50:37 +00:00

805 lines
24 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, no Front-Cover Texts, and 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.</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 &amp;
B</para>
<programlisting>#ZONE TYPE OPTIONS IN_OPTIONS OUT_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 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 &amp;
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_OPTIONS OUT_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 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
push "route 192.168.1.0 255.255.255.0"
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; or</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>
</section>
<section id="Dupnet">
<title>Roadwarrior with Duplicate Network Issue</title>
<para>The information in this section was contributed by Nicola
Moretti.</para>
<para>If your local lan uses a popular RFC 1918 network like
192.168.1.0/24, there will be times when your roadwarriors need to access
your lan from a remote location that uses that same network.</para>
<graphic align="center" fileref="images/Mobile1.png"/>
<para>This may be accomplished by configuring a second server on your
firewall that uses a different port and by using <ulink
url="netmap.html">NETMAP</ulink> in your Shorewall configuration. The
server configuration in the above diagram is modified as shown
here:</para>
<blockquote>
<programlisting>dev tun
<emphasis role="bold">server 192.168.3.0 255.255.255.0</emphasis>
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
<emphasis role="bold">port 1195</emphasis>
comp-lzo
user nobody
group nogroup
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
<emphasis role="bold">push "route 172.20.1.0 255.255.255.0"</emphasis>
verb 3</programlisting>
</blockquote>
<para>In <filename>/etc/shorewall/netmap</filename>, put these
entries:</para>
<blockquote>
<programlisting>#TYPE NET1 INTERFACE NET2
SNAT 192.168.1.0/24 tun1 172.20.1.0/24
DNAT 172.20.1.0/24 tun1 192.168.1.0/24
</programlisting>
</blockquote>
<para>The roadwarrior can now connect to port 1195 and access the lan on
the right as 172.20.1.0/24.</para>
</section>
<section>
<title>Roadwarrior with IPv6</title>
<para>While OpenVPN supports tunneling of IPv6 packets, the version of the
code that I run under OS X on my Macbook Pro does not support that option.
Nevertheless, I am able to take IPv6 on the road with me by creating a
6to4 tunnel through the OpenVPN IPv6 tunnel. In this configuration, the
IPv4 address pair (172.20.0.10,172.20.0.11) is used for the OpenVPN tunnel
and (2001:470:e857:2::1,2001:470:e857:2::2) is used for the 6to4
tunnel.</para>
<para>Here are my config files:</para>
<para>Server (conventional routed server config):</para>
<blockquote>
<programlisting>dev tun
local 70.90.191.121
server 172.20.0.0 255.255.255.128
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/clients
ccd-exclusive
client-to-client
push "route 172.20.1.0 255.255.255.0"
verb 3</programlisting>
<para>In the CCD file for the Macbook Pro:</para>
<programlisting>ifconfig-push <emphasis role="bold">172.20.0.11 172.20.0.10</emphasis></programlisting>
<para>From <filename>/etc/network/interfaces</filename> (very standard
<ulink url="6to4.htm#SixInFour">6to4 tunnel
configuration</ulink>):</para>
<programlisting>auto mac
iface mac inet6 v4tunnel
address <emphasis role="bold">2001:470:e857:2::1</emphasis>
netmask 64
endpoint <emphasis role="bold">172.20.0.11</emphasis>
local <emphasis role="bold">172.20.1.254</emphasis></programlisting>
<para>Note that while the remote endpoint (172.20.0.11) is also the
remote endpoint of the OpenVPN tunnel, the local endpoint (172.20.1.254)
of the 6to4 tunnel is not the local endpoint of the OpenVPN tunnel
(that;s 172.20.0.10). 172.20.1.254 is the IPv4 address of the Shorewall
firewall's LAN interface.</para>
<para>The following excerpts from the Shorewall configuration show the
parts of that configuration that are relevant to these two tunnels (bold
font). <emphasis role="bold">This is not a complete
configuration.</emphasis></para>
<para><filename>/etc/shorewall/zones</filename>:</para>
<programlisting>#ZONE TYPE
fw firewall
loc ip #Local Zone
drct:loc ipv4 #Direct internet access
net ipv4 #Internet
<emphasis role="bold">vpn ipv4 </emphasis> #OpenVPN clients</programlisting>
<para><filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
loc INT_IF detect dhcp,logmartians=1,routefilter=1,physical=$INT_IF,required,wait=5
net COM_IF detect dhcp,blacklist,optional,routefilter=0,logmartians,proxyarp=0,physical=$COM_IF,nosmurfs
<emphasis role="bold">vpn TUN_IF+ detect physical=tun+,routeback</emphasis>
- sit1 - ignore
<emphasis role="bold">- mac - ignore</emphasis>
- EXT_IF - ignore
- lo - ignore</programlisting>
<para><filename>/etc/shorewall/tunnels</filename>:</para>
<programlisting>#TYPE ZONE GATEWAY GATEWAY
# ZONE
<emphasis role="bold">openvpnserver:udp net</emphasis>
6to4 net
<emphasis role="bold">6to4 vpn</emphasis></programlisting>
<para>Similarly, here are excerpts from the Shorewall6
configuration.</para>
<para><filename>/etc/shorewall6/zones</filename>:</para>
<programlisting>#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv6
<emphasis role="bold">loc ipv6</emphasis>
rest ipv6</programlisting>
<para><filename>/etc/shorewall6/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
net sit1 detect tcpflags,forward=1,nosmurfs,routeback
loc eth4 detect tcpflags,forward=1
<emphasis role="bold">loc mac detect tcpflags,forward=1</emphasis>
rest eth+</programlisting>
<para>Note that in the IPv6 firewall configuration, the remove Macbook
Pro is considered to be part of the local zone (loc).</para>
</blockquote>
<para>Client (conventional routed client config):</para>
<blockquote>
<programlisting>client
dev tun
proto udp
remote gateway.shorewall.net 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca ca.crt
cert mac.crt
key mac.key
ns-cert-type server
comp-lzo
verb 3
up /Users/teastep/bin/up
down /Users/teastep/bin/down
</programlisting>
<para><filename>/Users/teastep/bin/up</filename>:</para>
<programlisting>#!/bin/bash
LOCAL_IP=<emphasis role="bold">172.20.0.11</emphasis>
LOCAL_IPV6=<emphasis role="bold">2001:470:e857:2::2</emphasis>
REMOTE_IP=<emphasis role="bold">172.20.1.254</emphasis>
REMOTE_IPV6=<emphasis role="bold">2001:470:e857:2::1</emphasis>
TUNNEL_IF=gif0
if [ $(ifconfig gif0 | wc -l ) -eq 1 ]; then
#
# Tunnel interface is not configured yet
#
/sbin/ifconfig $TUNNEL_IF tunnel $LOCAL_IP $REMOTE_IP
/sbin/ifconfig $TUNNEL_IF inet6 $LOCAL_IPV6 $REMOTE_IPV6 prefixlen 128
else
/sbin/ifconfig $TUNNEL_IF up
fi
/sbin/route -n add -inet6 default $REMOTE_IPV6 &gt; /dev/null 2&gt;&amp;1</programlisting>
<para><filename>/Users/teastep/bin/down</filename>:</para>
<programlisting>#!/bin/bash
TUNNEL_IF=gif0
/sbin/ifconfig $TUNNEL_IF down
/sbin/route -n delete -inet6 default &gt; /dev/null 2&gt;&amp;1
</programlisting>
</blockquote>
</section>
<section>
<title>Bridged Roadwarrior</title>
<para>If you want to use a bridged OpenVPN configuration rather than a
routed configuration, then follow any of the available HOWTOs to set up
the bridged configuration. Then:</para>
<orderedlist>
<listitem>
<para>In your current Shorewall two-interface configuration, replace
references to your internal interface with the name of the bridge;
and</para>
</listitem>
<listitem>
<para>Set the <emphasis role="bold">routeback</emphasis> option in the
bridge's entry in <ulink
url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink>;
end</para>
</listitem>
<listitem>
<para>Add this entry to <ulink
url="manpages/shorewall-tunnels.html">/etc/shorewall/tunnels</ulink>:</para>
<programlisting>#TYPE ZONE GATEWAY GATEWAY_ZONE
openvpnserver:1194 net 0.0.0.0/0</programlisting>
</listitem>
</orderedlist>
<para>This will make the roadwarrior part of your local zone.</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>
<note>
<para>The stanzas below were written before bridges could be defined in
/etc/network/interfaces. For current usage, see bridge-utils-interfaces
(5).</para>
</note>
<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 br0
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/openvpn --rmtun --dev 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 br0
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/openvpn --rmtun --dev 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>