Operating the TSM Client with Firewalls

There is an ever-increasing movement (and rightly so) to operate
firewalls to protect your local networks. However, these firewalls are
usually between the TSM server and your server running the TSM client
scheduler. This document is intended to give people a little more
background on TSM operation and how to deal with firewalls while still
protecting their data.

Before we continue, it is necessary to explain a little about how the
TSM client scheduler works. There are 2 methods of communication:
PROMPTED and POLLING. We have a mix of them out there, so we'll explain
both:

PROMPTED: In a nutshell, when the TSM client scheduler starts, it opens
and begins listening on a port on the local machine. It then contacts
the server and synchronizes what the server knows about the local
client. The client scheduler retrieves the backup schedule and then sits
in the background and waits for the server to contact it. At some point
the server will contact the client scheduler, using the local port that
was registered with the server at startup, and initiate a backup.

That works quite well, because the server can then manage its load and
only start new backups when it has the capacity. And with a firewall,
the TSM client scheduler startup sequence works well, because many
firewalls are configured to allow all outbound connections while
blocking most inbound ones. However, when it comes time for the TSM
server to tell the client scheduler to start backing up, the firewall
blocks the connection from the TSM server, so your client scheduler
never receives the message and the backup never occurs.

There are two good solutions for this:

1) Configure the firewall to permit connections from the TSM server to
the client scheduler port (by default TCP 1501, but you can set that).
This approach permits the old behavior of the TSM server, but will
require that you change the firewall rules for all the hosts you are
backing up if the TSM server IP ever changes. Currently, the IP address are:

buckybackup2.doit.wisc.edu - 144.92.9.161
buckybackup3.doit.wisc.edu - 144.92.9.162
buckybackup4.doit.wisc.edu - 144.92.9.162.

2) Change your method of communication to...

POLLING: When the TSM client scheduler starts, it contacts the server
and synchronizes what the server knows about the local client. It
retrieves the backup schedule, and then checks in with the server every
4 hours up until it's time to do the backup. When the time comes, the
client scheduler polls the server, in effect asking "Can I back myself
up now?" The server will tell the client scheduler to begin backing up,
or to wait a period of time and ask again. The client scheduler will
continue polling the server throughout the backup window until it gets
backed up. Because the machine inside the firewall is initiating all the
communications, this approach is instantly compatible with most firewall
installations. If your firewall does not permit outbound connections you
may wish to permit connections to the server's IP address, and at least
to the port(s) that the TSM server is using (TCP 1500 for Bucky2 & TCP
1501 for Bucky3 & TCP 1502 for Bucky4). You may also need to permit
"related" connections through the firewall also.

To change the client scheduler mode, look in dsm.sys or dsm.opt for the
SCHEDMODE directive and change it from PROMPTED to POLLING. If it is
missing this directive, add the line. You will need to save your changes
& restart the TSM client scheduler for it to take effect.

Many system administrators opt for the POLLING option, since it requires
less work on the firewall and some simple changes to the client
configurations. Also, our Bucky Backup support team has found this
option to decrease the chance of missed backups (regardless of the
existence of a firewall), so it is the recommended method. But either
way is a valid solution -- it just depends on what is easiest for you.