why drop rst packet

[Felixcao]

The customer is capturing packets on the firewall.

Check the files in the receive stage and find that the firewall has dropped the rst message sent by the client in the session.

Please refer to the screenshot for the file reference. Can someone tell me why the pa-firewall dropped this rst packet

[aleksandar.astardzhiev]

Hi @Felixcao ,

Check the global counters. The following link explain how to sue packet capture filter for the global counters - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CloNCAS

Once you follow the steps from the link, what is the output?

[Felixcao]

[2023/11/24 11:21:39] admin01@5260-02(active-secondary)> show counter global filter packet-filter yes delta yes
[2023/11/24 11:21:39]
[2023/11/24 11:21:39] Global counters:
[2023/11/24 11:21:39] Elapsed time since last sampling: 3.448 seconds
[2023/11/24 11:21:39]
[2023/11/24 11:21:39] --------------------------------------------------------------------------------
[2023/11/24 11:21:39] Total counters shown: 0
[2023/11/24 11:21:39] --------------------------------------------------------------------------------
[2023/11/24 11:21:39]
[2023/11/24 11:22:03] admin01@5260-02(active-secondary)> show counter global filter packet-filter yes delta yes
[2023/11/24 11:22:03]
[2023/11/24 11:22:03] Global counters:
[2023/11/24 11:22:03] Elapsed time since last sampling: 0.127 seconds
[2023/11/24 11:22:03]
[2023/11/24 11:22:03] --------------------------------------------------------------------------------
[2023/11/24 11:22:03] Total counters shown: 0
[2023/11/24 11:22:03] --------------------------------------------------------------------------------
[2023/11/24 11:22:03]
[2023/11/24 11:22:09] admin01@5260-02(active-secondary)> show counter global filter packet-filter yes delta yes
[2023/11/24 11:22:09]
[2023/11/24 11:22:09] Global counters:
[2023/11/24 11:22:09] Elapsed time since last sampling: 1.924 seconds

no any counter global output.

[aleksandar.astardzhiev]

Hi @Felixcao ,

The command will return only information in real-time (no historical data). Which means you need to setup the capture and reproduce the issue by generating traffic that is matching your filters.

The lack of any counters means that there is no session that is currently passing over the firewall that is matching your filter.

It looks like you are running active-active, so either the traffic is not matching your filter, or you are capturing on the wrong firewall, or just there is no traffic

[Felixcao]

Hi, Aleksandar:

Thank you very much for your enthusiastic reply.

The lack of any counters means that there is no session that is currently passing over the firewall that is matching your filter.
--------There should be no problem. After turning off the packet capture stop filtering condition, output a count of global traffic

It looks like you are running active-active, so either the traffic is not matching your filter, or you are capturing on the wrong firewall, or just there is no traffic

--------Yes, actvie active mode. The customer confirmed that the operation was done on the correct wall

[Felixcao]

From counter global output, suspect root cause is tcp_drop_out_of_wnd  ?

[2023/11/27 18:21:33] admin01@5260-02(active-secondary)> show counter global filter packet-filter yes delta yes
[2023/11/27 18:21:34]
[2023/11/27 18:21:34] Global counters:
[2023/11/27 18:21:34] Elapsed time since last sampling: 0.744 seconds
[2023/11/27 18:21:34]
[2023/11/27 18:21:34] name value rate severity category aspect description
[2023/11/27 18:21:34] --------------------------------------------------------------------------------
[2023/11/27 18:21:34] pkt_outstanding 13 17 info packet pktproc Outstanding packet to be transmitted
[2023/11/27 18:21:34] pkt_alloc 14 18 info packet resource Packets allocated
[2023/11/27 18:21:34] session_allocated 1 1 info session resource Sessions allocated
[2023/11/27 18:21:34] session_installed 1 1 info session resource Sessions installed
[2023/11/27 18:21:34] flow_np_pkt_xmt 10 13 info flow offload Packets transmitted to offload processor
[2023/11/27 18:21:34] flow_host_pkt_xmt 10 13 info flow mgmt Packets transmitted to control plane
[2023/11/27 18:21:34] flow_host_vardata_rate_limit_ok 10 13 info flow mgmt Host vardata not sent: rate limit ok
[2023/11/27 18:21:34] flow_fpga_rcv_fastpath 2 2 info flow offload fpga packets for fastpath received
[2023/11/27 18:21:34] flow_fpp_sess_bind_notify 1 1 info flow offload Sess bind notification to FPP
[2023/11/27 18:21:34] appid_override 1 1 info appid pktproc Application identified by override rule
[2023/11/27 18:21:34] tcp_drop_out_of_wnd 1 1 warn tcp resource out-of-window packets dropped
[2023/11/27 18:21:34] ha_msg_sent 3 4 info ha system HA: messages sent
[2023/11/27 18:21:34] ha_session_setup_msg_sent 1 1 info ha pktproc HA: session setup messages sent
[2023/11/27 18:21:34] ha_session_update_msg_sent 1 1 info ha pktproc HA: session update messages sent
[2023/11/27 18:21:35] ha_aa_session_setup_msg_sent 1 1 info ha pktproc HA: A/A session setup messages sent
[2023/11/27 18:21:35] ha_aa_session_setup_local 1 1 info ha aa Active/Active: setup session on local device
[2023/11/27 18:21:35] --------------------------------------------------------------------------------
[2023/11/27 18:21:35] Total counters shown: 16

[Felixcao]

After discussing the business model with the customer, it is believed that the reason for the Firewall to discard RST messages is Challenge ACK。

Refer to this kb：https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boBJCAY。

>configure
              #set deviceconfig setting tcp allow-challenge-ack yes
              #commit
              #exit
              >

However, the customer has a question, what are the risks to the firewall when executing this cli？

how to respone this question ？

[jamessciortino]

Did this fix the issue? The article you provided is for RSTs when the sequence ID is different. Your sequence ID's are the same.