Skip to content
Megaport Documentation
How MCR Performs NAT

How MCR Performs NAT

Network address translation (NAT) 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

NAT is performed by the MCR at the boundary where two networks are connected. Before forwarding packets from the inner network to the outer network, 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. To create a unique session, MCR assigns a different TCP or UDP source port number to the public IP address.

To map multiple IP addresses to a single IP address, MCR NAT uses a combination of source NAT (SNAT) and port address translation (PAT).

Note

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 figure shows an MCR at the edge of the data center, privately connecting to the Azure Platform as a Service (PaaS) 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.

NAT

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.
    NAT example

  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 port address translation (PAT) and assigns the session a unique TCP or UDP source port. The destination IP and port are left intact.
    NAT example

  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 figure 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.
NAT verification

The NAT IP Address field appears to the right of the Interface IP Addresses. The NAT Source IP address is the IP address of the MCR’s outside interface, to which any packets will be translated.

Note

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 details, see Configuring Q-in-Q.

This table summarizes the supported MCR NAT configurations and use cases, indicated by a ✓. It also includes configurations that aren’t a good fit, indicated by an X.

MCR NAT Type MCR NAT Use Case
NAT Overload ✓ Connectivity to Cloud Service Providers public services ✓
Hide NAT ✓ Connectivity to SaaS and PaaS services ✓
Source NAT X Connectivity to Megaport Marketplace partners ✓
Destination NAT X Preserve the IP address space for outbound traffic ✓
Static NAT Pool X Allow for inbound access from the internet X
Dynamic NAT Pool X Routing between overlapping networks X
Last update: 2022-01-21