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 mac address) > > > 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 DHCP. > 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 relay client. -- .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
signature.asc
Description: Digital signature
.===================================. | This has been a P.L.U.G. mailing. | | Don't Fear the Penguin. | | IRC: #utah at irc.freenode.net | `==================================='
