parallaxed.net

So I set myself a mission to overcome firewall restrictions for full ‘net access through the university campus connection. There’s nothing in the ToC that explicitly says you’re not allowed to tunnel out of their arsey setup. It first started to peev me off when I was unable to watch FLVs at a reasonable connection speed, due to some packet inspection and IP buckets placed to snare addicted YouTubers. I’m not partial to youtube overdoses, but I do like to see some online video without being transported back to the days of endless RealMedia-esque “buffering…”

First and obvious solution, VPN – but boy was that more of a headache than I could’ve anticipated. Thankfully, the software itself (OpenVPN) was flawless and the configuration was only encumbered by stupidity/misapprehension on my part. So here I outline those oversights, and describe with brevity how to set up an OpenVPN connection to work through an SSH tunnel.

My client in this case was Server 2003, but that shouldn’t affect your ability to use OpenVPN as long as you own the box.

Minimum Requirements:

• An external box you have a reasonable degree of control over, running Windows or *nix
• A free couple of hours and beverage of choice

What you’re going to do:

• Tunnel out through an open port over SSH
• Loop back through localhost to your VPN server
• Win

1. Grab putty if you’re on Windows.
2. Grab and install OpenVPN on client and server.
   This will ask you to install a Tap32 device or something similar, let it get on with that and you’ll have a new network connection pop up on your system (check control panel). If that step failed, there’s a nifty FAQ that deals with common problems. OpenVPN will install a system service. Find it by going: Administrative Tools -> Services.
3. Generate certificates. Go into the “easy-rsa” directory where you installed OpenVPN and follow the README. This is much easier to do on the *nix side if you can – transfer the generated files (.crt, .csr, .key) back to your client, and place them in your “config” directory.
4. sample-client.ovpn Here is a config you can use for the client. It’s pretty generic since you’re tunneling the connection, details of the VPN server address are only privvy to the tunnel setup.
   
   Note this is configured for a routing VPN (using “dev tun”). If your requirements are different (you need to send broadcasts or the like – see the FAQ), you can change the device to Tap. Also note that the generic windows device is only named “tap”, it does not do bridging) unless you tell it to.
   
   …also Note Here I lost my sanity for a bit. Thanks to Claus over at classy.dk, I discovered that putty does not tunnel UDP. Doh. The config file given uses “proto TCP” instead. I was getting baffling errors about “P_CONTROL_HARD_RESET_CLIENT_V2” and connection resets before stumbling across this gem.
5. Place your server certificates in some sensible place, and edit the OpenVPN supplied server config to your needs. Match the client on “dev” and “proto”. Also, turn on “redirect-gateway”, if your goals are similar. Start OpenVPN on your server by invoking it with the config file as an argument.
6. The primary idea here is to bypass everything, however some things are indispensible, like the path to your VPN server. Fix it by setting up a persistent route on the client:
   route -p [serveraddr] [default gateway]
7. Set up a tunnel to your box, going from your (client) localhost:1194 to 127.0.0.1:1194 (server’s “localhost”, or lo device) – here is a good guide.
8. Set up forwarding rules on the server to allow routed traffic out of the default gateway server-side

Alter for your own device names
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT


Finally, start up the OpenVPN service client side. For each .ovpn file in “config/”, one VPN client will be started. You can alternatively run the openvpn.exe from the command line if you’re having troubles.

*Note*: When testing this, do not use
ping -I tun0 google.com
… to test if traffic from the tunnel can get outside. For some reason this fails miserably, I’ve yet to find out why. Just try using your new gateway from the client.

Begin the mischief.