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.
Do you have any security profiles applied for the policies? Anything in the threat logs? Temptrip HTTPS policy service tab got only service port name changed l guess (is it still 443). Your policies can be combined into a single (1) rule. Did you test with application and services as any, without the security profiles (if any) or even to bypass the Palo?
I got my SE on the case and while studying packet-captures it suddenly seemed like the communication was great until the packets got big. We wondered if it could be an MTU problem.
I put a laptop in the PA220's place and ran through the connections at MTU 1500 - AOK.
Put the laptop in the client's place and had to drop down to 1400 to get the transfers to go.
We couldn't find anywhere in the PA220 where MTU was set below default (1500?) but when we turned on jumbo-frames and set the GlobalMTU at jumbo-default, and rebooted, all flows pass properly.
Yay, but really?!
i'll eat my crow now...
Bad cable/ethernet jack on upstream router. All successful connections correlate with events where a coworker was forcing the lab traffic over a different link. His timing just made my troubleshooting harder.
Layer 1 sure gets in the way when you're think 4 through 7.
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!