release notes | Book: 2.10, 2.11, 2.12, 2.13, 2.14 | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg

GridFTP Connections via two or more Network Interfaces

[return to top]


The host on which the GridFTP door is running has several network interfaces and is supposed to accept client connections via all those interfaces. The interfaces might even belong to separate networks with no routing from one network to the other.

As long as the data connection is opened by the GridFTP server (passive FTP mode), there is no problem with having more than one interface. However, when the client opens the data connection (active FTP mode), the door (FTP server) has to supply it with the correct interface it should connect to. If this is the wrong interface, the client might not be able to connect to it, because there is no route or the connection might be inefficient.

Also, since a GridFTP server has to authenticate with an X.509 grid certificate and key, there needs to be a separate certificate and key pair for each name of the host or a certificate with alternative names. Since each network interface might have a different name, several certificates and keys are needed and the correct one has to be used, when authenticating via each of the interfaces.

[return to top]


Define two domains, one for the internal and one for the external use. Start a separate loginbroker, srm and gridftp service in these domains.

The srm and the gridftp service have to be configured with the property listen, only to listen on the interface they should serve. The locations of the grid host certificate and key files for the interface have to be specified explicitly with the properties dcache.authn.hostcert.cert and dcache.authn.hostcert.key.


In this example we show a setup for two GridFTP doors serving two network interfaces with the hostnames door-internal ( and door-external ( which are served by two GridFTP doors in two domains.

ftp.authn.protocol = gsi

ftp.authn.protocol = gsi