[
https://issues.apache.org/jira/browse/NET-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700795#comment-17700795
]
Stefan Kuhr commented on NET-719:
---------------------------------
I am not a WAF expert. My interest is a reliable data exchange. Because a
FileZilla client was working without any issues, the WAF admin group pointed
the finger at our client, which basically is the FTPSClient.
As far as I understand it, the WAF is doing active protocol inspection, i.e. in
this case it blocks the return on the control-channel until the data-channel is
completely setup. This is how FileZilla behaves.
I had the opportunity to analyze the timing issues on a live customer setup
(from the outside) and was able to resolve the timeout issues we had by
adjusting the the various FTPS exchanges as shown in the solution diagram.
For me it only make sense to provide a pull request, if I can provide a test,
so I am currently looking into that.
> FTPS timing issues behind WAF (F5) firewall
> -------------------------------------------
>
> Key: NET-719
> URL: https://issues.apache.org/jira/browse/NET-719
> Project: Commons Net
> Issue Type: Improvement
> Components: FTP
> Affects Versions: 3.9.0
> Reporter: Stefan Kuhr
> Priority: Major
> Attachments: FTPSClient_RETR_Timing_diagram_current_impl-1.png,
> FTPSClient_RETR_Timing_diagram_problem.png,
> FTPSClient_RETR_Timing_diagram_solution.png
>
>
> A working data exchange setup stopped working, after the server (vsftpd /
> RedHat) was moved behind a WAF (F5) web application firewall. The client uses
> PASV mode and the operation resulted in a socket timeout on the client side,
> as soon as the data channel came into play (LIST/RETR/STOR).
> A FileZilla client does not exhibit this problem. By looking at the protocol
> exchanges and laying them down in timing diagrams the problem seems to be,
> that the WAF expects the client to fully establish the data-channel, after
> the data-command is send over the control-channel. The current FTPS client on
> the other hand expects the server reply directly after the command is sent.
> A pull request will be provided.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
