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:
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
Anyone else having any issues or have any experience in what I can do to resolve this?
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.
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
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!