Question:

Why is the FTP Data Connection Failing?

Answer:

Data Connections are created whenever the client lists a directory (MLSD or LIST), or transfers a file (STOR or RETR). There are a couple of different issues and possible solutions.

Switching to vlt-<PODID>-ftp.veevavault.com for the host name can also solve this issue if the client is having trouble completing the normal PASV command sequence shown below: 

<PODID> in this example is just the number after the prefix on the POD, so for VV2-28 the user would enter vlt-28-ftp.veevavault.com. This same workaround is also a solution to the case that Enhanced Passive EPSV is being used. A response like 229 Extended Passive mode OK (|||56030|), is an indication of this mode, which is not compatible with Veeva's server.

Being part of the Azure Cloud Firewall which uses a pool of IP addresses can cause an issue when passive FTP mode in used. If the source address of the data connection does not match that of the control connection the server will receive the connection and then drop it without logging.

Azure cloud has an IP address pool, and sometimes uses a different address for the control and data connections. This issue could be present in other Firewall applications used by customer as well. Veeva's server is not compatible with this and the user must switch off the firewall to avoid this problem. The firewall must also have open outbound connections to port range 56000-56100 on the FTP server. 

If an issue is being encountered while using a Python client or similar integration, such as the Python library: "ftplib", considerations need to be accounted for when the library being used does not support the control and data connections coming from different IP addresses. A workaround for this example is to set an attribute called "trust_server_pasv_ipv4_address" to "True". Other libraries and applications may have a similar issue and required solution, or may default to trusting the PASV response.