I guess it all depends on how long you need your connections open for. If oyu have connections open for days or weeks, you will still run into a memory issue if you have too many FTP's open. Something would have to be freed up from memory. If you only need connections open on the order of hours, then, yes, that will probably work as well.
> Interesting idea, however I think I found a more suitable solution. I am able > to increase the timeout for the FTP control session selectively by modifying > the init.def file on the management station: > > /* > * Set timeouts for tcp services > * > * In order to change the tcp session timeout for specific services, add a line > * "ADD_TCP_TIMEOUT(port,timeout)," before the line "ADD_TCP_TIMEOUT(0,0)" > * where port is the TCP service port and timeout is the desired timeout. > */ > > #ifndef FTP_CONTROL_TIMEOUT > #define FTP_CONTROL_TIMEOUT TCP_TIMEOUT > #endif > > #define ADD_TCP_TIMEOUT(port,to) (record <port;to> in tcp_timeouts) > > ( > <0> in tcp_timeouts > ) or ( > ADD_TCP_TIMEOUT(21,FTP_CONTROL_TIMEOUT), > ADD_TCP_TIMEOUT(0,0) > ); > > > #endif /* __init_def__ */ > > by replacing the TCP_TIMEOUT variable in the 9th line of this section you can > set the FTP control session timeout. > > Jim Previti > > > > > [EMAIL PROTECTED] > 05/17/2002 10:42 AM > > To: James J. Previti/Telecom/Philadelphia/Fiserv@Fiserv > cc: [EMAIL PROTECTED]@FiservMail > Subject: Re: FTP control session timeout > > > Well, that's the thing. The reason your session is getting flushed is > because it has been inactive for a long period of time. Unfortunately it > would require infinite memory to keep track of all open states (a state that > hasn't gone through FIN/FIN-ACK to close) so the firewall needs to flush > states that are getting stale so that memory doesn't run out. > > So what is happening is your state is being flushed as it has been idle for > so long. What the below command does is watch for sessions that look like > they are established (ie, SYN bit not set) and then compare that packet to > the rulebase. If it matches a rule in the rulebase, it allows the packet > through, and re-enters it into the state table. Unfortunately, you lost all > the state information when you flushed it the first time, so the sequence > number may be wrong, but the firewall won't know. So it is a bit of a > security risk but the firewall can emulate having an infinite number of > sessions open. > > > What happens to the state table when you do this? > > > >I haven't visited this list in a while so I apologize if this is old news. > > >We have a problem with FTP control sessions timing out of the state table > > >before the data session has ended. > > > > In fwui_head.def, add/uncomment the line: > > > > #define ALLOW_NON_SYN_RULEBASE_MATCH > > > > That will allow sessions to stay open "indefinitely". > > > > > ================================================= To set vacation, Out Of Office, or away messages, send an email to [EMAIL PROTECTED] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [EMAIL PROTECTED] =================================================
