Skip to main content
conserves IPv4 address space by translating the unregistered private IP addresses used for an organization’s private inner network into a single registered public IP address. This single public IP address is then used to connect to external networks, like the internet. This topic describes how NAT on the MCR is designed to specifically support public peering types to Cloud Service Providers.

​
Many-to-one NAT using different ports

MCR supports Overload NAT, also known as Source Overload NAT or NAT Overload, which is a form of many-to-one NAT. It works as follows:
  • Source NAT (SNAT) — Translates multiple private IP addresses to a single public IP address.
  • Port Address Translation (PAT) — Assigns unique source ports to ensure that each connection remains distinct.
This configuration supports egress traffic (outbound connectivity) to Megaport Marketplace partners and other external networks, such as the internet or cloud services. The MCR commonly performs NAT at the boundary where two networks are connected. For example, before forwarding packets from the inner network to the outer network, the MCR translates the private, non-unique IP addresses to a single, globally unique public IP address. This many-to-one translation allows the MCR to advertise only one IP address to the outside world while hiding multiple private source IP addresses behind the IP address of the MCR interface. While a typical use case involves translating private IP addresses on the inside network to a public IP address on the outside network, this is not a strict requirement. The MCR can translate any IP address—private or public—on either interface as required.
NAT on the MCR is similar to Cisco’s NAT overload or Checkpoint’s Hide NAT functionality.
MCR keeps track of each IP address translation and port assignment in a NAT table that can handle thousands of concurrent translations. When a port is no longer in use, MCR releases it and returns it to the pool of available ports. This image shows an MCR at the edge of the data center, privately connecting to the Azure Platform as a Service () with a Virtual Cross Connect (VXC) into Azure public peering, known as Microsoft Peering. Because Microsoft will only accept public IPv4 addresses through Microsoft Peering, the MCR translates the private IP addresses to public addresses using NAT. The MCR provides the added benefit of using Megaport’s autonomous system number (ASN) and publicly registered IP space for this connection.

​
MCR NAT example

In this example, MCR is logically sitting between a customer’s data center (10.100.0.0/16) and Azure (West US 13.100.0.0/16). Packets destined for 13.100.0.0/16 are sent from the data center to the MCR.
  1. The data center sends a packet with a source IP of 10.100.20.10 and a destination IP of 13.100.12.136 toward the MCR.
  2. MCR receives the packet on its inside interface. Upon egress, MCR performs a SNAT to translate the source IP address (10.100.20.10) to the local IP address of its outside interface (117.18.84.113). To create a unique session, MCR also performs a PAT and assigns the session a unique TCP or UDP source port. The destination IP and port are left intact.
  3. When Azure receives the packet, it has a source IP of 117.18.84.113. Azure forwards the packet to the destination 13.100.12.136 and replies back to the source at 117.18.84.113.
  4. Assume that Azure receives another packet from MCR with a source IP of 10.100.5.16 and a destination IP of 13.100.14.27. MCR performs a SNAT to the same IP address of 117.18.84.113. The only difference is the TCP/UDP source port that has been automatically assigned by MCR.

​
Verifying the NAT assignment

MCR automatically configures the VLAN IDs used for private and public peering after you configure the peering type. When provisioning VXCs from the MCR to a service provider, MCR configures the private peering with VLAN 100 and the public peering with VLAN 200, by default. This image shows MCR with a VXC connecting to Azure. During the initial VXC configuration, both Private and Public Microsoft peering types were selected. For this configuration, MCR automatically configured VLAN 100 to support private peering and VLAN 200 to support the public Microsoft peering. The Network Address Translation (NAT) field appears to the right of the Interface IP Addresses field. The NAT Source IP address is the IP address of the MCR’s outside interface, to which any packets will be translated.
When multiple Azure VXCs on an MCR populate the same VLAN 100 tag (private peering) and the same VLAN 200 tag (public peering), MCR manages the 802.1Q tunnel, also known as a Q-in-Q tunnel, for each Azure VXC that terminates on the MCR. Each Azure VLAN will still be a separate logical interface. For more information, see Configuring Q-in-Q.
Last modified on August 21, 2026