d7x Server Connectivity

In current versions of d7x, detailed error messages exist to inform you of the reason for the failure (e.g. DNS lookup failure, connection rejected due to invalid credentials, IP banned for too many invalid login attempts, subscription expired, etc. etc.)  

As for other connectivity issues, d7x requires access to several servers which could be restricted by a software or hardware firewall/NAT router or a UTM appliance.

• d7x software will not activate your purchased license.  An already activated copy of d7x can exhibit other behaviors as described below.
• d7x may fail to report or downloaded updated versions of it’s own software binaries, as well as default custom apps profile updates.
• d7x may fail with various functionality related to the Config Mgmt Portal, which stores your d7x configurations and custom definition files.
• d7x may fail to submit debug reports to the server when using capture mode to submit a bug report (however the option to request a response via email will still succeed to submit the information, as well as create a ticket in our support queue.)
• d7xRDT (the d7x “Remote Deployment Tool”) cannot populate your configuration list when run, cannot download the d7x core files (complete failure), or cannot download your configurations (if the core download was successful but not the configurations, it may prompt for registration when starting d7x.)

To test connectivity in a browser, try opening these addresses:

https://xcloud.d7xtech.com/ (SSL) or http://xcloud.d7xtech.com/ (Non-SSL) For these tests, when successful you should see a custom error page offering to return you to d7xTech.com

ftp://xcloud.d7xtech.com:32767/ or ftp://xcloud.d7xtech.com/  For the ftp:// based tests, when successful you should receive a login prompt (it is unnecessary to attempt login.)

Both of the above methods are used for various communications, so both must be available.  With both HTTP and FTP protocols, d7x now defaults to an SSL connection, however should d7x fail to connect over SSL, it will also try non-SSL connections as well.

d7x connectivity uses not only HTTP/HTTPS, but also Passive FTP/FTPS to access different servers for different purposes.  In Passive FTP, the client uses a standard port as a “control channel” to initiate communication with the server, which then responds with a randomly selected port in the upper range (we configure for 49000-54000) allowing the client to initiate a new outgoing TCP connection with the server from this port for data transfers. This works well in most cases, because firewalls typically do not block outgoing TCP connections.

Troubleshooting an FTP issue can be as simple as consulting your model’s documentation, or better yet, search the internet for issues using the model number with ‘FTP’ and look for keywords like ‘problem’ or ‘issue’ and similar.

In some cases a “smart” NAT router can block FTP over SSL (Implicit or Explicit) or any tightly locked down system can block all Passive FTP traffic if configured to block outgoing TCP connections on non-HTTP based ports; this should be extremely rare.  Similar issues can occur with some SPI firewalls due to default internal logic, but this should also be very rare.  In cases such as these where SSL connectivity over FTP is not possible, d7x will fall back to non-SSL connections.

Some “smart” NAT/firewalls attempt to detect the FTP control messages sent by the server in order to dynamically open data ports based on the PASV response, however this fails with SSL traffic and ports will never be opened to outgoing traffic.  In such a case the data port is not reachable, however d7x will attempt to reestablish a connection using non-secure communication (which we believe is acceptable, because your configuration data is also AES-256 encrypted at the file-level with the “Technician Password” you created during first-time setup of d7x.)

Unfortunately a NAT/firewall can still block insecure Passive mode FTP traffic under certain configurations.  There are at least two models of Sonicwall routers that include a setting to “Block FTP Bounce Attacks” which is enabled by default, and will block all Passive FTP traffic. We cannot confirm but there may have been a model of Cisco router that shipped with a similar setting enabled by default.  Fortunately, these older models are less common to find, and other similar configurations are also less likely since Passive mode FTP usage became widespread years ago due to the common usage of firewalls which block the incoming TCP connections required by Active mode FTP.