This is a document that can be followed in order to set up both client and server side OpenVPN connectivity.

In particular, some references to sample-config-files remain that should have been done in a directory of my choosing elsewhere (they're now production on my machine, and these instructions worked, so you may wish to change them on your system - or you can put production files in sample-config-files too).

Results: The Eee connects to the internet normally. Bringing up OpenVPN, all IP traffic is sent to my home OpenVPN server over an encrypted connection, leaving only the home machine's IP address and the fact that I'm serious about security exposed to the patrons of the internet cafe/airport/hotspot I'm working at.

While Windows clients can accept pushed DHCP options natively, while non-Windows clients can accept them by using a client-side up script which parses the foreign_option_n environmental variable list. Reference: Readlist.com entry. The setup for that client-side script has not been contributed yet.

How do we turn off the MSBROWSE/NBNS traffic from the Eee, which is not IP, and thus doesn't go out over a routed VPN (though it would over a bridged one, of course)? Disabling smbd by itself is insufficient.

The purpose - to be able to sit at a public wireless cafe and do what you do on the net without blatantly broadcasting everything to everyone in range (their range, not yours - theirs is likely longer).

The alternate purpose - to be able to securely connect to a work network (all the config is the same except the pushed routing commands - instead, either read up at openvpn.org or follow the idea presented in the proof of concept www.ibm.com routing… but with IP addresses).

All this is done from a terminal (Ctrl-Alt-t):

konsole

gives a terminal with colors and a scrollbar.

cd /usr/share/doc/openvpn/examples mkdir ~/openvpnclient cp -r ~/openvpnclient cd ~/openvpnclient cd sample-config-files

kwrite client.conf:

remote <ip addr from server.conf> <port, e.x. 1194>
uncomment (remove the leading # or ;) user nobody
uncomment (remove the leading # or ;) group nobody

ca /home/user/openvpnclient/keys/ca.crt
cert /home/user/openvpnclient/keys/client1-Password.crt
key /home/user/openvpnclient/keys/client1-Password.key

uncomment ns-cert-type server
uncomment tls-auth ta.key 1
  note: and change it to
tls-auth /home/user/openvpnclient/keys/ta.key 1

note: set cipher to the same as the server - one example:
cipher AES-256-CBC

note: add a line for a more secure digest - the default hasn't been secure for years:
auth SHA512

note: add a line to specify a more secure TLS link:
tls-cipher DHE-RSA-AES256-SHA

note set comp-lzo to the same as the server (commented or uncommented - do uncommented if you're not certain)

note: We don't want logging writing to our SSD much - for production:
verb 0

note: OR, if we're debugging/trying to figure out why the blasted thing doesn't work, set it higher:
verb 6

note: And we don't need thousands of the same message, so uncomment and change the mute line to (so if you see 8 messages, you might have been supposed to see thousands):
mute 8

Save the file, exit kwrite (File→Quit)

cd ~/openvpnclient mkdir keys (or use the File Manager, XandrosFileManager) copy the keys into /home/user/openvpnclient/keys You will need the basics on all machines:

ca.crt
ta.key

You will also need a client key pair, for example (use a different pair on every machine):

client1-Password.crt
client1-Password.key

Now we need to enable TUN support:

sudo mkdir /dev/net
sudo mknod /dev/net/tun c 10 200

And if we want to go from the Eee over VPN to our home machine, and then from our home machine out to the Internet, and our home machine isn't quite set up to do that automatically (skip this if your server has push “redirect-gateway def1” set up in server.conf):

sudo route add  .... ("man sudo route" gives syntax - see the www.ibm.com example below)

Now try running it (make sure your home machine's OpenVPN server is running first!): cd ~/openvpnclient/sample-config-files sudo openvpn client.conf

Note: VMWare Virtual Machines do use the VPN tunnel if their Ethernet interface is set to “NAT”.

Validation: Try to see if we have a route that starts with “default” and ends with “tun0”:

sudo route

If so, your server redirects you automatically. Life is good - look up wireshark and tcpdump so you can prove to yourself that it's all encrypted (except ARP and NBNS and BROWSER).

If your server doesn't redirect you automatically (i.e. it doesn't have push “redirect-gateway def1” set up in server.conf), as a proof of concept, let's add just one route that goes through the VPN:

sudo route add www.ibm.com gw 10.8.0.5 tun0
Note: we are of course, assuming that your sudo ifconfig also shows 10.8.0.5 for P-t-P: on the tun0 device - if not, use what your sudo ifconfig shows.
Note: this would also be much better as an IP address if you're going to use this technique for real.
sudo route    by itself will now show a third tun0 route

Browse to www.ibm.com… and run sudo ifconfig before and after (or have verb 6 in your client.conf and watch the messages) to see what's sending and receiving the traffic!

Now let's get rid of the proof of concept:

sudo route del www.ibm.com
Note: this may not work immediately.  Kill your VPN connection (Ctrl-C in the window it's running in is simplest) and the route goes away.

Very basic network niceties: sudo ifconfig:

This command will show you some information about your network setup.
tun0 is the openvpn tunnel - the tun0 inet addr is your (the Eee) vpn IP address, and the IP address of the server is almost certainly the same first three number and 1 (i.e. 10.8.0.1)

ping <ip addr>

ping 10.8.0.1    - if your server is the default (see sudo ifconfig) this will allow you to ping your server, and see the responses.  sudo ifconfig will then show more RX bytes and TX bytes for tun0, thus indicating that yes, the openvpn tunnel is indeed the one carrying the data - as we want.

sudo route

This is the routing command - i.e. how the computer decides which network traffic to send where.  The far right column, Iface, shows which network interface each uses - eth0 is the wired internet, ath0 is wireless, and tun0 is our openvpn tunnel.

Troubleshooting: If you get (at verb 6, not verb 0):

Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Note: Attempting fallback to kernel 2.2 TUN/TAP interface
Cannot allocate TUN/TAP dev dynamically
--

Then:

You haven't done the TUN steps above properly (enable TUN support).

If you think your OpenVPN server is indeed set up properly as a router with a push command for the whole gateway, and you're getting a VPN connection but not the internet routing:

Check your server's server.conf - in the push command for routing, is it def1 (correct - letter d, letter e, letter f, number one), or is it the letter l at the end by mistake?

Other questions: Start at the OpenVPN FAQ.

Base build: Ubuntu 7.10. This would no doubt work on an Ubuntu Virtual appliance running on a Windows host, as well as other Debian based distributions. Slight modifications for other distributions, of course.

This is effectively a short compendium of http://openvpn.net/howto.html and http://openvpn.net/faq.html with some additional hardening (security) included.

From a terminal (or you can do almost all of this graphically - whichever you like)

sudo apt-get install openvpn cd /usr/share/doc/openvpn/examples/easy-rsa mkdir ~/openvpn cp * ~/openvpn cd ~/openvpn (your favorite text editor) vars (i.e. “vi vars”, or right-click and open it with a text editor)

Put values in the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don't leave any of these parameters blank.  Remember that KEY_PROVINCE can only be 2 characters.  Note - these don't have to be real values, they just have to be values.  Be the Easter Bunny if you like.
Change the value after KEY_SIZE to 2048 from the old 1024
Save vars

sudo . vars (it'll either be ”. vars” or “sudo . vars” - without the quotes, but period space vars)

sudo ./clean-all sudo ./build-ca

It will ask for some values - you can just hit Enter for all EXCEPT the Common Name, where you must fill in a name.  "Test-CA" is a simple one, but anything you like is good - keep CA in the name so you know which key this is.

sudo ./build-key-server server

Again, the Common Name is important.  You can put in something with "Server" in it.  Also, choose a password for this, and write it down.  This is _not_ a password you'll use very often.

sudo ./build-key-pass client1-Password

Make the Common Name client1key as well, for simplicity.  Make the password secure - a phrase might be wise.  This _is_ the password you'll be using every time you open up VPN, so you'll need it written down and/or remembered as well.  You can use anything you like instead of "client1-Password" - "CutePinkEee" or "Fluffy" or "client1key" would be fine, for example.  Again, a unique Common Name here.

Note: You'll need to repeat the sudo ./build-key-pass once, with a different filename (client2-Password, etc.) and a different password (for security) for every machine you'll want to have connecting to your home server.

sudo ./build-dh

This will take awhile - go get a snack or a drink, and let it do the work for you.

cd /usr/share/doc/openvpn/examples/sample-config-files mkdir ~/openvpn/config cp * ~/openvpn/config cd ~/openvpn/config sudo gunzip server.gz sudo (your favorite text editor) server.conf

Change the IP address to the IP address of this (the host/home server) machine.
Leave the port 1194 unless you know what you're doing.
Explicitly update all the paths to all the keys - i.e. /home/<yourusername>/openvpn/keys/ca.crt instead of ca.crt
  You can see these paths by going to their directory at a command prompt and typing "pwd" if you need to.  It should also be in the prompt itself.
Uncomment tls-auth ta.key 0
  Then change ta.key to be the same kind of explicit path as above, such as /home/<yourusername>/openvpn/keys/ta.key
Change the cipher line to read "cipher AES-256-CBC" without quotes.
Under the cipher line (for convenience) add a line that says "auth SHA512" without quotes
Under the auth line (for convenience) add a line that says "tls-cipher DHE-RSA-AES256-SHA" without quotes

Change the verb option to 0 if you're working fine already, 4 if you want a little information and 6 if you want a lot, just like the client gets, i.e.
verb 4

Change the mute option to 20, so you only see 20 identical messages before it stops spamming your screen, i.e.
mute 20

If you intend this VPN tunnel to allow your client machine (Eee) to surf the internet as if it was your host/server (home) machine, then add lines that say
  push "redirect-gateway def1"
  push "dhcp-option DNS 10.8.0.1"
  Note: there are double quotes around redirect-gateway def1, and that's letter d, letter e, letter f, numeric 1.
  Note: I am still unsure of the dhcp-option line.  If you don't have DNS (names don't work) on your client, try 4.2.2.2 instead of 10.8.0.1.

Save server.conf

cd ~/openvpn/keys

NOTE: you may need to execute "sudo -i" at the prompt to become root to do this.  After you're done in there, type "exit" to get out of root mode. 

sudo openvpn –genkey –secret ta.key

If you use this server/virtual machine for nothing else at all, then you can do:

sudo (your favorite text editor) /etc/hosts.deny
  add "ALL:ALL" without the quotes
  save hosts.deny
sudo (your favorite text editor) /etc/hosts.allow
  add "ALL EXCEPT PARANOID:openvpn"
  save hosts.allow

copy the keys a client needs to a USB stick for the client

(they should be in ~/openvpn/keys, where you should be now)
ca.crt
client1-Password.crt
client1-Password.key
ta.key
Note: again, "sudo -i" may be required. 

At this point, you can fully set up the client, as above. Note that the auth, cipher, and tls-cipher lines in server.conf and client.conf are identical! This means they'll be able to talk to each other in the same “language”

Right now, and after each reboot, on the server, the following must be done:

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Note that eth0 is what your network card is likely to be if it's wired - if not, put in the actual value (which could be ath0)

sudo -i echo 1 > /proc/sys/net/ipv4/ip_forward exit

sudo iptables –list -t nat

This should show you a MASQUERADE line item

sudo cat /proc/sys/net/ipv4/ip_forward

This should show 1

cd ~/openvpn sudo openvpn server.conf

Now you need to get your client to connect to it.

In theory, your firewall should only need to allow UDP traffic to your server machine on the appropriate port for this to work. TCP can (and should for maximum security) remain closed/stealthed at the firewall.