On Tue, 18 Feb 2003 16:03:15 -0500, Gary Goldberg <og AT DIGIMARK DOT NET> 
wrote:

>Thank you for the advice. I'm currently allowing ports 7937-8764 and
>10001-30000 on UDP and TCP between the nsrserverhost and the clients.
>This is from the Legato firewalls white paper. I've examined the firewall
>logs (and re-examined them before replying, and nothing between the
>nsrserverhost and the clients was recorded. Is it possible there is a
>port not listed that is being used? I know each client generally has
>two nsrexecd's running -- once for Networker and one for its own
>version of portmapper. Could something here be hanging that would
>account for the failures? -Gary
>
There has apparently been a problem with NetWorker using ports outside of
the specified range going back as far as version 5.5.3.  This has
*supposedly* been *fixed* as of version 6.1.2.  However, if you do upgrade,
I would recommend skipping 6.1.2, and go directly to 6.1.3.

One test to try before upgrading might be to open up ALL the ports and see
if the problem persists.

There has also been some discussion about the tcp_keep_alive timeout (which
I don't fully understand, not being a firewall expert). Attached are some
fragments I've seen from listers in the past.

HTH
Carl Farnsworth
DigiDyne Inc.

========================
LGTpa31980 (fixed in 6.0.3 & 6.1.2)
----------
Problem Synopsis:
Beginning with NetWorker 5.5.3, NetWorker uses privileged ports when it
shouldn't, even though the configuration is to use service ports from
7937-9936 and connection ports from 10001-30000 (default range for both
connection ports and service ports)
Hypothesis:
If you install either NetWorker 5.5.3 or 6.x server then NetWorker uses
ports outside the configured port range (in this case ports < 1024). This is
no the expected behaviour and it worked correctly with NetWorker 5.5.1
Expected Behaviour: NetWorker should not use ports outside the configured
port range. It should not use privileged ports unless so configured.
Notes
Nsrmmd is found to use privileged ports even the option -P is not specified.
This has been corrected by modified the source file.

LGTpa35336 (Fixed in 6.1.2)
----------
Threads on nsrexecd.exe on NT do not initialize port ranges properly.  The
problem was caused by a logic error in the problem and has been fixed.

=========================================
In addition to the ports being used outside the restricted range, we were
originally getting problems trying to back up our clients through the
firewall when the ports were not restricted and the firewall was wide open.
We were getting errors of "!no output" and also "code 9". These were fixed
by modifying the tcp_keepalive_interval on the Unix backup server using ndd
from the default 7200000 to 3000000 (milliseconds), and also getting our
firewall team to modify the objects.c code on the Checkpoint firewall FW-1
software for tcp initial timeout (can't recall actual variable name) from
60 seconds to 3600 seconds.

This then allowed us to backup the server without problems through
an 'open' firewall. We now have issues, as discussed in this forum, of not
being able to back up through the firewall using the restricted port range.

=========================================
Date:    Mon, 3 Jun 2002 10:07:47 -0700
From:    Ragu Nandan <ragus1edify AT YAHOO DOT COM>
Subject: Re: backup client through a DMZ

Its a very good explanation. But how do I liberate
those ports? Anyway this problem is same as the one
suggested by the Daemon Welch-Albernathy (aka
Phoneboy, the author of Essential CP FW-1).Below
  "The problem is that Legato does something
non-standard. It assumes that since there is *some*
established connection between the two hosts that
it can send an ACK packet on a *different* port.
FireWall-1 rightly drops these packets because they
are not part of an established connection. The below
modification (uncommenting the line) disables that
check, but it also opens you up to a potential DoS
attack and can even be used as a covert channel to get
around the firewall".
*#define ALLOW_NON_SYN_RULEBASE_MATCH*/
in $FWDIR/lib/fwui_head.def
 I might try this suggestion just for the heck of it
and worry about security ramifications later.
Ragu


--- "VERHAEGHE Koen (BMB)"
<Koen.VERHAEGHE AT PROXIMUS DOT NET> wrote:
Dave, this is an extract of a mail from out firewall
people. It may help. We have the same issue here :
sometimes it works very nice, other times, we get a
time-out

"I look the log and the properties of the firewalls
and you can see the timeout is 3600 s.
So after this timeout the firewall drop the session
TCP if there is not traffic after 1 hour, and you can
see in this log than the elments try to communicate
each other with the same port which has been used more
1 hour ago:
So the firewall drop the TCP session for the reason
'TCP session no establish' because for it, in its
table the port isn't used.
So the solution is to liberate the ports in the
elements when they has finished the communication with
the backup server otherwise the elements use an old
port (which is designed for the legato session in the
table of elements) whereas for the firewalll the
session doesn't exist anymore so it drops the
session."

--
Note: To sign off this list, send a "signoff networker" 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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=