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.
Symptoms:
- 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.)
Testing Connectivity:
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.
More Info:
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.
Where Problems Can Occur:
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.
Latest News
-
d7x v21.4.2 Release Notes Fixed: d7x should now extract the correct product key from...
Read More -
New Release: dSupportSuite and dSS Mgmt Console v21.3.27.1 with ShadowGuard! dSupportSuite, our White-Label Automated Maintenance app / Business Card with...
Read More -
d7x v21.3.24 Release Notes Added new “Battery Report” to reports options (using powercfg /batteryreport)...
Read More -
New app: EC2Tool (for use with AWS) EC2Tool is a utility designed for two purposes: Amazon EC2 Backup...
Read More -
d7x v21.3.2 Release Notes Added list of ‘Installed Apps’ and ‘Installed Store Apps (Non-Microsoft)’...
Read More -
d7x v21.2.27 Release Notes For the new Windows Updates (DISM Wrapper) – updated install...
Read More -
d7x v21.2.26 Release Notes Added d7x function to enable Windows System Restore, which is...
Read More -
d7x v21.2.19 Release Notes Registry Hive backup function now backs up registry hives to...
Read More -
d7x v21.2.16 Release Notes Fixed an issue with dUninstaller (UI) failing to uninstall programs...
Read More -
d7x v21.2.13 Release Notes Added ability to run Custom Apps with standard user privileges...
Read More