|
|
I-Gene Leong <openvpn@xxxxxxxxxx> said: > I'm looking at using OpenVPN to secure wireless LANs in multiple > locations with the same clients. From reading the documentation it > sounds to me like each separate tunnel needs its own UDP port and > daemon. This would be mildly inconvenient, although I guess I could live > with it. > > My question is: is it possible to set things up so that I can run one > daemon on one UDP port and have my multiple clients connect to that port? This feature is not yet implemented integral to OpenVPN, though you can use inetd/xinetd to accomplish it (using different ports). Unfortunately, the inetd/xinetd semantics are not ideal -- you need a separate inetd/xinetd configuration element for each OpenVPN tunnel. For that reason making an integral forking server feature is high on the wishlist. It would be implemented by having a server listen on a single public port for incoming connections requests. The requests would then be matched up with either a static configuration file or a dynamic configuration template, and a new OpenVPN process would be forked off, running on a a separate dynamic port (allocated from a pool), and using a separate tun/tap interface. There have also been requests for an OpenVPN mode to handle multiple clients from a single thread, while only using a single port and a single tun/tap interface (rather than multiple OpenVPN processes for each tunnel, each with their own port and tun/tap interface). I have some problems with this approach -- essentially you need to implement a number of functions inside of OpenVPN which are now covered by the OS, violating the principle of modularity and minimalism which has guided OpenVPN's development process thus far. And the only real benefit you gain is a certain kind of scalablity. I say "certain kind" because it is not even clear that this is an unequivocal win from the performance perspective -- as an example, consider an SMP machine. Here the scalability win only occurs when you have at least as many threads as processors, and those threads need to be sufficiently decoupled that they don't lock down the bus with a lot of mutex activity. In the SMP case, the performance win occurs when you have a larger number of decoupled processes -- exactly what the integral forking server concept delivers. Comments? James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |