Using the Motorola Tunnel Service with MSP

Transcription

1 Using the Motorola Tunnel Service with MSP

2

3 Using the Motorola Tunnel Service with MSP 72E Revision B April 2012

4 2012 by Motorola Solutions, Inc. All rights reserved. No part of this publication may be reproduced or used in any form, or by any electrical or mechanical means, without permission in writing from Motorola Solutions. This includes electronic or mechanical means, such as photocopying, recording, or information storage and retrieval systems. The material in this manual is subject to change without notice. While every reasonable precaution has been taken in the preparation of this document, neither Symbol Technologies, Inc., nor Motorola Solutions, Inc., assumes responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. The software is provided strictly on an as is basis. All software, including firmware, furnished to the user is on a licensed basis. Motorola Solutions grants to the user a non-transferable and nonexclusive license to use each software or firmware program delivered hereunder (licensed program). Except as noted below, such license may not be assigned, sublicensed, or otherwise transferred by the user without prior written consent of Motorola Solutions. No right to copy a licensed program in whole or in part is granted, except as permitted under copyright law. The user shall not modify, merge, or incorporate any form or portion of a licensed program with other program material, create a derivative work from a licensed program, or use a licensed program in a network without written permission from Motorola Solutions. The user agrees to maintain Motorola Solution s copyright notice on the licensed programs delivered hereunder, and to include the same on any authorized copies it makes, in whole or in part. The user agrees not to decompile, disassemble, decode, or reverse engineer any licensed program delivered to the user or any portion thereof. Motorola Solutions reserves the right to make changes to any software or product to improve reliability, function, or design. Motorola Solutions does not assume any product liability arising out of, or in connection with, the application or use of any product, circuit, or application described herein. No license is granted, either expressly or by implication, estoppel, or otherwise under any Motorola Solutions, Inc., intellectual property rights. An implied license only exists for equipment, circuits, and subsystems contained in Motorola Solutions products. Motorola Solutions and the Stylized M Logo and Symbol and the Symbol logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. Motorola Solutions, Inc One Motorola Plaza Holtsville, New York

5 Table of Contents About This Guide... 1 MSP Documentation... 1 Help... 1 Service Information... 1 Chapter 1 Introduction... 3 Overview... 3 What is the Motorola Tunnel Service?... 3 Acquiring the Motorola Tunnel Service... 4 Obtaining the Add-On Kit... 4 Add-On Kit Contents... 4 Add-On Kit Installation... 5 Licensing the Motorola Tunnel Service... 5 Chapter 2 Key Concepts of Tunnel Service Operation... 7 Overview... 7 Tunnel Service Patrons... 7 Device Contactability... 7 Directly Contactable... 7 Indirectly Contactable... 8 Tunnel Agent Modes of Operation... 9 Inbound Mode... 9 Tunnel Service Patron Inbound Port Information...12 Outbound Mode...13 Tunnel Service Patron Outbound Port Information...17 Tunnel Agent Device Attributes Chapter 3 Security Considerations Overview Motorola Tunnel Service Contactability Tunnel Service Ports... 20

6 vi -- Using the Motorola Tunnel Service with MSP Tunnel Agent Ports Connection Security General Network Node Attacks...22 Motorola Tunnel Service-Specific Attacks...22 General Port Attacks...22 Service-Based Attacks...22 End-to-End Security...23 Chapter 4 Control Modules Required Control Modules TunnelAgent...25 Purpose...25 Installation...25 Configuration...25 Description...25 Connection Type:...26 Tunnel Agent Listening Port:...26 Workstation to Tunnel Service IP:...26 Workstation to Tunnel Service Port:...26 Device to Tunnel Service IP:...26 Device to Tunnel Service Port:...26 Number of Retries:...27 Connection Loss Retry Frequency:...27 Retry Frequency:...27 Heartbeat Interval:...27 Log Level:...27 Display Tray Icon?:...28 Operation...28 Device Attributes...28 Related Control Modules GetAdapters...30 Chapter 5 Installation and Configuration Overview Motorola Tunnel Service Target Hardware Motorola Tunnel Service Pre-requisites Motorola Tunnel Service Deployment Motorola Tunnel Service Configuration TunnelService.Configuration Settings Object...33 Description...33 Workstation to Tunnel Service Port:...33 Device to Tunnel Service Port:...34 Log Level:...34 Configuration Wizard...35 Tunnel Service Workstation Port...35 Tunnel Service Device Port...36 Log Level...36 Chapter 6 Using the Motorola Tunnel Service Overview Usage Transparency NAT Traversal NAT Traversal Operation...38 One-to-One NAT IP Address Mapping...38 One-to-Many NAT IP Address Mapping...38 Simplifying NAT Variations...39

7 Table of Contents -- vii Configuring MSP NAT Traversal for Tunnel Service...39 System Deployment Tunnel Service Status Monitoring Status Monitoring Using MSP...40 Status Monitoring Using Standalone Status Viewer...41 Best Practices... 43

8 viii -- Using the Motorola Tunnel Service with MSP

9 About This Guide MSP Documentation This document provides information on using Motorola Tunnel Service. The library of available MSP documentation is extensive and widely available to MSP customers. Customers may obtain the latest version of all documents from: Help On-line Help is available in both the MSP Console UI and the MSP Administration Program. Rollover help is included for many fields in the MSP Console UI. In the MSP Administration Program, press F1 from any page to open page-specific Help (in some configurations you may have to press F1 twice). For page-specific Help in the MSP Console UI, click Help in the upper-right corner and click Help in the dropdown (see below). In the MSP Console UI, you also can click Help and Document Library to access PDF files of all the standard MSP manuals. When you import an MSP Add-On that comes with a manual, the manual will appear in the Document Library list after import. Service Information If you have a problem with your software, contact Motorola Enterprise Mobility support for your region. Contact information is available at: When contacting Enterprise Mobility support, please have the following information available:

10 2 -- Using the Motorola Tunnel Service with MSP Serial number of the software Model number or product name Software type and version number Software license information Motorola responds to calls by , telephone or fax within the time limits set forth in support agreements. If you purchased your Enterprise Mobility business product from a Motorola business partner, contact that business partner for support.

11 Chapter 1 Introduction Overview The Motorola Tunnel Service provides a mechanism to enhance the contactability of devices from Workstation PCs. One or more instances of the Motorola Tunnel Service can be installed, at appropriate locations within an Enterprise. The Motorola Tunnel Service is intended to be used in conjunction with its Tunnel Agent Patrons, such as the Motorola Remote Control Solution and the Motorola Real-Time Management Solution. The Motorola Tunnel Service is deployed and configured independently of its patrons. Both patrons will work without the Motorola Tunnel Service, to support Directly Contactable devices, and will detect and use the Motorola Tunnel Service, when it is deployed and appropriately configured, to support Indirectly Contactable devices. What is the Motorola Tunnel Service? The Motorola Tunnel Service is software that runs on one or more Windows PCs within an Enterprise and facilitates the establishment of communication sessions between Workstation PCs and devices. Each instance of the Motorola Tunnel Service must installed on a Windows PC that resides within the Enterprise at a location that is reachable by Workstation PCs and that is Directly Managed by MSP via the Windows PC Client, which is a variety of the MSP Client Software. Note: For more information on the Windows PC Client, see the MSP Client Software Guide. One or more instances of the Motorola Tunnel Service are typically deployed in cases where devices are not Directly Contactable from Workstation PCs. An instance of the Motorola Tunnel Service is generally required when contactability of devices must be enhanced in order to support Remote Control or Remote UI sessions to them or to support various MSP Real-Time Management functions.

12 4 -- Using the Motorola Tunnel Service with MSP When the contactability of a given device will be enhanced using an instance of the Motorola Tunnel Service, an additional device resident software component, called the Motorola Tunnel Agent, must be deployed and configured on that device. The Motorola Tunnel Agent is the device counterpart of the Motorola Tunnel Service and handles interactions with the Tunnel Motorola Service on behalf of the device and applications that benefit from enhanced contactability. Deploying one or more instances of the Motorola Tunnel Service can make devices Indirectly Contactable by allowing Workstation PCs to contact a given device indirectly, via a Tunnel Service and Tunnel Agent pair. The Tunnel Service can forward traffic from a Workstation PC to the Tunnel Agent on a device either via a connection established by the Tunnel Service to the Tunnel Agent (Inbound Mode) or over a connection established and maintained by Tunnel Agent to the Tunnel Service (Outbound Mode). The deployment of one or more instances of the Motorola Tunnel Service can thus enhance contactability and help overcome problems experienced due to the organization and security characteristics of an Enterprise network. Acquiring the Motorola Tunnel Service Obtaining the Add-On Kit The Motorola Tunnel Service components are provided via Add-On Kits that are available for download from the following link: Updated versions of the Add-On Kits containing updated components may also periodically be available for download from the same link. Add-On Kit Contents The Add-On-Kit will be a.zip File with a name of the form: Motorola_TunnelService_<os, if applicable>_<core version>_<zip version>_<date>.zip where: <os> is WM5 for Windows Mobile 5.0 or higher, WM2003 for Windows Mobile 2003 only, or CE for Windows CE or PC for Managed Windows PC <core version> This is the version of the primary component of the Add-On. <zip version> <date> This is a version number that is used to indicate that something has changed in the Add-On other than the primary component. This needs to be reset when the Core Version changes. indicates the release date of the Add-On Kit.ZIP File (represented in YYYYDDMM format). Each Add-On Kit.ZIP File contains the following contents: The Definition Document for Tunnel Agent settings, TunnelAgent.Configuration.setting.xml. The definition document for Tunnel Service settings, TunnelService.Configuration.setting.xml

13 Chapter 1 Introduction -- 5 TunnelAgent.apf or PC_TunnelAgent.apf, which includes the component necessary for installing the Tunnel agent on the Windows handheld device or Managed Windows PC respectively TunnelService_Prerequisites.apf, which includes the component necessary for installing the Tunnel Service Pre-requisites TunnelService_Setup.apf, which includes the component necessary for installing the Tunnel Service Add-On Kit Installation Important: If more than one Add-On Kit for the same solution is installed, then certain common files will likely appear in all.zip Files. Since Updates to parallel Add-On Kits may be released on independent schedules, it is very important that the latest copy of these common files be used. This can be accomplished by installing Add-On Kits in oldest to newest order since the last Add- On Kit installed will determine the version of the common files that will be used. This ordering can be determined by looking at the date that is part of the Add-On Kit.ZIP File name. For Users with direct access to Windows Console on the MSP Server, an Add-On Kit.ZIP Files can be installed using the MSP Administration Program. See Add-On Kit Installation in Administering MSP. Licensing the Motorola Tunnel Service Each instance of the Motorola Tunnel Service must be installed onto a Windows PC that is Directly Managed by MSP via the Windows PC version of the MSP Client Software. This managed Windows PC requires MSP to allocate a Provision or Control license. A Provision Edition License is required if a Data Collection Solution is not deployed to the Windows PC. A Control Edition License is required if a Data Collection Solution is deployed to the Windows PC. The Motorola Tunnel Service is implemented as Proxy Plug-In to the MSP Client Software on the Windows PC. As a result, once the Motorola Tunnel Service is installed onto a Windows PC, that an additional managed device, with a Device Class of TunnelServiceProxy, is discovered. Since the instance of the Motorola Tunnel Service is treated as a managed device, it also requires MSP to allocate a license. The Motorola Tunnel Service always requires a Control Edition License. Important: Because the Motorola Tunnel Service requires a Control Edition License, the Motorola Tunnel Service can only be used with MSP Control Edition. For more information on Proxies, see Understanding MSP Understanding Device Classes and Proxies.

14 6 -- Using the Motorola Tunnel Service with MSP

15 Chapter 2 Key Concepts of Tunnel Service Operation Overview This chapter introduces some key concepts that are important to grasp in order to understand and effectively utilize one or more instances of the Motorola Tunnel Service to enhance the contactability of devices managed by MSP. The solutions which makes use of Tunnel Service to resolve the connectivity issues are referred as Tunnel Service Patrons Tunnel Service Patrons The current Tunnel Service Patrons are the Motorola Remote Control Solution (MRCS) and the Motorola Real-Time Management Solution (RTM). They work in conjunction with the Motorola Tunnel Agent to leverage the enhanced contactability offered by the Motorola Tunnel Service. MRCS and/or RTM can be used alone for a device that is Directly Contactable. But when a device is Not Directly Contactable, it must be made Indirectly Contactable for such applets to be used. That means deploying an instance of the Motorola Tunnel Service, deploying the Motorola Tunnel Agent to the device, and suitably configuring the Tunnel Agent to work with that instance of the Motorola Tunnel Service. Device Contactability In order to use a Tunnel Service Patron (i.e., the Motorola Remote Control Solution and Real- Time Management) when there is no direct contact to a device, the Tunnel Service has to serve as a bridge for exchanging information between a device from a Workstation PC. Directly Contactable A device is Directly Contactable (Figure 1) if a connection from a Workstation PC can be directly established to the device via the IP Address reported to MSP by the device. If a given device is Directly Contactable from a Workstation PC, then an instance of the Motorola Tunnel Service is generally not required. For consistency, if an instance of the Motorola Tunnel Service is required to support other devices, it can also be used, even for devices that would otherwise not require it.

16 8 -- Using the Motorola Tunnel Service with MSP Figure 1 Direct Workstation to Device As shown above, the Direct connection is implemented via the following steps: 1. Browser requests MSP server to serve the Tunnel Service Patron applet (MRCS or RTM) on clicking on the appropriate link in the device details or device status page 2. The Applet is served up from the MSP Server to the Web Browser running on the Workstation PC along with the device IP Address and Port number in which Tunnel Agent patron is listening 3. The MSP Console User requests for a control function. If a connection is not already established or the previous connection has been lost, then a new connection to the device function is established. 4. Response will be delivered to the applet and appropriate rendering will be done Indirectly Contactable If a device is not Directly Contactable from a Workstation PC, then an instance of the Motorola Tunnel Service would generally be required to make the device Indirectly Contactable. Whenever the Motorola Tunnel Service will be used to enhance the contactability of a given device, the Tunnel Agent must be deployed and configured on that device either in Inbound mode (Tunnel Service contacts the device) or outbound mode (Device contacts the Tunnel Service) as explained below Important: The Tunnel Agent is a mandatory component on any device that will be used with an instance of the Motorola Tunnel Service.

17 Chapter 2 Key Concepts of Tunnel Service Operation -- 9 Tunnel Agent Modes of Operation The Motorola Tunnel Service and Motorola Tunnel Agent collectively support two modes of operation: Inbound Mode and Outbound mode. While the Tunnel Agent on any one device can operate in only one mode at a time, a single instance of the Motorola Tunnel Service can support multiple devices configured for different modes. Inbound Mode In Inbound Mode, an instance of the Motorola Tunnel Service acts as a bridge between Workstation PCs and the Tunnel Agents in one or more devices. A Workstation PC connects to a specific instance of the Motorola Tunnel Service which then bridges the connection to a specific device over a new connection it establishes on-demand to the Motorola Tunnel Agent in that device. A key advantage of Inbound Mode is the fact that the Motorola Tunnel Agent in the device listens for incoming connections from an instance of the Motorola Tunnel Service. This means that the device does not need to establish and maintain a connection to that instance, as would be required in Outbound Mode. The instance of the Motorola Tunnel Service establishes a connection to the Motorola Tunnel Agent in a device only in response to a connection request from a Workstation PC and hence a connection to the device only exists when it is actually needed. This can reduce network traffic and improve battery life by avoiding the need to keep a session continuously open. A key disadvantage of Inbound Mode is the requirement that devices be directly contactable from the instance of the Motorola Tunnel Service. This can severely constrain the locations where that instance of the Motorola Tunnel Service can be installed and hence may limit its viability as a solution. If the instance cannot be deployed such that it can contact the devices, then Inbound Mode cannot be effectively used. An instance of the Motorola Tunnel Service operating in Inbound Mode can be viewed as providing similar functionality to that which can be achieved through NAT Traversal. For example, in the case of an Enterprise NAT, the Enterprise NAT could be re-configured to enable Port Address Translation (PAT) and then MSP could be configured to contact selected ports that would then be mapped to specific devices. Using an instance of the Motorola Tunnel Service in Inbound Mode may offer a simpler solution that is easier to implement and use. By locating an instance of the Motorola Tunnel Service on the private side of a NAT, only a single port would need to be opened through the NAT to allow Workstation PCs to contact that instance. All devices could then be contacted by Workstation PCs via a single port that allows access to that instance. Inbound Mode is not always a viable solution, however. In the case of a Service Provider NAT, Inbound Mode generally will not solve the inherent contactability problem since an instance of the Motorola Tunnel Service likely could not be located inside the Service Provider NAT. If an instance cannot be located such that it can contact devices, then it cannot use Inbound Mode to help Workstation PCs contact those devices. To solve the contactability problems engendered by a Service Provider NAT, the use of Outbound Mode would generally be required. When using Inbound Mode, the Motorola Tunnel Agent in the device listens for incoming connections from an instance of the Motorola Tunnel Service and then routes those incoming connections to the appropriate Tunnel Service Patron on the device. This works similarly to the way it would work if the connections had come directly from the Workstation PC. The difference is that the actual connections from the Workstation PC to the device are indirect, bridged through connections to the device initiated by the instance of the Motorola Tunnel Service.

18 10 -- Using the Motorola Tunnel Service with MSP To use Inbound Mode, the Motorola Tunnel Agent must be deployed to the device and must be configured to listen for contact from a specific instance of the Motorola Tunnel Service. The Tunnel Agent on any one device can only be configured to listen for contact from a single instance of the Motorola Tunnel Service at any one time. If that instance becomes unavailable, the device will no longer be Indirectly Contactable until the instance becomes available again or the Motorola Tunnel Agent is re-configured to listen for contact from a different instance of the Motorola Tunnel Service. When the Motorola Tunnel Agent is configured to listen for contact from an instance of the Motorola Tunnel Service, it reports that information to MSP as Device Attributes. Any Workstation PC that wishes to establish a session to a device whose Motorola Tunnel Agent is configured to use Inbound Mode must do so via that instance of the Motorola Tunnel Service. To use Inbound Mode, the Motorola Tunnel Agent running on a device must be configured by applying a TunnelAgent.Configuration Settings Object. This Settings Object must specify a Connection Type of Workstation PC contacts Tunnel Service which contacts device (Inbound Mode). The Settings Object must also specify the IP Address and Port at which the instance of the Motorola Tunnel Service will be contacted by the Workstation PC and the Port at which the instance of the Motorola Tunnel Service will contact the device. Important: The configuration applied to the Motorola Tunnel Agent running on a device must properly specify the information about the instance of the Motorola Tunnel Service that will be used and must be compatible with the configuration applied to that instance of the Motorola Tunnel Service. When the Motorola Tunnel Agent running on a device processes the TunnelAgent.Configuration Settings Object, it will configure itself to listen for incoming connections from the proper instance of the Motorola Tunnel Service. It will also arrange to report to MSP the IP Address and Port at which the Workstation PC should contact that instance of the Motorola Tunnel Service. When an Applet running on a Workstation PC initiates a connection to a device, the Applet will connect to the proper instance of the Motorola Tunnel Service using the IP Address and Port sent to MSP by the Motorola Tunnel Agent running on that device. The Applet will also be provided with the IP Address of the device and the Port on which the Motorola Tunnel Agent running on the device is listening, which will passed on to the instance of the Motorola Tunnel Service to use when establishing an on-demand connection. The Applet will also pass information about the target Tunnel Agent Patron (the device counterpart of the Applet) that it wishes to contact. The instance of the Motorola Tunnel Service will then establish an on-demand connection (tunnel) to the Motorola Tunnel Agent on the appropriate device, using the IP Address and Port that was provided by the Workstation PC, and bridges the connection from the Workstation PC to the Motorola Tunnel Agent running on the device, over that connection (tunnel). If the Tunnel Service is on the same side of a NAT or Firewall as the device, then it would generally have no problem establishing the required on-demand connection to the device. When the instance of the Motorola Tunnel Service bridges the traffic to the Motorola Tunnel Agent running on the device, the Tunnel Agent will direct that traffic to the appropriate Tunnel Service Patron as determined by the information passes by the Workstation PC to the instance of the Motorola Tunnel Service and then passed on to the Tunnel Agent. Once a bridged connection is successfully established, the Applet on the Workstation PC Control Module on the device will communicate over that connection. If the connection is lost, the Applet will reestablish the connection seamlessly, in coordination with the Tunnel Service and Tunnel Agent, without any additional involvement of the MSP Server. The actual exchange of data between the Applet and the Control Module is end-to-end and will occur based on how the Control Module is configured. This may include authentication and/or

19 Chapter 2 Key Concepts of Tunnel Service Operation encryption, if selected. The instance of the Motorola Tunnel Service and the Motorola Tunnel Agent are not active participants in the end-to-end communications - they merely provide a connection bridge across which the end-to-end communications can occur. All authentication and encryption, if selected, is between the Applet and the Control Module, and is simply passed through by the Tunnel Service and Tunnel Agent. If a Workstation PC running a Tunnel Service Patron applet (i.e., MRCS, RTM) cannot be in direct contact with a managed device and the Tunnel Service and the device are on the same side of the NAT or the Firewall, Tunnel Service can be used in Inbound Mode. Figure 2 represents Tunnel Service being employed in Inbound Mode. Figure 2 Indirect Workstation PC to Tunnel Service to Device Inbound Mode As shown above, the Indirect connection inbound mode is implemented via the following steps: 1. Browser requests MSP server to serve the Tunnel Service Patron applet (MRCS or RTM) on clicking on the appropriate link in the device details or device status page 2. The Applet is served up from the MSP Server to the Web Browser running on the Workstation PC along with the Tunnel Service IP, Port, Device IP, Tunnel Agent Port and the target Tunnel Service patron. 3. The MSP Console User requests for a control function. If a connection is not already established with the Tunnel Service or the previous connection has been lost, then a new connection to the Tunnel Service is established. On receiving request from workstation PC, tunnel service will establish a tunnel with device using the connection information passed by the workstation 4. Response will be delivered to the applet and appropriate rendering will be done in the applet

20 12 -- Using the Motorola Tunnel Service with MSP Tunnel Service Patron Inbound Port Information The following table discusses specific port information for the existing Tunnel Service Patrons. Tunnel Service Patron Port Information Motorola Remote Control Solution The MRCS Applet running on the Workstation PC establishes an indirect connection to the device by establishing a direct connection to TCP Port 7778 on the Tunnel Service. The Tunnel Service then establishes an on-demand connection to the device using the IP Address reported by the device to MSP and bridges the connection from the Workstation PC to the device over the connection established from the Tunnel Service to the device. Since the Tunnel Service is on the same side of the NAT or Firewall as the device, it has no problem contacting the device. If a NAT or Firewall were present, it would need to be configured to permit connections from the Workstation PC to the Tunnel Service on port 7778, but would not need to be configured to permit connections from the Workstation PC to devices on port 7776 (Tunnel Agent Port). This configuration is likely simpler and more practical than would be required to traverse a NAT without a Tunnel Service, but it nonetheless may not be consistent with Enterprise security policies. Note: Default port for Tunnel Service from Workstation PC is 7778 (Old port is 7775) Default port for Tunnel Agent is 7776 Default port for MRCS is 7775

21 Chapter 2 Key Concepts of Tunnel Service Operation Tunnel Service Patron Port Information The Applet running on the Workstation PC establishes an indirect connection to the device by establishing a direct connection to TCP Port 7778 on the Tunnel Service. The Tunnel Service then establishes an on-demand connection (shown as a tunnel) to the device using the IP Address reported by the device to MSP and bridges the connection from the Workstation PC to the device over the connection established from the Tunnel Service to the device. Since the Tunnel Service is on the same side of the NAT or Firewall as the device, it has no problem contacting the device. Motorola Real Time Management Solution If a NAT or Firewall were present, it would need to be configured to permit connections from the Workstation PC to the Tunnel Service on port 7778, but would not need to be configured to permit connections from the Workstation PC to devices on port 7776 (Tunnel Agent Port). This configuration is likely simpler and more practical than would be required to traverse a NAT without a Tunnel Service, but it nonetheless may not be consistent with Enterprise security policies. Note: Default port for Tunnel Service from Workstation PC is 7778 (Old port is 7775) Default port for Tunnel Agent is 7776 Default port for RTM is 7777 Outbound Mode In Outbound mode, the Motorola Tunnel Agent in the device is responsible for establishing and maintaining a connection to a specifically configured instance of the Motorola Tunnel Service. As connectivity is lost and regained, the Motorola Tunnel Agent will automatically and invisibly reestablish the connection to the instance as needed. On establishing the connection Tunnel Agent registers the device UUID with the Tunnel Service. A Workstation PC connects to a device by connecting to that instance of the Motorola Tunnel Service, which then informs the device to establish a new session over the existing connection established and maintained to that instance by the Motorola Tunnel Agent. On receiving request from Tunnel Service the new data connection will be established from device to Tunnel Service so that Tunnel Service will maintain a tunnel between Workstation PC and device over this new connection. Further traffic from the Applet running on the Workstation PC is then bridged to target Tunnel Service Patron running on the device, over the connection (tunnel) established between the Tunnel Service and the Tunnel Agent A key advantage of Outbound Mode is the fact that an instance of the Motorola Tunnel Service does not need to be located such that it can contact devices. Instead, the instance must be located such it can be contacted both by devices and by Workstation PCs. This is often more readily achievable than the requirements for Inbound Mode.

22 14 -- Using the Motorola Tunnel Service with MSP A key disadvantage of Outbound Mode is the requirement for the Motorola Tunnel Agent in each device to establish and continuously maintain a connection to its configured instance of the Motorola Tunnel Service. This can impact battery life and add a small, but measurable additional load on the network. This is often an acceptable price to pay to enable contactability when it would otherwise not be possible. Using Outbound Mode can solve problems that would otherwise be impractical to solve. For example, in the case of a Service Provider NAT, it is often the case that devices can contact the internet but cannot be contacted from the internet. By locating an instance of the Motorola Tunnel Service such that it is contactable from the internet, devices can be made Indirectly Contactable. Workstation PCs would contact that instance of the Motorola Tunnel Service and, via that instance, would be able to contact devices, via their resident Motorola Tunnel Agents. To use Outbound Mode, the Motorola Tunnel Agent running on a device must be configured by applying a TunnelAgent.Configuration Settings Object. This Settings Object must specify a Connection Type of Workstation PC contacts Tunnel Service which is contacted by device (Outbound Mode). The Settings Object must also specify the IP Address and Port at which the instance of the Motorola Tunnel Service will be contacted by the device and the IP Address and Port at which the instance of the Motorola Tunnel Service will be contacted by the Workstation PC. Important: The configuration applied to the Motorola Tunnel Agent running on a device must properly specify the information about the instance of the Motorola Tunnel Service that will be used and must be compatible with the configuration applied to that instance of the Motorola Tunnel Service. When the Motorola Tunnel Agent running on a device processes the TunnelAgent.Configuration Settings Object, it will configure itself to contact the instance of the Motorola Tunnel Service at the appropriate IP Address and Port. It will also arrange to report to MSP the IP Address and Port at which the Workstation PC should contact that instance of the Motorola Tunnel Service. When a Tunnel Service Patron applet (i.e., MRCS, RTM) running on a Workstation PC initiates a connection to a device, the Applet will connect to the proper instance of the Motorola Tunnel Service using the IP Address and Port sent to MSP by the Motorola Tunnel running on that device. The Applet will also be provided with the UUID of the device, which will be passed on to the instance of the Motorola Tunnel Service to identify the device to be contacted. The Applet will also pass information on the target Tunnel Agent Patron (the device counterpart of the Applet) that it wishes to contact. The instance of the Motorola Tunnel Service will then check to see if a device of the requested UUID has already established a connection (tunnel) to that instance of the Motorola Tunnel Service. If not, then the connection from the Workstation PC will be immediately refused. If a device with the requested UUID already established a connection (tunnel) to that instance of the Motorola Tunnel Service, then the Tunnel Service bridges the connection from the Workstation PC to the Motorola Tunnel Agent running on the device, by informing the device to make a new connection to establish the over that connection (tunnel). Once a bridged connection is successfully established, the Applet on the Workstation PC Control Module on the device will communicate over that connection. If the connection is lost, the Applet will reestablish the connection seamlessly, in coordination with the Tunnel Service. As discussed above, in Outbound Mode a connection (tunnel) is established and maintained by the Motorola Tunnel Agent running on the device to an instance of the Motorola Tunnel Service, even when no application session is in progress. The instance of the Tunnel Service keeps a list of devices, by UUID, that have registered and that continue to maintain such connections.

23 Chapter 2 Key Concepts of Tunnel Service Operation It is part of the nature of many devices, especially mobile devices, that connectivity may come and go and/or that devices may suspend and resume, reboot, etc. As a result, the connection (tunnel) established between the Motorola Tunnel Agent on a device and an instance of the Motorola Tunnel Service may occasionally be lost. When the connection from a device to a Tunnel Service is lost, it may stay disconnected for a significant period of time. Maintaining a connection with a device requires a continuing use of resources on the instance of the Motorola Tunnel Service. If many connections are lost, a significant amount of Tunnel Service resources could be dedicated to keeping track of stale sessions. This could limit the scalability and performance of Tunnel Service. The Tunnel Service is therefore designed to detect a time-out and un-register devices that have not been heard from for a while. To prevent unnecessary time-outs, a heartbeat is maintained between the Motorola Tunnel Agent running on a device and the instance of the Motorola Tunnel Service. The heartbeat consists of a message that is periodically sent from the Tunnel Service to the Tunnel Agent. The Tunnel Service uses the heartbeat to reset its timer and keep the connection active. The heartbeat also allows the Tunnel Agent to better detect losses of connectivity. When connectivity is lost and becomes available again, the Tunnel Agent on the device automatically re-establishes a connection to its Tunnel Service. Note: The heartbeat between the device and the Tunnel Service in Outbound Mode represents additional network traffic that can also lead to a reduction in battery life. This is an unavoidable consequence of using Outbound Mode which must be weighed against the benefits of enhanced contactability. When no Tunnel Service is used or when in Inbound Mode is used, a heartbeat is not required. As a result, Outbound Mode should only be used when the contactability benefits it offers are important enough to justify the additional network traffic and impact on battery life. The actual exchange of data between the Applet and the Control Module is end-to-end and will occur based on how the Control Module is configured. This may include authentication and/or encryption, if selected. The instance of the Motorola Tunnel Service and the Motorola Tunnel Agent are not active participants in the end-to-end communications - they merely provide a connection bridge across which the end-to-end communications can occur. All authentication and encryption, if selected, is between the Applet and the Control Module, and is simply passed through by the Tunnel Service and Tunnel Agent. If a Workstation PC running a Tunnel Service Patron applet (i.e., MRCS, RTM) cannot be in direct contact with a managed device and the Tunnel Service and the device are on different sides of the NAT or the Firewall, Tunnel Service can be used in Outbound Mode. Figure 3 represents Tunnel Service being employed in Outbound Mode.

24 16 -- Using the Motorola Tunnel Service with MSP Figure 3 Indirect Workstation PC to Tunnel Service to Device Outbound Mode As shown above, the Indirect connection outbound mode is implemented via the following steps: 1. During startup Tunnel Agent registers the device UUID with the Tunnel Service 2. Tunnel Service acknowledges the registration and maintains the map 3. Tunnel Service maintains the connection with Tunnel Agent by sending heartbeat request to the tunnel agent 4. Browser requests MSP server to serve the Tunnel Service Patron applet (MRCS or RTM) on clicking on the appropriate link in the device details or device status page 5. The Applet is served up from the MSP Server to the Web Browser running on the Workstation PC along with the Tunnel Service IP, Port, Device UUID and the target Tunnel Service patron. 6. The MSP Console User requests for a control function. If a connection is not already established with the Tunnel Service or the previous connection has been lost, then a new connection to the Tunnel Service is established. 7. On receiving request from workstation PC, tunnel service will inform the Tunnel agent to initiates a data connection to establish a tunnel with device 8. Tunnel Agent will establish a new data connection to the Tunnel Service and establishes a tunnel between Tunnel Service and Tunnel Agent 9. Tunnel Service forwards the request from Workstation PC to the Tunnel Agent over newly established data connection (tunnel) 10. Response from device will be traversed back to the requested applet over the tunnel

25 Chapter 2 Key Concepts of Tunnel Service Operation Tunnel Service Patron Outbound Port Information The following table discusses specific port information for the existing Tunnel Service Patrons. Tunnel Service Patron Port Information Motorola Remote Control Solution The MRCS applet running on the Workstation PC establishes an indirect connection to the device by establishing a direct connection to TCP Port 7778 on the Tunnel Service. The device has previously established a connection (shown as a tunnel) to the Tunnel Service on port The Tunnel Service then informs the device over the existing connection to make a new connection to the Tunnel Service. On receiving the new data connection from device the Tunnel Service bridges the connection from the Workstation PC to the device and maintains a tunnel If a NAT or Firewall were present, it would need to be configured to permit connections from the device to the Tunnel Service on port Support for outgoing connections is often the default configuration for such NATs and Firewalls. But even if this were not the default configuration, changing the configuration would likely be reasonably simple and would quite often be consistent with Enterprise security policies. Note: Default port for Tunnel Service from Workstation PC is 7778 (Old port is 7775) Default port for Tunnel Service from device is 7779 (Old port is 7776) Default port for MRCS is 7775

26 18 -- Using the Motorola Tunnel Service with MSP Tunnel Service Patron Port Information The RTM applet running on the Workstation PC establishes an indirect connection to the device by establishing a direct connection to TCP Port 7778 on the Tunnel Service. The device has previously established a connection (shown as a tunnel) to the Tunnel Service on port The Tunnel Service then informs the device over the existing connection to make a new connection to the Tunnel Service. On receiving the new data connection from device the Tunnel Service bridges the connection from the Workstation PC to the device and maintains a tunnel Motorola Real Time Management Solution If a NAT or Firewall were present, it would need to be configured to permit connections from the device to the Tunnel Service on port Support for outgoing connections is often the default configuration for such NATs and Firewalls. But even if this were not the default configuration, changing the configuration would likely be reasonably simple and would quite often be consistent with Enterprise security policies. Note: Default port for Tunnel Service from Workstation PC is 7778 (Old port is 7775) Default port for Tunnel Service from device is 7779 (Old port is 7776) Default port for RTM is 7777 Tunnel Agent Device Attributes As discussed earlier, when the Tunnel Agent is configured by applying a Settings Object, it reports to MSP the Connection Type that will be used by a Workstation PC to contact the Control Module and the information that will be needed to establish that Connection Type. This is accomplished via the values of Device Attributes set by the Control Module in the Device Registry and then reported to MSP by the MSP Agent.

27 Chapter 3 Security Considerations Overview This chapter discusses some security considerations that should be taken into account when deploying one or more instances of the Motorola Tunnel Service into an Enterprise network. Motorola Tunnel Service Contactability Each instance of the Motorola Tunnel Service continuously listens for incoming socket connections from Workstation PCs. It is therefore imperative that each instance be located such that it will be contactable from all Workstation PCs that will need to contact devices via that instance. Notes: Connections are never established directly from the MSP Server to an instance of the Motorola Tunnel Service. The MSP Console UI merely facilitates the establishment of connections from a Workstation PC to a Tunnel Service. Both the MSP Server and appropriate instances of the Motorola Tunnel Service must be contactable from the Workstation PC, but instances of the Motorola Tunnel Service do not need to be contactable from the MSP Server. In Inbound Mode, an instance of the Motorola Tunnel Service contacts the Motorola Tunnel Agents running on devices on behalf of Workstation PCs. If Inbound Mode is used, then it is imperative that a given instance of the Motorola Tunnel Service be located where it will be able to reach devices that it will need to contact.

28 20 -- Using the Motorola Tunnel Service with MSP In Outbound mode, an instance of the Motorola Tunnel Service continuously listens for incoming socket connections from Motorola Tunnel Agents running on devices. If Outbound Mode is used, then it is imperative that a given instance of the Motorola Tunnel Service be located where it can be reached by all devices that will need to contact it. Note: If a single instance of the Motorola Tunnel Service is supporting a mixture of devices in Inbound and Outbound Modes, it may be necessary for that instance to be able to contact some devices (to support Inbound Mode) and to be contactable by some devices (to support Outbound Mode). Tunnel Service Ports Each instance of the Motorola Tunnel Service must be contacted by Workstation PCs and may need to contact or be contacted by Tunnel Agents running on devices. Depending on the organization and configuration of the Enterprise network, this may require some configuration of NATs, Firewalls, etc. to enable connections to be established on the requisite network ports. Table 1 below shows the various ports that are used by the Motorola Tunnel Service. Table 1 Tunnel Service Ports Interface Name Description/Purpose Old Default Port New Default Port Can Change? Tunnel Service Workstation Port Tunnel Service Device Port Used to connect to the Tunnel Service from Workstation PCs. Used to connect to the Tunnel Service from devices. TCP 7775 TCP 7778 Yes TCP 7776 TCP 7779 Yes

29 Chapter 3 Security Considerations Important: Prior to version 2.2 of the Tunnel Service, the default ports used by the Tunnel Service were in conflict with the default ports used by the Motorola Remote Control Solution. This prevented the Tunnel Service, the Tunnel Agent, and the Motorola Remote Control Solution from all being used on the same Managed Windows PC unless some ports were suitably reconfigured. Beginning with version 2.2 of the Tunnel Service, the default ports have been changed to coexist with the default ports used by the Tunnel Agent and the Motorola Remote Control Solution. This allows the Tunnel Service, the Tunnel Agent, and the Motorola Remote Control Solution to all be used on the same Managed Windows PC without the need to reconfigure the ports. Because of this change, care must be taken when installing new instances of the new Tunnel Service onto new Managed Windows PCs or updating existing Managed Windows PCs to use the new Tunnel Service. If any instances of the Tunnel Service were previously deployed that used the old default ports, and if the Tunnel Agent on any devices was configured to access those instances of the Tunnel Service via those default ports, then some changes will likely need to be made when the new Tunnel Service is deployed. To remain compatible with existing devices, one approach would be to ensure that all instances of the Tunnel Service are configured to use the old default ports. This would need to be done explicitly since both new and updated instances would use the new default ports in the absence of explicit reconfiguration. An alternate approach would be to reconfigure the Tunnel Agent on devices to use the new default ports to connect to new and updated instances of the Tunnel Service. If the new default ports are used, reconfiguration of Firewalls and/or NATs may be required to allow traffic on these new ports to be properly routed. Tunnel Agent Ports An instance of the Motorola Tunnel Service may need to contact the Tunnel Agent in one or more devices (i.e. when Inbound mode is used). Depending on the organization and configuration of the Enterprise network, this may require some configuration of NATs, Firewalls, etc. to enable connections to be established on the requisite network ports. Table 2 below shows the various ports that are used by an instance of the Motorola Tunnel Service to contact the Motorola Tunnel Agent. Table 2 Motorola Tunnel Agent Ports Interface Name Description/Purpose Default Port Can Change? Tunnel Agent Listening Port Used by the Tunnel Service to connect to the Tunnel Agent in the inbound mode. TCP 7776 Yes Notes: If the Tunnel Agent Listening Port for an instance of the Motorola Tunnel Service is changed from the default, then the configuration of the Motorola Tunnel Agent must generally be correspondingly changed on devices that will be contacted by that instance of the Tunnel Service, in order to ensure successful operation.

30 22 -- Using the Motorola Tunnel Service with MSP Connection Security It is important to understand that the Motorola Tunnel Service is designed as a solution to enhance contactability of devices by Workstations PCs and is not designed as a solution to increase the security of those connections. In fact, in some cases the introduction of one or more Tunnel Services could actually have a negative impact on overall network security. Any new entity introduced into an Enterprise represents a potential new attack surface and hence introduces the possibility of new vulnerabilities. And, by increasing the contactability of devices, the vulnerability of devices to contact by unauthorized entities may potentially be increased. The following subsections present some specific security issues that may be worthy of consideration and describe mitigations where applicable. General Network Node Attacks The introduction of the Windows PC on which an instance of the Motorola Tunnel Service software is installed could introduce vulnerabilities not directly related to the Motorola Tunnel Service software itself. Like any other node introduced into an Enterprise, an assessment should be made of the potential vulnerabilities of that node and suitable mitigations should be deployed where appropriate. For example, all relevant and available Operating System security patches should be deployed to harden the Windows PC against malicious attacks. Further, any network ports that may be open for incoming traffic on the Windows should be closed if they are not needed. Such hardening of network nodes is always good practice and would generally be part of any standard Enterprise security policy. Motorola Tunnel Service-Specific Attacks Since an instance of the Motorola Tunnel Service is designed to act as a bridge between Workstation PCs and devices, it is designed to accept connections from those Workstation PCs and devices. This means that ports must be opened to permit incoming connections from the network. As such, every instance of the Motorola Tunnel Service may be exposed to attack by malicious entities attempting to exploit these exposed network ports. For example, if an instance of the Motorola Tunnel Service is exposed to the internet, to allow it to be accessed by devices over a Wide Area Network, then that instance may be subject to attacks from malicious entities anywhere on the internet. General Port Attacks Since the Motorola Tunnel Service requires two ports (by default TCP Port 7778 and TCP Port 7779) to be opened, these ports are subject to general port attacks. A malicious entity could repeatedly send traffic on these ports without making any attempt to conform to the interfaces supported by the services listening on these ports. As such, a malicious entity could cause the Motorola Tunnel Service software to expend resources simply receiving and rejecting traffic on these ports. This is generally unavoidable and is part of the risk involved in exposing any interface on any network. Service-Based Attacks Attacks that attempt to conform to the interface supported by a service listening on a network port can have more serious consequences. This is because, if successful, they can result in the allocation of resources by the server and hence could cause an overload condition and prevent the service from fulfilling its intended goal. Such an attack is generally referred to as a Denial of Service Attack. There are only two services that are exposed to access from the network by an instance of the Motorola Tunnel Service. The first is the ability of a device to contact that instance and register

31 Chapter 3 Security Considerations its UUID. The second is the ability for a Workstation PC to contact a device via that instance, either over a previously registered connection from the Motorola Tunnel Agent in the device or over a connection established on-demand to the Motorola Tunnel Agent in the device. The Motorola Tunnel Service protects itself from Denial of Service attacks on both services through the use of a mandatory built-in challenge/response mechanism. Whenever a Workstation PC or Motorola Tunnel Agent attempts to connect to a service of an instance of the Motorola Tunnel Service, the instance issues a challenge that includes a piece of data randomly selected by that instance. The Workstation PC or device must respond to the challenge by sending back the same random data, encrypted using a shared 128 bit AES encryption key. The Applet on the Workstation PC, the Control Module on the device, and the Motorola Tunnel Service all have the requisite shared encryption key hard-coded. This challenge/response mechanism effectively means that an entity cannot conform to the service interfaces of the Motorola Tunnel Service unless it has access to the proper shared encryption key. And the use of a challenge/response mechanism with random data-based encrypted using a 128 bit AES encryption key means that it is computationally impractical to derive the encryption key from simply snooping on connections occurring over the network. This provides a high degree of protection to the Motorola Tunnel Service against Service-Based Denial of Service Attacks. End-to-End Security As stated earlier, the Motorola Tunnel Service itself is not designed as a solution to increase the security of connections between Workstation PCs and devices. No protection against unauthorized connections from Workstation PCs to devices is implemented within the Motorola Tunnel Service. Likewise, no protection of the privacy or integrity of the data exchanged between Workstation PCs and devices is implemented within the Motorola Tunnel Service. Nonetheless, authorization, privacy, and security are of significant concern and are addressed as part of the solutions that can interoperate with the Motorola Tunnel Service. But security is not addressed specifically by the Motorola Tunnel Service. Instead, optional end-to-end security features are implemented between Workstation PCs and devices as part of other solutions. These end-to-end security features can be used whether or not the Motorola Tunnel Service is being used as part of the overall system solution. The Motorola Tunnel Service is completely unaware of and does not participate in any end-to-end security mechanisms implemented between Workstation PCs and devices. The Motorola Tunnel Service merely provides for enhanced contactability of devices by Workstation PCs. The Motorola Tunnel Service does not monitor or participate in the communications performed over connections it helps establish. The end-to-end security mechanisms used between Workstation PC and devices are opaque to the Motorola Tunnel Service and all data is merely passed along, unmodified and unexamined by the Motorola Tunnel Service.

32 24 -- Using the Motorola Tunnel Service with MSP

33 Chapter 4 Control Modules Required Control Modules TunnelAgent Purpose The TunnelAgent Control Module is used to deploy the Motorola Tunnel Agent to a device to facilitate contactability from Workstation PCs to devices, on behalf of Tunnel Agent Patrons, such as the Motorola Remote Control Solution and the Motorola Remote Management Solution. In order for a device to be used with an instance of the Motorola Tunnel Service, the TunnelAgent Control Module must be deployed to the device. Installation In order for a device to be used with an instance of the Motorola Tunnel Service, the Tunnel Agent must be deployed using MSP via a Package that adds the Motorola Tunnel Agent to the device. Use the appropriate TunnelAgent Package depending on the Target device. Configuration When it is initially deployed, the TunnelAgent Control Module is turned off. This ensures that existing contactability is not affected simply by the installation of this Control Module. Once it is installed, the TunnelAgent Control Module can be configured to turn it on by setting the desired Contact Mode by applying a TunnelAgent.Configuration Settings Object. Settings Objects of the Settings Class TunnelAgent.Configuration are used to configure the Motorola Tunnel Agent on a device. The following Settings can be used to configure the operation of the Motorola Tunnel Agent. Description This Setting specifies an optional overall description which can be used to enter comments or other information about this Settings Object.

34 26 -- Using the Motorola Tunnel Service with MSP Connection Type: This Setting specifies that how the Workstation PC can contact the device. The following values are possible: Turn off Tunnel Service This indicates that the Motorola Tunnel Agent is deactivated. In this mode, Workstation PCs must contact devices directly. Deactivating the Motorola Tunnel Agent allows it to be installed without immediately affecting device operation and allows it to be deactivated without requiring it to be uninstalled., All patrons of the Motorola Tunnel Agent will behave identically when the Motorola Tunnel Agent is installed but deactivated as they do when it is not installed at all. This is the default value. Workstation PC contacts Tunnel Service which contacts device This indicates that the Motorola Tunnel Agent is activated in Inbound Mode. In this mode, Workstation PCs must contact the device indirectly via the proper instance of the Motorola Tunnel Service. Workstation PC contacts Tunnel Service which is contacted by device This indicates that the Motorola Tunnel Agent is activated in Outbound Mode. In this mode, Workstation PCs must contact the device indirectly via the proper instance of the Motorola Tunnel Service. Tunnel Agent Listening Port: This Setting specifies the Port on which the Motorola Tunnel Agent should listen for incoming connections from an instance of the Motorola Tunnel Service. This setting is applicable only when the Motorola Tunnel Agent is activated in Inbound Mode. Default Value: 7776 Workstation to Tunnel Service IP: This Setting specifies the IP Address or Network Name that will be used by Workstation PCs to contact the instance of the Motorola Tunnel Service. This setting is applicable only when the Motorola Tunnel Agent is activated in either Inbound Mode or Outbound Mode. Workstation to Tunnel Service Port: This Setting specifies the Port that will be used by Workstation PCs to contact the instance of the Motorola Tunnel Service. This setting is applicable only when the Motorola Tunnel Agent is activated in either Inbound Mode or Outbound Mode. Default Value: 7778 Device to Tunnel Service IP: This Setting specifies the IP Address or Network Name that will be used by the Motorola Tunnel Agent on the device to contact the instance of the Motorola Tunnel Service. This setting is applicable only when the Motorola Tunnel Agent is activated in Outbound Mode. Device to Tunnel Service Port: This Setting specifies the Port that will be used by the Motorola Tunnel Agent on the device to contact the instance of the Motorola Tunnel Service. This setting is applicable only when the Motorola Tunnel Agent is activated in Outbound Mode.

35 Chapter 4 Control Modules Default Value: 7779 Number of Retries: This Setting specifies how many times the Motorola Tunnel Agent running on the device will attempt to connect to the instance of the Motorola Tunnel Service before considering it as an unrecoverable failure. This Setting is applicable only when the Motorola Tunnel Agent is activated in Outbound Mode. Default Value: 4096 Possible values: Notes: If the specified number of retries is exhausted, the Motorola Tunnel Agent will cease trying to connect to the instance of the Motorola Tunnel Service until the Motorola Tunnel Agent is restarted or re-configured. Connection Loss Retry Frequency: This Setting specifies the time interval in seconds to check for the network connectivity available. If the device network is not configured Motorola Tunnel Agent will continuously checks for the connectivity before making an attempt to connect to the Tunnel Service. There is no limit for number of attempts made for this check Default Value: 30 seconds Possible values: seconds Retry Frequency: This Setting specifies the time interval in seconds to check for the connection attempt to the Tunnel Service. If the Tunnel Service is not reachable then it will attempt until number of retries exhaust Default Value: 30 seconds Possible values: seconds Heartbeat Interval: This Setting specifies the time interval in seconds between heart beat messages sent by the instance of the Motorola Tunnel Service to the Motorola Tunnel Agent running on the device to keep the connection alive. If the Motorola Tunnel Agent does not receive a heart beat request within this time period, then it will automatically re-establish the connection. This Setting is applicable only when the Motorola Tunnel Agent is activated in Outbound Mode. Default Value: 30 seconds Possible values: seconds Log Level: This Setting specifies the level of logging generated by the Motorola Tunnel Agent. Default Value: INFO The following values are possible: ERROR

36 28 -- Using the Motorola Tunnel Service with MSP This is the lowest level you can set for this setting. Only Error logs will be logged in the log file WARN Error and Warning logs will be logged in the log file INFO Error, Warning and Information logs will be logged in the log file DEBUG This is highest level of logging available. All the logs will be logged in the log file Display Tray Icon?: This Setting specifies whether the Tray Icon should be displayed in the System Tray of the device UI when the Tunnel Agent is running. The Tray Icon can be used to visually determine if the Tunnel Agent Control Module is running, which can often be a good indicator of whether connectivity is through Tunnel Agent The following values are possible: True This indicates that the Tray Icon should be displayed in the System Tray. If many Tray Icons are displayed, the device may respond in a variety of ways, including truncating the list of icons, allowing the list to be scrolled, etc. Prompt the Device User for permission This indicates that the Tray Icon should not be displayed in the System Tray. This may be desirable if the System Tray is already full or if the System Tray is not generally visible to Device Users (e.g. because it is hidden by a custom application). Default Value: True Operation See Chapter 6 Using the Motorola Tunnel Service for information on the operation of this Control Module. Device Attributes The TunnelAgent Control Module will add or replace entries into the device Registry to set various Device Attributes to reflect the use of an instance of the Motorola Tunnel Service. Table 3 below details the Device Attributes that can be reported by the TunnelAgent Control Module.

37 Chapter 4 Control Modules Table 3 Device Attributes Attribute Name UserAttribute.TunnelService.ConnectionType Explanation This Device Attribute is reported as having a value of 0 when the Tunnel Agent is turned off so that direct connection from Workstation PC to device is allowed. This Device Attribute is reported as having a value of 1 when the Tunnel Agent is configured for Workstation PC contacts Tunnel Service which contacts device (i.e. Indirect Contact, Inbound Mode). This Device Attribute is reported as having a value of 2 when the Tunnel Agent is configured for Workstation PC contacts Tunnel Service which is contacted by device (i.e. Indirect Contact, Outbound Mode). UserAttribute.TunnelService.TunnelAgentPort This Device Attribute is reported only if the Device Attribute UserAttribute.TunnelService.ConnectionType is reported as having a value of 1. This Device Attribute reports the Port on which the Tunnel Agent is listening and at which it should be contacted by a Tunnel Service when the Tunnel Agent is configured for Workstation PC contacts Tunnel Service which contacts device (i.e. Indirect Contact, Inbound Mode). UserAttribute.TunnelService.TunnelIpAddr This Device Attribute is reported only if the Device Attribute UserAttribute.TunnelService.ConnectionType is reported as having a value of 1 or 2. This Device Attribute reports the IP address or Network Name at which the Workstation PC should contact the Tunnel Service. UserAttribute.TunnelService.TunnelPort This Device Attribute is reported only if the Device Attribute UserAttribute.TunnelService.ConnectionType is reported as having a value of 1 or 2. This Device Attribute reports the TCP Port at which the Workstation PC should contact the Tunnel Service.

38 30 -- Using the Motorola Tunnel Service with MSP Related Control Modules GetAdapters As described in Understanding MSP Understanding Control Modules, the GetAdapters Control Module acquires and delivers information about all networks adapters that are active and connected in a device and what it considers to be the best adapter to be used to contact the device. The TunnelAgent Control Module does not duplicate the functionality of the GetAdapters Control Module. In particular, since the GetAdapters Control Module already reports the IP Address via which the device can be contacted, the TunnelAgent Control Module leverages this information for use in Indirect Contact Inbound Mode.

39 Chapter 5 Installation and Configuration Overview This chapter discusses the installation and configuration of instances of the Tunnel Service. Motorola Tunnel Service Target Hardware An instance of the Motorola Tunnel Service software should be installed on one or more Windows PCs within an Enterprise when the need for enhanced contactability of devices is required. Instances of the Motorola Tunnel Service software could be installed on any dedicated or shared Windows PC or Windows Virtual Machine that is running a supported Windows Operating System. Motorola Tunnel Service Pre-requisites Important: Because each instance of the Motorola Tunnel Service requires a Control Edition License, the Motorola Tunnel Service can only be used with MSP Control Edition. Instances of the Motorola Tunnel Service must always be installed using MSP onto a Windows PC that is already being Directly Managed by MSP via the Windows PC Client. Note: For information on the Windows PC Client and how to get a Windows PC to be Directly Managed by MSP, refer to the MSP Client Software Guide. In addition to the Windows PC Client, the Motorola Tunnel Service requires that the following prerequisites be present on the Windows PC before the Motorola Tunnel Service can be successfully installed onto that Windows PC:

40 32 -- Using the Motorola Tunnel Service with MSP Java Runtime Environment The MSP recommended Java Runtime can be installed via the TunnelService_Prerequisite Package. Motorola Tunnel Service Prerequisites can be manually installed onto a Windows PC or can be deployed to a Windows PC using MSP via a Package that adds all the necessary pre-requisites onto a Windows PC. Once a given Windows PC has been discovered by MSP and is shown as having a Device Class of Windows PC, the Tunnel Service Pre-requisites Package can be installed onto that Windows PC by deploying the Package TunnelService_Prerequisites.apf to that Windows PC. Note: Installing the Motorola Tunnel Service Pre-requisites Package will install all the Motorola Tunnel Service Pre-requisites, but uninstalling the Motorola Tunnel Service Pre-requisites Package will not remove those pre-requisites. In particular, uninstalling the Motorola Tunnel Service Prerequisites Package will not prevent the Motorola Tunnel Service, if it has been installed, from continuing to operate. If the previous version of Java is already installed on the machine and is being used by any of the process then installation of pre-requisite will fail. This is because during java upgrade instead of doing the silent installation it throws up the error message on the server saying Java is being used by one of the process. Always make sure no program is using the Java before installing the pre-requisite During the un-installation of Tunnel Service make sure that Tunnel Service Status viewer and Tunnel Service Configuration Wizard is closed. This is important because these two components are part of Tunnel Service package and will be removed during the un-installation process. If these file being used then Tunnel Service un-installation will fail. Motorola Tunnel Service Deployment An instance of the Motorola Tunnel Service is deployed using MSP via a Package that adds Tunnel Service support into the Windows PC Client running on a Windows PC. Once a given Windows PC has been discovered by MSP and is shown as having a Device Class of Windows PC, the Tunnel Service can be installed onto that Windows PC by deploying the Package TunnelService_Setup.apf to that Windows PC. If any of the Motorola Tunnel Service Prerequisites are not met on that Windows PC, then the installation of that Package will fail. Once the Motorola Tunnel Service Package is successfully installed on the Windows PC, the instance of the Motorola Tunnel Service on that Windows PC will get discovered by MSP and will be shown as having a Device Class of TunnelServiceProxy. This will be an indication that the instance of the Motorola Tunnel Service on that Windows PC is active and ready to be configured.

41 Chapter 5 Installation and Configuration Motorola Tunnel Service Configuration Each instance of the Motorola Tunnel Service is initially configured with defaults that may allow it to be used right away. In some cases, however, the default configuration may not be suitable and re-configuration may be required. An instance of the Motorola Tunnel Service software can be configured in any of the following ways: TunnelService.Configuration Settings Object Once an instance of the Motorola Tunnel Service is installed on a Windows PC and discovered as a managed device, then it is ready to be configured. One or more instances of the Motorola Tunnel Service can be configured by creating and deploying a Settings Object of Settings Class TunnelService.Configuration. Important: TunnelService.Configuration Settings Objects can only be deployed to managed devices of Device Class TunnelServiceProxy. If a TunnelService.Configuration Settings Object is deployed to any other Device Class, such as to a Windows PC, then it will fail. This is true even though the managed device of Device Class TunnelServiceProxy is running on the Windows PC. If multiple instances of the Motorola Tunnel Service are installed on multiple Windows PCs, they could all be configured using a single TunnelService.Configuration Settings Object. Whether this is appropriate to do would depend on whether the desired configuration is the same for all instances. Sending the same Settings Object to multiple instances could easily be accomplished by using a Provisioning Policy with an Applicability Rule that includes a test for the Device Class TunnelServiceProxy, The following Settings can be used to configure the operation of an instance of the Motorola Tunnel Service. Description This Setting specifies an optional overall description which can be used to enter comments or other information about this Settings Object. Workstation to Tunnel Service Port: This Setting specifies the Port that should be used by Workstation PCs to contact the instance of the Motorola Tunnel Service. This Setting is applicable for Indirect Contact Inbound Mode (i.e. when Connection Type is set to Workstation PC contacts Tunnel Service which contacts device ) or Indirect Contact Outbound Mode (i.e. when Connection Type is set to Workstation PC contacts Tunnel Service which is contacted by device ). Default Value: 7778 Note: If the default port is changed for an instance of the Motorola Tunnel Service, then a corresponding change will need to be made to the configuration of the Motorola Tunnel Agent for all devices that will be used with that instance of the Motorola Tunnel Service.

42 34 -- Using the Motorola Tunnel Service with MSP Device to Tunnel Service Port: This Setting specifies the Port that should be used by the Motorola Tunnel Agent running on devices to contact the instance of the Motorola Tunnel Service when Outbound Mode is used. This Setting is applicable only for Indirect Contact Outbound Mode (i.e. when Connection Type is set to Workstation PC contacts Tunnel Service which is contacted by device ). Default Value: 7779 Note: If the default port is changed for an instance of the Motorola Tunnel Service, then a corresponding change will need to be made to the configuration of the Motorola Tunnel Agent for all devices that will be used in Outbound Mode with that instance of the Motorola Tunnel Service. Log Level: This Setting specifies the level of logging to be generated by the instance of the Motorola Tunnel Service. The following values are possible: Note: SEVERE This is the lowest level of logging available. Only the occurrence of Errors will be logged. WARNING The occurrence of Errors and Warnings will be logged. INFO The occurrence of Errors, Warnings, and Informational Messages will be logged. DEBUG This is the highest level of logging available. The occurrence of Errors, Warnings, Informational Messages, and Debug Messages will be logged. The higher the level of logging configured, the larger and faster the Log file can grow in the Tunnel Service. Logging should be configured as low as appropriate under normal circumstances. If problems are encountered, then logging may be increased until the problem is found, but should be lowered again when no longer needed. There will be a maximum of 3 log files created with 10MB size. After this first file will be deleted

43 Chapter 5 Installation and Configuration Default Value: INFO Configuration Wizard Once an instance of the Motorola Tunnel Service has been installed on a Windows PC, that single instance can be re-configured using the Motorola Tunnel Service Configuration Wizard. This is not recommended way for changing the configuration Note: If multiple instances of the Motorola Tunnel Service need to be identically configured, then a using a TunnelService.Configuration Settings Object, as described in the prior section, would likely be a more efficient approach. The Motorola Tunnel Service Configuration Wizard can be launched using the Tunnel Service Configuration shortcut that can be found in the Start Menu of the Windows PC at Programs > Motorola MSP > Tunnel Service Configuration. Important: Running the Motorola Tunnel Service Configuration Wizard requires access to the Windows Console of the Windows PC on which the Motorola Tunnel Service has been installed. This would generally require physical access to that Windows PC or the ability to remotely login to the Windows Console of that Windows PC (e.g. using the Microsoft Remote Desktop Protocol or some similar mechanism). Figure 4 below shows the Motorola Tunnel Service Configuration Wizard Dialog that will be displayed when the Motorola Tunnel Service Configuration Wizard is launched using the shortcut. Note: Figure 4 Tunnel Service Configuration Wizard Dialog If the Tunnel Service is installed on Windows Vista and above user must login as Administrator to make any changes to the configuration using Wizard. Changes made to the configuration of an instance of the Motorola Tunnel Service while it is running may not take effect until the instance is restarted or the Windows PC is rebooted. Tunnel Service Workstation Port This option specifies the Port that should be used by Workstation PCs to contact the instance of the Motorola Tunnel Service.

44 36 -- Using the Motorola Tunnel Service with MSP Note: If the default port is changed for an instance of the Motorola Tunnel Service, then a corresponding change will need to be made to the configuration of the Motorola Tunnel Agent for all devices that will be used with that instance of the Motorola Tunnel Service. Tunnel Service Device Port This option specifies the Port that should be used by the Motorola Tunnel Agent running on devices to contact the instance of the Motorola Tunnel Service when Outbound Mode is used. Note: If the default port is changed for an instance of the Motorola Tunnel Service, then a corresponding change will need to be made to the configuration of the Motorola Tunnel Agent for all devices that will be used in Outbound Mode with that instance of the Motorola Tunnel Service. Log Level The Tunnel Service Log Level can be adjusted, if needed. This might be changed if there is a need to debug the operation of the Tunnel Service.

45 Chapter 6 Using the Motorola Tunnel Service Overview This chapter discusses how to use the Tunnel Service Usage Transparency The Tunnel Service is designed to enhance the contactability of devices from Workstation PCs, when used in conjunction with Tunnel Agent Patrons, such as the Motorola Remote Control Solution or the Motorola Real-Time Management Solution, while providing a high degree of Usage Transparency. By this is meant that once the Tunnel Services are appropriately installed and configured and once devices are appropriately configured, the usage of the Tunnel Agent Patrons is the same as if no Tunnel Service were used. In fact, to meet the potentially varying needs of a complex Enterprise network, some devices might need to be contacted directly (without an intermediary Tunnel Service), some devices might need to be contacted via a Tunnel Service using Inbound Mode, and some devices might need to be contacted via a Tunnel Service using Outbound Mode. Once such a system is properly deployed, an MSP Console UI User can use the Tunnel Agent Patrons without needing to worry how devices will be contacted. NAT Traversal For Indirect Contact Modes to be used, Workstation PCs must be able to directly contact instances of the Motorola Tunnel Service. If an instance of the Motorola Tunnel Service is inside the inner network of a NAT and Workstation PCs are in the outer network, then it may be the case that the instance of the Motorola Tunnel Service will not be directly contactable from some or all Workstation PCs. When such a situation exists, NAT Traversal may be used or the instance of the Motorola Tunnel Service will need to be relocated. It may seem somewhat strange to set up a network in this way, since one key reason for using an instance of the Motorola Tunnel Service is to avoid the need for NAT Traversal. But in fact, this can be a very reasonable approach.

46 38 -- Using the Motorola Tunnel Service with MSP Configuring NAT Traversal for a large number of devices can be quite complicated since it must take into account the mappings required to reach each and every device. If an instance of the Motorola Tunnel Service is placed with the devices in the inner network, then NAT Traversal need only be configured to reach the instance of the Motorola Tunnel Service and the instance of the Motorola Tunnel Service will handle reaching the devices. In addition, traffic to the instance of the Motorola Tunnel Service may be the only traffic for which NAT Traversal must be configured. This can make the configuration of the NAT Router much simpler since there is only one IP Address and one port to be dealt with. NAT Traversal Operation The most automatic way for a node in an inner network to learn the IP Address of a node in an inner network is to have the node in the inner network send it to the node in the outer network.. But this does not help much for NAT Traversal since a node in the inner network generally does not know its public IP Address, and hence cannot tell a node in the outer network about it. While traffic from the node in the inner network may be identified as coming from its public IP Address, the public IP Address generally cannot be included as data sent by the node. The key task in NAT Traversal is determining the proper IP Address and possibly Port Number (if NAPT is used) required to contact nodes in the inner network from nodes in the outer network. This requires understanding and leveraging knowledge about configuration of the NAT Router. There are two primary NAT IP Address Mapping modes: One-to-One NAT IP Address Mapping and One-to-Many NAT IP Address Mapping. These modes have different requirements for successfully accomplishing NAT Traversal. One-to-One NAT IP Address Mapping When One-to-One NAT IP Address Mapping is used, the NAT Traversal must somehow determine the proper public IP Address to use to contact the desired node in the inner network from a node in the outer network. This process can be relatively simple since there is a unique public IP Address for each node. NAT Traversal must be accomplished by maintaining a table mapping private IP Addresses to public IP Addresses. Since a node in an inner network can know its private IP Address, it can report that. A node in the outer network can then use that private IP Address to look up the proper public IP Address required to reach that node. As mentioned earlier, implementing NAT Traversal for instances of the Motorola Tunnel Service can often be significantly less work than implementing NAT Traversal for devices. This is because there are generally far fewer instances of the Motorola Tunnel Service than there are devices, since a single instance of the Motorola Tunnel Service generally services many devices. One-to-Many NAT IP Address Mapping When One-to-Many NAT IP Address Mapping is used, the NAT Traversal must somehow determine both the proper public IP Address and Port Number to use to contact the desired node in the inner network from a node in the outer network. This process is more complicated since the same public IP Address is used for multiple devices and must be paired with a Port Number. NAT Traversal must be accomplished by maintaining a table mapping private IP Addresses to pairs of public IP Addresses and Port Numbers. Since a node in an inner network can know its private IP Address, it can report that. A node in the outer network can then use that private IP Address to look up the proper pair of public IP Address and Port Number required to reach that node.

47 Chapter 6 Using the Motorola Tunnel Service As mentioned earlier, implementing NAT Traversal for instances of the Motorola Tunnel Service can often be significantly less work than implementing NAT Traversal for devices. This is because there are generally far fewer instances of the Motorola Tunnel Service than there are devices, since a single instance of the Motorola Tunnel Service generally services many devices. Simplifying NAT Variations NAT Traversal can be very complicated in the general case, especially if there are many NAT Routers and their configurations vary. Having several different models or vendors of NAT Routers could also significantly complicate the successful configuration of NAT Traversal. If all NAT Routers are of the same vendor and model and if all NAT Routers are configured similarly, then the effort to configure MSP for NAT Traversal can be made much more practical. This is sometimes referred to as a cookie cutter approach because all inner networks look alike and are served by NAT Routers that behave consistently. Configuring MSP NAT Traversal for Tunnel Service When necessary, NAT Traversal may be used to enable the use of Indirect Contact Modes between Workstation PCs in an outer network and devices in an inner network when the instance of the Motorola Tunnel Service to be used is also inside the same inner network. This can be configured as described below. When the MotoRemoteControl or MotoRemoteUI Control Module is configured to use Indirect Contact Mode, the IP Address and Port Number of an instance of the Motorola Tunnel Service must also be configured. The Control Module then notifies the MSP Server of this information using the Device Attributes UserAttribute.TunnelService.TunnelIpAddr and UserAttribute.TunnelService.TunnelPort. The MSP Server uses this information to connect Workstation PCs to the instance of the Motorola Tunnel Service and thence to devices. Since the instance of the Motorola Tunnel Service is in the inner network, and Workstation PCs are in the outer network, the Control Module must report the public IP Address of the instance of the Motorola Tunnel Service to the MSP Server. In this type of configuration, Indirect Contact Inbound Mode should generally be used. In this mode, the instance of the Motorola Tunnel Service will contact the devices, at the request of Workstation PCs, rather than the devices contacting the instance of the Motorola Tunnel Service. Devices can thus safely be configured with the public IP Address of the instance of the Motorola Tunnel Service since they will send it to the MSP Server but will not use it to contact the instance of the Motorola Tunnel Service themselves. If Indirect Contact Outbound Mode were used instead, then the devices would need to contact the instance of the Motorola Tunnel Service using the public IP Address. This might work, if the NAT Router were capable of detecting and routing such references properly efficiently. But not all NAT Routers can perform such routing and many cannot perform it inefficiently. And there should be no reason to use Indirect Contact Outbound Mode in this type of configuration. Since the instance of the Motorola Tunnel Service and devices are in the same inner network, Indirect Contact Inbound Mode should work fine. And Indirect Contact Inbound Mode will improve battery life and reduce network traffic.

48 40 -- Using the Motorola Tunnel Service with MSP System Deployment To deploy an MSP system that leverages the Tunnel Service to support any application which requires the contactability need, the following Tunnel Service-specific steps should be followed: 1. Identify all devices where contactability will need to be enhanced through the use of a Tunnel Service. 2. Identify the Tunnel Service Connection Type that will be used for each identified device. 3. Identify all Servers within the Enterprise network on which Tunnel Service software is required to enhance the contactability of the identified devices. 4. Identify any changes to the default Tunnel Service ports that will be required for each identified Server to comply with Enterprise security policies. 5. Install the Tunnel Service software on each identified Server and configure any identified changes to default Tunnel Service ports using the TunnelService.Configuration setting 6. Identify the groups of devices that will be contacted via the same Tunnel Service using the same Connection Type. 7. Create a TunnelAgent.Configuration Settings Object that specifies the Tunnel Service, Connection Type, and other device and Tunnel Service-specific information, for each identified group of devices. 8. Provision the Tunnel Agent Package to all devices to be used with the Tunnel Service Solution. 9. Provision the appropriate TunnelAgent.Configuration Settings Object to the devices in each identified group of devices. Once the above steps have been completed, any Tunnel Agent Patron can leverage the contactability through the Tunnel Service. Tunnel Service Status Monitoring The status of an instance of the Motorola Tunnel Service can be monitored using the MSP Console UI or using a standalone status viewer application running on the Windows PC on which that instance of the Motorola Tunnel Service is installed. These methods are described in the following sub-sections. Status Monitoring Using MSP In every Tunnel Service Plug-In check-in interval, Plug-In queries the Tunnel Service to display the following information Device Status Attribute Device ID IP address Description UUID of the device IP address of the device

49 Chapter 6 Using the Motorola Tunnel Service Device Status Attribute Status Number of Devices Number of Registered outbound devices Number of Active outbound sessions Number of Active inbound sessions Description Displays the Tunnel Service status Possible Values: Running Tunnel Service is in running state Stopped Tunnel Service is stopped Not Installed Tunnel Service Plug-In is not installed Total number of devices using Tunnel Service Total number of devices registered to Tunnel Service Total number of active outbound sessions Total number of active inbound sessions Status Monitoring Using Standalone Status Viewer Using this feature administrator can monitor the Tunnel Service connections. This is installed as part of the Tunnel Service installer To launch the Tunnel Service status viewer, use the Tunnel Service Status Viewer shortcut that was installed into the Start Menu when the Tunnel Service software was installed. This shortcut can be found at: Programs > Motorola MSP > Tunnel Service Status Viewer. Figure 5 shows the Status Viewer Window

50 42 -- Using the Motorola Tunnel Service with MSP Figure 5 - Status Viewer Window The following table shows the details that will be displayed in the Status Viewer Window: Field Device ID IP address Description UUID of the device IP address of the device

51 Chapter 6 Using the Motorola Tunnel Service Field Status Description Status of the connection Possible Values: Registered Device is registered to Tunnel Service but there is no active session (Outbound mode only) Active Device has an active remote control or Request Checkin session running (Outbound mode only) Inbound If the Remote control or Request Checkin session is established using the inbound mode Active Connections The number of active sessions for a device The user can export the list to the file in the csv format. Note: This standalone status viewer can be used to monitor any one single instance of Tunnel Service. The recommended method is to use the MSP Device status page to monitor the status attributes Best Practices The following Best Practices can be followed to help improve the overall success when using a Tunnel Service with the Motorola Remote Control Solution. Deploy the minimum number Tunnel Services required to achieve the desired enhancement of device contactability. Choose the Connection Type to be used for each device carefully: Use a Connection Type of Workstation PC contacts device (Direct Contact, without a Tunnel Service) whenever practical. Use a Connection Type of Workstation PC contacts Tunnel Service which contacts device (Indirect Contact, Inbound Mode), if possible, when Direct Contact is not practical. Use a Connection Type of Workstation PC contacts Tunnel Service which is contacted by device (Indirect Contact, Outbound Mode) only when no other Connection Type is practical. Ensure that a TunnelAgent.Configuration Settings Object is deployed to all devices to specify the Connection Type to be used for each device. Do not change the default Tunnel Service ports on a Tunnel Service unless it is required to conform to Enterprise security policies.

52 44 -- Using the Motorola Tunnel Service with MSP If the ports are changed, ensure that a TunnelAgent.Configuration Settings Object is deployed to all affected devices to configure the changed ports. End application is responsible for any end-to-end encryption. Tunnel Service only act as a pass through. Enable end-to-end encryption only when it is necessary to ensure the privacy and integrity of data, such as when connections will occur over an insecure network segment (e.g. over the internet).

53

54 Motorola Solutions, Inc. One Motorola Plaza Holtsville, New York 11742, USA Motorola Solutions, Inc E