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

Increasment of "out of state packet"

Hello,

 

 I received from our SOC a report that the "out of state packets" have been increased (skyrocketed) since 23th of October. We still had some of them out of state packets by the past and that makes sense for me... 

On the November month, we got like arround 15 millions of dropped packets and most of them related to "out of state packet" (on September month, arround 2-3 millions dropped packets).

The flow generating this "out of state packet" is the following, a flow back from our proxy to an user : 

source-port : 80 - destination-port : dynamic / src-ip : Proxy-IP (Blue-Coat) dst-ip : random_user (not related to a specific user)

I checked on Checkpoint side if something have been enabled or disabled before 23th of October (global properties > Statefull inspection > out of state & also checking the aggressive aging on http service that have been still enable).

 

But I'm not able to explain, why an increasment like that (x6-7 of out of state packets and related to the same kind of flow)... 

May be it's more related to our Blue-Coat proxy, I tried to check if some parameters have been modified (hard to get audit from more 1 month...).

Just in case that you can provide me some news ideas about this topic 😉

Thanks for your support !

 

Regards,


Robin.

1 Solution

Accepted Solutions
HeikoAnkenbrand
Champion Champion
Champion

Hi @rdegoix,

I work a lot with Symantec SGs. That sounds a lot like asymmetric routing.

The following typical SG issues:
1) If you use two interfaces on the SG (internal and external), then asymmetric routing could be the issue ( @PhoneBoy mentioned this)
2) If you use the (default) bridge mode interface on the SG as explicit proxy interface, there are many side effects on the SG vs in the network. 
3) This can also be timer settings on the check point in the http/https protocol, for example "aggresiv agging" thus the tcp connection is terminated after 600 seconds instead of 3600 seconds. Now there is no session table entry on the gateway, for an existing connection on the SG or a web-server in the internet. Solution, disable "aggresiv agging".

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips

View solution in original post

4 Replies
PhoneBoy
Admin
Admin
This could easily be the result of asymmetric routing occurring within your environment.
It could also be the proxy server taking too long to respond to a TCP SYN packet as well.
rdegoix
Participant
@PhoneBoy
Appreciate your feedback 😉

I was expecting something like that but it's hard to demonstrate, as there is not really user experience issue with proxy, it's only about out of state packet when flow come back from Internet to Proxy and then Proxy to user... (as you said, proxy server taking too long to respond to a TCP SYN packet is one of my best argument, but I need to demonstrate it 😛 And health signals from my Proxy looks like OK, not overloaded at CPU, RAM , session level)

0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

Hi @rdegoix,

I work a lot with Symantec SGs. That sounds a lot like asymmetric routing.

The following typical SG issues:
1) If you use two interfaces on the SG (internal and external), then asymmetric routing could be the issue ( @PhoneBoy mentioned this)
2) If you use the (default) bridge mode interface on the SG as explicit proxy interface, there are many side effects on the SG vs in the network. 
3) This can also be timer settings on the check point in the http/https protocol, for example "aggresiv agging" thus the tcp connection is terminated after 600 seconds instead of 3600 seconds. Now there is no session table entry on the gateway, for an existing connection on the SG or a web-server in the internet. Solution, disable "aggresiv agging".

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
rdegoix
Participant

@HeikoAnkenbrand 

Hey, 

appreciate your feedback and experience on this, I will focus on this and try to demonstrate it 😉

About aging, I already check audit log on checkpoint and we didn't make any change before 23th of October (already configured with an aggresive aging long time ago... ).

I have more confidence in a guilty SG Proxy 😉

Best regards,

 

Robin.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events