Hi there,
> there are patches for networker 6.x.x Nt client and
> Unix servers to make them obey the port restrictions.
I believe someone posted my replay to the list month
ago something like that with LGTpas for that. Note,
I said there that I had currently an issue with 6.1.2
as well. Now, this has been cleared out. Due to some
code changes (mostly DNS caching) if You calculated amount
of communication ports needed and everything was fine
with versions prior to 6.1.2 You will hit the problem here.
It seems that 6.1.2 requires larger amount of communication
ports. I'm currently waiting for official LGTpa on that.
After increasing communication ports range everything was
fine (upgrade was only action taken).
> There is a problem with some versions of the software for
> Nokia FW1.
Legato is aware of this for quite some time and there is no
doubt about that; as prove I would use those Legato users
who already reported this to Legato and You may find their
emails in archives.
However, there is a solution for this which basically has
been taken from Firewall mailing list I would say. What
they say, to repeat known stuff, is (quote):
------------------------------------------------------------
In 4.1, you can revert to the old behavior by adding the
following to $FWDIR/lib/fwui_head.def:
#define ALLOW_NON_SYN_RULEBASE_MATCH
You can disable logging of these packets in FireWall-1 4.1
base or 4.1 SP1 by commenting out the following line in
$FWDIR/lib/ fwui_head.def (place two forward slashes '//'
in front of the line):
#define CLUSTER_RULEBASE_MATCH_LOG
In FireWall-1 4.1 SP2 and later, you would comment out the
following line in $FWDIR/lib/fwui_head.def:
#define NON_SYN_RULEBASE_MATCH_LOG
-------------------------------------------------------------
>From here we can conclude one clear thing: when Legato code
was designed it obviously didn't follow restrictions which
took the place after in Checkpoint (prior to 4.1).
However, firewall community certainly doesn't like it. To make
things simpler we have 3 points in communication:
1. The "Start" of a connection, which is a four-way handshake
(i.e. the normal 3-way handshake plus the first "real data"
packet).
2. The "middle" of a connection (anything before a FIN or RST
packet is received).
3. The "end" of a connection (begins with the first FIN packet)
We see the timeouts here, specially between 3-way handshake and
first real data as You noticed (60 secs).
So, You may wish to increase those timeouts as first thing to do.
Further, I found on firewall mailing list that's actually a really
bad way to solve the problem. Check Point doesn't actually give
the connection it's proper TCP Timeout until it receives a forth
packet on that connection. So here we go:
----------------------------------------------------------------
"What you really want to do is change the tcpstarttimeout, though
making that change globally may not be desirable. I figured out a way
to do it on a per-service basis. This is a change for 4.1, I'm sure
there's a way to do this in NG, but I haven't looked yet. Change the
line in $FWDIR/lib/base.def on the management that says:
record <conn;r_ckey,r_ctype,r_cflags@TCP_START_TIMEOUT>
(which appears in the funcdef for RECORD_CONN) and replace it with:
((dport = X, record <conn;r_ckey,r_ctype,r_cflags@Y>) or record
<conn;r_ckey,r_ctype,r_cflags@TCP_START_TIMEOUT>)
Where X is the port number of the service (I don't know exactly) and
Y is the timeout you want in seconds. I think 15 minutes, i.e. 900
seconds is sufficient, though you'll need to test your specific
situation to find out for certain. Note that for other TCP services,
the normal tcpstarttimeout value will be used as defined in
objects.C, so the new timeout will only apply for TCP connections on
port X.
----------------------------------------------------------------
So, to conclude, we do have a bunch of workarounds just because
current NetWorker code does not fit current Checkpoint settings.
We do have an options from Checkpoint firewall side to change this
(which in Your case may or may not open some other holes). I would
love to see NetWorker having an option to keep alive the session
which has been initiated by him. I do not expect this to be big
work for a code change. With that, we would avoid timeout issue.
One more things, I found information that FW-1 prior to SP5 had
some problems and was also killing some valid connections (that
was planned to be fixed in SP5). So check that out as well.
Cheers,
Hrvoje Crvelin
Orchestra Service
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
