I've seen an openvpn deployment as server, where clients use pre-shared keys and certificates for authentication, with only one config file and each client with his certificate
further more, the traffic rules between the networks can be settled via netfilter
I'll try to install it this weekend and come up with a howto
@@@@ later edit
1 - follow http://www.openvpn.net/index.php/open-source/documentation/howto.html#pki for issuing certificates with the built-in tools of openvpn
2 - server config
local 1.2.3.4
port 1977
proto tcp
dev tap-server
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/server.crt
key /etc/openvpn/certs/server.key
dh /etc/openvpn/certs/dh1024.pem
server 172.17.188.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/var/pool.txt
client-to-client
keepalive 10 120
#tls-auth /etc/openvpn/certs/ta.key 0
#cipher DES-EDE3-CBC
max-clients 10
persist-key
persist-tun
status /var/log/openvpn/server-status.log
log-append /var/log/openvpn/server.log
verb 3
mute 10
push "route 10.0.0.56 255.255.255.255"
#client-config-dir /etc/openvpn/var/routes
3 - on the client side, along with ca.crt and user.(key,csr,crt)
remote 1.2.3.4
client
dev tap
nobind
port 1977
proto tcp-client
persist-key
persist-tun
ping-timer-rem
ping-restart 60
ping 10
verb 3
ca ca.crt
cert user.crt
key user.key
you can have various settings starting from this schema, following openvpn's examples
I have implemented something along these lines before, but my setup was fairly complicated, perhaps too much so. I am currently investigating implementing a simpler solution along the lines of / influenced by what is described at the following URL, but I will describe what I have built in the mean time. The URL is http://www.linuxjournal.com/article/9915
One option which has worked quite well for me in the past is to build my OpenVPN tunnels using tap devices instead of tun devices. This encapsulates Ethernet over the tunnel instead of layer 3, and it allows you to workaround the inherent limitations of OpenVPN maintaining its own routing table separate from the kernel. The downside is you incur a lot of overhead from tunneling this way... imagine TCP over Ethernet over TCP encrypted SSL... you get the idea. Upside is it has worked and scaled out horizontally fairly well.
Assuming your VPN servers and clients are Linux endpoints (I have only tested on Linux), you can create a new virtual bridge interface and assign the tap interface to the bridge to get your layer 3. In my topology, I gave each VPN server its own 10.x.0.0/16 subnet and also deployed a local DHCP server to assign addresses to connecting clients. The DHCP server needs to be there because OpenVPN is no longer aware of IP addresses; it is tunneling Ethernet. Clients run dhclient to get an IP over the VPN interface after connecting, and this is all managed by connect-scripts tied to the OpenVPN configuration.
Once you have IP addresses on both sides via DHCP you can use a dynamic routing protocol to advertise routes between connected clients. I have used Quagga in the past, and it works quite reliably.
Example server configuration using tap:
mode server
proto tcp-server
port 1194
dev tap0
Example commands to add tap interface to new bridge:
sudo brctl addbr vpnbr0 # create new bridge called vpnbr0
sudo brctl setfd vpnbr0 0 # set forwarding delay to 0 secs
sudo brctl addif vpnbr0 tap0 # add openvpn tap interface to vpnbr0
Example teardown commands:
sudo brctl delif vpnbr0 tap0
sudo brctl delbr vpnbr0
Once you have the vpnbr0 bridge interface, you can run a DHCP server on it or assign IP addresses manually. You can then treat it like any other Ethernet interface. You would probably want to make additional changes to adjust MTU size, and you might try different protocols and encryption options until you found the right balance between efficiency and security. I don't have any good specs to offer anymore on overall throughput, and there are a whole lot of moving parts here.
If I had it to do over again, I would stick with tun devices in OpenVPN, and I would follow the instructions in the article I linked in the first paragraph to update the Linux kernel's routing table anytime OpenVPN's internal address table updated. This would eliminate DHCP from the stack, reduce tunneling overhead, and would allow my clients to connect and operate without participating in dynamic routing.
Best Answer
The FAQ -- Running an OpenVPN server on a dynamic IP address
There is some more conversation at the Slashdot page on
VPN Solutions for Distributed Installations, if you don't mind sifting through it.