Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
tlloyd22
Employee
Employee
Jump to solution

First packet isn't syn

Hey everyone.  I have a new CPGW R81.10 and I have one workstation that's dropping traffic 3 to 4 times a second with the following issue:

TCP packet out of state: First packet isn't SYN

TCP Flags: RST-ACK and FIN-PUSH-ACK

Can this be ignored?  I can't say I'm seeing a perf problem.  Or, should/how can it be fixed?  Thanks all!

 

 

0 Kudos
36 Replies
Jonne_Hannon
Contributor

It looks like the SecureXL connection still has the correct TCP session timeout, but for some reason the firewall connection timeout gets reduced to 15 seconds:

10.122.21.80 52570 172.28.32.21 80 6 ...A..S............. Destination FIN 3/24 24/3 2 0 3202928558/1670317441 0 32 13.07KB 1s 2m2s 3599/3600


<00000000, 0a7a1550, 0000cd5a, ac1c2015, 00000050, 00000006; 0001e001, 40044080, 00000039, 000001cf, 00000000, 639030bc, 00000005, 9db24937, f54cc138, 00000003, ffffffff, ffffffff, ffffffff,
0000e800, 00000000, 80000000, 00000000, 00000000, b9155808, 00007f8e, 00000000, c2053003, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000; 14/15>

0 Kudos
Timothy_Hall
Legend Legend
Legend

Is your TCP start timeout 10 seconds?  SecureXL adds 5 seconds to it upon receipt of FIN which would explain where the 15 is coming from, see: sk110672: When a TCP connection ends, its entry in the Connections Table appears with a timeout valu...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Jonne_Hannon
Contributor

Thanks for the suggestion.  TCP start timeout is 25 seconds, which I believe is default.  TCP end timeout (R80.20 and higher Gateways) should apply to R81.10, which is 5 seconds.  The connection state is 0001e001 (Destination FIN) with a 15 second end timeout timer.  Under advice from TAC, I have upgraded to JHFA Take 79, but the issue persists after the upgrade.  Disabling SecureXL resolves the issue, but is obviously not a permanent solution.

0 Kudos
Dion-ben
Explorer

Checkpoint has identified this as a problem with a timeout on half closed TCP sessions e.g. one side has send a FIN but the other has not responded with a FIN yet and has a Hotfix in sk180364 

Jonne_Hannon
Contributor

Thanks.  You might have just saved me collecting SecureXL debugs for TAC.  I'll let my Case Engineer know and try the hotfix.

0 Kudos
Jonne_Hannon
Contributor

the workaround in sk180364 does the job as well.  Not sure if I need the hotfix, but will check with TAC.

0 Kudos
Jonne_Hannon
Contributor

I noticed that sk137672 has been updated with added information:
"...Some of the Half closed connections ( DST-FIN ) by default will have 15 seconds timeout starting from the versions mentioned above...."

Looks like this is now considered normal behaviour from the versions listed in the SK article.  What is the rationale behind expiring the half-closed connections so quickly? 

I have been testing the hotfix from sk180364, but I still see the 15 second timeout on DST-FIN firewall connections and out of state packet drops.  I noticed during troubleshooting that there was no fwaccel DST-FIN connection, so maybe the hotfix only removes the DST-FIN connection from the SecureXL connection table.  

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events