NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FW1] TCP session timeout whoa's!



Hi,

I ve got the same behavior with VRRP monitored circuit.
A lot of packets are droped on the slave and somtime the slave take over the master for any reason I do not understand.
What is strange is that the synchronization of the state table is installed on oth of the firewall in the cluster.
So the session sould not be dropped ....

The action I plan to do is to install the synchronization on an interface dedicated for that job and use an crossover cable between the firewall in the cluster.
But concerning the vrrp hello It always use the interfaces on wich it is installed (internal and external for example).
I do not Know what kind of bandwith is necessary for this kind traffic ???
I do neither know the amount of memory needed to use vrrp on two stressed interfaces...????

Concerning the Nokia resolution to disable the TCP time out session it is : 3317

Guillaume.

If anyone of you configured the VRRRP monitored circuit, please be free to explain how and which solutions resolve wich problems.

Thanks.
 

Jay Clukey a écrit :

To all:     I have just recently upgraded our two Nokia IP650 FW's running in a VRRP monitored circuit environment to IPSO 3.3 with FW-1 4.1SP2 and I am seeing a LOT of Unknown established TCP connections being dropped by rule 0 in the logs.     I have determined that this is indeed due to the nature as to how 4.1SP2 and beyond now handle TCP session timeouts. In 4.1SP1? and prior versions of CheckPoint if a TCP session exceeded the TCP session timeout set in the FW properties the FW would first attempt to re-establish the connection and if it could not it would then drop the connection and a message would be received on the client that the "connection was reset by a foreign host." Now from 4.1SP2 and on the FW does NOT attempt to re-establish the connection but does indeed drop the connection and it also does NOT send the signal/message back to the client indicating that the connection was reset by a foreign host (because it is being dropped).     The problem with this is that to the simple user this is very confusing as their window (whether they are using a simple telnet client or ssh client or whatever) just freezes (sometimes for a very long time) before they can regain control of their client window. Most users just get fed up with this and cancel/close the window and open up another window.     Now for the question:         I have done some testing and was wondering.... Now that CheckPoint has a new "monitoring" tool much like snoop on variants of Unix platforms is there a way to "watch" this traffic given a specific src and dest IP address (and perhaps a service port to listen on) along with the Src_Port (because I want to be able to watch the connection from beginning to end)?? And can you set it up to monitor say every 5 minutes?         I am hoping to be able to prove something. In our testing I have had one of our problem users telnet into one of their machines in the DMZ and just let it sit. At about the 45 minute mark I have had them hit the <CR> return key a couple of times to verify that the telnet session is still active; which it is. In about another 20 minutes (because I know that the TCP session timeout threshhold has now been exceeded I have them hit the <CR> return a couple more times. This time the window is frozen. I would basically like to track the TCP session timeout counters for "a" particular session and verify that the TCP session timeouts are not getting re-set.         I have also had users complain that they are in the middle of typing when the window freezes but have not been able to verify the particulars on this.         Does the FireWall ignore <CR> returns as a form of communication? It sure seems like it because the window freezes at exactly one hour from the time that the telnetted in and got the login prompt (Unix machine).         I know that I can modify one of the files (can't remember which one, I'd have to go back to one of the FAQs that I gleaned) under FW-1 to ignore this TCP session timeout but I am a little weary of this since the reason that I hear that CheckPoint did it this way was to close a hole for a DoS attack against TCP session timeouts under CheckPoint. Note: I also have in the FW-1 properties page set the traffic INSPECT direction to Inbound (not Outbound nor Etherbound). Sorry for the length but I was hoping that with the detail it would help someone with the answer. As always TIA for any help that might be given.
begin:vcard 
n:Schachtele;Guillaume
tel;fax:(+33) 4.42.36.67.60
tel;work:(+33) 4.42.36.65.50
x-mozilla-html:FALSE
url:http://www.gemplus.fr
org:GEMPLUS;Management Information Service
version:2.1
email;internet:[email protected]
title:MIS Security Engineer
note:DMZ administrator
adr;quoted-printable:;;Gemplus  BP 100=0D=0AGEMENOS=0D=0A13881=0D=0AFRANCE;;;;
end:vcard


 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.