less openvpn-setup-guide-on-debian-routed-and-bridged-vpn.md
OpenVPN: setup guide on Debian (routed and bridged VPN)
# historical archive — written years ago, kept as it was. Some info is dated.
A rather delicate and at the same time very fascinating topic! The solution I’m proposing lets you connect to a central server both other machines by exploiting network bridging (TAP), and mobile devices using network routing (TUN).
The main prerequisite is knowing the concept of a Virtual Private Network (VPN) and consequently a good part of the world behind it. You can find an initial and interesting read on what a VPN is by following the relevant link on wikipedia.
Summarizing the concept very briefly, I think we can say that:
“…a VPN is the extension of a private local network that connects together servers and clients variously located across a wide territory by exploiting a public Internet connection to effectively build a LAN network, called precisely virtual and private, completely equivalent to a physical network infrastructure (that is, with physical connections) specifically dedicated.”
To be honest, the difficulties I encountered in building my personal VPN were not few. Tens of thousands of guides proliferate on the net. If you don’t find something you need in this one, all that’s left is to search.
Disclaimer: Be careful about what we’re about to build. Any mistakes can expose your internal network to some malicious actor, so proceed with caution! A VPN has in the security of data transmission its reason for existing, but remember that the first bulwark when it comes to security is you!
I’ll tell you right away that authentication to our VPN will happen through the issuance of digital certificates. If any certificate should be lost or stolen, you just need to revoke it to prevent access to the network. Other types of authentication can be easily implemented but will not be covered in this guide.
CREATE A BRIDGE
OpenVPN will be the software that lets us create our private network. First let’s take care of creating a network bridge (br0).
apt-get install uml-utilities bridge-utils
Let’s activate the relevant module in the kernel
modprobe tun
The following command serves to make permanent the creation of the special loopback device tap0, assigning it to a specific user: for example the user nobody
/usr/sbin/tunctl -t tap0 -u nobody
Now the time has come to remove any prior configuration of the network interfaces that will become part of the network bridge
ifconfig eth0 0.0.0.0 promisc up
ifconfig tap0 0.0.0.0 promisc up
Let’s create our bridge and add the network devices to it
brctl addbr br0
brctl addif br0 tap0
brctl addif br0 eth0
Check with the command brctl show that everything is in order
bridge name bridge id STP enabled interfaces
br0 8000.1c6f653460a7 no eth0
tap0
The time has come to bring up the special device, assigning it an IP
ifconfig br0 up
ifconfig br0 10.105.1.150/24
route add default gw 10.105.1.1
if the route is set correctly the command /sbin/route -n should return something like this
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.105.1.1 0.0.0.0 UG 0 0 0 br0
10.105.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
Now we should have network connectivity on both network interfaces. To make permanent what we’ve done so far, it will be necessary to appropriately modify the file /etc/network/interfaces. Below is an example based on mine. The IP address of the bridge and consequently of the network interface will have to be corrected according to your subnet.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
auto br0
#iface br0 inet dhcp
iface br0 inet static
bridge-ports eth0 tap0
bridge_stp on
bridge_hello 2
bridge_maxage 12
bridge_prio 1000
bridge_maxwait 0
address 10.105.1.150
netmask 255.255.255.0
gateway 10.105.1.1
# The primary network interface
auto eth0
iface eth0 inet manual
up ip link set $IFACE up
down ip link set $IFACE down
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
up brctl addif br0 $IFACE || true
down brctl delif br0 $IFACE || true
auto tap0
iface tap0 inet manual
pre-up /usr/bin/tunctl -t tap0 -u nobody
up ip link set $IFACE up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ip link set $IFACE down
up brctl addif br0 $IFACE || true
down brctl delif br0 $IFACE || true
INSTALL OPENVPN
The time has come to install openvpn and configure its daemon.
apt-get install openvpn
We’ll need to start by creating the files of our Certification Authority
Let’s proceed with creating the necessary certificates. Below is a cross-section of commands that may serve the purpose.
cp -r /usr/share/easy-rsa/ /etc/openvpn
mkdir -pv /etc/openvpn/easy-rsa/keys
sed -ie 's/KEY_NAME="EasyRSA"/KEY_NAME="MyVPN"/' /etc/openvpn/easy-rsa/vars
openssl dhparam -out /etc/openvpn/dh1024.pem 1024
cd /etc/openvpn/easy-rsa && . ./vars
# Optionally set indentity information for certificates:
# export KEY_COUNTRY="<%COUNTRY%>" # 2-char country code
# export KEY_PROVINCE="<%PROVINCE%>" # 2-char state/province code
# export KEY_CITY="<%CITY%>" # City name
# export KEY_ORG="<%ORG%>" # Org/company name
# export KEY_EMAIL="<%EMAIL%>" # Email address
# export KEY_OU="<%ORG_UNIT%>" # Orgizational unit / department
cd /etc/openvpn/easy-rsa && ./clean-all
cd /etc/openvpn/easy-rsa && ./build-ca --batch
cd /etc/openvpn/easy-rsa && ./build-key-server --batch server
cp /etc/openvpn/easy-rsa/keys/server.crt /etc/openvpn
cp /etc/openvpn/easy-rsa/keys/server.key /etc/openvpn
cp /etc/openvpn/easy-rsa/keys/ca.crt /etc/openvpn
cp /etc/openvpn/easy-rsa/keys/crl.pem /etc/openvpn
cd /etc/openvpn/ && openvpn --genkey --secret ta.key
Now let’s move on to configuring the server. What follows has, for example, the objective of creating two different openvpn instances that will allow two subnets to be connected so that the iOS devices, for example, can see the PCs and servers on the net and vice versa.
Consider that the subnet 10.105.1.0/24 will be used for most of the servers and PCs, while the subnet 10.105.2.0/24 will be dedicated to mobile devices such as iOS devices, as well as all those that don’t make it possible to use the tapX interface but rather the tunX one.
SERVER “Bridging Mode”
Let’s take a look at the file /etc/openvpn/server.conf
mode server
proto udp
port 1194
dev tap0
client-to-client
client-config-dir ccd
tls-server
tls-auth ta.key 0
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
crl-verify crl.pem
keepalive 10 120
daemon
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
mute 20
script-security 3 system
cipher AES-256-CBC
auth sha256
push "route 10.105.2.0 255.255.255.0 10.105.1.150"
push "route-delay 5 600"
The two push directives at the bottom of the file will make more sense at the end of everything. They will serve those who connect to the VPN to correctly set up traffic toward the IPs of the “mobile” subnet.
In the file are present the directives on the certificates that will need to be created before starting the server and that will also be necessary for creating the keys for the clients.
Let’s proceed with creating the necessary certificates. Below is a cross-section of commands that may serve the purpose.
cp -r /usr/share/easy-rsa/ /etc/openvpn
mkdir -pv /etc/openvpn/easy-rsa/keys
sed -ie 's/KEY_NAME="EasyRSA"/KEY_NAME="MyVPN"/' /etc/openvpn/easy-rsa/vars
openssl dhparam -out /etc/openvpn/dh1024.pem 1024
cd /etc/openvpn/easy-rsa && . ./vars
# Optionally set indentity information for certificates:
# export KEY_COUNTRY="<%COUNTRY%>" # 2-char country code
# export KEY_PROVINCE="<%PROVINCE%>" # 2-char state/province code
# export KEY_CITY="<%CITY%>" # City name
# export KEY_ORG="<%ORG%>" # Org/company name
# export KEY_EMAIL="<%EMAIL%>" # Email address
# export KEY_OU="<%ORG_UNIT%>" # Orgizational unit / department
cd /etc/openvpn/easy-rsa && ./clean-all
cd /etc/openvpn/easy-rsa && ./build-ca --batch
cd /etc/openvpn/easy-rsa && ./build-key-server --batch server
cp /etc/openvpn/easy-rsa/keys/server.crt /etc/openvpn
cp /etc/openvpn/easy-rsa/keys/server.key /etc/openvpn
cp /etc/openvpn/easy-rsa/keys/ca.crt /etc/openvpn
cp /etc/openvpn/easy-rsa/keys/crl.pem /etc/openvpn
cd /etc/openvpn/ && openvpn --genkey --secret ta.key
SERVER “Routing Mode”
If everything went well, bringing up the second instance that will take care of allowing mobile devices to connect will be extremely simple. Below is a cross-section of the server_mobile.conf file
proto tcp-server
port 1194
dev tun0
tcp-nodelay
tls-server
tls-auth ta.key 0
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
crl-verify crl.pem
user nobody
group nogroup
persist-key
persist-tun
cipher BF-CBC
auth SHA1
comp-lzo
script-security 3 system
keepalive 30 120
status /var/log/openvpn/openvpn-statusmobile.log
log /var/log/openvpn/openvpn-mobile.log
verb 3
client-config-dir ccd
mode server
topology "subnet"
push "topology subnet"
server 10.105.2.0 255.255.255.0
push "route-delay 5 600"
route 10.105.2.0 255.255.255.0
ifconfig-pool-persist ipp_mobile.txt
push "route 10.105.1.0 255.255.255.0"
client-to-client
client-connect "/etc/openvpn/connect"
client-disconnect "/etc/openvpn/disconnect"
up "/etc/openvpn/up_mob.sh"
#push "redirect-gateway def1 bypass-dhcp"
#push "dhcp-option DNS 8.8.8.8"
#push "dhcp-option DNS 8.8.4.4"
The last lines that follow might serve you should you wish to make all the internet traffic of the mobile devices pass through the VPN. Honestly, I prefer to choose at the client level whether and when to take advantage of the benefit. After all, the VPN is yours and you use it as you please. I absolutely cannot suggest here the benefits of using a VPN that redirects traffic entirely through the VPN server. Just think about what benefits you could take advantage of when you’re abroad and your server is in Italy at your home…
The time has come to restart openvpn, checking for the absence of any errors.
systemctl restart openvpn
CLIENT CONFIGURATION
This last part goes through two aspects: generating the certificates (one per single client) and the configuration file to use to connect to the central server.
What follows is a small script that I use and that greatly simplifies the task for me.
#!/bin/sh
if [[ -z "$1" ]]; then
echo "Inserisci il CN del futuro client"
echo "Usage: $0 "
exit 1
fi
cd /etc/openvpn/easy-rsa/
. ./vars
. ./build-key --batch $1
The client that connects to the server in Bridging Mode will have a configuration of this type:
client
dev tap
proto udp
remote IPOFYOURSERVER 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
keepalive 6 180
tls-auth ta.key 1
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
float
ping-timer-rem
reneg-sec 3600
mute-replay-warnings
ping 15
verb 6
pull
mute 20
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn-append.log
tls-cipher TLS-RSA-WITH-AES-256-CBC-SHA
cipher AES-256-CBC
auth sha256
script-security 2
What follows is an example configuration for the clients that will connect in Routing Mode
client
dev tun
tls-client
remote IPYOURSERVER 1194
pull
#ca ca.crt
#cert 6_plus.crt
#key 6_plus.key
#tls-auth ta.key 1
comp-lzo
proto tcp
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
float
key-direction 1
#
# 2048 bit OpenVPN static key
#
<CHIAVE/CERTIFICATO REDATTO — esempio>
<CHIAVE/CERTIFICATO REDATTO — esempio>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 16 (0x10)
Signature Algorithm: sha1WithRSAEncryption
...
<CHIAVE/CERTIFICATO REDATTO — esempio>
<CHIAVE/CERTIFICATO REDATTO — esempio>
Done!
If you need clarifications, just ask… Have fun!!!
References:
http://manpages.ubuntu.com/manpages/precise/man8/tunctl.8.html