Building a cheap secure wireless (WLAN) infrastructure with OpenVPN and Linux (an advanced tutorial of OpenVPN)

possibledisastrousSecurity

Dec 9, 2013 (3 years and 8 months ago)

99 views

(c) 2007 by Flosse R.

http://2blocksaway.com


Building a cheap secure wireless (WLAN) infrastructure with

OpenVPN and Linux (an advanced tutorial of OpenVPN)
Having “wireless LAN” access (WLAN) in your office is nowadays almost a given. The challenge

comes though on how to secure your WLAN and how to deploy it correctly. You probably want

the least overhead for administration and a very flexible, yet secure deployment. Since WLAN

access points (AP’s) have a semi limited range depending on your building, you might want to

deploy more then one AP per floor, or even one AP per meeting room. But creating different

networks for each meeting room is pretty much out of the question.
Also the fact that WEP encryption is not much of a cracking challenge nowadays (things like

kismet or kismac helps you do the dirty work) and adding every single MAC address to every

AP you have is a BIT cumbersome. What you really want is a very secure yet very simple VPN

solution. Using IPSec would be secure but you need a LOT of configuration and the

administrative overhead is or can be quite huge. OpenVPN is free (as in beer and speech),

uses SSL for encryption and only a single TCP (or UDP) port to communicate. Configuration

and installation for it is also very simple. This combination makes it an excellent choice for this

little project. So how do you do it? Simple, you have a central OpenVPN server on a separate

network and link all the AP’s to it.
What? Again, how? - Yes i can see the confusion here but in the next few paragraphs we will

go through all the steps necessary. If you have questions or comments of course feel free to

mail me or leave a comment.
First you need to be clear what you want to do. In the case of this tutorial we take the most

challenging setup and deploy one AP in each meeting room, this also gives us range to the

normal offices. 3 meeting rooms per floor and 2 floors. so we need 6 AP’s deployed. We also

want to give guests the chance to actually access the internet as an “added bonus”. One

caveat: In this tutorial we will use PKI and Certificates. However we will create a Certificate

Authority specifically for this how-to. For integration of this with your central CA check “the

OpenSSL for everything project”.
Now that we got this cleared, let’s move on.
Step 1: Outlining the setup
It is always a good practice is to visualize the layout. And for this kind of setup you might need

it later on when you get stuck. So here we have an outline of our desired result:
As you can see we need to have a central switch and each meeting room has to have an RJ-45

plug that is patched to that switch. Also on that switch has to be connected the OpenVPN

gateway and the Gateway to the internet, which could maybe be hooked up to an ADSL

connection OR tunneled through to your real internet gateway. You should run a proxy server

on it to disallow malicious surfing and have maybe a guest access procedure with

authentication. Also to mitigate “rogue” connections, make sure you place the APs not next to

a window or close to a door.
Step 2: Designing it all
As seen in the outline, to get this setup running smoothly we need the to design the following:

Placement of the AP’s in each meeting room. Make sure they are out of sight and

well situated.

Product selection for the AP’s, make sure you just take Access Points , no need for

Routers or Access points with heavy encryption. Simple ones will do (if you have any

recommendations leave them in the comments please).

Product selection for the switch. The switch should be quite good and should be

gigabit. The reason is that you want to provide the maximum bandwidth to each

Access point (making them 802.11g, so 54mbit). If you have 6x 54mbit going to

your switch that is already over 300mbit/s so its wiser to just buy a gigabit switch.

They don’t cost an arm and a leg anymore.

You need a server for OpenVPN, It has to have 2 gigabit ethernet cards and should

be reliable (read: RAID setup!), however it does not have to be a monster with

processor power or brand new. an entry level DELL Server will do just fine. Just

make sure you install Linux on it ( Fedora Core 6 for this tutorial)

For this how-to we use the LAN network of 172.10.1.0/24 which the clients will

access over the VPN.

You need to have 2 private IP networks separated for your setup, a class C (/24)

range should be enough unless you want to provide access to more then just ~250

users at once. For this tutorial, the “public” IP range will be 10.1.1.0/24 and the VPN

range will be 192.168.1.0/24 just to make it easier.

Name the AP’s according to where they are (e.g.: M2F3 = Meeting Room 2 Floor 3).

The OpenVPN Server IP in the public network will be 10.1.1.2, whereas the LAN IP

will be 172.10.1.45. It will also host the DHCP Server and the DNS Server for the

“public” network.

Make sure you have everyone’s name that has a laptop that will need access to the

LAN.
Also please create extensive documentation about the placement, the IPs and the Management

IPs of the AP’s etc. This is crucial for administration later on. I have seen cases where

everything was working very smoothly but for some reason something on one AP needed to be

changed and no-one knew the Management IP much less the password for the AP. This can be

delaying causes for something that could have been solved quickly.
An example of an IP and traffic map that might be necessary to understand everything is here:
Looking at pictures often helps you understand more then just plain text.
Step 3: Installing the backbone (OpenVPN)
After you have a clear picture of everything install Fedora Core 6 on your OpenVPN server. We

won’t go through the installation here but I think it is clear that you won’t need X or any GUI,

a simple minimal install is enough. Configure it that one network card is configured on your

internal LAN and one network card to the “public”, yes this machine will become a router. Don’t

worry we will secure it.
Now that you have a functioning Linux server, you can just log into it and type:
yum install openvpn
and hit enter. It will download all the packages and install OpenVPN for you. Once installed you

are ready to go to Step 4. But please make sure you have a regular update schedule for this

server, for security updates. Also make sure it is up to date (
yum update && yum upgrade
) before you bring it online as a production unit.
Step 4: Prepare the server (Certificates for OpenVPN)
Log into the OpenVPN Server and become root. Create the easy-rsa directory and copy the

necessary OpenVPN scripts in
/usr/share/openvpn/easy-rsa/2.0 to /etc/openvpn/easy-rsa

(Fedora Core 6 example:
mkdir /etc/openvpn/easy-rsa && cp -R /usr/share/openvpn/easy-rsa/2.0/* /etc/openvpn/easy-rsa/
).
Now change to the /etc/openvpn/easy-rsa directory and execute the following 3 commands:
. ./vars
./clean-all
./build-ca
And yes, that is a space on the . ./vars. The last command (build-ca) will ask you to enter

information to make your Certificate Authority. Write every information you put in down and fill

it in according to your company.Once done, you can do an ls -l in your
/etc/openvpn/easy-rsa

directory and will notice there is a new directory called keys. If you find files like this:
[root@shorty easy-rsa]# ls keys/ca.crt ca.key index.txt serial
in there, you are ready to go to the next command. The next command we will do will create a

certificate for the server. This will be used by your server to communicate with the clients. It is

special thats why it will be issued with the build-key-server command like so :
.
/build-key-server server
where “server” means the name of your server. That will make it easier later on for you to

identify the server certificate, and it adds a layer of personality :) . You will be asked again to

enter a lot of information, try using the same you used on the CA, but in the common name

use the servers hostname. Also, if you enter a password for the server certificate you will need

to enter this every time you restart the OpenVPN service, in my case i leave it blank but you

should add one. When you are prompted to “sign the certificate” say YES and also to the

COMMIT. Your response will be something like this:
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
In the keys directory you will now have 3 more files, the servername.key, .crt and .csr. You

need to complete 3 more commands and you are ready to go to configure everything :) . On a

note, from an infrastructure point of view, you are about 50% done.
You now need to create at least one client certificate so you can test connectivity later on. Do

not create client certificates yet for all your users. You can do that later since you need to get

the keys later all securely to the users anyway and teach them. Better make sure it works

before that.
The next command therefore is
./build-key admin
where admin is the user that will test this later (e.g. YOU!). Enter again all the information

necessary and this time make sure you GIVE a password. this password is the one that the

user will later on use to bring his VPN connection up. SIGN and COMMIT the process again and

tada you have your keys generated in the keys directory. Now you only need to build

encryption keys and authentication keys for the server and the clients and you are done.

Running the command
./build-dh
will take a while (about 20 seconds on a Pentium 4) but requires no user intervention and it

generates the file: dh1024.pem in your keys directory. This is the handshake mechanism

between the server and the client and to make that even stronger we generate a tls-auth key

as well. This requires each handshake to be signed before you can even start. :) very neat and

very secure. To do this run :
openvpn --genkey --secret keys/ta.key
You have now a nice long list of files in your keys directory. This is your most important

directory on the server, make backups of it whenever you have made new certificates etc.
Step 5.1: Configuring the Server (OpenVPN)
To configure the server you really can copy this config file and just change it as you need it. It

is pretty self explanatory and has tls-auth already included as well as compression and the

virtual device tun for routing. Notice that the the protocol is set to TCP. Its a personal choice

and you can use UDP as well. Also the keys are already pointing to the ones we have used in

this tutorial with the paths that we used. The Virtual Lan that the VPN clients will get their IPs

from is as we determined in the beginning 192.168.1.0/24. And we have set it so that split

tunneling is not allowed. This means that while connected to your VPN, the clients cannot

access any other network at the same time. Sometimes you can connect to a VPN and traffic

destined for that network will go there, everything else goes through “the internet” which we

will not allow here. When the clients connect, they should be setup as if they were physically

present in your LAN. The server config can be seen here:
#OpenVPN Server config file
# Which local IP address should OpenVPN listen on? (optional)
local 10.1.1.2
# Which TCP/UDP port should OpenVPN listen on?
port 1194
# TCP or UDP server?
proto tcp
# "dev tun" will create a routed IP tunnel, which is what we want
dev tun
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
;dev-node MyTap
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
ca keys/ca.crt
cert keys/server.crt
key keys/server.key # This file should be kept secret
# Diffie hellman parameters.
dh keys/dh1024.pem
# Configure server mode and supply a VPN subnet
server 192.168.1.0 255.255.255.0
# Maintain a record of client <-> virtual IP address
# associations in this file.
ifconfig-pool-persist ipp.txt
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push “route 172.10.1.0 255.255.255.0″
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
push “redirect-gateway”
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses.
;push “dhcp-option DNS 172.10.1.2″
# Uncomment this directive to allow different
# clients to be able to “see” each other.
client-to-client
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
# For extra security beyond that provided
# by SSL/TLS, create an “HMAC firewall”
# to help block DoS attacks and UDP port flooding.
tls-auth keys/ta.key 0 # This file is secret
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Enable compression on the VPN link.
comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
max-clients 250
# It’s a good idea to reduce the OpenVPN
# daemon’s privileges after initialization.
user nobody
group nobody
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
# Output a short status file showing
status openvpn-status.log
log-append openvpn.log
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 4
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
mute 20
5.2: Configuring the Server (DHCP)
You want to give all the WLAN clients an IP from a certain range. For that you need a DHCP

Server. I know that most APs come with a built in DHCP server but this is not a real option

since you want to have a central location AND you do not want each meeting room to have

their own IP range. Administration would become hell :) . Your DHCP server basically needs to

contain very little information for the clients.
The default gateway
The DNS Server
The network range for the IP pool and subnetmask
The DHCP Server should also reside on your OpenVPN server. to install it simply type
yum install dhcpd
Now all you need to do is enter the following information into the /etc/dhcpd.conf file:
option domain-name "youromain.com";
option domain-name-servers 10.1.1.2;
option subnet-mask 255.255.255.0;
default-lease-time 3600;
max-lease-time 86400;
ddns-update-style none;
subnet 10.1.1.0 netmask 255.255.255.0 {
range 10.1.1.10 10.1.1.254;
option routers 10.1.1.1;
}
Once done, save the file and do a
service dhcpd restart
and if it said you are OK, you are done.
Step 5.3: Configuring the Server (Public DNS)
Since we want a DNS Server for the “public” internet usage that we will provide to our visiting

clients, we will need to configure one. This is a very simple thing to do since you do not need a

specific domain zone for this, you just need to set the DNS server up so that it will forward all

requests to our ISPs public DNS servers. Since all legit corporate DNS traffic will come over the

VPN tunnel only there is no need to have any zone and corporate DNS information here. In the

/etc/named.conf
file look for something like:
options {
and add this line in between the {} :
forwarders { x.x.x.x, y.y.y.y };
Where x.x.x.x and y.y.y.y are the DNS servers of your ISP or the DNS servers you will use to

provide public DNS lookups. Save the file and do the service named restart and your DNS

Server. You are now ready to serve DNS requests, well forward them anyway.
Step 6: Configuring and installing the Access Points
This is the “boring” job of all of it. You need to configure each Access Point as such, as an

Access Point. you should assign a management IP to each one of them and select a VERY VERY

difficult password. Write it down though! Next you need to disable any DHCP servers on the

APs and also disable any WEP or WPA encryption. This way any client within range can connect

to it ,basically. At this point they wont get anywhere though. Connect one AP via the patch

cable to the switch where your server is connected. Then connect with any laptop to the AP

and see if you get an IP. If you do, ping the OpenVPN server. If you get a reply you are set and

can install the other APs as well, if not something needs to be re-checked :) .
Step 7: make the route changes (LAN router)
In order for your wireless clients to be able to use the LAN, the LAN needs to know about that

new VPN network you just spent so much time on creating. So , you need to add a route entry

on your main corporate ROUTER to route all traffic going to the VPN network (192.168.1.0) to

172.10.1.45 (the OpenVPN server). The OpenVPN server will handle the routing to and from

the VPN network but your LAN router needs to know where that network is located. Adding a

route to the main router will solve this problem as the main router knows where to send the

packets to.
Step 8: Configuring the Client (OpenVPN)
The good part about OpenVPN is that the client and server configuration files differ VERY little

from each other as you can see by looking at the client config here. The client configuration file

needs to be copied to each client. This is always “the same” file. The only thing you need to

change for each client is the names of the certificate files. For this example we will install and

configure 2 client software packages. Tunnelblick for MAC OS X and OpenVPN GUI for

Windows. At this point you should enable IP forwarding on the OpenVPN server for a while with

a simple command:
echo 1 > /proc/sys/net/ipv4/ip_forward
The reason why I mentioned temporarily is because your server is not yet fully secured. But

you need to test this all first so, enable it temporarily and disable it (
echo 0 > /proc/sys/net/ipv4/ip_forward
) when you are done.
Tunnelblick:
install Tunnelblick by downloading it from the internet and installing it as you

would any Mac software. Once installed you probably have to restart, or at least its beneficial.

Now, create a directory in the users home directory called openvpn and copy 5 files from the

servers KEYS directory into it: the 3 files that start with the users name, the ta.kay file and the

dh1024.pem file. You also need the client config with the certificate names correctly. HINT:

copy the 3 users files to the client computer and then rename them to something like

vpn.pem, vpn.crt etc. this way, all users will have the same names of the files on their

machines. and you can use a single client config that never needs to be changed. However on

the server you still have the certificate files in the users names.
OpenVPNGUI:
The OpenVPNGUI can be found online and the installation instructions included

are more then enough and not necessary to be repeated. BUT the great thing about the

OpenVPN Gui for Windows is that they include instructions to make a complete package that

the admin can just install and thats it, configuration included, just the certificate missing. The

how-to on this is here.
The client config on any operating system is the same and once you start either Tunnelblick or

OpenVPN GUI you should be able to browse the LAN and access network resources in your

corporate LAN. You can see the client config for this how-to here:
#OpenVPN Client config file
client
# Which TCP/UDP port/ip is the server listening on?
remote 10.1.1.2 1194
# TCP or UDP server?
proto tcp
# "dev tun" will create a routed IP tunnel, which is what we want
dev tun
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
# Most clients don't need to bind to
# a specific local port number.
nobind
# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
mute-replay-warnings
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
;dev-node MyTap
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
ca ca.crt
cert vpn.crt
key vpn.key # This file should be kept secret
# Diffie hellman parameters.
dh dh1024.pem
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server". The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
tls-auth keys/ta.key 1 # This file is secret
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Enable compression on the VPN link.
comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
max-clients 250
# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
user nobody
group nobody
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
log-append openvpn.log
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 4
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
mute 20
Step 9: Securing the server and enabling forwarding.
Now, we are almost done, so you have a VPN server, all access points are set and working, you

can access the “public” WLAN and you can get from your LAN to the VPN network.

Theoretically that should be it. Well not exactly, right now your OpenVPN server is wide open,

and it even forwards packages to the “public” network. You do not have a route to the public

network but return spoofing isn’t rocket science.
So you want to enable IP Forwarding permanently on that server but also make a firewall that

allows only connections on port 67 UDP (DHCP), 53 UDP (DNS) and 1194 TCP (OpenVPN). To

do this I have made a simple small IPTables script here but for in depth explanation and

learning please check the IPTables explained articles series.
Once you have the firewall up and running you are done, you can now connect clients to the

Wireless network and to your LAN. You should configure a proxy for public internet access but

that is not part of this tutorial. Though this tutorial is pretty in-depth it is not fully 100%

complete and you will need to read up on things to understand them better. But this at least

should give you a pretty good introduction and get you pretty much 80% there.