I'm actually kind of curious what reasons there would be that listening to 0.0.0.0 would be undesireable. For other daemons, I can see a rationale because of two reasons, one being that you don't trust the security of the daemon and want to add interface specificity to your firewall rules for belt-and-suspenders security. The other reason I can think of is if you want to have different configurations bound to different interfaces, like maybe running squid as a caching proxy for your internal users but as a load balancing proxy for inbound connections to a web server, or if you want to have a DNS server that returns different information based on what IP is being accessed but don't want to use views.
Neither of these scenarios makes much sense. If you don't trust the security of openvpn enough to let it listen on the internet, you probably shouldn't be using it in the first place. And 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. 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'd still have issues if you have multiple dynamic IP's, but that's getting to be *really* convoluted and weird. 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. On Sat, Mar 12, 2011 at 10:36 AM, Peter Stuge <pe...@stuge.se> wrote: > Federico Heinz wrote: >> The reason I looked into this in the first place was that, unlike >> those TCP-based protocols, I couldn't get OpenVPN to work on a >> firewall with two external IP addresses without running two deamons, >> each one bound to one interface only. It is then that I stumbled upon >> the difficulty of setting up the server that must listen on an >> interface that has a dynamically-assigned address. > > If this is the problem you want to solve I have to say I think you're > doing it the wrong way. > > There are components in your system which *will* know when your > address is reconfigured. Please just configure them to reconfigure > OpenVPN. This would seem to be a good use for the management > interface in OpenVPN. > > I like to use udhcpd for systems like this. It is fast and > no-nonsense. It runs a script that you have to write. > > It makes no sense trying to work around the requirement of knowing > your configuration. That is always neccessary, unless you are > prepared to listen on 0.0.0.0, which I would guess already works > without special OpenVPN options or code. > > > //Peter > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
