OpenVPN

How to run OpenVPN inside the current version of vserver patch (tested on 2.0.2 an some earlier versions)

Note : I don't think it's The Good Way (tm) in the long term, but it works just fine.

Tested with tun mode openvpn, not in tap mode.

1. Configure OpenVPN on the host computer (give it a key, config file,...)
2. Configure the vservers so that they get access to bindings of the openvpn tun interface with a unique IP, i.e. : IPROOT="tunX:a.b.c.d" (among other interfaces if wanted)
3. Configure the OpenVPN server to use a ccd (see client-config-dir)
4. Add a configuration named after the key common name of the vserver host
5. Add "iroute" entries to that file so the OpenVPN server knows where the IP resides.

Here you are. You should be able to access the VPN from inside the vserver, and access the vserver from the VPN.

Now a more tricky part : giving internet access to a vserver having only a vpn IP (SNAT)

The problem is that the routing table is shared among the host and the vserver, so you can't replace the 0.0.0.0 route by something using the OpenVPN server VPN address.

The solution is to add a second routing table with special application scope :

ip rule add from 10.0.0.112/28 lookup 2

This will make all routing for the 10.0.0.112 .. 10.0.0.127 ip range (adapt it to match the vserver vpn address, this examples can route 14 consecutives VPN address on the same host). Why do I use table 2 ? Just a random choice :). Just make sure the table numbers matches the other in the rule and that you don't use something already used. I have no ide if there is any convention in that area.

Then add the default gateway rule:

ip route add default via 10.0.0.110 dev tun0 table 2

10.0.0.110 being the IP of the host. Here is something quite strange - for me - : the packets are rerouted to the openvpn server even if the vserver host IP is given... So it's the one we will configure as a gateway (shorewall configuration extracts) :

/etc/shorewall/mask
eth0 10.0.0.0/24
/etc/shorewall/policy
vpn net ACCEPT

Last step is to configure the resolv.conf inside the vserver (but is it worth mentioning ? :) ).

Make the services reload their configurations and voila.

I think something likewise should be possible to allow DNAT (port forwarding), but I hadn't any need for that so I didn't try.