NAT Policies

• Log into Console.

• Click Multi-Cloud Network Connect.

Figure: Console Homepage

• Select Manage > Networking > NAT Policies.

Figure: NAT Policies

• Click Add NAT Policy.

Figure: NAT Policy Form

• In the Name field, enter the name for the new NAT policy. Optionally add labels and a description.

• In the Applies To section, Site is automatically selected since it is the only current option.

  • Select a site from the Site drop-down menu for which the NAT Policy is being applied.
  • You can have the policy apply to multiple sites by clicking the Add Item button in the sites list. NAT Policies are supported for multiple sites simultaneously.

• In the Rule section on the NAT Policy form, click Configure to create a list of rules.

• Click Add Item to create the first rule.

Figure: NAT Policy Rule Form

• In the Name field, enter the name for the new NAT policy. Optionally add labels and a description.

• Select Yes or No from the Enable drop-down menu to turn this rule on or off. Generally, rules are always enabled except when testing/troubleshooting or in situations where you might plan for NAT configurations to only be applied during maintenance windows.

• In the Scope section, select the ingress point at which to apply the rule:

  • Cloud Connect: Cloud Connects instantiate a GRE Tunnel on the CE that connects to the TGW. Thus, by selecting the Cloud Connect you are expecting the traffic to arrive on the particular GRE Tunnel from the TGW. You can select one Cloud Connect at a time.
  • Interface: Select an ethernet interfaces that is available on the CE. You can select one interface at a time. The NAT rule will apply to the packet coming from that interface.
  • Segment: This is useful in situations where the interesting traffic can arrive on multiple interfaces in the same segment. Thus, instead of selecting a single interface and repeating the NAT rules, you can select a segment and the result is that the rule is applied to all interfaces that belong to that segment. Do not select Segment for your scope if your Action is set to Virtual Subnet NAT.
  • Virtual Network: Prior to Segmentation, Global Networks were the main construct to place different sites in the same VRF. Thus, this option is meant to apply NAT on those legacy site types that utilize virtual networks. The NAT rule will apply to the packet in the virtual network. Do not select Virtual Network for your scope if your Action is set to Virtual Subnet NAT.

• The Match Criteria section allows you to specify which packets should go through NAT processing.

Figure: NAT Policy Rule Form

• Standard options:

  • Source IP: Click Add Item and enter an IP prefix for each source IP you want included.
  • Destination IP: Click Add Item and enter an IP prefix for each destination IP you want included.

• Advanced options (Enable the Show Advanced Fields toggle):

  Note: These advanced match options are not supported for the case of overlapping CIDRs where the NAT Action is set to Virtual Subnet NAT.

  • Protocol: Select a protocol to match from the drop-down list. Only All or a single protocol can be selected.
  • Source Port: Select Port or Port Range to match specific port(s). The default is No Port match.
  • Destination Port: Select Port or Port Range to match specific port(s). The default is No Port match.
  • Destination Network: If there is a network connector, select Destination Virtual Network and then select the Virtual Network Reference. If there is a segment connector, select Destination Segment and then select the Segment. If there is neither, then Destination Network does not need to be configured.
    • The Destination Network option will only be used when the traffic is destined to:

      • Internet: This is egress traffic from networks behind the CE to the Internet. In this case the destination network will be set to Virtual Network, and you specify the SLO network. This is the most common usage for the destination network.

      • SLI: This is only used when the traffic is destined to the Site Local Inside (SLI) network.

      Note: In this release, these virtual networks need to be created to be able to reference them, thus you will need to navigate to Manage > Networking > Virtual Network and then add a Virtual Network of type Site Local Outside or Site Local Inside. With the virtual network for SLO or SLI created, then we can reference those in the NAT configuration.

• Configure the Action section to specify what happens when the match criteria above is satisfied (a match occurs).

Figure: NAT Policy Rule Form

• In the NAT field, select the type of action you want to take:

  • Virtual Subnet Nat: Enter the virtual subnet NAT CIDR. Virtual Subnet NAT is static NAT that does a one-to-one translation between the real source IP CIDR in the policy and the virtual CIDR in a bidirectional fashion. The range of the real CIDR and virtual CIDRs should be the same (e.g. if the real CIDR has the CIDR 10.10.10.0/24, the virtual CIDR has 100.100.100.0/24. This is the best option for overlapping CIDRs. One key advantage of Virtual Subnet NAT is that it preserves the host bit during translation, making it easier to identify the original hosts in the flow. For instance, if the original subnet is 10.10.10.0/24 and it's translated to 100.100.100.0/24, a host with the address 10.10.10.5 will be translated to 100.100.100.5, preserving the .5 host bit. Additionally, the CE advertises these virtual subnets to other CEs and third-party devices to ensure return traffic is correctly routed to the corresponding nodes.

  • Source Nat: Use this to translate the source address of the matching packet (for example, when you want to mask the real IP address of a particular host or network). Note that with Source NAT, traffic can only be initiated from the host or networks that are being Source NAT and not from the remote networks since Source NAT is unidirectional in nature. Select the type of pool you want to use:

    • SNAT Pool: Use the Add Item buttons to enter the pool members in either IPv4 or IPv6 format. These pools can reference a single /32 address or be much larger. Note that for a 3-node site, the pool must contain at least 3 addresses to ensure each node has an IP address from the pool for Source address translation. For larger pools, such as /24, the CE automatically allocates subsets to multiple nodes without user intervention. Additionally, CE nodes ensure these per-node subnets are advertised to other CEs and third-party devices to route return traffic correctly. For IPv6, this functionality must be enabled for the Tenant.

    • Cloud Elastic IP Object: Use the Add Item buttons to enter one or more cloud elastic IP references. This is useful for example when you want a particular workload, VPC, subnet, or Cloud Connect to egress with one or more specific public IP addresses. See Create a Cloud Elastic IP to create a new one.

• Click Apply to save the rule.

• Click Add Item in the Rule list to add more rules.

Note: When viewing the list of rules for your NAT Policy, you can reorder your rules by dragging the 6-dot handle (to the left of the rule) to a new position.

• Click Apply when finished adding rules to the list.

Click Save and Exit to create the NAT policy.

• Log into Console.

• Click Multi-Cloud Network Connect.

Figure: Console Homepage

• Select Manage > Networking > Cloud Elastic IPs.

Figure: Cloud Elastic IPs

• Click Add Cloud Elastic IP.

Figure: Cloud Elastic IP Form

• In the Name field, enter the name for the new Cloud Elastic IP object. Optionally add labels and a description.

• Select a site from the Site Reference drop-down menu that will have the elastic IP(s).

• In the Elastic IP Count Per Node field, enter the number of required elastic IPs per node.

• Click Save and Exit.