hans at fugal.net
Tue Jul 5 14:45:27 MDT 2005
On Tue, 5 Jul 2005 at 14:23 -0600, Andrew McNabb wrote:
> For the sake of clear communication, I'd like to point out that whenever
> someone mentions OpenVPN, I assume they're talking about tun (IP) rather
> than tap (ethernet), unless they specifically say otherwise. This is a
> good assumption, since IP over VPN is much more efficient and much more
> common than ethernet over VPN.
Ok, it's good to know your assumption. Now, when you're talking to me or
Von, throw that assumption out the window because you'll usually be
wrong. For the record there have been no tests that I'm aware of that
indicate tap is empirically worse than tun. That is a purely logical and
theoretical conclusion, but some anecdotes indicate that tap may be just
as fast or faster in real life.
> > > You don't want to use DHCP over a VPN.
> > Sometimes you do.
> Please give me an example or two.
Dynamic DNS was one example. Consistent IP assignment as Von explained
is another. There are many other esoteric DHCP capabilities that can be
brought to bear as well, but those two are the most useful in my
experience. In case you or someone else is still confused, here is how
it works. I plug in my laptop at home and I get a DHCP address, my
client ID is reported to the DHCP server which then does a little dance
with BIND and now gandalf.lan resolves to my IP address. That's really
neat. Consistent IP assignment from the DHCP server is less complicated
but serves the same function if you can remember that gandalf always get
172.17.0.37. (Note, to get this you need to have a dhcp client that
supports passing client id, or a persistent tap interface with a fixed
> > > The VPN software does everything you would want DHCP to do.
> > You mean like dynamic DNS? If a VPN is duplicating all the behavior of a
> > DHCP server we have a serious violation of the "don't reinvent the
> > wheel" syndrome.
> I'm sorry. I don't quite understand what you said here. I don't see
> the connection between dynamic DNS and DHCP.
Hopefully the above made that clear.
> > I think OpenVPN goes too far in DHCP-server emulation, but I admit
> > it's a hard line to draw.
> OpenVPN does not emulate DHCP in any way. It gives you a dynamic IP
> address, but that has nothing to do with DHCP.
Of course it does. That is DHCPs primary job! 90% of all small DHCP
setups are for that very reason - give me an IP address automatically.
Usually nameservers are thrown in there too, but most people ignore the
other DHCP niceties. In the case that OpenVPN's emulation of "DHCP"
(automatic network configuration) fits what you need, you don't need
> The purpose of DHCP is
> to automatically discover network configuration over ethernet. DHCP is
> by no means a generalized means of configuring networks, and it is
> poorly adapted to OpenVPN (for example, due to problems with Windows,
> each OpenVPN node needs a space of four IP addresses).
I agree DHCP is not perfect, but I'm not aware of another common piece
of software that does what DHCP does.
My own assumptions are shining through here - DHCP doesn't make sense in
a tun setup, unless you have openvpn dhcp relay integration that
doesn't (yet) exist. The limitation of which you speak actually is that
windows can't do tun natively, so it's all tap underneath. If you do
tap, windows can do dhcp over openvpn quite happily, and you are only
using one IP.
> With an OpenVPN connection, the peers know enough about each other
> that a start-from-scratch protocol like DHCP is inefficient.
Yes, but they don't know enough about other things that DHCP is designed
to know about. If it were just a matter of assigning IP addresses,
there would be no problem. The issue is that sometimes we want to do
more, and to do that we need DHCP.
> > It is very nice that you don't have to set up a DHCP server to do the
> > basics (give me an IP address, set up routes and nameservers).
> > Unfortunately a side effect of this is that anytime someone asks about
> > using a DHCP server in an OpenVPN setup, people just blast them with
> > "why are you doing that, moron?" And, if you do buy into it, you end
> > up administering both a DHCP server and OpenVPN, and we all know that
> > repeating yourself is to be avoided wherever possible.
> > I've done it, and it's useful. Unless you're as crazy as me, though, you
> > probably won't feel the need. :-) But it works great (over tap, of
> > course, although it should work over tun if you hack up some sort of
> > DHCP relay thingie).
> There are two types of network designs here, and maybe the main problem
> here is confusion between the two of them.
I think so.
> Tun is the "standard" way of
> doing things.
Or so you've been told.
> All it's doing is IP over VPN. Tap, on the other hand,
> is Ethernet over VPN. It is much less efficient, and you should avoid
> it unless you have a good reason (gaming is the main one).
SMB without a WINS server is another good reason. DHCP is (IMHO) the
most important reason to go with tap.
> With tap, you're doing ethernet, so DHCP makes lots of sense. However,
> in the standard OpenVPN method, tun, DHCP makes very little sense.
I disagree. DHCP may not at first seem like it fits, it may seem an odd
choice, but it could be useful. If it seems useful enough to someone,
that someone will hack OpenVPN to allow it to act as a dhcp relay client
on behalf of the peer and you will get all of the benefits of DHCP
without a lot of code. In hindsight, my own opinion is that this is how
it should have been done to begin with. If the openvpn author doesn't
believe that, in the end he is going to have to write in the ability for
openvpn to dole out persistent IP addresses like DHCP does because
people are always asking for that (or for how to use DHCP so they can
get that benefit). That would be a crying shame, I think, especially
when you get all the other DHCP goodies for free just by being a dhcp
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20050705/3803757e/attachment.bin
More information about the PLUG