Enrico Scholz wrote: > >> I am running a multihomed host where 'local <extip>' must be > >> specified for proper operation. > > > > Could you add a route and use nobind? Unless you have one openvpn > > on each IP that should work. > > I would really like to avoid the NAT hackery.
I didn't mean to suggest any NAT. If you have access to the system that is running openvpn I think you could add routes to the routing table in that system which will remove the need for openvpn to explicitly bind at all. Applications that do not bind() are assigned source address according to the system routing table. Of course this will affect all processes on the system, not only openvpn. > > I would actually expect the firewall to notice that there is a new > > connection. Since it doesn't, maybe you can explicitly allow this > > traffic? > > I do not have access to this firewall. Can you reach someone who does? I guess the VPN working right is in their interest too, and.. > > I know I would prefer fixing the firewall rules. > > I would prefer to fix openvpn ;) ..I maintain that the problem is actually with the firewall that doesn't notice the new connection. (I guess because of too simplistic packet inspection?) > I think, supporting common TCP/UDP client functionality (which choses > random source ports) suits my needs best. I do not see reasons why > 'local' must be tied to 'lport'. The source IP and source port are specified using one and the same system call; bind(). It's likely that when developing the binding options it was simply thought that either both can be specified, or neither will be neccessary. Perhaps specifically because firewalls usually do connection tracking better than the one you're dealing with. :\ //Peter
