Why PASV Poses Problems for FTP Servers on Internal Networks.

The other server-side problem that can occur is when a client is trying to access an FTP server on an internal network protected by a routing device.  Because a server response from PASV includes an IP address and port number, if this IP address corresponds to a private network then the client will not be able to connect to that private address.  From our PASV example above, we have:
Server:  227 Entering Passive Mode (172,16,3,4,204,173)
If left unaltered, the client would try to connect to port 52397 on the IP address 172.16.3.4.  If the client is not on the private internal network, the client would time-out trying to connect to that address, when in reality it should be connecting to the external IP address of the routing device.
Solution 1:  The network administrator of the server network can consult the routing device vendor's documentation to see if FTP connections can be dynamically monitored and dynamically replace the IP address specification for packets containing the PASV response.
Using our PASV example above, when the FTP server replies to the PASV request:
Server:  227 Entering Passive Mode (172,16,3,4,204,173)
The routing device should rewrite the packet like this, assuming the external address is 17.254.0.91:
Server:  227 Entering Passive Mode (17,254,0,91,204,173)
The remote client would then attempt to connect to the routing device at 17.254.0.91:52397. The routing device in this example would then forward all traffic for this connection between the remote client and the internal FTP server at IP address 172.16.3.4.