What ports need to be open to back up a client that is behind a firewall?

Article:TECH3101  |  Created: 2000-01-05  |  Updated: 2001-01-24  |  Article URL http://www.symantec.com/docs/TECH3101
Article Type
Technical Solution



What ports need to be open to back up a client that is behind a firewall?


NetBackup is not designed to support backups through a firewall.  Some customers have used the following document
to successfully configure a client to backup  through a firewall, even though this is not a certified operation.
NetBackup will provide this documentation for customers who wish to test this non-supported configuration.

Allow ports 512 - 1024 on the NetBackup master/media server outbound to port 13782 on the client.
Allow connections from port 13721 outbound from the NetBackup master to ports from 512 - 1024 on all NetBackup media servers.  
NOTE:  Outbound port connections are usually not a concern, but are included in this document for completeness.  

Allow connections to ports 512 - 1024 on the NetBackup master server inbound from the NetBackup client
(bpcd/bpbkar to bptm/bpbrm).
Allow connections inbound from the NetBackup client to port 13720 on the NetBackp master server
(requests to bprd).

If multiplexing is being used (not just on), and streaming multiple jobs to a single tape in unison is occurring,
then allow inbound connections from the NetBackup client to ports 1025 - 5000 on the NetBackup master server.

The following is a description of the backup/restore process and how ports are used:
When a server initiates a backup, it uses service "bpcd" with a default service port number of 13782.
It uses a reserved port on the connect, so that the client can be assured that the server process was initiated as root.
This prevents normal users on the server from running NetBackup software and attempting to backup client workstations.

The client "bpcd" process is initiated by "inetd" when the service is requested. The server will then send a 10 character
magic number to the client, that the client uses to make sure that it is talking to NetBackup server software.

The server then sends the number of a reserved port, that it will listen on for the reserved port number,
that the client will use for the NetBackup file data. The client checks the port to make sure it is a reserved port.
The client connects back on this reserved port and the server accepts the connection.
If the accepted socket is not a reserved port, the server aborts.

The client then checks the <peername> of the original connection to see that it is in the list of valid
servers in the /usr/openv/netbackup/bp.conf file.  Messages are sent back and forth for the client to get the file list
to the client, and for the client to tell the server that it is starting the backup.

Using the first available reserved port allows NetBackup to do multiple backups simultaneously.  This process also
sends information about tape mounts from the server to the client progress logs during user initiated backups.

When a client initiates a restore, it uses service "bprd" on the server with default service port number 13720.
The server daemon process "bprd" is listening on this port number for requests.

When a request comes in, "bprd" accepts the connection and reads a request string from the socket.
The string contains a magic number and a request type. Since a normal user can initiate a list or restore request,
a reserved port is not used. A random socket number is used on the connect from the client so that multiple user
initiated backups and/or restores can be done simultaneously.

The server checks the client's <peername> against its list of valid clients. It also uses the
<username> and <groupname> sent in the request string when searching for files to restore. The mode bits
on the file when it was backed up are used to restrict access to the file.

When the files that are needed are found, the server initiates a restore to the client using "bpcd",
as in the backup description above.

The client process does a "setuid" and "setgid" to the user that initiated the restore request.
Files can't be written if the user does not have access.


Legacy ID


Article URL http://www.symantec.com/docs/TECH3101

Terms of use for this information are found in Legal Notices