The logic that Checkpoint has in the tcp timeout feature is correct from a security standpoint.
If the user is not using the tcp connection for an extended period of time, in this case a max of
2hours, drop the connection from the state table.

Unfortunately, in the real world, we have these people that insist on logging on once in the morning and
leaving the application idle until they need to access the application. At times this could be up to ten hours.
And they have large mouths and they scream and yell when they have their sessions dropped. So I have to find
another solution.

As for our collegue who previously posted, he has some programmers that need to have their sessions idle for a
considerable amount of time.

The Nortel Contivity switch, although a little pricey, solves some problems for me. One of them being this time out issue.
The other is that of redundacny. I work in education and my boss does not have enough money to buy another Checkpoint
Firewall for load balancing and redundancy.

Hope this clarifies some my thought.

merlin
 

Robert MacDonald wrote:

Barry,

Figuring that CP is in the security related field,
it's probably for security reasons. Why should
a connection be left open, if nothing is going on?

Robert

>>> "Barry W. Kokotailo" <[EMAIL PROTECTED]> 8/17/00 1:33:41 PM >>>
>Well that is a good point. According to my working on the problem, there
>is a paramater called tcp keepalive. Unfortunately it has to be built within the
>client
>application. Noticed some threads about and Microsoft has some definitions in
>his Knowledge Base.
>
>The thing that is interesting is why Checkpoint limits the tcp idle time to 7200
>seconds.
>Any suggestions from the group?
>
>merlin
>
>Robert MacDonald wrote:
>
>> This seems awful expensive. Why spend big
>> $$(again) for a problem that can be fixed by
>> having the programmers fix the programs that
>> are running. Anything from a simple NOHUP
>> to actually spending 15 minutes to correct
>> the program to send all output to a file, email
>> or printer for analysis.
>>
>> Heck, why not just cron a ping or something.
>>
>> Robert
>>
>> - -
>> Robert P. MacDonald, Network Engineer
>> e-Business Infrastructure
>> G o r d o n   F o o d    S e r v i c e
>> Voice: +1.616.261.7987 email: [EMAIL PROTECTED]
>>
>> >>> "Barry W. Kokotailo" <[EMAIL PROTECTED]> 8/16/00 7:27:46 PM >>>
>> >I have come across this same situation. As far as my experience, research, and
>> >asking of this group
>> >is concerned, the answer is "no".
>> >
>> >My suggestion would be to look into Nortel Extranet Contivity Switch products.
>> >Features:
>> >
>> >IPsec
>> >PPTP
>> >Time outs of 23 hours 59 minutes.
>> >Ability of users to change their own passphrases.
>> >Password aging.
>> >Authentication:
>> >        User base
>> >                Using pass phrases of at least 16 chars.
>> >        Radius
>> >        Entrust Certificates
>> >        Ldap
>> >
>> >Secure Remote as a product is a nice freebie from Checkpoint, but it has some
>> >severe limitations,  one of them
>> >being this tcp time out issue.
>> >
>> >Hope this helps.
>> >
>> >merlin
>> >
>> >Doug Schmidt wrote:
>> >
>> >> Hi,
>> >> I have called CP Support and also searched the Phonyboy FAQ's, but nothing.
>> >> CP Support told me to increase the TCP Session Timeout. Which has a max
>> >> setting of 6500 seconds ( ~2 hours) which is not long enough for our needs.
>> >>
>> >> We have our user LAN behind the FW. Some of our developers on this LAN, need
>> >> to have telnet/ssh connections
>> >> to some servers (outside the FW), While these connections are open, they run
>> >> some jobs, which can last anywhere
>> >> from minutes to many hours. In the case of a job lasting say 4-5 hours, this
>> >> would not be long enough, since the FW
>> >> will drop the TCP Session when it is not active.
>> >>
>> >> Is/are there any workarounds fixes to this problem? Any advise would be
>> >> great.
>> >>
>> >> Firewall Version 4.1 Build 41489 running on Slowaris 2.7
>> >>
>> >> ~D

-- 
Barry W. Kokotailo
Senior Unix Systems Administrator
1-780-675-6399
PGP =  71 71 96 A3 C0 C2 23 7A  23 4E D4 04 8C E0 42 6B  B0 2D D1 A5
 


Reply via email to