OpenVPN Tunnels and Bridges

SimonMatter

TomEastep

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
“GNU Free Documentation
License”.

Caution

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.

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 licensed under the
GPL. OpenVPN can be downloaded from http://openvpn.net/.

Unless there are interoperability issues (the remote systems do not
support OpenVPN), OpenVPN is my choice any time that I need a VPN.

It is widely supported -- I run it on both Linux and
Windows.

It requires no kernel patching.

It is very easy to configure.

It just works!

Preliminary Reading

I recommend reading the VPN
Basics article if you plan to implement any type of VPN.

Bridging two Masqueraded Networks

Suppose that we have the following situation:

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
/etc/shorewall/tunnels file and the
/etc/shorewall/policy file and OpenVPN.

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.

On each firewall, you will need to declare a zone to represent the
remote subnet. We'll assume that this zone is called “vpn”
and declare it in /etc/shorewall/zones on both
systems as follows.

/etc/shorewall/zones — Systems A &
B

#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
vpn ipv4

On system A, the 10.0.0.0/8 will comprise the vpn zone.

In /etc/shorewall/interfaces on system
A:

#ZONE INTERFACE OPTIONS
vpn tun0

In /etc/shorewall/tunnels on system A, we need
the following:

#TYPE ZONE GATEWAY GATEWAY_ZONE
openvpn net 134.28.54.2

This entry in /etc/shorewall/tunnels 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:

/etc/shorewall/tunnels with port 7777:

#TYPE ZONE GATEWAY GATEWAY_ZONE
openvpn:7777 net 134.28.54.2

Similarly, if you want to use TCP for your tunnel rather than UDP
(the default), then you can define /etc/shorewall/tunnels like
this:

You will need to allow traffic between the “vpn” zone
and the “loc” zone on both systems -- if you simply want to
admit all traffic in both directions, you can use the policy file:

/etc/shorewall/policy on systems A &
B

#SOURCE DEST POLICY LOG LEVEL
loc vpn ACCEPT
vpn loc ACCEPT

On both systems, restart Shorewall and start OpenVPN. The systems in
the two masqueraded subnetworks can now talk to each other.

Roadwarrior

OpenVPN 2.0 provides excellent support for roadwarriors. Consider
the setup in the following diagram:

On the gateway system (System A), we need a zone to represent the
remote clients — we'll call that zone “road”.

/etc/shorewall/zones — System A:

#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
road ipv4

On system A, the remote clients will comprise the road zone.

In /etc/shorewall/interfaces on system
A:

#ZONE INTERFACE OPTIONS
road tun+

In /etc/shorewall/tunnels on system A, we need
the following:

#TYPE ZONE GATEWAY GATEWAY_ZONE
openvpn:1194 net 0.0.0.0/0

If you are running Shorewall 2.4.3 or later, you might prefer the
following in /etc/shorewall/tunnels 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.

#TYPE ZONE GATEWAY GATEWAY_ZONE
openvpnserver:1194 net 0.0.0.0/0

We want the remote systems to have access to the local LAN — we do
that with an entry in /etc/shorewall/policy (assume
that the local LAN comprises the zone “loc”).

#SOURCE DESTINATION POLICY
road loc ACCEPT

The OpenVPN configuration file on system A is something like the
following:

Roadwarrior with Duplicate Network Issue

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.

This may be accomplished by configuring a second server on your
firewall that uses a different port and by using NETMAP in your Shorewall configuration. The
server configuration in the above diagram is modified as shown
here:

The roadwarrior can now connect to port 1195 and access the lan on
the right as 172.20.1.0/24.

Roadwarrior with IPv6

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.

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.

The following excerpts from the Shorewall configuration show the
parts of that configuration that are relevant to these two tunnels (bold
font). This is not a complete
configuration.

Bridging Two Networks

Occasionally, the need arises to have a single LAN span two
different geographical locations. OpenVPN allows that to be done
easily.

Consider the following case:

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.

OpenVPN configuration on left-hand firewall:

remote 130.252.100.109
dev tap0
secret /etc/openvpn/bridgekey

OpenVPN configuration on right-hand firewall:

remote 206.124.146.176
dev tap0
secret /etc/openvpn/bridgekey

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.

Note

The stanzas below were written before bridges could be defined in
/etc/network/interfaces. For current usage, see bridge-utils-interfaces
(5).