Remote Workers and Cradle – how do they communicate?

Cradle, like many modern applications, uses networked communications between clients and servers. However, with modern working practices, often not all users are on the same site. Some, not even the same continent as the Cradle server. So we need to create a method to allow these remote workers access to the Cradle server.

Thin Clients

3SL created the CWS (Cradle Web Server).  This allows a capable thin client deployment to local and remote workers without the need to install Cradle WorkBench.  But some customers want their remote workers to have access to the full capabilities of WorkBench, Project Manager, Document Publisher, and Document Loader; so how can these remote workers deploy the Cradle clients with network access to the server?

Virtualised Applications and Desktops – (e.g. XenApp, RemoteApp)

Citrix XenApp® and Microsoft® RemoteApp allow your applications and desktops to be virtualised and then served to the user from central servers.  The Cradle client utilities are installed on the Application Servers.  Users are able to connect to the server which redirects the Application or Desktop display to the users device.  These technologies allow users with devices which are not currently supported by 3SL to use the full desktop Cradle applications.

Many Cradle customers use Citrix XenApp® and Microsoft® RemoteApp virtualised apps and desktops to serve Cradle WorkBench, and other Cradle utilities to their local and remote workers.  But what if you’re remote and your company doesn’t use these distribution technologies? What are your options for remotely connecting to a Cradle server?

There are a number of methods which we have assisted customers in deploying to allow their remote workers access to a central Cradle system.

VPN – Virtual Private Network

Virtual private networks provide a link from the remote hosts to the network where the CDS lives and we can talk directly to the CDS over this connection. VPN can provide host to network, and network to network communications. Authenticating and encrypting VPN links provide security over the internet.

This is the preferred method between sites, or dedicated remote workers, as most customers already have VPN technologies in place and this provides the least restrictions and requires little additional configuration of the Cradle server.

NAT – Network Address Translation

This is where we remap one IP address space to another IP address space.  What this gives us is the ability of a gateway or firewall to route Cradle communications to a CDS behind the firewall.  This can expose the Cradle server to unwanted external traffic if the firewall rules are not carefully locked down.

SSH Tunnels  – Secure Shell for Unix and Linux hosts

Part of this protocol is the ability to map local IP ports to remote IP hosts and ports beyond the remote SSH host. We can use this to direct Cradle communications to the CDS.

You may not wish to expose the Cradle server using NAT as it can open it up to potential hostile traffic, but you don’t want to go down the route of a full VPN solution.  SSH tunnels fulfils this need.

In future blogs, we’ll be going through some of these options in more detail for Cradle specific installations.