FTP Inbound Decrypt Issues

[jsalmans]

Ok, I'm at my wit's end with TAC.. after 7 months of explaining the issues, collecting logs, and then starting over when a new agent takes the case, I'm hoping the community can help me.

I've had inbound decryption set up for our FTP server for some time.  We noticed an issue after updating to 10.0.8 (we're now on 10.1.5-h1 ) where people seemed to not be able to connect anymore.  After investigating, it appears that in Filezilla they are actually able to connect but it looks like they aren't because a TLS error occurs and the LIST command fails.  Right-clicking on the remote side and hitting Refresh several times will often eventually complete the directory listing.  This is with FTPS set to "Require explicit FTP over TLS" and with the Transfer Method set to Default (which I think may be Passive). This issue appears to be intermittent and sometimes it seems to connect fine.

Further investigation also showed the following:

• The TLS error mentioned above when the LIST command fails is "GnuTLS error -110:  The TLS connection was non-properly terminated." followed by "Server did not properly shut down TLS connection" followed by "The data connection could not be established: ECONNABORTED - Connection Aborted" and then followed by "Failed to retrieve the directory listing".  Decryption logs GUI shows "General TLS Protocol Error" when this happens.
• Error showing: "Server sent unsorted certificate chain in violation of the TLS specifications" at the start of each connection attempt
• Changing the Transfer Method to Active seems to make it more reliable as far as connecting without a TLS error and getting the directory listed automatically (it still complains about the certificate chain)
• Even with Active set, we then sometimes get a message indicating that the connection isn't secure because the server previously was detected as supporting TLS session resumption (I'm assuming this was either working before through the Palo and now it isn't or it's because when we've tested we've connected directly to the server which supports it)
• Trying another client, WinSCP also doesn't list the directory on Passive.. it works when changed to Active.  I have no idea if it is getting any errors/warnings as I haven't noticed if there is a log view in that software.
• Turning off the decryption rule resolves all of the issues.. the FTP connection is also a lot less verbose (in another words, when decryption is turned on there is a lot more chatting with commands/responses between the client and the firewall/server)

It looks like someone else has run into an issue like this before with Passive FTP and it was related to an issue with the content packs

https://live.paloaltonetworks.com/t5/general-topics/passive-ftp/td-p/11573

Anyone else having any issues or have any experience in what I can do to resolve this?

Thanks!

[Remo]

Hi @jsalmans 

What was the last version when it was working? How does the decryption profile and rule look like that you cobfigured? How did you prepare the certificate file that you used for the inbound decryption? According to the error message you placed the intermediate certificate authority file at the wrong location in the file. Are there any decryption errors in the log on the paloalto firewall? What did TAC do so far with troubleshooting and whar were the results?

I think this issue should be solvable but I need some more information and more details about the steps taken and current config.

[Will-78]

I'll let you know if I make progress, but here's some info about things I've done and my situation. If you ever found a resolution, please let me know too.

I've had a ticket open for over a month on that (IIS FTPeS on Windows Server 2022) over directory listing issues. I never have issues connecting or sending, receiving and deleting did work the one time I was able to get the directory listing to work. I've tried with all the data ports allowed in the security policy (makes no difference and shouldn't be necessary with decryption).

Normally with a PASV problem you won't even get the path. In this scenario you can change paths on the server, get the initial path and it claims it's successful, but it's the contents of the directory that don't list. It did properly list 1 time, out of 100+ tests (which is why I know it can delete and retrieve files).

Status: Retrieving directory listing of "/path"...
Status: Directory listing of "/path" successful

Important Note: Decryption profile must have the TLS max at 1.2, this cured my connection issues. Otherwise when set to max/1.3 I'd end up with TLS errors on connect.
Other note: After leaving the connection idle we also get GnuTLS error -110: The TLS connection was non-properly terminated. I tested with FTP implicit over SSL as well and had the same results (granted that makes sense since the directory listing part is the same for both)

PAN-OS version: 10.1.7
Setup includes a Windows NLB vIP but I've tested direct as well.
Tested with Filezilla client and WinSCP

[Will-78]

Additional info: No denies in the traffic logs, shows SSL decryption is occurring, and no decryption errors (works perfectly fine with decryption disabled)