NWFTPD: Proper approach for the FORCE_PASSIVE_ADDR setting

An FTP server behind NAT (Network Address Translation) sometimes provides unique challenges, because initiating a passive FTP data connection causes the server to announce (in the data portion of packet) it's private address and port where it is listening, for the public client.  The public client cannot reach that private address.  To accommodate this, most NAT implementations will watch for passive FTP attempts, and translate the address not just in the TCP header but also in the data portion of the packet.  They will also dynamically open up the specified port on the firewall, so the client can connect to that port and address.

 

There are two cases when this may fail:

 

1. The NAT implementation doesn't know how to do these things.

or

2. The FTP session is encrypted though SSL.  Once you encrypt the FTP session, the NAT device cannot look inside the data portion to translate the address, or learn the port that should be dynamically opened.

In order to give administrators a way around this, Novell introduced a new setting to NWFTPD.NLM, in NetWare 6.5 SP4.

 

NOTE: Although this feature was introduced in NetWare 6.5 SP4, NWFTPD.NLM v5.05.04, there was a side-effect in some cases, so NWFTPD.NLM v5.06.04, Oct 27, 2005 (or newer), should be used. NetWare 6.5 SP5 is adequate.

 

In FTPSERV.CFG (assuming it was properly updated by the support pack process) there should be a new item near the top:

FORCE_PASSIVE_ADDR =

 

This setting tells NWFTPD.NLM what address to include in the data portion of it's passive replies.  In most cases, this will be an address that is not even bound to the NetWare FTP system.  It will typically be bound to the public side of the NAT device, and the NAT device will consider it to be statically mapped to the FTP server's private address.

 

That takes care of the private vs public address concern, but opening of the ports on the firewall has to be done as well.  The administrator will need to decide on a range of high ports to be used for passive FTP connections.  That range will have to be configured in at least two places:

 

- In the FTPSERV.CFG file, define the range by setting PASSIVE_PORT_MIN = and PASSIVE_PORT_MAX = as needed.

- In the NAT or Firewall configuration, open up the same range of ports, on the FTP server's public address.

 

The above steps will solve the problem of public clients failing to get passive data connections to the private FTP server.  However, if there are FTP clients inside private network who need to reach the FTP server, those clients will begin to fail after these changes is made, due to an issue called NAT loop back.  Failures will usually occur if a private client is told to go to a public address, but that public address is mapped to a private address within the client's private network.

 

In order to solve this issue, a secondary private IP address must be bound to the NetWare FTP server, and two instances of NWFTPD.NLM need to be running:  One for public clients, and one for private clients.

 

Hypothetical example:  (This example is for cases where both private and public clients need to access the FTP server. If only public clients need access, this configuration is more complex than necessary.)

 

Beginning point:

NetWare Server "ftpserv1" has private address 10.1.2.3.

NAT device statically maps that to public address 151.1.2.3.

 

Changes that must be made:

 

1.  In FTPSERV.CFG, tell the system to listen on just that one private address, and force the public equivalent as the passive address.  Also define the passive port range (in our example, we'll use 50001-50030). This takes a total of 4 settings.  Remember to remove pound signs (#) from the beginning of these lines if they are present.

 

HOST_IP_ADDR = 10.1.2.3

FORCE_PASSIVE_ADDR = 151.1.2.3

PASSIVE_PORT_MIN = 50001

PASSIVE_PORT_MAX = 50030

 

2.  Configure the NAT device or firewall to open that same TCP port range on 151.1.2.3.

 

3.  Add another private IP address to the NetWare system. This can be done with:

 

ADD SECONDARY IPADDRESS 10.1.2.4

 

This command can be done dynamically at the console prompt, but should be included in a more permanent location, like AUTOEXEC.NCF, or be set up in the INETCFG configuration, so it will be present after a reboot.

 

4.  Create an additional set of FTP configuration files, to use for the private side FTP server instance. The simplest way is to copy SYS:ETC\FTPSERV.CFG to SYS:ETC\FTPSERV2.CFG, and copy SYS:ETC\FTPREST.TXT to SYS:ETC\FTPREST2.TXT.

 

5.  Edit the new configuration file (FTPSERV2.CFG), find and set the following:

 

RESTRICT_FILE = sys:/etc/ftprest2.txt

HOST_IP_ADDR = 10.1.2.4

FORCE_PASSIVE_ADDR = 0.0.0.0

NOTE: In this case, either 0.0.0.0 or 10.1.2.4 would be fine for the FORCE_PASSIVE_ADDR setting.

NOTE: You can set the PASSIVE_PORT_MIN and _MAX back to the defaults, or leave them as they copied over from the first set of files.  Either way should work for the private side, and no firewall exceptions are needed in connection with this private side configuration.

 

6.  Edit the FTPSTART.NCF file and insure the following 2 lines are present:

 

nwftpd -c sys:/etc/ftpserv.cfg

nwftpd -c sys:/etc/ftpserv2.cfg

Extra comments or non-nwftpd commands should not be placed in this file, as it is used by iManager and the format is strict.

 

7.  Private side FTP users will need to be trained to use 10.1.2.4 (or the host name associated with that particular address) for their FTP connections, not 10.1.2.3 or 145.1.2.3 (nor their names).  Some sites have private-side DNS servers that associate private addresses with names, and so appropriate changes there would be helpful.