[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] DHCP over tun?

  • Subject: Re: [Openvpn-users] DHCP over tun?
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Tue, 21 Dec 2004 05:02:57 -0700 (MST)

On Mon, 20 Dec 2004, Leonard Isham wrote:

> On Mon, 20 Dec 2004 16:55:02 -0700, Hans Fugal <fugalh@xxxxxxxxx> wrote:
> > I love openvpn, but I am uneasy about ifconfig-pool. No doubt many of
> > you will try to convince me it is OK with varying degrees of success,
> > but let's say for the sake of this thread that I want to leave things
> > that DHCP has been doing well for so long up to a DHCP server, and ask
> > openvpn only to do what it does best: VPN.
> > 
> > I've done this happily in a bridging setup, but I'm not clear whether
> > it can be done with TUN. TUN being IP-based as it is, I'm guessing
> > it's not possible since communication over the VPN requires routing
> > and all that good stuff.
> > 
> > I wonder, though, would it be possible to set up the openvpn as a bona
> > fide DHCP relay?
> > 
> > What are your thoughts on this?
> > 
> > PS Yes, I can think of things that DHCP does, that we use, that
> > openvpn does not emulate. I think it's silly to emulate DHCP to the
> > point of implementing DHCP if there's a way to work a real DHCP server
> > in there.
> > 
> > 
> First of all the system running OpenVPN would have to support BOOTP
> forwarding, yes DHCP is built on the BOOTP foundation and uses the
> same basic packet.  Aftere that you neeed your DHCP serer correctly
> configured.

I can see a few more issues which would need to be resolved in order to 
use a DHCP server in --dev tun mode:

(1) The OpenVPN server would need to sniff the DHCP handshake so that it
would know which IP address was assigned and add it to its routing table.  
The address would also need to be added to the kernel routing table, and
would ideally need to be known in advance at daemon startup because adding
system routes midstream breaks OpenVPN's reduced privilege model.

(2) The DHCP client would need to handle point-to-point interfaces.

(3) The DHCP client and server would need some ability to handle the
dynamic route propagation of leased addresses.

Of course this all works perfectly if you are running in --dev tap mode
because (1) and (3) are already accomplished through ARP-based MAC address
learning and (2) is not an issue since DHCP clients are already designed
to operate natively on ethernet interfaces.

I see DHCP and Ethernet as being very closely intertwined.  When you 
decouple them, you then need to deal with route discovery and propagation 
which under Ethernet, would be handled by ARP.

While --ifconfig-pool is not a substitute for real DHCP, when you consider
its automatic route propagation features, you have something that goes
beyond what vanilla DHCP can do.  Consider also that OpenVPN can push an
IP address, routes, and DHCP options to a client based on high-level,
authenticated client properties such as the certificate common name, and 
do this for both virtual ethernet (tap) and virtual point-to-point 
(tun) links.

One solution might be to write a --client-connect script which acts as a 
DHCP proxy.  It masquerades as a client to the DHCP server, gets the 
address lease, then pushes it to the OpenVPN client via --ifconfig-push.

In OpenVPN, --ifconfig-pool (address pool management) is decoupled from 
--ifconfig-push and --push "route ..." (dynamic route propagation), so you 
have a certainly level of flexibility with regard to replacing address 
pool management with something else like DHCP or RADIUS, but still keep 
the ability to do dynamic route propagation.


Openvpn-users mailing list