|
|
Chris Heinze <x@xxxxxxx> said: > hi! > > > My plan is that the initial version of the forking daemon will follow the > > current OpenVPN model of one process, port, and tun/tap dev for each tunnel, > > why one (server) port for each tunnel? TCP allows port reuse because it is connection-oriented. A hundred different connections to the same well-known port is possible, because the OS can fork separate processes for each connection instance, and the IP stack can keep track of them. UDP, however, is another matter. Because UDP is connectionless, the destination port number is the key piece of information that tells the OS which process to route the packet to. And you want to use multiple processes for multiple tunnels because you want the SMP scalability win. Allocating dynamic ports is actually quite typical behavior for an IP stack. For example, every client-side TCP initiation causes the OS to allocate a dynamic port number. Stateful firewalls know how to play along with this. > if you really want to ease things: let there at least be the possibility for the server to receive all connections for all tunnels > on the same port... This is planned -- however, once the tunnel is started, it will switch over to a dynamic port number. > each time i have to configure ftp, h323, or similar <bleeep> thru a firewall > i become depressive. why repeat mankind's sins over and > over... Well no need to be too depressed, because most stateful firewalls will not need to know about OpenVPN's dynamic port usage. Most likely, you will need only one firewall hole, and that will be for the server's well-known port that is used to accept initial connection requests. > hm, did you understand my idea of simply using an arp library instead? You mean implementing a kind of userspace ethernet switch? James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |