Network Requirements
This page lists every network endpoint and port that an IoT Edge device of Datalogic Connect needs, with the component that uses each one and when. The endpoints fall into three groups: the cloud endpoints the gateway reaches for its whole life, the endpoints the installation script contacts once, and the local ports the field devices use to reach the gateway on the store network. What the gateway runs is described in IoT Edge Gateway.
On Windows the IoT Edge runtime runs inside the EFLOW virtual machine (VM), which has its own static IP address on the host subnet through a Hyper-V external switch bound to a physical adapter. Firewall, proxy and DNS rules must cover the address of the VM, not only the Windows host.
Cloud Endpoints (Edge Device → Internet)
The IoT Edge runtime and the Connect modules reach these endpoints from the installation onward. All connections are outbound: the gateway needs no inbound connection from the Internet.
| Endpoint | Port | Protocol | Notes |
|---|---|---|---|
*.azure-devices.net | 8883, 443, 5671 | MQTT TLS, AMQPS, or HTTPS | Azure IoT Hub. edgeAgent receives the deployment manifest from it after enrollment; edgeHub uses it as upstream to send diagnostic data and device reports and to receive cloud commands. |
global.azure-devices-provisioning.net | 443 | HTTPS | Azure Device Provisioning Service (DPS). The installation script writes it as the global_endpoint of /etc/aziot/config.toml, together with the Scope ID and the symmetric key of the Edge Device, and the runtime provisions the gateway against it. The Windows installer stops if the EFLOW VM cannot resolve this name. |
*.blob.core.windows.net | 443 | HTTPS | Azure storage: file upload and Docker image pull. |
crsolinfraprodeuw.azurecr.io | 443 | HTTPS | Datalogic container registry. The installation script pins the bootstrap image crsolinfraprodeuw.azurecr.io/azureiotedge-agent:1.5.40 in config.toml; the runtime pulls the module images of the deployment manifest from the same registry after enrollment. The Windows installer waits up to 5 minutes for edgeAgent to run and stops if the image cannot be reached from the EFLOW VM. |
crsolinfraprodeuw.westeurope.data.azurecr.io | 443 | HTTPS | Data endpoint of the same container registry, contacted during the image pull. Allow it together with the registry name. |
*.azureiotcentral.com | 443 | HTTPS | Device Smart Enrollment: the DeviceHubModule enrolls the devices connected to the gateway with the SAS Smart Enrollment Key of the organization, delivered in the deployment manifest. |
The names above must resolve from the device. The Windows installer checks it before applying the IoT Edge configuration: it queries global.azure-devices-provisioning.net from inside the EFLOW VM with the DNS servers passed through -DnsServer, or inherited from the host adapter when the parameter is omitted, and exits if the name does not resolve. The Ubuntu installer makes no such check: a wrong DNS configuration shows up only when the runtime fails to provision, see Verify the installation.
If your device is behind a corporate firewall, ensure all outbound endpoints above are whitelisted. The IoT Edge runtime will automatically select the best available upstream protocol (MQTT TLS on 8883 or HTTPS on 443).
Installation Endpoints
The installation script contacts these endpoints once, to download the container engine and the IoT Edge runtime. They are not needed after the script has run, and neither script downloads anything else.
| Endpoint | Port | Protocol | Platform | Notes |
|---|---|---|---|---|
packages.microsoft.com | 443 | HTTPS | Ubuntu | Microsoft package repository. The script downloads packages-microsoft-prod.deb for the Ubuntu release in use (22.04 or 24.04), registers the repository and installs moby-engine and aziot-edge from it. |
Ubuntu package mirrors configured in /etc/apt | 80, 443 | HTTP, HTTPS | Ubuntu | The script runs apt-get update and apt-get upgrade before installing the IoT Edge packages, and installs the docker.io package from these mirrors when moby-engine is not available from the Microsoft repository. |
aka.ms, download.microsoft.com | 443 | HTTPS | Windows | Azure IoT Edge for Linux on Windows (EFLOW) 1.5 LTS installer. The script downloads the MSI from the aka.ms/AzEFLOWMSI_1_5_LTS_X64 or aka.ms/AzEFLOWMSI_1_5_LTS_ARM64 short link, which redirects to the Microsoft download site, verifies its Authenticode signature and installs it with msiexec. |
On Windows the download happens on the host, before the EFLOW VM exists. For the parameters that set the adapter of the external switch, the VM address and the DNS servers, see Run the installer.
Local Inbound Ports (Field Devices → Edge Device)
The following ports must be reachable from Datalogic field devices or AladdinSDS on the local network. On Windows, the address to reach is the static IP of the EFLOW VM, the one entered as Device IP when the Edge Device was created.
| Port | Protocol | Service | Used by |
|---|---|---|---|
1883 | MQTT (plain TCP) | NanoMQ | PCs, POS systems, HOST-type devices: a POS running AladdinSDS connects here by default, as does a mobile computer enrolled without an enrollment token |
9883 | MQTT over TLS (mTLS) | NanoMQ | Datalogic devices with a client certificate issued by the gateway, today the mobile computers enrolled with an enrollment token |
8090 | HTTP | StorageModule | Field devices downloading firmware and configuration files or uploading logs |
8098 | HTTP | ProvisioningModule | Field devices requesting X.509 certificates with an enrollment token, before their first connection on port 9883 |
Neither installation script changes the host firewall:
- Ubuntu: if
ufwor another host firewall is active, allow the four ports above on the interface facing the store network. - Windows (EFLOW): the VM sits behind the Hyper-V firewall. Add the inbound Hyper-V firewall rules for TCP ports
8098and9883as described in Add the inbound firewall rules, before enrolling mobile devices with an enrollment token.
An enrollment without a token needs only port 1883. An enrollment with a token also needs port 8098, for the certificate, and then port 9883, for the connection. If a firewall blocks them, the token-based enrollment fails while the unauthenticated one on port 1883 still succeeds.