NinfG and Firewall

The latest version of NinfG (version 5.0) has a lot to offer in terms of allowing client-server connectivity. First, it introduces the invoke server module separating components used to invoke remote applications from the core. This does not only decouple NinfG from the Globus Toolkit like the previous versions, but it also allows the use of other middlewares such as SSH to execute remote commands. Since most Linux distributions already include some form of SSH, this makes the installation of NinfG more useful and a lot easier. You don’t have to install the Globus Toolkit just to install NinfG. The other feature I like is the communication proxy module, which tries to solve firewall-related problems. Unfortunately, NinfG currently only supports a communication proxy for the Globus Toolkit. If you don’t want to install the Globus Toolkit and only employ SSH invoke server, you are out of luck.

In this post, I would like to introduce a work-around of the firewall problem using only the SSH invoke server. The assumption is that the NinfG client and server applications are separated by a firewall. We would like also to assume that the client machine, where the client application is running, can connect to the server machine via SSH directly or via virtual private network. In this way, we can then use the SSH invoke server. If not, we are completely out of luck.

Although NinfG version 5 can now use SSH to invoke remote commands, it still has the same firewall problem inherent when using the Globus Toolkit. The reason is that the server application still needs to connect back to the client application. So if there is a firewall in-between client and server applications, this connection always fails and thus the entire application fails even if the client can connect to the server via SSH (since SSH connection is usually only allowed one way). This is further compounded if the client machine is in a NAT network.

To solve the problem, we should find a way such that the server application does not have to connect back directly to the client application, which causes the connection failure. My solution is therefore to use SSH port forwarding. Since we can connect to the server via SSH, we can instruct SSH to forward a port from the server machine to a local port in the client machine. We can then configure the server application to connect to this local port (in the server machine) instead of connecting directly to the client machine. At the same time, we can also configure the client application to listen to this specific local port.

Fortunately, NinfG allows us to do this using the configuration file. The specific section to use is the CLIENT section. The CLIENT section of the configuration file can look like this:

<CLIENT>
    hostname    localhost
    listen_port 2222
</CLIENT>

This will trick the server application to connect to port 2222 in localhost (which is set to be the hostname of the connecting client). But local port 2222 in the server machine is forwarded to the client’s local port 2222 via SSH. So when the server application connects to this port, it is indirectly connected to the client application and thereby establishing the server and the client connection with SSH working in the background. The SSH command to achieve this is as follows (run from the client machine)

[user@client]$ ssh –R 2222:localhost:2222 remoteserver.com

For a more general setting, you can use a third machine which is globally accessible via SSH. You can then use SSH to forward a port from this third machine to a local port in the client machine and configure NinfG’s server applications to connect back to this machine in the forwarded port. The CLIENT section of the configuration file will now look like this assuming thirdserver.com is the hostname of the third machine.

<CLIENT>
    hostname    thirdserver.com
    listen_port 2222
</CLIENT>

And the SSH command is

[user@client]$ ssh –R 2222:localhost:2222 thirdserver.com

This also assumes that you have an account in thirdserver.com machine. Or else, you will not be able to connect to it. In general, you should allow the forwarded port to be available to any machine, not just thirdserver.com. In this way, other server applications residing in other machines can connect to your client application via thirdserver.com. To do this, you can set GatewayPorts to yes in /etc/sshd_config in thirdserver.com.