Joe Patterson wrote: > I'm actually kind of curious what reasons there would be that > listening to 0.0.0.0 would be undesireable. .. > if you want to have different configurations bound to different > interfaces,
Exactly. > while I could possibly see having one configuration for Internet > users connecting inbound via VPN and maybe internal wireless users > using a different configuration because they understandably don't > trust WPA... it's a stretch. Not really. I've implemented this on a customer site with a fairly complex network split into different subnets, but with a single router box that also handled multiple VPNs. > And I'm pretty sure that if you start one openvpn process listening > on a specific IP, then another listening on 0.0.0.0, it'll still > work, and the second instance will effectively be listening on > every *other* IP from the first. You'll need to do some more socket programming. :) It will not work. Ports are first come first serve. Only one process can bind to a port at a time. Multicast is the exception, but then the sender must also be using the multicast as destination. > I'm all for adding flexibility, but this really seems like a solution > to a problem for which there's hardly ever *not* a better work-around. I actually think the proposed patch is a workaround, and that driving a configuration change into openvpn from the system components which are in charge of the network reconfiguration in the first place is the only actual solution. //Peter
