Using the Globus Toolkit with Firewalls

Resolving Firewall and NAT issues

As discussed in the previous Grids and Clusters columns, one activity that Grids must allow is the coordination of resources not subject to central control. In practice, this means that resources distributed across different sites on the Internet, which often have firewalls in between. In this article, we discuss the use of the Globus Toolkit® for Grid computing in the presence of firewalls, explaining what the issues are and what can be done to address them.

What is a Firewall?

{mosgoogle right} First we should discuss what we mean by a firewall . Generically speaking, a firewall is a system that allows some wanted stuff to pass through, while keeping out unwanted stuff (like fire). In terms of this article, a firewall is a device on the network that allows some traffic to pass through while blocking other traffic.

Many firewalls filter traffic based on the source or destination of the traffic. All traffic on the Internet, like postal mail, carries a header that contains a pair of addresses: one for the recipient and another for the sender (so that the recipient knows where to send a response). These addresses identify not only the computer but also a port number, which specifies the application for which the traffic is destined or from which it is being sent.

By filtering incoming traffic based on the recipient address in the message header, a firewall allows only traffic that is destined for specific and approved applications, such as Web and mail servers. High-end firewalls may inspect the message payload as well, in order to catch foul play, making sure the messages are not malformed or don't carry viruses. Firewalls may also filter messages based on the address of packet sender, to allow only traffic from authorized clients (it is possible to fake source addresses on the Internet, however, so this is not 100 percent reliable).

Firewall Diagram
Figure One: A common scenario showing two typical types of firewalls. A user, on the left, has a gateway router in his house that is blocking incoming connections. On the right, a site has a firewall that allows only authorized traffic to enter the site.

Less sophisticated devices may also act as firewalls but aren't commonly called firewalls. One common example is gateway routers that are sold to consumers. These permit multiple computers to share a single Internet connection, such as a cable modem or DSL line, by changing addresses in the outgoing traffic to permit this sharing (this technique is called NAT, or Network Address Translation). In addition, they typically block incoming network connections. For simplicity, we include such devices in our definition of firewall.

When Grids Meet Firewalls?

Let us now consider the issues that arise when trying to run a Grid in the presence of a firewall. Although we focus in this article specifically on the Globus Toolkit® (GT), the first issue is common with almost any new services a site may install: they need to be accessible through a firewall. GT consists of several services, including MDS (Monitoring and Discovery Service), which allows for information discovery; GridFTP, which allows for data movement; and GRAM (Grid Resource Allocation and Management), which allows for resource management. The services listen on a set of well-known ports for incoming connections; hence, if a site wants to make these services available outside a firewall, that firewall must pass traffic on these ports.

A second issue that arises with GT is that it provides the coordination of dynamic resources, namely, user processes. When a user sets the GRAM system to run a process on a (remote) computer, GRAM creates a subservice, called a Job Manager, that lets the user monitor and control the process. For example, the user can register a callback URL with the Job Manager that is used to inform the user of state changes in the monitored process. This feature results in a network connection from the Job Manager to the user when the job completes, informing the user of that fact and providing the exit status of the job.

This Job Manager functionality means that network connections are made from the site running GT back to the user. This situation may raise issues if the site's firewall doesn't allow for outbound connections or if the user has a firewall. Further complications may arise because the ports used for the callbacks are dynamically assigned by the client's operating system and not known ahead of time. Depending on the version of GT, which we will discuss in the following section, new ports may be dynamically assigned on the Job Manager side as well.

Sidebar One: NAT and Clusters

NAT (Network Address Translation) or IP Masquerading can be useful to clusters. If you enable NAT on the head (or gateway node), the cluster nodes can effectively communicate with the outside world. This enhancements allows nodes to access the Internet and even use NFS servers that only viewable to the head node. NAT only needs to be enables on the head node. The compute nodes only need to have their default route pointing to the head node. You can find more about NAT from the Linux Masquerade HOWTO.

GridFTP exhibits the same problem. When a data transfer is initiated, additional ports, called data channels, are dynamically assigned to the user process, and the bulk data transfers are made on those ports. A user may start multiple parallel data channels or orchestrate a third-party transfer by creating a user processes at two different remote sites and have them initiate direct data channels between themselves.

A third issue is encountered when using NAT. GT uses the callback paradigm to allow asynchronous communication; that is, a client will send an address and port to a service and then wait for a connection back from the service. Examples are clients registering callbacks with Job Managers so they can be informed when their jobs complete or when a new data channel connection is established in GridFTP. When traffic from clients is crossing a firewall that uses NAT, the address that a client believes to be his address is different from the address that appears in the outgoing traffic because of the changes made by the NAT process. As a result, connections back to the client using the given address are sent to the wrong place and never arrive.

    Search

    Feedburner

    Login Form

    Share The Bananas


    Creative Commons License
    ©2005-2012 Copyright Seagrove LLC, Some rights reserved. Except where otherwise noted, this site is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. The Cluster Monkey Logo and Monkey Character are Trademarks of Seagrove LLC.