|
|
> > A protocoll that negotiate the port to use, would require the firewalls > > to understand this protocoll to dynamicly open the right ports, like with > > ftp, if you don´t want to open up a wide range of ports. > > I'm not sure this is true. Consider that most firewalls, upon seeing an > outgoing UDP packet fly by on port X, will open up a temporary hole allowing > return packets on port X, from the destination address of the outgoing packet. > > ... > > > This works if (a) the firewall is stateful and (b) outgoing packets > are not filtered. Yes, but many corporate firewalls are configured to not pass all outgoing packets. If you want openvpn to pass such a firewall you have 2 choices. 1. Use a port already opened because of another service. Yes, this ugly and bad, but it works (through a non proxy based firewall). 2. Make the firewall admin open up the neccessary port. Either which, it´s much easier to educate the users that port XXX is the nessecary open outbound port, than not knowing or having to ask the admin to open up a range of ports. Rolf Weber said: > > I fully agree with this. Try to make it use only ONE port. > > > No, please don't. > Don't add complexity (especially to a security product) as long as > it is not essentially needed. I agree with this too. I´ve been using OpenVPN for net-to-net vpns for quite a while, and really enjoy that it´s such a small, simple software, but still has all the required security features. But as I have started to use it for "roadwarrier" configurations I´ve found not beeing able to use a singe port a problem. So, of cource, one has to weight the added complexity and increased risk of adding a bug with the added usability. If the goal of OpenVPN is to do net-to-net vpns and small (1-10 users) road warrier setups, then I agree, don´t add the this complexity. But if the goal is that OpenVPN should work well with hundreds of roadwarriors, then I think multiplexing the sessions over a single port is necessary. James Yonan said: > > Ideally, I´d like OpenVPN to be able to use one port for all clients, > > then start several instances of OpenVPN on the server to make it listen > > to say, UDP/53 UDP/500, TCP/80, and then tell the client to try them all > > if the first fail! > > Suppose client A is connected to UDP 53. The network hiccups and the client > reconnects to TCP 80. But the OpenVPN process on UDP 53 still thinks it's > connected to the client, so it holds on to client-specific resources such as > return routes or tunnel endpoint addresses. Okay, maybe that wasn´t such a good idéa. Though this could be solved by some inter-process communcation that terminates the first process if a second one recieves a session from an already connected user. However, I don´t think this added complexity can be motivated by the usage. Just my 2 cents... PS. I think OpenVPN is the coolest vpn software availible, both commersial and non-commerial, so don´t get me wrong! /Mathias |