OpenVPN Tunnels
Simon
Mater
Tom
Eastep
2005-10-12
2003
2004
2005
Simon Mater
Thomas M. Eastep
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
.
This article applies to Shorewall 3.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/.
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 OUT
# OPTIONS 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 BROADCAST 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
Shorewall versions prior to 2.2.0 Beta 1 enforced use of the same
port number for both the source and destination port.
Some OpenVPN clients (notabley on Windows)
do not use the same source and destination ports which can cause
problems. If system B is a Windows system or if you find that Shorewall
is blocking the UDP port 1194 traffic from the remote gateway and you
are running a version of Shorewall prior to 2.2.0 Beta 1, then you will
want the following entry in /etc/shorewall/tunnels
instead of the one above:
#TYPE ZONE GATEWAY GATEWAY ZONE
generic:udp:1194 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
This is the OpenVPN config on system A:
dev tun
local 206.162.148.9
remote 134.28.54.2
ifconfig 192.168.99.1 192.168.99.2
up ./route-a.up
tls-server
dh dh1024.pem
ca ca.crt
cert my-a.crt
key my-a.key
comp-lzo
verb 5
Similarly, On system B the 192.168.1.0/24 subnet will comprise the
vpn zone
In /etc/shorewall/interfaces on system
B:
#ZONE INTERFACE BROADCAST OPTIONS
vpn tun0 192.168.1.255
In /etc/shorewall/tunnels on system B, we
have:
#TYPE ZONE GATEWAY GATEWAY ZONE
openvpn net 206.191.148.9
And in the OpenVPN config on system B:
dev tun
local 134.28.54.2
remote 206.162.148.9
ifconfig 192.168.99.2 192.168.99.1
up ./route-b.up
tls-client
ca ca.crt
cert my-b.crt
key my-b.key
comp-lzo
verb 5
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 OUT
# OPTIONS OPTIONS
road ipv4
On system A, the remote clients will comprise the road zone.
In /etc/shorewall/interfaces on system
A:
#ZONE INTERFACE BROADCAST 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:
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
Configuration on the remote clients follows a similar line. We
define a zone to represent the remote LAN:
/etc/shorewall/zones — System B:
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
home ipv4
On system A, the hosts accessible through the tunnel will comprise
the home zone.
In /etc/shorewall/interfaces on system
B:
#ZONE INTERFACE BROADCAST OPTIONS
home tun0
In /etc/shorewall/tunnels on system B, we need
the following:
#TYPE ZONE GATEWAY GATEWAY ZONE
openvpn:1194 net 206.162.148.9
Again in you are running Shorewall 2.4.3 or later, in
/etc/shorewall/tunnels on system B you might
prefer:
#TYPE ZONE GATEWAY GATEWAY ZONE
openvpnclient:1194 net 206.162.148.9
We want the remote clien to have access to the local LAN — we do
that with an entry in /etc/shorewall/policy.
#SOURCE DESTINATION POLICY
$FW home ACCEPT
The OpenVPN configuration on the remote clients is along the
following line:
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
If you want multiple remote clients to be able to communicate openly
with each other then you must:
Include the client-to-client
directive in the server's OpenVPN configuration; and
Specify the routeback option on
the tun+ device in /etc/shorewall/interfaces.
If you want to selectively allow communication between the clients,
then see this
article by Marc Zonzon
Securing a Home Wireless Network with OpenVPN (OpenVPN
Bridge)
This section will discuss how I secured my home wireless network
using OpenVPN. Our network is as shown in the following diagram.
The Wireless zone is in the lower right of the diagram and consists
of two laptops: Eastepnc6000 (Windows XP - SP1) and Tipper (SuSE 10.0). We
use OpenVPN to bridge those two laptops with the Local Zone shown in the
lower left hand corner. The laptops are configured with addresses in the
192.168.3.0/24 network connection to the firewall's eth0 interface which places them in the
firewall's Wifi zone. OpenVPN bridging allows them to be assigned an
additional temporary IP address from the 192.168.1.0/24 network and to be
securely bridged to the LAN on the lower left.
Configuring the Bridge
The firewall runs Debian Sarge so the bridge is defined in
/etc/network/interfaces.
# 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 tun0 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
up ip route add 224.0.0.0/4 dev br0
post-down /usr/sbin/brctl delif br0 eth3
post-down /usr/sbin/brctl delif br0 tap0
post-down /usr/sbin/brctl delbr br0
post-down /usr/sbin/openvpn --rmtun --dev tap0
Note that the IP address assigned to the bridge is 192.168.1.254
-- that is the default gateway address for hosts in the local
zone.
Configuring OpenVPN
We use X.509 certificates for authentication.
Firewall (Server) configuration.
/etc/openvpn/server-bridge.conf defines a bridge and reserves IP
addresses 192.168.1.64-192.168.1.71 for VPN clients.
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
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
verb 3
Tipper Configuration
/etc/openvpn/wireless.conf:
dev tap
remote 192.168.3.254
tls-remote gateway.shorewall.net
client
route-gateway 192.168.1.254
up /etc/openvpn/wireless.up
down /etc/openvpn/wireless.down
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
/etc/openvpn/wireless.up changes the default gateway to
192.168.1.254
ip route replace default via 192.168.1.254 dev tap0
/etc/openvpn/wireless.down restores the default gateway to
192.168.3.254
ip route replace default via 192.168.3.254 dev eth0
Configuring Shorewall
In this configuration, we don'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 becomes as described in the Simple Bridge documentation.
Firewall
/etc/shorewall/interfaces
Note that the bridge (br0) is defined as the interface to the
local zone and has the routeback
option.
#ZONE INTERFACE BROADCAST OPTIONS
net eth2 206.124.146.255 dhcp,norfc1918,logmartians,blacklist,tcpflags,nosmurfs
loc br0 192.168.1.255 dhcp,routeback
dmz eth1 - logmartians
Wifi eth0 192.168.3.255 dhcp,maclist
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
/etc/shorewall/tunnels
#TYPE ZONE GATEWAY GATEWAY
# ZONE
openvpnserver:1194 Wifi 192.168.3.0/24
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Tipper
/etc/shorewall/zones
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
home ipv4 #Wired LAN at our home
net ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
/etc/shorewall/interfaces
#ZONE INTERFACE BROADCAST OPTIONS
#
net eth0 detect routefilter,dhcp,tcpflags
home tap0 192.168.1.255
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
/etc/shorewall/policy
Since we don't expect any traffic between the net zone and the home zone, we use NONE policies for that
traffic. If any such traffic should occur, it will be handled
according to the all->all policy.
#SOURCE DEST POLICY LOG LIMIT:BURST
# LEVEL
fw net ACCEPT
fw home ACCEPT
home fw ACCEPT
net home NONE
home net NONE
net all DROP info
# The FOLLOWING POLICY MUST BE LAST
all all REJECT info
#LAST LINE -- DO NOT REMOVE