ThingWorx Edge Java SDK > Tunneling
This section provides an overview of tunneling (remote sessions) between edge devices and ThingWorx platform and then explains how to configure tunneling for your edge application. Finally, it provides the settings required for the Tunneling Subsystem of the ThingWorx platform.
The ThingWorx Edge Java SDK fully supports application tunneling. Application tunnels allow for secure, firewall-transparent tunneling of TCP client server applications such as VNC and SSH. You can create mashups from which your users can start remote sessions with edge devices that are running your Java SDK application.
Configuring Tunneling
To enable tunneling, either invoke ClientConfigurator.tunnelsEnabled(true), or set the tunnelsEnabled directive in your config file. A full example is available in the file, located in the directory, samples/com/thingworx/sdk/simple.
As of v.6.1.0, the Java SDK supports compression between the edge and the platform for tunneling by default. For more information see ClientConfigurator Component.
// Create a client config
ClientConfigurator config = new ClientConfigurator();

// Basic configuration. See for additional info.

// Ensure tunnels are enabled for this example

try {

ConnectedThingClient client = new ConnectedThingClient(config);

VirtualThing myThing = new VirtualThing(ThingName, "Tunnel
Example", client);


while (!client.isShutdown()) {

} catch (Exception e) {
Once it connects to the server, this client binds myThing to the matching remote thing that was created using the RemoteThingWithTunnels thing template on the ThingWorx platform. Once bound, the thing can receive tunnel requests from the platform, and facilitate tunnels to local applications.
Required Setting for the Tunneling Subsystem
When attempting to configure tunneling, you must check the configuration for the Tunneling Subsystem of the ThingWorx platform. There is a field where you can specify the host/IP of the end point for the tunnel, called Public host name used for tunnel. The following figure shows the configuration page for the Tunneling Subsystem, with this field highlighted:
Why do you need to configure this address? Suppose that you start up your server in Amazon EC2. The default IP address for the Tunneling Subsystem when the server is running in EC2 might be 10.128.0.x. Unless you change that address, the Tunneling Subsystem will tell the clients to attempt to connect to that host for the tunnel websocket. Since that IP address is a local network address, the tunnel will not work. Therefore, you must populate that configuration field with the external host/IP address that tunnels will use for connections.