Skip to main content

Interconnected Devices with Internet Access via NAT Gateway

Networking Architecture (Scenario 4) - Implementing network connectivity where devices are connected to each other, and Internet access is routed through a NAT gateway

Interconnected Devices with Internet Access via NAT Gateway

On this page

In this scenario:

  • Some devices are connected to the Internet
  • Most devices are not connected to the Internet
  • One or more Internet-connected devices function as NAT gateway(s)
  • All other devices communicate with the Internet via the NAT gateway(s)
  • Devices communicate with each other via standard Equinix Metal networking
  • Devices use private IPs allocated by Equinix Metal
  • Devices may be all in one metro or in multiple metros

General layout

This is a classic protected set of devices, where they all can communicate with each other, but do not have public IP addresses; only devices with public IP addresses can communicate with the Internet.


Private devices can communicate with each other. They can communicate with the Internet solely through a gateway providing Network Address Translation (NAT).

Comms via NAT

Each normal device receives only a private IPv4 address. In addition, a few devices dedicated to routing traffic to and from the Internet also receive a public address. Each device is on its own private subnet, to which just the device and its upstream router are connected.

Both the public and the private addresses are provided and managed by Equinix Metal.

To provide this architecture:

  1. Deploy each private device with only a private IP address; we call these "private devices".
  2. Deploy one or more devices to act as NAT gateways, giving them both public and private IP addresses; we call thse "router devices".
  3. Assign private IPv4 addresses from management subnets as Elastic IPs on the router devices.
  4. On the router device(s), deploy NAT software to route packets between the private addresses and public Internet, using NAT, and vice-versa.
  5. Configure the routing tables on the private-only devices to use the private Elastic IPs as their default routes.
  6. Optionally, request a public Elastic IP and assign it to the router devices, if you need to respond to incoming requests, or want consistent source addresses on outbound requests.

Multiple Metros

If you wish to deploy devices in multiple metros while enabling communications between them, you have several options.

First, you can deploy the devices as-is, and use the public IP addresses for public hosts, and NAT for the private ones to communicate between them. As with the default public architecture, this may be sufficient if the communications use publicly available services anyways, such that they already are secure. It may also be sufficient if the communications need not be secure.

However, if the private devices need to communicate directly with the private devices in the other metro, then this will not work.

Second, you have the option of installing your own VPN.

  1. On one of the router devices in each metro, install VPN services, such as openvpn or StrongSWAN. You may want to designate one or more of these router devices as exclusively for the purpose of VPN, i.e. a "VPN Concentrator".
  2. Create a VPN tunnel between the two "VPN devices" over the Internet.
  3. Configure routing on each device, such that the addresses for the private range in the other metro is via the local VPN device.

Inter-metro VPN

Finally, and most simply for a secure channel, you can enable Backend Transfer.

Inter-metro Backend Transfer

If you have backend transfer enabled, then any device in any metro can communicate directly with any device in any other metro, using the private IPs. This includes your NAT Gateway router devices. If each metro also will have Internet connectivity, then you need to decide if you will have router devices in each metro, or just in one or more metros, through which Internet traffic from the other metros will route.

Egress via Backend Transfer

Unless there are other considerations, we recommend deploying one or more "router devices" in each metro. Otherwise, traffic for the Internet from metros without "router devices" will need to transit to other metros, those with "router devices", to communicate with the Internet. This will have a negative impact in terms of latency and cost.

Egress per Region

Last updated

15 May, 2024



Subscribe to our newsletter

A monthly digest of the latest news, articles, and resources.