Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Samuli Seppänen]

> Reap the benefits of engauging with the larger
> FOSS community, not just the OpenVPN community.
> Without the larger community OpenVPN would,
> at minimum, be greatly diminished.  It makes
> sense to reach out.
>   
I agree you on this. I personally have trouble figuring out which
approach would be best and given the amount of discussion (~40 mails +
one IRC meeting) I assume others have the same problems. I think what
we're essentially missing is a shared understanding of the problem
itself as well as options we have to fix it. I suggest we organize the
information we currently have along these lines:

http://www.secure-computing.net/wiki/index.php/OpenVPN/Supporting_%22route-gateway_dhcp%22_on_non-Windows_platforms

What do you think?

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Gert Doering]

Hi,

On Thu, Mar 11, 2010 at 05:42:07PM -0500, Stefan Monnier wrote:
> >> Let's not add more complexity to openvpn itself, I'd be much happier if 
> > You just don't understand.
> > The complexity *WILL* be in OpenVPN, if we decide to support
> > "route-gateway dhcp" for non-Windows platforms.
> 
> I'm not sure what "route-gateway dhcp" does, so maybe that's part of the
> reason why we disagree.  

In that case it might be helpful to read the mail from James Yonan that
started this thread.

> I thought the discussion was about how to make
> DHCP work over an OpenVPN bridge (i.e. a TAP device) under systems like
> GNU/Linux.  On those systems, the only thing you need to do is to make
> sure that things like ifplugd correctly receive the info about when the
> tunnel goes up and down.

This is the trivial bit.

[..]
> I find the effort would be better spent on working with other people
> trying to make sure that ifplugd/NetworkManager/distributions/... make
> this setup as troublefree as possible.  E.g. make sure that ifplugd
> works well with tap devices (e.g. that it tries to handle them by
> default) and that NetworkManager can easily use OpenVPN and correctly
> (re)starts dhcp clients for the corresponding tap devices.

The world is a bit larger than "Linux distributions having ifplugd".

OpenVPN runs on Linux, 5 different *BSD variants, Solaris, MacOS X 
and Window - and it's not OpenVPN's job to fix the local equivalent of
ifplugd on each of these systems.  OpenVPN's aim is to provide an 
easy-to-use VPN environment for people that do not want to endlessly
fiddle with operating system settings.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/11/2010 04:42:07 PM, Stefan Monnier wrote:
> >> Let's not add more complexity to openvpn itself, I'd be much
> happier if 
> > You just don't understand.
> > The complexity *WILL* be in OpenVPN, if we decide to support
> > "route-gateway dhcp" for non-Windows platforms.
> 
> I'm not sure what "route-gateway dhcp" does, so maybe that's part of
> the
> reason why we disagree.

I don't think that's the problem.  Route-gateway dhcp makes the
openvpn server into a dhcp gateway so a remote dhcp server
can be used to configure the local VPN interface.  Right?

(It suddenly occurs to me that you probably don't want
the entire local lan using the remote dhcp server,
unless you do.)

  I thought the discussion was about how to
> make
> DHCP work over an OpenVPN bridge (i.e. a TAP device) under systems
> like
> GNU/Linux.  On those systems, the only thing you need to do is to 
> make
> sure that things like ifplugd correctly receive the info about when
> the
> tunnel goes up and down.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/11/2010 04:42:07 PM, Stefan Monnier wrote:

> I find the effort would be better spent on working with other people
> trying to make sure that ifplugd/NetworkManager/distributions/... 
> make
> this setup as troublefree as possible. 

Exactly.  

As an example appended is a 47 line patch to the Debian Lenny
/etc/init.d/openvpn that should be against sid,
is untested, needs cleanup to get documentation
where it belongs, and probably does not work.
But something like it could probably be made to work.

It's an example, and may be a bad example at that.
I'm not going to make it work or ship it off
to Debian for consideration.

It does not use ifplugd, instead relying on ifup/down
to do the right thing to ensure that the dhcp client
keeps configuring the interface in the event
of trouble.  I've no clue whether that's really
something that ifup/down is supposed to handle.  Perhaps instead
of this it should be calling some helper function
that does the same thing that ifup/down does to
decide what dhcp client to use (working with
the ifupdown people) and then call
ifplugd with the result.

So it's nothing but an idea at this point but
and idea which is probably 2 orders of magnitude
less code than would be required to integrate a
dhcp client into openvpn.  Repeat for RedHat
(and again for Suse?) and you cover, at a guess
80% of the Un*x world and provide plenty of examples
for the maintainers of other distros/OSs 
(BSD, Solaris, etc.) to follow.  The point
being to help the people who are responsible for 
systems integration do the integrating because
they will do a better job in the diverse Un*x
world out there.  Even better the task
of maintaining the code gets pushed out
to the distros further reducing the eventual
work required by, according to estimates, 70%.

Reap the benefits of engauging with the larger
FOSS community, not just the OpenVPN community.
Without the larger community OpenVPN would,
at minimum, be greatly diminished.  It makes
sense to reach out.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

---

--- /etc/init.d/openvpn 2008-09-17 06:54:05.0 -0500
+++ openvpn 2010-03-11 17:47:23.0 -0600
@@ -31,6 +31,17 @@
   . /etc/default/openvpn
 fi
 
+set_tap () {
+  TAP=$(grep '^[[:space]]*dev[[:space]]+tap' \
+$CONFIG_DIR/$NAME.conf \
+ | awk '{print $2;};')
+}
+
+tap_needs_dhcp () {
+  [ -n "$TAP" ] \
+&& grep -q '^[[:space::]]*route-gateway[[:space:]]+dhcp
[[:space:]]|$'
+}
+
 start_vpn () {
 if grep -q '^[  ]*daemon' $CONFIG_DIR/$NAME.conf ; then
   # daemon already given in config file
@@ -62,9 +73,26 @@
   $DAEMON $OPTARGS --writepid /var/run/openvpn.$NAME.pid \
  $DAEMONARG $STATUSARG --cd $CONFIG_DIR \
  --config $CONFIG_DIR/$NAME.conf || STATUS=1
+
+  # This only works if a specific tap device is
+  # configured and the interfaces file has it configured
+  # with dhcp and noauto.  (This note should be in
+  # /usr/share/doc/openvpn/README.Debian.)
+  set_tap
+  if tap_needs_dhcp ; then
+  # Start a dhcp daemon to configure the 
+  # new interface.
+ ifup $TAP
+  fi
 fi
 }
 stop_vpn () {
+  set_tap
+  if tap_needs_dhcp ; then
+# kill the dhcp daemon by shutting down the tap
+# interface.
+ifdown $TAP || true
+  fi
   kill `cat $PIDFILE` || true
   rm -f $PIDFILE
   rm -f /var/run/openvpn.$NAME.status 2> /dev/null

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Stefan Monnier]

>> Let's not add more complexity to openvpn itself, I'd be much happier if 
> You just don't understand.
> The complexity *WILL* be in OpenVPN, if we decide to support
> "route-gateway dhcp" for non-Windows platforms.

I'm not sure what "route-gateway dhcp" does, so maybe that's part of the
reason why we disagree.  I thought the discussion was about how to make
DHCP work over an OpenVPN bridge (i.e. a TAP device) under systems like
GNU/Linux.  On those systems, the only thing you need to do is to make
sure that things like ifplugd correctly receive the info about when the
tunnel goes up and down.

> a) figuring out how to properly run the system's DHCP client [which might 
>not even be installed] for *this* version of Linux or FreeBSD or 
>OpenBSD or NetBSD or Solaris or MacOS in the right way

That's not something OpenVPN should worry about.  It's the
distribution's job to do that.

> This might be the other big misunderstanding here.  As of today, if you
> want to use "ifplugd + dhcp + ..." on a TAP interface, just do so - OpenVPN
> won't stand in your way.  This is not the issue at hand - the issue is
> that OpenVPN wants to be friendly to the users, and give them an option
> to do DHCP-on-TAP without(!) having to fiddle with their local network
> setup.

I find the effort would be better spent on working with other people
trying to make sure that ifplugd/NetworkManager/distributions/... make
this setup as troublefree as possible.  E.g. make sure that ifplugd
works well with tap devices (e.g. that it tries to handle them by
default) and that NetworkManager can easily use OpenVPN and correctly
(re)starts dhcp clients for the corresponding tap devices.


Stefan

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/11/2010 01:21:19 PM, Gert Doering wrote:


> This might be the other big misunderstanding here.  As of today, if
> you
> want to use "ifplugd + dhcp + ..." on a TAP interface, just do so -
> OpenVPN
> won't stand in your way.  This is not the issue at hand - the issue 
> is
> that OpenVPN wants to be friendly to the users, and give them an
> option
> to do DHCP-on-TAP without(!) having to fiddle with their local 
> network
> setup.

This is not so much a mis-understanding as a big rift in
design approach.  Both sides can be "right", for some
value of right.

On one side we have those who want tight integration and
multi-functionality within a single tool.  The argument
is that then you only ever need to use the 1 tool.
On the other side is the Unix philosophy of having
each tool do one thing well.  The argument is that
once you learn to do "thing", you're done learning
forever until you decide to switch tools.

Frankly I always get stuck bumping up against the
limits of the 'do everything' tools, whether
it's a "framework", a computer language,
or an app like mozilla before firefox
when there was a web browser, an email reader,
a usenet reader and whatever all else bundled
in one program.  To address Gert's point above,
bundling yet more into OpenVPN makes it just
a little bit harder for a new user to figure
out what to ignore to get OpenVPN to do a VPN.
But that's minor.  The more important point
is that the user is much better served learning
how to fiddle with their local network setup
than how to fiddle with OpenVPN because there
is much more opportunity and reason to do the
former.

To re-state this last point, there are good (and bad too
but that's immaterial here) reasons
why Un*x has multiple ways to configure
interfaces and setup dhcp.  OpenVPN
won't be able to replicate all this functionality.

There are exceptions to the one-tool-per-task
rule.  I find I use emacs/readline
quite a bit and make a little bit of extra
effort to plug it into my work flow.  I believe
this makes sense because, in this case, using
a single application leverages "muscle memory".
This kind of argument cannot often be made.

So, the discussion has uncovered a fundamental
rift over whether to help OpenVPN users integrate
OpenVPN into their existing systems or whether
OpenVPN should _be_ the user's system.   Gert is
right, so long as OpenVPN does not interfere with
integration with existing tools then in some sense
the Unix philosophy people shouldn't care.  They
would not be the ones doing the code maintenance.
But it does not save the "Unix people" from having
to do the work they'd otherwise have to do because
there will still be people for whom OpenVPN won't
work who will have to revert to integrating with
the Unix environment.  It will be harder for
those people because they will have to discover
that they have a problem and un-learn what they've
tried and discover the less-often-used approach
that fixes the problem.

"Unix makes easy things hard and hard
things possible."  The corollary is that making
the easy things easier makes the harder things
harder.

James seems to want DHCP integration and
nobody's mind seems to be changing at this
point.  So if somebody steps up to maintain
the DHCP code and docs then that will happen.
Hopefully there's also a place in the documentation
and examples for some of the U*ix side alternatives
if somebody wants to step up and provide those.
I can't help but think that documentation that
points the user to the Un*x tools will be a whole
lot easer to maintain, but at this point it comes
down to people actually doing the work so which
approach works best over time remains to be
discovered.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Gert Doering]

Hi,

On Thu, Mar 11, 2010 at 05:07:29PM +0100, Jan Just Keijser wrote:
> Let's not add more complexity to openvpn itself, I'd be much happier if 

You just don't understand.

The complexity *WILL* be in OpenVPN, if we decide to support
"route-gateway dhcp" for non-Windows platforms.

The question is, *where* will it be?

a) figuring out how to properly run the system's DHCP client [which might 
   not even be installed] for *this* version of Linux or FreeBSD or 
   OpenBSD or NetBSD or Solaris or MacOS in the right way

b) contain the code to generate a DHCP request (trivial) and parse the
   response (fairly trivial), and use the already-existing IP configuration
   and route-setup bits

For people that only know their small local operating system island, 
"a)" seems like a trivial task.  For software that is so highly portable
as OpenVPN, "a)" is a truckload of pain.

I have been through the pain in implementing IPv6 support for all 
operating systems (except OpenBSD yet) that OpenVPN supports - and that
was harmless in regard to the variety of DHCP clients that exist and
all of them need to be twiddled and poked in different ways, most of them
*way out of control of OpenVPN*.


This might be the other big misunderstanding here.  As of today, if you
want to use "ifplugd + dhcp + ..." on a TAP interface, just do so - OpenVPN
won't stand in your way.  This is not the issue at hand - the issue is
that OpenVPN wants to be friendly to the users, and give them an option
to do DHCP-on-TAP without(!) having to fiddle with their local network
setup.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Gert Doering]

Hi,

On Thu, Mar 11, 2010 at 04:10:23PM +0100, David Sommerseth wrote:
> In my point of view, it's more important to find a solution which will
> be easy to maintain in the OpenVPN code and which doesn't give a
> headache to the package maintainers or system admins needing to
> configure OpenVPN.

Seconded.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Stefan Monnier]

>>> Implementing a DHCP client within OpenVPN tends to make this a more
>>> self-contained problem.
>> I don't think OpenVPN should get into the DHCP business.
>> Especially because this is not a problem specific to OpenVPN: the same
>> problem of refreshing DHCP info happens with ethernet and with wifi when
>> you disconnect and reconnect.
> I agree to your points, from a theoretical point of view.  But from a
> practical point of view, I'm not sure how possible it is to find a more
> generic solution which can be used on all *nix based setups.

There is maybe no such generic solution, but every system will have such
a tool, for the reason stated: it's a general problem not specific
to OpenVPN.

> I'm running Fedora 12, and ifplugd is available but not installed.  I
> presume that's because NetworkManager is taking care of everything with
> networking.  In fact, I know that if I manually start dhclient on an
> extra device with NetworkManager, I often experience that NetworkManager
> reclaims control of that device, and it looses its IP address.  In this
> case, I'd say that OpenVPN should integrate against NetworkManager
> instead.  But that's not sustainable either.

NetworkManager is indeed an alternative to ifplugd.
If NetworkManager doesn't know how to do-the-right-thing in this case,
then we should try and fix *that*, rather than implement DHCP in OpenVPN.

> In my point of view, it's more important to find a solution which will
> be easy to maintain in the OpenVPN code and which doesn't give a
> headache to the package maintainers or system admins needing to
> configure OpenVPN.

The least headaches for the distribution maintainers is when each tool
sticks to its particular functionality so you don't get
spurious conflicts (e.g. both OpenVPN and some DHCP client trying to
configure the interface), and you don't get inconsistency where
different configurations are needed for the same problem depending on
which device happens to be used.


Stefan

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Jan Just Keijser]

Stefan Monnier wrote:

Implementing a DHCP client within OpenVPN tends to make this a more
self-contained problem.



I don't think OpenVPN should get into the DHCP business.
Especially because this is not a problem specific to OpenVPN: the same
problem of refreshing DHCP info happens with ethernet and with wifi when
you disconnect and reconnect.

Various solutions to this problem already exist: a tool (e.g. ifplugd)
can monitor the interface's status, or OpenVPN can be instructed (via
its script hooks) to run commands upon (re|dis)connection.

These existing solutions are better because they profit from the general
infrastructure and will hence blend in much better.  E.g. they will
automatically adopt the global DHCP customizations.

  

I tend to agree with Stefan here:

it would be useful if the package builder or system engineer has more 
control over how a tun or tap device is configured but why re-invent the 
wheel ? I'd more than happy if the /sbin/ip command (as determined by 
./configure) became scriptable so that a package maintainer can 
determine which script/program to use to bring the interface up and 
down. I do most of my work on RedHat based systems so I'd replace 
/sbin/ifup with a script which writes out

/etc/sysconfig/networking-scripts/ifup-tap
and then simply call
/sbin/ifup tap0
or something like that... On Ubuntu the package maintainer can choose to 
write his or her favourite /etc/network script, etc etc. Adding your own 
DHCP code is more than likely only going to interfere with system 
package which are already in place (NetworkManager, ifplugd, etc etc).


Let's not add more complexity to openvpn itself, I'd be much happier if 
the complexity is separated as much as possible (heck, why am I even 
stuck using a tun or tap adapter? It'd be nice/fun to be able to use a 
ppp adapter as well, provided that I provide the right interface between 
what openvpn expects and what ppp expects)


JM2CW,

JJK / Jan Just Keijser

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/11/2010 09:10:23 AM, David Sommerseth wrote:

> I agree to your points, from a theoretical point of view.  But from a
> practical point of view, I'm not sure how possible it is to find a
> more
> generic solution which can be used on all *nix based setups.  AFAIK,
> ifplugd is very Linux oriented, and depends on features found in that
> kernel.  What about *BSD, Solaris or other Unix based OSes?

OpenBSD has ifstated.  I'd be surprised if the others didn't have
something similar.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/03/10 14:51, Stefan Monnier wrote:
>> Implementing a DHCP client within OpenVPN tends to make this a more
>> self-contained problem.
> 
> I don't think OpenVPN should get into the DHCP business.
> Especially because this is not a problem specific to OpenVPN: the same
> problem of refreshing DHCP info happens with ethernet and with wifi when
> you disconnect and reconnect.
> 
> Various solutions to this problem already exist: a tool (e.g. ifplugd)
> can monitor the interface's status, or OpenVPN can be instructed (via
> its script hooks) to run commands upon (re|dis)connection.
> 
> These existing solutions are better because they profit from the general
> infrastructure and will hence blend in much better.  E.g. they will
> automatically adopt the global DHCP customizations.
> 

I agree to your points, from a theoretical point of view.  But from a
practical point of view, I'm not sure how possible it is to find a more
generic solution which can be used on all *nix based setups.  AFAIK,
ifplugd is very Linux oriented, and depends on features found in that
kernel.  What about *BSD, Solaris or other Unix based OSes?

Another issue with these programs is that they often do need a
configuration file to take care of the interface setup.  On some Linux
distroes, ifplugd can even cause conflicts with other similar solutions
which that distro prefers over ifplugd.

I'm running Fedora 12, and ifplugd is available but not installed.  I
presume that's because NetworkManager is taking care of everything with
networking.  In fact, I know that if I manually start dhclient on an
extra device with NetworkManager, I often experience that NetworkManager
reclaims control of that device, and it looses its IP address.  In this
case, I'd say that OpenVPN should integrate against NetworkManager
instead.  But that's not sustainable either.

We do need this feature into OpenVPN.  But, as Gert stated, you move
complexity from one place to another place.  It's not given now it will
be easier to implement DHCP features inside OpenVPN or to get something
started outside OpenVPN ... just because it's not a de-facto solution
which even distroes make use of.

In my point of view, it's more important to find a solution which will
be easy to maintain in the OpenVPN code and which doesn't give a
headache to the package maintainers or system admins needing to
configure OpenVPN.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuZB9sACgkQDC186MBRfrqw8QCeMjOgwpctv+G7BMqGa68IVbr+
K+gAn3gXx9/HKnmX++pyeOwCRnd3Q2yM
=l4QC
-END PGP SIGNATURE-

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Stefan Monnier]

> Implementing a DHCP client within OpenVPN tends to make this a more
> self-contained problem.

I don't think OpenVPN should get into the DHCP business.
Especially because this is not a problem specific to OpenVPN: the same
problem of refreshing DHCP info happens with ethernet and with wifi when
you disconnect and reconnect.

Various solutions to this problem already exist: a tool (e.g. ifplugd)
can monitor the interface's status, or OpenVPN can be instructed (via
its script hooks) to run commands upon (re|dis)connection.

These existing solutions are better because they profit from the general
infrastructure and will hence blend in much better.  E.g. they will
automatically adopt the global DHCP customizations.


Stefan

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Gert Doering]

Hi,

On Wed, Mar 10, 2010 at 10:52:00PM +, Timothy Baldwin wrote:
> James Yonan wrote:
> 
> > Implementing a DHCP client within OpenVPN tends to make this a more
> > self-contained problem.
> 
> But what about IPv6, tunnels and DHCP prefix delegation? 

IPv6 is a separate issue.  The current IPv6 payload patch supports 
"IPv6 ifconfig pool" and ccd/-based static IPv6 assignment on the server
side (pushing "ifconfig-ipv6" to the client), or static configuration 
on client and server side.

The configuration of IPv6 on the interface is done with the distribution-
specific methods (ifconfig, ip -6 addr, netsh, ...)

IPv6 prefix delegation is something OpenVPN currently doesn't do at all -
neither with a server-based configuration, nor with DHCP PD.

For TAP interfaces (what this discussion was about for IPv4), DHCP PD
could be made to work without assistance from OpenVPN - because OpenVPN
only sees ethernet frames anyway.  For TUN interfaces, OpenVPN would need
to understand DHCP PD and act as a DHCP relay router - otherwise, OpenVPN
wouldn't know how to install the necessary iroute6 towards the client
that has been delegated a prefix.  But this is all "future plans" - first,
get the current IPv6 payload stuff tested well enough that it can get
integrated in the next beta :-)

> Invoking the distribution auto-configuration/ scripts makes more sense.

It doesn't.  For the same reasons as with IPv4.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Timothy Baldwin]

James Yonan wrote:

> Implementing a DHCP client within OpenVPN tends to make this a more
> self-contained problem.

But what about IPv6, tunnels and DHCP prefix delegation? Invoking the 
distribution auto-configuration/ scripts makes more sense.

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Stefan Monnier]

> My understanding of dhcp is that the client is supposed to 
> automatically reconfigure on lease expiration

Yes.

> or whenever the link goes up and down.

Not necessarily, and that's the problem.

> I suppose it's possible that there are dhcp clients
> that exit when the link goes down and must be restarted
> but I don't know of any.

No, but many don't do anything when the link goes down or when the link
comes back up.  They only do something when the lease needs to
be refreshed.
That's why we have things like ifplugd.


Stefan

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 11:27:13 AM, David Sommerseth wrote:
> On 09/03/10 17:41, Karl O. Pinc wrote:
> > On 03/09/2010 10:16:37 AM, David Sommerseth wrote:
> >
> >>> Over-automating things will cause people headaches.
> >>> You don't want to willy-nilly startup a dhcp client
> >>> and have all your interfaces configured with dhcp without
> >>> your consent.
> >>
> >> Exactly!  Which again moves it more in the direction of some
> built-in
> >> DHCP client in OpenVPN, but as stated earlier - that mostly solves
> >> the
> >> core DHCP issues - but not the resolv.conf issue.
> >
> > I'm not at all sure it solves the core issues, which is that
> > an already running dhcp client won't have auto-detected
> > the tap interface that OpenVPN creates -- iff OpenVPN is
> > started after the dhcp client.
> 
> Can you actually start an DHCP client on a non-existing TAP device?  
> I
> don't think so.

No.  That's my point.  The tap device won't exist if you start
openvpn after starting dhcp.

>  And I haven't seen any clients which do have such
> auto-detect features

man dhclient says: "If no interface names are specified
   on the command line dhclient will normally  identify
   all  network  interfaces,  eliminating non-broadcast
   interfaces if possible,  and  attempt  to  configure
   each interface."


 ... I begin to feel we're talking about 
> different
> things now.

You may be closer to reality than me.  I'm not a dhcp expert,
at least not when it comes to experience with various client
implementations and especially not when it comes to tap
interfaces.  So I hope I'm not making things more confusing
when I point out potential problems I see.  

> 
> > This is the
> > core issue, right? Otherwise it would just work so long
> > as dhcp is turned on.  I think we need to decide where
> > the problem really is before we decide how to fix it.
> 
> I don't think we're on the same page now.  The issue how I see it:
> There is a real DHCP server which provides DHCP clients network
> configurations automatically, including IP addresses, routes and
> default
> gateway, DNS/WINS servers, and a lot of the other options the DHCP
> server supports.
> 
> The challenge for OpenVPN in this is that now a separate DHCP client
> needs to be started via a --up script, and to be torn down via a
> --down
> script.  But this needs to be run as root (at least on most platforms
> I
> know about).
> 
> The problem, how I see it, is how to do this in an easier and more
> robust way, configuration wise - to make OpenVPN on *nix behave more
> like it does on Windows, where no extra configuration is needed at 
> all
> (if you ignore the DNS cache issues in Windows for now), it just
> works.
> 
> Please correct me, if you think I have made it too vague and simple,
> or
> simply wrong.

This is right.  Perhaps too simple in the case of dhcp clients
that support multiple interfaces.  This is especially true
if the dhcp server is started after the openvpn process
because then the dhcp server can see the tap interface
and configure it (and fiddle with resolv.conf) without 
anything having to be done on the openvpn side.
See also this bottom of this message for an alternate statement of
the problem.

> 
> > If you build a dhcp client into openvpn you push the problem in
> > the other direction.  Now you've, potentially, got
> > multiple dhcp clients running and you need to do
> > something to keep them from interfering with each other.
> 
> Why is this an issue?  Unless they operate on each separate network
> segment, this shouldn't cause any unexpected behaviour.  And it's not
> uncommon to see boxes with multiple interfaces running separate DHCP
> clients per interface, and that don't seem to cause any problems in
> those setups I've done that with.

The issue is when two clients want to assign an address to 
one interface.  I don't know if dhclient will autodetect tap
interfaces but if so, or if anything else does, then you get
2 clients doing dhcp for one interface.


> > You can't rely on processes being started and stopped
> > in boot-time order because the sysadmin might start
> > and stop services as needed to maintain the system
> > and you don't want surprising things to happen.
> > (The principle of least surprise is a good one.)
> 
> Exactly, and if a user stops OpenVPN, the DHCP client for that TAP
> interface should also be taken down, right?  And if the OpenVPN is
> started at boot time, OpenVPN will take care of getting the DHCP
> config
> when the link is established, right?  I don't see any obstacles here,
> nor any potential surprises.

You're assuming one client dhcp process per interface.  I'm not.
(And have been habitually assuming the opposite until
corrected by Peter's post.)
So an already running (or yet to be started) dhcp client
can fuss with the openvpn tap interface.

> 
> You start OpenVPN, and expect it to do the setup properly.  If the
> DHCP
> client is built into OpenVPN, that should really not cause any

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Peter Stuge]

Karl O. Pinc wrote:
> I'm not at all sure it solves the core issues, which is that
> an already running dhcp client won't have auto-detected
> the tap interface that OpenVPN creates -- iff OpenVPN is 
> started after the dhcp client.

Note that several DHCP clients only handle one interface per DHCP
client process..


//Peter

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/03/10 17:41, Karl O. Pinc wrote:
> On 03/09/2010 10:16:37 AM, David Sommerseth wrote:
> 
>>> Over-automating things will cause people headaches.
>>> You don't want to willy-nilly startup a dhcp client
>>> and have all your interfaces configured with dhcp without
>>> your consent.
>>
>> Exactly!  Which again moves it more in the direction of some built-in
>> DHCP client in OpenVPN, but as stated earlier - that mostly solves 
>> the
>> core DHCP issues - but not the resolv.conf issue.
> 
> I'm not at all sure it solves the core issues, which is that
> an already running dhcp client won't have auto-detected
> the tap interface that OpenVPN creates -- iff OpenVPN is 
> started after the dhcp client.  

Can you actually start an DHCP client on a non-existing TAP device?  I
don't think so.  And I haven't seen any clients which do have such
auto-detect features ... I begin to feel we're talking about different
things now.

> This is the
> core issue, right? Otherwise it would just work so long
> as dhcp is turned on.  I think we need to decide where
> the problem really is before we decide how to fix it.

I don't think we're on the same page now.  The issue how I see it:
There is a real DHCP server which provides DHCP clients network
configurations automatically, including IP addresses, routes and default
gateway, DNS/WINS servers, and a lot of the other options the DHCP
server supports.

The challenge for OpenVPN in this is that now a separate DHCP client
needs to be started via a --up script, and to be torn down via a --down
script.  But this needs to be run as root (at least on most platforms I
know about).

The problem, how I see it, is how to do this in an easier and more
robust way, configuration wise - to make OpenVPN on *nix behave more
like it does on Windows, where no extra configuration is needed at all
(if you ignore the DNS cache issues in Windows for now), it just works.

Please correct me, if you think I have made it too vague and simple, or
simply wrong.

> If you build a dhcp client into openvpn you push the problem in
> the other direction.  Now you've, potentially, got
> multiple dhcp clients running and you need to do
> something to keep them from interfering with each other.

Why is this an issue?  Unless they operate on each separate network
segment, this shouldn't cause any unexpected behaviour.  And it's not
uncommon to see boxes with multiple interfaces running separate DHCP
clients per interface, and that don't seem to cause any problems in
those setups I've done that with.

In fact, with TAP devices, they will have different MAC addresses, so
even if you have multiple OpenVPN connections to a network, the DHCP
server will see them as separate clients, giving them separate IP addresses.

> You can't rely on processes being started and stopped
> in boot-time order because the sysadmin might start
> and stop services as needed to maintain the system
> and you don't want surprising things to happen.
> (The principle of least surprise is a good one.)

Exactly, and if a user stops OpenVPN, the DHCP client for that TAP
interface should also be taken down, right?  And if the OpenVPN is
started at boot time, OpenVPN will take care of getting the DHCP config
when the link is established, right?  I don't see any obstacles here,
nor any potential surprises.

You start OpenVPN, and expect it to do the setup properly.  If the DHCP
client is built into OpenVPN, that should really not cause any
surprises.  It should simply, just work(tm).

I don't see how this relies on boot-time order, etc, etc.  As long as
OpenVPN has not established a connection it would not start a DHCP
request anywhere.

> You may as well just statically configure your existing
> dhcp client so that it knows to go looking for the
> tap device.

How would you do that?  The different DHCP client applications might
have different arguments, where and how would you configure this statically?

> I think the only way to go is to integrate with
> anything that the local admin may decide to use
> for dhcp/resolv.conf/etc.

For resolv.conf issues, at present, using a third-party DHCP application
is probably a safer bet right now.  I agree to that one.  But I'm far
from convinced that it is the best solution, just because of the wide
range of DHCP clients and distribution specific adjustments.


kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuWhO4ACgkQDC186MBRfrraiQCfRtC3Lx3Wbxr99L6+Z5mGq9D3
7oEAnjEhBegux6kNLp2yTFTF8DObIWLd
=Ll81
-END PGP SIGNATURE-

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 10:16:37 AM, David Sommerseth wrote:

> > Over-automating things will cause people headaches.
> > You don't want to willy-nilly startup a dhcp client
> > and have all your interfaces configured with dhcp without
> > your consent.
> 
> Exactly!  Which again moves it more in the direction of some built-in
> DHCP client in OpenVPN, but as stated earlier - that mostly solves 
> the
> core DHCP issues - but not the resolv.conf issue.

I'm not at all sure it solves the core issues, which is that
an already running dhcp client won't have auto-detected
the tap interface that OpenVPN creates -- iff OpenVPN is 
started after the dhcp client.  

This is the
core issue, right?  Otherwise it would just work so long
as dhcp is turned on.  I think we need to decide where
the problem really is before we decide how to fix it.

If you build a dhcp client into openvpn you push the problem in
the other direction.  Now you've, potentially, got
multiple dhcp clients running and you need to do
something to keep them from interfering with each other.
You can't rely on processes being started and stopped
in boot-time order because the sysadmin might start
and stop services as needed to maintain the system
and you don't want surprising things to happen.
(The principle of least surprise is a good one.)
You may as well just statically configure your existing
dhcp client so that it knows to go looking for the
tap device.

I think the only way to go is to integrate with
anything that the local admin may decide to use
for dhcp/resolv.conf/etc.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/03/10 16:34, James Yonan wrote:
>> looking at the multitude of DHCP clients available for unix, the completely
>> different handling of DHCP on MacOS, and the issues that most unix clients
>> seem to have with "DHCP active on two different interfaces (ethX and tapY),
>> and both trying to set a default gateway", ...
>>
>> On Mon, Mar 08, 2010 at 08:21:35AM -0700, James Yonan wrote:
>>> (2) Complex method: Write code in OpenVPN to simulate a DHCP client, 
>>> then translate the settings received in the DHCP reply to OpenVPN 
>>> push-style directives (such as ifconfig, route, etc.) as if they had 
>>> been pushed by the OpenVPN server.
>>
>> ... this seems to be the most portable way, as we already have the 
>> ifconfig/route code for all the platforms.
>>
>> Well.  Let me rephrase.
>>
>> The "simple way" is simple as far as the packet flow inside OpenVPN
>> goes (because OpenVPN only needs to transport packets, but not generate
>> them or parse them), but is, at the same time, the "most complex way" 
>> as far as getting it to work reliably across all supported operating 
>> systems.  Lots of testing and "configure" magic would be necessary to
>> reliably figure out how to do DHCP properly on each individual system.
>>
>> I'm not saying it can't be done :-) - but just that the "simple way"
>> is not so simple, it's just complex in other places.
> 
> I would tend to agree.  All the discussion about the non-portable 
> semantics of DHCP clients on different platforms makes me think that the 
> "complex" method might really be the correct approach.
> 
> OpenVPN is already in the business of abstracting platform-specific 
> network configuration complexity to a portable interface, i.e. in the 
> manner of pushable directives such as route, ifconfig, dhcp-option, 
> etc., so I think it makes sense to leverage on this.  Implementing a 
> DHCP client within OpenVPN tends to make this a more self-contained problem.
> 

I agree.

What I am wondering about what we should do with updates of
/etc/resolv.conf.  It's not directly connected to DHCP, but it is
tightly related to it.  As long as DHCP can push DNS servers as well,
this will be the next challenge.  This has been solved in several
distroes by calling its own script for updating the resolv.conf
file. [1]

And it's needed to consider the consequences when using --user/--group
and/or chrooting.


kind regards,

David Sommerseth


[1]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuWd6kACgkQDC186MBRfrqCRQCdE9XxyO9q+5MxNTm24lRfBJoT
DEcAoKMwEiw6BJDh0kCWLYSWitkq88sA
=b3AJ
-END PGP SIGNATURE-

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/03/10 16:58, Karl O. Pinc wrote:
> On 03/09/2010 08:05:17 AM, David Sommerseth wrote:
> 
>>  On the other hand, ./configure
>> could try to detect which DHCP client the system got and could use
>> that
>> as a default client to kick off.
> 
> I think this might cause more problems than it solves because
> there's no guarantee that build hosts will have the same,
> or any, dhcp client that is ultimately used.   
[...snip...]

Agreed.  Not ideal situation, especially if you can not configure an
override.

> Maybe what makes the most sense from a package
> management standpoint is to have the package installation
> process autodetect the existing dhcp client so that whatever
> the user has installed will be used (once the feature
> is turned on with --route-gateway.)  I'm not sure how
> to best facilitate this with OpenVPN.  Perhaps OpenVPN
> should default to using something like
> /etc/openvpn/route-gateway-dhcp-client and then
> package installation can softlink that to whatever
> dhcp client is installed.  

A symlink like this also then requires the current (and future) DHCP
clients to use the same arguments.  People would then replace this with
a script of course.  But then this script can be used to do more nasty
things than what it is intended for, so then you have a possible
security issue again.  Is this really an approach we want to use?

Actually this issue will always be present, as long as third party
applications are exec()ed from OpenVPN.  We already got plenty of script
hooks available, do we really want or need one more?  And do we want one
which will need to have root access on most platforms when the tap
device is being teared down?

> Over-automating things will cause people headaches.
> You don't want to willy-nilly startup a dhcp client
> and have all your interfaces configured with dhcp without
> your consent.

Exactly!  Which again moves it more in the direction of some built-in
DHCP client in OpenVPN, but as stated earlier - that mostly solves the
core DHCP issues - but not the resolv.conf issue.

And by doing it this way (embedded DHCP client), we could maybe even
make this work with tun devices as well, if the server then can act as a
DHCP relay against a real DHCP server.


kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuWdGMACgkQDC186MBRfrrI0gCgkPt63MTUc2yFimrkWRG9VKzQ
8D8An1vidIoFp2SivjySNExpqvyvc928
=CAOE
-END PGP SIGNATURE-

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 08:01:32 AM, Stefan Monnier wrote:
> > bring the interfaces up
> > start dhcp client (if not triggered directly from the interfaces)
> > start openvpn
> 
> That is a misconfiguration in my book.  The only correct 
> configuration
> is when the dhcp client is triggered from the interface.  After all,
> openvpn may take half an hour to get the connection and it may lose
> the
> connection at some point and reconnect to another openvpn server (via
> round-robin DNS, for example) which might require a reconfiguration 
> on
> the dhcp side.

My understanding of dhcp is that the client is supposed to 
automatically reconfigure on lease expiration or whenever
the link goes up and down.  There's no reason to
restart a dhcp client just to connect to another dhcp
server because dhcp should also do this automatically.

I suppose it's possible that there are dhcp clients
that exit when the link goes down and must be restarted
but I don't know of any.  Then again I don't have
experience with various client implementations.
But it would seem kind of odd, having to restart
the dhcp client just because somebody unplugged
an ethernet cable.

The only reason why we're talking about restarting
dhcp clients in the first place is so that they
autodetect newly created tap devices.  If the
dhcp client is configured with the tap device, or once
it detects the tap device and the tap device stays
existent, all the dhcp clients I know of should just
be able to keep running and do what's needed as
links go up and down and dhcp servers come and go.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 08:05:17 AM, David Sommerseth wrote:

>  On the other hand, ./configure
> could try to detect which DHCP client the system got and could use
> that
> as a default client to kick off.

I think this might cause more problems than it solves because
there's no guarantee that build hosts will have the same,
or any, dhcp client that is ultimately used.   I'm with
Peter Stuge regarding being able to support a choice
of clients, and having the wrong default in place can
just complicate things.

Maybe what makes the most sense from a package
management standpoint is to have the package installation
process autodetect the existing dhcp client so that whatever
the user has installed will be used (once the feature
is turned on with --route-gateway.)  I'm not sure how
to best facilitate this with OpenVPN.  Perhaps OpenVPN
should default to using something like
/etc/openvpn/route-gateway-dhcp-client and then
package installation can softlink that to whatever
dhcp client is installed.  

Over-automating things will cause people headaches.
You don't want to willy-nilly startup a dhcp client
and have all your interfaces configured with dhcp without
your consent.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 12:47:36 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > The boot order that makes sense to me is:
> > 
> > bring the interfaces up
> > start dhcp client (if not triggered directly from the interfaces)
> > start openvpn
> > 
> > The problem is that if the dhcp client is started before openvpn
> > and openvpn is creating the tap interface then it's too late
> 
> At least some distributions work more like this:
> 
> foreach interface:
>   set link up
>   possibly start openvpn
>   address add

Ok.  So this then relies on openVPN retries to get the connection
open, because when openvpn starts it's not got addresses
in place to reach the other endpoint.  The only downside
is that the startup is not really synchronous so that if
later portions of the boot process are relying on having
the VPN available they'd better be able to retry too.

In this case it should "just work" on those distros, at least so
long as the "address add" part is configured to use dhcp.  Yes?

Anyone know if it does work?

Which distros work like that?  I'm most familiar with
Debian and RedHat, although I've not looked at openvpn
on RedHat in a while.  I seem to recall on these
that the sysV init stuff starts openvpn last.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[James Yonan]

looking at the multitude of DHCP clients available for unix, the completely
different handling of DHCP on MacOS, and the issues that most unix clients
seem to have with "DHCP active on two different interfaces (ethX and tapY),
and both trying to set a default gateway", ...

On Mon, Mar 08, 2010 at 08:21:35AM -0700, James Yonan wrote:
(2) Complex method: Write code in OpenVPN to simulate a DHCP client, 
then translate the settings received in the DHCP reply to OpenVPN 
push-style directives (such as ifconfig, route, etc.) as if they had 
been pushed by the OpenVPN server.


... this seems to be the most portable way, as we already have the 
ifconfig/route code for all the platforms.


Well.  Let me rephrase.

The "simple way" is simple as far as the packet flow inside OpenVPN
goes (because OpenVPN only needs to transport packets, but not generate
them or parse them), but is, at the same time, the "most complex way" 
as far as getting it to work reliably across all supported operating 
systems.  Lots of testing and "configure" magic would be necessary to

reliably figure out how to do DHCP properly on each individual system.

I'm not saying it can't be done :-) - but just that the "simple way"
is not so simple, it's just complex in other places.


I would tend to agree.  All the discussion about the non-portable 
semantics of DHCP clients on different platforms makes me think that the 
"complex" method might really be the correct approach.


OpenVPN is already in the business of abstracting platform-specific 
network configuration complexity to a portable interface, i.e. in the 
manner of pushable directives such as route, ifconfig, dhcp-option, 
etc., so I think it makes sense to leverage on this.  Implementing a 
DHCP client within OpenVPN tends to make this a more self-contained problem.


James

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/03/10 17:14, Karl O. Pinc wrote:
> On 03/08/2010 09:21:35 AM, James Yonan wrote:
>> OpenVPN 2.1 has a relatively recent feature that allows a TAP-based 
>> OpenVPN session to be established where the client gets its IP 
>> address
>>
[...snip...]
> C) A combination of A and B, where there's a separate dhclient
> process run just for openvpn.  This might avoid problems with
> B where the regular interfaces must also be configured because
> autodetection is turned off.  It might also be more portable
> across different dhcp client implimentations (or not.)
[...snip...]

If going for a "simpler way", I'd say this is probably the best
solution.  This gives a flexibility.  On the other hand, ./configure
could try to detect which DHCP client the system got and could use that
as a default client to kick off.

But having that said, it looks pretty close to what --up and --down
scripts can do.  Except that you probably need to be root to run and
stop the DHCP client.  With --user/--group you might have troubles
getting --down run without a downroot plug-in or something like that.

And adding a --dhcp-client feature might be (mis-)used for more things
than just DHCP - depending on the final implementation.  If not
supporting a script interface via --dhcp-client, should OpenVPN know
about different ways how to start and stop each supported DHCP client,
in regards to needed parameters?  How would the maintenance work be
staying updated on behavioural changes in different versions, etc, etc.

I don't know how complex it would be to parse DHCP requests.  Even
though I dislike the idea of making OpenVPN more "feature full" by
extending it to include stuff which is available other places ... but
considering the amount of different DHCP client solutions that exists on
Linux, *BSD, MacOSX and other Unices, I *might* begin to lean towards an
included solution which don't depend on external DHCP clients at all.
But the drawback is that more code need to be maintained, but that's
code which should be able to rely on RFC docs.

But DHCP parsing and configuring IP addresses and routes are one thing
... the next obstacle will then be updating /etc/resolv.conf, which
again is another chapter.  The vpnc client updates that itself, which is
then funny if you're using NetworkManager which haven't understood
another program modified it on purpose, and resets it back.  Many
distroes now make use of the openresolv or similar packages to solve
this.  But, this is a similar issue as the DHCP client issue as well,
which again favours doing the DHCP stuff via a fork()ed DHCP client.


Just my thoughts.


kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuWVZsACgkQDC186MBRfroqMgCfZWcJgPdzxzWjkSJwnafHkvtf
07cAn3fCJuDCYUEhI0WnUz7AheUEM+mx
=7yxH
-END PGP SIGNATURE-

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Stefan Monnier]

> bring the interfaces up
> start dhcp client (if not triggered directly from the interfaces)
> start openvpn

That is a misconfiguration in my book.  The only correct configuration
is when the dhcp client is triggered from the interface.  After all,
openvpn may take half an hour to get the connection and it may lose the
connection at some point and reconnect to another openvpn server (via
round-robin DNS, for example) which might require a reconfiguration on
the dhcp side.
Of course, the correct result can be obtained in various ways:
- let openvpn run scripts to start&stop the dhcp client.
- use ifplugd (assuming it works with openvpn, which I haven't checked).
- use a dhcp client which internally does what ifplugd does (don't know
  which ones that would be).


Stefan

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Peter Stuge]

Karl O. Pinc wrote:
> The boot order that makes sense to me is:
> 
> bring the interfaces up
> start dhcp client (if not triggered directly from the interfaces)
> start openvpn
> 
> The problem is that if the dhcp client is started before openvpn
> and openvpn is creating the tap interface then it's too late

At least some distributions work more like this:

foreach interface:
  set link up
  possibly start openvpn
  address add


//Peter

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 05:09:49 PM, Stefan Monnier wrote:
> >> I think if the user just starts the dhcp client on an interface
> >> independently from the moment the interface goes up (or down), 
> this
> 
> >> is simply a misconfiguration.
> > I'm not sure I understand.  Are you saying that manually starting
> > a dhcp client means that the system is mis-configured because
> > it's not configured to do the right thing automatically?
> 
> No, I mean if the dhcp client is started for example in the
> boot scripts.

I see the boot scripts as problematic.  The boot order
that makes sense to me is:

bring the interfaces up
start dhcp client (if not triggered directly from the interfaces)
start openvpn

The problem is that if the dhcp client is started before openvpn
and openvpn is creating the tap interface then it's too late
for the dhcp client to autodetect (at least at startup).
You could start openvpn before the dhcp client, and that could be
a good solution, but it does not work if there are tun
interfaces because the interfaces won't have yet
gotten an ip address from dhcp.

Or am I missing something?



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Stefan Monnier]

>> I think if the user just starts the dhcp client on an interface
>> independently from the moment the interface goes up (or down), this 
>> is simply a misconfiguration.
> I'm not sure I understand.  Are you saying that manually starting
> a dhcp client means that the system is mis-configured because
> it's not configured to do the right thing automatically?

No, I mean if the dhcp client is started for example in the
boot scripts.


Stefan

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 03:26:11 PM, Stefan Monnier wrote:
> > In either case we'd be looking at an openvpn configuration
> > directive (or 2) that takes a command to run once
> > the link comes up (and down).  If that was in place then
> > any of A, B, C, or D, or your choice of using an ifup/ifdown
> > script would all work.
> 
> BTW, there are generic tools to run/stop dhcp clients (and other
> configuration steps) when the interface goes up/down.  I've used
> ifplugd
> for it, but IIUC there are others.

Come to think of it I've used ifplugd too.

Since there are multiple "right" ways it sounds like the documentation
could be extensive.  Would this be a job for the wiki, at least
initially?

FWIW http://openvpn.net/wiki/ comes up a blank page.  Is this
because I've cookies and scripts off or something?

> 
> I think if the user just starts the dhcp client on an interface
> independently from the moment the interface goes up (or down), this 
> is
> simply a misconfiguration.

I'm not sure I understand.  Are you saying that manually starting
a dhcp client means that the system is mis-configured because
it's not configured to do the right thing automatically?


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Stefan Monnier]

> In either case we'd be looking at an openvpn configuration
> directive (or 2) that takes a command to run once
> the link comes up (and down).  If that was in place then
> any of A, B, C, or D, or your choice of using an ifup/ifdown
> script would all work.

BTW, there are generic tools to run/stop dhcp clients (and other
configuration steps) when the interface goes up/down.  I've used ifplugd
for it, but IIUC there are others.

I think if the user just starts the dhcp client on an interface
independently from the moment the interface goes up (or down), this is
simply a misconfiguration.

> Given that.  Why not just use -up and --down to do what's
> needed?  Avoid changing the code and write documentation.

Sounds about right,


Stefan

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 02:26:13 PM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > > I know of at least four DHCP clients and I avoid dhclient as much
> as
> > > possible. It would be a tremendous mistake to tie OpenVPN to any
> one
> > > DHCP client IMO.
> > 
> > Only D is tied to dhclient.  A, B, and C, work fine with any dhcp
> > client daemon.  (Or A does anyway, B and C require configuration
> file
> > support for the interface.  I assume this is a common property of
> > dhcp clients.)
> 
> Actually no, neither dhcpcd nor pump nor udhcpc uses one.

dhcpd needs one if you're going to have different interfaces
that need different dhcp options.

> 
> 
> > It would be nice not to force use of a particular client.
> 
> I think it's neccessary.

Ok.  Agreed.

> 
> 
> > Given that.  Why not just use -up and --down to do what's
> > needed?  Avoid changing the code and write documentation.
> 
> Agree completely. This is how I've been using OpenVPN for years
> already.

Do you have a particular config known to work with
"route-gateway dhcp"?

Do you think the distros are different enough that
separate sample config files should be supplied for each?

If documentation is all that's required perhaps the user
list should be queried to see who's already doing what
and if anybody has a starting point.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Peter Stuge]

Karl O. Pinc wrote:
> > I know of at least four DHCP clients and I avoid dhclient as much as
> > possible. It would be a tremendous mistake to tie OpenVPN to any one
> > DHCP client IMO.
> 
> Only D is tied to dhclient.  A, B, and C, work fine with any dhcp
> client daemon.  (Or A does anyway, B and C require configuration file
> support for the interface.  I assume this is a common property of
> dhcp clients.)

Actually no, neither dhcpcd nor pump nor udhcpc uses one.


> It would be nice not to force use of a particular client.

I think it's neccessary.


> Given that.  Why not just use -up and --down to do what's
> needed?  Avoid changing the code and write documentation.

Agree completely. This is how I've been using OpenVPN for years
already.


//Peter

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 10:50:48 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > > I'm hoping that we can make "route-gateway dhcp" work on Unix
> > > platforms as well.  I'm thinking there are two possible ways we
> > > could do this:
> 
> Network interface configuration is highly distribution specific.
> 
> 
> > A) dhclient
> > 
> > B) dhclient.conf
> > 
> > C) dhclient
> > 
> > D) dhcptl or omapi or .. omshell
> ..
> > This would be tied to the ISC implementation, but probably nobody
> > cares.
> 
> I know of at least four DHCP clients and I avoid dhclient as much as
> possible. It would be a tremendous mistake to tie OpenVPN to any one
> DHCP client IMO.

Only D is tied to dhclient.  A, B, and C, work fine with any dhcp
client daemon.  (Or A does anyway, B and C require configuration file
support for the interface.  I assume this is a common property of dhcp
clients.)

Yes.  It would be nice not to force use of a particular client.
Especially if, as you write, many clients are in use.

> 
> 
> What most if not all distributions have in common, or could have in
> common, is that a script configures the network interface. Sometimes
> it's called ifup, other times it's /etc/init.d/net.tap0, yet other
> times it's something else.
> 
> I suggest instead relying on a generic configuration script to do
> interface configuration when the VPN comes up.

The trouble with that is that these scripts can do other things.
If all you're interested in is configuring via dhcp, then that's all
you want to start/stop.  At least that's what runs through my head.
It's because network configuration is distro specific, but 
starting/stopping/running/configuring a dhcp daemon isn't nearly so 
that makes this approach appealing.   On the other hand, if
the ifup/ifdown/(etc.) scripts do what's needed and don't cause
any problems then maybe it makes sense to use what the
administrator is familiar with -- but this assumes that the
person setting up OpenVPN is familiar with how network
interface activation is scripted.

In either case we'd be looking at an openvpn configuration
directive (or 2) that takes a command to run once
the link comes up (and down).  If that was in place then
any of A, B, C, or D, or your choice of using an ifup/ifdown
script would all work.

Given that.  Why not just use -up and --down to do what's
needed?  Avoid changing the code and write documentation.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Gert Doering]

Hi,

looking at the multitude of DHCP clients available for unix, the completely
different handling of DHCP on MacOS, and the issues that most unix clients
seem to have with "DHCP active on two different interfaces (ethX and tapY),
and both trying to set a default gateway", ...

On Mon, Mar 08, 2010 at 08:21:35AM -0700, James Yonan wrote:
> (2) Complex method: Write code in OpenVPN to simulate a DHCP client, 
> then translate the settings received in the DHCP reply to OpenVPN 
> push-style directives (such as ifconfig, route, etc.) as if they had 
> been pushed by the OpenVPN server.

... this seems to be the most portable way, as we already have the 
ifconfig/route code for all the platforms.

Well.  Let me rephrase.

The "simple way" is simple as far as the packet flow inside OpenVPN
goes (because OpenVPN only needs to transport packets, but not generate
them or parse them), but is, at the same time, the "most complex way" 
as far as getting it to work reliably across all supported operating 
systems.  Lots of testing and "configure" magic would be necessary to
reliably figure out how to do DHCP properly on each individual system.

I'm not saying it can't be done :-) - but just that the "simple way"
is not so simple, it's just complex in other places.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Peter Stuge]

Karl O. Pinc wrote:
> > I'm hoping that we can make "route-gateway dhcp" work on Unix
> > platforms as well.  I'm thinking there are two possible ways we
> > could do this:

Network interface configuration is highly distribution specific.


> A) dhclient
> 
> B) dhclient.conf
> 
> C) dhclient
> 
> D) dhcptl or omapi or .. omshell
..
> This would be tied to the ISC implementation, but probably nobody
> cares.

I know of at least four DHCP clients and I avoid dhclient as much as
possible. It would be a tremendous mistake to tie OpenVPN to any one
DHCP client IMO.


What most if not all distributions have in common, or could have in
common, is that a script configures the network interface. Sometimes
it's called ifup, other times it's /etc/init.d/net.tap0, yet other
times it's something else.

I suggest instead relying on a generic configuration script to do
interface configuration when the VPN comes up.

I believe that's actually what most distributions do already.


//Peter

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 09:21:35 AM, James Yonan wrote:
> OpenVPN 2.1 has a relatively recent feature that allows a TAP-based 
> OpenVPN session to be established where the client gets its IP 
> address
> 
> assignment and other attributes from the server-side DHCP server.

> I'm hoping that we can make "route-gateway dhcp" work on Unix
> platforms 
> as well.  I'm thinking there are two possible ways we could do this:
> 
> (1) Simple method: Trigger a DHCP client bind on TAP interfaces when 
> they are instantiated.  (This is what Windows does automatically)

Offhand, there seem to be various ways to go. 

A) OpenVPN restarts dhclient so that it autodetects the new interface.

B) Configure dhclient.conf with an interface directive for the
tap device.   It may be necessary to use hooks in dhclient-script.

C) A combination of A and B, where there's a separate dhclient
process run just for openvpn.  This might avoid problems with
B where the regular interfaces must also be configured because
autodetection is turned off.  It might also be more portable
across different dhcp client implimentations (or not.)

D) Use the dhcptl or omapi APIs or, perhaps even better, the omshell
command.  This would be tied to the ISC implementation,
but probably nobody cares.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

[Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[James Yonan]

OpenVPN 2.1 has a relatively recent feature that allows a TAP-based 
OpenVPN session to be established where the client gets its IP address 
assignment and other attributes from the server-side DHCP server.


The feature is enabled by the "route-gateway dhcp" directive on the client.

It's a pretty cool feature because it allows you to set up a TAP-based 
VPN server without configuring IP addresses, routes, etc. because you 
can simply leverage on the existing server-side DHCP server 
configuration.  When a client connects to the VPN, it gets an IP address 
assignment just as if it were physically "plugged into" the server-side LAN.


The problem is that "route-gateway dhcp" only works on platforms where 
the TAP driver negotiates a DHCP client handshake.  Currently, only 
Windows support this out-of-the-box (Windows supports it not because of 
any special code in the Windows TAP driver, but because the Windows DHCP 
client automatically binds to TAP adapter instances when they transition 
to the "up" state).


I'm hoping that we can make "route-gateway dhcp" work on Unix platforms 
as well.  I'm thinking there are two possible ways we could do this:


(1) Simple method: Trigger a DHCP client bind on TAP interfaces when 
they are instantiated.  (This is what Windows does automatically)


(2) Complex method: Write code in OpenVPN to simulate a DHCP client, 
then translate the settings received in the DHCP reply to OpenVPN 
push-style directives (such as ifconfig, route, etc.) as if they had 
been pushed by the OpenVPN server.


It would be great if someone wanted to volunteer to work on this.  I'm 
hoping that Mac and Linux could be supported via the Simple method.


James