Cluster Address Mapping for Expressway-E Clusters
For secure deployments like MRA, each Expressway-E peer must have a certificate with a SAN containing its public FQDN. The FQDN is mapped in the public DNS to the Expressway-E's public IP address. This configuration enables external entities, like MRA endpoints, to discover the Expressway-E's public interface and establish a secure connection.
Do You Need Cluster Address Mapping?
-
If you simply want to cluster Expressway-E peers and you don't need TLS verification between them, then you can form the cluster using the nodes' private IP addresses. You don't need cluster address mapping.
-
If you want the Expressway-E peers in a cluster to verify each other's identities using certificates, you could allow them to use DNS to resolve cluster peer FQDNs to their public IP addresses. This is a perfectly acceptable way to form a cluster if the Expressway-E nodes have only one NIC, are not using static NAT, and have routable IP addresses. You don't need cluster address mapping.
-
If your security policy dictates that you enforce TLS verification between the peers, and if the Expressway-Es are using static NAT, or dual NIC, or both, then we do not recommend using the external interfaces or the static NAT addresses to form the cluster.
Also, do not try to use the public DNS to map the peers' public FQDNs to their private IP addresses, because you will break external connectivity.
You should use cluster address mapping in these situations.
How Cluster Address Mapping Works
When you use Fully Qualified Domain Names to form the cluster, peers must be able to translate those names into IP addresses. This translation is the main reason for DNS but, if the peers have no access to DNS, or if you need to translate the FQDN into a private IP address, then you can populate the cluster address mapping table to provide a local alternative to the DNS.
Cluster address mappings are FQDN:IP pairs which are shared around the cluster, one pair for each peer. The peers consult the mapping table before they query DNS and, if they find a match, they do not query DNS.
If you choose to enforce TLS, the peers must also read the names from the SAN field of each other's certificates, and check each name against the FQDN side of the mapping. If the SAN matches the FQDN side of the mapping, and if the IP address that presented the certificate matches the IP side of the mapping, then the peer trusts the other peer and they can establish the TLS connection.
Without using DNS, cluster address mapping is the only way to achieve this verification.
Where Does the Suggested Mapping Come From?
If the cluster is already formed, using IP addresses, and the peers already have a System host name and a DNS name configured on the page, then you have the option to automatically populate the cluster address mapping table with assumed mappings as follows:
Peer1Hostname.Peer1DNSName maps to <Peer1 Private IP address>
….
Peer6Hostname.Peer6DNSName maps to <Peer6 Private IP address>
Note |
This automatic mapping may be incorrect! If the peers' certificates do not contain these assumed FQDNs in their SAN fields, then the cluster will not form when TLS verification mode is changed to Enforce. You must check that the SANs contain the entries that you place in the peer FQDN fields. |