release notes | Book: 1.9.5, 1.9.12 (opt, FHS), 2.11 (FHS), 2.12 (FHS), 2.13 (FHS), 2.14 (FHS), | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg

Firewall Configuration

The components of a dCache instance may be distributed over several hosts (nodes). Some of these components are accessed from outside and consequently the firewall needs to be aware of that. This section assumes that all nodes are behind a firewall and have full access to each other. More complex setups are described in the following sections. Depending on the access method, certain ports have to be opened to only some of the nodes. We will describe the behaviour of a standard installation using the default values. Since dCache is very flexible, most port numbers may be changed in the configuration. The location (node) of any dCache component might also be changed from this standard.

[return to top]

The dCap Protocol

The dCap protocol should be used for local, trusted access only, because it is not authenticated. The traditional method is to mount pnfs locally on the client and use paths to the files on this local mount to address files. For this, the client has to be able to mount the NFS export of the pnfs server. It is also possible to use the dCap protocol with a URL instead of a local path within a pnfs mount. The URL has the form

dcap://<dCapDoorHostFQN>:<dCapDoorPort>/<fullPnfsPath>

If the <dCapDoorPort> is not specified, 22125 is used to establish a TCP connection to <dCapDoorHostFQN> (see next paragraph). In this case no NFS mount is needed anymore. However, the access is unauthenticated and therefore access is only granted if the other part of the UNIX rights are set accordingly. In other words: The user is mapped to nobody for unauthenticated dCap access.

In both cases (pnfs mount and URL access) the dCap client (dCap library or dccp command) will connect to the dCap door (doorDomain) on the admin node with TCP port 22125 (can be changed in config/dCacheSetup with dCapPort). After the pool manager selected a pool to be used for the transfer (the section called “The Pool Selection Mechanism” describes how to configure that selection mechanism.) this pool will establish the data connection to the client on a TCP port which has been selected by the client. The port range to use may be specified on the client side (e.g. by the -p option of the dccp command.)

[return to top]

The GSIdCap Protocol

The GSIdCap protocol is the dCap protocol with a GSI authentication wrapper (tunnel). The mechanism is the same as described for the URL-stype dCap protocol in the previous section. The only difference is the default port number: For the GSIdCap door the default port number is 22128. It is specified in config/dCacheSetup with the parameter dCapGsiPort.

Another difference between the dCap door and GSIdCap doors is that the dCap door is started on the admin node and there can only be one in the standard configuration, while there may be several GSIdCap doors on separate nodes. Correspondingly, ports have to be opened in a firewall. Note that it should not be necessary to run as many GSIdCap doors as GridFTP doors (see below), because no data is transfered through the GSIdCap door.

[return to top]

The GridFTP Protocol

A GridFTP client connects to one of the GridFTP doors on TCP port 2811. The data connections are established independent of the direction of the data transfer. In active FTP mode the server connects to the client while in passive FTP mode the client connects to the server.

In active FTP mode the pool selected by the pool manager (see the section called “The Pool Selection Mechanism”) will open one or more data connections to the client on a TCP port in the range between 20000 and 25000. In passive FTP mode, the client will establish the data connections to the GridFTP door in the same port range. The pool will connect to the door and the door will route the data traffic. It is not possible to establish a direct connection between pool and client in passive mode, because the FTP protocol redirection mechanism has to be triggered before the client sends the name of the requested file.

[return to top]

The SRM Protocol

An SRM is a webservice which uses the https as transport protocol and negotiates data transfers between the client and the server as well as between the server and another server. For the actual data transfer one of the other protocols is negotiated. Usually this is GridFTP - especially for wide-area transfers. There are two things to note about SRM-initiated GridFTP transfers:

For reading data, only active FTP mode will be used, i.e. the pool containing the data will connect to the client or to the server which should receive the data. For writing, only passive FTP mode will be used, i.e. the client or the pool containing the data will connect to the client or to the server which should receive the data.

Apart from SRM put and get operations which always copy data between one SRM and the client there is also a true SRM copy from one SRM to another SRM. There are two modes for SRM copy: pull and push mode. If the destination SRM is dCache based and SRM pull mode (default) is used, the destination pool will play the role of the GridFTP client, will contact the GridFTP door of the source instance and receive the data directly from the source pool (if the source system is a dCache system). If push mode is used and the source is a dCache based SRM, the source pool will be the GridFTP client and will send the data to the GridFTP door of the destination. All this might have to be considered when designing the system and configuring the firewall.

[return to top]

Pool Selection

Restricting wide-area transfers to a subset of your dCache pools may be done with the pool selection unit in the pool manager. the section called “The Pool Selection Mechanism” contains a describtion on how to do that. This can be useful to ease firewall configurations, optimize throughput, and improve security.

[return to top]

Protocol Overview

The following table gives an overview about the default ports used by the client protocols supported by dCache. Note that all of them may be changed in config/dCacheSetup.

Table 23.1. Protocol Overview

Protocol Port(s) Direction Nodes
dCap22125incomingdoorDomain (admin node)
 anyoutgoingpools
GSIdCap22128incominggsidcapDomain (where GSIDCAP=yes in node_config)
 anyoutgoingpools
GridFTP2811incominggridftpDomain (where GRIDFTP=yes in node_config)
 20000-25000outgoing (active FTP)pools
 20000-25000incoming (passive FTP)gridftpDomain
SRM8443incomingsrmDomain