[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

[Openvpn-users] Re: OpenVPN 2.0 client/server setup

  • Subject: [Openvpn-users] Re: OpenVPN 2.0 client/server setup
  • From: "Tom Barcellona" <tdb@xxxxxxx>
  • Date: Wed, 8 Dec 2004 14:32:37 -0600 (CST)
  • Importance: Normal

> Config. files are taken from
> http://openvpn.sourceforge.net/20notes.html - "Sample OpenVPN 2.0
> config file for multi-client server" and "Sample client-side OpenVPN
> 2.0 config file for connecting to multi-client server."

My advice is to not use any sample config files at all. I always recommend
to start from scratch with a blank config file, and only add what you need
one item at a time. This has several benefits:

1. Although the examples are pretty thorough, the fact remains that they
were not written with your specific situation in mind. It is always best
to custom write something for your specific situation.

2. It is harder to diagnose problems with generic config files. Same goes
for custom files where someone added all the features they could possibly
find before using it for the first time. You'd be surprised how many
problems can be solved this way.

3. You don't get a chance to understand exactly what is going on with each
setting in your config. This is a big deal when you're talking about your
network security. OpenVPN offers a wealth of features, and this is a great
way to learn and test them.

My recommendation: First, read the manpage all the way through. See what
all it has to offer, and what you might be interested in using. Don't
write the config file yet; just read the manual. Next, start with no
config file at all. Get a basic point to point tunnel going with no
encryption at all, no routing, no push or pull, no nothing; just the
tunnel. (see example 1 on the bottom of the manpage) Can you get packets
from one end to the other, does the other side send packets back? Great,
now you know there are no issues with any firewalls. (both internal and
external.) Get an idea of what connection you'll need, either tun or tap.
(I do recommend doing this part with the two actual machines you'll be
using. Be mindful, though, that this could leave sensetive data exposed
for a time, so be sure to turn off any sensitive services during this

After that, pick your authentication and encryption method. Pre-shared
static key, certificates, username/pass, pam, whatever. Get the
authentication working first, then tweak your ciphers, HMAC, replay,
tls-auth, server and client, etc.. one item at a time. Test each one to
make sure it works before you add another one. This makes it easier to
find out what went wrong. Once all that works, then add push/pull
directives for security options.

After the security is tweaked the way you want, start setting up the
server/client settings. Add any keepalive, ping-restart / exit settings.
Simulate client disconnects by killing (kill -9) one end at a time and see
if the other end does what you want it to. (restart, give error message,
run a script, change routing tables, etc...) Be sure to do this one
setting at a time.

After all that, you can start setting up routing commands for each client.
Test that those work and that packets are getting to, and through, where
you want them to. Again, after that works, then add the push/pull
directives for addressing and routing.

After addressing and routing works, then add your performance tweaks like
comp-lzo, mssfix, etc... I would not mess with the mss/mtu settings too
much, since I understand that the 2.0 series takes care of those pretty
well on its own.

Once all that works, then add your security settings like chroot,
user/group/ etc... same way as above.

Best to run at verb 5 while you're doing all this so that you can get good
feedback as to what is going on. After it all works, then you can drop to
verb 1 and add a few mute settings.

All that should get you a good, working config file every time. If you
have specific errors during the process, then you can post to the list
with an exact description of what feature went wrong and the output of the
log file. If you follow this method, I will guarantee that you will have a
far better understanding of how each specific option or feature, and
OpenVPN in general, works.


Openvpn-users mailing list