There are a variety of hostnames (also referred to as FQDNs) that Mapped needs whitelisted in order for our gateway to function properly. There are some legacy FQDNs that are needed for older gateways, and a set of new FQDNs for all current and future gateways. In many cases, security and IT teams want to know the purpose of each hostname and the kinds of traffic involved.

To help cover that need, here is the complete list of all FQDNs with descriptions:

Current FQDNs for new gateway installations

Mapped GraphQL API

Hostname	Port	Transport Protocol	Traffic Direction	Customer Data	Use
api.mapped.com	443	TLS 1.3/HTTPS	↕️	✅	Edge connector configurations are pulled from here

Observations and Control

Hostname	Port	Transport Protocol	Traffic Direction	Customer Data	Use
d2c.edge.mapped.com	443	TLS 1.3/WebSocket	⬆️	✅	Observations receiver for discovered devices, points, and ongoing timeseries data from those points and devices
c2d.edge.mapped.com	443	TLS 1.3/WebSocket	↕️	✅	Push server for control commands (new connector installed, config updated, restart application, etc) and CnC, if enabled

OS-Level Control, Logging, and Monitoring

Hostname	Port	Transport Protocol	Traffic Direction	Customer Data	Use
api.mgmt.edge.mapped.com	443	TLS 1.3/HTTPS	↕️	❌	Management API server, used to fetch the core device/platform configuration and periodically check for OS/container updates and send metrics (CPU, memory, temperature, etc)
cloudlink.mgmt.edge.mapped.com	443	OpenVPN/TLS 1.3	↕️	❌	Control channel - immediate container updates, host OSs, reboot, shutdown, metrics retrieval (CPU, memory, temperature, etc)
delta.mgmt.edge.mapped.com	443	TLS 1.3/HTTPS	⬇️	❌	Delta (partial) OS-level updates for Mapped VMs and hardware
logs.mgmt.edge.mapped.com	443	TLS 1.3/HTTPS	⬆️	❌	Mapped UG OS-level log receiver
registry.mgmt.edge.mapped.com	443	TLS 1.3/HTTPS	⬇️	❌	Container registry for Mapped UG edge applications
s3.mgmt.edge.mapped.com*	443	TLS 1.3/HTTPS	⬇️	❌	Backing storage for the container registry and OS-level delta updates; uses the S3 protocol, but is hosted by Mapped, not AWS's S3

Application-Level Logging and Monitoring

Hostname	Port	Transport Protocol	Traffic Direction	Customer Data	Use
api.telemetry.edge.mapped.com	443	TLS 1.3/HTTPS	⬇️	❌	Log/metrics configuration
logs.telemetry.edge.mapped.com	443	TLS 1.3/HTTPS	⬆️	✅	Log receiver
process.telemetry.edge.mapped.com	443	TLS 1.3/HTTPS	⬆️	❌	Metrics receiver - CPU usage/memory/network throughput/polling counts/etc

Legacy Observations and Control (in use but being phased out for c2d/d2c)

Hostname	Port	Transport Protocol	Traffic Direction	Customer Data	Use
mapped-iot-prod.azure-devices.net	443	TLS 1.3/HTTPS	↕️	✅	Edge discoveries and timeseries data receiver
global.azure-devices-provisioning.net	443	TLS 1.3/HTTPS	⬇️	❌	Device provisioning service

Legacy FQDNs used by older gateways

Hostname	Use
datadog-api.mapped.com	Previous method for log processing
datadog-process.mapped.com	Previous method for log processing
datadog-logs.mapped.com	Previous method log processing
hosted.mender.io	Previous method for gateway management
hosted-mender-artifacts.s3.amazonaws.com	Previous method for gateway management
*.balena-cloud.com	Previous method for gateway management
mapped-iot-prod.azure-devices.net	Edge discoveries and timeseries data receiver
global.azure-devices-provisioning.net	Device provisioning service

Mapped Cloudlink

What is the Mapped Cloudlink connection?

The Mapped gateway establishes an outbound OpenVPN connection from the Mapped gateway (hardware/VM/docker) to Mapped’s cloud over TCP port 443. We call this connection “Cloudlink”. Mapped uses Cloudlink to control the device state (e.g. device reboot, device shutdown, service(s) restart, etc.)

Why does the Mapped gateway use OpenVPN for Cloudlink?

Currently, Cloudlink uses OpenVPN as an underlying technology to achieve device state control, but this is subject to change as we implement better technology, which is why we just refer to this as “Cloudlink”. We are actively working to transition Cloudlink from OpenVPN to a standard WebSocket, however this change will not be deployed until Q1 2025, as it requires significant testing and careful coordination among the Mapped gateways deployed in the field.

How does the Mapped UG establish its Cloudlink connection?

As mentioned above, devices only connect outbound to Cloudlink and all traffic over the Cloudlink is encrypted with TLS. Cloudlink disallows device-to-device traffic and prohibits outbound traffic to the Internet. If a device were compromised, this ensures that it cannot contaminate another device. To achieve this, the Cloudlink service is configured to run with iptables default FORWARD policy set to DROP, and we do not enable OpenVPN --client-to-client config option server side. This means there is no way for traffic between clients to traverse the interface(s).

OpenVPN uses a lightweight protocol to wrap a mutually authenticated TLS 1.3 connection. This lightweight protocol splits packets into control and data streams, over a single link. The mutual authentication means that both sides authenticate the other - the Mapped gateway validates the server’s identity certificate to ensure it is talking to a real Mapped Cloudlink server, and the Mapped Cloudlink server validates the Mapped gateway's identity to ensure it is a real Mapped gateway.

Do I need to allow any traffic inbound on my firewall for this Cloudlink connection?

No, the Cloudlink connection is established from the Mapped gateway to Mapped’s cloud, all traffic goes outbound via TCP on port 443 – no inbound connects made, and thus your firewall does not need to permit any inbound traffic.

Does the Cloudlink connection allow remote access to my network?

When enabled by the customer through the Mapped Console, as shown in the screenshot below, access is granted to a subset of Mapped employees to enable support and device troubleshooting. Mapped employees access devices only with permission from the customer – and that permission is always time limited to ensure it shuts off automatically.

What happens if the Mapped gateway is unable to establish the Cloudlink connection?

When the Mapped gateway is unable to establish the Cloudlink connection, the gateway falls back to polling the Mapped cloud for new gateway updates at a regular interval (15 minutes). Additionally, the gateway will regularly report CPU, memory, disk usage, and temperature to the Mapped Cloud. While Mapped still has the ability to roll out software updates, we are unable to remotely start/stop services, reboot, or shutdown the gateway. Additionally, Mapped is unable to provide remote troubleshooting through the support access feature. Once a Mapped gateway is up and running in a building, these tasks are rarely needed; on the rare occasion they are, Mapped’s response will be delayed as it will require either the cooperation of someone on site, or Mapped to schedule a site visit.

What types of network security systems can inadvertently block the Cloudlink connection?

Enterprise network security systems that tend to block OpenVPN connections running on TCP port 443 by detecting that it is not a normal TLS connection typically include:

• Next-Generation Firewalls (NGFWs): Advanced firewalls like Palo Alto Networks, Fortinet, Barracuda Networks, or Cisco ASA with Firepower often have deep packet inspection (DPI) capabilities. These firewalls can analyze the packet payload and distinguish between genuine HTTPS/TLS traffic and OpenVPN traffic even when it runs over TCP port 443.
• Intrusion Detection and Prevention Systems (IDS/IPS): Systems like Snort or Suricata, when configured with appropriate rules, can detect OpenVPN traffic by analyzing the packet structure, even if it's running over a commonly used port like 443.
• Application Layer Gateways (ALGs): Some enterprise routers and firewalls have ALGs that can inspect traffic at the application layer and identify non-standard uses of protocols, such as using OpenVPN over TCP 443 instead of HTTPS. Some example systems include Cisco ASA/ISR series, Juniper SRX, SonicWall, HPE/Aruba, and MikroTik RB.
• SSL/TLS Inspection Proxies: Devices that intercept and inspect SSL/TLS traffic, such as Blue Coat ProxySG, Zscaler, A10 Thunder SSLi, Sophos XG, McAfee Web Gateway, and Cisco WSA/Umbrella/ASA/FTD can detect anomalies in the handshake or traffic pattern that do not conform to standard HTTPS and flag or block OpenVPN connections.

These systems rely on DPI, traffic pattern analysis, or specific detection rules to identify and block OpenVPN connections on TCP port 443, even though this port is typically used for HTTPS traffic.

Should I block the Mapped gateway's Cloudlink connection?

Blocking Cloudlink is certainly an option, but it's important to note that Mapped has implemented robust security measures to ensure that the Cloudlink connection is highly secure. Cloudlink is designed with strong encryption, mutual authentication, and strict traffic controls to safeguard the connection and prevent unauthorized access. Moreover, it only allows outbound connections over TCP port 443, with no inbound traffic, and can’t be used as a route to the internet, ensuring that it fits within typical enterprise firewall configurations. While we are transitioning to a WebSocket-based solution in early 2025, Cloudlink currently provides secure and reliable device management and support capabilities. Blocking it could disrupt critical device management functions and slow response times from Mapped Support, so it’s important to weigh this carefully before making a decision.