Hi Arne, thanks for the prompt feedback. please see comments in-line:
Thanks in advance, Rafael On Wed, Aug 26, 2015 at 5:35 AM, Arne Schwabe <a...@rfc2549.org> wrote: > > > Am 26.08.15 um 03:43 schrieb Rafael Gava: > > Hi, > > this is my first submission to the list and I hope that I'm doing in the > right way. :-) > > Yes submitting patches to the list is the preferred way. I haven't looked > in the patch yet. I am first trying to understand the goal of the patches. > > > Well, the features added to Network Address Translator are: > > 1) Allow the user to use the string "localhost" on the client-nat network > configuration in a way that is not necessary to inform the IP address > beforehand. Openvpn will set the dynamic received IP from DHCP. > Example: > > client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the > 'localhost' string with the DHCP address received from openvpn server. > > > I am not sure what you trying to achieve here? Forward all packets > intended for this host to another? > RafaelGava: yes, exactly!!! Today we have hundreds of boxes on the field, including PCs (Windows) and also embedded devices, all running openvpn with NAT in a way that these boxes work as a kind of router for another bigger equipments. So, the reason for the NAT is that we can establish another virtual network on top of the vpn one and then reach these bigger equipments without changing its local network infrastructure. Let me give an example. Suppose that we have 2 equippments and one openvpn box on the same LAN. The configuration that we are setting on the openvpn client is as showed below: client-nat snat localhost 255.255.255.255 172.20.1.15 # vpn box. Note that with the localhost string, we don't need to worry which IP it will get from openvpn server. client-nat snat 10.10.10.132 255.255.255.255 172.20.1.16 # Equipment 1 client-nat snat 10.10.10.134 255.255.255.255 172.20.1.17 # Equipment 2 So, with this configuration it's possible to reach these 2 equipments through the 172.20.1 network. In general, a subnet is set for each openvpn box. > 2) Allow the user to enable the FTP NAT support through the > --enable-nat-ftp-support option. > This is useful for systems that don't have conntrack-tools support, for > example on Windows systems. On windows this feature is enabled by default. > > enable-nat-ftp-support (yes | no) > > Okay yes. Active FTP is broken by our simple nat implementation. But I > think FTP, let alone active FTP is dead. I am not sure if we should support > this in our simple NAT implementation. > RafaelGava: I agree with you but unfortunately there are a huge legacy of proprietary equipments on the field that still use Active FTP and we have no control over them. So, based on these items and difficulties that the patch was written. > > > Arne >
