[ubuntu] Concise OpenVPN installation. . .?

[michwill]

Hi All,

My apologies for posting such a question when there is a plethora of information available, but I need something much more concise if possible. A client of mine just had a meltdown of their Win 2K3 VPN server -- they're starting from scratch and they're *very* open to Linux and especially OpenVPN.

That said, I need a *Linux Based* OpenVPN instructional/tutorial that is both concise and accurate. Does such exist?

Thus far, I've encountered and gathered a great quantity of excellent information about OpenVPN, but nothing less than about 30 pages.

My requirements are simple. I need the functional equivalent of their old PPTP server. Now, I don't necessarily want to set up a PPTP server, but I *do* want as many of the capabilities that came along with it as possible. Most importantly, I need outside computers to behave as though they are *on* the network with little to no interference, so I'm guessing I'll need a bridged setup. Also, I'd like Username/Password authentication as opposed to shared keys. My client isn't interested in having to provide keys for each login.

Anyway, all that said, I'd appreciate some amazingly concise direction on setting up a bridged OpenVPN server on Linux.

As a sidenote, their server hardware is as follows:

HP ML350 G5 Server (Quad-core Xeon)
9 GB DDR2
250GB Raid1


Best Regards!

[SpaceTeddy]

mhm... have you had a look at this howto yet ? that pretty much explains on how to do the job. But then i've been doing this so often i tend to forget how overwhelming OpenVPN can be to people...

But in general - i don't think there is a tutorial on how to do this in less than 30 pages, because openvpn is way to complex and has way too many options and tweaks to possibly fit it in anything under 100 pages. Not if you want to really understand what is going on.

i'll just throw some bones now, and i can provide sample configurations and commands on how to manage openvpn server (I acctually earn money with these things)

1.) routing of subnets.
Openvpn can be bridged or tunneld. I personally perfer the tunnels way, as it puts the clients into their own ip subnet and does not mess with the real network the server is attached to. Of course, that is a little harder to setup, as you do need ip_forwarding as well as some (basic) route settings and possibly nat to make it work. But it does work, and it does work without briding !

As an example think of the openvpn clients to have their own swicth (the openvpn process) with their own ip's and subnets. So the OpenVPN server can be thought of as to be only a router... really.

Also, it is possible to redreict all traffic via the VPN, or only specific networks/ip-ranges that are to be used. For example, i have setup multiple VPN's that only set the routes for the internal networks on the client, and leave the rest to the client. You probably want to read about the --redirect-gateway vs. push "route ip/mask" commands to understand what is happening here.

2.) Authentification
OpenVPN can authenticate against any and everything. Build in modules are for a normal PKI strucutre with or without password for the client certificates. But it also works against PAM (Plugable Authentification Modules ?) as well as LDAP and a lot of others.
And if all fails, OpenVPN has a hook for auth scripts that you can write yourself ! So if you really want to, you can even authenticate against a textfile...

3.) ports
This is a real beauty. OpenVPN uses ONE port - and one only. It work on UDP and TCP and has no other requirement. Just one Port. No GRE protocoll, no special port 500 ********. Just one Port. (i think you got the point now )

4.) your server
is more than enough. I've ran OpenVPN server on P-II pro with 128 mbyte ram with more than 60 clients. It's not the fastest, but the users didn't notice that. Altought, on a small machine like that, i never did redirect ALL traffic over it.

So, i am sorry for not being able to point you to a more... specific howto, but wrote an advertisment post instead - but i just love openvpn. It's simple, it's powerfull and it is slim.

If you have any specific question about how to setup, or if you get stuck anywhere, just ask.

hope it helps

[michwill]

Originally Posted by SpaceTeddy mhm... have you had a look at this howto yet ? that pretty much explains on how to do the job. But then i've been doing this so often i tend to forget how overwhelming OpenVPN can be to people...

Yeah, that was the first item I checked out when looking at OpenVPN. But it is amazingly detailed and I'm on a *very* short time table. I am currently beginning to read it *again* while waiting for a shorter response, however.

I just need a 10-line 10-step tutorial.

[SpaceTeddy]

here we go... let's see if i can compact it into 10 steps
NOTE: all commands run as root. i will skip the sudo everywhere. To fully become root, use

sudo su

1.) preparing the PKI
copy the easy-rsa from /usr/share/doc/openvpn/examples/easy-rsa/the examples into the /etc/openvpn/easy-rsa folder.

cp -R /usr/share/doc/openvpn/examples/easy-rsa /ect/openvpn

then go into that folder, and edit the vars to match your enviroment. i'd also suggest you remove all comments after you read them.
The settings in that file are the defaults.
once that is done, load the file with this command

source vars

NOTE: every time you want to do something on the PKI, you *MUST* load the vars again.

2.) creating the keys
first, let the scripts inititialize the enviroment (all commands run in the directory /etc/openvpn/easy-rsa) :

./clean-all

first, create a diffie-hellman key (not sure if it is needed - create it anyway)

./build-dh

then create a CA

./build-ca

now, build a server key

./build-server %name

with %name as it's common name. All Clients will always be referenced with their common name, NOT with any filename or dns name. So make sure you choose the common names of anything wisely. Also, they are in no relation to dns names (like they are in SSL certs) so you can choose them freely

3.) configuring the server
here is a sample config of a server that (should) work. create a file in /etc/openvpn calles vpn1.conf (the vpn1 can be changed to anything, really, stick with the .conf tho - that IS needed):

daemon
port 1194
proto udp
dev tun0

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/dh2048.pem 

server 10.20.30.0 255.255.255.0
ifconfig-pool-persist openvpn.dhcp

keepalive 10 120
comp-lzo

user nobody
group nogroup

persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 4
mute 20

;push "route 192.168.0.0 255.255.255.0"
;push "route 192.168.173.0 255.255.255.0"
;push "redirect-gateway def1"

;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;client-to-client
; max-clients 10

# plugin /usr/lib/openvpn/openvpn-auth-pam.so common-auth
# client-cert-not-required
# username-as-common-name

i will not go into detail on this (that would make me use 30 pages aswell)... so if you are unsure about any option, just read up what it does. However you *MUST* change the italic options to correspond to the real filenames (you should have created them in the step beforehand).

lastly, make sure the log directory exists and it is owned by nobody. Othewise, openvpn will fail to write to it's log and will fail to start.
So, create the directory and chown it with these comands:

mkdir /var/log/openvpn
chown nobody.nogroup /var/log/openvpn

4.) starting the server
All set, the server should come up fine now...
start it with this command:

/etc/init.d/openvpn start vpn1

where the vpn1 corresponds to the filename. If anything fails, check the logs in /var/log/openvpn to what failed. If i've made no typos, this should work.

5.) allowing passthrough traffic on the VPN server
This is a very tricky point. Since i could write about a book here too, i will just assume some default settings and hope they (kind of) fit your environment.

enable ip_forwarding:

sysctl -w net.ipv4.ip_forward=1

and enable it so it loads on boot via the /etc/sysctl.conf

Also, masquerade the traffic that leaves the machine, so the pakets can find their way back (this is the *easiest* solution, it is by far not the best !):

iptables -A POSTROUTING --tabe nat -o ! tun0 -j MASQUERADE

and this line to the /etc/rc.local to make the settings load on boot-up

/sbin/iptables -A POSTROUTING --tabe nat -o ! tun0 -j MASQUERADE

This should give your vpn clients full connectivity to all networks that are pushed to be accessed over the VPN.

6.) client certificates
every client needs it's own certificate. you can generate them the same way you have done all the other generation if certificates. go into the the /etc/openvpn/easy-rsa folder, make sure you run the source vars (if this is a new console) and then type

./build-client %client

where %client is the filename of the client, NOT the common name!

7.) Windows XP Clients
Download the openvpn-gui from http://openvpn.se/ and install it.
Then open the config folder (usually C:\programm files\OpenVPN\config) and create a file with the ovpn extension. this is also a normal textfile. fill it up with this sample configuration:

float
client
dev tun
proto udp

remote %vpn-server
;redirect-gateway

resolv-retry infinite
nobind
persist-key
persist-tun
ca ..\\cert\\ca.crt
cert ..\\cert\\client.crt
key ..\\cert\\client.key
ns-cert-type server
comp-lzo
verb 3
;mute 20

again, make sure that the italic bits are changed to your setup and filenames. the relative path ..\\ will bring your into the c:\program files\openvpn folder - i usually create a new folder there called cert where i store the keys and certificates.
Also, as you can see, the client needs three files from the server (all found in /etc/openvpn/easy-rsa/keys) - the ca.crt, it's own certificate and its own key. Make sure it's got it.
NOTE: Vista clients need a small change in the config as well as a way to start the openvpn-gui as administrator and not unprivilegdes user. I have yet to find a way to do this without problems...

Now, after the config is created, the files are copied and the openvpn-gui is loaded, tell it to connect. If your firewall is not blocking anything, this should work and you should be able to connect to the server. Once that is done, the client should be able to ping the 10.20.30.1 (if you kept my subnet) and the server should be able to ping the 10.20.30.6

that's pretty much the simplest, shortest way of doing this i can think of. i hope it works, and if it does i will turn this into a howto and paste it in a new thread on this forum.

If anything fails or any questions arise, just ask

PS: only took me seven steps

[michwill]

Originally Posted by SpaceTeddy PS: only took me seven steps

First and foremost: WOW! I appreciate all that. I haven't had time to try it yet, but hopefully I will have by 5 pm EST today.

That said, after glancing over this, it seems to be missing reference to two things:

1) Password authentication (key distribution is kinda out of the question as it's not sufficiently "agile")

2) Network Bridging, but I suppose I can check out links like this to get me going.

. . .again, WOW! and thank you.

[SpaceTeddy]

Originally Posted by michwill 1) Password authentication (key distribution is kinda out of the question as it's not sufficiently "agile")

ok - that was a possiblity check the server config. there are some commeted lines down the bottom. the ones i am refering to are these

# plugin /usr/lib/openvpn/openvpn-auth-pam.so common-auth
# client-cert-not-required
# username-as-common-name

this will overwrite the PKI structure and use pam to authenticate the users on the system. i.e. anybody being able to log in as a "normal" user on the machine will be able to use that user/password combination to also log into the server.
On the client side, the following lines are cancelled:

cert ..\\cert\\client.crt
key ..\\cert\\client.key

that should do the trick

if you do not want to authenticate against PAM, then i can also provide a sample script to authenticate against plain text files. btw: this example is taken from a server that has ldap integreated into pam - so the real auth is against LDAP via PAM.

Originally Posted by michwill 2) Network Bridging, but I suppose I can check out links like this to get me going.

i don't see any real need to bridge the network... really. Briding brings the heavy disadvantage of layer 2 broadcasts. This means, that your network can possibly be swamped by one client as even arp requests (which are generated automaticially to resolve ip-addresses) will be sent out via the link.
i'd strongly advise against briding if you do not need the layer 2 support (i.e. if you need broadcasts for "lan" games or protocolls like IPX to run, then you will need briding) in favor of saving bandwidth and increasing the performance.
Stick with IP based routing for as long as you can - at least that is my motto. Also, i have written a howto on ethernet network bridging. I think the bridge configuration in my case is more sufficient and closer to the operating system than the scripts mentioned in the tutorial... but that is only my opinion about my work. The thread can be found here - you are probably interested in part 2 if you want to do bridging.

[michwill]

Originally Posted by SpaceTeddy i don't see any real need to bridge the network... ... i'd strongly advise against briding if you do not need the layer 2 support (i.e. if you need broadcasts for "lan" games or protocolls like IPX to run, then you will need briding) in favor of saving bandwidth and increasing the performance. Stick with IP based routing for as long as you can - at least that is my motto. Also, i have written a howto on ethernet network bridging. I think the bridge configuration in my case is more sufficient and closer to the operating system than the scripts mentioned in the tutorial... but that is only my opinion about my work. The thread can be found here - you are probably interested in part 2 if you want to do bridging.

Well, the thing is, we need all logged-in clients to be *on the network*. Initially they will only need to access "internal" web pages. However, eventually (meaning before the end of summer), they will need to access network resources like printers, other computers via VNC, and file (with the likelihood of music) sharing across the "office". For all intents and purposes they need to be verifiably *on* the network.

What capabilities does routing alone provide?

[SpaceTeddy]

routing can do anything that requires an IP connection. Accessing shares, printing via IP or vnc is not a problem (as long as it runs on ip and not any other protocoll).

With "on the network" you just mean access to the internal networks - that is NOT a problem... at all.

hope it helps

[michwill]

Excellent! I'll actually end up setting this up over the weekend. One more question: given that my client will likely want to be able to manage this setup without having to call me every week, he's going to want some type of interface. Are there any quality graphical interfaces (web-based or otherwise) for managing OpenVPN?

Thanks again btw!

[SpaceTeddy]

i only know of a management for the PKI based VPN - that one has a webmin module which is not really finished yet, but works good enough for the guys i installed the VPNs for. The module can be found here.

how that works for non PKI structures i don't know, since then you need some kind of management tool for either the useraccounts on the machine itself, or something that will edit your OpenVPN useraccount. The only other management i have worked with as a domino 6.5.3 server which has an LDAP backend that is used by PAM to authenticate local users. OpenVPN then authenticated against PAM, this against LDAP and therefore against domino 6.5.3.