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. James
