Hello Daniel and Michael, I actually discovered the solution last night, but thank you very much for your responses, I appreciate it.
In case the documentation folks are looking.... I found the answer in section which would appear to be the 'wrong' section, as the section was related to security methods and options. (http://toolkit.globus.org/toolkit/docs/4.2/4.2.1/data/gridftp/admin/ section 1, Security Considerations, Section 1.3.3) In the section you would expect to find it, it is non existent.. This section talks about NAT exclusively, even the chapter is named NAT..., it speaks to methods employed to deal with NAT scenarios. Seems like a more logical place to at least reference this flag. http://toolkit.globus.org/toolkit/docs/latest-stable/admin/install/#_network_address_translation_nat_2 (section 4.1.3 and 4.2.3 speak directly about NAT setups but no mention of the data-interface option. Regardless, this forced me to read and understand more of the options/methods of the suite, so all good! :) be well, greg On Tue, Apr 18, 2017 at 5:40 PM, Michael Link <ml...@globus.org> wrote: > For the machines beind NAT, you'll need to edit the configuration to set > the public address they are reachable on. For sshftp, you can add the > -data-interface option to the exec line at the end of > /etc/grid-security/sshftp. The value can be a hostname or IP address. > > Mike > > On 4/18/2017 2:13 PM, greg whynott wrote: > >> Hello, >> >> First post, searched around for an answer but maybe I'm not using the >> proper lingo. sorry in advance if this has been covered previously. >> >> >> >> 3 machines involved, 3rd is where commands are being issued from >> (tor-hm1) it is local to tor-xfer. >> >> tor-hm1 - local network - behind NAT >> tor-xfer - local network - behind NAT >> chn-xfer remote network - public IP >> >> This command works as expected, moving data from tor-xfer to chn-xfer, >> >> [hpcdata1@tor-hm1 ~]$ globus-url-copy -vb -cd -p 2 >> sshftp://hpcda...@tor-xfer.removed.com/var/tmp/outtest.gz >> <http://hpcda...@tor-xfer.removed.com/var/tmp/outtest.gz> sshftp:// >> hpcda...@chn-xfer.removed.com/var/tmp/outtest.gz >> <http://hpcda...@chn-xfer.removed.com/var/tmp/outtest.gz> >> >> Attempting to move data in the other direction from chn to tor, this >> command will fail: >> >> [hpcdata1@chn-xfer ~] globus-url-copy -vb -cd -p 2 >> sshftp://hpcda...@chn-xfer.removed.com/var/tmp/chn-300k.fl >> <http://hpcda...@chn-xfer.removed.com/var/tmp/chn-300k.fl> sshftp:// >> hpcda...@tor-xfer.removed.com/var/tmp/chn-300k.fl >> <http://hpcda...@tor-xfer.removed.com/var/tmp/chn-300k.fl> >> >> tor-hm1, and tor-xfer are RFC1918 numbered and behind a NAT firewall >> with 1 to 1 mapping to an outside address on the firewall. Any >> traffic hitting this outside IP will be forwarded to tor-xfer. THis has >> been tested and confirmed to work, there are no readability issues from >> the remote network for any ports. >> >> chn-xfer has an interface on a rotatable public IP, no NAT. >> >> tor-hm1 and tor-xfer use internal DNS. The answers returned are not >> the same as what the internet name servers will return when asking for >> host lookups. think split dns. >> >> What appears to be happening is when tor-hm1 contacts chn-xfer, it >> asks it to "connect to this IP and send this file", the problem is it >> is telling chn-xfer to connect back to the RFC1918 IP address, not the >> public one. which of course it can't reach. This was verified via >> packet trace, chn-xfer attempts to connect to tor-xfer's internal IP. >> >> >> >> *My question:, Is there a method to force the hostname to be passed >> over to the remote server instead of the IP, so the remote end does the >> lookup?* If chn-xfer did its own lookup on the name, it would get >> the 'proper' IP to use and things would likely be good again. >> >> >> >> While I could be wrong, it would seem to be a better idea to have the >> local NS used instead of the requester doing this for them, what is the >> thinking here? Just curious really. >> >> thanks for your time, >> greg >> >
