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/

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

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

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

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!

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.