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):
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
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:
You will also need a client key pair, for example (use a different pair on every machine):
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”:
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.
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 --
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.
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.
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 188.8.131.52 instead of 10.8.0.1.
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.