Overview
The Workspot Client attempts to discover where it is relative to your organization's network. This is called location detection (not to be confused with geolocation, which is different.) The benefit of location detection is to avoid using Gateways and VPNs unnecessarily, since a direct connection is faster and has lower overhead.
Location detection is set up in Control in “Setup > Configuration” and applied in two places:
Pool Definitions. When a desktop pool or application server pool been defined with the "Route through Gateway: External Only" option, the Client tries to connect to the Workspot desktop directly if it is on your network and uses the RD Gateway (or VPN) if it isn't.
Protocol Policies. Protocol Policies are also specified per-pool. With desktop pools, you can specify a different Protocol Policy for when the Client is on your organization's network and another for when it is remote. (See Protocol Policies.) The local/remote determination uses the location detection in this article. for more information.
Workspot Web Client Limitation. The Workspot Web Client cannot function unless it uses a Gateway (browsers cannot open standard RDP connections and only Gateways support the necessary WebSocket connections). Web Client access requires that you specify your desktop and application server pools with:
A Gateway, not a VPN or direct access.
“Route through Gateway” set to “Always.”
This means that pools where the Web Client is used can’t benefit from routing optimization but can still benefit from local vs. remote Protocol Policies.
How Location Detection Works
Location detection uses beacons: Web servers accessible to the organization's internal network but not externally. The details of beacon operation are given in the next section. In this section, we describe how the Workspot Client uses location detection to decide:
How to connect to Workspot desktops and apps, and
Which Protocol policy to use for the connection.
Client Connection Algorithm
If VPN routing is specified for the pool, the following tests are applied in order:
If a "Custom Routing List" is defined on the "Setup > Configuration" page, and any of the destination addresses match, the Client connects using the VPN if the entry's "Route Through VPN" option is selected. Otherwise, it makes a direct connection to the Workspot desktop. No further tests are made.
If a "Corporate WLAN List" is defined in "Setup > Configuration," and the Client detects any of the listed SSIDs, the Client connects using the VPN if the entry's "Route Through VPN" option is selected. Otherwise, it makes a direct connection. No further tests are made.
The Client considers whether it can detect any defined beacons:
If the Client can reach any beacon (before using the VPN defined in Workspot Control), it considers itself to be on the company's network and attempts a direct connection with the desktop.
If it can't reach any beacons, it considers itself to be remote from the company's network and attempts a VPN connection.
If it can't establish a VPN connection, it attempts a direct connection as a fallback regardless of whether a beacon is defined or reachable. No further tests are made.
If RD Gateway routing is specified for the pool:
If the Client can reach any beacon (before using the RD Gateway defined in Workspot Control), it considers itself to be on the company's network.
If the pool option "Route Through Gateway" option is set to "External Only" (or "Never"), the Client attempts a direct connection.
If the Client can't reach any beacons, or if no beacons are defined, the Client assumes it is Internet-connected and uses the RD Gateway without attempting a direct connection.
Protocol Policy Algorithm
The Protocol Policy selection algorithm is not available to VPN pools, just RD Gateway pools. Its algorithm is simple: if the Client detects one or more valid beacons, the "Company Network" policy is used. Otherwise, the "Internet" policy is used.
Using Beacons
Note: The Workspot Web Client has stricter requirements than the other Clients. If you configured beacons before using the Web Client, you may need to change them. See URL Requirements, below.
Beacon URLs are specified in Control under "Setup > Configuration > Location Detector." These URLs need to resolve to one of your internal Web servers.
Web Server requirements
Hosted on at least one web server that is reachable ONLY from inside your organization's network.
The specified URL page must not redirect to another page or URL, and it must not require authentication. The Workspot client is looking for a normal (code 200) response.
If HTTPS is used, a valid certificate (that isn't a self-signed certificate) must be used by the server. This certificate must be trusted by the Client device.
URL requirements
Use the IP address of your internal Web server, (not its DNS name), to prevent the DNS hijacking performed by many ISPs.
The Workspot Web Client accepts only HTTPS URLs, which must request a valid image file (such as favicon.ico, or any .ico, .jpg, .png file). The contents of the file are not examined, just the server reply (which should be "200 OK").
Other Clients work fine with the URLs accepted by the Workspot Web Client, but are less strict. They accept both HTTP and HTTPS URLs, which resolve to anything that returns a "200 OK" response.
To avoid wasting time, bandwidth, and server resources, the URL should return a relatively small object, such as a favicon.ico icon.
Configuration
Go to "Setup > Configuration > Location Detector"
Enter the URI of internal sites that will play the role of "beacons" and hit "Save".
(Maximum of three Sites/Web Servers.)
FAQs
What type of web server should I use?
Many companies have Microsoft Windows Servers. These servers can be configured to be a web server (IIS) fairly easily.
What type of security should the IIS server have?
None. The Location Detector service is looking for a response from the server. If incoming connection requests require authentication first, the location detection response from that server will return as false.
What ports are supported by the Location Detector?
The Location Detector supports common web ports: 80, 443. Other ports may work but have not been tested.
What data or content is sent to and from the server participating in the Location Detector service?
No web content is sent to the server. When the Client communicates with the server, the client is looking for a response of “200 OK”.
What order should I place the servers in?
There is no preference as to which server is selected. The feature will attempt to solicit a response from up to three servers. Once a "200 OK" response is received from any of the servers, the Workspot Client concludes that it is on your organization's network. Subsequent responses from the server are discarded.
Do the servers need to be available on the internet?
No! The servers defined for the Location Detector service must not be accessible from the internet. This would negate the Location Detector purpose. Our best practices for this feature call for Control to be configured with an IP address, (instead of a FQDN). The reason is that many companies use non-routable addresses (i.e.: 10.x.x.x) in their internal networks, this helps ensure the servers are internal to the company’s network.