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

Re: [Openvpn-devel] Re: Radius support (Authentification, Authorization and Accounting)

  • Subject: Re: [Openvpn-devel] Re: Radius support (Authentification, Authorization and Accounting)
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Tue, 17 May 2005 10:26:00 -0600 (MDT)

On Tue, 17 May 2005, Torge Szczepanek wrote:

> Am Dienstag, den 17.05.2005, 07:18 -0600 schrieb James Yonan:
> > It's more like the opposite:  1.x supported a specific tunx interface and
> > port for each client.  2.0 was rewritten to allow all clients to share a
> > single tun/tap interface and TCP/UDP port.  The 2.0 approach tends to be
> > preferred because it scales better and is easier to manage.
> I know this. I am using OpenVPN quite some time now. (And I am quite
> happy with it! ;-))
> You are right. Using just one Port (and one OpenVPN process) for all
> clients has many advantages over the 1.x behaviour.
> The only disadvantage is that one cannot disentangle different users by
> the device (only useful for tun (aka ptp devices)). The major advantage
> of this approach is that one can apply queuing disciplines for a user to
> a network device rather than to use tun0 and specify the users IP
> address. The queing discipline automatically gets removed, when the user
> disconnects and the device goes down.
> Another advantage would be that one can use the device number in Radius
> Authentication for having a unique NAS-Port.
> Is there an easy way to have a single OpenVPN process, running on just
> one port for multiple clients and assign each client a seperate
> tun-Device? Or would that patch be very long? 

I think the patch could be done, but it would have some disadvantages such
as (a) you would need to run OpenVPN as root (without dropping privileges)
because the daemon would need to dynamically open and close tun/tap
devices, (b) you have all the scalability problems of dealing with a large
number of network interfaces -- for example, on Windows, it's not even
practical to handle more than a relatively small number of TAP-Win32
adapters, and they can't easily be created and destroyed programmatically.


Openvpn-devel mailing list