this is a test sitewide banner

Update and test your Globus Connect Server configuration

November 27, 2017   |  Greg Nawrocki

Note: With the release of Globus Connect Server v5, this article contains outdated/inaccurate information. Please refer to this document for help with troubleshooting Globus Connect Server connectivity issues.

If you are responsible for managing one or more of your organization’s Globus endpoints, you may need to take action on or before December 9, 2017 to ensure that your Globus endpoints continue to work. At your earliest convenience, please read https://www.globus.org/blog/important-update-your-globus-connect-server-configuration and ensure you make the necessary updates to your firewall configuration, if applicable.

If you do make changes to your firewall configuration and would like to test those changes, we have set up test services for your convenience.


Overview

We have set up GridFTP and MyProxy check services running on 54.237.254.194, to help Globus endpoint administrators confirm that their site's firewall is correctly configured. These services allow you to conduct a simple, self-scan of your endpoint server(s) from our host at this IP address, and confirm that your site’s firewall policy permits inbound traffic from the 54.237.254.192/29 CIDR block.

Use

It is important to note that the check services will only scan the client that is making the scan request—there is no way for the client to request scanning of a host other than itself. As a result, you must run this scan from each GridFTP node and MyProxy node (if any) in your endpoint, to check if traffic from the GridFTP and MyProxy check services is able to reach that particular node.

The GridFTP check service listens on TCP port 50000 on 54.237.254.194. The MyProxy check service listens on TCP port 50001 on 54.237.254.194.

The client must establish a connection with the check service, and then send it a message that contains ONLY the port on the client that the client wants the check service to scan.

The simplest way to use the check services would be to construct a netcat command such as this one that uses the GridFTP check service:

$ echo 2811 | nc 54.237.254.194 50000
Scan of 1.2.3.4:2811 successful.

The above command connects to the GridFTP check service and instructs it to scan the host on port 2811 to confirm that it could connect to a GridFTP server listening there. From the output, we can see that the command was run from the host with IP address of 1.2.3.4, and that the scan was successful.

 

Here is a similar command to check that your MyProxy service running on port 7512 can be reached by the MyProxy check service:

$ echo 7512 | nc 54.237.254.194 50001
Scan of 1.2.3.4:7512 successful.

Other tools that allow the establishment of a raw connection, such as telnet, may also be used:

$ telnet 54.237.254.194 50000
Trying 54.237.254.194...
Connected to 54.237.254.194.
Escape character is '^]'.
2811
Scan of 1.2.3.4:2811 successful.
Connection closed by foreign host.

 

Results

After the scan has been conducted, the GridFTP check service and MyProxy check service will issue a response to the client containing the results of the scan. Examples of check service responses include:

Scan of X:Y successful.

The check service connected to X:Y and received data consistent with what was expected for the service being checked on the client.

Scan of X:Y failed: [Errno 111] Connection refused

The check service attempted to connect to X:Y, but the connection was refused. Possibly no service is running on this port on the client, or there may be a firewall that is 'politely' refusing access.

Scan of X:Y failed: timed out

The check service attempted to connect to X:Y, but the connection timed out. Very likely there is a firewall that is just silently dropping the connection attempt.

Scan of X:Y failed: Bad port value Y

The check service evaluated the port value supplied by the client and determined it to be invalid.

Scan of X:Y failed: Unexpected GridFTP Banner

The check service connected to something listening on the client at X:Y, but the data received from the client was not consistent with what was expected for a GridFTP server. Some sites customize their GridFTP banner, so this is not necessarily a hard fail. If you encounter this message, it would probably be best to contact Globus support so that we can take a closer look.

Scan of X:Y failed: Unexpected MyProxy Reply

The check service connected to something listening on client at X:Y, but the data received from the client was not consistent with what was expected for a MyProxy server. If you encounter this message, it would probably be best to contact Globus support so that we can take a closer look.


If you have any questions, please email Globus support (support@globus.org), or post to the Globus admin discussion (admin-discuss@globus.org) mailing list.