Replica Clusters behind a NAT
Published Mar 21 2019 04:37 PM 444 Views
Brass Contributor
First published on TECHNET on Oct 10, 2013

When a Hyper-V Replica Broker is configured in your DR site to accept replication traffic, Hyper-V along with Failover Clustering intelligently percolates these settings to all the nodes of the clusters. A network listener is started in each node of the cluster on the configured port.

While this seamless configuration works for a majority of our customers, we have heard from customers on the need to bring up the network listener in different ports in each of the replica server (eg: port 8081 in, port 8082 in and so on). One such scenario is around placing a NAT in front of the Replica cluster which has port based rules to redirect traffic to appropriate servers.

Before going any further, a quick refresher on how the placement logic and traffic redirection happens in Hyper-V Replica.

1) When the primary server contacts the Hyper-V Replica Broker, it (the broker) finds a replica server on which the replica VM can reside and returns the FQDN of the replica server (eg: and the port to which the replication traffic needs to be sent.

2) Any subsequent communication happens between the primary server and the replica server ( without the Hyper-V Replica Broker’s involvement.

3) If the VM migrates from to, the replication between the primary server and fails as the VM is unavailable on After retrying a few time, the primary server contacts the Hyper-V Replica Broker indicating that it is unable to find the VM on the replica server ( In response, the Hyper-V Replica broker looks into the cluster and returns the information that the replica-VM now resides in It also provides the port number as part of this response. Replication is now established to

It’s worth calling out that the above steps happen without any manual intervention.

In a NAT environment where port-based-address translation is used (i.e traffic is routed to a particular server based on the destination ports) the above communication mechanism fails. This is due to the fact that the network listener on each of the servers (R1, R2, comes up on the same port . As the Hyper-V Replica broker returns the same port number in each of it’s response (to the primary server), any incoming request which hits the NAT server cannot be uniquely identified.

Needless to say, if there is an one to one mapping between the ‘public’ IP address exposed by the NAT and the ‘private’ IP address of the servers (R1, R2…, the default configuration works fine.

So, how do we address this problem – Consider the following 3 node cluster with the following names and IP address: @, @ and @

1) Create the Hyper-V Replica Broker resource using the following cmdlets with a static IP address of your choice ( in this example)

$BrokerName = “HVR-Broker”

Add-ClusterServerRole -Name $BrokerName –StaticAddress

Add-ClusterResource -Name “Virtual Machine Replication Broker” -Type "Virtual Machine Replication Broker" -Group $BrokerName

Add-ClusterResourceDependency “Virtual Machine Replication Broker” $BrokerName

Start-ClusterGroup $BrokerName

2) Hash table of server name, port: Create a hash table map table of the server name and the port on which the listener should come up in the particular server.

$portmap=@{""=8081; “"=8082; ""=8003, “”=8080}

3) Enable the replica server to receive replication traffic by providing the hash table as an input

Set-VMReplicationServer -ReplicationEnabled $true -ReplicationAllowedFromAnyServer $true

-DefaultStorageLocation "C:\ClusterStorage\Volume1"

-AllowedAuthenticationType Kerberos

-KerberosAuthenticationPortMapping $portmap

4) NAT Table: Configure the NAT device with the same mapping as provided in the enable replication server cmdlet. The below picture is applicable for a RRAS based NAT device – similar configuration can be done in any vendor of your choice. The screen shot below captures the mapping for the Hyper-V Replica Broker. Similar mapping needs to be done for each of the replica servers.

5) Ensure that the primary server can resolve the replica servers and broker to the public IP address of the NAT device and ensure that the appropriate firewall rules have been enabled.

That’s it – you are all set! Replication works seamlessly as before and now you have the capability to reach the Replica server in a port based NAT environment.

Version history
Last update:
‎Mar 21 2019 04:37 PM
Updated by: