One of my clients has recently started getting the above-mentioned error message in the FileZilla Client software (on Windows 7) when connecting to my FTP server (WS_FTP Server by Ipswitch). Before getting into what I've done for troubleshooting so far, here are a few points about this issue:
- This is the only one of my clients experiencing (or at least reporting) this issue, and I know there are other clients using the FileZilla Client software.
- I use the FileZilla Client software myself and am unable to reproduce the error connecting to the same server.
- This error has only recently started occurring (within the last couple of days). Before that, the user was able to connect to the same server without error.
- The WS_FTP Server logs show the user successfully connecting, but do not show any errors indicating any problems with that connection.
To resolve this issue, I've tried the following:
- Verified that the SSL certificate for my FTP server is still valid (it expires in approximately 10 months).
- Reviewed all of the settings regarding SSL/TLS in the WS_FTP Server configuration.
- Verified the connection settings in the user's FileZilla Client software by comparing them to the settings in my Site Manager.
- Following instructions from several posts on the FileZilla Forums, cleared the "cached certificates" by renaming the
%APPDATA%\FileZilla\trustedcerts.xml) and allowing the FileZilla Client software to recreate it.
- Updated the user's FileZilla Client software to the latest version.
I've cross-posted this information from the FileZilla Forums page, but because I'm aware the issue could potentially be the client software, something in the user's network or even something in my server, I wanted to widen the net a bit. At this point, I'm not sure what else to look at, and I'm hoping that someone can at least point me in the right direction. I'm leaning towards something on the user's network possibly causing the issue, but I want to try to get some evidence of that before I go "blaming" another IT Department. Any help you can provide would be greatly appreciated.
UPDATE: I connected in to my client's workstation and checked the items suggested by @Martin Prikryl in the comments. I found that the client is using a domain-controlled installation of Webroot SecureAnywhere® Business Endpoint Protection software. They are still unable to connect, so this time I copied the logging information from the main FileZilla Client window:
Status: Resolving address of ftp.company.com Status: Connecting to XX.XX.XX.86:21... Status: Connection established, waiting for welcome message... Status: Initializing TLS... Status: Verifying certificate... Status: TLS connection established. Status: Logged in Status: Retrieving directory listing... Status: Server sent passive reply with unroutable address. Using server address instead. Command: MLSD Response: 150 Transferring directory Error: Primary connection and data connection certificates don't match. Error: Transfer connection interrupted: ECONNABORTED - Connection aborted Response: 226 Transfer completed Error: Failed to retrieve directory listing
I've redacted the URLs in the images, but they all match up. Looking at the Fingerprint values and the details of the Certificate issuer block, however, there are obviously some discrepancies. I had the user temporarily disable their Webroot protection (someone from his IT Department was luckily there to help us), and tried again. Unfortunately, the same problem occurred, and when I checked the certificate again, it still showed the same discrepancies when compared against the one listed on my computer.
Their IT guy also tried the connection from a fresh install of the FileZilla Client software on another PC on the same network. That connection resulted in the same error. I suggested the possibility of configuring the FileZilla Client software on a laptop connected to another network (like a cell phone's WiFi hotspot) to see if the problem persists, but they haven't had the chance to do that yet.
Our SSL certificate IS a COMODO PositiveSSL certificate, so now I just need to determine what's causing his system/network to be picking the issuer up as Fortinet.
EDIT: On a whim, I set up a new connection in my FileZilla Client where I explicitly specified the IP address from the user's connection log I posted above, just to be sure there wasn't anything different about the way I was connecting. I didn't get any errors, and my Certificate details dialog shows the same thing as it did before (other than the host being listed as the IP address instead of the DNS name). Here is the log from my most recent session:
13:35:44 Status: Connecting to XX.XX.XX.86:21... 13:35:44 Status: Connection established, waiting for welcome message... 13:35:44 Status: Initializing TLS... 13:35:44 Status: Verifying certificate... 13:35:44 Status: TLS connection established. 13:35:45 Status: Logged in 13:35:45 Status: Retrieving directory listing...
UPDATE #2: I just got a call back from the client informing me that his IT Department found the cause of the issue and have made changes internally to get his connection working. Here's a summary:
Over a year ago, our company changed the IP address of our FTP server. At that time, we sent out an e-mail "blast" to all of our clients and partners notifying them of this change. Apparently, however, this client's IT Department didn't get that memo because they didn't recognize the IP address and didn't have appropriate rules in their firewall to allow that traffic.
The fact that it has been working for over a year without error still stumps me a bit, but as long as it's working now, I'm going to let it go (for now). I'll post a troubleshooting summary as an answer later, but I've got to get back to work.