Firewall concerns for outbound Gateway connections to the Device Cloud --> What to do if everything checks out but your Gateway still shows up as "Disconnected"...
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 the ConnectPort X2e: The ConnectPort X2e Linux-based Gateways 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.
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 login.etherios.com/co.uk and my.idigi.com/co.uk are both valid DNS names to get to their respective Device Cloud servers, the my.idigi and login.etherios DNS names must resolve to a unique IP address to satisfy SSL Certificate requirements.
Making the Firewall Rules:
The Windows command used to find the IP address of our Device Cloud servers 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 CP-X2e Gateways.
If your Gateway is still configured to use the old my.idigi DNS name/IP, you should migrate to the new login.etherios url at your earliest convenience (to avoid having to be redirected from the old DNS name of my.idigi.com). If you have Gateways pointing to both the my.idigi and login.etherios of either Device Cloud server, you'll need to make firewall rules for all ports used to all DNS server names used.