Peculiar issue with PI FTP Adapter (ftp 425 failed to establish connection)
We use PI heavily in our landscape as middleware for connecting our SAP systems to external parties, one of our third party required us to make a secured FTP connection to transfer files from SAP Application server to their publicly listed (exposed on internet) FTP servers. As you can imagine, setting up interfaces through corporate firewalls can be a pain, we managed to setup this connection, get all the firewall rules sorted, tested with a secure FTP program and were able to connect from our network through the firewalls and transfer files securely over the internet.
The next step would be to setup our PI FTP adapter to transfer files through the same secure tunnel. We set it up using the following link: Configuring the Receiver FTP Adapter
The Adapter was configured to use FTPS connection, hence certificates were exchanged accordingly with the third-party, root and intermediate public root certificates were added to TrustedCAs keystore view, however transfer tests failed with the error: ftp 425 failed to establish connection a search on SCN results in nothing that particularly describes the issue and its potential resolution, besides a single thread where a user explains that you need to ask the firewall team to resolve this issue.
However, I was determined to understand why this issue occurs and how it can be prevented/resolved. A bit of research on internet and reading the FTP Specification RFC4217 explains the problem and provides the options to prevent/resolve it.
A typical FTPS works in the following way:
The protocol mandates that FTP client initiates two connections with the FTP Server.
1. Control Connection – For exchange of authentication
2. Data Connection – For transfer of files, this connection can be done in two modes, Active mode or passive mode
A simplified view of Active Mode is depicted in the following diagram
a) FTP Client initiates Control Connection
b) On acceptance, FTP Client initiates Port command with port number
c) FTP Server Acknowledges the port number and initiates a connection on the same.
d) FTP Client acknowledges and initiates Data Transfer as necessary
A simplified view of Passive Mode is depicted in the following diagram
a) FTP Client initiates Control Connection
b) On acceptance, FTP Client initiates PASV command
c) On acceptance of PASV mode, the Server responds back with IP Address/Port number combination that it will also listen to
d) FTP Client has a choice, it can initiate a socket on original IP address used for Control Connection or the new IP sent by FTP server, the port number would be the one returned by FTP server in step c, (some FTP clients like FILEZILLA and LFTP have flags/settings to override the new IP and use the original IP, however SAP PI Adapter seems to be using the new IP)
e) FTP Client initiates Data Transfer
(A very detailed explanation is provided about Active & Passive modes is provided here )
3. The FTP 425 issue occurs when PI Adapter attempts to initiate a Data connection in passive mode, as the PI Adapter attempts to initiate Data connection on the IP address port numbers provided by FTP server in response to PASV command.
Resolution – There are couple of possibilities
Solution #1 – Fix the FTP server – there is a setting on FTP server that ensures that FTP server returns the correct IP address as a response to PASV command from FTP client. We asked our third party supplier to fix this setting and they did the needful, so we din’t have to go implement the alternative.
Solution #2 – Allow PI Adapter to Use the new IP provided by FTP Server – This potential solution was researched by a member in the SAP Netweaver Application Server space, he recommends applying a SAP Note 1591971 , after implementing the note you get a new parameter (in older versions of PI ) strictHostnameChecking which allows you to force PI to skip validation check and allow the data connection to be initiated, this solution is documented in the forum post .
Note: Solution #2 does not work if the FTP Server sends a garbage IP address which some implementation of FTP Servers do, as that IP won’t exist and PI adapter will attempt to connect on this garbage IP and fail, this was our issue, our data connection failed all the time since our third party FTP Servers were dishing out garbage IP addresses to PASV responses.