Strange Timeout issue in Checkpoint

[munit_si@yahoo.com]

We have default tcp timeout set on Checkpoint firewall to 1 hr. Now problem which we are facing is that our connection after 1 hr of inactivity still persist (hanging login sessions still there) between the client and pc(example our ssh sessions)

we are using NG55 AI W

my question is


1) When idle timeout is reached for tcp , is the connection removed from the connection table only or is reset also issued to the client and server

2) any idea how to avoid this issue


any help is highly appreciated

[northlandboy]

No reset is sent. The connection is removed from the connection table, and the next packet that comes along will be marked as out of state, and dropped. Generally you don't want to send rejects for out of state traffic.

Try changing the tcp_keepalive_interval on your server to less than an hour, if you want those connections to stay alive.

[munit_si@yahoo.com]

Thanks a lot. But what does the below article means from checkpoint. It says that reset is being issued now as per the fix.


snippets below from the checkpoint site


Symptoms

* Application needs to receive a reset (RST) or FIN from the Security gateway after 3 minutes of inactivity indicating connection timeout.

Solution
VPN-1/FireWall-1 records all TCP connections with a certain timeout. Default timeout is one hour. When timeout is reached, connection is deleted from connections table. Certain applications, where connections stay idle for a time, then communication is resumed, need reset (RST) packets sent to client and server upon connection timeout. These packets prompt client and server to return ACK packets with correct sequences. VPN-1/FireWall-1 then generates RST packets based on returned sequences.

This problem was fixed. The fix is included in the following release(s): VPN-1/FireWall-1 NG with AI R55 HFA R55_02.

Check Point recommends to always upgrade to a recent version, and to the most recent HFA (HotFix Accumulator) of this version

[munit_si@yahoo.com]

Also, is thier a way we can make it to send reset if required by the application on the server side to avoid this issue ?


I am using the NG55 AI w in my enviornment.




Thanks
Munit

[northlandboy]

Set tcp_keepalive_interval to less than an hour on your server.

And look into the fw_rst_expired_conn parameter. It may do what you want, but have a think about what you're doing.

You will note from the SK you looked up that articles in Check Point's KB are not always complete, or necessarily even accurate. Sometimes they're only really suited to internal use - you particularly notice this with the higher levels of access.

[munit_si@yahoo.com]

Thanks a lot.

Regards
Munit

[munit_si@yahoo.com]

Originally Posted by northlandboy

Set tcp_keepalive_interval to less than an hour on your server.

And look into the fw_rst_expired_conn parameter. It may do what you want, but have a think about what you're doing.

You will note from the SK you looked up that articles in Check Point's KB are not always complete, or necessarily even accurate. Sometimes they're only really suited to internal use - you particularly notice this with the higher levels of access.

Hi,

Thanks a lot for all ur help.

What is the more preffered way(recommended) setting up the fw_rst_expired_conn parameter or settings up the tcp_keepalive_interval on the server ? Reason why I am asking is as I have to decide atleast one of these solutions.

Regards
Munit

[northlandboy]

Depends what you want to do. I would change the server, or possibly increase the service timeout in CP. I've seen very little documentation for that other parameter, so I personally would be wary of it.

But I know nothing about your network, or your site policies. I have no idea if you can even change that parameter on your server, as I don't know what OS you are using. I don't know how the politics work at your site, or what is possible.

You will need to look at each of the three potential solutions, and make a decision based on what is best for your site. Try and understand the implications of each of the potential fixes first.