Hi Greg, It sounds like your GridFTP servers are reporting their private IP addresses as their data interfaces. You can control the data interface that GridFTP (and globus-url-copy) report like so:
GridFTP: Set the 'data_interface' option in your gridftp.conf file to the value you want it to advertise. This option is documented in the GridFTP man page, which you can read here: https://docs.globus.org/globus-connect-server-installation-guide/man/globus-gridftp-server/ A GridFTP server will report the value set for the 'data_interface' option as the host/IP that other nodes should connect to if they are attempting to transfer data to this GridFTP server. globus-url-copy: Set the 'GLOBUS_FTP_CLIENT_DATA_IP' env variable to the value you want it to report for its data interface, and then export it. This will only be relevant in transfers where you are transferring between globus-url-copy and GridFTP directly, and won't matter for transfers where you are merely using globus-url-copy to transfer data between 2 GridFTP servers. -Dan Powers ________________________________ From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on behalf of greg whynott [greg.whyn...@gmail.com] Sent: Tuesday, April 18, 2017 2:13 PM To: gt-user@lists.globus.org Subject: [gt-user] force command to use DNS name instead of IP for remote commands. 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
