Firewalls (and the IT security people that maintain them) are generally concerned with protecting a location’s Local Area Network from unauthorized use – both from traffic coming at the network from the outside world, and traffic from within the local area network going outward. A Remote Management-capable Digi product falls into the latter category, because the Digi device creates an outbound TCP socket connection to the Device Cloud or Remote Manager server. This EDP (easy device protocol) socket connection is tunnel through which data gets pushed from your Gateway to to the Device Cloud, so that data can be accessed from anywhere in the world.
The following article describes:
- The IP socket connections used when a Digi RF Gateway,TransPort Router, or edp-capable device (using Digi Cloud Connector) makes a Remote Management connection to Device Cloud or Remote Manager
- How to determine the IP address in use for a given Device Cloud or Remote Manager DNS name
Locations where it is likely that Firewall Rules will be needed:
Those who are trying to connect to Device Cloud or Remote Manager from a location which has strict outbound firewall rules will especially need the guidance found within this article. Some likely examples for this type of network security environment include: Government offices/buildings and institutions, Schools, Universities, and some Businesses (especially ones that do government contract work).
What network port(s) does a Gateway or Connect-capable device use to connect to Device Cloud?
By default, the TCP and/or UDP port(s) your Device Cloud-capable Gateway or device uses to connect with Device Cloud will depend in part on the age/default configuration of your Gateway, the device’s configuration, as well as the particular model.
TCP Port 3197: The outbound EDP/non-SSL (non-secure) socket connection from NDS-based products like the ConnectPort X2 / X4 / X5 / X8 Gateways, and ERT/Ethernet Gateway (especially if the product hasolder firmware), which may still be configured to create an un-encrypted Device Cloud socket connection.
Note: If possible, the firmware of older products should be updated so that the Device Cloud configuration settings can changed to use of SSL socket connections into the Device Cloud instead (see next entry below).
TCP Port 3199: The outbound EDP/SSL (secure) socket connection from NDS-based products like the ConnectPort X2 / X4 / X5 / X8 Gateways, and ERT/Ethernet Gateway with newer firmware which are configured to create a secure SSL socket connection into Device Cloud. Required on ALL Linux-based Gateways, examples: XBee Gateway ZB andConnectPort X2e for Smart Energy. Can also be required if the Device Cloud account is configured to accept SSL connections only (new Device Cloud option as of version 2.16)
UDP Port 53: Outbound DNS (Domain Name Service) name recognition service, i.e. translates the my.devicecloud.com name for Device Cloud connectivity.
Note: DNS service is not a requirement. If access to DNS service is not allowed or possible from your network, the device’s remote connectivity address would need to use the IP address of my.devicecloud.com (188.8.131.52), rather than the DNS name itself (see below under What IP address is needed for outbound Firewall rule(s)? for more details).
UDP Port 123: The outbound socket connection to an NTP (time) server is required for ALL Linux-based Gateways such as the XBee Gateway and ConnectPort X2e, as well as gateways and devices configured for NTP time management.
Important Note for all XBee and ConnectPort X2e Gateways (and Gateways configured for NTP Time Management)
The XBee Gateway and ConnectPort X2e are Linux-based gateways which require outbound access to UDP port 123 (NTP), in order to generate the secure (SSL) TCP socket connection into Device Cloud. Any Gateways which are configured for NTP time management will have this requirement as well, since the Gateway connects to an NTP server in order to to keep an accurate date/time.
If your XBee (or CP-X2e) Gateway is added to your Device Cloud account but never shows up in a Connected state, check to ensure that outbound NTP access is available for the Gateway through your local network Firewall. ConnectPort X2 and X4 gateways would still connect to Device Cloud (assuming TCP port 3199 isn’t blocked), but the Gateway might show an epoch 1970-based date/time if no other Time Sources are configured.
What IP address is needed for outbound Firewall rule(s)?
The best way to determine that is to do an nslookup of the DNS name for the Remote Management server you want your device(s) to connect to. As of the date of this article (6/16/2015), here is how this looked from my Windows 7 commandline (Start – Run – CMD) prompt when doing nslookup of our various Remote Management and NTP ring servers:
Digi Device Cloud and Remote Manager device connectivity address:
Past Device Cloud connectivity addresses which may still be in use on devices (all device configurations should be updated to use of the my.devicecloud.com address, then re-connected to the server at the new address):
Digi Primary NTP Time Server Ring addresses:
Addresses: 184.108.40.206, 220.127.116.11
Secondary/Tertiary NTP Time Server addresses for pool usage:
Deprecated NTP/Time server addresses which may still be in use on devices (all devices should be updated to use time.devicecloud.com within their configuration):
Making the Firewall Rules:
If the IP address of the DNS name ever changes (before this article is updated to reflect it), a Windows CLI command can be used to determine the IP address of our server:
The Name and Address fields will be the DNS name and IP address for the Remote Management or Time server listed. Your firewall rule will need to allow access for the appropriate network port used based on your Gateway’s Device Management configuration, as well as UDP port 123 if NTP Time Management is in use.
Important Note regarding deprecated DNS names:
If your Gateway is configured to use an idigi.* or etherios.* DNS name, it should be re-configured to use the my.devicecloud.com url at your earliest convenience. You will need to create firewall rules for all IP addresses/ports used, for all Remote Management and Time (NTP) DNS server names used within your device.
Cloud services can be used for applications built around Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS).
Digi International has a platform called iDigi. iDigi is a cloud platform for both device network management and for data management. The iDigi Device Cloud is designed using a high-availability architecture, with redundancy and failover characteristics. It is a highly scalable system that can host single units to tens of thousands of Digi devices. It also has web services APIs for secure application integration and data messaging. iDigi device clouds are located in Chicago and in London and you can select to which cloud your data is subscribed.
Device management also include the ability to send commands to remote devices. Standard web service calls are available to manage traditional device settings. An optional Server Command Interface / Remote Command Interface (SCI/RCI) mechanism is available for any custom device or application commands that may be required.
iDigi Manager Pro is a pay-as-you-go model, starting at $1.59 per registered device, per month. Sending data to and from the iDigi Device Cloud is billed on a transactional basis and are available at different usage levels. Data is managed through iDigi, which means that iDigi provides a collection point of data. iDigi is not a (long-term) data storage solution–Digi Dia data is stored for 1 day, and iDigi files are stored for 7 days.
Unlike the ConnectPort WAN, the serial ports on the standard builds of the Digi Transport line are DTE not DCE serial, this means that a null modem cable should be used instead of a cross-over cable.
Null modem is a communication method to connect two DTEs (computer, terminal, printer etc.) directly using an RS-232 serial cable. The name stems from the historical use of the RS-232 cable to connect two teleprinter devices to modems in order to communicate with one another; null modem communication was possible by instead using RS-232 to connect the teleprinters directly to one another.