Hi Arne, I left both options available, at least for now. Either 'client-ip', or 'localhost' as an undocumented alias.
This patch to 'client-nat' is necessary to allow it to work properly on a Windows client (not necessary on Linux) of client/server configuration when server issues OVPN DHCP addresses but the client has a static IP. Otherwise the traffic from the Windows client device back through the tunnel uses the DHCP address as source instead of the static IP. And this breaks the system. We have had to use our own build of this for many years now. We have several thousand clients running in this way on our system. Your request not to use 'localhost' is ok. So I changed 'client-ip'. But since we have so many clients already configured with the 'localhost' keyword, we would like to gradually make the transition. We would like to have 'localhost' be an undocumented alias to 'client-ip', at least until we have made the transition. Our hope is that we can do what is necessary to make this option available for others as well and merge it into the main build. When originally searching for a solution the 'client-nat' issue, we noticed that we were not the only ones running into it. BR Rafael On Mon, Jul 25, 2016 at 5:20 AM, Arne Schwabe <a...@rfc2549.org> wrote: > > > Am 05.07.16 um 15:13 schrieb Rafael Gava: > > Hi Arne, sorry for replying so late. > > > > Below is the NAT client-ip patch fixing the messed up whitespaces. > > The only difference from the previous patch, besides the whitespaces, > > is that I'm considering both strings 'client-ip' and 'localhost' as > > valid options. > > > > Please, whatever problem let me know. > Wasn't the general consensus on the mailing list that making localhost > an alias for client-ip is confusing? I wonder why you introduced it again. > > Arne >
