OpenVPN/Supporting "route-gateway dhcp" on non-Windows platforms

From Secure Computing Wiki
Jump to: navigation, search

Contents

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

References

Personal tools
Namespaces

Variants
Actions
Miscellaneous
Operating Systems
Toolbox