OpenVPN
From SOWNWiki
Update Needed
This page needs to be updated
The OpenVPN configuration files have changed so this page needs updating
| OpenVPN | |
|---|---|
| |
| Installed on | sown-auth2, sown-vpn2, SOWN(at)HOME Node |
| Was installed on | |
| Website | http://www.openvpn.net/ |
Contents
OpenVPN on SOWN
"OpenVPN is an open-source software application that implements virtual private network (VPN) techniques for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities."
SOWN runs its primary OpenVPN server on sown-auth2 to which SOWN(at)HOME Nodes connect as clients. sown-vpn2 runs OpenVPN server for supporting development work on SOWN(at)HOME Node firmware.
OpenVPN also has the ability to keep state of which clients are connected and clients will attempt automatic reconnection if the server gets lost. OpenVPN can distribute routes to the clients automatically. All these features have been successfully implemented for IPv4 only at the moment.
For help on generating the keys on the server for the clients see openvpn.net/howto.html for a good guide. This is a pretty basic operation which involves running the scripts which exist in /usr/share/doc/openvpn/examples/easy-rsa/2.0/
Q: How do you generate addition client keys after the initial keygen process has been complete?
A: # cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/
# source ./vars
# ./pkitool clientX
The SOWN Config
The Server
files in /etc/openvpn:
ca.crt
ca.key
dh1024.pem
server.crt
server.key
server.conf
/etc/openvpn/server.conf
port 1194
proto tcp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
#magical route statement.
#This will automatically route traffic to nodes subnets which can start at 10.13.129 or above
#Note that openvpn will assign 10.13.129+ to clients if there are more than 254, maybe start at 132
server 10.13.128.0 255.255.240.0
#connect to sown via vpn tunnel
push "route 10.13.0.0 255.255.0.0"
push "dhcp-option DNS 10.13.0.253"
client-to-client
#Allow 1 client certificate to be used many times
duplicate on
keepalive 10 120
#Downgrade level of access once tap/tun is created (which ssh doesn't have...yet)
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn-status.log
log /var/log/openvpn.log
log-append /var/log/openvpn.log
verb 3
The following part of the config could prove useful if you want to perform operations upon client connection since we are only having one tap device (I think).
# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script
The Client
NEW: Download the get_vpn_keys script from http://auth.sown.org.uk/vpn-keys/get_vpn_keys and run this with your node subnet as the first argument to get your keys: e.g. ./get_vpn_keys 131.
files in /etc/openvpn:
ca.crt
client1.crt
client1.csr
client1.key
client.conf
update-resolv-conf
client1.conf
client
dev tap
proto tcp
remote auth.sown.org.uk
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
status /var/log/openvpn-status.log
log /var/log/openvpn.log
log-append /var/log/openvpn.log
verb 3
Running
On the server
openvpn /etc/openvpn/server.conf &
On the client
openvpn /etc/openvpn/client1.conf &
No additional rip routing is required and all of the routes are nicely aggregated, keeping the routing tables on the sown servers nice and clean. Next IPv6 of which there are some notes in the section below.
Routing on the SOWN Servers
To make the routes nice and clean the vpn routes are static which means that every sown server (bar sown-vpn to which the tunnels are connected needs the following added to /etc/init.d/setup_routes
#!/bin/sh -e
case "$1" in
start)
`route add -net 10.13.128.0/17 gw 10.13.0.253`
;;
stop)
`route del -net 10.13.128.0/17 gw 10.13.0.253`
;;
esac
exit 0
And then linked on boot up:
ln -s /etc/init.d/setup_routes /etc/rcS.d/S50setup_routes
OpenVPN NOTES
An alternative to OpenSSH tunnels has been proposed which would use OpenVPN as a point to point authenticated layer 2 tunnel. This would appear to the network as identical to the Pptp-ssh system.
An OpenVPN connection requires a client and a server. The server runs on a central machine and the client on the access point. To establish a connection the client and server must have a public/private key pair which is signed by the same certificate authority.
Each OpenVPN server listens on its own port (5000-5050)
Setting Up OpenVPN
A good guide to setting up OpenVPN can be found on the the openVPN website at openvpn.net/howto.html. For SOWN we need to do the following:
- Setup a CA
- Setup the servers
- Setup the node
Setup a CA
Install OpenVPN in a way aproprite to your system. For Debian
apt-get open-vpn
should be sufficiant The install should have created a directory /usr/share/doc/packages/openvpn or prehaps /usr/share/doc/openvpn-2.0. In that directory should be the following scripts vars, clean-all, build-ca and more. Run the vars script to update the default values for certificates. Now run clean-all to clear any previous keys and finaly run build-ca, this will create you a CA.
build-ca should produce the following:
./build-ca Generating a 1024 bit RSA private key ............++++++ ...........++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [KG]: State or Province Name (full name) [NA]: Locality Name (eg, city) [BISHKEK]: Organization Name (eg, company) [OpenVPN-TEST]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:OpenVPN-CA Email Address [me@myhost.mydomain]:
You now have a working CA
Setup the Servers
Each server will require a public/private key pair which in turn must be signed by the CA. All the servers could (and possibly should) share the same public/private key pair.
To build a server key called 'server' run the following command:
./build-key-server server
assuming or course that you were in the same directory as the build-key-server script.
Now you can confgure the server startup script here is an example for server number 10
#Server 10 Config File local $ipOfVPNserver #This prevents routers/computers trying to be clever and causing cahos. port 5010 proto udp #should be tcp if connection tracking is needed dev-type tap dev tun10 #linux may need re-configuring to support more than 4 tap devices ca /etc/vpn/vpnca.crt #path to CA certificate used to sign client and server keys cert /etc/vpn/VPN.crt #path to the server certificate signed by the CA key /etc/vpn/VPN.key #path to the servers private key dh /etc/vpn/dh1024.pem #path to the DH thing created earier server-bridge 172.16.13.37 255.255.255.252 172.16.13.38 172.16.13.38 keepalive 10 120 #Stop NAT from timing out due to inactivity user nobody #user to drop privilages to group nobody persist-key #Load key into memory to avoid sharing problems persist-tun #Can't remember, setting it can't hurt surely? status /var/log/openvpn/openvpn-status-10.log #location of the log for this connection
The server should now work by running the following commands
/usr/local/sbin/openvpn --config /etc/vpn/server10.conf --daemon tunnel-10 ifconfig tun10 link0 ifconfig tun10 inet6 2001:2001:630:c2:0901::37 prefixlen 126 alias
The v6 addreses can be pushed by OpenVPN in the same way v4 adresses can.
Setup the node
The client needs a public private key pair like the server. The clients can share the same key but probably should not in case a user's access needs to be revoked.
To create the client key
./build-key client
Copy the generated files to the client (node).
All clients need to connect to the same port now so the config file looks like so:
client #OpenVPN should run as a client dev tap0 #bind to tap0 so Linux knows what it is doing proto udp #TCP may have to be used but udp is better remote $serverIP 1194 resolv-retry infinite #Never give up never surrender nobind #Don't bind to a specific port persist-key #Load the keys into memory persist-tun #Keep the tunnel working ca /etc/vpn/vpnca.crt #path to CA certificate cert /etc/vpn/client.crt #path to client certificate key /etc/vpn/client.key #path to client private key verb 3 #lots of logging!
To start the client try:
#! /bin/sh echo "Starting VPN" /usr/sbin/openvpn --config /etc/vpn/client.conf --daemon sleep 5 ip -6 addr add 2001:2001:630:c2:0901::38/126 dev tap0 ip -6 route add ::/0 via 2001:2001:630:c2:0901::37 echo "Creating bridges" brctl addbr br0 brctl addbr br1 brctl addif br0 eth0 brctl addif br0 ath2 brctl addif br1 ath0 brctl addif br1 ath1 ip -6 addr add 2001:2001:630:c2:0937::1/64 dev br1 ip -6 addr add 2001:2001:630:c2:0938::1/64 dev br0 #Start Quagga /usr/lib/quagga/zebra -d sleep 1 /usr/lib/quagga/ripngd -d
This script needs customising to what SOWN is curently doing. The v6 tunnel addresses should be pushed by the VPN server. The script also thinks that ath0 and ath1 are SOWN virtual APs and ath2 is the WPA encrypted virtual AP for connecting the the users home network. ath1 is the 1x virtual access point. These things are still in development so the script can be simplified.
Quaagga
Here are some Quagga files to compliment the above setup. They need modifying to actualy work.
zebra.conf
! ! Zebra configuration ! password **** enable password **** log syslog ! !Interfaces ! !Home network bridge !This bridge comprises of the WPA encrypted access point and eth0 interface br0 no ipv6 nd suppress-ra ipv6 nd prefix 2001:2001:630:c2:0938::/64 ! !SOWN Bridge !This bridge consists of the sown-1x interface and the sown-nodename interface interface br1 no ipv6 nd suppress-ra ipv6 nd prefix 2001:2001:630:c2:0937::/64 ! !Loop back interface interface lo ! !Tunnel interface back to tunnel broker interface tap0 ipv6 nd suppress-ra ! ipv6 forwarding ! line vty !
ripngd.conf
! ! RIP-NG configuration ! password **** enable password **** log syslog ! router ripng network tap0 route 2001:2001:630:c2:0938::/64 route 2001:2001:630:c2:0937::/64 ! line vty !