[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FW1] Connection timeouts on Nokia IPxxx boxes

To: <[email protected]>
Subject: Re: [FW1] Connection timeouts on Nokia IPxxx boxes
From: "Daniel Morone" <[email protected]>
Date: Tue, 15 May 2001 14:47:30 -0400
Cc: <[email protected]>
Sender: [email protected]

Dave, 
We are having the same problem.   Did disabling flows work for you?

It doesn't seem like Nokia recommends disabling flows anymore - It looks like they removed the KB Resolution 5034
which recommended the disable flows solution. That is the one Jonathan Jackson quoted to you.  Nokia still has the instructions for turning off flows though - Resolution 4188 

Nokia only has the Resolution 3317 now - ALLOW_NON_SYN_RULEBASE_MATCH for the 'unknown established TCP/IP packet' error.  I'm trying that resolution now.  That's what PhoneBoy and Checkpoint support (skI1789) recommend.

If you haven't seen them - here's a couple links which seem to indicate that is a bug:
http://securityportal.com/topnews/weekly/checkpoint20010212.html
http://www.securityportal.com/list-archive/fw1/2001/Feb/0224.html

============================================================

Date: Wed, 11 Apr 2001 09:48:33 -0400
From: "Dave Dunaway (ncc0296)" <[email protected]>
Subject: Re: [FW1] Connection timeouts on Nokia IPxxx boxes.



> What config's do you have? IPSO version and FW version. 


I'm running IPSO 3.3 with flows enabled, and FW-1 4.1 SP3. 


> I found an article on Nokia's site yesterday relating to the problem you 
> describe and I've posted it below. It relates to the default 'FLOWS' 
> installation when you have IPSO3.3 and Checkpoint v4.1 sp2/3 specifically. I 
> haven't tested the resolution yet (will try today) and see what happends. 


Well, the Nokia resolution below refers to their being continuous traffic 
which in my case is not happening. We make connections through the Nokia's 
and then might let the connection have no traffic for 30mins or so. 


However, I will try to disable Flows and see if that helps the situation. 


> 
> Cheers, 
> 
> Jonathan Jackson 
> Network Security Analyst 
> AMP Group 
> 4 Broadgate, Liverpool St 
> London, EC2M 2PA 
> Tel (44)> [email protected] 
> 
> Nokia article..... 
> 
> Established TCP sessions are being disconnected after FW-1's TCP timeout 
> with the error - unknown established TCP packet. 
> This issue only appears to crop up when the following is true: 
> 
> 1. IPSO 3.3 
> 2. FireWall-1 4.1 SP2 or SP3 
> 3. Flows is enabled (it is by default) 
> 4. The connection in question has continuous traffic. 
> 
> Part of this problem comes from how FireWall-1 interacts with the Flows 
> feature. Flows moves the packets through the OS without involving 
> FireWall-1, so FireWall-1 doesn't "reset" the timer value for the entry in 
> the connections table. When the connection is about to expire, FireWall-1 
> queries IPSO to see how long it has been since it has seen a packet on the 
> connection. If there is traffic on the connection at the exact second that 
> FireWall-1 decides to try and "refresh" the connection table entry, the 
> entry and the corresponding flows get deleted. 
> 
> TCP sessions being dropped on IPSO 3.3 and FireWall-1 4.1 SP2/SP3 
> 
> Check Point FireWall-1, SecuRemote/Secure Client 
> for version: 4.1 SP3 And Before 
> 
> last update: 03/01/2001 06:34:56 
> Established TCP sessions are being disconnected after FW-1's TCP timeout with 
> the error - unknown established TCP packet. 
> SOLUTION 
> This issue only appears to crop up when the following is true: 
> 
> 1. IPSO 3.3 
> 2. FireWall-1 4.1 SP2 or SP3 
> 3. Flows is enabled (it is by default) 
> 4. The connection in question has continuous traffic. 
> 
> Part of this problem comes from how FireWall-1 interacts with the Flows feature. 
> Flows moves the packets through the 
> OS without involving FireWall-1, so FireWall-1 doesn't "reset" the timer value 
> for the entry in the connections table. 
> When the connection is about to expire, FireWall-1 queries IPSO to see how long 
> it has been since it has seen a packet 
> on the connection. If there is traffic on the connection at the exact second 
> that FireWall-1 decides to 
> try and "refresh" the connection table entry, the entry and the corresponding 
> flows get deleted. 
> 
> Nokia Customer Support has been able to reproduce this problem and has escalated 
> it to Check Point. 
> Updates to this issue will be placed here. In the meantime, you can work around 
> this problem by disabling 
> flows per Resolution 4188. 
> 
> Resolution 4188........ 
> 
> 
> Detailed Resolution View 
> 
> 
> 
> -------------------------------------------------------------------------------- 
> 
> 
> -------------------------------------------------------------------------------- 
> 
> Resolution 4188 
> How do I disable firewall flows in IPSO 3.3 and later? 
> 
> Check Point FireWall-1, Miscellaneous 
> for version: 4.1 SP2 And Later 
> 
> last update: 12/11/2000 15:47:03 
> Firewall Flows is designed to increase performance of FireWall-1 on the Nokia 
> Platform. 
> However, there may be reasons why you would want to disable it. 
> SOLUTION 
> To temporarily disable it, one can issue the command: 
> 
> ipsofwd slowpath 
> 
> This also clears the flows tables. To re-enable it, use the command: 
> 
> ipsofwd flowpath 
> 
> However, it may also be desirable to disable it permanently. This must be done 
> by modifying 
> $FWDIR/etc/rc/rc.fwload. Replace the "bolded" flowpath in the following section 
> with slowpath: 
> 
> ipsctl -n net:ip:forward:available_modes | grep -q -s flowpath 
> if ($status == 0) then 
> ipsctl -w net:ip:forward:switch_mode flowpath 
> else 
> echo "FireWall-1: You are attempting to start the FW on an incompatible OS - 
> exiting" >>& $LOGDIR/fw.log 
> exit 1 
> endif 
> 
> 
> You also need to modify $FWDIR/bin/fwstart. Replace the "bolded" flowpath in the 
> following section with slowpath: 
> 
> if ($ipso) then # enable flows, if available. 
> 
> Don't need check because it is already checked! ipsofwd flowpath 
> FireWall-1 must be re-started for this change to take effect. Once you have done 
> that, 
> you can not use the ipsofwd command to re-enable flows. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Dave Dunaway (ncc0296)" <[email protected]> on 10/04/2001 20:56:59 
> 
> To: [email protected] 
> cc: (bcc: Jonathan B Jackson(IT)/UK/AMP) 
> Subject: [FW1] Connection timeouts on Nokia IPxxx boxes. 
> 
> 
> 
> 
> I've noticed that my connections through Nokia boxes, when not 
> used in a while, tend to timeout and die. Is there anyway to 
> not have the boxes drop the connection? The box on which 
> the connection is made to does not have anything which 
> times the connection out. This even occurs when I'm 
> ssh'ed onto the firewall itself and haven't sent any 
> activity in a while. 
> 
> thanks. 
> 
> 
> -- 
> Dave Dunaway [[email protected]] 
> 




================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================
Follow-Ups:
- Re: [FW1] Connection timeouts on Nokia IPxxx boxes
  - From: "Dave Dunaway (ncc0296)" <[email protected]>
Prev by Date: [FW1] State Table
Next by Date: [FW1] Forcing UDP encapsulation on SecuRemote Clients
Prev by thread: RE: [FW1] State Table
Next by thread: Re: [FW1] Connection timeouts on Nokia IPxxx boxes
Index(es):
- Date
- Thread