Regkey of the month: March

Port customization using the registry

The modern enterprise data center is characterized by a high degree of complexity, where a multitude of services, security agents, and infrastructure management tools compete for finite network resources. At the heart of this complexity lies the challenge of network orchestration, particularly the management of TCP and UDP ports. For data protection architects utilizing Veeam Backup & Replication, the default port assignments for various services—while designed for ease of use—frequently encounter conflicts with existing environment constraints. 

The ability to pivot away from these defaults is not merely a technical convenience but a prerequisite for maintaining operational continuity, satisfying security compliance, and ensuring the seamless deployment of backup agents across heterogeneous environments.

Conflicts in with default network topologies

The initial deployment of Veeam Backup & Replication typically proceeds with the assumption that the standard communication channels are unobstructed and unoccupied. The Veeam Deployer Service, which manages the lifecycle of components on remote managed servers, defaults to TCP port 6160. Similarly, the Veeam Transport Service, responsible for the actual movement of backup data between the source and the repository, defaults to TCP port 6162. In a vacuum, these assignments are sufficient; however, real-world deployments are rarely conducted in a vacuum

The evolution of the Veeam platform itself introduces new network requirements that can clash with existing infrastructure. The transition to Veeam VBR version 13 has highlighted a significant architectural shift, requiring port 443 for critical update and management functions. In scenarios where the Veeam Backup & Replication (VBR) server is co-located on a physical host that also serves as a Hyper-V Replication server or hosts a mission-critical web application, port 443 is often already claimed. This necessitates a complex reconfiguration process where administrators must choose between moving the conflicting application or modifying the backup infrastructure’s network profile. This is particularly challenging for smaller organizations where dedicated hardware for separate roles is not always economically viable, leading to high-density service co-location.

Security hardening is another primary driver for port customization. The implementation of an Veeam Hardened Repository (VHR) requires a minimal attack surface. Administrators frequently seek to move management services away from well-known ports to obfuscate the infrastructure from automated scanning tools. Additionally, automated firewall management features within Veeam may inadvertently open ports on all active network interfaces, including public-facing ones, posing a risk in multi-homed systems. Restricting these services to specific ports on isolated management networks is a core practice of Zero Trust strategies.

The standard list

It is necessary to categorize the primary default ports utilized within the Veeam VBR ecosystem. The following table provides an overview of the essential communication channels that are subject to modification requirements.  

Service Component	Direction	Protocol	Default Port	Functional Description
Veeam Deployer Service	VBR Server to Target	TCP	6160	Deployment and management of Linux components.
Veeam Transport Service	VBR Server to Target	TCP	6162	Data mover management and certificate exchange.
Veeam Data Mover	Source to Target	TCP	2500–3300	Dynamic range for actual data transmission.
Management Agent	Tenant to Cloud Gateway	TCP	6180	Management traffic in Service Provider environments.
Cloud Gateway	VBR Server	TCP	6169	Listening for incoming cloud commands from tenants.
VSPC Web UI	Console Server	TCP	1989	Communication between UI and management server.
Veeam License Server	Server to Web	TCP	443	Automated license updates and usage reporting.
Enterprise Manager	Web UI	TCP	9392	Web-based management interface for VBR.

Port Determination: Logic Priority and Architectural Hierarchy

When Veeam Backup & Replication initiates a deployment task, the system evaluates several configuration layers to determine the target ports. This hierarchy is designed to provide maximum flexibility, allowing for global defaults to be overridden by more granular, group-specific settings. Understanding this logic is important for administrators who need to apply unique settings to specific network zones—such as a DMZ or a remote branch office—without disrupting the primary data center configuration.

The determination logic follows a strict three-tier priority system :

1. Protection Group-Specific Overrides: The system first queries the registry (on Windows) or the configuration file (on the Linux appliance) for settings specific to the Protection Group ID. If a custom port is mapped to that specific ID, it takes precedence over all other settings.
2. Global Custom Overrides: If no Protection Group-specific value is found, the system checks for a global custom port configuration. This applies a universal change to all new deployments across the entire backup infrastructure.
3. Hardcoded System Defaults: In the absence of any custom configuration, the system reverts to the default ports (6160 and 6162).

Important to know

The customization of these ports only impacts deployments that occur after the registry values or configuration entries have been created. For existing agents, the ports remain at their previous settings unless the agent is removed and redeployed or the port is manually changed on the target host through the command-line interface.

Customizing Ports on Windows-Based VBR Servers

For environments managed by a Windows-based Veeam Backup & Replication server, the Windows Registry serves as the primary orchestration engine for port customization. Modification of these values requires administrative privileges and a restart of the Veeam services to ensure the internal deployment logic is refreshed.
 

Global Port Configuration

When the objective is to move eg. all future Linux agent deployments to a new port standard—for instance, to align with an organization-wide policy that reserves the 6000-range for other purposes—global registry keys are utilized.

    To modify the Global Custom Deployer Service Port

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: AMCustomLinuxDeployerPort
• Type: REG_DWORD

                            This defines the port used by the veeamdeployment service.

    To modify the Global Custom Transport Service Port

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: AMCustomDataMoverPort
• Type: REG_DWORD

                           This defines the management port used by the veeamtransport service.

Protection Group-Specific Configuration

In complex network topologies, different segments may require different port configurations. This is common in Service Provider environments where different tenants may have unique firewall constraints. Implementing these changes requires identifying the Protection Group ID via the Veeam PowerShell.

    To modify the Protection Group-Specific Deployer Port

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: AMProtectionGroupCustomDeployerPort
• Type: REG_SZ (String)

                            Format: The data follows the pattern PG_ID:port. Multiple groups can be handled by using the pipe separator (e.g., PG_ID_1:7160|PG_ID_2:8160).

    To modify the Protection Group-Specific Transport Port

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: AMProtectionGroupCustomDataMoverPort
• Type: REG_SZ (String)

                            Format: PG_ID:port.

Time Synchronization and infrastructure health can cause troubles

Sometimes you think it's the port, but it's actual time-drift... In environments utilizing eg. Nutanix or other hyper-converged infrastructure, port issues can sometimes be symptoms of underlying health check failures. For instance, if NTP port (UDP 123) is blocked, the resulting time skew can cause authentication failures between the VBR server and the cluster, which may manifest as connection timeouts. A time skew of even 5 seconds can risk cluster operations and prevent third-party backup software from interacting with the cluster correctly. Therefore, validating NTP connectivity and ensuring a stable time source is a prerequisite for reliable network communication.
 

Security Hardening and Zero Trust Implementation

Customizing ports is a fundamental component of securing the backup infrastructure. By moving management and transport services away from well-known ports, administrators can significantly reduce the efficacy of reconnaissance tools used by malicious actors during the initial phases of a ransomware attack

 

Finally, let me give you a list of all keys available for the specific customization

Environment	Specificity	Registry Value / Config Key	Data Type
Windows VBR	Global	AMCustomLinuxDeployerPort	REG_DWORD
Windows VBR	Global	AMCustomDataMoverPort	REG_DWORD
Windows VBR	PG-Specific	AMProtectionGroupCustomDeployerPort	REG_SZ
Windows VBR	PG-Specific	AMProtectionGroupCustomDataMoverPort	REG_SZ
Linux Appliance	Global	AMCustomLinuxDeployerPort	Integer
Linux Appliance	Global	AMCustomDataMoverPort	Integer
Linux Appliance	PG-Specific	AMProtectionGroupCustomDeployerPort	String
Linux Appliance	PG-Specific	AMProtectionGroupCustomTransportPort	String

Note: Protection Group IDs are required for all group-specific overrides and can be retrieved via the Get-VBRProtectionGroup PowerShell cmdlet.