Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
jakeeey
New Contributor

Client-RST on FortiGate Logs

Hi All,

 

Anyone encountered a TCP Client-Rst in the FortiGate Logs? We've been running replication job and monitored it with continuous ping and every time the job fails the same time the ping is going RTO and FortiGate logs it as Client-RST. (see screenshot).

 

Replication-ping-log.png

Appreciate if anyone can share workaround. Thanks

 

FortiGate 

5 REPLIES 5
knagaraju
Staff
Staff

Hello jakeey,'

As I understand, you are initiating TCP-based traffic and intermittently it is getting failed due to client-rst .
Also, you have enabled continuous ping, whenever a job fails from source to destination you are seeing request timeout message in the ping output.

 

Please share the below information
1.) May I know if you have enabled any security profiles in the firewall policy to which this traffic hits?
2.) May I know if the job has a large file size?
3.) May I know if you have enabled any traffic shaping policies on Fortigate?
4.) May I know if this traffic is from LAN to public(Internet) ?
5.) May I know if you have SDWAN enabled?
6.) May I know the total number of ISPs connected to Fortigate?
7.) May I know the fortios version of the fortigate?

Regards
Nagaraju.

jakeeey

Hi Nagaraju,

 

Based on the screenshot we already did a continuous ping during the replication job and it caused RTO same time the job failed.

here are the answers to your questions:

1.) May I know if you have enabled any security profiles in the firewall policy to which this traffic hits?

    Nothing yet as we are still monitoring this firewall policy
2.) May I know if the job has a large file size?

    not so sure but I can see maximum files it transmitted during one instance that it successfully did the replication job is around 120-130Mbpsent/3-4Gbps received.
3.) May I know if you have enabled any traffic shaping policies on Fortigate?

   not doing traffic shaping
4.) May I know if this traffic is from LAN to public(Internet) ?

   LAN to Site to site IPsec VPN
5.) May I know if you have SDWAN enabled?

     yes, the tunnel interface is associated/built using one of the SD-WAN member interface
6.) May I know the total number of ISPs connected to Fortigate?

    6 ISP links
7.) May I know the fortios version of the fortigate?

   7.4

 

Regards,

Jake

msanjaypadma
Staff
Staff

Hi @jakeeey ,

 

You can collect the  below debug  and sniffer logs  to understand where and why  packet is getting drop or it cause of FGT.

Putty1 : 
diag debug reset
diag debug flow show console enable
diag debug flow show function-name enable
diag debug flow show iprope enable
diag debug flow filter addr x.x.x.x <<< replace x.x.x.x with destination ip of the communication.
diag debug flow trace start 100000
diag debug enable

Putty2 :
diag sniffer packet any “host x.x.x.x” 6 0 a <<<<< replace x.x.x.x with destination ip of the communication.

After running the commands please initiate the traffic to destination  and once the access is blocked /disconnected.
Please stop the debug using below command

dia de reset

Putty3 : 

get sys status

get sys performance status
get router info routing detail <destination>
get router info routing detail <source>
get router info routing all

Thanks ,

Mayur Padma
sw2090
Honored Contributor

I keep seeing client-rst and ip connection errors too. This happen to me since the update to FortiOS 7.

Meanwhile I found there is an issue with using utm filters (or profile groups) and asic offloading. This causes exactly that behaviour on Sites that e.g. use http v2. If you disable asic offloading on that policy the sites work correctly.

I do have a call open with TAC on this but still we have not found a solution.

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
seshuganesh
Staff
Staff

Hi Team,

 

Are you observing reset packet at the same time when you are getting request timed out ?

Usually client reset is common, to understand this we need to follow tcp stream in capture:

Open firewall putty and enable logging:

diag sniffer packet any 'host <dst ip>' 6 0 a

 

Once you get reset packet you can use ctrl+c to stop the capture.

Please share this output to TAC ticket, they will analyse and update you

Labels
Top Kudoed Authors