|
|
Doug Lytle <support@xxxxxxxxxxxxxxx> said: > Chris, > > I'm still waiting on a response from my last question. I have not been > able to get more then 1 tun device and 1 tap device to work > concurrently, but I am sure others have. I want to support not more > then 10 tap devices. I would guess that James has been a bit busy as of > late or we'd be seeing more posts from him. > > I'm hoping, givin time, we'll both get our questions answered. OpenVPN supports any number of concurrent tunnels. Each tunnel must have: * its own port number (--port) * its own tun/tap interface (--dev and/or --dev-node) * a separate OpenVPN process and configuration file (--config) On Linux 2.4, tun and tap devices are created dynamically, and it is possible to have more than 100 tun/tap interfaces. On Windows, tun/tap interfaces must be created manually before usage. It's pretty easy, there's a start menu item for it. I'm not sure what the limit is under Windows, but I would guess that it's less than Linux. The above approach has its strengths and weaknesses. The key strength is that handling one tunnel per OpenVPN process and requiring a separate port number and tun/tap interface for each tunnel makes the code simple, modular, and easy to maintain. It also makes the OS kernel do more of the heavy lifting such as handling the routing between tun/tap interfaces, implementing bridging, etc. The weakness is that OpenVPNs scalability is constrained by the OS's ability to handle larger numbers of tun/tap interfaces, and by the complexity of needing to maintain a larger number of configuration files. A key feature which is not yet available in 1.5.0 but I expect some time down the road is "point-to-multipoint" mode which has been discussed and argued at length on this list. In this mode, a single OpenVPN process, running on a single UDP port, controlling a single tun/tap interface will be able to drive a large number of tunnels to different peers. This type of model should be able to scale to thousands of tunnels (assuming that the processor and memory are up to task). James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |