Home > Support > Knowledge Base
Knowledge Base
Reset Search



Getting Device Cloud Connected: Firewall concerns for outbound Gateway connections to Device Cloud

« Go Back


Problem Resolution


This article assumes you've reviewed the available Configuration/Troubleshooting guidance for your particular Digi product, and have ensured your Gateway or device is otherwise configured properly for a Device Cloud connection.

Firewall concerns:

Firewalls (and IT security people) are generally concerned with protecting a location's Local Area Network from unauthorized use - both from traffic which is coming at the network from the outside world, as well as traffic from within the network going outward.  Your Device Cloud-capable Gateway falls into the latter category, since the Gateway makes a TCP socket connection to the Device Cloud server.  The  EDP (easy device protocol) socket connection is what allows you to access the data pushed from your Gateway to Device Cloud, from anywhere in the world.

The following article below describes the IP socket connections used when a Gateway or device makes a Device Cloud connection, as well as how to determine the IP address of the DNS name for our Device Cloud servers, when Firewall Rules are needed.  This article will especially be useful to those who try to Device Cloud connect a device from a location which has strict outbound firewall rules, such as Government/Government contractors and institutions, Schools, Universities, and some Businesses. 


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, as well as the particular model.

TCP Port 3197:  The outbound EDP connection from NDS-based Gateways like the ConnectPort X2X2 for Smart EnergyX4X5X8, and ERT/Ethernet Gateway with older firmware which are configured to create an un-encrypted Device Cloud connection.  Note:  If possible, the firmware in these Gateways should be updated, then the configuration settings changed in order to create an SSL socket connection instead (see below)

TCP Port 3199:   The outbound EDP connection from NDS-based Gateways with newer firmware and ALL Linux-based Gateways such as the XBee Gateway and ConnectPort X2e to create an SSL (secure) Device Cloud connection.

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 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:

C:\> nslookup login.etherios.com

Name:    login.etherios.com

C:\>nslookup my.idigi.com

Name::    my.idigi.com

European Device Cloud addresses:

C:\>nslookup login.etherios.co.uk

Name:    login.etherios.co.uk

C:\>nslookup my.idigi.co.uk

Name:    my.idigi.co.uk

NOTE:  In the examples above, although login.etherios.com login.etherios.co.uk and my.idigi.com my.idigi.co.uk are all valid DNS names to get to their respective Device Cloud servers, you'll note that all have unique IP addresses for that destination.  The reason is that the DNS names all must resolve to a unique IP address, in order to satisfy SSL Certificate requirements.

Etherios Primary NTP Time Server Ring addresses:

C:\>nslookup time.etherios.com

Name:     time.etherios.com

C:\>nslookup time.etherios.co.uk

Name:    0.idigi.pool.ntp.org
Aliases:   time.etherios.co.uk 

Etherios Secondary/Tertiary NTP Time Server addresses:

C:\>nslookup 0.idigi.pool.ntp.org

Name:     0.idigi.pool.ntp.org

C:\>nslookup 1.idigi.pool.ntp.org

Name:     1.idigi.pool.ntp.org

C:\>nslookup 2.idigi.pool.ntp.org

Name:     2.idigi.pool.ntp.org

C:\>nslookup 3.idigi.pool.ntp.org

Name:     3.idigi.pool.ntp.org

Making the Firewall Rules:

A Windows CLI command can be used to determine the IP address of our Device Cloud servers:
nslookup <Device Cloud server DNS name>

The Name and Address fields will be the DNS name and IP address for the Device Cloud 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 for NTP Time Management.

Important Note regarding deprecated Device Cloud DNS names:

If your Gateway is configured to use a my.idigi.* DNS name, it should be re-configured to use the new login.etherios.* url at your earliest convenience. If you have Gateways pointing to more than one Device Cloud server name, you'll need to make new firewall rules for all IP ports used, to all DNS server names used.



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255