--- title: "Private NAT" canonical: "https://docs.aryaka.com/space/KNOW/1272774684/Private%20NAT" format: markdown --- Aryaka supports both internet network address translation (NAT) and private NAT to manage network translation needs. Internet NAT translates private IP addresses into public IP addresses for internet-bound traffic. Private NAT, also known as overlapping NAT, is used for internal, non-internet traffic, such as VPN Path Aryaka, VPN Path Internet, and cloud connectors. Private NAT is essential in environments where subnets overlap across sites or where LAN-side IPs need to be translated into unique, routable addresses. This allows traffic to flow seamlessly between sites without IP conflicts, even when using the same internal IP address ranges. By translating a private IP or subnet to a new private range before sending traffic to a remote site, private NAT enables route consistency and simplifies integration across customer networks. It also helps abstract internal IP schemes, limits subnet exposure, and ensures compatibility with LAN devices that expect a single, consistent IP. This document provides an overview of private NAT and describes how to configure and manage private NAT rules in MyAryaka. Prerequisites Private NAT is available for sites with an Aryaka Network Access Point (ANAP) and for sites that have a point of presence (POP) with Route Service Engine (RSE) enabled. Use cases The following are the three primary use cases for private NAT: Allow communication between Aryaka sites with overlapping subnets. Private NAT allows you to communicate between subnets that use overlapping private IP address ranges. For example, if your company undergoes an acquisition, you can configure private NAT to communicate between any existing sites and acquired sites that have overlapping subnets. Likewise, if your company configured non-Aryaka sites when testing SD-WAN solutions, you can configure private NAT to communicate between any Aryaka sites and non-Aryaka sites that have overlapping subnets. Hide IP addresses or subnets from remote sites. Private NAT allows you to mask IP addresses or multiple large subnets from remote sites to prevent the remote site from knowing the number of subnets and their CIDR on the local site. Converge subnets from remote sites. Private NAT allows you to converge multiple subnets from remote sites into a smaller subnet or a host IP so that the local site can advertise the smaller subnet or host IP to the external router on the LAN. Private NAT rules Private NAT occurs in the RSE—a process that runs on any number of network interfaces on an ANAP or POP. The RSE performs routing and basic firewall operations for your configured sites. Therefore, whether to use pre-NAT or post-NAT IPs and ports when configuring network services and policies depends on the NAT direction. The following sections describe the types of NAT and the traffic directions that you can configure private NAT rules for. Traffic that originates from the internet is handled by internet NAT . NAT types When you create a private NAT rule, you can choose one of the following types of translation to perform on matched traffic: Static source NAT (SNAT)—Translates the source IP address of matched traffic to a specified IP address. Static destination NAT (DNAT)—Translates the destination IP address of matched traffic to a specified IP address. Port address translation (PAT)—Translates all IP addresses and ports in a subnet of matched traffic to a single IP address or IP address range. Skip SNAT—Skips network address translation of the source IP address for matched traffic. This is typically used for testing. Skip DNAT—Skips network address translation of the destination IP for matched traffic. This is typically used for testing. Private NAT rules use 5-tuple match criteria (source IP (SIP), destination IP (DIP), source port, destination port, and protocol) to identify traffic and perform the configured address translation. Note that most private NAT rules only network address translate IP addresses. However, a rule that uses PAT as the NAT type also network address translates ports. NAT direction When you configure a private NAT rule, you must specify whether the rule applies to inbound, outbound, or bidirectional matched traffic. The following graphic displays three private NAT rules configured in MyAryaka: In this example, there is one rule configured for each traffic direction (inbound, outbound, and bidirectional). Note how both the Inbound NAT and Outbound NAT columns are filled only for the bidirectional rule. The following sections provide details about the different traffic directions that you can configure a private NAT rule to match. Inbound Inbound NAT rules apply when traffic is initiated from a remote site or cloud connector (source site) toward a local site (destination site) LAN. The inbound NAT rule must be configured on the destination site. The return traffic from the destination site to the source site is automatically translated using the NAT cache. However, because inbound NAT is unidirectional, if the destination site initiates traffic toward the source site, it does not match the inbound rule. Before private NAT rules are applied, pre-NAT IP addresses and ports are used by your configured network services such as Link Assure or Internet Link Assure policies, optimization access control lists, and QoS marking rules. After private NAT rules are applied, post-NAT IP addresses and ports are used by your configured routing and security rules. Outbound Outbound NAT rules apply when traffic is initiated from a local site (source site) toward a remote site or cloud connector (destination site). The outbound NAT rule must be configured on the source site. This rule translates the source or destination IP address before the traffic is sent to the destination site. The return traffic from the destination site to the source site is automatically translated using the NAT cache. As with inbound rules, outbound NAT is also unidirectional—if the destination site initiates traffic, it does not match the outbound rule. Before private NAT rules are applied, pre-NAT IP addresses and ports are used by your configured routing and security rules. After private NAT rules are applied, post-NAT IP addresses and ports are used by your configured network services such as Link Assure or Internet Link Assure policies, optimization access control lists, and QoS marking rules. Bidirectional A bidirectional private NAT rule allows you to create a single rule to match inbound and outbound traffic for a site. When you create a bidirectional rule, you select a NAT Type for the outbound direction and a mirrored rule is automatically configured for the inbound direction. This simplifies configuration and ensures consistency for bidirectional traffic between the sites, especially for one-to-one NAT. For example, if you configure an outbound, static SNAT rule where the source IP is 192.0.2.1/32 and the network address translated source IP is 198.51.100.1/32, a corresponding inbound, static DNAT rule is automatically created where the destination IP is 198.51.100.1/32 and the network address translated destination IP is 192.0.2.0/32. Rule evaluation When private NAT rules are applied to traffic, DNAT rules are evaluated first. The system processes the rule list top-down and applies the first matching DNAT rule, translating the destination IP accordingly. After this, SNAT rules are evaluated. For an SNAT rule to match, it must be configured to recognize the translated destination IP resulting from the DNAT rule. For both DNAT and SNAT, only the first matching rule is applied, and no further rules are evaluated. Aryaka recommends placing rules with specific prefixes (for example, /32 or /29) above rules with broader ranges (for example, /16) to ensure more granular matches take precedence. Example rules The following scenarios provide examples of private NAT rules configured in MyAryaka. The scenarios and corresponding rules included in these example are for instructional purposes only. You should configure your private NAT rules based on your organization's needs. Scenario 1: Hide local subnets from an external site In this scenario, a customer has two Aryaka sites (site A and site B) and one non-Aryaka site (an external site). Site A uses a local subnet (192.0.2.0/24) that overlaps with the existing subnet at the non-aryaka site. Site B is in the same location as the external site. The customer is able to communicate between their Aryaka sites, but traffic between site A and the external site (which is sent through site B) fails due to the overlapping IP ranges. The customer does not want to re-address site A or the external site. The following graphic displays this scenario: This would require an inbound, static SNAT rule at site B that matches traffic with a source IP of 192.0.2.0/24 and any destination IP and then network address translates the source IP to a unique IP address in a different IP range (for example, 198.51.100.0-198.51.100.255). The following graphic displays this rule configured in MyAryaka: Scenario 2: Hide an IP address In this scenario, a customer owns sister companies (A, B, and C) that need access to a web server located at one of the customer’s sites (site DC). The IP address of the web server (192.0.2.1) needs to remain hidden from the sister companies. Each sister company can be assigned a unique IP address for the web server. The customer can then create a private NAT rule for each site. For example, sister company A could be assigned the IP address 192.51.100.1 for the web server. They could then create a private NAT rule for site DC such that when company A sends traffics to the web server using the destination IP 192.51.100.1, this IP address is network address translated to the web server’s real IP address (192.0.2.1). The following graphic displays this scenario: This would require an inbound, static DNAT rule that matches traffic with any source IP and a destination IP of 192.51.100.1/32 and then network address translates the destination IP to 192.0.2.1. The following graphic displays this rule configured in MyAryaka: Scenario 3: Communicate between overlapping subnets In this scenario, a customer has two sites (site A and site B) that they want to have bidirectional communication between. However, 192.168.2.0/24 is a subnet that exists on both sites. The following graphic displays this scenario: This would require the following bidirectional NAT rules: At site A, an outbound, static SNAT rule that matches outbound traffic initiated from site A with a source IP of 192.168.2.0/24 and then translates the source IP to an IP address in the range 192.51.100.0/24. An inbound, static DNAT rule is then automatically created to allow inbound traffic initiated from site B with a destination IP of 192.51.100.0/24 and translate it to the original IP in the range 192.168.2.0/24. At site B, an outbound, static SNAT rule that matches outbound traffic initiated from site B with a source IP of 192.168.2.0/24 and then translates the source IP to an IP address in the range 10.0.10.0/24. An inbound, static DNAT rule is then automatically created to allow inbound traffic initiated from site A with a destination IP of 10.0.10.0/24 and translate it to the original IP in 192.168.2.0/24. The following graphic displays the rule for site A configured in MyAryaka: Scenario 4: Hide local subnets from remote sites In this scenario, a customer has a site (site A) with multiple local subnets in two zones (vpn 0 and vpn 1). They do not want clients on remote sites to see the subnets on site A. Traffic always originates from site A to the remote sites. The following graphic displays this scenario: This would require an outbound, PAT rule at site A that matches traffic with any source or destination IP from the source zones vpn 0 or vpn 1 and then translates the source IP to a unique IP address in a different IP range (for example, 192.0.2.1-192.0.2.6). The following graphic displays the configuration of this rule in MyAryaka: Scenario 5: Limit route advertisement on client device In this scenario, a customer has a cloud endpoint (for example, a VPC/Direct Connect gateway) connected to the Aryaka POP at an IaaS site. The IaaS site does not initiate traffic to the remote sites and expects incoming traffic from the Aryaka POP by way of the remote sites. The cloud endpoint does not have the capacity to handle the number of routes (100+) that it needs to receive from the Aryaka POP. Instead, the customer wants only a small range of IP addresses (192.0.2.1-192.0.2.6) to be routed to the cloud endpoint. The following graphic displays this scenario: This would require an inbound, PAT rule at the IaaS site that matches traffic with any source or destination IP and translates the source IP to an address in the range 192.0.2.1-192.0.2.6. The following graphic displays this rule configured in MyAryaka: Configure The Sites > Site: page enables you to configure private NAT rules for selected sites. If there is not a NAT section on the Sites > Site:< siteName > page, contact Aryaka Customer Support for assistance. When you configure a private NAT rule, you must specify whether the rule applies to inbound, outbound, or bidirectional matched traffic. Based on the direction selected, you can then choose the type of translation to perform on matched traffic—static SNAT, static DNAT, PAT, or skip NAT. Private NAT rules use 5-tuple match criteria (source IP, destination IP, source port, destination port, and protocol) to identify traffic and perform the configured address translation. See the Configure private NAT rules topic for details about creating private NAT rules in MyAryaka. Monitor The SD-WAN flow logs in MyAryaka include the following private NAT details: Pre-NAT Source IP Natted Source IP Pre-NAT Source Port Natted Source Port Pre-NAT Destination Port Natted Destination Port Pre-NAT Destination IP Natted Destination IP See the SD-WAN flow logs topic for details about SD-WAN flow logs and how to navigate to the page in MyAryaka. In this topic Related topics Configure private NAT rules Internet NAT