* May not completely remove all the complexity from the package maintainers

* /etc/resolv.conf updates might be another headache

* /etc/resolv.conf updates might be another headache

Line 84:

Line 84:

Benefits compared to other solutions.

Benefits compared to other solutions.

−

* Allows us to leverage the non-OpenVPN OSS community (OpenVPN packages) to the integration, saving OpenVPN developers a lot of trouble.

+

* Allows us to leverage the non-OpenVPN OSS community (OpenVPN packages) for integration, saving OpenVPN developers a lot of trouble.

* Following the Unix philosophy: Several small modules which does dedicated work, but does it well

* Following the Unix philosophy: Several small modules which does dedicated work, but does it well

−

* Might re-use the --up/--down options for starting and stopping system wide configuration

+

* Might re-use the --up/--down options for starting and stopping system wide configuration - which might give even less changes to OpenVPN.

=== Concerns ===

=== Concerns ===

Line 93:

Line 93:

* Some distribution maintainers might not do a good job in integrating their DHCP clients with OpenVPN. This problem can be mitigated by proving good sample scripts, documentation etc. so that the integration is as straightforward as possible.

* Some distribution maintainers might not do a good job in integrating their DHCP clients with OpenVPN. This problem can be mitigated by proving good sample scripts, documentation etc. so that the integration is as straightforward as possible.

+

* It will be a wide range of OSes and distributions to support. This might lead to difficulties to support, due to the broad variety of solutions.

* If using --up/--down script this can cause some challenges when used together with --user/--group/--chroot

* If using --up/--down script this can cause some challenges when used together with --user/--group/--chroot

Feature description

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.

Rationale

At this point it makes sense to involve the users as much as possible.

Why should this feature be implemented?

What benefit would this feature provide to users?

What benefit would this feature provide to developers?

How many would benefit from this feature?

Alternatives

What can be done to circumvent lack of this feature?

Implementation options

Option 1: add a DHCP client to OpenVPN itself

Overview

High-level overview of this solution.

Benefits

Benefits compared to other solutions.

Does not depend on package maintainers as much as option 2

Will only "act" as a DHCP client for the current TAP device which the current OpenVPN instance is using

Can maybe, theoretically, open up for DHCP support for TUN devices as well, if the OpenVPN server instance can act as an DHCP relay

Concerns

Potential problems with taking this approach (and how to address them)

Adds complexity to OpenVPN. There's no way to address this issue.

May not completely remove all the complexity from the package maintainers

/etc/resolv.conf updates might be another headache

Tasks

List of things that need to done to make this work.

Sort out how to manage /etc/resolv.conf (or equavalent)

Option 2: let distribution maintainers handle DHCP integration

Overview

High-level overview of this solution.

Benefits

Benefits compared to other solutions.

Allows us to leverage the non-OpenVPN OSS community (OpenVPN packages) for integration, saving OpenVPN developers a lot of trouble.

Following the Unix philosophy: Several small modules which does dedicated work, but does it well

Might re-use the --up/--down options for starting and stopping system wide configuration - which might give even less changes to OpenVPN.

Concerns

Potential problems with taking this approach (and how to address them)

Some distribution maintainers might not do a good job in integrating their DHCP clients with OpenVPN. This problem can be mitigated by proving good sample scripts, documentation etc. so that the integration is as straightforward as possible.

It will be a wide range of OSes and distributions to support. This might lead to difficulties to support, due to the broad variety of solutions.

If using --up/--down script this can cause some challenges when used together with --user/--group/--chroot

Tasks

List of things that need to done to make this work.

Get response from all major platform's package maintainers, get their help implementing the needed scripts