Just remember, there are 2 ways of backing up through a firewall.
- The "insecure" way, where you open incoming ports to the TSM Servers
"TCPPORT" setting, and perform backups in "polling" mode.  If the client
was compromised, it would have access to all the backups, and conceivably
the TSM server.
- The secure way where you only open outgoing ports to the TSM client, and
use the SESSIONINITIATE=serveronly; TCPCLIENTPORT options in prompted mode
Just make sure and don't get those confused.

Regards,
Shawn
________________________________________________
Shawn Drew





Internet
rrhodes AT FIRSTENERGYCORP DOT COM

Sent by: ADSM-L AT VM.MARIST DOT EDU
02/07/2012 09:07 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Firewall problem






Thanks for all the thoughts!

>The 'register node' and 'update node' commands have a
>'sessioninitiation' parameter. The default value, 'clientorserver',
>would be needed for the backup arrangement you describe for clients
>outside the firewall. The other possible value, 'serveronly', would
>cause these backups to fail, possibly with the symptoms you describe.

Will check it out.


>We have a firewall rule that allows all of the DMZ servers
>to contact the TSM servers and the TSM servers are
>allowed in on specific ports.
>In the opt files we have these lines:
>httpport yyyy
>webports xxxx zzzz

I'm not a firewall person - but the rules we have for the other five tsm
servers all work just fine.
It's just this one grrrrrr tsm server.  THey've checked and checked.


>compare the "q opt" output from an instance that works with the instance
>that doesn't.  There might be a conservative timeout setting.

Yes.  We've done that many times.  That's what makes this such
an frustrating problem.  it looks the same as the other servers.
So does the AIX setup, so does the fw rules (from what the fw folks
say - except for a diff ip addr).


>Other long-shot things to compare are "q node (NODENAME) f=d" for the
>specific nodes that are having trouble and "q stat"

Will do.

>I've had to use schedmode polling to get some firewall backups to run.

Yes, we've had to do this also for some nodes to get them to work.
Some nodes just won't work unless we change to polling.  The nodes
behind firewalls just don't work with this one tsm instance, but if we
move
the node to one of the other instances - poof (technical term) - it works.


>You doubtless checked the DNSLOOKUP option, and set it the
>same way on all your servers.
>Is it possible that the DNS for the problem client is also
>the only DNS that is also behind the firewall?   - Margaret

Actually, no . . .not familiar with that options.  WIll have to
read up on it.


Now . . .maybe I brought up this problem too quickly.  It turns out
the firewall folks missed some firewalls, so rules were not made
on some.  The tsm6 instance (where fw backups work) is having failed
backups because of this.  It could be that our testing last friday
evening was with a firewall'ed nodes for which there weren't
any rules!!

Nothing is simple . . . .

Thanks

Rick




-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.