TCP-RST-FROM-CLIENT

[AhDon79]

Hi,

I have allowed a FTP session. However, the FTP session does not connect. When I search the logs, the traffic is allow however the session end reason is tcp-rst-from-client.

Please advice.

Thks and Rgds

[TranceforLife]

Hi,

Is it just a one client or others as well. Had a similar issue. Try to user different FTP software from the client side. Logs suggests the same as Palo received a reset from the client, Give a go

Thx,

Myky

[AhDon79]

Hi Trance,

I will give it a try.

Thks and Rgds

[MatthewSabin]

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?

[TranceforLife]

Eating the packets! Haha.  Hungry PA :0 What can you see from the PCAP on Palo and server side? Get the PCAP on all stages from the Palo (use the filter based on source and destination ).

p.s What PAN-OS you are on?

[bradk14]

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.

[MatthewSabin]

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?

[bradk14]

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?

[MatthewSabin]

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.

[bradk14]

I think it may make sense to share your defined policies for this case. also are you performing ssl decryption at all for the https connection?

[MatthewSabin]

Is there a better way than a screen shot?

Here's the ruleset I have, only NetAdmin and NTP work at this time.

[TranceforLife]

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?

[MatthewSabin]

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?!

[MatthewSabin]

i'll eat my crow now...

Problem solved:

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.

[raghavendra.badiger]

Hi All,

I am using PA-850, where copying files from internet or other sites via PAN has slowed down very much.

On Monitor logs, it shows TCP-RST-FROM-CLIENT. And when I do PCAP on those packets I see TCP getting retransmitted.

Any help would be great here. Thanks.

Regards,

Raghav