This article assumes you've already read through and tried the steps in these two knowledgebase articles:
1. How do I migrate my Digi product to a different Device Cloud server?
2. HOW TO: Configure an ERT/Ethernet Gateway, ConnectPort X RF Gateway, or Digi Connect/ConnectPort Cellular Router to Connect to a Device Cloud server (and/or Troubleshoot the Device Cloud connection from the Gateway CommandLine Interface (CLI))
but it still shows as disconnected. How do I troubleshoot and fix this issue?
If you haven't gone through the articles above, the present article may not resolve you're issue because it is a remote possibility you'd be affected by this (the basic stuff is covered in the other articles). For those who are in locations with strict outbound firewall rules, this article will get you connected to the Device Cloud.
Firewalls (and IT security people in general) are concerned with two things to protect a location's Local Area Network from unauthorized use - traffic coming at the network from the outside world, and what traffic going on inside the network is going out. Your Device Cloud-capable Gateway will fall into this latter category, as it needs to tunnel its way up to the Device Cloud so you can access your data, whatever it may be.
What ports does it use?
By default, the TCP and/or UDP port(s) your Device Cloud-capable Gateway uses to tunnel up to the Device Cloud will depend in part on the age of your Gateway, as well as the particular model.
NDS-based Gateways (ConnectPort X2, X2 for Smart Energy, X4, X5, X8, ERT/Ethernet Gateway) with older firmware versions used outbound TCP port 3197 to create a connection into the Device Cloud, but NDS-based Gateways with newer firmware (and ALL Linux-based Gateways like the ConnectPort X2e) use outbound TCP port 3199 to create an SSL (secure) Device Cloud connection instead.
Important Note for all ConnectPort X2e (or other ConnectPort gateways which use NTP Time Management):
The ConnectPort X2e Linux-based Gateways (as well as any other ConnectPort gateway which has NTP configured as a Time Management type) require access to outbound UDP port 123 in order to access NTP time services and generate their Device Cloud connection. If your CP-X2e 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 do I need to use for my outbound Firewall rule(s)?
The best way to determine that is to do an nslookup of the DNS name for the Device Cloud server you want your Gateway to connect to. As of the date of this article (10/21/2013), here is how this looked from my Windows 7 commandline (Start - Run - CMD) prompt when doing nslookup of the US and European Device Clouds:
US Device Cloud addresses:
European Device Cloud addresses:
NOTE: In the examples above, though devicecloud.digi.com/devicecloud-uk.digi.com
and my.idigi.com/co.uk are both valid DNS names to get to their respective Device Cloud servers, the my.idigi.com and devicecloud.digi.com DNS names must resolve to a unique IP address in order to satisfy SSL Certificate requirements.
Making the Firewall Rules:
The Windows command used to find the IP address of a Device Cloud server is nslookup <Device Cloud server DNS name>
The Name and Address fields are the DNS name and IP address for the Device Cloud server listed. Your firewall rule would need to allow access to the TCP port used with your Device Cloud connection (TCP port 3197 (non-secure) or 3199 (SSL), depending on your Gateway's Device Management configuration)), as well as UDP port 123 for NTP Time Management.
If your Gateway is still configured to use the old my.idigi.* or login.etherios.* DNS name/IP, you should migrate to the new devicecloud.digi url at your earliest convenience (to avoid having to be redirected from the old DNS name). A separate Firewall Rule will need to be created for each unique IP Port/Device Cloud server name combination.