0% found this document useful (0 votes)
741 views10 pages

Netbackup Firewall Requirements

NetBackup requires certain TCP ports to be open between hosts for communication. The main ports that must be open are: - TCP port 1556 (PBX) for communication between master servers, media servers, clients, and admin consoles. - TCP port 13724 (vnetd) is also often required for legacy service communication and is recommended to remain open. - Additional ports like 443 and 902 may be required for VMware backup and restore functionality.

Uploaded by

Brijesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
741 views10 pages

Netbackup Firewall Requirements

NetBackup requires certain TCP ports to be open between hosts for communication. The main ports that must be open are: - TCP port 1556 (PBX) for communication between master servers, media servers, clients, and admin consoles. - TCP port 13724 (vnetd) is also often required for legacy service communication and is recommended to remain open. - Additional ports like 443 and 902 may be required for VMware backup and restore functionality.

Uploaded by

Brijesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

support by produc
Search all support & community content...

 Support / Knowledge Base / 100002391

NetBackup 6.x and 7.x and 8.x firewall port requirements  


Article ID:100002391 Last Published:2018-08-09 Product(s):NetBackup

Problem
 
Which TCP ports must be open through a firewall for NetBackup (NBU) 6.x, 7.x and 8.x hosts to communicate with each other?
This does not include port requirements for communication with services that run on back-level hosts; NetBackup 5.x services, remote EMM Server, or other legacy
processes. Those details are covered in the NetBackup (tm) 6.0 Port Usage Guide for Windows and UNIX Platforms and the NetBackup 7.0.1 Security and
Encryption Guide, see the Related Articles.
 

Cause
 
As the number of NetBackup services has multiplied, and networking as a whole has evolved from the 20th century to the 21st century to the internet, NetBackup
too has evolved.  The goal has been to generally minimize the network and firewall configuration requirements where possible.  These were the main transition
points in the evolution of NetBackup.

Initially, all NetBackup services listened on their own unique (daemon) TCP port. 
Any additional connections needed between the process on the connecting host and the servic were made by the service using a call-back connection
from the service host to a TCP port in the SERVER_PORT_WINDOW on the connecting host.
 

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
In NetBackup 4.5, the services began to also listen/accept connections from the new vnetd service that listened on TCP port 13724.  The connecting
processes still defaulted to daemon port usage to prevent immediate firewall conflicts (connect options = x x 2).  Once firewalls were reconfigured,
NetBackup could be configured to try to reach services via vnetd with retries via the daemon ports (connect options = x x 1). 
Any additional connections needed between the processes were still made with call-back (connect options = x 0 x), but could be configured to use the
new connect-back connection type.  The latter is from the service to vnetd/13724 on the connecting host(connect options = x 1 x).
If the TCP port for vnetd/13724 was open bi-directionally between all hosts, the daemon and call-back ports no longer needed to be open through any
firewalls provided the 'default_connect_options = 1 1 1' was configured on all hosts.
 
In NetBackup 5.x, the connecting processes where switched to prefer vnetd over the daemon port by defaults (default_connect_options = 1 1 1).  If a
connection could not be established via vnetd, it was still retried via the daemon port.
 
In NetBackup 6.0, the PBX process was introduced to support CORBA connections.  It listens on TCP port 1556 for inbound CORBA connections to the new
services which are multi-threaded, much like vnetd does on TCP port 13724 for the many single-threaded legacy services. Thus, all of the new services could
be reached via port 1556 and each new service did not need to listen on its own unique port.
At the same time, the vnetd forwarding connection was introduced as an alternative to the the prior call-back and connect-back mechanisms used to
make additional connections to bpcd and other legacy client processes. The forwarding connection, like the service connection, is opened from
the connecting host to the targert/service host, thus removing the need to accept TCP SYN packets inbound from NetBackup client hosts if only
server-initiated standard backup and restore operations are performed.  Forwarding sockets were automatically used with connect options = x x 0|1. 
Legacy call-back or vnetd connect-back was still available with connect options = x 0|1 2.
 
In NetBackup 7.0.1, the legacy services were updated to also register with PBX to accept inbound connections; in addition to still accepting connections from
vnetd and directly on the daemon port.  At the same time, the connecting processes were switch to first try to connect to the legacy services via PBX before
retrying via vnetd and then retrying via the daemon port if necessary.
 
In NetBackup 7.5, the Resilient Network Transport Daemon (nbrntd) was introduced.  It uses the TCP port for vnetd/13724 exclusively because PBX cannot
do what nbrntd needs to have done, but vnetd can.
 

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
In NetBackup 8.1, outbound connections to legacy services between secure communication capable hosts were changed to utilize only the TCP port for
PBX/1556; any configured connect options are ignored.  The legacy services still listen for inbound connections via the TCP ports for vnetd/13724 and
daemon ports, but only continue the communication if the connection is from a known, verified, pre-8.1 host (or the local vnetd process in the case where
Resilient Network is configured).
 
NetBackup also continues to need to interact with a growing number of other network accessible 3rd party processes listening on additional ports.
 

Additional details are included in the Solution below.


 

Solution
 
The TCP ports used by NetBackup in the default configuration are as follows; without overriding connect options in the Client Attributes (bpclient) or Firewall
(CONNECT_OPTIONS) settings:

Master server to/from media servers requires the TCP port for PBX/1556, bi-directional.
Master server to client requires the TCP port for PBX/1556 if performing stream discovery, application discovery, or if the clients perform user-directed
backup/archive/restore, or client-directed application backup/list/restore.

Media server to media server requires the TCP port for PBX/1556, bi-directional.
Media server to client requires the TCP port for PBX/1556.
 
Client to master server requires the TCP port for PBX/1556 for client-initiated (user or application), but not server-initiated, operations.
Client to master server requires the TCP port for PBX/1556 for Client Direct restores (new in 7.6).
Clients require the TCP port for PBX/1556 to be open either to the master server or to a media server that can act as a http proxy tunnel for web service calls
(new in 8.1). 

SAN Client to/from master/media servers requires the TCP port for PBX/1556, bi-directional.
 

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
Java/Windows admin consoles to master and media servers requires the TCP port for PBX/1556, bi-directional.
 
Hosts running NetBackup 7.0.1 - 8.0 will retry connections to legacy services via the TCP port for vnetd/13724 if the connection cannot be established via the
TCP port for PBX/1556.
If the service cannot be reached via the TCP port for PBX/1556 and the TCP port for vnetd/13724 is blocked by a firewall which silently discards the
TCP SYN packet, then the operating system connect() API will wait for TCP SYN retry/timeout before failing the connection attempt.  This will
introduce delays before NetBackup can detect a connection failure.
If the firewall returns an immediate TCP RESET, there will be minimal delay before the connction failure is detected.
 
Note:  The firewall behaviors described in the bullet above also apply to any other TCP port that is blocked, but attempted to be used.
For that reason, it is recommended that the TCP port for vnetd/13724 remain open bi-directional between NetBackup hosts.
 
Hosts running NetBackup 5.x - 7.0 target the TCP port for vnetd/13724 when connecting to legacy services (instead of PBX/1556).
 
Hosts running NetBackup 4.5 target the TCP daemon ports for the legacy services (instead of vnetd/13724), unless the connect options have been changed
to 'x x 0|1'.
Hosts running NetBackup 3.x - 4.0 target the TCP daemon ports for the legacy services (instead of vnetd/13724).
 
If using the Resilient Network/Client feature for connections to legacy services:  (new in 7.5)
It must be configured on both the connecting and accepting hosts; master, media server, and/or client.
The TCP port for vnetd/13724 must be open bi-directional between the hosts.

To backup and restore VMWare:


Backup host to vCenter requires TCP port 443.
If using query builder (VIP), master server to vCenter requires TCP port 443.
If using the nbd transport type, backup host to ESX host requires TCP port 902.
 
If using the NetBackup plugins for VMware or Hyper-V:

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
The master server must have TCP port 8443 open inbound from the hosts running the plugin (vCenter, vSphere web client, etc).

To backup and restore SharePoint:


Front End to/from SQL client hosts requires legacy service connectivity, bi-directional; PBX/1556.
Front End to/from SQL client hosts also use the "remote registry service" which requires TCP ports 135, 137, 138, 139 and 445.
See Microsoft article, https://docs.microsoft.com/en-us/SharePoint/security-for-sharepoint-server/security-hardening
 
If using Granular Restore Technology (GRT):
Clients need to connect to the media server on portmap/111 and nbfsd/7394.
 
If using OpsCenter:
Web browsers require TCP ports http/80 and https/443 to the OpsCenter Web GUI with either 8181 and 8443 or 8282 and 8553 used as alternates.
Custom report generators require TCP port 13786 to the OpsCenter Server.
Open port 1556 (pbx) between the OpsCenter server and master server.
OpsCenter Server also uses UDP port 162 outbound for SNMP trap protocol.
 
To backup and restore NDMP filers:
Media server (DMA) to NDMP filer (tape or disk) requires TCP port 10000.
The SERVER_PORT_WINDOW is used inbound from the filer to the media server for remote NDMP and can also be used for efficient catalog file (TIR
data) movement with local and 3-way NDMP.
 
If using VxSS with NetBackup pre-7.1 Access Control (NBAC):
Master servers require the TCP ports vrts-at-port/2821 and vrts-auth-port/4032 to the VxSS server.
Media servers require the TCP ports vrts-at-port/2821 and vrts-auth-port/4032 to the VxSS server.
Clients require the TCP port vrts-at-port/2821 to the VxSS server.
Java/Windows admin consoles require the TCP port vrts-at-port/2821 to the VxSS server.
 
If using the OpenStorage plug-in by DataDomain:

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
Requires access to TCP port 2049, UDP/TCP port 111, and the mountd port on the target DataDomain array.
For optimized duplication access to TCP port 2051 is also required.
 
If using Optimized Duplication (including Automatic Image Replication):
For MSDP-to-MSDP, the source storage server needs access to spad/10102 and spoold/10082 on the destination server.
For MSDP-to-PDDO, the source storage server needs access to SPA/443 and spoold/10082 on the destination server.
For PDDO-to-PDDO, the source storage server needs access to SPA/443 and spoold/10082 on the destination server.
 
For Automatic Image Replication (AIR)
In addition to the ports for Optimized Duplication, also open the TCP port for PBX/1556 between the master servers.
 
For NetBackup Copilot
Open 8446 from the master server to the NetBackup appliance media server hosting the co-pilot NFS shares, for web service reqeusts.
Open 2049 and 111 from the client to the NetBackup appliance media server, so it can mount the NFS share.
 
For NetBackup 5xxx Appliances:
Open ssh/22, http/80, and https/443 inbound for in-band administration.
Open http/80 and https/443 inbound to the Intelligent Platform Management Interface (IPMI) for out-of-band administration.
Open 5900 inbound to the IPMI for KVM remote console/CLI and virtual ISO/CDROM redirection from NetBackup Integrated Storage Manager
(5020/5200 appliances).
Port 623 will also be used if open.
Open 7578 inbound to the IPMI for Remote Console CLI access (5220/5x30 appliances).
Open 5120 inbound to the IPMI for Remote Console virtual ISO/CD-ROM redirection (5220/5x30 appliances).
Open 5123 inbound to the IPMI for Remote Console virtual floppy redirection (5220/5x30 appliances).
Open 111, 867, 2049, and 20048 inbound for portmapper, nfs, and mountd.
Open 139 and 445 for samba/netbios.
Open 27017 inbound between nodes in an Appliance High Availability cluster.
Open https/443 outbound to the Veritas Call Home server for proactive hardware monitoring and messaging.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
Open https/443 outbound to the Veritas Critical System Protection (SCSP) server to download SCSP certificates.
Open snmp/162 outbound to the SNMP server for SNMP traps and alerts.
Open 11111 between PureDisk appliances for multi-node topology discovery.
 
For CloudStore open port 5637 inbound to master and media servers from other NB servers and OpsCenter hosts (new in 8.1).
 
For CloudCatalyst, open port 443 from the media server to the cloud server.

 
Local/Internal Listening Ports
NetBackup processes also use TCP ports for intra-host connects that are internal to the host.  These ports do not need to be open externally.  The ports may be
bound and listening only for connections to the loopback interface (127.0/8, or ::1) or for all network interfaces (0.0.0.0, *.*.*.*, or:::) depending on the hostname
targeted by the connecting process; localhost or other hostname local to the host.

port 1557 (PBX)


port 3652 (nbwmc)
port 8205 (nbwmc)
port 9284 (nbsl NBSL_NCWS_PORT)
port 13785 (NB_dbsrv <--> nbwmc)

Note: These ports need to be available when/if the service starts, or functionalitly will be impaired.
 
Legacy Daemon Ports
The NetBackup legacy daemons continue to listen on the legacy ports for both intra-host connections from other processes on the same host and inter-host
connections from back-level hosts.  These ports do not need to be open through the firewall unless back-level hosts are present that cannot connect via PBX/1556.

port 13701 (vmd, media servers)


port 13702 - 13719 (robotic and control daemons, media servers)
port 13720 (bprd, master server)
port 13721 (bpdbm, master server) 
port 13722 (bpjava-msvc, master server)

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
port 13723 (bpjobd, master server)
port 13782 (bpcd, master and media servers, clients)
port 13783 (nbatd, master server)
port 13786 (OpsCenter report generation, master server) 

Note: These ports need to be available when/if the service starts, or functionality will be impaired.
 
NetBackup 7.0.1 Considerations
The bpcd and vnetd processes now run standalone. They and the other legacy processes now register with PBX at startup. Connections to legacy processes that
previously contacted the vnetd port will now prefer to use PBX port 1556. If the PBX port is unreachable, then the vnetd port will be used. If the vnetd port is
unreachable, then the daemon port will be used. Opening TCP port 1556 outbound from NetBackup servers to NetBackup clients will prevent delays that occur while
attempting to use PBX. Similarly, opening TCP port 1556 inbound will prevent delays for client-initiated requests to the master server.
Note that the Java console to master server uses the vnetd port for connection to bpjobd and the PBX port for all other connections.
For efficiency the upgrade/install also adds Connect Options of '1 0 2' for localhost. Internal sockets on the loopback interface to processes on the same host will
use the daemon ports instead of passing through vnetd or PBX.
 
NetBackup 7.1 Considerations
NetBackup Access Control (NBAC) has been integrated with NetBackup and the processes nbatd and nbazd will be used in place of vxatd and vxazd. These
processes are registered with PBX for inbound connections via the PBX port 1556, removing the need to have ports open to the VxSS server.
The processes are also listening on TCP ports 13783 and 13722 respectively. These port numbers are registered with IANA using the original service names of
'vopied' and 'bpjava-msvc', and resolved by NetBackup using those original names. Back level hosts are unaware of the new processes available via port 1556 and
will continue to contact vxatd and vxazd via vrts-at-port/2821 and vrts-at-auth/4032.
Snapshot backups may experience a small delay during snapshot deletion if port 1556 is not open from the client to the master server.
 
NetBackup 7.5 Considerations
The Resilient Network feature requires vnetd/13724 to be open bi-directional for connection to legacy services on any host specified by the configuration of the
feature.  This is meant primarily for media server to client.  But can also be configured for client-directed operations between the client and the master server, or
between master and media server. This feature cannot use PBX/1556.
 
NetBackup 7.6 Considerations

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
The Client Direct restore feature requires the TCP ports for PBX/1556 and vnetd/13724 to be open from the client to the master server for the file list port
connection; regardless of whether the restore is server or client initiated.
 
NetBackup 7.7.1
The Co-Pilot feature requires the TCP port for 8443 to be open inbound to the NetBackup appliance from the master server to manage the NFS shares.  The
standard NFS ports, 2049 and 111 must be open inbound from the clients so that they can mount the NFS shares.
 
NetBackup 8.1 Considerations
The secure communication feature requires that all NB 8.1 or higher hosts (including clients) can connect to web services on the master server. The connection is
via port 1556/PBX, either direct to the master server or indirectly via a media server acting as a proxy tunnel. The media server already has/requires access to the
master server on port 1556/PBX.
The secure communication feature also deprecates the use of Connect Options from NB 8.1 or higher hosts to any other host. Options settings that enable legacy
daemon ports, vnetd connect-back, legacy call-back, and reserved port use are ignored.
The CloudStore feature introduces a new service (nbcssc) which runs on master and media servers. The new service listens, by default, on port 5637 which must be
open inbound from the other NB servers and the OpsCenter hosts.
 
Network Address Translation (NAT) and Port Address Translation (PAT) Considerations
The use of NAT and PAT is not supported with NetBackup. See 100004694 in the Related Articles section for details.
 

Related Articles
Veritas NetBackup (tm) 7.0.1 Security and Encryption Guide
Veritas NetBackup does not support Network Address Translation and Port Address Translation

References
Etrack : 3332635

Was this content helpful?

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
Yes  No 

Get Support

Create Case Chat Phone

VOX Community Veritas.com Visit Our Social Dashboard     

Privacy Policy Legal User Agreement

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD

You might also like