Leveraging Your DMZ for Seamless, Rapid WFH Monitoring

As a follow up to my 10 Steps to a Work-from-Home program. I reached out to my colleagues, Steve Hajek and Mark Knouse, here at Liquidware for some additional advice on utilizing Stratusphere UX to monitor the effectiveness of your Work-From-Home (WFH) options.


Key Monitoring Objectives for WFH Programs

As I mentioned in my previous blog, monitoring WFH environments allows you to answer three key questions:

  1. Who is connecting?   You need to see who is logging in at what times.   These metrics provide  basic information that lets you know that your workers are able to sign  on to the system.
  2. Who is operational?   This set of metrics allows you to get basic performance stats for your users.  Login times, network latency and app response times among them.  This data helps you determine that your users are having an acceptable level of performance and are not frustrated in trying to accomplish work with sub-optimal workspaces.
  3. Who is productive?   This set of metrics can validate what applications are being used, how long they are being used, how they are responding to users’ needs.  Applications are the backbone of work and this information validates that workers are leveraging them to perform their tasks.

Obviously, this is important information for organizations to have in order to validate that their WFH programs are sound, reliable and effective for workers.

Alternative WFH Set Up Stratusphere UX – Collector Deployed into DMZ

You may be facing a situation right now where some portion of your workforce needs to work remotely, although they haven’t in the past, and you must expedite configuring and installing Stratusphere UX to respond to these immediate needs.  By deploying a Collector into a DMZ and leveraging a public IP, you can securely collect Stratusphere UX data in real time and lessen the load on your internal network.


In this alternative approach, you can configure Stratusphere UX to accept data from your remote users without requiring them to connect to the VPN for the data to be uploaded.  This configuration prevents a delay in data being available in Stratusphere UX, so your views of data are kept  current throughout the day as you review them.

In order to securely accomplish this, we recommend using a Collector deployed into a DMZ and accessible via a public IP on TCP/443.  Using a Collector instead of the HUB prevents placing the webUI on the public internet since it also uses TCP port 443.  The CID keys make their connection to Collectors using HTTPS just as your browser does, so there is no concern about data crossing the public internet since its encrypted.  In most cases, the only other change needed to make this work seamlessly are some DNS record modifications.

How the Alternative DMZ Approach Expedites WFH Monitoring

To see how this could work, let’s look at an example of  existing or new Stratusphere UX deployment of 10,000 users/machines.  Normally, most or all of the machines reporting data would be on the internal network, so you’d probably have two internally accessible Collectors running alongside the HUB and Database.

If we needed to make a shift where half of those machines were now remote, we can take one of those Collectors, move it to a DMZ network and forward TCP/443 to it from a public IP.  Assuming your HUB’s CID Callback Address is already using an internal FQDN – and you have a matching externally-facing DNS forward-lookup zone, you can update the internal DNS record to point to the internal Collector IP and the external, but matching, DNS record to point to the public-facing Collector IP.  Then you’d create a new Collector Group named “Disabled” and re-assign both Collectors into the new, but un-used, Collector Group.  This removes the Collectors from the normal round-robin rotation and allows DNS to determine which Collector a machine will connect to.

Then, if a machine is “in-network”, the internal resolution would send it to the internal Collector IP and if the machine is “out-of-network”, the external DNS zone would resolve to the public IP of the other Collector.

The above scenario can extend to a single Collector, as well, where ultimately both DNS records send you back to the same Collector, one to the internal IP and the other to the public IP.

You can also deploy more complicated configurations if your environment dictates.  For example, Collectors support multi-homing and can accept CID key data from multiple networks, use a specific NIC to communicate to the HUB and another to communicate to the Database.

For those organizations with existing cloud implementations or those looking to deploy Stratusphere UX in the cloud, follow the same guidelines as the on-premises recommendations as well as ensuring proper security groups and firewalls exist to secure the traffic to the public IP address of the appliance.

Here are some external references on our Support site that can help you with more information:

As always, our experts are here to help you.  You can contact us at the Liquidware website at any time, and they are standing by at this critical time to ensure you get a prompt answer to your questions.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.