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.
|