I hope OP will forgive me for hijacking this thread.
I too have a client behind the firewall trying to connect to an FTP site. The session end is always noted as tcp-rst-from-client.
It's an IoT-thing, so I did a packet capture and see the device connect, log-in (plaintext password - ick!) and navigate to the desired directory, change to binary, attempt to get a file, after that fails, set passive and try to get the file again.
My capture shows the client request the get, and the server attempt to send, but the client never gets the packet.
I put my laptop in the client's spot and tried from my FTP client - same resuts. Each get times out.
apparently the PA220 is eating the reply packet, yet I can't find loggin to that effect.
Where do I look next?
not to discourage you, but aside from being unencrypted (as you pointed out), FTP is a super difficult protocol to deal with, especially with firewalls.
first, port 21 is only one of the ports FTP uses, which it calls the control port. the other port is either 20 or a randomized port, depending on whether you're in active or passive mode. if you're in active mode, it's 20, but the tcp session is established by the server, which means the firewall has to allow for 20 to come from the outside back in. if it's passive, the server chooses an open port on its side and the client needs to establish a brand new session to the randomized port.
bottom line, you generally want to use passive mode if it's available (it sounds like your client is automatically trying passive at some point, but it sounds like it's after the fact) and of course the firewall will have to be able to inspect the traffic to see which port to dynamically open for the client (which I don't believe PA should have any issue doing).
if all that's in play, there could be something else, but you'd definitely have to look at all the packet captures (rx/tx/dr) to get a more precise picture.
or migrate to sftp if you can. simple port 22 and encrypted.
It's not a decision I get to make - IoT means "I'll make this thing and decide how it woll communicate and you can take it or leave it" for the most part - sigh.
My laptop in the thing's spot can connect on the TCP/21 port and I can authenticate etc. It's only when I try to GET a file that the connection times out. Once the server stops trying to send and the client stops trying to GET, I have CLI back and can try GET again.
I've got the same behavior in the web browser. The client session starts helloing and negotiating then when TLS is engaged, I stop getting packets.
Is there a knob or switch set someplace which tells the PA to analyze the streams and I've got it set at 10 when it needs to be turned down to 2?
Sorry, missed the IoT bit.
but TLS? as in FTPS? you'd likely need SSL decryption enabled at that point so the PA can inspect the traffic to determine the port to allow if it is in passive mode.
I mean. do the traffic logs show anything beyond the activity on port 21? have you tried a policy to allow all traffic for the device's IP just to see if it works at all?
Sorry, I confused the thread there.
There are three processes which my IoT device preforms: NTP, FTP, HTTPS
NTP: get the time (obviously I suppose) - this works perfectly, UDP out, UDP in session times out, repeat
FTP: check for updates, download and install them automagically - the check works, the GET to pull down update fails
HTTPS: send telemetry to the cloud (the function we've installed the thingh to perform) - the client hello and key negotiation work fine, firewall stops passing as soon as encryption is engaged.
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!