Screen OS

Hello Folks. Need verification on session behavior when they expire.

I'm battling an issue with a vendor forwhich they establish stateless TCP connection to there server. What this really boils down to is that its stateless because they are orpfaned, the connection is never closed via the application.. When the application process additional information, it opens a new connection without using the one it already had established.. Thus 4-20 connections end up getting established in "ESTABLISHED" state on the server/client side. 

I mentioned to them the default session timeout of session at 30 minutes which they have become fixated on as the problem. Shame on me for mentioning that as I figured I could force a connection close which is not the case. What we see the problem is from our packet sniffer is that the server is not listening for that inbound connection for a set timeout period.. Then it opens and established another connection. Its causing signifficant delays in the application for a connection to be free.

So, there is a chance that these ESTABLISHED are not transmitting any information for which causes the session within ScreenOS to timeout. The question i have is that once the session expires and drops out of the picture, this does not drop the connection between client and server.. The next packet sent in either direction should just recreate the session, correct ?.. Nothing more, Nothing Less

Thanks All

The 30 minutes is idle time, so they can keep their session open indefinately as long as there is never a 30 minute pause with no activity at all.

Alternativiely the session will close if a FIN or RST bit is received from either the server or client.

You can set the service to never timeout for testing (though I wouldn't leave it like this as after a while your firewall may crash if the application never actually closes the sessions).

Once the session has been dropped, if the firewall receives more traffic it will need the full 3 way handshake again (assuming we're talking about TCP), so the session will not just be recreated automatically.

Sam.

JNCIS-FWV JNCIS-SSL JNCIS-SEC JNCIS-ER

Hi,

You can use "unset flow tcp-syn-bit-check" and  "unset flow tcp-syn-check" to override the default behaviour.

The firewall will not drop the packet arriving after the idle time has expired and will create a new session without performing the full 3 way handshake. The disadvantage of this solution is the reduced security. tcp-syn-check is a global firewall setting, not limited to a policy or a zone. 

Good programmed applications send regularly the keep-alive packets if persistent connections are required but the traffic is low/irregular. Perhaps you can find an alternative SW.

I totally agree about the correct way to code a tcp client server application.. Both responses hit on the tcp-syn-bit-check and I believe that is the solution in putting a workaround in for sub-par programming.

Thanks to both for the response..

I've been down that road of increasing the timeout and sent the number of session from 16K to 94K on a SSG-350 that can handle 128K sessions. You touched on the on the tcp-syn which I totally forgot about that setting in the firewall.

The information you provides was excellent and very helpful.. I do appreciate the reply.