Network address translation (NAT) is usually used for firewall and security because it hides the server's real address. NAT is supported in HADR environments unless you are also using the DB2® pureScale® Feature.
In an HADR setup, the local and remote host configurations on the primary and standby nodes are cross-checked to ensure that they are correct. In a NAT environment, a host is known to itself by a particular IP address but is known to the other hosts by a different IP address. This behavior causes the HADR host cross-check to fail unless you set the DB2_HADR_NO_IP_CHECK registry variable to ON. Using this setting causes the host cross-check to be bypassed, enabling the primary and standby to connect in a NAT environment.
If you are not running in a NAT environment, use the default setting of OFF for the DB2_HADR_NO_IP_CHECK registry variable. Disabling the cross-check weakens the HADR validation of your configuration.
In a NAT environment with a multiple standby setup, you must use each standby's settings for the hadr_local_host and hadr_local_svc configuration parameters for the primary's hadr_target_list configuration parameter. Otherwise, the primary does not accept the connection from that standby.
In a multiple standby setup, you should set the DB2_HADR_NO_IP_CHECK registry variable for all databases that might connect to another database across a NAT boundary. If a database will never cross a NAT boundary to connect to another database (that is, if no such link is configured), you should not set this registry variable for that database. If you set the DB2_HADR_NO_IP_CHECK registry variable, it prevents a standby from automatically discovering the new primary after a takeover has occurred, and you must manually reconfigure the standby to have it connect to the new primary.