Check Point Connectra NGX R66 CM Admin Guide

Connectra Central Management
Administration Guide Version NGX R66
TM
January 11, 2009
2003-2009 Check Point Software Technologies Ltd.

All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.
TRADEMARKS:
Please refer to http://www.checkpoint.com/copyright.html for a list of our trademarks For third party notices, see http://www.checkpoint.com/3rd_party_copyright.html.
Contents
Preface
Who Should Use This Guide.............................................................................. 16 Summary of Contents ....................................................................................... 17 Section 1 Connectra Gateway....................................................................... 17 Section 2: SecureClient Mobile .................................................................... 18 Section 3: Endpoint Connect ....................................................................... 19 Related Documentation .................................................................................... 20 More Information ............................................................................................. 22 Feedback ........................................................................................................ 23
Connectra Gateway
Chapter 1 Introduction to Connectra
Overview of Connectra ...................................................................................... 28 Connectra Applications..................................................................................... 30 Connectra Management .................................................................................... 31 SSL Network Extender...................................................................................... 32 SSL Network Extender Network Mode ........................................................... 32 SSL Network Extender Application Mode....................................................... 32 Commonly Used Concepts ................................................................................ 33 Authentication............................................................................................ 33 Authorization.............................................................................................. 33 Endpoint Compliance Scanner ..................................................................... 33 Secure Workspace....................................................................................... 34 Protection Levels ........................................................................................ 34 Session...................................................................................................... 35 Connectra Security Features ............................................................................. 36 Server Side Security Highlights .................................................................... 36 Client Side Security Highlights..................................................................... 37 User Workflow ................................................................................................. 38 Signing In .................................................................................................. 38 First time Installation of ActiveX and Java Components .................................. 39 Language Selection..................................................................................... 40 Initial Setup ............................................................................................... 40 Accessing Applications ................................................................................ 40 Getting Started With Connectra ......................................................................... 42
Chapter 2
Applications for Clientless Access

Introduction to Applications.............................................................................. 44
Table of Contents
Protection Levels ............................................................................................. 45 Using Protection Levels ............................................................................... 45 Defining Protection Levels ........................................................................... 46 Web Applications............................................................................................. 48 What is a Web Application? ......................................................................... 48 Connectra Web Applications ........................................................................ 49 Web Applications of a Specific Type ............................................................. 49 Configuring Web Applications ...................................................................... 50 File Shares...................................................................................................... 60 What is a File Share? .................................................................................. 60 File Share Viewers ...................................................................................... 60 Configuring File Shares ............................................................................... 60 Using the $$user Variable in File Shares....................................................... 64 Citrix Services ................................................................................................. 66 Understanding Citrix Services ...................................................................... 66 Citrix Deployments Modes - Unticketed and Ticketed ..................................... 66 Citrix features Supported by Connectra ......................................................... 68 Configuring Citrix Services ........................................................................... 71 Web Mail Services ........................................................................................... 78 Connectra Web Mail Services ....................................................................... 78 Web Mail Services User Experience .............................................................. 79 Incoming (IMAP) and Outgoing (SMTP) Mail Servers ...................................... 80 Configuring Mail Services ............................................................................ 80 Native Applications .......................................................................................... 84 DNS Names .................................................................................................... 85 Why Use DNS Name Objects? ...................................................................... 85 DNS Names and Aliases .............................................................................. 85 Where DNS Name Objects are Used ............................................................. 86 Defining the DNS Server used by Connectra .................................................. 86 Configuring DNS Name Objects.................................................................... 86 Using the Login Name of the Currently Logged in User ........................................ 88
Chapter 3
Single Sign On
Introduction to Single Sign On .......................................................................... 90 Supported SSO Authentication protocols............................................................ 91 HTTP Based SSO............................................................................................. 92 HTTP Based SSO Limitation ........................................................................ 92 Web Form Based SSO ...................................................................................... 93 Application Requirements for Easy Configuration ........................................... 94 Web Form Based SSO Limitations ................................................................ 94 Application and Client Support for SSO ............................................................. 95 Connectra Applications that Support SSO ..................................................... 95 Applications that Support Web Form SSO ..................................................... 95 Connectra Client Support for SSO................................................................. 95 Basic Configuration of SSO............................................................................... 96 Basic Configuration of Web Form SSO .......................................................... 97 Advanced Configuration of SSO......................................................................... 98 Configuring the Single Sign On Method......................................................... 98
Configuring Login Settings ........................................................................... 99 Advanced Configuration of Web Form SSO ....................................................... 102 Sign In Success or Failure Detection........................................................... 102 Credential Handling .................................................................................. 103
Chapter 4
Native Applications for Client-Based Access

Introduction to Native Applications.................................................................. 108 VPN Clients................................................................................................... 109 SSL Network Extender............................................................................... 109 SecureClient Mobile .................................................................................. 112 Endpoint Connect ..................................................................................... 113 Configuring VPN Clients ................................................................................. 114 Basic VPN Client Configuration .................................................................. 114 Advanced VPN Client configuration............................................................. 115 Configuring SSL Network Extender Advanced Options .................................. 117 Configuring SecureClient Mobile ................................................................ 119 Endpoint Application Types ............................................................................ 122 Application Installed on Endpoint Machine.................................................. 122 Application Runs Via a Default Browser....................................................... 122 Application Downloaded From Connectra..................................................... 123 Ensuring the Link Appears in the End-User Browser ..................................... 125 Configuring a Simple Native Application .......................................................... 127 General Properties .................................................................................... 127 Authorized Locations................................................................................. 127 Applications on the Endpoint Machine ........................................................ 128 Completing the Native Application Configuration ......................................... 129 Configuring an Advanced Native Application..................................................... 130 Configuring Connection Direction ............................................................... 130 Multiple Hosts and Services....................................................................... 131 Configuring the Endpoint Application to Run Via a Default Browser ............... 132 Automatically Starting the Application ........................................................ 133 Making an Application Available in Application Mode ................................... 134 Automatically Running Commands or Scripts............................................... 135 Configuring Downloaded-From-Connectra Endpoint Applications ........................ 138 Configuring the Telnet Client (Certified Application) ..................................... 139 Configuring the SSH Client (Certified Application) ....................................... 140 Configuring the TN3270 Client (Certified Application).................................. 140 Configuring the TN5250 Client (Certified Application).................................. 141 Configuring the Remote Desktop Client (Add-On Application) ........................ 141 Configuring the PuTTY Client (Add-On Application) ...................................... 143 Configuring the Jabber Client (Add-On Application)...................................... 143 Configuring the FTP Client (Add-On Application).......................................... 144 Adding a New Downloaded-From-Connectra Endpoint Application ...................... 145 Downloaded-from-Connectra Application Requirements ................................ 145 Procedure: Adding a New Downloaded-From-Connectra Application ............... 145 Example: Adding a New SSH Application .................................................... 148 Example: Adding a New Microsoft Remote Desktop Profile............................ 150
Table of Contents
Chapter 5
Two-Factor Authentication
Introduction to Two-Factor Authentication........................................................ 158 The SMS Service Provider............................................................................... 159 SMS Authentication Granularity ...................................................................... 160 Basic Two-Factor Authentication Configuration ................................................. 161 Obtaining the SMS provider credentials ...................................................... 161 Configuring the Phone Directory ................................................................. 161 Basic SmartDashboard Configuration of Two-Factor Authentication................ 164 Testing Two-Factor Authentication.............................................................. 165 Advanced Two-Factor Authentication Configuration ........................................... 166 Advanced Two-Factor Authentication Configuration Options .......................... 166 Two-Factor Authentication Per Gateway (Central management only) ............... 169 Two-Factor Authentication Per Application .................................................. 170
Chapter 6
Authorization
Identity and Access Management .................................................................... 174 Authorization in Connectra.............................................................................. 175 Configuring Access To Applications ................................................................. 177
Chapter 7
Endpoint Security On Demand

Endpoint Compliance Enforcement.................................................................. 180 Introduction to Endpoint Compliance Enforcement....................................... 180 Endpoint Compliance Policy Rule Types...................................................... 181 Endpoint Compliance Logs ........................................................................ 192 Workflow for Endpoint Compliance Configuration ......................................... 193 Defining the Endpoint Compliance Policy.................................................... 194 Using the ICSInfo Tool .............................................................................. 196 Configuring the Endpoint Compliance Policy ............................................... 197 Configuring Endpoint Compliance............................................................... 199 Endpoint Compliance Scanner End-User Workflow ....................................... 208 Secure Workspace ......................................................................................... 215 Introduction to Secure Workspace .............................................................. 215 Enabling Secure Workspace ....................................................................... 216 Applications Permitted by Secure Workspace............................................... 217 SSL Network Extender in Secure Workspace................................................ 219 Secure Workspace Policy Overview ............................................................. 219 Configuring the Secure Workspace Policy .................................................... 221 Secure Workspace End-User Experience...................................................... 226 Endpoint Compliance Updates ........................................................................ 231 Working with Automatic Updates................................................................ 231 Performing Manual Updates....................................................................... 233
Chapter 8
Connectra Gateway Configuration

Portal Settings............................................................................................... 236 Portal Customization ................................................................................. 236 Alternative Portal Configuration .................................................................. 238 Link Translation............................................................................................. 239
Introduction to Hostname Translation ......................................................... 239 Link Translation Per Gateway or Per Application .......................................... 240 How Hostname Translation Works............................................................... 240 Configuring Link Translation ...................................................................... 242 Portal Access with Hostname Translation .................................................... 245 Link Translation Issues.............................................................................. 246 Connectra Server Certificates .......................................................................... 247 Overview of Server Certificates ................................................................... 247 Obtaining and Installing a Trusted Server Certificate .................................... 247 Connectra Self-Signed Certificates.............................................................. 250 Viewing Connectra Certificate Details.......................................................... 252 Session Settings ............................................................................................ 254 Simultaneous Logins to the Portal .............................................................. 254 Session Timeouts...................................................................................... 258 Roaming .................................................................................................. 258 Tracking................................................................................................... 258 Securing Authentication Credentials ........................................................... 258 Changing the IP Address of a Connectra Gateway or Cluster ............................... 260 At the local machine ................................................................................. 260 Using SmartDashboard .............................................................................. 260 VPN Client and Portal Connectivity in a Single Gateway..................................... 261 Web Data compression ................................................................................... 262 Understanding Web Data compression ........................................................ 262 Configuring Data Compression.................................................................... 263
Chapter 9
Connectra Gateway Clusters

The Connectra Gateway Clustering Solution ...................................................... 266 Clustering Definitions and Terms................................................................ 266 Load Sharing ............................................................................................ 268 High Availability ....................................................................................... 268 Comparing Load sharing and High Availability ............................................. 268 Geo-Clustering of Connectra Gateways ............................................................. 270 Connectra Cluster installation and Licensing Requirements................................ 271 Synchronization Between Cluster Members....................................................... 272 Introduction to State Synchronization ......................................................... 272 The Synchronization Network ..................................................................... 272 Synchronized Cluster Restriction ................................................................ 273 Connectra Cluster Topology............................................................................. 274 Example Connectra Gateway Cluster Topology.............................................. 274 Cluster Interfaces ..................................................................................... 274 SSL Client and Portal Connectivity in a Cluster ............................................ 275 The Cluster Member IPs ............................................................................ 276 Configuring Member Networks.................................................................... 276 The Synchronization Network ..................................................................... 277 How Connectra Clusters Work ......................................................................... 278 The Cluster Control Protocol....................................................................... 278 How Load Sharing Mode Works .................................................................. 278 How High Availability Mode Works.............................................................. 280
Table of Contents
The Sticky Decision Function.......................................................................... 283 Failover ........................................................................................................ 284 What is a Failover?.................................................................................... 284 What Happens When Failover Occurs? ........................................................ 284 When Does a Failover Occur? ..................................................................... 285 Cluster Member Priority............................................................................. 286 What Happens When a Cluster Member Recovers? ....................................... 286 How a Recovered Cluster Member Obtains the Security Policy....................... 286 How Connectra Applications Behave Upon Failover ...................................... 287 Hardware Requirements and Compatibility ....................................................... 289 Connectra Cluster Hardware Requirements .................................................. 289 Connectra Cluster Hardware Compatibility ................................................... 290 Example configuration of a Cisco Catalyst Routing Switch............................. 291 Basic Connectra Cluster Configuration ............................................................. 293 Cluster Configuration Deployment Tips ................................................... 293 Configuring Cluster Member IP Addresses ................................................... 294 If the Switch is Incapable of Forwarding Multicast ....................................... 294 SmartDashboard Configuration of a Single Cluster Interface Cluster............... 295 Adding a Server Certificate to a New Cluster Member ................................... 301 Advanced Connectra Cluster Configuration ....................................................... 303 SmartDashboard Configuration of a Dual Cluster Interface Cluster ................. 303 IP Address Migration................................................................................. 306 Changing the IP Address of a Connectra Cluster or Single Gateway ................ 306 Setting Up the Default Gateway if the Virtual IP is on a Different Subnet than the Physical IPs........................................................................................... 307 Removing a Member from a Cluster ............................................................ 307
Chapter 10
Troubleshooting Connectra
Troubleshooting Web Connectivity ................................................................... 310 Troubleshooting Outlook Web Access .............................................................. 311 Troubleshooting Checklist.......................................................................... 311 Unsupported Feature List .......................................................................... 312 Common OWA problems ............................................................................ 312 1. Authentication...................................................................................... 313 2. Authorization........................................................................................ 315 3. Security Restrictions ............................................................................. 318 4. Performance Issues............................................................................... 320 5. Saving File Attachments ........................................................................ 324 Troubleshooting File Shares ............................................................................ 325 Troubleshooting Citrix .................................................................................... 326 Troubleshooting Checklist.......................................................................... 326 Common Connectra Citrix problems ............................................................ 327 Troubleshooting SSL Network Extender Connectivity ......................................... 341 General SSL Network Extender Issues......................................................... 341 SSL Network Extender Application Mode Issues........................................... 341 Ensuring Application Connectivity with Web Intelligence ................................... 343
10
Chapter 11
SecurePlatform CLI Reference

Check Point SecurePlatform Overview.............................................................. 346 Managing SecurePlatform............................................................................... 347 Standard Mode ......................................................................................... 347 Expert Mode............................................................................................. 347 Copying Files Using SCP ................................................................................ 348 Secure Shell.................................................................................................. 349 SecurePlatform Shell Commands .................................................................... 350 Expert Mode Command ............................................................................. 350 Backup and Restore .................................................................................. 350 Snapshot Image Management .................................................................... 351 Web Administration Server Control ............................................................. 352 Check Point Commands............................................................................. 353 Network Diagnostics Commands ................................................................. 354
SecureClient Mobile - VPN Client

Chapter 12 Introduction to SecureClient Mobile
SecureClient Mobile Overview ......................................................................... 358 SecureClient Mobile Features.......................................................................... 360 Security Policies and Central Enforcement ....................................................... 361 Clustered Gateway Support ............................................................................. 362
Chapter 13
SecureClient Mobile Installation and Setup

Gateway Setup .............................................................................................. 364 Overview .................................................................................................. 364 Requirements for Central Management ....................................................... 365 Setting Up SecureClient Mobile Support for Connectra Gateways................... 366 Setting Up SecureClient Mobile Support for VPN-1 Gateways........................ 367 Client Installation .......................................................................................... 372 Client Deployment Overview ....................................................................... 372 Supported Platforms ................................................................................. 372 Installation Prerequisites ........................................................................... 373 Installing SecureClient Mobile.................................................................... 373 Importing Personal Certificate .................................................................... 375 Uninstalling SecureClient Mobile................................................................ 375
Chapter 14
Central Management of SecureClient Mobile

Introduction .................................................................................................. 378 Authentication Settings .................................................................................. 379 Supported Authentication Schemes ............................................................ 379 Configuring the Authentication Method ....................................................... 380 Password Caching ..................................................................................... 381
Table of Contents
11
Authentication Timeout ............................................................................. 382 Connectivity Settings ..................................................................................... 383 Connect Mode .......................................................................................... 383 Automatic Dialup Initiation ........................................................................ 385 Automatic Disconnect ............................................................................... 386 Encryption Methods .................................................................................. 387 Routing All Traffic To the Gateway (Hub Mode) ................................................ 388 Firewall Policy ............................................................................................... 389 Configuration and Version Management ........................................................... 392 Certificates ................................................................................................... 394 Certificate Nickname................................................................................. 394 Management of Internal CA Certificates ...................................................... 394 Importing a Certificate in the Device........................................................... 395 Topology Update............................................................................................ 396 Advanced Configuration.................................................................................. 397 Configuring a Non-Centrally Managed Gateway ............................................ 397 SecureClient Mobile Database Properties .................................................... 399
Chapter 15
SecureClient Mobile Client Configuration

VPN Connections ........................................................................................... 414 Status Page.............................................................................................. 414 Initiating a VPN Connection ....................................................................... 414 Closing SecureClient Mobile ...................................................................... 415 Client Configuration ....................................................................................... 416 Connectivity Options ................................................................................. 416 Configuring Display Settings ...................................................................... 417 Firewall Policy .......................................................................................... 418 Controlling Device Connections .................................................................. 418 Troubleshooting ............................................................................................. 420 Enabling Log Files .................................................................................... 420 Viewing Network Configuration ................................................................... 420 Error Messages ......................................................................................... 421 Additional Resources ..................................................................................... 423
Chapter 16
SecureClient Mobile Package Management

Client Deployment, Repackaging and Upgrading ............................................... 426 Post-Installation / Post-Uninstallation Scripts ................................................... 426 Package Customization................................................................................... 427 Adding a File to a CAB Package ................................................................. 428 Deleting a File from a CAB Package............................................................ 429 Exporting the Client Configuration .............................................................. 429 Defining the Client Installation Version ....................................................... 430 Creating a CAB Package ............................................................................ 431 Creating an MSI Package........................................................................... 431 Configuring the SAA Plug-in ...................................................................... 432
12
Chapter 17
SecureClient Mobile Client API

Introduction .................................................................................................. 436 Function Return Codes ................................................................................... 437 Functions...................................................................................................... 438
Endpoint Connect - VPN Client

Chapter 18 Endpoint Connect
Introduction .................................................................................................. 450 Why Endpoint Connect?............................................................................. 450 Capabilities .............................................................................................. 450 Installation and Use .................................................................................. 452 Administration.......................................................................................... 453 Configuring the Gateway ................................................................................. 454 Configuring the Gateway for Endpoint Connect............................................. 454 Working with RSA Hard and Soft Tokens ..................................................... 460 Configuring Logging Options for Client Users ............................................... 461 Disabling CAPI Authentication ................................................................... 461 Disabling DNS-based Geo-Cluster Name Resolution ..................................... 462 Configuring Endpoint Compliance Checks ................................................... 463 NAT Traversal........................................................................................... 463 Using the Packaging Tool ............................................................................... 465
Chapter 19
Endpoint Connect API

Introduction to the Client OPSEC API ......................................................... Function Return Codes .............................................................................. Client Functions Communicating with Service.............................................. Notification Identifiers .............................................................................. Functions from Service to Client................................................................. 468 469 470 479 485
Index........................................................................................................... 501
Table of Contents
13
14
Preface
Preface
P
page 16 page 17 page 20 page 22 page 23
In This Chapter
Who Should Use This Guide Summary of Contents Related Documentation More Information Feedback
15
Who Should Use This Guide
Who Should Use This Guide

This guide is intended for administrators responsible for maintaining remote access and user security in an enterprise, including policy management and user support. This guide assumes a basic understanding of: System administration. The underlying operating system. Internet protocols (IP, TCP, UDP etc.).
16
Summary of Contents
Summary of Contents
This guide contains the following sections and chapters:
Section 1 Connectra Gateway

Chapter Chapter 1, Introduction to Connectra Chapter 2, Applications for Clientless Access Chapter 3, Single Sign On Chapter 4, Native Applications for Client-Based Access Chapter 5, Two-Factor Authentication Description Connectra, feature summary and user workflow summary. Web Applications, File Shares, Citrix Applications and Web Mail services. HTTP based and Web form based Single Sign On for applications for clientless acess. Native Applications are IP-based applications, hosted on servers within the organization, that requires an installed client on the endpoint to access the application and encrypt traffic. Two-factor authentication requires users to provide additional credentials before they can access Connectra. A One Time Password is sent to their mobile communications device via an SMS message. Access to Application rules define the user groups that are authorized to access Connectra applications, per Conenctra gateway. The Endpoint Compliance Scanner scans the endpoint for potentially harmful software and ensures it complies with a policy. Secure Workspace provides a secure virtual environment on endpoint computers that is segregated from the real workspace. A variety of Connectra gateway configuration issues such as changing the IP Address of a Connectra gateway or cluster, SSL client and portal connectivity in a single gateway, portal configuration, Connectra server certificates, session security, and Web data compression.
Chapter 6, Authorization
Chapter 7, Endpoint Security On Demand
Chapter 8, Connectra Gateway Configuration
Chapter
Preface
17
Section 2: SecureClient Mobile
Chapter Chapter 9, Connectra Gateway Clusters
Description ClusterXL Connectra gateway cluster provide high availability and load sharing to ensure reliable and high performance operation of Connectra. Guidelines for findinng solutions for specific issues. Areas covered include Web Connectivity, Outlook Web Access, File Shares, Citrix and SSL Network Extender Connectivity, and ensuring application connectivity with Web Intelligence. Command line reference for the Connectra SecurePlatform operating system.
Chapter 10, Troubleshooting Connectra
Chapter 11, SecurePlatform CLI Reference
Section 2: SecureClient Mobile

Chapter Chapter 12, Introduction to SecureClient Mobile Chapter 13, SecureClient Mobile Installation and Setup Chapter 14, Central Management of SecureClient Mobile Chapter 15, SecureClient Mobile Client Configuration Chapter 16, SecureClient Mobile Package Management Chapter 17, SecureClient Mobile Client API Description Overview of the gateway and client features included in SecureClient Mobile. Initial set up and required configuration of the Gateway and Client. Understanding and configuring SecureClient Mobile on the gateway. Understanding and configuring the SecureClient Mobile client. Configuring SecureClient Mobile client settings by customizing the installation package. The API functions available for SecureClient Mobile configuration.
18
Section 3: Endpoint Connect
Section 3: Endpoint Connect

Chapter Chapter 18, Endpoint Connect Chapter 19, Endpoint Connect API Description Administering and customizing the Endpoint VPN client. The OPSEC API for embedded custom client integrations.
Chapter
Preface
19
Related Documentation
Related Documentation
This release includes the following documentation related to managing Connectra NGX R66 from SmartCenter version NGX R66:
TABLE P-1 VPN-1 Power documentation suite documentation
Title Internet Security Product Suite Getting Started Guide
Description Contains an overview of NGX R66 and step by step product installation and upgrade procedures. This document also provides information about Whats New, Licenses, Minimum hardware and software requirements. Explains all available upgrade paths for Check Point products from VPN-1/FireWall-1 NG forward. This guide is specifically geared towards upgrading to NGX R66. Explains SmartCenter Management solutions. This guide provides solutions for control over configuring, managing, and monitoring security deployments at the perimeter, inside the network, at all user endpoints. Describes how to control and secure network access; establish network connectivity; use SmartDefense to protect against network and application level attacks; use Web Intelligence to protect web servers and applications; the integrated web security capabilities; use Content Vectoring Protocol (CVP) applications for anti-virus protection, and URL Filtering (UFP) applications for limiting access to web sites; secure VoIP traffic. This guide describes the basic components of a VPN and provides the background for the technology that comprises the VPN infrastructure.
Upgrade Guide
SmartCenter Administration Guide
Firewall and SmartDefense Administration Guide
Virtual Private Networks Administration Guide
20
Related Documentation TABLE P-1 VPN-1 Power documentation suite documentation (continued)
Title Eventia Reporter Administration Guide
Description Explains how to monitor and audit traffic, and generate detailed or summarized reports in the format of your choice (such as list, vertical bar, pie chart) for all events logged by Check Point VPN-1 Power, SecureClient and SmartDefense. Explains how to install and configure SecurePlatform. This guide will also teach you how to manage your SecurePlatform machine and explains Dynamic Routing (Unicast and Multicast) protocols. Explains the Provider-1/SiteManager-1 security management solution. This guide provides details about a three-tier, multi-policy management architecture and a host of Network Operating Center oriented features that automate time-consuming repetitive tasks common in Network Operating Center environments.
SecurePlatform/ SecurePlatform Pro Administration Guide
Provider-1/SiteManager-1 Administration Guide
Chapter
Preface
21
More Information
More Information
For additional technical information about Check Point products, and for the latest version of this document, see the Check Point Support Center at http://support.checkpoint.com/.
22
Feedback
Feedback
Check Point is engaged in a continuous effort to improve its documentation. Please help us by sending your comments to: cp_techpub_feedback@checkpoint.com
Chapter
Preface
23
Feedback
24
Connectra Gateway
Chapter Introduction to Connectra

In This Chapter
Overview of Connectra Connectra Applications SSL Network Extender Commonly Used Concepts Connectra Security Features User Workflow Getting Started With Connectra
1
page 28 page 30 page 32 page 33 page 36 page 38 page 42
27
Overview of Connectra
Check Point Connectra is a comprehensive and unified remote access solution that makes corporate applications and network resources securely available to mobile and remote users. Remote and mobile employees, contractors, business partners and customers can access network resources and applications through either a lightweight VPN client or simply through a Web browser. By unifying SSL and IPSec VPN technologies into a single gateway and management console Connectra provides flexible access for end users and simple, streamlined deployment for IT. Connectra offers administrators tight access controls to help ensure that only authorized users using clean hosts will gain access to corporate resources. To that end Connectra features multiple strong authentication methods and tight integration with directory services, as well as comprehensive endpoint security capabilities enabling malware scans, compliance checks, and a virtual Secure Workspace providing session confidentiality on both managed and unmanaged endpoints such as laptops, home PCs, internet kiosks and more. Connectra can be deployed as either a turnkey appliance, as software on open servers, or as a virtual appliance on VMware ESX Server. Connectra gateways can be managed either standalone or centrally through a single Check Point SMART management console, reducing the administration time required to configure, monitor, update and audit remote access policies. Benefits: Increases productivity by allowing workers to work anywhere, anytime Provides secure and flexible remote access tailored to user needs Includes tight, uniform access controls across all access methods Ensures only safe endpoints are allowed to access network Safeguards confidentiality of corporate information Protects internal network and applications from attack Provides the multiple deployment choices including as a virtual appliance Helps ensure business continuity Unified IPsec and SSL solution reduces Total Cost of Ownership (TCO)
Features: Unified, flexible remote access Unified security management
28
Comprehensive endpoint security Integrated Intrusion Prevention Superior user experience, with intelligent auto-connect, location awareness, and roaming Strong authentication methods including innovative SMS One-Time Password Flexible deployment options, including deployment on VMware ESX Best-in-class performance and scalability
Chapter 1
Introduction to Connectra
29
Connectra Applications
Connectra Applications
Connectra provides the remote user with access to the various corporate applications, including, Web Applications, File Shares, Citrix services, Web Mail and Native Applications. A Web application can be defined as a set of URLs that are used in the same context and that is accessed via a Web browser, for example inventory management, or HR management. A file share defines a collection of files, made available across the network by means of a protocol, such as SMB for Windows, that enables actions on files, such as opening, reading, writing and deleting files across the network. Connectra supports Citrix client connectivity to internal MetaFrame servers. In this type of deployment, Connectra functions as a Secure Gateway. Connectra supports Web Mail services including: Built-in Web Mail: Web Mail services give users access to corporate mail servers via the browser. Connectra provides a front end for any email server that supports the IMAP and SMTP protocols. Other Web-based mail services, such as Outlook Web Access (OWA) and IBM Lotus Domino Web Access (iNotes). Connectra relays the session between the client and the OWA server.
Connectra supports any Native Application, via the SSL Network Extender. A Native Application is any IP-based application that is hosted on servers within the organization. When a user is allowed to use a native application, Connectra launches SSL Network Extender and allows users to employ native clients to connect to native applications, while ensuring that all traffic is encrypted.
Remote users initiate a standard HTTPS request to the Connectra Gateway, authenticating via username/password, certificates, or some other method such as SecurID. Users are placed in groups and these groups are given access to a number of applications. For information about Web Applications, File Shares, Citrix services, Web Mail see Applications for Clientless Access on page 43. For information about Native Applications, see Native Applications for Client-Based Access on page 107.
30
Connectra Management
Connectra Management
Centrally managed Connectra gateways are managed by a SmartCenter server that can manage other Check Point gateways. Locally managed Connectra is a standalone, self-managed Connectra gateway. All Connectra related configuration is performed from the Connectra tab of SmartDashboard. Connectra users are shown in SmartConsole, along with real-time counters, and history counters for monitoring purposes. SmartDefense Updates are downloaded using the SmartDefense tab of SmartDashboard. A Connectra-specific SmartDefense profile is used for all Connectra related SmartDefense configuration. Connectra supports SNMP. Status information regarding Check Point products can be obtained using a regular SNMP Network Management Station (NMS) that communicates with SNMP agents on Connectra gateways. See Working with SNMP Management Tools in the SmartCenter Administration Guide.
Chapter 1
31
SSL Network Extender

The SSL Network Extender client makes it possible to access Native Applications via Connectra. SSL Network Extender is downloaded automatically from the Connectra portal to the endpoint machines, so that client software does not have to be pre-installed and configured on users' PCs and laptops. SSL Network Extender tunnels application traffic using a secure, encrypted and authenticated SSL tunnel to the Connectra gateway.
SSL Network Extender Network Mode

The SSL Network Extender Network Mode client provides secure remote access for all application types (both Native-IP-based and Web-based) in the internal network via SSL tunneling. To install the Network Mode client, users must have administrator privileges on the client computer. After installing the client, an authenticated user can access any authorized internal resource that is defined on Connectra as a Native Application. The user can access the resource by launching the client application, either directly from the desktop or from the Connectra portal.
SSL Network Extender Application Mode

The SSL Network Extender Application Mode client provides secure remote access for most application types (both Native (IP-based) and Web-based) in the internal network via SSL tunneling. Most TCP applications can be accessed in Application Mode. The user does not require administrator privileges on the endpoint machine. After the client is installed the user can access any internal resource that is defined on Connectra as a Native Application. The application must be launched from the Connectra portal and not from the users desktop.
32
Commonly Used Concepts
Commonly Used Concepts

This section briefly describes commonly used concepts that you will encounter when dealing with Connectra.
Authentication
All remote users accessing the Connectra portal must be authenticated by one of the supported authentication methods. As well as being authenticated through the internal Connectra database, remote users may also be authenticated via LDAP, RADIUS, ACE (SecurID), or certificates. Note - Centrally managed Connectra only: For information about Authentication schemes, and configuration of authentication servers, see the Authentication chapter of the Firewall and SmartDefense Administration Guide. LDAP, see the SmartDirectory (LDAP) and User Management chapter in the SmartCenter Administration Guide.
Authorization
Authorization determines if and how remote users access the internal applications on the corporate LAN. If the remote user is not authorized, he/she will not be granted access to the services provided by the Connectra gateway. After being authenticated, the user will attempt to use an application. To access a particular application, the user must be authorized to do so. The user must belong to a group that has been granted access to the given application. In addition, the user must satisfy the security requirements of the application, such as authentication method and endpoint health compliance. For more information, refer to Authorization on page 173.
Endpoint Compliance Scanner

The Endpoint Compliance Scanner component of Check Point Endpoint Security On Demand scans endpoint computers for potentially harmful software and keyloggers, and optionally, for the presence of Antivirus software. Connectra can be configured to allow users to access a Web site or resource via the Connectra portal only if they successfully pass an Endpoint Compliance scan. By detecting spyware and other
Chapter 1
33
Secure Workspace
malware, Endpoint Security On Demand ensures compliance with corporate security policies and protects enterprises from threats emanating from unsecured client computers that can result in data loss and identity theft. When end users access the Connectra Portal for the first time, an ActiveX component that scans the client computer. If the client computer successfully passes the scan (i.e. there are no malware threats and has an approved antivirus application), the user is granted access to the Connectra portal. The scan results are presented both to the Connectra gateway and to the end user. When Endpoint Security On Demand detects such threats, it either rejects the connection or allows the user to choose whether or not to proceed, according to the Endpoint Compliance policies. The system administrator defines policies that determine which types of threats to detect and what action to take upon their detection. For more information, refer to Endpoint Compliance Enforcement on page 180.
Secure Workspace
End-users can utilize Check Points proprietary virtual desktop that enables data protection during user-sessions, and enables cache wiping, after the sessions have ended. Secure Workspace protects all session-specific data accumulated on the client side. It uses protected disk space and file encryption to secure files created during the access session. Afterwards, it cleans the protected session cache, eliminating any exposure of proprietary data that would have been inadvertently left on public PCs. For more information, refer to Secure Workspace on page 215.
Protection Levels
Protection Levels balance between connectivity and security. The Protection Level represents a security criterion that must be satisfied by the remote user before access is given. For example, an application may have a Protection Level, which requires users to satisfy a specific authentication method. Out of the box, Connectra has three pre-defined Protection Levels Permissive, Normal and Restrictive. It is possible to edit Protection Level settings, and define new Protection Levels. For more information, refer to Protection Levels on page 45.
34
Session
Session
Once authenticated, remote users are assigned a Connectra session. The session provides the context in which Connectra processes all subsequent requests until the user logs out, or the session ends due to a time-out. . For more information refer to Session Settings on page 254.
Chapter 1
35
Connectra Security Features
Connectra Security Features

Greater access and connectivity demands a higher level of security. The Connectra security features may be grouped as server side security and client side security.
Server Side Security Highlights

The following list outlines the security highlights and enhancements available on the Connectra gateway: 1. SmartDefense protects organizations from all known, and most unknown network attacks using intelligent security technology. The Web Intelligence component of SmartDefense enables protection against malicious code transferred in Web-related applications: worms, various attacks such as Cross Site Scripting, buffer overflows, SQL injections, Command injections, Directory traversal, and http code inspection. For Connectra, a default SmartDefense Profile (called Connectra_Default_Protection) is preconfigured with settings that are appropriate for Connectra. SmartDefense Profiles are available for all NGX R62CM gateways and above. Earlier versions of Connectra gateway do not receive a SmartDefense Profile. For more information, see SmartDefense in the FireWall and SmartDefense Administration Guide. 2. SmartDefense Service downloads new defense mechanisms to the SmartDefense console, and brings existing defense mechanisms up-to-date. 3. Granular authorization policy limits which users are granted access to which applications by enforcing authentication, encryption, and client security requirements. For more information, refer to Authorization on page 173. 4. Web Application support over HTTPS all traffic to Web-based applications is encrypted using HTTPS. Access is allowed for a specific application set rather than full network-level access. 5. Fully integrated with the hardened Check Point operating system: SecurePlatform. For more information, refer to SecurePlatform CLI Reference on page 345. 6. Encryption: SSL Network Extender, used by Connectra, typically encrypts traffic using the 3DES or the RC4 encryption algorithm.
36
Client Side Security Highlights
For more information, refer to Configuring SSL Network Extender Advanced Options on page 117.
Client Side Security Highlights

The following list outlines the security highlights and enhancements available on the client side: 1. Implements Endpoint Compliance for Connectra on the endpoint machine: Preventing threats posed by Malware types, such as Worms, Trojan horses, Hacker's tools, Key loggers, Browser plug-ins, Adwares, Third party cookies, and so forth. For more information, refer to Endpoint Compliance Enforcement on page 180. 2. Secure Workspace protects all session-specific data, accumulated on the client side. End-users can utilize Check Points proprietary virtual desktop that prevents data leakage, by encrypting all files and wiping it at the end of the user session. The administrator can configure Connectra (via Protection Levels) to force clients to use Secure Workspace when accessing the user portal or sensitive applications. For more information, refer to Secure Workspace on page 215. 3. Controls browser caching: You can decide what Web content may be cached by browsers, when accessing Web applications associated with a given Protection Level. Disabling browser caching can help prevent unauthorized access to sensitive information, thus contributing to overall information security. For more information, refer to Web Application Single Sign-On Page on page 55. 4. Captures cookies sent to the remote client by the internal Web server: Cookies provide a way of maintaining state information between clients and servers. A cookie is a text file placed on the clients hard drive by the Web server. Cookies contain information, such as login or registration information. If cookies are stolen they may be used to impersonate a user. For this reason, Connectra captures the cookies and maintains them on the gateway. Connectra simulates user/Web server cookie transmission by appending the cookie information, stored on Connectra, to the request that Connectra makes to the internal Web server, in the name of the remote user. 5. Supports strong authentication methods: For example, using SecurID tokens and SSL client certificates.
Chapter 1
37
User Workflow
User Workflow
In This Section:
Signing In First time Installation of ActiveX and Java Components Language Selection Initial Setup Accessing Applications The user workflow comprises the following steps: 1. Signing In and selecting the portal language 2. On first-time use, installation of ActiveX and Java Components. 3. Initial Setup 4. Accessing Applications page 38 page 39 page 40 page 40 page 40
Signing In
Using a browser, the user types in the URL, assigned by the system administrator, for the Connectra Gateway. Tip Various popup blockers may interfere with various aspects of portal functionality. You should recommend to users that they configure popup blockers to allow popups from Connectra.
If the Administrator has configured Secure Workspace to be optional, users can choose to select it on the sign in page. Users enter their authentication credentials and click Sign In. Before Connectra gives access to the applications on the LAN, the credentials of remote users are first validated. Connectra authenticates the users either through its own internal database, LDAP, RADIUS or RSA ACE/Servers. Once the remote users have been authenticated, and associated with Connectra groups, access is given to corporate applications. Note - If the Endpoint Compliance Scanner is enabled, the user may be required to pass a verification scan on his/her computer, before being granted access to the Connectra Sign In page, which ensures that his/her credentials are not compromised by 3rd party malicious software.
38
First time Installation of ActiveX and Java Components
First time Installation of ActiveX and Java Components

Some Connectra components such as the endpoint Compliance Scanner, Secure Workspace and SSL Network Extender require either an ActiveX component (for Windows with Internet Explorer machines) or a Java component to be installed on the endpoint machine. When using one of these components for the first time on an endpoint machine using Windows and Internet Explorer, Connectra tries to install them using ActiveX. However, Internet Explorer may prevent the ActiveX installation because the user does not have Power User privileges, or display a yellow bar at the top of the page asking the user to explicitly allow the installation. The user is then instructed to click the yellow bar, or if having problems doing so, to follow a dedicated link. This link is used to install the required component using Java.
Once the first of these components is installed, any other components are installed in the same way. For example, if the Endpoint compliance Scanner was installed using Java on Internet Explorer, Secure Workspace and SSL Network Extender are also installed using Java. Note - To install using ActiveX after a component was installed using Java, delete the browser cookies.
Chapter 1
39
Language Selection
Language Selection
The user portal can be viewed in several languages. The default language is English. To use non-English languages, a language pack may be required. To install a language pack, see the release notes for that language pack. Supported languages include: Bulgarian Chinese Simplified Chinese Traditional English Finnish French German Italian Japanese Polish Romanian Russian Spanish
Initial Setup
The user may be required to configure certain settings, such as application credentials. In addition, the user can define additional favorites for commonly used applications.
Accessing Applications
After the remote users have logged onto the Connectra gateway, they are presented with a portal. The user portal enables access to the internal applications that the administrator has configured as available from within the organization, and that the user is authorized to use.
40
Accessing Applications
Figure 1-1
Connectra Portal
Chapter 1
41
Getting Started With Connectra
Getting Started With Connectra

See the Connectra Getting Started guide for guidelines on: Deploying Connectra in a LAN or in a DMZ. Setting Up Connectra as a standalone gateway or (for Centrally managed Connectra only) as a high availability or load sharing cluster. Performing a fresh installation of Connectra. Upgrading Connectra.
42
2 Chapter Applications for Clientless Access

In This Chapter
Introduction to Applications Protection Levels Web Applications File Shares Citrix Services Web Mail Services Native Applications DNS Names Using the Login Name of the Currently Logged in User page 44 page 45 page 48 page 60 page 66 page 78 page 84 page 85 page 88
43
Introduction to Applications
Introduction to Applications
Giving remote users access to the internal network exposes the network to external threats. A balance needs to be struck between connectivity and security. In all cases, strict authentication and authorization is needed to ensure that only the right people gain access to the corporate network. Defining an application is about deciding which internal LAN applications to expose to what kind of remote user. Connectra provides secure remote access to applications on the corporate LAN. See the following location for guideline on configuring Connectra applications: Web Applications on page 48. File Shares on page 60. Citrix Services on page 66. Web Mail Services on page 78. chapter 4, Native Applications for Client-Based Access on page 107.
44
Protection Levels
Protection Levels
Protection Levels are predefined sets of security settings that offer a balance between connectivity and security. Protection Levels allow Connectra administrators to define application protections for groups of applications with similar requirements. Connectra comes with three default Protection Levels Normal, Restrictive, and Permissive. You can create additional Protection Levels and change the protections for existing Protection Levels.
Using Protection Levels

Protection Levels can be used in the definition of Connectra Web Applications, File Shares, Citrix Applications or Web Mail service. Every application of one of these types can have a Protection Level associated with it. A single Protection Level can be assigned for all Native Applications. When defining an application, in the Protection Level page of the application object, you can choose: Security Requirements for Accessing this Application: This application relies on the security requirements of the gateway Rely on the gateway security requirement. Users who have been authorized to the portal, are authorized to this application. This is the default option. This application has additional security requirements specific to the following protection level Associate the Protection Level with the application. Users are required to be compliant with the security requirement for this application in addition to the requirements of the portal.
Protection Level Page of the File Share Application Object
Figure 2-1
Chapter 2
45
Defining Protection Levels

To define an Protection Level: 1. From the Connectra tab in SmartDashboard, select the Additional Settings > Protection Levels page from the navigation tree. Figure 2-2
Protection Levels Page
2. Click New to create a new Protection Level or double-click an existing Protection Level to modify it. The Protection Levels window opens, displaying the General Properties page. Figure 2-3
Protection Level Window
3. Enter a unique name for the Protection Level (for a new Protection Level only), select a display color and optionally add a comment in the appropriate fields. 4. Click on Authentication in the navigation tree and select one or more authentication methods from the available choices. Users accessing an application with this Protection Level must use one of the selected authentication schemes. 5. If required, select User must successfully authenticate via SMS.
46
6. Click Endpoint Security in the navigation tree and select one or both of the following options: Applications using this Protection Level can only be accessed if the endpoint machine complies with the following Endpoint compliance policy. Also, select a policy. This option allows access to the associated application only if the scanned client computer complies with the selected policy. Applications using this Protection Level can only be accesses from within Secure Workspace. This option requires Secure Workspace to be running on the client computer.
7. Click OK to close the Protection Level window 8. Install the Security Policy.
Chapter 2
47
Web Applications
Web Applications
In This Section
What is a Web Application? Connectra Web Applications Web Applications of a Specific Type Configuring Web Applications page 48 page 49 page 49 page 50
What is a Web Application?

A Web Application can be defined as a set of URLs that are used in the same context and are accessed via a Web browser, for example, inventory management or human resource management. Connectra supports browsing to Web sites that use HTML and JavaScript. Browsing to Web sites with VBScript, Java, or Flash elements that contain embedded links is supported using SSL Network Extender, by defining the application as a Native Application. Additionally, some sites will only work via a default browser, and so cannot be defined as a Web Application. If that is the case, use a Native Application. See Configuring the Endpoint Application to Run Via a Default Browser on page 132.
48
Connectra Web Applications
Connectra Web Applications

When creating a Connectra Web application, you give the application a name, define servers using host or a DNS names, specific directories, specific services, and an associated Protection Level. For example, the definition in Table 2-1 turns the Example website into a single Web Application. Table 2-1 Name
Single Web Site
DNS Name or Host IP www.example.com
Directories
Services
Endpoint Compliance Profile Permissive
Example
Any
HTTP, HTTPS
Tip - You can define an application using a DNS name suffix, such as *.example.com, rather than a specific DNS name. This means that every URL ending with example.com is included in this application. In this case, the match is only for *.example.com, not *.*.example.com. Also, *.a.b will match to c.a.b, but not to c.d.a.b. The same host with a different directory (Table 2-2) constitutes a separate Web application: Table 2-2 Name
Web Application With The Same Host, Different Directory
DNS Name or Host IP www.example.com
Directories
Services
Endpoint Compliance Profile Permissive
Example
/wwserver/
HTTP, HTTPS
Web Applications of a Specific Type

It is possible to configure a Web Application with a specific type. Either as a Domino Web Access (iNotes) application or as a Outlook Web Access application.
Chapter 2
49
Configuring Web Applications
Domino Web Access

IBM Lotus Domino Web Access (previously called iNotes Web Access) is a Web application that provides access to a number of services including mail, contacts, calendar, scheduling, and collaboration services. Note 1. Domino Web Access requires its files to be temporarily cached by the client-side browser. As a result, the endpoint machine browser caching settings of the Connectra Protection Level do not apply to these files. 2. To allow connectivity, the cross site scripting, command injection and SQL injection Web Intelligence protections are disabled for Domino Web Access
The following Domino Web Access features are not supported: Working offline Notebooks with attachments. Color button in the Mail Composition window. Text-alignment buttons in the Mail Composition window. Decline, Propose new time and Delegate options in meeting notices. Online help (partial support is available).
Outlook Web Access

Outlook Web Access (OWA) is a Web-based mail service, with the look, feel and functionality of Microsoft Outlook. It provides a Web environment for users to access Exchange data, via an Internet browser. OWA combines the usability of Microsoft Outlook with the ease of operation of a browser. OWA functionality encompasses basic messaging components such as e-mail, calendaring, and contacts. Connectra supports Outlook Web Access versions 2000, 2003 SP1 and 2007.

To configure a Web Application: 1. In the Connectra tab navigation tree, select Applications > Web Applications. 2. Click New. The Web Application window opens. The following sections explain the fields in each page.
50
In This Section
Web Application General Properties Page Web Application Authorized Locations Page Web Application Link in Portal Page Using the Login name of the Currently Logged In User Web Application Single Sign-On Page Web Application Protection Level Page Web Application Link Translation Page Completing the Configuration of the Web Application Configuring a Proxy per Web Application Configuring Connectra to Forward Customized HTTP Headers page 51 page 52 page 53 page 54 page 55 page 55 page 57 page 58 page 58 page 58
Web Application General Properties Page

Go to the General Properties page
Fill in the fields on the page: Name is the name of the application. Note that the name of the application that appears in the user portal is defined in the Link in Portal page. This application has a specific type: Select this option if the Web application is of one of the following types:
Chapter 2
51
Domino Web Access is a Web application that provides access to a number of services including mail, contacts, calendar, scheduling, and collaboration services.
Note 1. Domino Web Access requires its files to be temporarily cached by the client-side browser. As a result, the endpoint machine browser caching settings of the Connectra Endpoint Compliance Profile do not apply to these files. 2. To allow connectivity, the cross site scripting, command injection and SQL injection Web Intelligence protections are disabled for Domino Web Access.
Outlook Web Access (OWA) is a Web-based mail service, with the look, feel and functionality of Microsoft Outlook. OWA functionality encompasses basic messaging components such as email, calendaring, and contacts.
Web Application Authorized Locations Page

Go to the Authorized Locations page.
Fill in the fields on the page: Host or DNS name on which the application is hosted. Allow access to any directory gives the user access to all locations on the application server defined in Servers.
52
Allow access to specific directories restricts user access to specific directories. For example /finance/data/. The paths can include $$user, which is the name of the currently logged-in user. Note 1. For an Outlook Web Access application, the following are typical default paths: Private Mailboxes: /exchange/ Graphics and Controls: /exchweb/ Client access to Exchange Server 2007: /owa/ Public Folders: /public/ 2. When two or more overlapping applications are configured (for example, one for any directory and one for a specific directory on the same host), it is undefined which application settings take effect
Application paths are case sensitive improves security. Use this setting for UNIX-based Web servers that are case sensitive. Services that are allowed are typically http for cleartext access to the Web application, and https for SSL access.
Web Application Link in Portal Page

Go to the Link in Portal page.
Fill in the fields on the page: Add a link to this Web application/file share in the Connectra portal (Web Application without a specific type). If you do not enter a link, users will be able to access the application by typing its URL in the user portal, but will not have a pre-configured link to access it. This application requires a link in the Connectra portal (Web Application with a specific type), otherwise it cannot be accessed. Link text (multi-language) is shown in the Connectra Portal. Can include $$user, which represents the username of the currently logged-in user. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal.
Chapter 2
53
URL is the link to the location of the application. Can include $$user, which represents the username of the currently logged-in user. For example, a URL that is defined as http://host/$$user appears for user aa as http://host/aa and for user bb as http://host/bb. Tooltip (multi-language) for additional information about the application. Can include $$user, which represents the username of the currently logged-in user. The text appears automatically when the user pauses the mouse pointer over the link and disappears when the user clicks a mouse button or moves the pointer away from the link.
Using the Login name of the Currently Logged In User

Connectra applications can be configured to depend on the username of the currently logged-in user. For example, portal links can include the name of the user, and a file-share can include the users home directory. For this purpose, the $$user directive is used. During a Connectra session, $$user resolves to the login name of the currently logged-in user. For such personalized configurations insert the $$user string into the relevant location in the definitions of Web Applications, File Shares and Native Applications. For example, a Web Application URL that is defined as http://host/$$user appears for user aa as http://host/aa and for user bb as http://host/bb. If the user authenticates with a certificate, $$user resolves during the users login process to the username that is extracted from the certificate and authorized by the directory server.
54
Web Application Single Sign-On Page

Go to the Single Sign-On page.
For configuration details, see chapter 3, Single Sign On on page 89.
Web Application Protection Level Page

Go to the Protection Level page.
Chapter 2
55
Fill in the fields on the page: Security Requirements for Accessing this Application allows you to EITHER allow access to this application to any endpoint machine that complies with the security requirements of the gateway, OR make access to the application conditional on the endpoint being compliant with the selected Endpoint Compliance Profile.
Browser Caching on the Endpoint Machine allows you to control caching of web application content in the remote users browser. Allow caching of all content is the recommended setting when using the Hostname Translation method of Link Translation. This setting allows Web sites that use ActiveX and streaming media to work with Hostname Translation. Prevent caching of all content improves security for remote users accessing a Web Application from a workstation that is not under their full control, by making sure that no personal information is stored on the endpoint machine. On the other hand, this setting prevents users opening files that require an external viewer application (for example, a Word or a PDF file), and may cause some applications relying on caching of files to malfunction.
Configuring Web Content Caching

Protection Levels allow administrators to prevent browsers from caching Web content. The caching feature in most browsers presents a security risk because cache contents are easily accessible to hackers. However, when the Prevent caching of all content option is enabled, users may not be able to open files that require an external viewer application (for example, a Word or PDF file). This requires the user to first save the file locally. To allow opening such files, perform the following steps: 1. Configure the Protection Level to Allow caching of all content. 2. To allow caching Microsoft Office documents, add them to the HTML caching category by editing the Apache configuration file $CVPNDIR/conf/httpd.conf and uncommenting the CvpnCacheGroups directives dealing with Microsoft Office documents. Perform the following steps: a. Execute the 'cvpnstop' command. b. Backup and edit the 'httpd.conf' file. c. In cluster setups, repeat these steps for all cluster members.
56
d. Execute the 'cvpnstart' command. 3. Install the policy.
Web Application Link Translation Page

Go to the Link Translation page.
Choose the Link Translation method used by Connectra to access this application. Use the method specified in the Connectra through which this application is accessed uses the method configured in the: For locally managed Connectra: Connectra gateway object Link Translation page, in the Default Translation Method section. For centrally managed Connectra: SmartDashboard Additional Settings > Link Translation page, in the Link Translation Settings on Connectra Gateways section. Using the following method is the Link translation method that will always be used for this application. Either URL Translation, which is supported by the Connectra gateway with no further configuration, or Hostname Translation, for which further configuration is required. See Preparing Connectra for Hostname Translation on page 242.
Chapter 2
57
Completing the Configuration of the Web Application

1. Go to the Access to Application page of the Connectra tab.
2. In the Access to Application page, associate: User groups. Applications that the users in those user groups are allowed to access. Install On are the Connectra gateways and gateway clusters that users in those user groups are allowed to connect to.
3. From the SmartDashboard main menu, choose Policy > Install... and install the Policy on the Connectra gateways.
Configuring a Proxy per Web Application

It is possible to define an HTTP or HTTPS proxy server per Web application. This configuration allows additional control of access to Web resources allowed to users. For configuration details see SecureKnowledge solution sk34810.
Configuring Connectra to Forward Customized HTTP Headers

For proprietary Web applications that do not support a standard HTTP authentication method, the CvpnAddHeader directive can be used to forward end-user credentials (username and IP address) that are carried in the HTTP header. To configure Connectra to automatically forward a customized HTTP header, with a specified value, such as the username or the client IP address: 1. Edit $CVPNDIR/conf/httpd.conf. For a Connectra cluster, edit all members.
58
2. Add or edit the line containing CvpnAddHeader according to the following syntax:
CvpnAddHeader "customized_header_name" "customized_header_value"

You can use the following two macros for the customized_header_value string:
$CLIENTIP, which is resolved to the actual IP address of the end-user's client machine. $USERNAME which is resolved to the username entered as a credential in the login page
Examples:
CvpnAddHeader "CustomHTTPHeaderName" "MyCustomHTTPHeaderValue" CvpnAddHeader "CustomIPHeader" "$CLIENTIP" CvpnAddHeader "CustomUsernameHeader" "$USERNAME"
Chapter 2
59
File Shares
File Shares
In This Section
What is a File Share? File Share Viewers Configuring File Shares Using the $$user Variable in File Shares page 60 page 60 page 60 page 64
What is a File Share?

A file share is a way of making files across the network by means of a file sharing protocol. A file sharing protocol is a high-level network protocol that provides commands for actions, such as opening, reading, writing, copying and moving files across the network (also known as a client/server protocol).
File Share Viewers

Two file share viewers are available. For end-users using Microsoft Internet Explorer, the administrator can allow the end-user to choose the file share viewer: Web-based file viewer is browser-based, browser-independent, and therefore multi-platform. Note that when using this viewer, extremely large files (bigger than 2GB) cannot be viewed or accessed. Windows Explorer user interface is for Windows file shares, and requires Internet Explorer 6 or higher. It is based on Microsoft Web Folders and the WebDAV extension of HTML, and uses the familiar Windows file and folder handling model. However, the capabilities of this viewer depend on the version of Web Folders installed on the endpoint machine, and the viewer must be restarted if the users credentials become out of date.
Configuring File Shares

To configure a File Share Application: 1. In the Connectra tab navigation tree, select Applications > File Shares. 2. Click New. The File Share Application window opens. The following subsections explain the fields in each page.
60
In This Section
File Share Application General Properties Page File Share Application Authorized Locations Page File Share Application Authorized Locations Page File Share Application Single Sign-On Page File Share Application Protection Level Page Completing the Configuration of the File Share Application page 61 page 61 page 61 page 63 page 63 page 64
File Share Application General Properties Page

Go to the General Properties page of the File Share Application object. Name is the name of the SmartDashboard object.
File Share Application Authorized Locations Page

Go to the Authorized Locations page of the File Share Application object. This page allows you to configure the file shares that users are authorized to access. These settings take effect whenever a user attempts access, no matter what interface is used, whether by manually typing a path in the portal, browsing using the file viewer, clicking a user-defined file favorite, or clicking the predefined file favorite path defined by the administrator in the Link in Portal page.
Chapter 2
61
Fill in the fields on the page: Servers are the machine(s) or DNS Name(s) on which the file server is hosted. Choose either a single Host or DNS name, or Multiple hosts. Allow access to any file share gives the users access to all locations on the file server defined in Servers. Allow access to specific file shares restricts user access to specific shares. For example My_Share. Use only the name of a share, such as My_share, $$user, or My_share$, without any slashes. Do not specify a subdirectory inside a share. The $$user variable represents the name of the currently logged-in user. This variable provides personalized authorization for users. If $$user is defined as a file share, then if the user currently logged-in is alice, alice will be allowed access to the share named alice defined on the server, such as \\myserver\alice. Note - When two or more overlapping file share applications are configured (for example,
one for any share and one for a specific share on the same host), it is undefined which application settings are in effect.
File Share Application Link in Portal Page

Go to the Link in Portal page of the File Share Application object. This page allows you to configure one predefined favorite link. This link is displayed in the Connectra portal. By clicking the link the user is able to directly access the specified path. Note that you must authorize access to this location in the Authorized Locations page.
Fill in the fields on the page: Add a link to this file share in the Connectra portal. If you do not enter a link, users will be able to access the application by manually typing its link in the portal, but will not have a pre-configured link to access it. Link text (multi-language) is shown in the Connectra Portal. Can include $$user, which represents the username of the currently logged-in user. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal.
62
Path is the full file path that the link will attempt to access, specified using UNC syntax. It Can be either a location of a share, or any path under the share. Can include $$user, which represents the username of the currently logged-in user. For example, a path that is defined as \\host\Pub\users\$$user appears for user alice as \\host\Pub\users\alice and for user Bob as \\host\Pub\users\Bob.
Note - The host defined here is the same host that is defined in the Authorized Locations page. However, the IP address of the host is resolved by the DNS Server that is
defined on Connectra itself (and not by the Connectra management).
Tooltip (multi-language) for additional information. Can include $$user, which represents the username of the currently logged-in user. The text appears automatically when the user pauses the mouse pointer over the link and disappears when the user clicks a mouse button or moves the pointer away from the link.
File Share Application Single Sign-On Page

Go to the Single Sign On page of the File Share Application object.
File Share Application Protection Level Page

Go to the Protection Level page of the File Share Application object.
Chapter 2
63
Using the $$user Variable in File Shares
Completing the Configuration of the File Share Application


It is possible to configure personalized user locations that use the login name of the currently logged in user. To do this, use the $$user variable wherever you need to specify the name of the user. The $$user variable is resolved during the Connectra session to the login name of the currently logged-in user. For example, a UNC file path that is defined as \\host\Pub\$$user is resolved for user Alice as \\host\Pub\Alice and for user Bob as \\host\Pub\Bob.
64
For more information about the $$user variable, see Using the Login Name of the Currently Logged in User on page 88.
Chapter 2
65
Citrix Services
Citrix Services
In This Section
Understanding Citrix Services Citrix Deployments Modes - Unticketed and Ticketed Citrix features Supported by Connectra Configuring Citrix Services page 66 page 66 page 68 page 71
Understanding Citrix Services

Connectra supports Citrix client connectivity to internal MetaFrame servers. In this type of deployment, Connectra functions as a Secure Gateway. Connectra implements its own STA engine. Thus, using Secure Ticket Authority (STA) servers is not necessary. It is possible, however, to install Connectra in a topology where STA and Citrix Secure Gateway (CSG) servers are present.
Citrix Deployments Modes - Unticketed and Ticketed

Figure 2-4
Connectra in a Citrix Deployment - Unticketed Mode (recommended setup)
In the recommended Unticketed Mode scenario:
66
Citrix Deployments Modes - Unticketed and Ticketed
The remote access user logs into the Connectra user portal Using the Connectra Web interface, the user is directed to the Citrix Web Interface server and then has access to the MetaFrame server.
Connectra in a Citrix Deployment - Ticketed Mode (using external STA servers)
Figure 2-5
In the Ticketed Mode scenario: The remote access user logs into the Connectra user portal. Using the Connectra Web interface, the user is directed to the Citrix Web Interface server. The user logs into the Citrix Web Interface server and is assigned a secure ticket by the Secure Ticket Authority. This ticket allows the user to access the MetaFrame server once it is verified by the Connectra Web Security Gateway. Note - Connectra implements its own Secure Ticketing authority (STA) engine, Thus, using STA servers is not necessary.
Chapter 2
67
Citrix features Supported by Connectra

Table 2-3 lists the Citrix features supported by Connectra. Note - Considering the diversity of Citrix products and product versions, it is possible that
Connectra conforms to more Citrix features and product versions than are listed in this table. However, Connectra has undergone thorough testing with only the feature-set described. Check Point is working to expand the feature set. Note that using SSL Network Extender may effectively meet your Citrix needs
Table 2-3 Feature
Citrix Features Supported by Connectra
Description When securing an access center, Check Point's proprietary agents are not required to run on the client devices. ICA Web Client for Windows based PCs (ActiveX), Versions 6.3 - 8.2. ICA Java Client for any Java-enabled browser (Applet) for UNIX, LINUX Macintosh, Windows, Versions 6.3 8.2. Citrix Program Neighborhood client, Versions 6.3 - 8.2.
Details
Clientless support of Independent Citrix Architecture Clients supported
Clientless Support. Clientless Support.
Clientless support when working through Connectra and WI Web portals.
Predefined client with published applications, IP addresses, server names and connections options Servers supported MetaFrame Presentation Server (MPS) 3.0 MetaFrame XP server for Windows MetaFrame XP server for Solaris We recommend stage testing this server version with Connectra in non-production mode first.
68
Table 2-3 Feature
Description MetaFrame 1.8 server
Details We recommend stage testing this server version with Connectra in non-production mode first.
Web Interface (WI) 3.0 Server Web Interface (WI) 2.0 server NFuse 1.7 server. Multiple STA servers of versions 1.0 - 2.0. Support for Citrix STA servers. NOTE that Connectra has its own internal STA engine. Thus, using external STA servers is not necessary, but possible.
Parallel gateways
Connectra beside Citrix Secure Gateway (CSG) server. Multiple points of access. Multiple points of access into organization are possible. Connectra may serve as one such point of access. Such setup is extremely useful for integration purposes, for example. No need to alter existing configurations or Citrix servers' topology.
Seamless integration.
Firewall traversal
Connections from clients are secured with standard protocols using ports typically open on corporate firewalls. No special configuration of Citrix servers is necessary in order to set up Connectra.
Zero configuration
Chapter 2
69
Table 2-3 Feature
Description Seamless integration in preexisting setups.
Details
Unticketed mode Ticketed mode Single point of access
WI (NFuse) server configured to work in un-ticketed mode. WI (NFuse) server configured to work in ticketed mode. Single point of access to all backend servers including WI (NFuse), MetaFrame, Presentation and third party servers. Centralized management. Restricted access to Citrix backend servers. Access to specific WI (NFuse) MetaFrame, Presentation & STA servers is regulated by Connectra. Endpoint Compliance Profile configuration per Citrix-service. Enforcement of authentication strength and security scans. Single point of access protected by various intelligent defense mechanisms, SSL/TLS encryption & certificates. Advanced auditing and logging. Connectra administrator may specify specific MF, WI (NFuse) & STA servers to which access is permitted.
Security & Access restrictions
Custom Certificate Authorities
Connectra Web Security Gateway certificate can be issued by a custom Certificate Authority (CA). The certificate can also be self-signed.
This feature is useful for organizations that choose to utilize their own Certificate Authorities to sign server certificates.
70
Configuring Citrix Services

To configure a Citrix Service: 1. In the Connectra tab navigation tree, select Applications > Citrix Services. 2. Click New. The Citrix Services window opens. The following subsections explain the fields in each page.
In This Section
Before Configuring Citrix Services Citrix Service Web Interface (NFuse) page Citrix Service Link in Portal Page Citrix Service STA Servers Page Citrix Service MetaFrame Servers Page Citrix Service Single Sign On Page Citrix Service Protection Level Page Completing the Configuration of the Citrix Service page 71 page 72 page 72 page 73 page 74 page 75 page 75 page 76
Before Configuring Citrix Services

Connectra's server certificate must be Fully Qualified Domain Name (FQDN)-based i.e. issued to Connectra's FQDN, for example www.example.com. Before configuring Citrix Services, change the Connectra server certificate to one that was issued to the Fully Qualified Domain Name (FQDN). This is required in order to comply with the accepted Citrix standards for server certificates. Additionally, end-users must browse to Connectra using its FQDN, and the FQDN must be routable from their network. For instructions about how to install server certificates, see Connectra Server Certificates on page 247. If your Web Interface (NFuse) server is configured to deploy ICA Web clients and Connectra's server certificate is issued by a private CA, the certificate's public key must be installed on the client side browser in order for ICA Web Client to function properly. Connectra's certificate public key is located under: $CVPNDIR/var/ssl/server.crt.
Chapter 2
71
Citrix Service Web Interface (NFuse) page

Go to the Web Interface page of the Citrix Service object.
Fill in the fields on the page: Servers are the machine(s) or DNS Name(s) on which the Web Interface server is hosted. Choose either a single Host or DNS name, or Multiple hosts. In order to keep the environment simple, it is recommended to configure a single Web Interface (NFuse) server per Citrix Application. Services must match the settings on the Web Interface server. Select http or https, as required. Other services are NOT supported.
Citrix Service Link in Portal Page

Go to the Link In Portal page of the Citrix Service object.
Fill in the fields on the page: Link text (multi-language) is shown in the Connectra Portal. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal. URL is the link to the location of the application, or to a subdirectory of the application.
72
Tooltip (multi-language) for some additional information. The text appears automatically when the user pauses the mouse pointer over the link and disappears when the user clicks a mouse button or moves the pointer away from the link.
Citrix Service STA Servers Page

Go to the STA servers page of the Citrix Service object.
Obtain the Host and the STA ID of the Secure Ticketing Authority (STA) servers from the current settings on the Web Interface (WI) server. Note - Connectra implements its own Secure Ticketing authority (STA) engine, Thus, using STA servers is not necessary.
To retrieve the hostname/IP

1. Login to the WI (NFuse) Citrix administration page. 2. Click Server-Side Firewall. 3. Scroll to the Secure Ticket Authority list. If the field is blank, you are in unticketed mode and you do not need to define any STA Servers on Connectra. If the field contains entries, you are in ticketed mode. Each entry in this list is a URL containing the IP or FQDN of a Citrix server. Every entry in the Secure Ticket Authority list must be separately entered into Connectra.
Chapter 2
73
To retrieve the STA ID

1. Login to the STA server. 2. From the Windows Start menu, select Programs > Citrix > Citrix Secure Gateway > Secure Ticket Authority Configuration. 3. Click Next. The STA ID is shown in the Enter the STA ID field.
Citrix Service MetaFrame Servers Page

Go to the MetaFrame servers page of the Citrix Service object.
In this page you can either allow access to all MetaFrame Servers or restrict access to defined MetaFrame Servers. Note - If you select Restrict access to these servers only, 1. Define the servers using an IP address or Fully Qualified Domain Name (FQDN). 2. Make sure that the definition matches the configuration made on the Metaframe server farm. If you do not, Connectra may not authorize the connection. (The Metaframe server configuration affects one of the parameters in the ICA file that is received by the client).
74
Citrix Service Single Sign On Page

Go to the Single Sign-On page.
Citrix Service Protection Level Page

Go to the Protection Level page of the Citrix Service object.
Note - The Citrix architecture requires ICA files and ActiveX executables to be temporarily cached by the client-side browser. As a result, Connectra's Protection Level settings do not apply to these files.
Chapter 2
75
Obtain the Host and the STA ID of the Secure Ticketing Authority (STA) servers from the current settings on the Web Interface (WI) server. Note - Connectra implements its own Secure Ticketing authority (STA) engine, Thus, using STA servers is not necessary.
To retrieve the hostname/IP

1. Login to the WI (NFuse) Citrix administration page. 2. Click Server-Side Firewall. 3. Scroll to the Secure Ticket Authority list. If the field is blank, you are in unticketed mode and you do not need to define any STA Servers on Connectra. If the field contains entries, you are in ticketed mode. Each entry in this list is a URL containing the IP or FQDN of a Citrix server. Every entry in the Secure Ticket Authority list must be separately entered into Connectra.
To retrieve the STA ID

1. Login to the STA server. 2. From the Windows Start menu, select Programs > Citrix > Citrix Secure Gateway > Secure Ticket Authority Configuration. 3. Click Next. The STA ID is shown in the Enter the STA ID field.
Completing the Configuration of the Citrix Service

76
Chapter 2
77
Web Mail Services
Web Mail Services

In This Section
Connectra Web Mail Services Web Mail Services User Experience Configuring Mail Services page 78 page 79 page 80
Connectra Web Mail Services

Connectra supports built-in Web mail. Web mail provides a simple way for remote users, through a web browser interface, to access their email. Employees can access their email from any computer that has access to the Internet, such as a computer in a library, or Internet cafe. There is no need to install special email or remote access software. This is helpful for employees who work outside the office on a regular basis. Note - The traffic log does not show actions done by the user through the Web mail
interface.
Connectra also supports the IBM Lotus Domino Web Access (DWA, formerly known as iNotes) and Outlook Web Access (OWA). DWA and OWA are configured in Connectra as Web Applications.
78
Web Mail Services User Experience
Figure 2-6
Connectra Mail Services
Web Mail Services User Experience

Remote users login to Connectra and authenticate themselves in order to gain access to the portal. They can then click a link to access the Web mail application. Connectra can be configured to reuse the login credentials when authenticating to the IMAP account on the mail server. If the reused credentials are incorrect, Connectra again presents the user with a login page. Valid credentials are saved for future logins. Once authenticated to the mail application, users can: Compose, send and receive email. Create, delete, rename, and manipulate mail folders. Index messages in various ways. Stores addresses. Search emails according to various criteria, such as body text, subject and senders address. Highlight messages with different background colors, enabling quick differentiation. Display preferences.
Chapter 2
79
Incoming (IMAP) and Outgoing (SMTP) Mail Servers
Incoming (IMAP) and Outgoing (SMTP) Mail Servers

Connectra provides a Web front-end for any email application that uses the IMAP protocol for incoming mail, and SMTP for outgoing mail. Email stored on the IMAP server is manipulated through the browser interface without having to transfer the messages back and forth. Users can connect to several mail servers depending on their authorization.
Configuring Mail Services

To configure a Web Mail application: 1. In the Connectra tab navigation tree, select Applications > Web Mail. 2. Click New. The Web mail service window opens. The following sections explain the fields on each page.
In This Section
Web Mail Service General Properties Page Web Mail Service Link in Portal Page Web Mail Service Single Sign-On Page Web Mail Service Single Sign-On Page Completing the Configuration of the Web Mail Service Enabling LDAP Contacts Search in Web Mail Applications page 81 page 81 page 82 page 82 page 83 page 83
80
Web Mail Service General Properties Page

Go to the General Properties page of the Web mail service object.
Fill in the fields on the page: Name for the mail service, for example, my_mail_server Outgoing Mail Server (SMTP) Host or DNS Name, for example, smtp.example.com Service is normally the standard predefined SMTP service.
Incoming Mail Server IMAP server type Host or DNS Name, for example, smtp.example.com Service is normally the standard predefined IMAP service.
Web Mail Service Link in Portal Page

Go to the Link In Portal page of the Web mail service object.
Chapter 2
81
Fill in the fields on the page: Link text (multi-language) is shown in the Connectra Portal. If more than one link is configured with the same (case insensitive) text, only one of them will be shown in the portal. Tooltip (multi-language) for additional information. The text appears automatically when the user pauses the mouse pointer over the link and disappears when the user clicks a mouse button or moves the pointer away from the link.
Web Mail Service Single Sign-On Page

Go to the Single Sign On page of the Web mail service object.
Web Mail Service Protection Level Page

Go to the Protection Level page of the Web mail service object.
82
Completing the Configuration of the Web Mail Service

Enabling LDAP Contacts Search in Web Mail Applications

By default, the contact search in Web Mail applications works only for internal users that are defined on the Connectra gateway. To enable search on contacts that are defined on an LDAP server, see SecureKnowledge solution sk34997.
Chapter 2
83
Native Applications
Native Applications
Native Applications are not clientless. They require the SSL Network Extender client on the endpoint machine. See chapter 4, Native Applications for Client-Based Access on page 107.
84
DNS Names
DNS Names
In This Section
Why Use DNS Name Objects? DNS Names and Aliases Where DNS Name Objects are Used Defining the DNS Server used by Connectra Configuring DNS Name Objects page 85 page 85 page 86 page 86 page 86
Why Use DNS Name Objects?

If an internal application is hosted on a server inside the organization, using a DNS Name object in the definition of the Connectra application makes it possible to change the IP address of the server without having to change the definition of the host object in the Connectra application. For example, if myhost.example.com is used in the definition of a Connectra application, Connectra resolves the IP address of myhost when authorizing access to the application. Also, if an internal application is hosted on multiple replicated servers, a single DNS Name object can be used in the definition of the Connectra application, instead of having to individually define each host. Note - The resolving of DNS Name is done using the DNS server specified in two locations: 1. On Connectra itself (by using the sysconfig command from the console). 2. In SmartDashboard (in the Connectra tab, in the Additional Settings > Network Accessories > Name Resolution page).
DNS Names and Aliases

A DNS name can have a number of aliases. For example, www.example.com, www.example.co.uk and www.example.co.fr could be aliases of the same DNS name. In the definition of the DNS Name object, use the format a.b x.y.z, where each section of the DNS name is demarcated by a period. For example, mail.example.com or www.example.co.uk.
Chapter 2
85
Where DNS Name Objects are Used
Wildcards can be used at the beginning of a domain name, but not at the end. For example, *.example.com includes www.example.com and mail.example.com. On the other hand, www.example.* is NOT valid.
Where DNS Name Objects are Used

DNS objects are used when defining hosts for Connectra Web applications, File Share applications, Citrix services, and Web mail services. They are also used when configuring support for Hostname Translation. DNS Name objects cannot be used in the Security Rule Base.
Defining the DNS Server used by Connectra

The DNS server that resolves the IP addresses of the DNS Name objects must be defined in two locations: 1. In SmartDashboard, in the Connectra tab, in the Additional Settings > Network Accessories > Name Resolution page. 2. From Connectra itself, using either the console, or the SecurePlatform Web UI. To define the DNS server using the Connectra console, run sysconfig, and select 3) Domain Name Servers. To define the DNS server using the SecurePlatform Web UI, connect your browser to https://<Connectra_IP>:4433, and go to the Network > DNS page. Note - After changing the IP address of the DNS server, you must either run cpstop and then cpstart at the Connectra console, or Restart All Connectra Products in the Device > Control page of the SecurePlatform Web UI.
Configuring DNS Name Objects

To create a DNS Name object: 1. In SmartDashboard, select Network and Resources > DNS Names. 2. Click New. The DNS Name window opens. 3. Give the DNS Name object a Name. 4. Click DNS Names.
86
Configuring DNS Name Objects
The DNS Names window opens. 5. Click Add. The Edit DNS Name window opens. 6. Type the DNS name. Figure 2-7
Editing a DNS Name
7. Click OK three times. The DNS Name window closes.
Chapter 2
87
Using the Login Name of the Currently Logged in User
Using the Login Name of the Currently Logged in User

Connectra applications can be configured to depend on the username of the currently logged-in user. For example, portal links can include the name of the user, and a file-share can include the users home directory. For this purpose, the $$user directive is used. During a Connectra session, $$user resolves to the login name of the currently logged-in user. For such personalized configurations insert the $$user string into the relevant location in the definitions of Web Applications, File Shares and Native Applications. For example, a Web Application URL that is defined as http://host/$$user appears for user aa as http://host/aa and for user bb as http://host/bb. If the user authenticates with a certificate, $$user resolves during the users login process to the username that is extracted from the certificate and authorized by the directory server. For its use in configuring File shares, see Using the $$user Variable in File Shares on page 64.
88
Chapter Single Sign On

In This Chapter
Introduction to Single Sign On Supported SSO Authentication protocols HTTP Based SSO Web Form Based SSO Application and Client Support for SSO Basic Configuration of SSO Advanced Configuration of SSO Advanced Configuration of Web Form SSO
3
page 90 page 91 page 92 page 93 page 95 page 96 page 98 page 102
89
Introduction to Single Sign On
Introduction to Single Sign On

Single Sign On (SSO) removes the need to reauthenticate to an application when accessing it for a second time either during an existing Connectra session, or even between Connectra sessions. The authentication credentials used for logging in to the Connectra portal can be re-used automatically by Connectra to authenticate to multiple applications accessed through Connectra. It is also possible to record other credentials for the application, and store them for future use. SSO user credentials are securely stored on Connectra and so remain valid even if the user logs back in from a different client machine. Figure 3-8
.
Single Sign On to an Application Behind Connectra
90
Supported SSO Authentication protocols
Supported SSO Authentication protocols

Connectra supports Single Sign On for authentication to internal Web and other application servers. The supported authentication protocols are: Basic (RFC enhancement. Not recommended because of security implications). Digest (RFC enhancement). Integrated Windows Authentication (RFC enhancement. Formerly NTLM version 1). Credential forwarding in HTTP headers (Ad hoc solution. Not recommended because of security implications). Web form (HTML) based.
Chapter 3
Single Sign On
91
HTTP Based SSO
HTTP Based SSO

For applications that perform authentication at the HTTP level, HTTP-based SSO is available, in which the credentials are forwarded in HTTP headers. This applies to the Basic, Digest, Integrated Windows Authentication, and Credential forwarding in HTTP headers authentication protocols. When the user attempts to access these sites, a browser-specific form appears: Figure 3-9
HTTP Authentication Browser-Specific Credential Request Form
The user must enter his/her username and password for that application, and click OK.
HTTP Based SSO Limitation

Where the Web server requests authentication for a POST request, in either the digest or Integrated Windows Authentication methods and the server does not support sending of 100 Continue responses, Single Sign On is not supported.
92
Web Form Based SSO
Web Form Based SSO

Most Web applications have their own Web forms for authentication. For those applications, Connectra supports Web form (HTML) based SSO. HTTP-based authentication methods, on the other hand, are becoming legacy. The advantage of Web form based SSO authentication is that users are presented with the login page of the application itself, rather than a browser-specific page, which make for a much more unobtrusive user experience A typical Web form is shown below, for Outlook Web Access, together with a Connectra SSO popup that assists the user. Figure 3-10 Web Form Based SSO Example
Chapter 3
Single Sign On
93
Application Requirements for Easy Configuration
It is recommended to use the Web form based SSO for every application that is configured to work with Web form authentication. Do not enable Web form SSO for other applications, in order to maintain performance and connectivity. Note - Web form SSO is available for Connectra NGX R66 and higher.
Application Requirements for Easy Configuration

Web form based SSO in its default configuration can be configured by selecting a single check box in SmartDashboard. In order for the default settings to work, the application must: Present the login form as the first form seen by the user. Redirect (status 301 or 302) on login success.
Web Form Based SSO Limitations

Web form based SSO does not support: Password remediation forms Forms containing 'old/new/confirm' password fields. Those fields are not recognized properly, and wrong credentials may be recorded or forwarded.
94
Application and Client Support for SSO
Application and Client Support for SSO

Connectra Applications that Support SSO
The two SSO methods are available for Connectra applications to varying degrees, as follows: Connectra Application Supports HTTP Based SSO Yes Yes Yes Simplified No Supports Web Form Based SSO Yes No Yes No No
Web applications File shares Citrix services Web Mail Native applications
Applications that Support Web Form SSO

Most Connectra Web Applications and Citrix Services support Web Form SSO, with either no configuration, or minimal configuration required. Some applications have been tested and found to require manual configuration (of the HTTP Post details). Some applications do not support Web Form SSO at all. For a list of common applications that are certified by Check Point to work with Web Form SSO, see SecureKnowledge solution sk35080.
Connectra Client Support for SSO

Single Sign On is available only via the Connectra portal. It is not available for authentication via the VPN clients: SSL Network Extender, SecureClient Mobile and Endpoint Connect.
Chapter 3
Single Sign On
95
Basic Configuration of SSO
Basic Configuration of SSO

Single Sign On (SSO) removes the need to reauthenticate to an application when accessing it for a second time either during an existing Connectra session, or even between Connectra sessions. To configure a basic SSO setup: 1. In the SmartDashboard Connectra tab, select the Additional Settings > Single Sign On page.
2. In the Single Sign On page, select an application and click Edit. The Single Sign On page of the application window opens.
3. Select Turn on single Sign On for this application. 4. Configure the sign on method for the application. The default option is: For Web applications, File Shares and Citrix Services: Prompt the users for their credentials and store them for future use For Web Mail applications this same option is called: Prompt user for credentials With this option, the application credentials are stored and reused. The portal credentials are not used to authenticate to applications.
96
Basic Configuration of Web Form SSO
Basic Configuration of Web Form SSO

Web form SSO is supported only for Connectra Web applications and Citrix services. In its the default settings, Web Form Single Sign On automatically analyses the sign-in Web page of the application. The default settings assume: HTTP redirect (301, 302) upon authentication success. No redirect upon authentication failure.
To configuring Web Form SSO with default settings: In the Single Sign On page of the Connectra application, select This application uses a Web form to accept credentials from other users Note - Only enable Web form SSO for applications that use a web form to accept user credentials, in order to maintain performance and connectivity.
Chapter 3
Single Sign On
97
Advanced Configuration of SSO
Advanced Configuration of SSO

The following configuration instructions apply to both HTTP based SSO and to Web form based SSO. The advanced configuration options are supported for Web applications, file shares, and Citrix services. Advanced configuration options include: Configuring the Single Sign On Method on page 98 Configuring Login Settings on page 99
For configuration options that are specific to Web form SSO, see Advanced Configuration of Web Form SSO on page 102.
Configuring the Single Sign On Method

There are a number of Single Sign On methods. The different options allow you to configure how to handle portal credentials, and how to handle other credentials used to authenticate to the application. To configure the Single Sign On methods, go the Single Sign On page of the Connectra application. For the Advanced options, click Edit.
98
Configuring Login Settings
Table 3-4 summarizes the available single sign on methods. Table 3-4
Single Sign On Methods
SSO Method Turn on Single Sign On for this application - Unchecked Prompt users for their credentials, and store them for future use This application reuses the portal credentials. Users are not prompted. This application reuses the portal credentials. If authentication fails, Connectra prompts users and stores their credentials.
Single Sign On is On/Off Off Users are always prompted. On Default method On Advanced method. On Advanced method.
Forward portal credentials No
Learn other credentials No
No Yes Yes
Yes No Yes

Login settings allow you to configure the default Windows domain (if Windows authentication is being used), to notify users that their credentials will be stored, and to specify a hint to help users supply the correct credentials. To configure the login settings for Single Sign On: 1. Go the Single Sign On page of the Connectra application 2. In the Login Settings section, click Edit.
Chapter 3
Single Sign On
99
The Login Settings window opens.
Windows domain
The user of this application belongs to the following Windows domain: The windows Domain or workgroup, for example LOCALDOMAIN. Specify the domain if Windows authentication is used. Integrated Windows authentication requires the domain to be forwarded along with the username and password, but if one of the Accept the portal credentials from the gateway Single Sign On methods are selected, Connectra does not know the domain because the user does not supply it with the portal credentials. Therefore, the domain is fetched from the one specified here.
User notification
Notify the users that their credentials for this application are going to be stored Users accessing the application login page for the first time see a popup message such as the following:
Allow the users to specify that their credentials for this application will not be stored
100
Users accessing the application login page for the first time see a popup message such as the following:
Administrator message
Show the following message together with the credentials prompt Show a hint to the user about the credentials they must supply. for example, whether or not they should supply the domain name and username (for example: AD/user) or just the username (for example: user). After clicking the Help me choose credentials link, the user sees the hint. The message can include ASCII characters only.
Chapter 3
Single Sign On 101
Advanced Configuration of Web Form SSO
Advanced Configuration of Web Form SSO

Use the advanced Single Sign On settings for Web form credentials to configure an application for web form SSO if there is: No HTTP redirect (301, 302) upon authentication success OR No redirect upon authentication failure.
You can specify different criteria for: Sign In Success or Failure Detection on page 102. Credential Handling on page 103.
Sign In Success or Failure Detection

Most web applications respond to authentication success by redirecting to another page. If a redirect is not an indication of success, you can configure here the indicator of success or failure. To configure Sign In success or failure criteria:
102
Credential Handling
In the Single Sign On page of the Connectra application, in the Web Form section, click Edit.
Specifying a Criterion for Success or Failure

Connectra regards the authentication as successful, if after signing in, this application creates a cookie with the following name: The application places a session cookie upon success. To obtain the exact name of the session cookie, install a sniffer or browser plug-in (such as the Fiddler HTTP debugging proxy) Connectra regards the authentication as a failure, if after signing in, this application redirects to the following URL: The application redirects on failure. To find the target URL, install a sniffer or browser plug-in (such as the Fiddler HTTP debugging proxy). Use the following URL format: <protocol>://<host>/[<path>][?< query>]
Credential Handling
By default, Connectra looks for the username and password fields at the application URL. If the default settings do not work, you can either configure an automatic credential detection method, or you can manually hard-code the POST details.
Chapter 3
Single Sign On 103
Credential Handling
To configure credential handling: 1. In the Single Sign On page of the Connectra application, in the Web Form section, click Edit. 2. in the Credentials Handling section, click Edit. The Credentials Handling window opens.
Automatically Handle the Credentials

Sign In Web Form Detection Settings
Connectra regards the following URL as the sign in Web form: If the application presents a Web form that requires credentials, before the actual login form, so that Connectra is unable to automatically analyze the sign-in Web page, you can specify the URL of the actual login form. Use the following URL format: <protocol>://<host>/[<path>][?< query>]
104
Credential Handling
Password Validation Settings

Connectra sends the following password: Clients need to submit the sign on Web form with a username and password. However, it is not secure to store the password on the client for future SSO use. Connectra therefore generates a dummy password that it sends to the client, and replaces it upon sign on with the real password. Some applications check the dummy password on the client side. If the Connectra dummy password is not compatible with the application, you can define a different one. Note - This password cannot include special characters. Use ASCII characters only.
Manually Defining HTTP Post Details

Manually specify how to handle the credentials If automatic Web form SSO does not work, you can define HTTP POST details. When the following sign in URL is requested ...post to the following URL In this and the previous field, the URL must be absolute. Use the URL format <protocol>://<host>/[<path>][?< query>] ...the following POST data, which must include the following two macros: A. $USERNAME resolves to the username stored on Connectra. B. $PASSWORD resolves to the password stored on Connectra. Note - When manual credential handling is configured for Web form SSO, the HTTP authentication request window (Figure 3-9 on page 92) appears, when credentials are requested for the first time.
Chapter 3
Single Sign On 105
Credential Handling
106
4 Chapter Native Applications for ClientBased Access

In This Chapter
Introduction to Native Applications VPN Clients Configuring VPN Clients Endpoint Application Types Configuring a Simple Native Application Configuring an Advanced Native Application Configuring Downloaded-From-Connectra Endpoint Applications page 108 page 109 page 114 page 122 page 127 page 130 page 138
Adding a New Downloaded-From-Connectra Endpoint Application page 145
107
Introduction to Native Applications
Introduction to Native Applications

A Native Application is any IP-based application that is hosted on servers within the organization, and requires an installed client on the endpoint. The client is used to access the application and encrypt all traffic between the endpoint and Connectra. The following VPN clients are available: SSL Network Extender. SecureClient Mobile (for handheld devices). Endpoint Connect.
Microsoft Exchange, Telnet and FTP, are all examples of native application servers. Authorized users can use their native clients (for example, telnet.exe, ftp.exe, or Outlook) to access these internal applications from outside the organization. A native application is defined by the: Server hosting applications. Services used by applications. Connection direction (usually client to server, but can also be server to client, or client to client). Applications on the endpoint (client) machines. These applications are launched on demand on the user machine when the user clicks a link in the user portal. They can be: Already installed on the endpoint machine, or Run via a default browser, or Downloaded from Connectra.
108
VPN Clients
VPN Clients
Three VPN clients are allowed to connect to a Connectra gateway or gateway cluster: SSL Network Extender, SecureClient Mobile, and Endpoint Connect. The SSL Network Extender client can operate in two modes: Network Mode and Applications Mode.
In This Section
SSL Network Extender SecureClient Mobile Endpoint Connect page 109 page 112 page 113

The SSL Network Extender client makes it possible to access Native Applications via Connectra. SSL Network Extender is downloaded automatically from the Connectra portal to the endpoint machines, so that client software does not have to be pre-installed and configured on users' PCs and laptops. SSL Network Extender tunnels application traffic using a secure, encrypted and authenticated SSL tunnel to the Connectra gateway. SSL Network Extender is installed using ActiveX (for Windows with Internet Explorer), or Java. For details see First time Installation of ActiveX and Java Components on page 39. For SSL Network Extender configuration details, see Configuring VPN Clients on page 114.
SSL Network Extender Network Mode

The SSL Network Extender Network Mode client provides secure remote access for all application types (both Native-IP-based and Web-based) in the internal network via SSL tunneling. To install the Network Mode client, users must have administrator privileges on the client computer. After installing the client, an authenticated user can access any authorized internal resource that is defined on Connectra as a Native Application. The user can access the resource by launching the client application, either directly from the desktop or from the Connectra portal.
Chapter 4
Native Applications for Client-Based Access 109
SSL Network Extender Application Mode

The SSL Network Extender Application Mode client provides secure remote access for most application types (both Native (IP-based) and Web-based) in the internal network via SSL tunneling. Most TCP applications can be accessed in Application Mode. The user does not require administrator privileges on the endpoint machine. After the client is installed the user can access any internal resource that is defined on Connectra as a Native Application. The application must be launched from the Connectra portal and not from the users desktop.
Supported Application Mode Applications

Most TCP application work with SSL Network Extender in the application mode. If an application is defined in the Connectra tab in SmartDashboard as one that can be used in Application Mode, a user that connects in Application Mode will be able to see it and launch it. If the application is not supported in Application mode, a user who connects with Application Mode will not see it in the list of applications. The following applications have been tested and are Check Point OPSEC-certified for use with Connectra SSL Network Extender in Application Mode. Note this mode is different from SSL Network Extender in Network Mode which supports any IPbased application. While Application Mode is designed to work with most applications, only OPSEC-certified applications have been tested and verified to work with SSL Network Extender in Application Mode. Only specified versions are guaranteed to work and are fully supported. However, in most cases other versions of the same client and most other applications that are TCP based will work. For the latest information, see http://www.opsec.com/solutions/snx_support.html. Table 4-1
SSL Network Extender - Application Mode Support
Partner/ Company Telnet / SSH Microsoft Microsoft Putty VanDyke Database Clients Rational
Client Microsoft Telnet (Command Line) HyperTerminal Putty SecureCRT ClearQuest
Version 2000 XP 5.1 0.55 4.1 2003.06.00. 436.000
110
Table 4-1
SSL Network Extender - Application Mode Support (continued)
Partner/ Company Siebel TN3270 Ericom IBM FTP Microsoft Ipswitch GlobalSCAPE E-Mail (POP3, IMAP, SMTP) Microsoft Microsoft
Client Siebel Client PowerTerm InterConnect for Windows Personal Communications Workstation Program FTP (Command Line) WS_FTP Home/PRO CuteFTP
Version 7 6.6.2 5.8
2000 XP 9.1.0.429 4.2 7
Outlook Express Outlook (See note below table) Eudora Thunderbird Lotus Notes
6 2000 2003 SP1 XP 6.2 1.0.2 6.0.3 6.5.3
QUALCOMM Mozilla IBM Web Browser (HTTP, HTTPS, Passive FTP) Microsoft Mozilla Terminal Services Microsoft RealVNC
Internet Explorer Mozilla Firefox
5.5 and up 1.0.3 1.0.4 XP 2000 4.1.1
Remote Desktop Connection VNC Viewer
Chapter 4
SecureClient Mobile
Table 4-1
SSL Network Extender - Application Mode Support (continued)
Partner/ Company Famatech Citrix Citrix Citrix Citrix Citrix Productivity Suites IBM
Client Remote Administrator
Version 2.0 2.1 6.20.985 9.0.0.32649 8.0.1672 8.2.1684 8.0.24737.0 6.0.3 6.5.3
Program Neighborhood Java Connection Center JICA ActiveX Lotus Notes
Note - Some Anti Virus applications do not scan email when Microsoft Outlook is launched with SSL Network Extender Application Mode. This is due to the fact the mail is encrypted in SSL before the scanning takes place.
SecureClient Mobile
SecureClient Mobile is a client application for mobile devices that includes a VPN and a firewall. SecureClient Mobile enables easy customization with central management and enforcement. SecureClient Mobile's VPN is based on SSL (HTTPS) tunneling and enables handheld devices to securely access resources behind Check Point gateways. Any Native Application that can be accessed using the SSL Network Extender Network Mode client can also be accessed by SecureClient Mobile clients on handheld devices. For configuration details, see Configuring VPN Clients on page 114.
112
Endpoint Connect
Endpoint Connect
Endpoint Connect is Check Points lightweight remote access client. Providing seamless, secure VPN connectivity to corporate resources, the client works transparently with Connectra NGX R66 and higher gateways. For more information, see Chapter 18, Endpoint Connect.
Chapter 4
Configuring VPN Clients
Configuring VPN Clients

In addition to configuring Native Applications, you must also configure the VPN clients that are allowed to connect to the Connectra gateway or gateway cluster. For background information about the supported VPN clients, see VPN Clients on page 109.
In This Section
Basic VPN Client Configuration Advanced VPN Client configuration Configuring SSL Network Extender Advanced Options Configuring SecureClient Mobile page 114 page 115 page 117 page 119
To configure Endpoint Connect clients settings on the gateway, see Configuring the Gateway for Endpoint Connect on page 454.
Basic VPN Client Configuration

To configure VPN clients, in the Connectra Gateway or Connectra Cluster object, go to the VPN Clients page.
VPN clients allowed to connect to this gateway

SSL Network Extender. Extender must be selected if you wish to make SSL Network Extender on-demand clients available to users. SecureClient Mobile. A pre-installed client for mobile devices. It is configured in the Policy > Global Properties > Remote Access > SecureClient Mobile window. Note - This option must be selected to allow the SecureClient Mobile clients to connect to the gateway. SecureClient Mobile is not affected by the Endpoint Compliance and Secure Workspace settings Endpoint Connect. Must be selected if you wish to allow users of the Endpoint Connect pre-installed client to connect to the gateway.
114
Advanced VPN Client configuration
VPN clients traffic

Connectra listens for SSL clients traffic on one or more of the Connectra machine interfaces, and on a specific port (service). Service is the TCP port on which Connectra listens for client communication. Machines interface is the IP address from which Connectra accepts client SSL connections.

For advanced VPN client configuration options, select the Connectra Gateway/Connectra Cluster object > VPN Clients > Advanced page.
Defining Which Clients are Downloaded to Endpoint Machines

Define which clients are downloaded to the endpoint machines. Automatically decide on client type according to endpoint machine capabilities downloads the SSL Network Extender Network Mode client if the user on the endpoint machine has administrator permissions, and downloads the Application Mode client if the user does not have administrator permissions.
Chapter 4
Application Mode only specifies that the SSL Network Extender Application Mode client is downloaded to the endpoint machines irrespective of the capabilities of the endpoint machine. Network Mode only specifies that the SSL Network Extender Network Mode client is downloaded to the endpoint machines irrespective of the capabilities of the endpoint machine. The user on the endpoint machine must have administrator permissions in order to access Native Applications.
IP Address Allocation for VPN Clients

Allocate IP from network assigns an IP address to SSL Network Extender Network Mode or Secure Client Mobile remote clients from a pool of internal addresses. This internal address identifies the client that is accessing Connectra Native Applications as being in the internal network. This method of allocating IP addresses is called Office Mode.
Name Resolution for Network Mode Clients

Name resolution for endpoint machines allows the SSL client to resolve Native Application DNS name servers via an organizational SNS server. In this window you can configure name resolution settings for endpoint machines in one of the following ways: Name Resolution Method Use the predefined name resolution settings on the endpoint machine. Download the settings used by Connectra to the endpoint machine when a secure connection is established. Download customized name resolution settings to endpoint machines when a secure connection is established. Setting Uncheck Download Name Resolution settings to endpoint machines Check Download Name Resolution settings to endpoint machines Select Use the settings from the Name Resolution page Check Download Name Resolution settings to endpoint machines Select Customize Specify up to three DNS servers, DNS Suffixes, and up to three WINS servers.
116
Configuring SSL Network Extender Advanced Options
VPN Clients Advanced Connectivity

Public IP address that VPN clients connect to is selected when the private and public IP addresses of the Connectra gateway are not the same. For example, if the real IP address of Connectra is NATed behind a public IP address, or is resolved using DNS.

For advanced SSL Network Extender configuration options, in the SmartDashboard Connectra tab, select the Additional Settings > VPN Clients > Advanced Settings for SSL Network Extender page, and click Edit.
Upgrade and Uninstall for Network Mode Clients

Client upgrade upon connection specifies how to deploy a new version of the SSL Network Extender Network Mode client on endpoint machines, when it becomes available. This setting is global and applies to all Connectra gateways managed by SmartCenter. Note - Upgrading requires Administrator privileges on the endpoint machine.
Chapter 4
Client uninstall upon disconnection specifies how to handle the installed SSL Network Extender Network Mode client on the endpoint machine when the client disconnects. This setting applies to all Connectra gateways that are managed by SmartCenter. Do not uninstall allows the user to manually uninstall if they wish to. Ask User allows the user to choose whether or not to uninstall. Always uninstall does so automatically, when the user disconnects.
Encryption
Supported Encryption methods defines the strength of the encryption used for communication between SSL Network Extender clients and all Connectra gateways and gateway clusters that are managed by SmartCenter. 3DES only. This is the default. The 3DES encryption algorithm encrypts data three times, for an overall key length of 192 bits. 3DES or RC4 to configure the SSL Network Extender client to support the RC4 encryption method, as well as 3DES. RC4 is a variable key-size stream cipher. The algorithm is based on the use of a random permutation. It requires a secure exchange of a shared key that is outside the specification. RC4 is a faster encryption method than 3DES.
Launch behavior
These settings define the behavior of the SSL Network Extender clients when launched on the endpoint machines. Automatically minimize client window after client connects minimizes the SSL Network extender window to the system tray on the taskbar after connecting. This makes for better usability for non-technical users.
Configuring Authorized Locations per User Group

The authorized locations (hosts or address ranges) of a Native application are defined in the Authorized Locations page of the Native Application. However, it is also possible to configure authorized locations per user group. Users who belong to two or more groups, are allowed to access the union of the authorized locations of the groups. For configuration details, see see SecureKnowledge solution sk32111.
118
Configuring SecureClient Mobile

In This Section
SecureClient Mobile Configuration Modes Configuring SecureClient Mobile on Connectra page 119 page 119
SecureClient Mobile Configuration Modes

SecureClient Mobile has two modes of operation. Enforcement Mode The client on the hand-held device connects to Connectra and downloads a set of policies. The client then enforces those policies. Clients can access any Connectra Native Application. This mode of operation requires a available license for SecureClient Mobile on the Connectra gateway. Connectivity Mode The client on the hand-held device connects to Connectra and can access Connectra Native Applications, the but cannot download policies. This mode applies when the Connectra gateway does not have a SecureClient Mobile license available for the connecting device.
Configuring SecureClient Mobile on Connectra

Note - To enable devices to connect to Connectra in Enforcement Mode, ensure there are sufficient licenses for SecureClient Mobile on the Connectra gateway. To enable support for SecureClient Mobile on Connectra: 1. Enable SecureClient Mobile. In the Connectra tab, select the Additional Settings > VPN Clients page Locally managed Connectra: Select SecureClient Mobile.
Centrally managed Connectra: From the list of available gateways, select a Connectra Gateway or Connectra Cluster object and click Edit....
Chapter 4
The Connectra Properties window opens, at the VPN Clients page.
Select SecureClient Mobile. 2. Configure Native Applications. See Configuring a Simple Native Application on page 127 and Configuring an Advanced Native Application on page 130. 3. Configure the SecureClient Mobile settings. In the Connectra tab, select the Additional Settings > VPN Clients page and click Edit under Advanced Settings SecureClient Mobile.
120
In a centrally managed Connectra, the Advanced Settings SecureClient Mobile page can also be found in Global Properties > Remote Access > SecureClient Mobile.
For information about each of the SecureClient Mobile options, see Central Management of SecureClient Mobile on page 377. 4. Install the Policy.
Chapter 4
Endpoint Application Types
Endpoint Application Types

When defining a Native Application, you can define applications on endpoint machines. These applications launch on the endpoint machine when the user clicks a link in the Connectra portal. You do not have to configure endpoint applications for users using SSL Network Extender in Network Mode, as they will be able to access them using their native clients.
In This Section
Application Installed on Endpoint Machine Application Runs Via a Default Browser Application Downloaded From Connectra Ensuring the Link Appears in the End-User Browser page 122 page 122 page 123 page 125
Application Installed on Endpoint Machine

These endpoint applications are already installed on the endpoint machines.
Application Runs Via a Default Browser

Run via default browser is used to define a link to any URL. The link appears in the Connectra portal, and launches the current Web browser (the same browser as the Connectra portal). The link can include $$user, which represents the username of the currently logged-in user. This option has a similar user experience to a Web Application with a URL: The application is opened in a Web browser. However, Connectra Web applications perform Link Translation on the URL and encrypt the connection over SSL, while the Run via default browser option with SSL Network Extender does not perform link translation, and encrypts using SSL Network Extender. You may prefer to define a Native Application rather than a Web Application for convenience, or because some Web sites have problems working with Link Translation.
122
Application Downloaded From Connectra

Downloaded-from-Connectra applications (known as Embedded Applications in Connectra NGX R62 and below) allow you to select a client application located on the Connectra gateway, that is downloaded from Connectra to the endpoint machine when the user clicks a link in the Connectra portal These applications allow end users to securely use client-server applications, without requiring a native client to be installed on their machines. Two kinds of downloaded-from-Connectra Applications are available by default: Certified Applications and Add-on Applications. Certified applications are an integral part of Connectra, and are fully supported. Add-on downloaded-from-Connectra applications are third-party applications, which are supplied as-is, and for which Check Point provides limited support. Connectra provides eight built-in applications that the administrator can configure. Downloaded-from-Connectra applications are either Java-based applications or single-executable applications (including batch files). All the applications that are available by default, other than the Terminal (PuTTY) client, are Java based applications, and are therefore multi-platforms applications. The PuTTY client can be used only on Windows machines. It is possible to add downloaded-from-Connectra applications to Connectra, in addition to the built-in applications. See Adding a New Downloaded-FromConnectra Endpoint Application on page 145.
Chapter 4
Certified Applications
Certified applications are an integral part of Connectra, and are fully supported. The packages that are downloaded to the endpoint machine are signed by Check Point. Table 4-2 lists the available certified downloaded-from-Connectra Native Applications: Table 4-2
Downloaded-from-Connectra Certified Applications
Application Telnet SSH
Description Telnet terminal. Provides user oriented command line login sessions between hosts on the Internet. Secure Shell (SSH) is designed for logging into and executing commands on a networked computer. It provides secure encrypted communications between two hosts over an insecure network. An SSH server, by default, listens on the standard TCP port 22. IBM 3270 terminal emulator tailored to writing screenscraping applications. TN3270 is the remote-login protocol used by software that emulates the IBM 3270 model of mainframe computer terminal. IBM 5250 terminal emulator that interprets and displays 5250 data streams.
TN3270
TN5250
For configuration details, see Configuring Downloaded-From-Connectra Endpoint Applications on page 138.
Add-on Applications
Add-on downloaded-from-Connectra applications are third-party applications, which are supplied as-is, for which Check Point provides limited support.
124
Ensuring the Link Appears in the End-User Browser
These packages are not signed by Check Point, and when they are downloaded by end- users a popup warning informs the user that the package is not signed. If the application does not function as expected, it can be deleted or replaced. Table 4-3 lists the available downloaded-from-Connectra Native Applications: Table 4-3
downloaded-from-Connectra Add-On Applications
Application Remote Desktop (RDP)
Description Downloaded-from-Connectra Client for Windows NT Terminal Server and Windows 2000/2003 Terminal Services. Communicates using Remote Desktop Protocol (RDP) in order to present the user's NT desktop. Unlike Citrix ICA, no server extensions are required. Runs on Java 1.1 up (optimized for 1.4), and works on Linux, Windows and Mac. An implementation of Telnet and SSH for Win32 platforms, including an Xterm terminal emulator. Downloaded-from-Connectra Jabber Client is an instant messenger based on the Jabber protocol Runs on every computer with at least Java 1.4. Graphical Java network and file transfer client. Supports FTP using its own FTP API and various other protocols like SMB, SFTP, NFS, HTTP, and file I/O using third party APIs, includes many advanced features such as recursive directory up/download, browsing FTP servers while transferring files, FTP resuming and queueing, browsing the LAN for Windows shares, and more
Terminal (PuTTY) Jabber
FTP
For configuration details, see Configuring Downloaded-From-Connectra Endpoint Applications on page 138.

If an endpoint application is defined by the administrator, but is not available on the endpoint machine, the link to the application will not be shown in the Connectra portal.
Chapter 4
For example, the link will not be shown if: An endpoint application that is pre-installed on the endpoint machine (of type Already Installed) is configured, and the application is in fact not installed on the endpoint machine. A Downloaded-from-Connectra (Embedded) application requires Java, but Java is not installed on the endpoint machine.
126
Configuring a Simple Native Application
Configuring a Simple Native Application

To configure a simple Native Application: 1. In the Connectra tab navigation tree, select Applications > Native Application. 2. Click New. The Native Application window opens. The following sections explain the fields in each page.
General Properties
In the General Properties page, define the name of the Native Application.
Authorized Locations
Go to the Authorized Locations page.
An authorized location ensures users of the Native Application can only access the specified locations using the specified services. Host or Address Range is the machine or address range on which the application is hosted. Service is the port on which the machine hosting the application listens for communication from application clients.
Chapter 4
Applications on the Endpoint Machine
Applications on the Endpoint Machine

Go to the Endpoint Applications page.
Add link in the Connectra portal must be selected if you want to make available to users endpoint application(s) associated with the Native Applications. Link text can include $$user, a variable that represents the username of the currently logged-in user. Tooltip for additional information. Can include $$user, which represents the username of the currently logged-in user. Path and executable name must specify one of the following:
Note - If the endpoint application is not available on the endpoint machine, the link to the
application will not be shown in the end users browser.
Full path of the application on the endpoint machines. For example, c:\WINDOWS\system32\ftp.exe The location of the application by means of an environment variable. This allows the location of the application to be specified in a more generalized way. For example %windir%\system32\ftp.exe
128
Completing the Native Application Configuration
If the application is listed in the Windows Start > Programs menu, only the application name need be entered, as it appears to the user in the Start menu. For example HyperTerminal. If the location of the application is in the path of the endpoint machine, only the application name need be entered. For example ftp.exe
Parameters are used to pass additional information to the applications on the endpoint machine, and to configure the way they are launched. Can include $$user, which represents the username of the currently logged-in user.
Completing the Native Application Configuration

If necessary, configure VPN clients. See Configuring VPN Clients on page 114. After doing so: 1. Go to the Access to Application page of the Connectra tab.
Chapter 4
Configuring an Advanced Native Application
Configuring an Advanced Native Application

To configure an advanced Native Application: 1. In the Connectra tab navigation tree, select Applications > Native Application. 2. Click New. The Native Application window opens. The following sections how to define advanced Native Application features.
In This Section
Configuring Connection Direction Multiple Hosts and Services Automatically Starting the Application Making an Application Available in Application Mode Automatically Running Commands or Scripts page 130 page 131 page 133 page 134 page 135
Configuring the Endpoint Application to Run Via a Default Browser page 132
Configuring Connection Direction

In the General Properties page of the Native Application object, click Connection direction... .
Select one of the following options: Client to server: (For example, Telnet.) This is the default option. When you create a client to server application and assign it to a user group, you enable users of the group to initiate a connection to the specified server. Server to client: (For example, X11.) When you create a server to client application, the specified server can initiate a connection to all SSL Network Extender or Secure Client Mobile users currently logged on to the Connectra gateway, regardless of their group association.
130
Multiple Hosts and Services
Client to client: (For example, running Remote Administration from one client to another.) When you create a client to client Native Application and assign it to a user group, you enable users of that group to initiate a connection to all of the SSL Network Extender or Secure Client Mobile users currently logged on to Connectra, regardless of their user group association. Note - A Client to Client Native Application does not require configuration of a destination address.
Multiple Hosts and Services

The Native Application can reside on a range of hosts, that can be accessed by the Native Application clients. You can also specify more than one service that clients may use to communicate with the application. Users of the Native Application can only access the specified locations using the specified services. To define a Native application with multiple hosts and services: 1. Define a Native Application. 2. In the Authorized Locations page of the Native Application object, select Advanced: Edit. The Native Application - Advanced window opens.
Chapter 4
Configuring the Endpoint Application to Run Via a Default Browser
3. Click Add... or Edit. The Native Application Hosts window opens
Configuring the Endpoint Application to Run Via a Default Browser

To configure the Endpoint Application to run via a default browser: 1. Define a Native Application. 2. In the Endpoint Applications page of the Native Application object, select Add link in the Connectra portal. 3. Select Advanced > Edit. The Endpoint Applications - Advanced window opens.
132
Automatically Starting the Application
4. Click Add. The Edit Endpoint Application window opens.
Run via default browser is used to define a link to any URL. The link appears in the Connectra portal, and launches the current Web browser (the same browser as the Connectra portal). The link can include $$user, which represents the username of the currently logged-in user. This option has a similar user experience to a Web Application with a URL: The application is opened in a Web browser. However, Connectra Web applications perform Link Translation on the URL and encrypt the connection over SSL, while the Run via default browser option with SSL Network Extender does not perform link translation, and encrypts using SSL Network Extender. You may prefer to define a Native Application rather than a Web Application for convenience, or because some Web sites have problems working with Link Translation.
Automatically Starting the Application

To configure the Endpoint Application to start automatically: 1. Define a Native Application. 2. In the Endpoint Applications page of the Native Application object, select Add link in the Connectra portal. 3. Select Advanced > Edit. The Endpoint Applications - Advanced window opens.
Chapter 4 Native Applications for Client-Based Access 133
Making an Application Available in Application Mode
4. Click Add or Edit. The Edit Endpoint Application window opens. 5. Click Advanced.... The Advanced window opens.
Automatically start this application allows you to configure a Native Application to run a program or command automatically, after connecting to or disconnecting from SSL Network Extender (either Network mode or Application mode). When more than one Native Application is defined for automatic connection or disconnection, the applications run in the alphabetical order of the names of the Native Applications. When SSL Network Extender is disconnected option should not be used to launch applications that require connectivity to the organization. Note that this problem only occurs with SSL Network Extender Application Mode. In Network Mode, applications automatic start of applications when SSL Network Extender is disconnected works correctly.
Making an Application Available in Application Mode

To make an application available in Application Mode: 1. Define a Native Application. 2. In the Endpoint Applications page of the Native Application object, select Add link in the Connectra portal. 3. Select Advanced > Edit. The Endpoint Applications - Advanced window opens. 4. Click Add or Edit. The Edit Endpoint Application window opens.
134
Automatically Running Commands or Scripts
5. Click Advanced.... The Advanced window opens,
6. Select Show link to this application in SSL Network Extender Application Mode. The option SSL Network Extender application mode compatibility allows you to make an application available to Application Mode clients. Users that connect using the SSL Network Extender Application Mode client are able to see a link to the application and launch it. Use this option if the application works well in Application Mode. Note - If this option is NOT selected, users: 1. Who connect with Application Mode do not see it in their list of applications. 2. With SecureClient Mobile clients on handheld devices are unable to connect to the application.

Connectra allows you to define a Native Application that runs a program ( a command, for example). Note - The user must have the appropriate privileges on the endpoint machine to run the
commands.
It is possible to configure a Native Application to run a program or command automatically, after connecting to or disconnecting from SSL Network Extender (either Network mode or Application mode).
Chapter 4
One example of how automatically running a command can be useful is to mount or unmount a network drive. Giving users access to network drives is a convenient way of providing access to internal resources. A drive can be mapped by configuring an application that invokes the Windows net use command. Note - When more than one Native Application is defined for automatic connection or disconnection, the applications run in the alphabetical order of the names of the Native Applications. For configuration details, see How to Automatically Map and Unmap a Network Drive on page 136. It is possible to extend this ability by defining a dynamic add-on downloaded-fromConnectra application that runs a script (batch file) containing a sequence of commands to execute on the endpoint machine. This script can be launched manually when the user clicks a link, or it can launch automatically after connecting to or disconnecting from SSL Network Extender. For configuration details, see How to Automatically Run a Script (Batch File) on page 137.
How to Automatically Map and Unmap a Network Drive

Automatically running a command can be useful is to mount or unmount a network drive. Giving users access to network drives is a convenient way of providing access to internal resources. A drive can be mapped by configuring an application that invokes the Windows net use command. Note - The net use command is available for SSL Network Mode only.
To automatically map (mount) and unmap (unmount) a network drive, create a Native Application that automatically maps the network drive when SSL Network Extender is launched: 1. Define a Native Application. 2. In the Endpoint Applications page of the Native Application object, select Add link in the Connectra portal. 3. Select Advanced > Edit. The Endpoint Applications - Advanced window opens. 4. Click Add or Edit. The Edit Endpoint Application window opens. 5. Configure the Edit Endpoint Application page as follows:
136
Already installed. Path and executable name: net.exe Parameters: use drive_letter: \\servename\sharename
6. Click Advanced. In the Advanced page, check When SSL Network Extender is launched. 7. Create another Native Application that automatically unmaps the network drive when SSL Network Extender is disconnected. Configure the Edit Endpoint Application page as follows: Already installed. Path and executable name: net.exe Parameters: use /DELETE drive_letter:
8. Click Advanced. In the Advanced page, check When SSL Network Extender is disconnected.
How to Automatically Run a Script (Batch File)

It is possible to define a new downloaded-from-Connectra Endpoint Application (embedded application) that runs a script (batch file) automatically after connecting to or disconnecting from SSL Network Extender. Proceed as follows: 1. Create a batch (script) file containing a sequence of commands. 2. Define the batch file as a new downloaded-from-Connectra Endpoint Application (Embedded Application). Adding a New Downloaded-FromConnectra Endpoint Application on page 145. 3. Define a Native Application. 4. In the Endpoint Applications page of the Native Application object, select Add link in the Connectra portal. 5. Select Advanced > Edit. The Endpoint Applications - Advanced window opens. 6. Click Add or Edit. The Edit Endpoint Application window opens. 7. Click Advanced. In the Automatically start this application section of the Advanced page, check When SSL Network Extender is launched.
Chapter 4
Configuring Downloaded-From-Connectra Endpoint Applications
Configuring Downloaded-From-Connectra Endpoint Applications

In the Endpoint Applications page of the Native Application object: 1. Select Add link in the Connectra portal. 2. Select Advanced > Edit. The Endpoint Applications - Advanced window opens. 3. Click Add. The Edit Endpoint Application window opens.
4. Select Downloaded from Connectra. 5. From the Name drop-down list, select the desired downloaded-from-Connectra application. 6. Specify the Parameters for the downloaded-from-Connectra application. The parameters field is used to pass additional information to the downloaded-fromConnectra applications on the endpoint machine, and to configure the way they are launched. The $$user variable can be used here to dynamically change according to the login name of the currently logged in user.
138
Configuring the Telnet Client (Certified Application)
See the configuration sections below for details of the required parameters : Note - In the configuration sections for certified and add-on applications, below: parameter is a compulsory parameter, [parameter] is an optional parameter, | indicates a required choice of one from many. Configuring the Telnet Client (Certified Application) on page 139 Configuring the SSH Client (Certified Application) on page 140 Configuring the TN3270 Client (Certified Application) on page 140 Configuring the TN5250 Client (Certified Application) on page 141 Configuring the Remote Desktop Client (Add-On Application) on page 141 Configuring the PuTTY Client (Add-On Application) on page 143 Configuring the Jabber Client (Add-On Application) on page 143 Configuring the FTP Client (Add-On Application) on page 144
7. Continue with Completing the Native Application Configuration on page 129.
Configuring the Telnet Client (Certified Application)

Table 4-4 Supported Platforms Parameters field Parameters usage Description Home page
Telnet Client Configuration
All Server name or IP address. Default port is 23.
server [port]
Telnet terminal. Provides user oriented command line login sessions between hosts on the Internet. http://javassh.org
Chapter 4
Configuring the SSH Client (Certified Application)
Configuring the SSH Client (Certified Application)

Table 4-5 Supported Platforms Parameters field Parameters usage Description
SSH Client Configuration
All Server name or IP address.
server
Secure Shell (SSH) is designed for logging into and executing commands on a networked computer. It provides secure encrypted communications between two hosts over an insecure network. An SSH server, by default, listens on the standard TCP port 22. http://javassh.org
Home page
Configuring the TN3270 Client (Certified Application)

Table 4-6 Supported Platforms Parameters field Description
TN3270 Client Configuration
All. Requires Java 1.3.1 or higher. Ignored IBM 3270 terminal emulator tailored to writing screenscraping applications. TN3270 is the remote-login protocol used by software that emulates the IBM 3270 model of mainframe computer terminal. http://jagacy.com
Home page
140

Table 4-7 Supported Platforms Parameters field
TN5250 Client Configuration
All endpoint machines must have Java 1.4 or higher. Optional. Can use the Configure button on the application instead. For the full list of options that can be used in the parameters field, see the Quick Start Guide http://tn5250j.sourceforge.net/quick.html.
Parameters usage Description
[Server [options]]
IBM 5250 terminal emulator that interprets and displays 5250 data streams. You will be presented with a Connections screen for defining sessions. Select the configure button to define sessions when the session selection window opens. On first invocation of the emulator there are some console warning messages. These inform you that defaults files are being set up for the first run.
Home page Quick Start Guide
http://tn5250j.sourceforge.net/index.html http://tn5250j.sourceforge.net/quick.html
Configuring the Remote Desktop Client (Add-On Application)

Table 4-8
Remote Desktop Client Configuration
Supported Platforms Parameters field
All. endpoint machines must have Java 1.4 or higher. Must contain the server name or its IP address.
Chapter 4
Configuring the Remote Desktop Client (Add-On Application)
Table 4-8
Remote Desktop Client Configuration (continued)
Parameters usage
[options] server[:port] For example: g 800x600 -l WARN RDP_Server. The following options are available: -b Bandwidth saving (good for 56k modem, but higher latency). This option unsets the TCP 'no delay' flag. -d Windows domain you are connecting to. -f Show the window full-screen (requires Java 1.4 for proper operation). -g WIDTHxHEIGHT. The size of the desktop in pixels. -m Keyboard layout on the terminal server for different languages (for example, en-us). -l {DEBUG, INFO, WARN, ERROR, FATAL} Amount of debug output (otherwise known as the logging level). -lc Path to a log4j configuration file. -n Override the name of the endpoint machine. -u Name of the user to connect as. -p Password for the above user. -s Shell to launch when the session is started. -t Port to connect to (useful if you are using an SSH tunnel, for example). -T Override the window title.
Downloaded-from-Connectra Client for Windows NT Terminal Server and Windows 2000/2003 Terminal Services. Communicates using Remote Desktop Protocol (RDP) in order to present the user's NT desktop. Unlike Citrix ICA, no server extensions are required. Runs on Java 1.1 up (optimized for 1.4), and works on Linux, Windows and Mac.
Description
142
Configuring the PuTTY Client (Add-On Application)
Table 4-8
Remote Desktop Client Configuration (continued)
Home page
http://properjavardp.sourceforge.net
Configuring the PuTTY Client (Add-On Application)

Table 4-9 Supported Platforms Parameters field Parameters usage Description Home page
Putty Client Configuration
Windows only Optional. Leaving the Parameters field empty leads PuTTY Client to opened in full graphical mode.
[[-ssh | -telnet | -rlogin | -raw] [user@]server [port]]

An implementation of Telnet and SSH for Win32 platforms, including an Xterm terminal emulator. http://www.eos.ncsu.edu/remoteaccess/putty.html
Configuring the Jabber Client (Add-On Application)

Table 4-10 Jabber Client Configuration Supported Platforms Parameters field Description All. endpoint machines must have Java 1.4 or higher. Ignored Downloaded-from-Connectra Jabber Client is an instant messenger based on the Jabber protocol Runs on every computer with at least Java 1.4. http://jeti.jabberstudio.org
Home page
Chapter 4
Configuring the FTP Client (Add-On Application)
Configuring the FTP Client (Add-On Application)

Table 4-11 FTP Client Configuration Supported Platforms Parameters field Description All. endpoint machines must have Java 1.4 or higher. Ignored Graphical Java network and file transfer client. Supports FTP using its own FTP API and various other protocols like SMB, SFTP, NFS, HTTP, and file I/O using third party APIs, includes many advanced features such as recursive directory up/download, browsing FTP servers while transferring files, FTP resuming and queueing, browsing the LAN for Windows shares, and more http://j-ftp.sourceforge.net
Home page
144
Adding a New Downloaded-From-Connectra Endpoint Application
Adding a New Downloaded-From-Connectra Endpoint Application

It is possible to add downloaded-from-Connectra applications to Connectra, in addition to the eight built-in applications. This section explains how, and gives two detailed examples.
In This Section
Downloaded-from-Connectra Application Requirements Example: Adding a New SSH Application Example: Adding a New Microsoft Remote Desktop Profile page 145 page 148 page 150
Procedure: Adding a New Downloaded-From-Connectra Application page 145
Downloaded-from-Connectra Application Requirements

Downloaded-from-Connectra applications are either Java-based applications or single-executable applications (including batch files). Java applications have the following requirements: Application must be packaged into a JAR file The JVM of a version required by the application must be installed on the endpoint machine. The application must have a Main class.
Single-executable applications have the following requirements: Must not require installation. Must be platform-specific for either Windows, Linux or MAC OS.
Procedure: Adding a New Downloaded-FromConnectra Application

To add a new downloaded-from-Connectra application you must first place the application in the relevant directory on Connectra, and then use the Database Tool (GuiDBedit) to specify the properties of the new downloaded-from-Connectra application.
Chapter 4 Native Applications for Client-Based Access 145
Procedure: Adding a New Downloaded-From-Connectra Application
Proceed as follows: 1. Compress your downloaded-from-Connectra application file into CAB file with the same name as the original file but with a .cab extension. To compress a file into a CAB file, you can use the Microsoft Cabinet Tool cabarc.exe (which can be downloaded from the Microsoft Web site). For example
cabarc.exe -m LZX:20 -s 6144 N ssh2.cab ssh2.jar

2. Copy both your downloaded-from-Connectra application file and the .cab file you created to the Connectra machine at $CVPNDIR/htdocs/SNX/CSHELL, 3. Change the application file permissions to read, write and execute. 4. Run the Check Point Database Tool GuiDBedit.exe from the directory where SmartConsole is installed (in the same installation directory as SmartDashboard). 5. Log in: For locally managed Connectra, log into Connectra. For Centrally managed Connectra, log into the SmartCenter management server. Enter the administrator user name and password.
6. Select Table > Other > embedded_applications. You will now see the embedded_applications table.
146
Procedure: Adding a New Downloaded-From-Connectra Application
7. In the right side pane, right-click and select New.... 8. In the Object field, enter a name for the new downloaded-from-Connectra application. 9. Specify the characteristics of the new downloaded-from-Connectra application as follows: Field Name Explanation The application name, which will appear in the drop-down list of downloaded-from-Connectra applications in SmartDashboard, in the Edit Endpoint Application window. The type of downloaded-from-Connectra application. Choose one of the options in the Valid Values list (java_applet, linux_executable mac_executable, windows_executable.). The name of the file you placed in $CVPNDIR/htdocs/SNX/CSHELL (not the .cab version). Indicate if the new downloaded-from-Connectra application requires the server name to be configured in the Parameters field of the new downloaded-from-Connectra application, in the SmartDashboard Edit Endpoint Application window. Parameters concatenated before the server_name_required_params field. Usually used when configuring a new downloaded-fromConnectra Java application. In that case, specify the Main Class name of the application. Parameters concatenated after the server_name_required_params field. Can be left blank. Leave as embedded_application.
display_name
embedded_application_type
file_name
server_name_required_params
pre_custom_params
post_custom_params
type
Chapter 4
Example: Adding a New SSH Application
You will now be able to see and configure the new downloaded-from-Connectra application in SmartDashboard, just as you do with the built-in downloaded-fromConnectra applications. The downloaded-from-Connectra applications appear in the Edit Network Application page of the Native Application object (Getting there: Native Application object > Endpoint applications page > Advanced: Edit > Add/Edit.

The following example adds two applications to Connectra as new downloadedfrom-Connectra applications: 1. SSH2 Java application: Jar file name: ssh2.jar Main class name: ssh2.Main The application gets its server name as a parameter. Name in SmartDashboard: Jssh2 Client.
2. SSH2 Windows executable: Executable file name: WinSsh2.exe The application gets its server name as parameter. Name in SmartDashboard: Essh2 Client.
148
Proceed as follows: 1. Compress the ssh2.jar and WinSsh2.exe application files into ssh2.cab and WinSsh2.cab Do this by running:
# cabarc.exe -m LZX:20 -s 6144 N ssh2.cab ssh2.jar # cabarc.exe -m LZX:20 -s 6144 N WinSsh2.cab WinSsh2.exe
2. Assuming the IP address of the SSH2 server is 1.1.1.1, you must save the files ssh2.jar and WinSsh2.exe to $CVPNDIR/htdocs/SNX/CSHELL with the proper permissions. 3. Place the application files in $CVPNDIR/htdocs/SNX/CSHELL with the proper permissions 4. Use GuiDBEdit to configure the two new downloaded-from-Connectra applications as follows: Table 4-12 SSH2 Java Application Field Name Value Jssh2 Client
display_name embedded_application_type file_name post_custom_params pre_custom_params server_name_required_params type

Table 4-13 SSH2 Windows Executable Field Name
java_applet ssh2.jar
Empty
ssh2.Main
true
embedded_application
Value Essh2 Client
display_name embedded_application_type file_name post_custom_params pre_custom_params server_name_required_params type
windows_executable WinSsh2.exe
Empty Empty true
embedded_application
Chapter 4
Example: Adding a New Microsoft Remote Desktop Profile
When configuring either of the new downloaded-from-Connectra applications in SmartDashboard (Jssh2 Client and Essh2 Client), the Parameters field will be: 1.1.1.1 (the SSH2 server IP in this example).

This example demonstrates how to configure Connectra to work with Microsoft Remote Desktop, with a predefined profile. Also shown is how to configure the profile per user group. 1. Create the Remote Desktop Profile 2. Create a CAB Package from the Profile 3. Configure the Package Downloaded-from-Connectra Application 4. Configure the Link to the Remote Desktop Application 5. Configure the Remote Desktop Profile to Start Automatically 6. Assign the Native Application to the User Group Repeat for every new Microsoft Remote Desktop Connection.
Create the Remote Desktop Profile

Create the RDP profile file (with a .rdp extension) using Microsoft Remote Desktop Connection, found at %SystemRoot%\system32\mstsc.exe. When creating the profile, you can define the address, the settings, applications that should run at log in, and more. In this example, the profile file has the name of the relevant user group. For a user group called mygr1, save a profile file called mygr1.rdp.
150
Create a CAB Package from the Profile

1. Compress the profile file into CAB file with the same name as the original file. The Microsoft Cabinet Tool Cabarc.exe can be used. It is available at http://msdn2.microsoft.com/en-us/library/aa751974.aspx. For this example, run the command: cabarc.exe -m LZX:20 -s 6144 N mygr1.cab mygr1.rdp This produces the output file mygr1.cab. 2. Copy both mygr1.rdp and mygr1.cab to the Connectra machine at $CVPNDIR/htdocs/SNX/CSHELL. 3. Change their permissions to read, write and execute.
Configure the Package Downloaded-from-Connectra Application

1. Run the Database Tool GuiDBedit.exe from the directory where SmartConsole is installed. The default location is: C:\Program Files\CheckPoint\SmartConsole\R65\PROGRAM. 2. Enter the administrator username and password. 3. Select Table > Other > embedded_applications.
Chapter 4
The embedded_applications table opens.
4. In the right side pane, right-click and select New.... 5. In the Object field, enter a name for the new downloaded-from-Connectra application. Give it the name of the relevant user group. In this example: mygr1 6. Specify the characteristics of the new downloaded-from-Connectra application as follows: display_name: mygr1_RDP_Policy embedded_application_type: windows_executable file_name: mygr1.rdp
152
It is now possible to see and configure the new downloaded-from-Connectra application in SmartDashboard, just as for the built-in downloaded-from-Connectra applications.
Configure the Link to the Remote Desktop Application

Configure the link to Microsoft Remote Desktop that will appear in the SSL Network Extender window. Define it as an Already Installed endpoint application. 1. Define a Native Application. 2. In the Endpoint Application page of the Native Application, select Add a Link to the application in the Connectra portal. 3. Select Advanced, and click Edit. The Endpint Applications - Advanced window opens 4. Click Add. the Edit Endpoint Application window opens.
Chapter 4
5. In the Edit Endpoint Application window, use the following settings, as shown in the screen capture: Link text (Multi-language): MS-RDP (or any other name). Path and executable name: %SystemRoot%\system32\mstsc.exe Parameters: %temp%\mygr1.rdp
6. Click OK.
Configure the Remote Desktop Profile to Start Automatically

In the same Native Application, add another endpoint application for the Remote Desktop Profile. Define it as a Downloaded from Connectra endpoint application, that is downloaded to the user desktop as soon as SSL Network Extender is launched. 1. In the Endpoint Applications - Advanced window, click Add. the Edit Endpoint Application window opens. 2. Configure the Remote Desktop profile package with the following settings, as shown in the screen capture.
154
Add link to the application in the Connectra portal must be unchecked. Name: mygr1_RDP_Policy (as configured in GUIdbedit.exe).
3. Click Advanced. The Advanced window opens 4. Select Automatically Start this Application: When SSL Network Extender is launched. 5. Click OK three times to save and close the Native Application.
Assign the Native Application to the User Group

Assign the Native Application to the relevant user group.
Chapter 4
156
5 Chapter Two-Factor Authentication

In This Chapter
Introduction to Two-Factor Authentication The SMS Service Provider SMS Authentication Granularity Basic Two-Factor Authentication Configuration Advanced Two-Factor Authentication Configuration page 158 page 159 page 160 page 161 page 166
This chapter explains how to configure two-factor authentication via SMS. After successfully authenticating using one of the allowed gateway authentication schemes, users can be challenged to provide additional credentials, sent to their mobile communications device via an SMS message.
157
Introduction to Two-Factor Authentication
Introduction to Two-Factor Authentication

Two-factor authentication is a system where two different methods are used to authenticate. Using two-factors as opposed to one delivers a higher level of authentication assurance. In the first phase of the authentication, users must authenticate to the Connectra portal or to a VPN client (such as Endpoint Connector SecureClient Mobile), using one of the enabled authentication schemes that are configured in the Users and Authentication > Authentication > Authentication Schemes page of the SmartDashboard Connectra tab. Users who successfully complete the first-phase authentication, can be challenged to provide an additional credential: A One Time Password (OTP). The OTP is sent to their mobile communications device (such as a mobile phone) via SMS. When logging in to the Connectra portal, users see an additional authentication challenge such as the following:
Note - Two -factor authentication is available for Connectra NGX R66 and higher.
158
The SMS Service Provider
The SMS Service Provider

The SMS messages are sent by the SMS service provider that Connectra is configured to work with. Two factor authentication can be configured to work with any SMS provider that is able to accept an HTTP request and translate it into an SMS message. To access the SMS service provider, the proxy settings that are configured in the SmartDashboard Connectra tab, Additional Settings > Network Elements > HTTP Proxy page are used. If none is defined, no proxy is used. Whichever provider you work with, in order for the SMS messages to be sent to users, valid account details must be obtained from the provider and be configured in Connectra.
Chapter 5
Two-Factor Authentication 159
SMS Authentication Granularity
SMS Authentication Granularity

Successful two-factor authentication can be made a requirement for logging in to the gateway. Alternatively, two-factor authentication can be made a requirement for accessing particular applications. This flexibility allows for varying security clearance levels. Making two-factor authentication a requirement for accessing specific applications is done by configuring a Protection Level to require two-factor authentication, and associating the Protection Level with Connectra applications. For details, see Two-Factor Authentication Per Application on page 170. Centrally managed Connectra only: In an environment with multiple Connectra gateways, making two-factor authentication a requirement for logging into a particular gateway is done by configuring two-factor authentication for that gateway. See Two-Factor Authentication Per Gateway (Central management only) on page 169.
160
Basic Two-Factor Authentication Configuration
Basic Two-Factor Authentication Configuration

Users can be challenged to provide additional credentials, sent to their mobile communications device via SMS, after successfully authenticating using one of the allowed gateway authentication schemes. The workflow for basic configuration of two-factor authentication via SMS, is: 1. Obtaining the SMS provider credentials 2. Configuring the Phone Directory 3. Basic SmartDashboard Configuration of Two-Factor Authentication 4. Testing Two-Factor Authentication
Obtaining the SMS provider credentials

Obtain your SMS service provider settings from your SMS provider. The following are required: A URL in the format specified by the SMS provider. Account credentials: Username Password API ID
Configuring the Phone Directory

The default phone number search method is that the gateway searches for phone numbers in user records on the LDAP account unit, and then in the phone directory on the local gateway. The phone number search method can be changed in the Phone Directory Locations section of the Two-Factor Authentication - Advanced window.
Chapter 5
1. If users authenticate via LDAP, configure the list of phone numbers on LDAP: On the LDAP server, define a phone number for each user, in the Mobile field. The following screen capture shows a phone number configured in Microsoft Active Directory.
Note - A different Active Directory field can be configured using Check Point Database Tool GUIDBEdit. Search for the string PhoneNumberAttr. 2. Configure the list of phone number on the local gateway. Note - Centrally managed Connectra only: The list of phone numbers must be configured on each Connectra gateway. For a Connectra cluster, configure the directory on each cluster member.
162
To configure a list of phone numbers on the local gateway: a. Log into the Connectra gateway using a secure console connection. b. Change to Expert mode: Type expert and then the expert mode password. c. Backup $CVPNDIR/conf/SmsPhones.lst d. Edit $CVPNDIR/conf/SmsPhones.lst, and add to it a list of usernames and phone numbers. The list must be followed by a blank line. Use the following syntax:
<username | Full DN> <phone number>
Table 5-1 Parameter username or Full DN
User Details and Phone Number
Meaning Either a username or, for users that log in using a certificate, the full DN of the certificate. All printable characters can be used in the phone number, excluding the space character, which is not allowed. Only the digits are relevant.
phone number
Example
bob +044-888-8888 CN=jane,OU=users,O=con1.example.com.qwerty +044-7777777
Chapter 5
Basic SmartDashboard Configuration of Two-Factor Authentication
Basic SmartDashboard Configuration of Two-Factor Authentication

1. Go to the Users and Authentication > Authentication > Authentication to Connectra page of the SmartDashboard Connectra tab. 2. In the Authentication Schemes page, select Challenge users to provide an OTP received at their mobile device via SMS.
Centrally managed Connectra only: This makes two-factor authentication a requirement for logging in to all Connectra gateways with authentication settings (configured in the Additional Settings > Authentication page of the Connectra gateways) of Use the global settings, configured in the Connectra tab, under Authentication to Connectra). Locally managed Connectra: This makes two-factor authentication a requirement for logging in to the Connectra gateway. 3. Enter the SMS Provider URL in the format provided by the provider. An example SMS provider URL is (on a single line):
https://api.example.com/http/sendmsg?api_id=$APIID&user= $USERNAME&password=$PASSWORD&to=$PHONE&text=$MESSAGE
164
Testing Two-Factor Authentication
The following table explains parameters used in the SMS Provider URL. The value of these parameters is automatically used when sending the SMS. Parameter Meaning The value of this parameter is the API ID. The value of this parameter is the username. The value of this parameter is the password. User phone number, as found in Active Directory or in the local file on the gateway. The value of this parameter is the message configured in the Advanced Two-Factor Authentication Configuration Options in SmartDashBoard.
$APIID $USERNAME $PASSWORD $PHONE $MESSAGE
4. In the SMS Provider Credentials section, enter the credentials received from the SMS provider: Username Password API ID
5. For additional configuration options, click Advanced. See Advanced Two-Factor Authentication Configuration Options on page 166. 6. Install the Policy. Select Policy > Install.
Testing Two-Factor Authentication

To test the two-factor authentication via SMS, after completing the configuration: 1. Browse to the URL of the Connectra portal. 2. Log in as a user. Supply the gateway authentication credentials. 3. Wait to receive the one time password (OTP) at your mobile communication device. 4. Enter the OTP at the portal. You should now be logged in to the Connectra portal.
Chapter 5
Advanced Two-Factor Authentication Configuration
Advanced Two-Factor Authentication Configuration

In This Section
Advanced Two-Factor Authentication Configuration Options Two-Factor Authentication Per Application page 166 page 170
Two-Factor Authentication Per Gateway (Central management only) page 169
Advanced Two-Factor Authentication Configuration Options

Advanced options for two-factor authentication are available on the SmartDashboard Users and Authentication > Authentication > Authentication to Connectra > Advanced page. Centrally managed Connectra only: Advanced options for two-factor authentication are available on the Connectra Gateway properties window, in the Additional Settings Authentication > Advanced page
166
Figure 5-1
Two Factor Authentication- Advanced Page
SMS Authentication Enforcement

SMS authentication is not mandatory. Allow user to log in but deny access to applications which require SMS authentication: When users log in, they are given the option to Skip the two-factor authentication. Users are allowed to log in, but are denied access to applications which require two-factor authentication.
Users must successfully authenticate via SMS in order to log in

Chapter 5 Two-Factor Authentication 167
SMS Message
SMS Message text sent to the user is Connectra one-time verification code: by default. The message can contain the template fields shown in Table 5-2. For example, the message could say: $NAME, use the verification code $CODE to enter the portal.
Template fields for the SMS provider Message
Table 5-2 Parameter
Meaning User name used in the first phase of authentication to the portal. Replaced with the One Time Password. By default, $CODE is added to the end of the message.
$NAME $CODE
One Time Password

Length of one time password is 6 digits by default One time password expiration (in minutes) is 5 minutes by default. Ensure there is a reasonably sufficient time for the SMS message to arrive at the mobile communication device, for the user to retrieve the password, and to type it in.
Reauthentication
Number of SMS authentication attempts before the entire authentication process restarts. By default the user has 3 tries.
Phone Number Display in Login Page

Show in the login page the phone number to which the SMS message will be sent. By default, the phone number to which the SMS message was sent is not shown.
Country Code
Default country code for phone numbers that don't include country code. The default country code is added if the phone number stored on the LDAP server or on the local file on the gateway starts with 0.
Phone Directory Retrieval

Retrieve phone numbers from user record if user record is fetched from LDAP account unit. If fails, retrieve from the local file on the gateway. The LDAP account unit is defined in the Users and Authentication > Authentication > LDAP Account Units page of the SmartDashboard Connectra tab. The phone directory on the local gateway is stored at $CVPNDIR/conf/SmsPhones.lst.
168
Two-Factor Authentication Per Gateway (Central management only)
Retrieve phone numbers from user record if user record is fetched from LDAP account unit. The LDAP account unit is defined in the Users and Authentication > Authentication > LDAP Account Units page of the SmartDashboard Connectra tab. Retrieve phone numbers from local file on the gateway. The phone directory on the local gateway is stored at $CVPNDIR/conf/SmsPhones.lst.
Two-Factor Authentication Per Gateway (Central management only)

Note - This section applies only to centrally managed Connectra.
Successful two-factor authentication can be made a requirement for logging on to some but not all Connectra gateways. There are two possible approaches: Globally on, with custom settings per gateway Turn on two-factor authentication globally, and then for each Connectra gateway configure custom settings: either turn off the feature, or configure gateway-specific settings. Globally off, with custom settings per gateway Turn off two-factor authentication globally, and then for selected Connectra gateways, turn it on, while configuring custom settings for those gateways. To configure two-factor authentication Globally on, with custom settings per gateway: 1. Set up basic two-factor authentication. See Basic Two-Factor Authentication Configuration on page 161. 2. Turn on two-factor authentication in the Users and Authentication > Authentication > Authentication to Connectra page. (See Basic Two-Factor Authentication Configuration) 3. In the Authentication to Connectra page, select a gateway and click Edit The Authentication page of the Connectra Properties window opens:
Chapter 5
Two-Factor Authentication Per Application
4. Choose one of the options: EITHER choose Use the settings configured in the Users and Authentication > Authentication > Authentication Schemes page. The global settings are used. This is the default. OR choose This gateway has its own two-factor authentication settings but do not select the checkbox. This turns off two-factor authentication for this gateway. OR choose This gateway has its own two-factor authentication settings and select the checkbox. You must then configure custom SMS Provider Credentials for this gateway (see Basic SmartDashboard Configuration of Two-Factor Authentication on page 164). Optionally, configure Advanced options (see Advanced Two-Factor Authentication Configuration Options on page 166).
5. Repeat step 3 to step 4 for all other gateways. 6. Install the policy. Select Policy > Install.

Two-factor authentication can be made a requirement for accessing particular applications. This is done configuring a Protection Level to require two-factor authentication, and associating the Protection Level with Connectra applications.
170
To configure two-factor authentication per application: 1. Set up basic two-factor authentication. See Basic Two-Factor Authentication Configuration on page 161. 2. Configure the Protection Level. See Defining Protection Levels on page 46. In the Authentication page, select User must successfully authenticate via SMS.
3. Assign the protection level to Connectra applications that require two-factor authentication. See Using Protection Levels on page 45.
Changing the SMS Provider Certificates and Protocol

By default, it is recommended to use a secure (https) protocol for communication with the SMS provider. Connectra also validates the provider server certificate using a predefined bundle of trusted CAs. If your SMS provider uses a non-trusted server certificate you can do one of the following: Add the server certificate issuer to the trusted CA bundle under $CVPNDIR/var/ssl/ca-bundle/ and run the $CVPNDIR/bin/rehash_ca_bundle script. Ignore the server certificate validation by editing $CVPNDIR/conf/cvpnd.C and replacing the SmsWebClientProcArgs value with ("-k").
If your SMS provider is working with the non-secure http protocol, edit the file $CVPNDIR/conf/cvpnd.C and replace the SmsWebClientProcArgs value with ("").
Chapter 5 Two-Factor Authentication 171
172
Chapter Authorization
In This Chapter
Identity and Access Management Authorization in Connectra Configuring Access To Applications
6
page 174 page 175 page 177
173
Identity and Access Management
Identity and Access Management

The Connectra strategy for identity management and access management is two-fold. 1. The first stage is authentication, which ensures that a user is who he or she claims to be. 2. The second stage is authorization, which allows the user access to various resources based on the user's identity. Authorization is the process of granting or denying access to a network resource.
Note - Centrally managed Connectra only:

For information about
Authentication schemes, and configuration of authentication servers, see the Authentication chapter of the Firewall and SmartDefense Administration Guide. LDAP, see the SmartDirectory (LDAP) and User Management chapter in the SmartCenter Administration Guide.
174
Authorization in Connectra
Once users are authenticated (recognized and approved), Connectra allows the users to access the appropriate applications for that user. This process is called Authorization. Authorization is done by enforcing an access control policy in the Access to Applications page of the Connectra tab (Figure 6-1). Access control policies are applied to groups, not individual users. Figure 6-1
The Access to Application Table
Remote users, once authenticated, can only access those applications which have been authorized for their groups. In other words, for access to be granted, Connectra checks for: Access rights. Does the remote user belong to a group which is allowed to access the application? Security requirements. Does the remote user meet the security restrictions as expressed by the applications Protection Level?
Each Connectra gateway or gateway cluster enforces its own Access to Application policy.
Chapter 6
Authorization 175
For example, a Web application for ordering office supplies is less sensitive than an application that controls money transfers. All remote users can be given access to the office-supplies application, identifying themselves with a username and password. However, the money transfer application may be restricted to an exclusive group of remote users and require them to authenticate using certificates. In this way, the level of security surrounding an application is based on the applications Protection Level and the user group. The first applicable rule is matched. If necessary, change the order to ensure that the appropriate rule is matched.
176
Configuring Access To Applications

To configure access to applications, proceed as follows: 1. Define Connectra applications: Web Applications, File shares, Citrix Services, Web Mail Applications (see Applications for Clientless Access on page 43) and/or Native Applications (Native Applications for Client-Based Access on page 107). In the definition, associate a Protection Level with the application. 2. Define users (if necessary), user groups, and (if necessary) associate users with groups. Note - Nested user groups are not supported by the Access to Applications policy.
3. Define the access to applications rules, to associate user groups, applications, and Connectra gateways: a. Go to the Access to Application page of the SmartDashboard Connectra tab. b. Click Add. The Access to Applications window opens.
c. In the User Groups tab, click Add to add one or more user groups. d. In the Applications tab, click Add to add one or more Connectra applications.
Chapter 6
Authorization 177
e. In the Install On tab, click Add to add one or more Connectra gateways or Connectra clusters. Note - *Any means all. For example, an *Any/*Any/*Any rule means all user groups can
access all the defined applications on all the defined Connectra gateways.
4. Install the policy.
178
7 Chapter Endpoint Security On Demand

In This Chapter
Endpoint Compliance Enforcement Secure Workspace Endpoint Compliance Updates page 180 page 215 page 231
179
Endpoint Compliance Enforcement
Endpoint Compliance Enforcement

In This Section:
Introduction to Endpoint Compliance Enforcement Endpoint Compliance Policy Rule Types Endpoint Compliance Logs Workflow for Endpoint Compliance Configuration Defining the Endpoint Compliance Policy Using the ICSInfo Tool Configuring the Endpoint Compliance Policy Configuring Endpoint Compliance Endpoint Compliance Scanner End-User Workflow page 180 page 181 page 192 page 193 page 194 page 196 page 197 page 199 page 208
Introduction to Endpoint Compliance Enforcement

The Check Point Endpoint Security On Demand scanner enforces endpoint compliance by scanning the endpoint for potentially harmful software. If the endpoint is compliant with a pre-defined endpoint compliance policy, the user is allowed to access the portal. By ensuring that endpoints comply with a security policy, Endpoint Security On Demand protects enterprises from threats emanating from unsecured endpoint computers that can result in data loss and excessive bandwidth consumption. The endpoint compliance policy is made up of rules. The policy can specify, for example, that the endpoint machine must have an approved anti-virus application, and that it must be free of spyware.
Endpoint Compliance Policy Granularity

The administrators can make compliance with a policy a requirement for accessing either the portal or specific applications. This makes it possible to assign varying levels of security clearance to the portal and to Connectra applications.
180
Endpoint Compliance Policy Rule Types
Endpoint Compliance policies can be assigned to Connectra gateways. They can also be assigned to Protection Levels, which are in turn associated with Connectra applications. If an Endpoint Compliance policy is assigned to a gateway, endpoint machines must comply with the policy before they are allowed to log in to the portal. To provide additional protection to an application, it is possible to harden the Endpoint Compliance protection that is enforced by the gateway by assigning an Endpoint Compliance policy to a Protection Level, and then assigning that Protection Level to an application. In order to access that application, the endpoint machine must comply with the policy associated with the Protection Level, in addition to the policy associated with the gateway. In either case, the scan takes place before logging in to the portal. Only one scan is performed. Compliance to policies is determined according to the results of the scan.
Endpoint Compliance Licensing

To use Endpoint Compliance, a valid Endpoint Security On Demand license is required for the Connectra gateway. For Connectra version NGX R66 and higher, this requirement is enforced. At least as many Endpoint Security On Demand users as Connectra users must be installed.

There are different types of Endpoint Compliance policy rules, for different types of security application. It is possible to have multiple rules of the same type, each with different settings.
In This Section
Windows Security Rule Anti-Spyware Application Rule Anti-Virus Application Rule Firewall Application Rule Custom Check Rule OR Group of Rules Spyware Scan Rule page 182 page 183 page 184 page 185 page 187 page 188 page 189
Chapter 7
Endpoint Security On Demand 181
Windows Security Rule

Windows security rules perform Windows-specific checks. For example: Check for the latest Windows Service Pack on endpoint. Check the enabled/disabled state of the built-in Microsoft Windows Automatic Updates system. Check for Microsoft Windows Hotfixes and patches on the endpoint. Enforcement of Windows patches by their ID.
Endpoint computers running Windows must pass these checks in order to gain access to the network. At least one of the Hotfixes in the rule must be active on the endpoint computer in order for the endpoint to be considered compliant and be granted access to the portal. The rules also specify the action to be taken if an endpoint computer fails to comply with a rule and the error message that is presented to users in the event of non-compliance, such as remediation information.
182
Endpoint Compliance Policy Rule Types Figure 7-1 Windows Security Rule Configuration Window
Anti-Spyware Application Rule

Choose which anti-spyware applications endpoint computers (on the Windows platform) must have to gain access to the network. Ensure that appropriate anti-spyware software is running on endpoint computers, and that the software version and virus signature files are up-to-date. At least one of the anti-spyware applications in the rule must be active on the endpoint computer in order for the endpoint to be considered compliant and be granted access to the portal. For convenience, anti-spyware enforcement rules are pre-configured with supported anti-spyware providers. To require a non-supported anti-spyware provider, use a custom check rule.
Chapter 7
The rules also specify the action to be taken if an endpoint computer fails to comply with a rule and the error message that is presented to users in the event of non-compliance, such as remediation information.
Figure 7-2 Anti-Spyware Rule Configuration Window
Anti-Virus Application Rule

Choose which anti-virus applications endpoint computers (on the Windows, Linux or Macintosh platforms) must have to gain access to the network. Ensure that appropriate antivirus software is running on endpoint computers, and that the software version and virus signature files are up-to-date. At least one of the anti-virus applications in the rule must be active on the endpoint computer in order for the endpoint to be considered compliant and be granted access to the portal.
184
For convenience, anti-virus enforcement rules are pre-configured with supported anti-virus providers. To require a non-supported anti-virus provider, use a custom check rule. The rules also specify the action to be taken if an endpoint computer fails to comply with a rule and the error message that is presented to users in the event of non-compliance, such as remediation information.
Figure 7-3 Anti-Virus Rule Configuration Window
Firewall Application Rule

Choose which firewall applications endpoint computers (on Windows, Linux or Macintosh platforms) must have to gain access to your network. Ensure that appropriate firewall software is installed, enabled and running on endpoint computers.
Chapter 7
At least one of the firewall applications in the rule must be active on the endpoint computer in order for the endpoint to be considered compliant and be granted access to the portal. For convenience, firewall enforcement rules are pre-configured with supported firewall providers. To require a non-supported firewall provider, use a custom check rule. The rules also specify the action to be taken if an endpoint computer fails to comply with a rule and the error message that is presented to users in the event of non-compliance, such as remediation information.
Figure 7-4 Firewall Rule Configuration Window
186
Custom Check Rule

Perform custom checks on endpoint computers (on the Windows, Linux or Macintosh platforms) that are not covered by any of the other rule types. For example: Custom applications. These applications may include proprietary spyware scanners that supplement the predefined types and/or other special security solutions. Specific files. Registry keys or processes running on the endpoint computer. Non-English or localized names of processes and files.
Custom check rules can be configured to check for specific versions and modification dates. The rules also specify the action to be taken if an endpoint computer fails to comply with a rule, and the error message that is presented to users in the event of non-compliance, such as remediation information.
Chapter 7
Endpoint Compliance Policy Rule Types Figure 7-5 Custom Check Rule Configuration Window
OR Group of Rules
An OR Group of Rules rule includes a list of previously defined rules. An endpoint satisfies a rule of type OR Group of Rules if it satisfies one or more of the rules included in the OR Group of Rules rule. The rules also specify the action to be taken if an endpoint computer fails to comply with a rule and the error message that is presented to users in the event of non-compliance, such as remediation information.
188
Endpoint Compliance Policy Rule Types Figure 7-6 OR Group of Rules Rule Configuration Window
Spyware Scan Rule

Select the action that should take place for each type of spyware present on endpoint computers. Note - Spyware is referred to as Malware in Connectra NGX R62 and R62CM.
Chapter 7
Customizable protection is available for a wide variety of spyware threats, as shown in Table 7-1:
Table 7-1 Spyware Types
Spyware Type Dialer
Description Software that change the users dialup connection settings so that instead of connecting to a local Internet Service Provider, the user connects to a different network, usually a toll number or international phone number. Programs that replicate over a network for the purpose of disrupting communications or damaging software or data. Programs that record user input activity (keystrokes or mouse activity). Some keystroke loggers transmit the recorded information to third parties. Tools that facilitate unauthorized access to a computer and/or extraction of data from a computer. Commercially developed software that allows remote system access and control. Malicious programs that masquerade as harmless applications. Programs that display advertisements, or record information about Web use habits and forward it to marketers or advertisers without the users authorization or knowledge. Any unsolicited software that secretly performs undesirable actions on a users computer and does not fit any of the above descriptions. Software that record what a users monitor displays. Cookies that are used to deliver information about the users Internet activity to marketers. Software that modifies or adds browser functionality. Browser plug-ins change the default search page to a pay-per-search site, change the user's home page, or transmit the browser history to a third party.
Worm Keystroke Logger
Hacker Tool Remote Administration Tool Trojan Adware
Other
Screen Logger Tracking Cookie Browser Plug-in
It is possible to define an exception list of spyware software. For example, you can specify that a specific spyware signature is not blocked (see Excluding a Spyware Signature from a Scan on page 206).
190
The rules also specify the action to be taken if an endpoint computer fails to comply with a rule and the error message that is presented to users in the event of non-compliance, such as remediation information.
Figure 7-7 Spyware Scan Rule Configuration Window
Note - Connectra NGX R62CM and R62 have a Malware Protection option to Attempt to disable detected processes. This option is not available in NGX R66 and above. The Endpoint Compliance component of Endpoint Security On Demand in NGX R66 and above only collects information. It does not change anything on the client machine.
Chapter 7
Endpoint Compliance Logs
Endpoint Compliance Logs

If the end user machine is not compliant with one or more of the Endpoint Compliance policy rules, Connectra generates Endpoint Compliance-specific logs with the category ESOD (Endpoint Security On Demand). The log entries appear in SmartView Tracker, and include the: 1. Rule ID and name that causes the authorization failure. 2. Policies that this rules belongs to.
Note - Connectra logs incompliant rules from all policies, not only the Endpoint Compliance policy that is assigned to the gateway or to an application. This means that there may be entries in SmartView Tracker for rules that do not appear in the report presented to the end user.
3. A description in the info field of the log. Two logging levels are available to the administrator: (For configuration details, see Configuring Endpoint Compliance Logs on page 204.) Summary: only one log entry per scan is written to SmartView Tracker. The log entry shows endpoints that do not comply with the Endpoint Compliance policy. The date and time of the scan, the source IP, and the Endpoint Compliance scan ID are logged. Details: In addition to the Summary mode information, this adds a log entry for each non-compliant rule. For example, in the case of a Spyware Scan rule that screens for tracking cookies, a log entry is generated that contains the following fields: A. Malware name: unwantedexample. B. Malware type: 3rd party cookie. C. Description: symptom type: URL. Symptom value: cookie:bob@unwantedexample.net.
192
Workflow for Endpoint Compliance Configuration Figure 7-8 Example Endpoint Compliance Log
Workflow for Endpoint Compliance Configuration

The workflow for configuring Endpoint Compliance enforcement is as follows. Each step is described in detail in the next sections: 1. Define the Endpoint Compliance Policy Decide on security clearance levels for Connectra portals and applications. For example, is it OK for users to gain access to all Connectra applications as long as they comply with a a single set of requirements (that is, a single policy)? If some resources are more sensitive than others, you may wish to draw up a more stringent policy for some applications than for others. 2. Use the ICSInfo Tool Set up a stand-alone test computer with all the endpoint security applications you want to create enforcement rules for, and the run the ICSinfo tool to obtain the information needed to correctly define Endpoint Compliance policy rules. 3. Configure Endpoint Compliance Policies Policies are made up of rules. In order to comply with the policy, endpoints must comply with all rules in the policy. Rules can be used in more than one policy. Rules that are not in a policy are not used.
Chapter 7
Defining the Endpoint Compliance Policy
There are different types of rules for different security applications. The Endpoint Compliance policy configuration tool comes with a number of predefined rules which can be edited to match the needs of the organization. 4. Assign Policies to gateways To make access to the portal conditional on passing an Endpoint Compliance scan, assign a policy to a gateway. 5. Assign Policies to Applications To make access to applications conditional on passing an Endpoint Compliance scan: a. Assign a policy to a Protection Level. b. Assign Protection Levels to Connectra applications. 6. Complete the Endpoint Compliance Configuration Configure tracking options for the endpoint scan results, then save and install the security policy

Defining the Endpoint Compliance policy for Connectra clients involves some planning, prior to performing the SmartDashboard configuration. You need to define security clearance levels for the both the Connectra portal (that is, the gateway) and for portal applications. There are various approaches, and the best one to use depends on how granular you need to make the policy. Basic Approach The simplest approach is to define a single Endpoint Compliance policy for the gateway and all applications accessed via the gateway. In this approach, all applications accessed via the gateway are protected by the Endpoint Compliance policy of the gateway. Users whose client machines comply with the policy have access to the portal and all applications. For example: Resource Gateway A Web App P Web App Q File Share R Endpoint Compliance policy Low Security Rely on gateway requirements Rely on gateway requirements Rely on gateway requirements
194
Advanced Approach A more advanced approach is appropriate if there is one application (or a small number of applications) that has stricter security requirements than other applications. These additional requirements are specified in a separate Endpoint Compliance policy, which is enforced in addition to the gateway policy. To access the Connectra portal, all users must fulfil the threshold security requirements of the gateway policy. Users clicking a link in the portal to an application with additional security requirements are only allowed access to the application if they fulfill those additional requirements. For example: Resource Gateway A Web App P Web App Q File Share R Endpoint Compliance policy Low Security Rely on gateway requirements High Security Rely on gateway requirements
Very Advanced Approach Where most or every application has its own endpoint security requirements, it is possible to define an individual Endpoint Compliance policy for each application. In this scenario, there are no gateway security requirements: All users are able to access the portal. However, when clicking a link to an application, users are only allowed access if they fulfill the requirements for that application. If no requirements are configured for the application, users are allowed to access it. For example: Resource Gateway A Web App P Web App Q File Share R Endpoint Compliance policy None Low Security High Security Medium Security
Chapter 7
Using the ICSInfo Tool
Example Rules for Endpoint Compliance Policies

The following table illustrates Endpoint Compliance policies with different rules, for different security requirements. Rule Description High Security Endpoint Compliance policy Yes Yes Yes Yes Medium Security Endpoint Compliance policy Yes Yes Yes No Low Security Endpoint Compliance policy No Yes Yes No
1 2 3 4
Default Windows Security rule Anti-Virus applications check Firewall applications check Spyware Scan rule
Using the ICSInfo Tool

When defining Endpoint Compliance policy rules, you must use the correct format. This format varies from vendor to vendor. The ICSinfo.exe utility scans your computer, and generates an xml file that gives you the information in the correct format for all supported security programs it finds. Run ICSinfo before configuring the Endpoint Compliance policy rules. To use the ICSinfo.exe utility: 1. Set up a stand-alone test computer with all the endpoint security applications you want to create enforcement rules for. Be sure to apply the latest updates to your security software. 2. Copy the ICSinfo tool from the Connectra gateway to the test computer. The tool is located at $CVPNDIR/htdocs/ICS/components/ICSinfo.exe. 3. Run ICSinfo.exe. This utility lists all detected security software, along with the required information in the correct format. The xml format output file ICSinfo.xml can be viewed in a browser. The sections of the file can be collapsed or expanded by clicking the - or +. 4. Record the information for each security program and use this information to create your Endpoint Compliance policy rules.
196
Configuring the Endpoint Compliance Policy Figure 7-9 Example Output of ICSinfo
Configuring the Endpoint Compliance Policy

To create Endpoint Compliance policies, you define rules, and then assign the rules to a policy. There are different types of rules for different security applications. The Endpoint Compliance policy configuration tool comes with a number of predefined rules which can be edited to match the needs of the organization. To configure the Endpoint Compliance policy, proceed as follows: 1. From the SmartDashboard Connectra tab navigation tree, select Endpoint Security On Demand > Endpoint Compliance. The Endpoint Compliance page appears. 2. Click Edit policies.
Chapter 7
Configuring the Endpoint Compliance Policy
The Endpoint Compliance policy configuration tool opens at the Policies page.
3. Either create a new Endpoint Compliance policy or edit an existing policy. To create an Endpoint Compliance policy click New Policy. The Policies > New Policy page opens. To edit an existing policy, select the policy and click Edit. The Policies > Edit Policy page opens. 4. Give the policy a Name, and a Description. The description can be long and detailed. 5. This step applies only to Endpoint Compliance policies that include Spyware Scan rules (Note that a Spyware Scan rule is different from an Anti-Spyware rule): If an endpoint machine has a valid anti-spyware of anti-virus application, you may consider they do not need to undergo an Endpoint Security On Demand Spyware Scan. If that is the case, select Bypass malware scan if endpoint meets Anti-Virus or Anti-Spyware requirements.
Note - This option is grayed out if there is no Spyware Scan rule in the policy.
6. Either add previously defined Endpoint Compliance rules, or create new rules or edit previously defined rules. There are different types of rules for different security applications. It is possible to have multiple rules of the same type, each with different settings. See Endpoint Compliance Policy Rule Types on page 181.
198
Configuring Endpoint Compliance
To add a previously defined rule, click Add. The Add Enforcement Rules page opens. Select a rule and click OK.
To create a rule, click New Rule, and select the rule type To edit a previously defined rule, select the rule and click Edit.
7. Define the rules.

Note - For explanations of the meanings of particular fields in the Endpoint Compliance rule configuration windows, see the online help.
8. Click OK. This takes you back to the Edit Policy or the New Policy page. 9. Click OK. This takes you back to the Policies page. 10. Click OK. This completes the configuration of the Endpoint Compliance Policies, and takes you back to the Endpoint Security On Demand > Endpoint Compliance page. After the Endpoint Compliance policies are configured, Endpoint Compliance can be configured to make use of the polices.

The Endpoint Compliance scanner performs a scan on the endpoint computer when the user connects to a Connectra portal. Connectra enforce the Endpoint Compliance policy, and allows access to the Connectra portal applications according to the Endpoint Compliance policy. To configure Endpoint Compliance, proceed as follows: 1. On the Connectra tab of SmartDashboard, select Endpoint Security On Demand > Endpoint Compliance from the navigation tree. The Endpoint Compliance page appears.
In This Section
Configure the Endpoint Compliance Policy or Policies Enable the Endpoint Compliance Scan page 200 page 200
Basic Approach: Configuring a Common Policy for the Portal and all Applications page 201 Advanced Approach: Configuring a Threshold Policy for the Portal, Hardened for Specific Applications page 201
Chapter 7 Endpoint Security On Demand 199
Very Advanced Approach: Configuring Individual Policies for Each Application page 202 Configuring Endpoint Compliance Logs Configuring Advanced Endpoint Compliance Settings Completing the Endpoint Compliance Configuration Excluding a Spyware Signature from a Scan Preventing an Endpoint Compliance Scan Upon Every Login page 204 page 205 page 205 page 206 page 208
Configure the Endpoint Compliance Policy or Policies

To configure the Endpoint Compliance policy or policies, click Edit Policies. For details, see Configuring the Endpoint Compliance Policy on page 197.
Enable the Endpoint Compliance Scan

For locally managed Connectra, continue with step 2. 1. In the Endpoint Security Settings on Connectra Gateways section, select a Connectra gateway and click Edit. The Endpoint Compliance page of the Connectra Properties window opens.
2. Enable Scan endpoint machine when user connects. 3. Choose one of the following approaches: Basic Approach: Configuring a Common Policy for the Portal and all Applications. Advanced Approach: Configuring a Threshold Policy for the Portal, Hardened for Specific Applications Very Advanced Approach: Configuring Individual Policies for Each Application.
200
Basic Approach: Configuring a Common Policy for the Portal and all Applications
To make access to the portal and all applications conditional on passing an Endpoint Compliance scan, assign a policy to the gateway: 1. Enable the Threshold policy: to access any application via this gateway, the endpoint must comply with the following policy option. 2. From the drop-down list, select the Endpoint Compliance policy to be used for all applications accessed via this gateway. 3. Click OK. 4. This takes you back to the Endpoint compliance page. 5. Maintain all applications with their default Endpoint compliance settings. In the Additional Settings > Protection Level page of the application, ensure This application relies on the security requirements of the gateway is selected. 6. Continue with Configuring Endpoint Compliance Logs on page 204.
Advanced Approach: Configuring a Threshold Policy for the Portal, Hardened for Specific Applications
To configuring a threshold Endpoint Compliance policy for the portal, hardened for specific Connectra applications, define a policy for the gateway. Then, for application that require hardened endpoint security, assign a Protection Level to the application. 1. In the Endpoint Compliance page of the gateway, Enable the Threshold policy: to access any application via this gateway, the endpoint must comply with the following policy option. 2. From the drop-down list, select the default Endpoint Compliance policy to be used for applications accessed via this gateway. 3. Centrally managed Connectra only: Click OK.
Chapter 7
4. In the Connectra tab Endpoint Compliance page, select the application that requires hardened endpoint security.
5. Click Edit. The Connectra application opens at the Additional Settings > Protection Level page. (Connectra applications are defined in the Applications section of the Connectra tab.)
6. Select the second option (This application has additional...). 7. From the drop-down list, select a Protection Level for this application. To define a new Protection Level, click Manage. For details, see Defining Protection Levels on page 46. 8. Click OK. 9. Continue with Configuring Endpoint Compliance Logs on page 204.
Very Advanced Approach: Configuring Individual Policies for Each Application

It is possible to configure an individual policy for each application. In this scenario, there are no gateway security requirements: All users are able to access the portal. However, when clicking a link to an application, users are only allowed access if they fulfill the requirements for that application. If no requirements are configured for the application, users are allowed to access it.
202
To configure an individual policy for each application: 1. In the Endpoint Compliance page of the gateway, enable the No threshold option. 2. Centrally managed Connectra only: Click OK. 3. In the Connectra tab Endpoint Compliance page, select the application that requires hardened endpoint security.
4. Click Edit. The Connectra application opens at the Additional Settings > Protection Level page. (Connectra applications are defined in the Applications section of the Connectra tab.)
5. Select the second option (This application has additional...), and from the drop-down list, select a Protection Level with the required Endpoint compliance policy for this application. To define a new Protection Level, click Manage. For details, see Defining Protection Levels on page 46.
Note - If This application relies on the security requirements of the gateway is selected for the Connectra application, users are allowed to access the application without any Endpoint Compliance requirements.
Chapter 7
6. Repeat steps step 3 to step 5 for all Connectra applications that requires hardened endpoint security. 7. Click OK.
Configuring Endpoint Compliance Logs

Connectra generates Endpoint Compliance-specific logs. The logs can be viewed using SmartView Tracker, and have the category Endpoint Security On Demand (abbreviated in the log entry as ESOD). The Endpoint Security On Demand information can be found on the "info" field of the logs. For more information, see Endpoint Compliance Logs on page 192. To configure tracking options for the Endpoint Compliance scanner: 1. In the Connectra tab of SmartDashboard, select Endpoint Security On Demand > Endpoint Compliance from the navigation tree. In the Endpoint Compliance page, in the Tracking section, enable Log the endpoint scan results to record the results of Endpoint Compliance scans to the log. Select Details or Summary to determine the level of detail to record in the log file.
The Tracking options are as follows: Summary: only one log entry per scan is written to SmartView Tracker. The log entry shows endpoints that do not comply with the Endpoint Compliance policy. The date and time of the scan, the source IP, and the Endpoint Compliance scan ID are logged. Details: In addition to the Summary mode information, this adds a log entry for each non-compliant rule. For example, in the case of a Spyware Scan rule that screens for tracking cookies, a log entry is generated that contains the following fields: a. Malware name: unwantedexample. b. Malware type: 3rd party cookie. c. Description: symptom type: URL. Symptom value: cookie:bob@unwantedexample.net.
204
Configuring Advanced Endpoint Compliance Settings

In the Endpoint Security On Demand > Endpoint Compliance page, click Edit.... The Advanced Endpoint Compliance Settings window opens.
In this window you can decide whether or not to allow access to the gateway and applications if the Endpoint Compliance scanner is not supported on the endpoint operating system. The supported operating system of the Endpoint Compliance scanner are: Windows, Mac, and Linux. For details, see the operating system compatibility table in the Connectra release notes. To configure advanced operating system-specific settings, see SecureKnowledge solution sk34989.
Completing the Endpoint Compliance Configuration

1. After completing the Endpoint Compliance configuration, take an overall view of the configuration by looking at the Endpoint Security On Demand > Endpoint Compliance page of the Connectra tab. Figure 7-10 on page 206 shows (for Centrally managed Connectra): One Connectra gateway that is configured to scan endpoint machines, with a high security policy required on the gateway. Six Connectra applications, two of which have a Partial Level of Enforcement (require High security Endpoint Compliance policy on the gateway). Two of the applications have a Full Level of Enforcement (also require compliance with an High security endpoint compliance policy when accessing the application).
2. Save and install the policy.
Chapter 7
Configuring Endpoint Compliance Figure 7-10 Endpoint Compliance Configuration Summary (Centrally Managed Connectra)
Excluding a Spyware Signature from a Scan

It is possible to exclude a specific spyware from a scan so that its presence on an endpoint computer does not cause the computer to fail the scan. Obtain the name of the spyware signature from a scan report and then modify the Endpoint Compliance policy to exclude that signature. To exclude a spyware signature from a scan: 1. Configure Connectra so that endpoint computers must undergo an Endpoint compliance scan before they connect. The Endpoint Compliance policy must include a Spyware Scan rule. 2. Set up a stand-alone test computer that has the spyware to be excluded from the scan. 3. Run an Endpoint compliance scan on the test computer by connecting from it to Connectra.
206
When Endpoint Security On Demand detects the spyware (irrespective of the action configured in the Spyware Scan rule), the name of the spyware (something like Win32.megaspy.passwordthief) is included in the report. 4. Make a note of the name of the spyware. 5. Open SmartDashboard. 6. In the Connectra tab, select Endpoint Security On Demand > Endpoint Compliance. 7. Click Edit Policies. 8. Select the policy that is applicable to the clients, and click Edit. 9. Select the Spyware Scan rule from the list and click Edit.
10. In the Software exception list section, click Add.
Chapter 7
Endpoint Compliance Scanner End-User Workflow
11. Type the Name of the spyware obtained in step 3, and a Description.
12. Click OK three times to close the Endpoint Compliance policy editor. 13. Install the policy (Policy > Install).
Preventing an Endpoint Compliance Scan Upon Every Login

By default, the end user computer is scanned by the Endpoint Compliance scanner every time the user logs in. This is the default, and most secure configuration. It is possible to configure Connectra so that after logging in, the user is not scanned, even after logging in again, until the end of a timeout period. For configuration details, see SecureKnowledge solution sk34844.

In This Section:
Configuring Internet Explorer for the Endpoint Compliance Scanner page 209 Endpoint Compliance Scanner End-User Experience Using Endpoint Security On Demand with Unsupported Browsers page 210 page 213
208
Configuring Internet Explorer for the Endpoint Compliance Scanner

The on endpoint computers is supported on browsers that run ActiveX (for Windows with Internet Explorer), or Java. When using the Endpoint Compliance scanner with Internet Explorer, the browser must be configured to download and run ActiveX controls and to allow Active Scripting. This section explains how to configure Internet Explorer to ensure that the Endpoint Compliance scanner will install and run properly on the endpoint computer. To configure Internet Explorer for the Endpoint Compliance scanner, perform the following steps: 1. Select Tools > Internet Options from the Internet Explorer menu. 2. Select the Security tab.
3. Select the Web content zone used by the endpoint computer for remote connections from the Security Settings window. 4. Click Custom Level. 5. Enable the following options in the Security Settings window and then click OK: Download signed ActiveX controls Run ActiveX controls and plug-ins
Chapter 7 Endpoint Security On Demand 209
Script ActiveX controls marked as safe for scripting Active scripting
6. Select the Privacy tab. Select the Medium setting and then click Advanced. 7. Enable Override automatic cookie handling and then enable Accept in the 1st party cookies section. 8. Click OK.
Endpoint Compliance Scanner End-User Experience

When a user connects to a portal where the Endpoint Compliance is enabled, the end user computer is scanned before the user sees the login screen.
Note - The Endpoint Compliance scan takes place if Endpoint compliance is configured for any Connectra application in a portal, even if accessing the portal itself does not require compliance with any policy.
The Endpoint Compliance Scanner is installed on the endpoint machine, by using ActiveX (for Windows with Internet Explorer), or Java. For more details see First time Installation of ActiveX and Java Components on page 39. To logon to the Connectra Portal with the Endpoint Compliance scanner enabled, perform the following steps: 1. Enter the Connectra Portal URL in your browser. 2. If using the Endpoint Compliance scanner for the first time on a particular endpoint computer, you are prompted to download and install the Check Point Deployment Agent ActiveX or Java control.
210
3. Some warnings may appear, regarding the Connectra site server certificate, and the downloaded applet. 4. During the scan, a progress bar is displayed.
5. If the endpoint computer successfully passes the Endpoint compliance scan, the Connectra Portal login screen appears.
Chapter 7
If the endpoint computer fails to pass the scan, Endpoint Security On Demand displays a result screen showing the potentially harmful software and security rule violations detected during the scan.
Click on a potentially harmful software item to display a short description of the detected malware, what it does and recommended removal method(s). If the Continue Anyway button appears, you can continue and log on to the Connectra Portal without removing the malware or correcting the security rule violation. If there is no Continue Anyway button, you must remove the detected malware or correct the security rule violation before you can log on to the Connectra Portal. When you have corrected the problem, click Scan again to repeat the scan.
6. When the Connectra Portal login page appears, you can log on normally.
Note - The scan results are presented to the user, and to the administrator as log entries in the Traffic Log. Each log entry lists the username, his/her user group, the source computer, malware name, malware type and malware description.
212
Using Endpoint Security On Demand with Unsupported Browsers

Endpoint Security On Demand for Connectra requires browsers that support ActiveX or Java. The following sections describe Endpoint Security On Demand behavior when users attempt to access the Connectra Portal using an unsupported browser. If the Block access to all applications option on the Endpoint compliance scan Policy page is enabled and either of the following conditions exist, the endpoint computer cannot connect to the Connectra Portal. The Prevent Connectivity option is enabled for at least one malware protection rule. The Restrict action is selected for at least one enforcement rule (antivirus or custom). In this case, Endpoint Security On Demand presents an error message and generates a log entry in the administrators traffic log. In all other cases, users can log on to the Connectra Portal without passing an Endpoint compliance scan. In some cases an incompatibility message appears with a Continue button that allows users to proceed with Connectra login. Endpoint Security On Demand generates a log entry in the administrators traffic log. When an applications Protection Level is configured to require an Endpoint Compliance scan, users can still gain access to the Connectra Portal, but cannot run that application.
Chapter 7
Preventing Portal Access with Unsupported Browsers

The following steps can be used to prevent users from gaining access to the Connectra Portal and applications without passing an Endpoint Compliance scan by using unsupported browsers: Enable the Scan endpoint machine when user connects option, and set a threshold policy. This setting may be found on the Endpoint Security On Demand > Endpoint compliance page. Assign Protection Levels that require passing an Endpoint Compliance scan to all applications. Prevent users from using an unsupported browser to access the Connectra portal by forcing Endpoint Security On Demand to reject all connections from unsupported browsers. Do this by manually editing a Connectra configuration file as follows: On the Connectra gateway, in the $CVPNDIR/conf/cvpnd.C file, set the useMagicBrowser parameter to false.
214
Secure Workspace
Secure Workspace
In This Section
Introduction to Secure Workspace Enabling Secure Workspace Applications Permitted by Secure Workspace SSL Network Extender in Secure Workspace Secure Workspace Policy Overview Configuring the Secure Workspace Policy Secure Workspace End-User Experience page 215 page 216 page 217 page 219 page 219 page 221 page 226
Introduction to Secure Workspace

Secure workspace is a security solution that allows remote users to connect to enterprise network resources safely and securely. The Secure Workspace virtual workspace provides a secure environment on endpoint computers that is segregated from the real workspace. No data is allowed to leave this secure environment except through the Connectra portal. Also, Secure Workspace users cannot access any applications, files, system tools, or other resources from the virtual workspace unless they are explicitly permitted by the Secure Workspace policy. Administrators can easily configure Secure Workspace policy to allow or prevent activity according to enterprise requirements. Secure Workspace creates an encrypted folder called My Secured Documents on the virtual desktop that contains temporary files, cookies, registry changes, browser credentials, and so on. It deletes this folder and all other session data when the session terminates. Secure Workspace severely restricts users ability to write to real workspace folders. However, in order to allow certain applications to run properly, Secure Workspace policy may be configured to permit write access to specific files and folders in the real workspace. After enabling Secure Workspace, administrators can configure a Connectra gateway to either require all users to connect to the Connectra portal via Secure Workspace, or to give users the option of connecting via Secure Workspace or from their endpoint computers.
Chapter 7
Enabling Secure Workspace
Enabling Secure Workspace

To enable Secure Workspace for a Connectra gateway, perform the following steps: 1. On the SmartDashboard Connectra tab, select Endpoint Security On Demand > Secure Workspace. 2. Configure the Secure Workspace policy. Click Edit policy. For details, see Configuring the Secure Workspace Policy on page 221. 3. Centrally managed Connectra only: select the Connectra gateway and click Edit. The Secure Workspace page of the Connectra gateway opens. 4. Select This gateway supports access to applications from within the Secure Workspace.
5. Select either of the following options: Allow user to choose whether to use Secure Workspace Users must use Secure Workspace
6. Install the policy.
Configuring Advanced Secure Workspace Settings

In the Endpoint Security On Demand > Secure Workspace page, click Edit....
216
Applications Permitted by Secure Workspace
The Advanced Secure Workspace Settings window opens.
In this window you can decide whether or not to allow access to the gateway and applications if Secure Workspace is not supported on the endpoint operating system. The supported operating system for Secure workspace is Windows. For details, see the operating system compatibility table in the Connectra release notes. To configure advanced operating system-specific settings, see SecureKnowledge solution SK34989.
Applications Permitted by Secure Workspace

In its default configuration, Secure Workspace allows access to a limited group of applications. This is likely to be sufficient for most end-users working with the Connectra Portal and retrieving information from network hosts. The following table lists the latest version of applications that Secure Workspace permits by default.
Chapter 7
Applications Permitted by Secure Workspace Table 7-2 Applications Permitted by Secure Workspace by Default
Process Name Application DW20.EXE, dwwin.exe Dr. Watson igfxsrvc.exe iedw.exe unsecapp.exe ieuser.exe ieinstal.exe conime.exe runner.exe sndvol.exe SearchIndexer.exe Acrobat.exe acrodist.exe acrotray.exe telnet.exe hypertrm.exe Putty.exe SecureCRT.exe ptw32.exe pcsfe.exe ftp.exe internat.exe Mstsc.exe Vncviewer.exe radmin.exe WISPTIS.EXE MSOHELP.EXE MSTORDB.EXE Intel video card driver process Internet Explorer Microsoft Windows process Internet Explorer Internet Explorer Microsoft Console IME (Input Method Editor) CShell ActiveX component Microsoft Windows Volume Control Content indexing service Adobe Acrobat Writer Adobe Acrobat Distiller Acrobat Traybar Assistant Microsoft Telnet Client Microsoft HyperTerminal Putty SecureCRT TN3270 Telnet Client TN3270 Telnet Client Microsoft FTP Client Predefined Application Microsoft Remote Desktop VNC Viewer RAdmin Predefined Application Predefined Application Predefined Application Description A process offers support proper application crash handling. A process offers support video card functional. Microsoft Internet Explorer web browser A process offers support towards compatibility issues. Microsoft Internet Explorer web browser Microsoft Internet Explorer web browser A process is used when the locale of the computer is set to a non-western language. A CShell process required on Windows Vista. A process associated with the Microsoft Windows OS. A Windows Vista service to index modified content. A process is used to create and print PDF documents. A process is used to create and print PDF documents. A process provides a shortcut to additional configuration options for Adobe products and is used to create PDF documents. A terminal emulation program for TCP/IP networks. A Windows utility that offers Telnet facilities. Free implementation of Telnet and SSH client. Telnet and SSH client implementation from VanDyke Software, Inc. TN3270 telnet client. IBM Personal Communications Session Manager. A TN3270 telnet client. Microsoft FTP Utility process that provides basic FTP access. Windows process that provides multi-lingual features in Microsoft Windows. This program is important for the stable and secure running of the computer and should not be terminated. Allows initiation of terminal services commands via command line. Remote administration tool process from TWD Industries. Remote Administrator Server from Famatech Corp. Process is installed alongside Microsoft office or comes packaged with Windows update. This process handles Windows Ink Services and often runs with Adobe Acrobat Reader. Microsoft Office 2003 suite process. Microsoft Office 2003 suite process. Microsoft Windows Image Mastering API process, used for CD recording. This program is important for the stable and secure running of endpoint computers and should not be terminated. Microsoft Office Picture Manager process. Check Point Secure Workspace executable. This executable should be allowed in order to enable Secure Workspace to start. Microsoft Windows OS process that offers additional functions to the Local Area Network. Microsoft Windows OS process that offers additional functions to the Local Area Network. Generic Host Process for Win32 Services, an integral part of Microsoft Windows OS. It manages 32-bit DLLs and other services and cannot be stopped or restarted manually. Process that executes DLLs and places their libraries into memory. This program is important for the stable and secure running of the computer. Windows Installer Component process. This program is important for the stable and secure running of the computer. Microsoft Windows OS process that verifies a COM object before the COM object is instantiated by Windows Explorer. Adobe Acrobat Reader process. This process starts automatically when opening a PDF file and collects information about this file. Microsoft Office InfoPath process used by Microsoft Office to open and edit XML files. Sun Microsystems Java Runtime component Sun Microsystems Java Runtime component Microsoft Java Virtual Machine Command Line Interpreter Microsoft Java Virtual Machine Command Line Interpreter Microsoft Windows OS process. Process is initiated when launching online Help in Windows 2000 or later versions. Windows Media Player component. A process associated with the Microsoft Windows OS. Microsoft Windows Volume Control. A process associated with the Microsoft Windows OS. Check Point SNX Application Mode component. Microsoft Office Suite process that activates the Alternative User Input Text Input Processor (TIP) and the Microsoft Office XP Language Bar. Microsoft Synchronization Manager. Process associated with Internet Explorer. Microsoft Windows OS process that allows display or modification of the network configuration of a computer that is currently running. Microsoft Notepad Microsoft Calculator Microsoft Wordpad Microsoft Paint Microsoft MS Office Word
imapi.exe OIS.EXE CPSWS.exe net.exe net1.exe svchost.exe rundll32.exe msiexec.exe verclsid.exe AcroRd32Info.exe MSOXMLED.exe java.exe javaw.exe jview.exe wjview.exe helpctr.exe unregmp2.exe sndvol32.exe STAProxy.exe ctfmon.exe mobsync.exe netsh.exe notepad.exe calc.exe wordpad.exe mspaint.exe winword.exe
Predefined Application Predefined Application Check Point Secure Workspace Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Predefined Application Microsoft Notepad Microsoft Calculator Microsoft Wordpad Microsoft Paint Microsoft Word
218
SSL Network Extender in Secure Workspace
SSL Network Extender in Secure Workspace

When using SSL Network Extender inside Secure Workspace, traffic from outside the Secure Workspace is encrypted, as well as Secure Workspace traffic.
Secure Workspace Policy Overview

Secure Workspace governs access to applications and directories on endpoint computers according to a Secure Workspace policy. Each Connectra gateway has its own, individual Secure Workspace policy. The policy: Grants or denies permission for users to run applications. Allows applications to save files to specific files and directories Defines general portal protection security settings and user experience behavior.
Administrators can add to the list of Approved Applications, and can add to, edit or delete applications from the list. For some applications, you may also need to define locations where the application is allowed to save files that remain after Secure Workspace shuts down. These locations are called Allowed Save locations. There is no need to define locations for files that are not needed after Secure Workspace shuts down. Temporary files are deleted when the Secure Workspace is closed. Secure Workspace includes a built-in FireWall that allows you define Outbound FireWall Rules. These are the IP addresses and ports that approved applications are allowed to access. By default, desktop applications are allowed access to all addresses and ports. Note that settings for the approved applications, save locations and outbound fireWall rules independent. For example, the save locations are nor restricted to a particular application, and similarly, outbound firewall rules apply to all applications.
Integration with Check Point Program Advisor

Secure Workspace can be configured to work together with a Check Point Program Advisor server to check whether an application that is not an approved application is legitimate. Program Advisor identifies programs according to their filename and MD5 hash.
Chapter 7
Secure Workspace Policy Overview
For details of Program Advisor, see the Endpoint Security Administrator Guide, available from http://support.checkpoint.com. If the Program Advisor is used, the sequence of Secure Workspace checks is as follows: 1. User selects a program to run in Secure Workspace. 2. Secure Workspace checks the policy. If the program is not allowed by the Secure Workspace policy, program execution is blocked. 3. If the program is allowed by the policy, Secure Workspace queries the Program Advisor server about the program. 4. Program Advisor returns one of three responses about the application: Trusted, Untrusted, or Unknown. 5. Secure Workspace allows or blocks the application according to the Program Advisor responses, in one the following ways, as defined in the policy: Allow Trusted only. Allow Trusted and Unknown.
220
Configuring the Secure Workspace Policy

In This Section
Opening the Secure Workspace Policy Editor Portal Protection Settings User Experience Settings Configuring Approved Applications Configuring Allowed Save Locations Configuring Outbound FireWall Rules Configuring a Secure Workspace Policy per Gateway Configuring a Secure Workspace Policy per Gateway page 221 page 222 page 223 page 223 page 224 page 224 page 225 page 225
Opening the Secure Workspace Policy Editor

To configure the Secure Workspace Policy: 1. On the SmartDashboard Connectra tab, select Endpoint Security On Demand > Secure Workspace. 2. Configure the Secure Workspace policy. Click Edit policy.
Chapter 7
The Secure Workspace Settings window opens.
Portal Protection Settings

Prevent endpoint from printing secure documents prevents any documents in the Secure Workspace being printed Secure clipboard contents prevents any item copied from inside Secure Workspace being pasted or saved outside Secure Workspace Enable Program Advisor to validate the integrity of approved applications. When a user starts an application that is not an Approved Application, Secure Workspace contacts a Check Point Program Advisor server and checks whether the application is legitimate. The server returns one of three responses: The application is trusted; The application is untrusted, or the application is unknown. Configure the Secure Workspace policy to handle Program Advisor responses in one the following ways: Allow Trusted only Allow Trusted and Unknown
222
User Experience Settings

Prevent endpoint from switching between Secure Workspace and regular desktop prevents the user from switching back and forth between these environments. Access to the regular desktop is only allowed if Secure Workspace is closed. Enable welcome window prevents the window that says Welcome to Secure Workspace from appearing on the endpoint machine.
Configuring Approved Applications

Approved applications are available from Secure Workspace, and are allowed to run on endpoint computers. You can add, edit or remove applications from the list. Application Name is the name of the approved application. File Name is the path and filename corresponding to the application selected. If needed, specify more than one location per application. You can specify it using one of the following formats: Absolute path in the following format: <disk>:\<folder_path>\<binary_name>. Secure Workspace allows the endpoint to run the binary from specified location only. The full path is needed if the location of the program does not appear in the PATH. File name, for example: \<binary_name>. Secure Workspace allows the endpoint to run the binary with the specified name from any location on the disk. Use if the location appears in the PATH. Path with environment variable, for example: <path_with_env_variable(s)>\<binary_name>. Secure Workspace resolves the environment variable on endpoint, and uses its value as part of the path to executable.
Chapter 7
Add Application
Add shortcut to the Start Menu adds a shortcut to the application to the Start Menu in the Secure Workspace. The shortcut is only added if the application exists on the client computer. MD5 hash is the signature of the application. It is possible to add several hashes, for example: one for each version of the application. The ICSinfo tool (see Using the ICSInfo Tool on page 196) can be used to calculate the hash function of an application. Alternatively, MD5 calculators are freely available on the Internet.
Note - Check point Program Advisor is a more maintainable and reliable way of checking the security and integrity of programs than manually adding MD5 hashes.
Configuring Allowed Save Locations

Allowed Save locations are locations where the application is allowed to save files that remain after Secure Workspace shuts down. There is no need to define locations for temporary files that can be deleted after Secure Workspace shuts down. Save locations for the default approved applications are predefined. A good way of finding out the required save locations is to note the locations specified when installing an application. If after defining an application you are unable to use it, examine Secure Workspace log, which records attempts to save files or access locations that are not allowed.
Configuring Outbound FireWall Rules

Outbound FireWall Rules are IP addresses and ports that approved applications are allowed to access when they make outbound connections. A default rule allows desktop applications to access to all addresses and ports. The default rule can be deleted and replaced with more restricted rules. However, configure the rules carefully. At a minimum, define a rule that allows loopback traffic to 127.0.0.1. Also, take into account all ports required by the allowed protocols.
224
Configuring a Secure Workspace Policy per Gateway

Note - Applies to centrally managed Connectra only.
The Secure Workspace policy that is configured in SmartDashboard is applicable for all Connectra gateways. To configure a Secure workspace policy that is applicable per gateway, see SecureKnowledge solution sk34939.
Testing the Secure Workspace Policy

SecureKnowledge solution sk31592 explains how to test a new Secure Workspace policy on a standalone computer, without using Connectra.
Chapter 7
Secure Workspace End-User Experience

In This Section
Logging on to the Connectra Portal using Secure Workspace Working with the Secure Workspace Virtual Desktop Accessing Endpoint Applications in Secure Workspace Switching Between Secure Workspace and the Real Desktop Exiting Secure Workspace This section provides an overview of the Secure Workspace workflow. page 226 page 227 page 229 page 230 page 230
Logging on to the Connectra Portal using Secure Workspace

Secure Workspace initializes when a user logs on to the Connectra Portal. If the administrator has configured the Connectra gateway to require Secure Workspace, this occurs automatically. If the administrator has configured the gateway to allow users to choose whether or not to use Endpoint Security On Demand, an option appears on the Logon screen. To log on using Secure Workspace, 1. Enter the Connectra Portal URL in your browser. If the Use Check Point Secure Workspace option appears on to logon screen, enable it and log on normally.
226
2. Secure Workspace is installed on the endpoint machine by using ActiveX (for Windows with Internet Explorer), or Java. For more details see First time Installation of ActiveX and Java Components on page 39.
.
3. The Connectra Portal appears in a browser window on the secure desktop.
Working with the Secure Workspace Virtual Desktop

The Secure Workspace virtual desktop looks and feels like a normal Windows desktop.
Chapter 7
The principal difference is that Secure Workspace only allows users to work with a limited number of pre-approved applications and files and, by default, does not allow users to print, customize the desktop or perform any system configuration activities. Since most users only use Secure Workspace to work with the Connectra Portal, these functions are rarely needed.
Start Menu and Taskbar

The virtual desktop Start menu and taskbar function in the same manner their real counterparts do. Configuration settings in the Secure Workspace policy determine which shortcuts and options are available to users.
Allowing Users to Save Files to the Real Desktop

Users occasionally need to download and save files from resources behind the Connectra gateway to real desktop folders. Conversely remote users may need to upload files to the corporate network from the endpoint computer. To allow this, this, the administrator must configure the Secure Workspace policy to allow endpoints to switch between the secure and regular desktops. This is accomplished in the User Experience Settings section of the Secure Workspace policy editor.
Accessing Files and Applications on the Endpoint Computer

Generally, users can access files and run applications in Secure Workspace in the same manner as on the real desktop. Since, by default, users have read-only (access) privileges to all folders and files, they can freely navigate the file system using Windows Explorer. When attempting to run a program or open a file for which a user does not have Secure Workspace permission, an error message similar to the following appears.
228
Likewise, if a users attempts to save a file to a real desktop folder without Secure Workspace permissions, an error message appears.
Running Secured Programs

Secured programs (those with execute privileges) run normally. Administrators can configure the Secure Workspace policy to include such programs in the Secured Programs entry on the Start menu. Secured programs display the Secure Workspace icon in the upper right-hand corner of the application window title bar.
Accessing Endpoint Applications in Secure Workspace

When SSL Network Extender network mode users initiate an Secure Workspace session, permitted Endpoint Applications are available in the virtual desktop as follows: An Endpoint Application defined in the Native Application as... Path and executable name (already installed) Runs via default browser Downloaded-from-Connectra application ... is available to Users as a Shortcut in the Windows Start > Program menu. Shortcut on the desktop. Link in the Connectra Portal.
Note - During an Secure Workspace session, SSL Network Extender cannot toggle between the Network Mode and the Application Mode. User can change the mode, but must start a new Secure Workspace session after doing so.
Chapter 7
Switching Between Secure Workspace and the Real Desktop

You can switch back and forth between the Secure Workspace virtual workspace icon, located in the tray and the real desktop at any time. To do so, click the area of the taskbar.
Exiting Secure Workspace

To exit Secure Workspace, from the Windows Start menu, select Close Secure Workspace.
A confirmation and reminder to save open files appears. Click Yes, close it now to continue closing Secure Workspace.
230
Endpoint Compliance Updates
Endpoint Compliance Updates

Check Point provides Endpoint Compliance updates. You can download Endpoint Security On Demand updates from the Connectra tab in SmartDashboard. You can configure Endpoint Security On Demand to retrieve updates automatically according to a defined schedule or you can manually download and install the updates.
Working with Automatic Updates

You can periodically check for and automatically download Endpoint Compliance updates. You can choose to download updates from the Check Point Download Center or you can install updates previously downloaded to your SmartCenter server or locally managed Connectra gateway.
Note - Before performing an Endpoint Security On Demand update, install a policy at least once.
To configure automatic updates: 1. On the SmartDashboard Connectra tab, select Endpoint Security On Demand > Endpoint Compliance Updates from the navigation tree. 2. Select Enable Automatic Updates. 3. In the Update Configuration section, click Configure. The Automatic Updates window opens.
4. On the User Center Credentials tab, enter your User Center email address and password.
Chapter 7
Working with Automatic Updates
5. In the Endpoint Security On Demand tab, do the following:
a. To install updates from the Download Center, select the Check Point web site option. b. To install updates from your SmartCenter server, select the My local SmartCenter server option. If you wish to install updates from Download Center when the SmartCenter server is unavailable, enable the indicated option. c. Select the interval, in minutes, after which Endpoint Security On Demand checks for available downloads. 6. In the Tracking Configuration tab, select the various tracking options from the lists. You can select logging events or a variety of alert types.
232
Performing Manual Updates
7. If there is a proxy server between the SmartCenter and the User Center, select the Proxy tab, and enter the proxy host name or IP address, and the proxy port number (for example: 8080).
8. Click OK to complete the definition. 9. Install the policy on the Connectra gateways.

To perform a manual Endpoint Security On Demand update, perform the following steps: 1. In the SmartDashboard Connectra tab, select Endpoint Security On Demand from the navigation tree. 2. Click Update Databases Now. 3. Enter your Check Point User Center credentials and click Next. 4. Choose the All supporting gateways option to download to all available Connectra gateways. Alternatively, choose the Select option to select specific Connectra gateways for update, and then select the desired gateways in the left-hand list and then click Add. 5. Click Finish. A progress bar appears during the download. 6. Install policies to all affected gateways.
Chapter 7
234
Chapter Connectra Gateway Configuration

In This Chapter
Portal Settings Link Translation Connectra Server Certificates Session Settings Web Data compression Changing the IP Address of a Connectra Gateway or Cluster VPN Client and Portal Connectivity in a Single Gateway
page 236 page 239 page 247 page 254 page 262 page 260 page 261
235
Portal Settings
Portal Settings
In This Section
Portal Customization Alternative Portal Configuration page 236 page 238
Portal Customization
It is possible to configure the look and feel of the default Connectra end user portal. There is a default end user portal for each Connectra gateway or cluster. To customize the Connectra end user portal, proceed as follows: 1. In the SmartDashboard Connectra tab, select the Portal Settings > Portal Customization page. 2. Centrally managed Connectra only: Select a Connectra gateway or cluster object and click Edit. The Portal Customization page opens.
Title of the Portal

Title text (multi-language) of the end user portal, such as the name of your company, or any other text.
236
Portal Customization
Localization
Default language (can be changed by user) localizes the end user portal to the selected language.
Logo in the Portal

Use custom logo image and browse to a location where logos are stored. The maximum logo width is 300 pixels. Larger images are resized.
Note - If the custom logo is changed, end users must refresh their browser cache in order see the new logo image.
Clicking the logo redirects to this URL is a URL that can serve as a starting point. Often used for the URL of the organizations intranet home page.
Traffic to Portal
Service is the TCP port (or port range) on which Connectra listens for communication from clients. Machine's interfaces are the IP addresses of the interfaces on which Connectra listens for client connections to the Connectra portal.
Chapter 8
Connectra Gateway Configuration 237
Alternative Portal Configuration
Alternative Portal Configuration

It is possible to specify the portal that is presented to users when they sign in to Connectra. You can specify alternative portals for different user groups. Users that do not belong to any of these user groups reach the default Connectra portal. To specify an alternative user portal, proceed as follows: 1. In the SmartDashboard Connectra tab, select Portal Settings > Alternative Portal. 2. Click Add. The Connectra Sign-In Home Page window opens.
3. In the User Groups tab, specify user groups that may access the alternative user portal. 4. In the Install On tab, specify the Connectra gateways and gateway clusters that host the alternative portal. 5. In the Sign-In Home Page tab, choose an alternative portal for users, in place of the Connectra user portal that users reach by default. URL is the location of the alternative user portal for the user group(s) specified in the User Groups tab.
238
Link Translation
Link Translation
In This Section
Introduction to Hostname Translation Link Translation Per Gateway or Per Application How Hostname Translation Works Configuring Link Translation Portal Access with Hostname Translation Link Translation Issues page 239 page 240 page 240 page 242 page 245 page 246
Introduction to Hostname Translation

Link Translation is the process by which Connectra converts internal URLs to public URLs that are valid on the Internet, so that internal resources become accessible via any Internet-connected browser. Connectra supports two methods of Link Translation: URL translation and Hostname Translation. URL Translation works by default, out of the box, and can handle the large majority of Web sites. Hostname Translation provides dramatically improved performance for Connectra gateways and end users, resulting in faster Web access and fewer connectivity issues. Additionally, Hostname Translation allows Connectra to access a wider range of Web sites, due to enhanced support for HTML pages, JavaScript, VBscript, and Web applications (such as the SAP Portal).
Hostname Translation is an optional feature, which is disabled by default and requires additional (one time) configuration. For most Connectra deployments, Hostname Translation works well with its default configuration. In order to use Hostname Translation, it is necessary to add a record to your organizations DNS server. Additionally, defining a wildcard SSL certificate for the Connectra gateway is strongly recommended.
Chapter 8
Link Translation Per Gateway or Per Application
Link Translation Per Gateway or Per Application

For the majority of Web sites and Web applications, Hostname Translation is the preferred method of performing Link Translation. Many sites work better (or only) with Hostname Translation. However, a few sites may work better (or only) with URL Translation. Link Translation can be configured to accommodate the distinctive requirements of the application (that is, a Web application or a Citrix service) or the gateway through which the applications are accessed. It is possible, for example, to configure a particular Connectra application to work with URL translation, while all other applications supplied by the gateway use Hostname Translation. The workflow for configuring Link Translation is as follows 1. Configure the link translation methods that are supported by Connectra. URL translation is always supported by the gateway. Hostname Translation requires further configuration in order to be supported. 2. Configure the default link translation method used by Connectra. When Hostname Translation has been enabled on Connectra, the default link translation method used by Connectra applications can be chosen. Each Connectra application can be configured override the default translation method. 3. Configure the Links Translation method used by the application. This can be the method specified by the gateway through which the application is accessed. Alternatively, the application can be configured to always use a particular translation method.
How Hostname Translation Works

Connectra ensures secure VPN connectivity by converting HTTP requests into secure HTTPS requests and by changing the port to 443. To accomplish this, Connectra translates the source URL into an HTTPS URL that routes traffic to its destination via the Connectra gateway. The translated URL is returned to the browser and is visible to the user. Hostname Translation enhances security by replacing the destination host name with a seemingly random character string in the URL, as it appears in the client browser.
240
How Hostname Translation Works
How Translated URLs Appear in a Browser

The following example compares how a URL appears to users in their browser with Host Translation enabled and disabled. In this example, an HTTP request, sent via a Connectra gateway located at ssl.example.com to the destination URL http://www.example.com/path, appears as follows:
URL With Hostname Translation Enabled
https://c-ds1q-itfgppae7oq.ssl.example.com/path
Note that the seemingly random character string c-ds1q-itfgppae7oq represents the destination URL.
URL With Hostname Translation Disabled
https://ssl.example.com/Web/path,CVPNHost=www.example.com,CVPNProtoc ol=http
Wildcard SSL Certificates

Using wildcard SSL certificates with Hostname Translation eliminates certificate warnings generated when browsers attempt to access URLs pointing to different sub-domains behind a Connectra gateway. For example, If a Connectra gateway is located at ssl.example.com (the FQDN), you should purchase a certificate issued to *.ssl.example.com. This certificate covers the fully qualified sub-domains of the parent domain, such as a.ssl.example.com and b.ssl.example.com. When Connectra uses a fixed domain certificate, or a self-signed certificate, client browsers issue certificate warnings whenever they attempt to access Web applications in a sub-domain behind the Connectra gateway. This occurs because each Web applications URL is translated to a different Connectra host name.
Wildcard DNS Server Records

In order to use Hostname Translation, you must configure the DNS server to resolve Connectra sub-domains (such as *.ssl.example.com) to the Connectra IP address. For example, If a Connectra gateway is located at ssl.example.com (the FQDN), configure the DNS to resolve *.ssl.example.com. to the Connectra IP
Chapter 8
Configuring Link Translation
address. This wildcard includes all sub-domains of the parent domain, such as a.ssl.example.com and b.ssl.example.com. The parent domain ssl.example.com must also be defined as a separate DNS record.
Warning - If the DNS server is not configured to resolve wildcard Connectra host names, users will be unable to connect to Connectra, because the portal changes to a subdomain as well: portal.ssl.example.com.

In This Section
Preparing Connectra for Hostname Translation SmartDashboard Configuration of Link Translation page 242 page 243
Preparing Connectra for Hostname Translation

To prepare your Connectra gateway to use Hostname Translation, perform the following procedures: 1. 2. 3. Obtain and install a wildcard SSL certificate for the Connectra gateway (recommended). Add sub-domain records to the DNS server. Initialize Hostname Translation
The following sections describe these procedures.
Obtaining and installing a Wildcard SSL Certificate

It is strongly recommended that you obtain a wildcard SSL certificate (for example, *.ssl.example.com) from a trusted (well-known) certificate authority for the Connectra domain. A certificate for Connectra from a trusted CA allows users to log in to Connectra without receiving certificate warning popups. For instructions, see Obtaining and Installing a Trusted Server Certificate on page 247.
242
Adding Sub-Domain Records to the DNS Server

Configure the DNS Server used to resolve the Connectra host name to: Resolve all Connectra sub-domains to the Connectra IP Address (for example, *.ssl.example.com). Resolve the parent domain (such as ssl.example.com) to the same IP address. This allows users to browse directly to the Connectra portal by using its FQDN.
SmartDashboard Configuration of Link Translation

Link Translation can be configured to accommodate the distinctive requirements of the application (that is, a Web application or a Citrix service) or the gateway through which the applications are accessed. It is possible, for example, to configure a particular Connectra application to work with URL translation, while all other applications supplied by the gateway use Hostname Translation. To configure Link Translation: 1. Configure the supported link translation methods: a. In the Connectra tab, select Additional Settings > Link Translation. b. Central management only: Select a Connectra gateway and click Edit. The Link Translation page of the Connectra gateway opens. c. To enable support for Hostname Translation, select Hostname Translation. (URL Translation is always supported.)
Chapter 8
d. Create or select a DNS Name object that specifies the parent DNS names of the Connectra gateway. Do not include the wildcard prefix (i.e. "*.") in the DNS name. For example configure "ssl.example.com" as the DNS Name object. For further information, see DNS Names on page 85. 2. Configure the default link translation method used by Connectra: In the Translation method used by Connectra section, select the default link translation method for accessing Web applications. This method is used unless a different method is specified in the application itself. Select either URL translation or Hostname Translation.
3. Configure the Link Translation method used by the application: a. In the Link Translation Method Settings on Applications section, select an application and click Edit. The Link Translation page of the Connectra application opens.
b. Select the Translation methods. Either Use the method specified in the Connectra through which this application is accessed (as chosen in step 2), or Select the method that will always be used to access this application.
c. If necessary, click Advanced Hostname Translation Settings.
244
Portal Access with Hostname Translation
The Advanced Hostname Translation Settings window opens.
d. Select the appropriate Cookies Handling Mode: On the gateway is the default setting. All HTTP cookies that are sent to clients by internal Web servers are stored on Connectra, and are not passed on to the client's browser. On the endpoint machine can be used if the default setting causes the JavaScript (from the internal servers, that runs on the client browser) that handles HTTP cookies to fail. With this setting, Connectra passes HTTP cookies to the browser.
e. Click OK twice. 4. Examine the Link Translation configuration summary on the Link Translation page.
Portal Access with Hostname Translation

When Hostname Translation is enabled and configured, users access the Connectra Portal by entering the URL in their browser in any of the following formats. These examples assume that the Connectra FQDN is ssl.example.com.
http://ssl.example.com/ http://portal.ssl.example.com/ https://portal.ssl.example.com/ https://ssl.example.com/

Note - The last option results in a certificate warning stating that the certificate does not match the destination host. This is due to a limitation of the SSL Protocol.
Chapter 8
Link Translation Issues
Link Translation Issues

The following Link Translation configuration tips apply to Web applications. To allow Web sites that use ActiveX and streaming media to work with Hostname Translation, configure Connectra Web applications to Allow caching of all content. This is configured in the Endpoint Compliance page of the Web application Domain cookies created in JavaScript are not supported. For example, if you create a cookie with the following JavaScript code: document.cookie=Name=Value; domain=.example.com, the client browser cannot send the cookie to Connectra and the Web server if Connectra is not located under the domain .example.com. Note that domain cookies created in HTTP headers are supported, as long as they are not manipulated by JavaScript code. With Hostname Translation, the URL shown in the client browser is: https://<obscured destination hostame>.<Connectra FQDN>/path (For an explanation, see How Hostname Translation Works on page 240). The maximum number of characters in each part of the hostname (between https:// and the /path) is limited to 63 (see RFC 1034 - Domain names - concepts and facilities). Therefore, the entire internal hostname, including the protocol and the port, must not exceed 63 characters. Host names displayed in client browsers appear as a seemingly random character string, instead of the complete destination path. Signing out from Outlook Web Access, from Domino Web Access (iNotes), or from Microsoft SharePoint may disconnect the Connectra session as well.
246
Connectra Server Certificates
Connectra Server Certificates

In This Section
Overview of Server Certificates Obtaining and Installing a Trusted Server Certificate Connectra Self-Signed Certificates Viewing Connectra Certificate Details page 247 page 247 page 250 page 252
Overview of Server Certificates

Secure SSL communications requires that Connectra gateways establish trust with endpoint computers by presenting credentials in the form of a Server Certificate. This chapter discusses the process for installing and working with server certificates. Connectra, by default, uses a self-signed certificate as its server certificate. When an endpoint computer attempts to connect to the Connectra gateway presenting the default, self-signed certificate, certificate warning messages appears in the browser. In order to prevent these warnings, the administrator must install a server certificate signed by a trusted certificate authority.
Obtaining and Installing a Trusted Server Certificate

In order to be accepted by an endpoint computer without a warning, Connectra must present a server certificate signed by a known certificate authority (such as VeriSign or Thawte). This certificate can either be issued directly to the Connectra gateway, or be a chained certificate that has a certification path to a trusted root certificate authority (CA). To obtain a certificate for Connectra, signed by a known certificate authority (CA), perform the following steps:
Chapter 8
Generating the Certificate Signing Request

The first step is to generate a Certificate Signing Request (CSR) for the Connectra gateway. Note - The following procedure create private key files. If private key files with the same names (server1.csr and server1.key in the following example) already exist on the machine, they are overwritten without warning. 1. From the Connectra command line, run the following command in the expert mode: csr_gen <filename> This command creates the CSR and the private key. For example:
csr_gen server1
This creates the following output:

[Expert@cpmodule]# csr_gen server1 /opt/CPcvpn-R66/bin/csr_gen : Creating Key and Certificate Signing Request based on the following information : Key Size : rsa:1024 Number of days to certify the certificate for : 365 CSR output filename : server1.csr Private Key output filename : server1.key OpenSSL config file : /opt/CPcvpn-R66/conf/openssl.cnf
Do you want to continue (y/n)? [y] :
2. Click Enter to accept the default. The following message appears:

Do you want the private key file to be encrypted (recommended, but you'll need to remember the password till you install the signed certificate in Connectra) (y/n)? [y]:
3. Click Enter to encrypt the private key file (default). 4. The following output appears:
csr_gen : /opt/CPcvpn-R66/bin/csr_gen : Executing <openssl req -new -newkey rsa:1024 -out server1.csr -keyout server1.key -days 365 -config /opt/CPcvpn-R66/conf/openssl.cnf> Generating a 1024 bit RSA private key .....................................++++++ ............++++++ writing new private key to 'server1.key' Enter PEM pass phrase:
248
5. If you chose to encrypt the private key file in step 3, enter a password and confirm. You will see the following message:
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank.
6. Fill in the requested data according to the instructions presented. All fields are optional except, Common Name, which is required. This field must contain the Connectra Fully Qualified Domain Name (FQDN), which is the name that must be used by end-users to access Connectra on the Web. For example: sslvpn.example.com. 7. The following message appears:
csr_gen : Operation Succeeded Your Private Key File is : server1.key Your CSR File is : server1.csr
8. Send the CSR file to a trusted certificate authority, retaining the .key private key file. Be sure to request a Signed Certificate in PEM format.
Installing the Signed Certificate

1. Obtain the Signed Certificate for Connectra from the certificate authority.
Note - If the signed certificate is in the P12 or P7B format, you will need convert these files to PEM format. Refer to Converting a P12 or a P7B Certificate to PEM format page 250 for details.
2. Install the certificate using the *.crt certificate file together with the *.key key file that was generated by CSR_gen. a. If a previous signed certificate file exists, back up the following directory: $CVPNDIR/var/ssl. b. Execute the following command to install the signed certificate:
$CVPNDIR/bin/InstallCert <certfile> <keyfile> '<passwd>'

c. Execute the cvpnrestart command. In a cluster environment, perform the above commands for each cluster member. However, you need only back up previous files on one member.
Chapter 8
Connectra Self-Signed Certificates
Converting a P12 or a P7B Certificate to PEM format

Connectra portal server certificates must be in PEM format. If you have a P12 or P7B format certificate file, you must convert it to PEM format before you can install it on the Connectra gateway. Scripts for this purpose are deployed with Connectra.
To Convert a P12 File to PEM format

Execute the $CVPNDIR/bin/p12ToPem script. For detailed information, refer to SecureKnowledge solution sk30997.
To Convert a P7B File to PEM format

Execute the $CVPNDIR/bin/p7bToPem script. For detailed information, refer to SecureKnowledge solution sk31589.
Completing the Certificate Installation Procedure

After installing a Connectra server certificate, you must install the policy on Connectra.
Note - The Certificates page on the SmartDashboard Connectra gateway object is only used for creating self-signed certificates. It does not affect the certificate installed manually using this procedure.

Self signed Connectra certificates are convenient for use during pre-production testing and demonstrating of Connectra.
Note - For production environments, a server certificate signed by a known certificate authority is recommended, in order to prevent certificate warning messages appearing to users.
An installed and configured Connectra has a default self-signed server certificate. It is possible to generate and install a new self-signed certificate.
Generating and Installing a Self Signed Certificate

To replace the Connectra server certificate with self-signed certificate, run the GenerateAndInstallCert script. This script generates the certificate files that Connectra requires.
250
When the script runs, the following occurs by default: 1. The old certificates are backed up to $CVPNDIR/var/ssl/old_certs/. 2. Certificate files are created in $CVPNDIR/var/ssl. The options for running this script are as follows. All options can be combined:
GenerateAndInstallCert Basic options

Table 8-1 GenerateAndInstallCert Basic Options
Option (No flag)
Description Backup existing certificates, and create a self-signed certificates with the server IP as subject. Backup existing certificates, and create a self-signed certificate with mymodule.example.com as subject. Backup existing certificates, and create a self-signed wildcard certificate with *.mymodule.example.com as subject. (You must supply a subject when creating wildcard certificate). Display the usage message.
mymodule.example.com
-w mymodule.example.com
GenerateAndInstallCert Advanced options

Table 8-2 GenerateAndInstallCert Advanced Options
Command
Description Override existing certificates without backup. Backup existing certificates with the base name mycert (if it exists), and create new certificate files in the $CVPNDIR/var/ssl directory with the names mycert.* (instead of default names server.*). This option has no affect on the Connectra server certificate. Certificates with base names other than mycert are not affected.
o t mycert
Chapter 8
Viewing Connectra Certificate Details

The details of the Connectra default self-signed certificate can be viewed from SmartDashboard. If the Connectra self-signed certificate is replaced by a certificate from a well known Certificate authority, or by a new self-signed certificate, the details of the certificate can viewed via a Web browser.
Viewing the Default Connectra Self-Signed Certificate

To view the details of the default Connectra self-signed certificate: 1. In the SmartDashboard Connectra tab, select Additional Settings > Certificates. 2. For locally managed Connectra, click View. For centrally managed Connectra, select a gateway, click Edit and then click View. The Certificate View window opens:
Viewing Connectra Certificate Details via a Browser

If the Connectra self-signed certificate is replaced by a certificate from a well known Certificate authority, or by a new self-signed certificate, the details of the certificate can viewed via a Web browser.
252
To view the Connectra certificate details, browse to the Connectra gateway, at https://<Connectra IP address or FQDN>:443. The SSL certificate of the Connectra gateway is presented in a browser popup. For example:
Chapter 8
Session Settings
Session Settings
This section discusses Connectra session related parameters and best practices.
In This Section
Simultaneous Logins to the Portal Session Timeouts Roaming Tracking Securing Authentication Credentials page 254 page 258 page 258 page 258 page 258
Simultaneous Logins to the Portal

Having a single user logged in to Connectra more than once, from two different locations for example, is a potential security issue. Simultaneous login prevention enables a Connectra gateway to automatically disconnect a remote user who is logged more than once. When simultaneous login prevention is enabled, and a users authentication information used to log in from two different computers, only the later login is considered legitimate, and the earlier session is logged out.
Note - Simultaneous login prevention is available for Connectra NGX R66 and higher.
In This Section
Configuring Simultaneous Login Prevention Tracking of Simultaneous Logins Simultaneous Login Issues page 255 page 256 page 257
254
Configuring Simultaneous Login Prevention

Simultaneous login prevention is configured in SmartDashboard from the Additional Settings > Session page.
The options are: User is allowed several simultaneous logins to the Portal Simultaneous login detection is disabled. This is the default option. User is allowed only a single login to the portal selected Inform user before disconnecting his previous session not selected The earlier user is disconnected and the later user is allowed. The earlier user is logged out. For Connectra portal users, the following message appears: Your Connectra session has timed out. would you like to sign in again now?. The later user is not informed that an earlier user is logged in.
User is allowed only a single login to the portal selected Inform user before disconnecting his previous session selected
Chapter 8
The later user is informed that an earlier user is logged in, and is given the choice of either canceling the logon and retaining the existing session, or of logging in and terminating the existing session. If the existing session is terminated, the user is logged out with the message: Your Connectra session has timed out. would you like to sign in again now?.
Tracking of Simultaneous Logins

To track simultaneous login events, select All Events in the Tracking section of the Additional Settings > Session page. When the gateway disconnects a user, the gateway records a log of the disconnection, containing the connection information of both logins. All disconnect and connect events create a corresponding entry in the traffic log. The following values of the authentication status field relate to simultaneous logins: Success - User successfully logged in. Existing active sessions were terminated. Inactive - User successfully authenticated, but existing sessions need to be terminated prior to logging on. Disconnected - An existing user session has been terminated because the same user has logged on to another session.
256
Simultaneous Login Issues

Endpoint Connect- Simultaneous Login Issues
For Endpoint Connect users, Connectra does not prevent simultaneous login. This is equivalent to the User can have several simultaneous logins to the portal option. An Endpoint Connect user cannot log out another user with the same username, and cannot be logged out by another user with the same username.
SecureClient Mobile - Simultaneous Login Issues

With User can have only a single simultaneous login to the portal selected and Inform user before disconnecting previous sessions not selected
SecureClient Mobile users can be logged off by another user, and can log off other users. However, the Inform user before disconnecting his previous session option does not work, because no message can be sent to those users. User can be logged off, but cannot log off other users.
Other Simultaneous Login Issues

1. When a session is disconnected by another user and SSL Network Extender application mode client is being used, the SSL Network Extender window remains open, while the session is disconnected. Similarly, when a session is disconnected by another user and Secure Workspace is being used, Secure Workspace remains open, while the session is disconnected. 2. When a session is disconnected by another user and Citrix is being used, the Citrix window remains open, while the session is disconnected. 3. All current sessions are deleted when changing the section from User can have only a single login to the Portal to User is allowed several simultaneous logins to the Portal.
Chapter 8
Session Timeouts
Session Timeouts
Once authenticated, remote users work in a Connectra session until they log out or the session terminates. Security best practices provide for limiting the length of active and inactive Connectra sessions to prevent abuse of secure remote resources.
Note - Connectra uses the system time to keep track of session timeouts. Changing the system time may disrupt existing session timeouts. Therefore, it is recommended to change the system time during low activity hours.
Connectra provides two types of session timeouts, both of which are configurable. Re-authenticate users every is the maximum session time. When this period is reached, the user must login once more. The default value is 60 minutes. Changing this timeout affects only future sessions, not current sessions. Disconnect idle sessions after is the disconnection time-out if the connection remains idle. The default value is 15 minutes. When users connect via SSL Network Extender, this timeout does not apply.
Roaming
The Roaming option allows users to change their IP addresses during an active session. By default, user requests are denied if sent from a different IP address than that used for login.
Note - Users connected via SSL Network Extender can always change IP address while connected, irrespective of the roaming setting.
Tracking
Configure Connectra to log session activity, including login attempts, logouts, timeouts, activity states and license expiration warnings.
Securing Authentication Credentials

Having multiple users on the same machine accessing the Connectra portal via the Firefox browser can be a security hazard. A user that is logged in to the Connectra portal via the Firefox browser can open a new Firefox browser (by clicking an icon,
258
Securing Authentication Credentials
or for example, choosing Firefox from a menu), receive the authentication credentials of the earlier session and browse directly to the Connectra portal without re-entering the login credentials.
Tip - To ensure their authentication credentials are not stolen by others, you should recommend to users that they log off or close all browser windows after they have finished using the browser.
Chapter 8
Changing the IP Address of a Connectra Gateway or Cluster
Changing the IP Address of a Connectra Gateway or Cluster

To change the IP address of a standalone Connectra gateway or a Connectra cluster, you need to make configuration changes at the local machine console (using the Web IU), and also via SmartDashboard.
At the local machine

1. Log in to the Connectra local Web interface using the IP address of the Connectra gateway. 2. Select Network > Connections. 3. Click the name of the interface you want to change. 4. Enter the new IP address in the IP Address field. Click Apply.
Using SmartDashboard
5. Edit the Connectra object or the Connectra cluster object, and update the IP address in the following pages: General Properties Cluster Members (Connectra cluster only) Topology Portal Customization VPN Clients
6. Install the Policy.
260
VPN Client and Portal Connectivity in a Single Gateway
VPN Client and Portal Connectivity in a Single Gateway

To enable VPN access, Connectra must be configured to listen for Connectra portal traffic and VPN client traffic. For a single Connectra gateway, the default setting is that Connectra listens for portal and VPN client traffic as follows: Portal traffic on port 443 (TCP service: https). This setting is configured in SmartDashboard, as shown in Figure 8-1. VPN client traffic on port 444 (TCP service: CP_SSL_Network_Extender). This setting is configured in SmartDashboard, as shown in Figure 8-2
This requires one publicly routable IP address for Connectra.

Figure 8-1 Connectra Object Portal Customization page Figure 8-2 Connectra Object VPN Client Page
The other possible configuration is for Connectra to listen for both portal and SSL Network Extender traffic on port 443. This requires separate IP addresses for the portal and for SSL Clients, but allows access to users who are in locations that prevent access to port 444, and only allow access to port 443
Chapter 8
Web Data compression
Web Data compression

In This Section
Understanding Web Data compression Configuring Data Compression page 262 page 263
Understanding Web Data compression

Connectra can be configured to compress Web content. This can produce a much faster Web site for users. It also reduces bandwidth needs and therefore costs. Most compression algorithms, when applied to a plain-text file, can reduce its size by 70% or more, depending on the content in the file. Be aware that compression does increase the CPU usage of Connectra, which in itself does have some performance implications. Most browsers can accept compressed data, uncompress it and display it. If configured to compress data, Connectra compresses the data received from Web servers (the http or https response). If the Web browser at the endpoint compresses the http or https request, Connectra uncompresses it and sends it on to the server. This is illustrated in Figure 8-3. Connectra supports the gzip, deflate, and compress compression methods. It is possible to specify the mime types that will be compressed.
262
Configuring Data Compression Figure 8-3 Data Compression by Connectra
Configuring Data Compression

To configure data compression by Connectra, proceed as follows:
Note - In a Connectra cluster, perform the following steps on every cluster member.
1. Log in to the Connectra console. 2. Enter Expert mode. 3. Save a backup copy of $CVPNDIR/conf/cvpnd.C 4. Edit the file $CVPNDIR/conf/cvpnd.C 5. To add compression support, add the bolded word (including the minus).
:programArgs ("-DFOREGROUND -DWEBCOMP -E /opt/CPcvpn-R66/log/httpd.starlog -f /opt/CPcvpn-R66/var/httpd.conf-real -k start")

If you want specific mime types, include both bolded words (including the minus):
:programArgs ("-DFOREGROUND -DWEBCOMP -DCOMPMIME -E /opt/CPcvpn-R66/log/httpd.starlog -f /opt/CPcvpn-R66/var/httpd.conf-real -k start")

6. Save cvpnd.C 7. To set advanced features (such as setting higher compression level or changing the mime types that are compressed), save a backup and then edit the file $CVPNDIR/conf/includes/Root.location.conf. The # symbol indicates the start of a comment line. To get a higher compression level uncomment the line
#DeflateCompressionLevel 9
Chapter 8
Configuring Data Compression
To change the mime types that are compressed modify the list:
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css \ text/javascript application/x-javascript

The \ symbol splits the single line over two lines. (Both lines are considered to be on the same single line). It must be the last character of the line. (No space characters are allowed after it). 8. Save Root.location.conf 9. Run the command cvpnrestart.
264
9 Chapter Connectra Gateway Clusters

In This Chapter
The Connectra Gateway Clustering Solution Geo-Clustering of Connectra Gateways Connectra Cluster installation and Licensing Requirements Synchronization Between Cluster Members Example Connectra Gateway Cluster Topology How Connectra Clusters Work The Sticky Decision Function Failover Hardware Requirements and Compatibility Basic Connectra Cluster Configuration Advanced Connectra Cluster Configuration page 266 page 270 page 271 page 272 page 274 page 278 page 283 page 284 page 289 page 293 page 303
265
The Connectra Gateway Clustering Solution
The Connectra Gateway Clustering Solution

A Web Security Gateway is a business critical device for an organization. A failure of a gateway results in immediate loss of remote access traffic in and out of the organization. Many of these sessions may be mission critical, and losing them will result in loss of critical data. Connectra makes it possible to set up a Load Sharing or High Availability clustering solution that distributes network traffic between Connectra cluster members. A Connectra cluster provides: Transparent failover in case of cluster member failure. Zero downtime for mission-critical environments. Enhanced throughput (in Load Sharing mode).
All cluster members are aware of the sessions tracked through each of the other cluster members. The cluster members synchronize their sessions and status information across a secure synchronization network. Connectra gateway clusters are supported for centrally managed Connectra gateways. Locally managed Connectra clusters are not supported.
Clustering Definitions and Terms

Different vendors give different meanings to terms that relate to gateway clusters, High Availability and Load Sharing. Check Point uses the following definitions in discussing clustering: Cluster A group of gateways that work together to provide Load Sharing and/or High Availability. Failure A hardware or software problem that causes a cluster member to be unable to provide service. A failure of an Active cluster member leads to a Failover. Failover A cluster member taking over functionality in place of another cluster member in the cluster that suffered a Failure.
266
Clustering Definitions and Terms
High Availability The ability to maintain a session when there is a Failure by having another cluster member to take over the connection, without any loss of connectivity. Only the Active cluster member provides service, and the others do not. One of the cluster members is configured as the Active gateway. If a Failover occurs on the Active gateway, one of the other cluster members assumes its responsibilities. Active Up When the High Availability cluster member that was Active and suffered a Failure becomes available again, it returns to the cluster, not as the Active cluster member but as one of the standby cluster members. Primary Up When the High Availability cluster member that was Active and suffered a Failure becomes available again, it resumes its responsibilities as the Primary cluster member. Hot Standby Also known as Active/Standby. Means the same as High Availability. Load Sharing In a Load Sharing Cluster, all cluster members share the workload of providing service. Load Sharing provides High Availability, gives transparent Failover to any of the other cluster members when a Failure occurs and provides enhanced reliability and performance. Load Sharing is also known as Active/Active. Critical Device A device which the administrator has defined to be critical to the operation of the cluster member. A critical device is also known as a Problem Notification (pnote). Critical devices are constantly monitored. If a critical device stops functioning, this is defined as a Failure. A device can be hardware, or a process. The fwd and cphad processes are predefined by default as critical devices. The Security Policy is also predefined as a critical device. The administrator can add to the list of critical devices using the cphaprob command. State Synchronization The technology that maintains connections after Failover. It works by replicating Connectra kernel tables.
Chapter 9
Connectra Gateway Clusters 267
Load Sharing
Secured interface An interface on a secure network. The synchronization network should be secured because of the sensitivity of the data that passes across it. One way of securing a network is to ensure that all interfaces connected to it are in a single locked room. Connecting the synchronization interfaces via a cross cable is another way of securing an interface.
Load Sharing
In a Load Sharing deployment, all the cluster members are active at all times (Active/Active operation). Load Sharing brings significant performance advantages. Putting to work multiple Connectra gateways instead of a single gateway provides linear performance increases for CPU intensive tasks. If any individual Connectra cluster member becomes unreachable, transparent failover occurs to the remaining operational cluster member, thus providing High Availability. All sessions are shared between the remaining cluster members without interruption.
High Availability
In a High Availability Connectra cluster deployment, only one cluster member is active (Active/Standby operation). In the event that the active cluster member becomes unreachable, all sessions are re-directed to a designated backup without interruption. In a High Availability cluster, each cluster member is given a priority. The highest priority cluster member serves as the Connectra gateway in normal circumstances. If this cluster member fails, control is passed to the next highest priority cluster member. If that cluster member fails, control is passed to the next cluster member, and so on. Upon cluster member recovery, it is possible to Maintain current active Cluster Member (Active Up), or to Switch to higher priority Cluster Member (Primary Up).
Comparing Load sharing and High Availability

Whether to choose a Load Sharing (Active/Active) or a High Availability (Active/Standby) configuration depends on the requirements of the organization.
268
Comparing Load sharing and High Availability
The High Availability mode is equivalent to the ClusterXL High Availability New mode in VPN-1. The Load Sharing mode is equivalent to the ClusterXL Load Sharing Unicast mode in VPN-1. Features common to both Connectra ClusterXL modes are: Fail-safe operation. VLAN Tagging Support. Cluster members are synchronized. One machine in cluster receives packets from router. Cluster answers ARP requests for a MAC address using Unicast. Cluster Control Protocol (CCP) can use Multicast (by default) or Broadcast.
The differences between the Connectra clustering modes are: Feature Performance Load sharing operation Number of members that deal with network traffic High Availability Mode Good No 1 Load Sharing Mode Very Good Yes n
Chapter 9
Geo-Clustering of Connectra Gateways
Geo-Clustering of Connectra Gateways

The use of geographically remote gateways for failover and disaster recovery is known as geo-clustering. This capability is now available for the following Connectra remote access methods: by way of a browser to the Connectra portal, using SSL Network Extender, or by using the Endpoint Connect client. Geo-clustering is supported through the use of a single DNS name to represent multiple gateways. Third party devices enhance this basic capability, by providing monitoring of the operational status of Connectra gateways, and by supporting location-based gateway assignment to minimize the client's traffic latency. Two third party devices have been tested for Connectra NGX R66: Radware AppDirector For details, download the document: Global Load-Balancing with Check Point Connectra and RadWare AppDirector. F5 BIG-IP For details, download the document: Global Load-Balancing with Check Point Connectra and F5 BIG-IP GTM.
Geo clustering is distinct from normal gateway clustering, and used in different scenarios. While normal clustering is used for gateways in close proximity, geo-clustering applies to remote gateways. Unlike normal clustering, geo-clustering does not provide for replication of the gateway's configuration.
270
Connectra Cluster installation and Licensing Requirements
Connectra Cluster installation and Licensing Requirements

Connectra cluster members must all have the same software version. To install a policy on a Connectra cluster, all Connectra cluster gateways must be licensed for the same number of users. They do not necessarily have to have identical licenses. The maximum licensed number of users is enforced.
Chapter 9
Synchronization Between Cluster Members
Synchronization Between Cluster Members

In This Section
Introduction to State Synchronization The Synchronization Network Synchronized Cluster Restriction page 272 page 272 page 273
Introduction to State Synchronization

State Synchronization enables all cluster members to be aware of the sessions passing through each of the other cluster members. It ensures that if there is a failure in a cluster member, sessions that were handled by the failed cluster member will be maintained by the other cluster members. The following are synchronized: 1. Session data - including session cookies, authentication and authorization states. 2. Persistent data - such as favorites, which remain between logins.
The Synchronization Network

The Synchronization Network is used to transfer synchronization information about sessions and other Connectra states between cluster members. Because the synchronization network carries the most sensitive policy information in the organization, it is important to make sure that it is secured against both malicious and unintentional interference. It is therefore recommended to secure the synchronization interfaces by connecting the physical network interfaces of the cluster members directly using a cross-cable. In a cluster with three of more members, use a dedicated hub or switch. Following these recommendations guarantees the safety of the data in the synchronization network because no other networks carry synchronization information. The synchronization network is supported on the lowest VLAN tag of a VLAN interface. For example, if three VLANs with tags 10, 20 and 30 are configured on interface eth1, interface eth1.10 may be used for synchronization.
272
Synchronized Cluster Restriction
Synchronized Cluster Restriction

The following restriction applies to synchronizing Connectra cluster members: Accounting information is accumulated in each cluster member and reported separately to the SmartCenter Server, where the information is aggregated. In case of a failover, accounting information that was accumulated on the failed member but not yet reported to the SmartCenter Server is lost. To minimize the problem it is possible to reduce the period in which accounting information is flushed. To do this, in the cluster objects Logs and Masters > Additional Logging page, configure the attribute Log forwarding schedule:.
Chapter 9
Connectra Cluster Topology
Connectra Cluster Topology

In This Section
Example Connectra Gateway Cluster Topology Cluster Interfaces SSL Client and Portal Connectivity in a Cluster The Cluster Member IPs Configuring Member Networks page 274 page 274 page 275 page 276 page 276
Example Connectra Gateway Cluster Topology

Typically, the cluster is deployed behind the DMZ interface of a firewall, with the application servers behind the firewall in the internal networks, though it can also be deployed behind the firewall, or even without a firewall. Figure 9-1 shows a simple two-member Connectra cluster. Figure 9-1
Example Connectra Clustering Topology
Cluster Interfaces
Connectra cluster members have a unique IP and MAC addresses for each physical interface. The Connectra cluster has a virtual cluster interface with a routable IP address. Connectra clients access the Connectra portal via the cluster interface, not the member interfaces. The IP address (or addresses) of the cluster interface do not belong to any real cluster member interface. Running the ifconfig command on the cluster members shows only the member interfaces, not the cluster interfaces. This is because the operating system does know about the cluster interfaces. To get information about the cluster interfaces,
274
SSL Client and Portal Connectivity in a Cluster
you need to use run the ClusterXL commands cphaprob state (used to monitoring cluster status) and cphaprob -a if (used to monitor the state of the cluster interfaces). For information about cluster monitoring and troubleshooting commands, see the ClusterXL Administration Guide.
SSL Client and Portal Connectivity in a Cluster

Setting up Connectivity for client access to the portal and to Native Applications in a Connectra gateway cluster is similar to those in a single Connectra gateway (See VPN Client and Portal Connectivity in a Single Gateway on page 261). The difference is that in a Connectra gateway cluster, portal and SSL Network Extender are accessed via a cluster interface. The IP address (or addresses) of the cluster interface do not belong to any real cluster member interface. To configure Connectra to listen for portal and SSL client traffic on the same IP address (but on different ports), you need to configure a Single Cluster Interface, which is a cluster interface with a single IP address. Figure 9-1 shows a Connectra cluster with a Single Cluster Interface. To configure Connectra to listen for portal and SSL client traffic on different IP addresses (but on the same port), you need to configure a Dual Cluster Interface, which is a cluster interface with two IP addresses. Figure 9-2 shows a Connectra cluster with a Dual Cluster Interface.
Chapter 9
The Cluster Member IPs
Figure 9-2
Connectra Cluster with a Dual Cluster Interface
The Cluster Member IPs

Each Connectra cluster member has two interfaces: one data interface leading to the organization and to the Internet, and a second interface for synchronization. The cluster member data interfaces are connected via a switch, router, or VLAN switch. Each member interface is on a different subnet. One subnet for data (in Figure 9-2, 10.0.0.0). One subnet for synchronization (in Figure 9-2, 10.0.10.0).
The data subnet of the members can be either The same as the Cluster interface subnet (in Figure 9-1. 192.168.10.0). This is the default option. Different than the Cluster Interface subnet (in Figure 9-2, the cluster interface subnet is 10.0.0.0, and the member data subnet is 192.168.10.0). This options requires member networks to be configured.
Configuring Member Networks

Only one routable IP address is required in a cluster interface. All cluster member physical order to achieve this, member networks must Interfaces and the cluster member interfaces This is useful in order to: Connectra cluster, for the virtual IP addresses can be non-routable. In be configured, so that the Cluster are on different subnets
276
Enable a Connectra cluster to replace a single Connectra gateway in a pre-configured network, without the need to allocate new addresses to the cluster members. Allow organizations to use only one routable address for the Connectra Cluster. This saves routable addresses.
For details, see the ClusterXL Administration Guide.

To understand the synchronization network and its requirements, see The Synchronization Network on page 272. Figure 9-2 shows a synchronization interface with a unique IP address on each cluster member. 10.0.10.1 on Member_A and 10.0.10.2 on Member_B.
Chapter 9
How Connectra Clusters Work
How Connectra Clusters Work

In This Section
The Cluster Control Protocol How Load Sharing Mode Works How High Availability Mode Works page 278 page 278 page 280
The Cluster Control Protocol

The Cluster Control Protocol (CCP) is the glue that links together the Connectra gateways in the cluster. CCP traffic is distinct from ordinary network traffic, and can be seen using any network sniffer. CCP runs on UDP port 8116, and has the following roles: Allows cluster members to report their own states and learn about the states of other members, by sending keep-alive packets. State synchronization.
How Load Sharing Mode Works

The Load Sharing mode is equivalent to the ClusterXL Load Sharing Unicast mode in VPN-1. In Load Sharing mode a single cluster member, referred to as Pivot, is associated with the cluster's virtual IP addresses, and is thus the only member to receive packets sent to the cluster. The pivot is then responsible for propagating the packets to other cluster members, creating a Load Sharing mechanism. Distribution is performed by applying a decision function on each packet. Only one member performs this selection: any non-pivot member that receives a forwarded packet will handle it, without applying the decision function. Note that non-pivot members are still considered as active, since they perform functional tasks on a share of the traffic (although they do not make decisions). Even though the pivot member is responsible for the decision process, it still acts as a gateway that processes packets (for example, the decision it makes can be to handle a packet on the local gateway). However, since its additional tasks can be time consuming, it is assigned a smaller share of the total load.
278
How Load Sharing Mode Works
When a failover event occurs in a non-pivot member, its handled sessions are redistributed between active cluster members, providing High Availability capabilities. When the pivot member encounters a problem, a regular failover event occurs, and, in addition, another member assumes the role of the new pivot. The pivot member is always the active member with the highest priority. This means that when a former pivot recuperates, it will again become the pivot. See Figure 9-1 on page 274 for an example of a typical Connectra cluster configuration.
Example
In this scenario, we use a Load Sharing Connectra cluster as the gateway between the user's computer and the Web server. 1. The user requests a session from tier client computer 10.10.0.34 (the Web server).
192.168.10.78
to
2. A router on the 192.168.10.x network recognizes 192.168.10.100 (the cluster's virtual IP address) as the gateway to the 10.10.0.x network. 3. The router issues an ARP request to
192.168.10.100.
4. The pivot member intercepts the ARP request, and responds with the MAC address that corresponds to its own unique IP address of 192.168.10.1. 5. When the Web server responds to the user requests, it recognizes as its gateway to the Internet. 6. The Web server issues an ARP request to
10.10.0.100. 10.10.0.100
7. The pivot member intercepts the ARP request, and responds with the MAC address that corresponds to its own unique IP address of 10.10.0.1. 8. The user's request packet reaches the pivot member on interface
192.168.10.1.
9. The pivot decides that the second member should handle this packet, and forwards it to 192.168.10.2. 10. The second member recognizes the packet as a forwarded one, and processes it. 11. Further packets are processed by either the pivot member, or forwarded and processed by the non-pivot member. 12. When a failover occurs on the pivot, the second member assumes the role of pivot.
Chapter 9
How High Availability Mode Works
13. The new pivot member sends gratuitous ARP requests to both the 192.168.10.x and the 10.10.0.x networks. These requests associate the virtual IP address of 192.168.10.100 with the MAC address that correspond to the unique IP address of 192.168.10.2, and the virtual IP address of 10.10.0.100 with the MAC address that correspond to the unique IP address of 10.10.0.2. 14. Traffic sent to the cluster is now received by the new pivot, and processed by the local gateway (as it is currently the only active gateway in the cluster). 15. When the first gateway recovers, it re-assumes the role of pivot, by associating the cluster IP addresses with its own unique MAC addresses.

The High Availability mode is equivalent to the ClusterXL High Availability mode in VPN-1. The High Availability Mode provides basic High Availability capabilities in a cluster environment. This means that the cluster can provide services even when it encounters a problem, which on a stand-alone module would have resulted in a complete loss of connectivity. Combined with State Synchronization, High Availability can maintain sessions through failover events, in a user-transparent manner, allowing a flawless connectivity experience. Thus, High Availability provides a backup mechanism, which organizations can use to reduce the risk of unexpected downtime, especially in a mission-critical environment. To achieve this purpose, High Availability mode designates one of the cluster members as the active Connectra gateway, while the rest of the members are kept in a stand-by mode. The cluster's virtual IP addresses are associated with the physical network interfaces of the active Connectra gateway (by matching the virtual IP address with the unique MAC address of the appropriate interface). Thus, all traffic directed at the cluster is actually routed (and filtered) by the active member. The role of each cluster member is chosen according to its priority, with the active member being the one with the highest ranking. Member priorities correspond to the order in which they appear in the Cluster Members section of the Cluster Configuration page. The top-most member has the highest priority. You can modify this ranking at any time. In addition to its role as a Connectra gateway, the active member is also responsible for informing the stand-by members of any changes to its connection and state tables, keeping these members up-to-date with the current traffic passing through the cluster.
280
Whenever the cluster detects a problem in the active member that is severe enough to cause a failover event, it passes the role of the active member to one of the standby Connectra gateways (the member with the currently highest priority). Any open sessions are recognized by the new active Connectra gateway, and are handled according to their last known state. Upon the recovery of a member with a higher priority, the role of the active Connectra gateway may or may not be switched back to that member, depending on the configuration settings. It is important to note that the cluster may encounter problems in standby Connectra gateways as well. In this case, these Connectra gateways are not considered for the role of active members, in the event of a failover. See Figure 9-1, Example Connectra Clustering Topology, on page 274 for an example of a typical Connectra cluster configuration.
Example
This scenario describes a user logging from the Internet to a Web server behind the Firewall cluster. 1. The user requests a session from (the Web server).
192.168.10.78
(his computer) to
10.10.0.34
2. A router on the 192.168.10.x network recognizes 192.168.10.100 (the cluster's virtual IP address) as the gateway to the 10.10.0.x network. 3. The router issues an ARP request to
192.168.10.100.
4. The active member intercepts the ARP request, and responds with the MAC address that corresponds to its own unique IP address of 192.168.10.1. 5. When the Web server responds to the user requests, it recognizes as its gateway to the Internet. 6. The Web server issues an ARP request to
10.10.0.100. 10.10.0.100
7. The active member intercepts the ARP request, and responds with the MAC address that corresponds to its own unique IP address of 10.10.0.1. 8. All traffic between the user and the Web server is now routed through the active member. 9. When a failover occurs, the standby member concludes that it should now replace the faulty active member.
Chapter 9
10. The stand-by member sends gratuitous ARP requests to both the 192.168.10.x and the 10.10.0.x networks. These requests associate the virtual IP address of 192.168.10.100 with the MAC address that correspond to the unique IP address of 192.168.10.2, and the virtual IP address of 10.10.0.100 with the MAC address that correspond to the unique IP address of 10.10.0.2. 11. The stand-by member has now switched to the role of the active member, and all traffic directed through the cluster is routed through this Connectra gateway 12. The former active member is now considered to be down, waiting to recover from whatever problem that had caused the failover event
282
The Sticky Decision Function
The Sticky Decision Function

A connection is sticky when all of its packets are handled, in either direction, by a single cluster member. In Load Sharing mode it is necessary to ensure that a connection that starts on a specific cluster member will continue to be processed by the same cluster member in both directions. The Sticky Decision Function distributes sessions from client IPs between the cluster members, and ensures that connections from a given IP always pass through the same member.
Chapter 9
Failover
Failover
In This Section
What is a Failover? What Happens When Failover Occurs? When Does a Failover Occur? Cluster Member Priority What Happens When a Cluster Member Recovers? How a Recovered Cluster Member Obtains the Security Policy How Connectra Applications Behave Upon Failover page 284 page 284 page 285 page 286 page 286 page 286 page 287
What is a Failover?
A failover occurs when a cluster member is no longer able to perform its designated functions. When this happens another cluster member in the Connectra cluster assumes the failed cluster members responsibilities. In a Load Sharing configuration, if one Connectra cluster members goes down, its sessions are distributed among the remaining cluster members. All cluster members in a Load Sharing configuration are synchronized, so no sessions are interrupted.
What Happens When Failover Occurs?

During failover of a Load Sharing configuration, all sessions are redistributed, not just sessions from the failed member. For example, in a three member Connectra cluster, assume cluster member A handles sessions 1-33, member B handles sessions 34-66, and member C handles sessions 67-100. If member A fails, member B takes on sessions 1-50, and member C takes on sessions 51-100. Notice that sessions 51-66 are transferred from member B to member C, even though it was member A that failed. In most cases the failover is transparent and users are not aware that it has occurred (see How Connectra Applications Behave Upon Failover on page 287). In a High Availability configuration, if one cluster member in a synchronized Connectra cluster goes down, another cluster member becomes active and takes over the sessions of the failed cluster member.
284
When Does a Failover Occur?
To tell each Connectra cluster member that the other cluster members are alive and functioning, the Cluster Control Protocol (CCP) maintains a heart beat between cluster members. If a certain predetermined time has elapsed and no message is received from a cluster member, it is assumed that the cluster member is down and a failover occurs. At this point another cluster member automatically assumes the responsibilities of the failed cluster member. Note that more than one cluster member may encounter a problem that will result in a failover event. In cases where all cluster members encounter such problems, the Connectra cluster will try to choose a single member to continue operating. The state of the chosen member will be reported as Active Attention. This situation lasts until another member fully recovers. For example, if a cross cable connecting the cluster members malfunctions, both members will detect an interface problem. One of them will change to the Down state, and the other to Active Attention.
When Does a Failover Occur?

A failover takes place when one of the following occurs on the active Connectra cluster member: Any critical device (such as fwd) fails. A critical device is a process running on a Connectra cluster member that enables the member to notify other cluster members that it can no longer function as a member. The device reports to the clustering mechanism regarding its current state or it may fail to report, in which case the clustering mechanism decides that a failover has occurred and another cluster member takes over. An interface or cable fails. The cluster member crashes. The Security Policy is uninstalled. When the Security Policy is uninstalled Connectra can no longer function as a Web security Connectra gateway, and a failover occurs. Normally policy uninstallation is initiated by an administrator.
It should be noted that a Connectra cluster member may still be operational but if any of the above checks fail in the cluster, then the faulty member initiates the failover because it has determined that it can no longer function as a cluster member.
Chapter 9
Cluster Member Priority
Cluster Member Priority

In a High Availability New mode cluster (for Connectra, this is called a High Availability cluster), each machine is given a priority. The highest priority machine serves as the gateway in normal circumstances. If this machine fails, control is passed to the next highest priority machine. If that machine fails, control is passed to the next machine, and so on. In Load Sharing Unicast mode cluster (for Connectra, this is called a Load Sharing cluster), the highest priority is the pivot machine. The list of cluster members is displayed hierarchically in the Cluster Members page of the Cluster object with the highest priority member at the top of the list. The behavior upon cluster member recovery is controlled in the ClusterXL page of the Cluster object.
What Happens When a Cluster Member Recovers?

In a Load Sharing configuration, when the failed Gateway in a Connectra cluster recovers, all sessions are redistributed among all active members. In a High Availability configuration Upon Cluster Member recovery, the options are: Maintain current active Cluster Member. This is the recommended if all members are equally capable of processing traffic, in order to minimize the number of failover events. Switch to higher priority Cluster Member. This mode is recommended if one member is better equipped for handling connections, so it will be the default cluster member.
How a Recovered Cluster Member Obtains the Security Policy

The administrator installs the security policy on the Connectra cluster object rather than separately on individual cluster members. The policy is automatically installed on all cluster members. The policy is sent to the cluster member data interface addresses. When a failed Connectra cluster member recovers, it will first try to get a policy from one of the other cluster members. The assumption is that the other cluster members have an up to date policy. If this does not succeed, it compares its own
286
How Connectra Applications Behave Upon Failover
local policy to the policy on the management component of the cluster member. If the policy on the administration component of the cluster member is more up to date than the one on the cluster member, that policy will be retrieved. If the cluster member does not have a local policy, it retrieves one from the administration component of the cluster member. This ensures that all cluster members use the same policy at any given moment.

Table 9-1 summarizes the end-user experience upon failover for each Connectra application. Table 9-1
How Applications Behave Upon Failover
Application Web browsing through the user portal Domino Web Access Outlook Web Access File Shares
Survives failover? Yes
User experience upon failover User is unaware of failover. However, if the failover happens while a user is clicking a link or waiting for a server response, user may be disconnected and may need to refresh the page.
Web Mail
No
If failover occurs while a user is clicking a link or waiting for a server response, user sees an error page. By clicking the link Go to the login page the user returns to the Inbox, and the original session is lost. User is disconnected, and the Citrix session is lost. User must actively re-establish a connection. Re-scan may be required if user logs out of the portal, or needs to log in again. User is unaware of failover. However, if the failover happens while a user is clicking a link or waiting for a server response, user may be disconnected and may need to refresh the page. If user is in the middle of a multi-challenge login he/she is redirected to the initial login page.
Citrix
No
Endpoint Compliance Scan Secure Workspace
Yes Yes
Multi challenge login
No
Chapter 9
Table 9-1
How Applications Behave Upon Failover
Application SSL Network Extender Network Mode SSL Network Extender Application Mode
Survives failover? Yes
User experience upon failover The user may notice the connection stalling for a few seconds, as if there was a temporary network disconnection. SSL Network Extender remains open and in a connected state. However, connections of applications using the VPN tunnel are lost. Some applications (such as Outlook) try to reopen lost connections, while others (Telnet for example) are closed (or exit). Network Mode Survives failover. Application Mode Does not survive failover.
No
SSL Network Extender Downloaded-to-Connectra applications
Mode dependant
288
Hardware Requirements and Compatibility
Hardware Requirements and Compatibility

In This Section
Connectra Cluster Hardware Requirements Connectra Cluster Hardware Compatibility Example configuration of a Cisco Catalyst Routing Switch page 289 page 290 page 291
Connectra Cluster Hardware Requirements

The Connectra cluster is usually located in an environment having other networking devices such as switches and routers. These devices and Connectra must interact to assure network connectivity. This section outlines the requirements imposed by the Connectra cluster on surrounding networking equipment. Table 9-2
Switch Setting for Connectra Clustering
Switch Setting IGMP and Static CAMs
Explanation Connectra clusters do not support IGMP registration (also known as IGMP Snooping). You should disable this feature in switches that rely on IGMP packets to configure their ports. In situations where disabling IGMP registration is not acceptable, it is necessary to configure static CAMs in order to allow multicast traffic on specific ports. Certain switches have an upper limit on the number of broadcasts and multicasts that they can pass, in order to prevent broadcast storms. This limit is usually a percentage of the total interface bandwidth. It is possible to either turn off broadcast storm control, or to allow a higher level of broadcasts or multicasts through the switch. If the connecting switch is incapable of having any of these settings configured, it is possible, though less efficient, for the switch to use broadcast to forward traffic, and to configure the cluster members to use broadcast CCP (described in If the Switch is Incapable of Forwarding Multicast on page 294).
Disabling multicast limits
Chapter 9
Connectra Cluster Hardware Compatibility
The following settings should be configured on the router: Table 9-3

Router Setting for Connectra Clustering
Router Setting Unicast MAC
Explanation When running Connectra clusters, the Cluster interface (virtual) IP address is mapped to the MAC address of the active member. The router needs to be able to learn this MAC through regular ARP messages.
Connectra Cluster Hardware Compatibility

The following routers and switches are known to be compatible with Connectra clusters:
Routers
Cisco 7200 Series Cisco 1600, 2600, 3600 Series
Routing Switch
Extreme Networks Blackdiamond (Disable IGMP snooping) Extreme Networks Alpine 3800 Series (Disable IGMP snooping) Foundry Network Bigiron 4000 Series Nortel Networks Passport 8600 Series Cisco Catalyst 6500 Series (Disable IGMP snooping, Configure Multicast MAC manually)
Switches
Cisco Catalyst 2900, 3500 Series Nortel BayStack 450 Alteon 180e Dell PowerConnect 3248 and PowerConnect 5224
290
Example configuration of a Cisco Catalyst Routing Switch

The following example shows how to perform the configuration commands needed to support a Connectra cluster on a Cisco Catalyst 6500 Series routing switch. For more details, or instructions for other networking devices, please refer to the device vendor documentation. The example refers to the sample configuration described in Figure 9-3 on page 295.
Disabling IGMP snooping

To disable IGMP snooping run:
no ip igmp snooping
Defining static cam entries

To add a permanent multicast entry to the table for module 1, port 1, and module 2, ports 1, 3, and 8 through 12:
Console> (enable) set cam permanent 01-40-5e-28-0a-64 1/1,2/1,2/3,2/8-12 Permanent multicast entry added to CAM table. Console> (enable)
Determining the MAC addresses which needs to be set is done by using the following procedure: On a network that has a cluster virtual IP address of x.y.z.w: If y<=127, the multicast MAC address would be 01:00:5e:y:z:w. For example: 01:00:5e:5A:0A:32 for 192.90.10.50. If y>127, the multicast MAC address would be 01:00:5e:(y-128):z:w. For example: 01:00:5e:28:0A:32 for 192.168.10.50 (168-128=40 = 28 in hex). For a network x.y.z.0 that does not have a cluster virtual IP address, such as the sync, you would use the same procedure, and substitute fa instead of 0 for the last octet of the MAC. For example: 01:00:5e:00:00:fa for the 10.0.0.X network.
Chapter 9
Disabling Multicast limits

To disable multicast limits run: no storm-control multicast level
Configuring a static arp entry on the router

To define a static arp entry, run: arp 192.168.10.50 01:00:5E:28:0A:32 arpa Determining the MAC address is done using the procedure described in Defining static cam entries.
Disabling Multicast packets from reaching the router

To prevent multicast packets from reaching the router, run: set cam static 01:00:5E:28:0A:32 module/port Determining the MAC address is done using the procedure described in Defining static cam entries.
292
Basic Connectra Cluster Configuration
Basic Connectra Cluster Configuration

In This Section
Cluster Configuration Deployment Tips Configuring Cluster Member IP Addresses If the Switch is Incapable of Forwarding Multicast page 293 page 294 page 294
SmartDashboard Configuration of a Single Cluster Interface Cluster page 295 Adding a Server Certificate to a New Cluster Member page 301
Cluster Configuration Deployment Tips

The following points will help you understand the process of configuring a Connectra gateway cluster, in order to make it a successful and trouble free process.
Licensing
Ensure all cluster members are licensed for the same number of users. They do not necessarily have to have identical licenses. Connectra cluster members must run the same software version.
Cluster and Cluster Member Interfaces

Communication into the organization for users is done using the virtual IP address of the Cluster Interface, and not the member IP addresses. To change the configuration of a cluster member, connect to it directly using the IP address of the cluster member, and not to the virtual IP address of the Cluster Interface.
Interface Configuration
The synchronization interfaces of the cluster members reside on the SAME subnet. The data interfaces of the cluster members must reside on the SAME subnet, DIFFERENT from the synchronization subnet. Use different interfaces for the data and synchronization networks. The recommended setting is to use eth0 for data and eth1 for synchronization.
Chapter 9
Configuring Cluster Member IP Addresses
Physical Connectivity
Synchronization in a two-member cluster can be done using a cross-cable between the two members. A cluster with more than two members requires a switch/hub for synchronization.
Configuration
Cluster member clocks must be synchronized. Use an NTP server or manually synchronize the clocks. Connectra clients access Connectra via two IP address/port combinations: one for the Connectra portal and another for SSL Network Extender. If you wish to use the same IP address for both, configure the portal to listen on port 443 and SSL Network Extender to listen on port 444.
Administration
Cluster members become active after the Security Policy is installed.
Configuring Cluster Member IP Addresses

Using the local administration Web GUI, connect to each cluster member in turn and define IP addresses for each interface. For example, in Figure 9-3 on page 295: On Member_A-1 configure the synchronization interface Sync_IF with address 10.10.0.3, and the data interface Data_IF with address 192.168.10.3. On Member_B-1 configure the synchronization interface Sync_IF with address 10.10.0.4, and the data interface Data_IF with address 192.168.10.4.
If the Switch is Incapable of Forwarding Multicast

If the switch that connects the Connectra cluster members is incapable of forwarding multicast, it is possible, though less efficient, for the switch to use broadcast to forward traffic. The Cluster Control Protocol (CCP) on the cluster members uses multicast by default, because it is more efficient than broadcast. To toggle the CCP mode between broadcast and multicast, use the following command on each cluster member:
cphaconf set_ccp broadcast/multicast
294
SmartDashboard Configuration of a Single Cluster Interface Cluster

This procedure describes how to configure a Load Sharing or High Availability Connectra cluster. In SmartDashboard you need to create and edit a Connectra cluster object, set up Secure Internal Communication (SIC) between cluster members, and define the topology for both cluster and cluster members. Figure 9-3 is used to illustrate the configuration steps. It relates the physical cluster topology to the required SmartDashboard configuration. Figure 9-3
Connectra Cluster with a Single Cluster Interface Topology Configuration
To configure a Connectra cluster with a single cluster interface, proceed as follows: Define a new Connectra cluster object. Go to the SmartDashboard Connectra tab, and in the Connectra Gateways page select New > Connectra Cluster.
Connectra Cluster General Properties Page

Go to the General Properties page of the Connectra Cluster object.
Chapter 9
Figure 9-4
General Properties Page of the Connectra Cluster Object
Fill in the fields on the page: IP address of the Connectra cluster. Use the main cluster virtual IP address, such as the portal virtual IP address used in Portal page. Version of Connectra. The same version must be installed on all the cluster members. OS is the Operating System. All cluster members must have the same OS.
Connectra Cluster Cluster Members Page

1. Go to the Cluster Members page.
296
Figure 9-5
2. Click Add... to add cluster members to the cluster. Cluster members exist solely inside the Gateway Cluster object. For each cluster member: In the Cluster Members Properties window define a Name and IP Address. Choose an IP address that is routable from the SmartCenter server so that the Security Policy installation will be successful. This can be an interface used in the cluster, or a dedicated management interface. Click Communication, and Initialize Secure Internal Communication (SIC). Enter the same Activation Key used when performing initial configuration of the newly installed Connectra gateway (in the Establish trust with a SmartCenter server section of the First Time Configuration Wizard.
Connectra Cluster ClusterXL Page

Go to the ClusterXL page
Chapter 9
Figure 9-6
Fill in the fields on the page:
Cluster Mode
High Availability allows organizations to maintain a connection when there is a failure in a cluster member, without Load Sharing between cluster members. Only one machine is active (Active/Standby operation). Load Sharing distributes traffic within a cluster of gateways so that the total throughput of multiple machines is increased. All functioning machines in the cluster are active, and handle network traffic (Active/Active operation). If any cluster member becomes unreachable, transparent failover occurs to the remaining operational cluster members, thus providing High Availability. All connections are shared between the remaining cluster members without interruption.
Upon Cluster Member Recovery

In a Load Sharing configuration, when the failed Gateway in a Connectra cluster recovers, all sessions are redistributed among all active members. In a High Availability configuration Upon Cluster Member recovery, the options are: Maintain current active Cluster Member. This is the recommended if all members are equally capable of processing traffic, in order to minimize the number of failover events. Switch to higher priority Cluster Member. This mode is recommended if one member is better equipped for handling connections, so it will be the default cluster member.
298
Connectra Cluster Topology Page

1. Go to the Topology page. Here you define the virtual cluster IP addresses, the cluster member networks, and at least one synchronization network. 2. Click Edit Topology. The Edit Topology window for the example in Figure 9-3 on page 295 is as follows: Figure 9-7
Edit Topology Page Example- Single Cluster Interface
3. In the cluster member interfaces columns (with the symbol), define the topology for each cluster member interface. To automatically read the interface settings for a member, click Get Topology at the top of a column. To automatically read the interface settings for all members, click Get all members topology. 4. In the cluster interfaces column (with the symbol), define the topology for each virtual cluster interface. To automatically define the cluster interfaces, click Copy topology to cluster interfaces. Alternatively, in a virtual cluster interface cell, right click and select Edit Interface. The Interface Properties window opens. Name the virtual interface, and define an IP Address (in Figure 9-3 on page 295, 192.168.10.50). In the Member Networks tab, define the member network and its netmask if necessary.
5. In the Network Objective column, define the purpose of the network by choosing one of the options from the drop-down list 6. To define a new network, click Add Network.
Chapter 9 Connectra Gateway Clusters 299
The Network Objectives are explained in the following table: Network Objective Single Cluster Interface Meaning This network contains IP addresses of the: Cluster interface (virtual interfaces that represent the cluster as a whole, rather than the individual cluster members). Cluster member machine interfaces in the same direction as the cluster interface. A cluster interface with two IP addresses. (A cluster interface represents the cluster as a whole, rather than the individual cluster members). A Dual Cluster Interface is required where the Connectra user portal and SSL Network Extender have different IP addresses (in which case they must be in the same subnet and use the same port). Having separate IPs for the portal and for SSL Network Extender is useful to allow access to clients that are in locations which prevent client access to port 444, and only allow access to port 443. Sync Non-Monitored Private Cluster member machine interfaces in the same direction as the Dual Cluster Interface.
Dual Cluster Interface
This network contains IP addresses of:
To add a Dual Cluster Interface, Click to Edit and enter a name and IP for each IP address. This is a synchronization network. It is recommended that a secure and dedicated network is used for synchronization. VLANs cannot be used in the synchronization network.
This network is not cluster related.
300
Adding a Server Certificate to a New Cluster Member
Connectra Cluster SSL Clients Page and Portal Page

1. In the SSL Clients page, configure the Service (TCP port) and Machine interface (IP address) on which the Connectra cluster listens for SSL client traffic. 2. In the Portal page, configure the Service (TCP port) and Machine interface (IP address) on which the Connectra cluster listens for portal traffic. For background information see SSL Client and Portal Connectivity in a Cluster on page 275. For the deployment in Figure 9-3 on page 295, the settings are as shown in Figure 9-8: Figure 9-8
Listening for SSL Client and Portal Traffic- Single Cluster Interface
Connectra Cluster Completing the configuration

1. Configuring logging from the Connectra cluster to a Log Server and/or SmartCenter. Use the Logs and Masters pages. The procedure is the same as configuring logging from a VPN-1 gateway. For details, see the Tracking Configuration section of the SmartCenter Administration Guide. 2. Define the other pages in the cluster object as required (NAT, Certificates, SmartDefense, and so on). 3. Install the Security Policy on the cluster.

Add an Internally Signed Certificate to a New Cluster Member
1. Go to $CVPNDIR/var/ssl on the new cluster member. 2. Delete all the server*.* files. 3. In SmartDashboard install the Security Policy on the Connectra Cluster.
Chapter 9
Add an Externally Signed Certificate to a New Cluster Member

1. Go to $CVPNDIR/var/ssl on an existing cluster member. 2. Copy all the server*.* files. 3. Copy the files to the same location on the new cluster member. 4. On the new cluster member run cvpnrestart.
302
Advanced Connectra Cluster Configuration
Advanced Connectra Cluster Configuration

In This Section
SmartDashboard Configuration of a Dual Cluster Interface Cluster page 303 IP Address Migration page 306 Changing the IP Address of a Connectra Cluster or Single Gateway page 306 Setting Up the Default Gateway if the Virtual IP is on a Different Subnet than the Physical IPs page 307 Removing a Member from a Cluster page 307
SmartDashboard Configuration of a Dual Cluster Interface Cluster

A Dual Cluster Interface is required where the Connectra user portal and SSL Network Extender have different IP addresses (in which case they must be in the same subnet and use the same port). Having separate IPs for the portal and for SSL Network Extender is useful to allow access to clients that are in locations which prevent client access to port 444, and only allow access to port 443. However, in this case, an additional publicly routable IP addresses is required for the Connectra cluster. Figure 9-9 is used to illustrate the configuration steps. It relates the physical cluster topology to the required SmartDashboard configuration.
Chapter 9
Figure 9-9
Connectra Cluster with a Dual Cluster Interface Topology Configuration
To configure a Connectra cluster with a Dual Cluster Interface, follow the procedure described in SmartDashboard Configuration of a Single Cluster Interface Cluster on page 295, with the differences illustrated in the following figures.
304
Figure 9-10 General Properties and Cluster Members Pages- Dual Cluster Interface
Figure 9-11 Edit Topology Page Example- Dual Cluster Interface
Chapter 9
IP Address Migration
Figure 9-12 Listening For Traffic- SSL Clients and Portal Pages- Dual Cluster Interface
IP Address Migration
If you wish to provide High Availability or Load Sharing to an existing standalone Connectra gateway configuration, it is recommended to take the existing IP addresses from the current gateway, and make these the cluster virtual addresses, when feasible. It is possible to define a one member Connectra cluster as part of the migration to clustering.
Changing the IP Address of a Connectra Cluster or Single Gateway

To change the IP address of a standalone Connectra gateway or a Connectra cluster:
At the local machine

1. Log in to the Connectra local Web interface using the IP address of the Connectra gateway. 2. Select Device > Network > Connections. 3. Click the name of the interface you want to change. 4. Enter the new IP address in the IP Address field. Click Apply.
Using SmartDashboard
Edit the Connectra object or the Connectra cluster object, and update the IP address in the following pages: General Properties Cluster Members (Connectra cluster only) Topology
306
Setting Up the Default Gateway if the Virtual IP is on a Different Subnet than the Physical IPs
SSL Clients Portal
Setting Up the Default Gateway if the Virtual IP is on a Different Subnet than the Physical IPs
When Connectra is set up as a cluster, the Cluster Interface (virtual) IP address may have to be defined on a subnet that is different from the ones on which the cluster member physical IPs are defined. If the default gateway resides on the subnet of the virtual IP address, its subnet is also different from the subnets of the physical IP, and must be defined as follows: Perform the following on each cluster member in turn: 1. Log in to the Connectra local Web interface. 2. In the Device > Network > Routing page, define a new network routing rule (New > Route) to the desired subnet. Define the fields as follows: Destination IP address is the IP address of the desired subnet. Destination Netmask is the netmask of the desired subnet. Interface is the interface that should be used to access the default gateway Gateway should be left empty. Important! Metric should be kept as the default value.
3. Click Apply. 4. Define the new default gateway (New > Default Route). 5. Click Apply.
Removing a Member from a Cluster

To remove a member from a Connectra cluster: 1. Connect to SmartDashboard. 2. In the Cluster Members page of the Connectra Cluster object, select the desired cluster member and click Remove. 3. From command line of deleted member, run cpconfig. 4. Choose Disable cluster membership for this gateway. 5. Reboot the removed cluster member.
Chapter 9 Connectra Gateway Clusters 307
Removing a Member from a Cluster
308
10 Chapter Troubleshooting Connectra

In This Chapter
Troubleshooting Web Connectivity Troubleshooting Outlook Web Access Troubleshooting File Shares Troubleshooting Citrix Troubleshooting SSL Network Extender Connectivity Ensuring Application Connectivity with Web Intelligence page 310 page 311 page 325 page 326 page 341 page 343
309
Troubleshooting Web Connectivity
Troubleshooting Web Connectivity

Web connectivity issues can occur in Connectra Web Applications, while working with applications that use/require HTTP cookies. This is because some cookies usually forwarded by Microsoft Internet Explorer to a Web server are not forwarded by Connectra in the same scenario. To solve this, see SecureKnowledge solution SK31636.
310
Troubleshooting Outlook Web Access
Troubleshooting Outlook Web Access

Note - This section applies to Outlook Web Access-related issues occurring when working
through Connectra without SSL Network Extender.
If you have problems with Outlook Web Access (OWA) after deploying Connectra: 1. Read the relevant sections in the Connectra administration guide. See Web Applications on page 48. 2. Check the Connectra release notes for additional information. 3. Go over the Troubleshooting Checklist. 4. Look for a description that matches your issues in Common OWA problems on page 312.
Troubleshooting Checklist
Verification
Reproduce the scenario without Connectra and ensure the problem does not occur.
Connectivity
Make sure that: 1. The Connectra machine has a network route to all relevant Microsoft Exchange servers and relevant server ports are accessible. Usually port 80 or 443. HTTP and/or HTTPS protocols must be traversable towards Microsoft Exchange servers. 2. Connectra users have a network route to the Connectra machine.
Configuration
Make sure that: 1. The Outlook Web Access version is supported by Connectra. See Unsupported Feature List on page 312. 2. Client-side browsers are supported by OWA and by Connectra. See Unsupported Feature List on page 312.
Chapter 10
Troubleshooting Connectra 311
Unsupported Feature List
3. OWA Services are configured to use protocols acceptable by the servers in question. For example, if an Exchange server is configured to accept HTTPS traffic only, the corresponding OWA Web application on Connectra must utilize HTTPS. 4. SSL Network Extender is turned off. 5. Security restrictions are disabled. See 3. Security Restrictions on page 318 6. Users are authorized to access all necessary resources. 7. OWA services are configured with correct paths.
Unsupported Feature List

The following OWA features, platforms and product versions are not supported by Connectra: Outlook Web Access (OWA) 5.5. OWA 2000 on Microsoft Exchange 2003. (*) Any OWA version with a non-Internet Explorer browser (See the Tip -). (*) Outlook Mobile Access.
(*) These products and platforms have not been tested with Connectra. However, Connectra has been successfully integrated in such environments. Tip - According to Microsoft, only the following OWA configuration supports non-IE browsers: OWA 2000 / 2003 running on Microsoft Exchange 2003 using Outlook Web Access Basic scheme.
If you must utilize one of these features, use SSL Network Extender.
Common OWA problems

The following sections describe issues that may arise when browsing to OWA through Connectra. 1. Authentication on page 313 2. Authorization on page 315 3. Security Restrictions on page 318
312
1. Authentication
4. Performance Issues on page 320 5. Saving File Attachments on page 324
Tip -
Check your traffic logs for errors. The logs may help you to pinpoint the problem.
1. Authentication
After users log in to Connectra, and attempt to access an OWA application, they are required by OWA to provide authentication credentials. Outlook Web Access has two authentication schemes: the regular HTTP-based authentication (HBA), which is the default, and Form-Based authentication (FBA). In addition, Connectra supports single sign-on (SSO) through HBA. Hence, there are three possible authentication schemes when accessing OWA through Connectra.
In This Section
HBA problems FBA Problems Single Sign On Problems page 313 page 314 page 315
HBA problems
If an internal Web Server requests Integrated Windows Authentication (NTLM) or any other HTTP-based authentication, Connectra either displays dialog box requesting login credentials, or tries to use the users portal credentials, depending on the configuration of the Connectra Web application. HBA-related problems may result from: Client-side popup-blocker software The use of IIS web-based password management services
Chapter 10
1. Authentication
Client-Side Popup Blocker Software

Since HBA involves popup windows, it is not unusual for various client-side popup blockers to affect the HBA scheme. Problems of this nature may be manifested through lack of authentication popups. The Connectra user portal may also display various authentication-related error pages. When troubleshooting, disable all popup blocking software to allow the authentication dialog box to appear.
IIS web-based password management services

IIS Web applications (such as Outlook Web Access) can be configured to use IIS Web-based password management services. These services make it possible for users to change their Windows NT passwords via a web server. These services use IIS HTR technology which is known to be vulnerable to attack, and could allow an attacker to run malicious code on the user system. Microsoft has long advocated that customers disable HTR on their web servers, unless there is a business-critical need for the technology (Microsoft Security Bulletin MS02-028: http://www.microsoft.com/technet/security/Bulletin/MS02-028.mspx. In keeping with the Microsoft recommendation, Connectra protects against HTR exploits by default. If you wish to allow the use of the HTR mechanism, disable the htr worm pattern in Web Intelligence General HTTP Worm Catcher protection. Install the Security Policy from SmartDashboard after making these changes.
FBA Problems
Some authentication issues that occur in older versions of Connectra are rectified in later versions. See Authorization Use Case on page 316 for a similar problematic scenario.
314
2. Authorization
Single Sign On Problems

When troubleshooting, eliminate the possibility of Single Sign On problems by removing the OWA user credentials from the credentials list in the Connectra user portal. This changes the authentication scheme to HBA and forces users to re-authenticate.
2. Authorization
The authorization mechanisms of Connectra allow administrators to grant access to various resources on a per-path, per-host and per-port basis. Connectra views Outlook Web Access as a Web application with special properties, connecting to a special web server. Authorization-related problems may result from: 1. Discrepancies in the Configuration of the OWA Web Application versus the setup in Microsoft Exchange server. 2. Alternative References to OWA. 3. Insufficient User permissions or failure to apply pertinent user permissions.
Chapter 10
2. Authorization
User experiences may vary widely. However, most authorization failures will result in the following error page:
Discrepancies in the Configuration of the OWA Web Application

Possible discrepancies may occur in the configuration of the OWA port, protocol or paths versus the setup of the corresponding Microsoft Exchange server. OWA Service must be configured in accordance with the Microsoft Exchange server configuration. Otherwise, Connectra will not be able to authorize access to the application.
Authorization Use Case

A user launches an OWA application, gets to the Form-Based Authentication (FBA) page and authenticates using his/her credentials. Subsequently, the user gets the Access denied page:
Cause:
The Microsoft Exchange server side component (IIS or other) is configured to accept both HTTP and HTTPS traffic, whereas the Connectra OWA Web application is configured to authorize HTTP traffic only.
316
2. Authorization
Explanation:
The Form Based Authentication setting on the Microsoft Exchange server requires clients to use SSL, which means that some server-side component (be it IIS or other) must also accept SSL traffic. The following message is displayed to the Microsoft Exchange administrator upon FBA configuration:
This means that IIS is likely to be configured to work over SSL. However, in complex cases such as SSL encryption being off-loaded to another source, and the IIS server itself allowing HTTP traffic, the Connectra administrator may not be aware of the need to authorize HTTPS traffic. As a result, discrepancies may occur.
Tip -
When FBA is in use, always set the OWA Web application to allow HTTPS traffic.
Solution:
Match the OWA Web application configuration defined on Connectra with actual deployment.
Alternative References to OWA

Some companies access their OWA applications via intermediary web sites. These intermediary web sites might reference the OWA server by its IP(s) or hostname(s). If overlooked, this situation may cause an authorization failure in Connectra, if access to the OWA server was defined using a subset of its IPs or hostnames.
Chapter 10
3. Security Restrictions
User experiences may vary. In some cases the problem may result in a run-time JavaScript error or even apparent halting of OWA (see Insufficient User permissions for more information):
Insufficient User permissions

Unlike in case of Discrepancies in the Configuration of the OWA Web Application, it is possible to encounter authorization problems even though the OWA Service is fully compliant with the configuration of the corresponding Microsoft Exchange server. Usually, such problems are caused by failure to identify the application or site to which the client is trying to connect. This sort of mismatch may occur due to legitimate (but unforeseen) reasons usually caused by mediating parties. Alternative References to OWA are a good example of such legitimate factors. During troubleshooting of such problems, test OWA operation without using any mediator (such as proxies, gateways or web sites).
Connectra utilizes many built-in security features that screen inner networks from external threats. In addition, the Connectra endpoint security features protect the endpoint devices. Occasionally, protection mechanisms may hamper legitimate user activities. To eliminate this possibility, switch off all security features during troubleshooting. Install the Security Policy from the SmartDashboard after making these changes. User experiences may vary widely so they are not detailed here.
318
STEP #1:
To reduce the number of false-positives: In SmartDashboard, in the SmartDefense tab, go to Web Intelligence and turn all Application Layer Protection Level settings to Low. In the ASCII Only Request protection, uncheck Block non ASCII characters in form fields. Install the Security Policy from SmartDashboard.
STEP #2:
If Step #1 did not solve the problem, try the following: Modify the Endpoint Compliance page of the Connectra Web Application to Allow caching of all content. In SmartDashboard, in the Smart defense tab, go to Web Intelligence and In the HTTP Protocol Inspection > HTTP Methods protection, uncheck Block standard Unsafe HTTP methods. In the Malicious Code > General HTTP Worm Catcher protection, disable the htr worm pattern.
Install the Security Policy from the administration portal.
See IIS web-based password management services on page 314 for more details.
STEP #3:
If Step #2 did not cure the problem, try the following steps in order: 1. Switch off all Web Intelligence protections. 2. Switch off all SmartDefense protections. 3. Switch off all Endpoint Security features (in the Connectra tab, under Endpoint Security On Demand > Endpoint Compliance). 4. Install the Security Policy from SmartDashboard.
Chapter 10
4. Performance Issues
Performance issues may occur with OWA for the following reasons: 1. Connectra Logging Issues. 2. OWA over SSL or OWA with Form Based Authentication Enabled. 3. Slow Network Problems. 4. Latency Overhead Problems. 5. Authorization Problems. 6. SSL Time-out Problems.
Connectra Logging Issues

Generation of Debug and Trace logs (that are accessed via the console), and the storage of these log records when they grow too big, may considerably degrade the performance of the machine. Note - Traffic and event logs (that are accessible using the SmartConsole clients) do not
degrade the performance of Connectra.
Solution:
1. Turn off Debug logs and Trace logs. 2. Purge existing Debug logs and Trace logs. To turn off Debug logs and Trace logs: 1. Modify $CVPNDIR/conf/httpd.conf. 2. Set the LogLevel parameter to emerg. 3. Make sure the following lines are commented. Commented lines are preceded by #:
#LoadModule trace_logger /opt/CPcvpn-R66/lib/libModTrace.so #CvpnTraceLogMaxByte 10000000 #CvpnWsDebugSubjects

4. Run the cvpnrestart command 5. Repeat for each Connectra cluster member (if any).
320
To purge existing Debug logs and Trace logs: 1. Empty or delete all httpd*.log files located in $CVPNDIR/log directory 2. Empty or delete the mod_ws.log file located in $CVPNDIR/log directory 3. Empty or delete the mod_ws_boa.log file located in $CVPNDIR/log directory 4. Delete all files located under $CVPNDIR/log/trace_log directory 5. Repeat for each Connectra cluster member (if any).
OWA over SSL or OWA with Form Based Authentication Enabled

The Outlook Web Access service can be configured to work over SSL inside secure networks.
This option is normally used if the Microsoft Exchange server is configured to accept SSL-encrypted traffic (HTTPS). This is the case if OWA is configured to use Form Based Authentication (FBA). Upon enabling FBA, the Exchange administrator is prompted by the IIS to change the Web application to work over SSL. Configuring OWA to use SSL inside secure networks may cause degradation in performance and browsing experience.
Chapter 10 Troubleshooting Connectra 321
With Connectra in such a topology, the amount of SSL negotiations grows considerably. SSL negotiations are very CPU-intensive, hence the performance degradation.
Solution:
Change the topology to use HTTP instead of HTTPS inside secure networks. Use a machine with a faster CPU.
Slow Network Problems

Introducing Connectra into an OWA topology allows users to connect to enterprise resources from remote locations. Users connecting from those locations may be subject to temporary or permanent network problems. The rate of packet loss in those networks can vary widely, as can the throughput.
Latency Overhead Problems

Connectra inspects and modifies all HTTP traffic passing through the gateway. It takes time to process each particular packet of information. There is therefore a difference in latency between connections passing through Connectra and those that do not. The overhead in absolute elapsed time is proportional to the amount of data passed through the network. Latency and therefore performance problems when working through Connectra may be felt in particular by users with large numbers of emails, calendar events, task items and the like.
Solution:
Minimize the latency overhead by increasing the performance of Connectra. You can do this by using a machine with a faster CPU.
Authorization Problems
Problems may occur due to failure to apply proper user permissions. For more details, see the Insufficient User permissions section.
322
SSL Time-out Problems

SSL time-out problems can occur with Internet Explorer while working through Connectra. They can cause slowness and even temporary or permanent unresponsiveness of the browser.
Solution:
Do one of the following 1. If feasible, upgrade Internet Explorer by following the instructions in the relevant Microsoft articles below. 2. Alternatively, configure Connectra so that it does not use keep-alive packets when communicating with those hosts or paths. See the following Microsoft articles for more information: http://telanis.cns.ualberta.ca/ http://support.microsoft.com/kb/183110/ http://support.microsoft.com/?kbid=831167 http://support.microsoft.com/?scid=kb;EN-US;Q305217
To configure Connectra to work without keep-alive packets to specific locations: 1. Supply additional LocationMatch directives for each host used by the Web Application in question. All directives go in the $CVPNDIR/conf/includes/Main.virtualhost.conf file, in the VirtualHost section. For more information, see: http://httpd.apache.org/docs/2.0/mod/core.html#locationmatch
<LocationMatch "CVPNHost=<IP or DNS namedelimited by dots>"> SetEnv nokeepalive </LocationMatch>
For example:
<LocationMatch "CVPNHost=208\.77\.188\.166"> SetEnv nokeepalive </LocationMatch> ........ <LocationMatch "CVPNHost=myhost\.example\.com|CVPNHost=myhost"> SetEnv nokeepalive </LocationMatch>
Chapter 10
5. Saving File Attachments
2. Run the cvpnrestart command. 3. Repeat for each Connectra cluster member (if any).
5. Saving File Attachments

When trying to save a file attachment with Outlook Web Access (OWA), Connectra adds the full path to the file name. For example, the file name appears something like:
Bulletin1H.PDF,CVPNHost=192.168.201.6,CVPNProtocol=http,CVPNOrg=full,CVPN Extension=.PDF
To solve this, configure the Web Application to use Hostname Translation. See Configuring Link Translation on page 242.
324
Troubleshooting File Shares
Troubleshooting File Shares

Connectra gives an informative error message when an attempt to access a file share fails. However, if a user tries to access a share that does not exist on the file server, Connectra cannot always distinguish this error from an Access Denied error. In this case the user may be presented with the credentials input form again, or get an Access Denied error. All connections between a browser and Connectra are made over a secure SSL connection. However when an Internet Explorer browser changes context from Web browsing to file browsing, using the Connectra Windows Explorer viewer, it may warn about using a non secure connection. This warning can be ignored. The Windows Explorer viewer can normally be used for browsing web pages. However, the Connectra SSL Network Extender window may not load properly when using it, and the user may be presented with the Connectra login page. It is recommended to use the Web-based viewer instead. When browsing file shares through the Connectra user portal, users can open most files by clicking them. However, video files with the .wmv extension cannot be opened that way, and must be downloaded to the local desktop and opened from there. When using the Connectra Web-based file viewer, download the file by right-clicking on the file and choosing Save Target As.... When using the Windows File Explorer viewer, download the file by copying or drag-and-dropping it to the local desktop. When accessing files via Connectra, the client application used to view a file depends on the file type. Some file types (such as jpg files) can be configured to be opened by a Web browser. In some client configurations, the result of opening such a file may show the Connectra login page instead of the requested file. If this happens, verify that the client uses the latest recommended browser version including all patches and fixes. Specifically, install Internet Explorer patch Q823353 on the endpoint.
Chapter 10
Troubleshooting Citrix
Troubleshooting Citrix
Note - This Citrix troubleshooting section pertains to Citrix-related issues occurring when
working through Connectra without the use of SSL Network Extender.
If you have any problems with Citrix following the deployment of Connectra, take the following steps: 1. Read the relevant section on Citrix Services. See Understanding Citrix Services on page 66. 2. Read Connectras release notes for additional information. 3. Go over the Troubleshooting Checklist on page 326. 4. Look for problem description in Common Connectra Citrix problems on page 327.
Troubleshooting Checklist
Connectivity
Make sure that: 1. Connectra has a network route to all WI (NFuse) servers intended to be used and relevant server ports are accessible. Usually ports 80 or 443. HTTP and/or HTTPS protocols must be traversable towards WI (NFuse) servers. 2. Connectra has a network route to all MetaFrame servers intended to be used and relevant server ports are accessible. Usually ports 1494 or 2598. ICA protocol must be traversable towards MetaFrame servers. 3. Connectra machine has a network route to all STA servers intended to be used, if any, and port 80 on STA servers is accessible, and HTTP protocol is traversable. 4. Connectra users have a network route to the Connectra machine.
326
Common Connectra Citrix problems
Configuration
Make sure that: 1. Citrix servers and clients are of those versions supported by Connectra. 2. All necessary STA servers are configured with corresponding Citrix Services on Connectra. 3. Connectra's server certificate is issued to Connectra's Fully Qualified Domain Name (such as www.example.com), is properly configured, and is trusted by the client-side.

The following topics describe common issues arising when introducing Connectra into a Citrix topology. 1. Server and Root Certificates 2. Security Restrictions 3. External STA servers 4. Java Packages 5. JVM Environments 6. Published Links to Web Content page 327 page 333 page 333 page 335 page 338 page 338
1. Server and Root Certificates

When introducing Connectra into a Citrix topology, all traffic between ICA clients and Connectra becomes SSL-encrypted. SSL encryption requires the use of server certificates. Independent Citrix Architecture (ICA) requires gateway server certificates to be issued to server's FQDN, and not to IP. Note - To enable Citrix traffic to pass through Connectra, Connectra must utilize a server certificate issued to Connectra's FQDN. Connectra's FQDN must also be routable from the client side. The Windows operating system and many Web browsers come preconfigured with a set of root certificates from reputable Certification Authorities (CAs). The list of trusted CAs installed by default includes, but is not limited to Thawte, VeriSign, GeoTrust, EnTrust.
Chapter 10
Organizations may choose to act as their own CA. To do so, they must install and use their own certificate-generating service. Microsoft provides such a service with Microsoft Certificate Services, an optional Windows component. When using your own certificate server, the responsibility for distributing your CA root certificate to clients falls upon you. Tip Independent Citrix Architecture (ICA) allows automatic root-certificate distribution for Citrix Java clients 8.2 and earlier, deployed through the WI (NFuse) portal.
In such a case, root-certificate distribution becomes transparent for both Connectra administrators and users.
Use case #1 (Server and Root Certificates)

Symptom A user tries to launch a published application by clicking the application icon in the WI (NFuse) portal. During the launch, the user gets one of the following popups:
or
Cause Your Connectra's server certificate is issued to an IP address instead of an FQDN. Solution Make sure Connectra's server certificate is issued to an FQDN that fully matches the FQDN of the Connectra server. Make sure the FQDN of the Connectra server is routable from the client side.
328

Symptom A user tries to launch a published application by clicking the application icon in the WI (NFuse) portal. During the launch, the user gets the following popup:
Cause Your Connectra's server certificate is issued by a private Certification Authority (CA), which is not trusted by the client-side browser. This includes Connectra's self-signed certificate. Solution Set Connectra to use a server certificate signed by a publicly trusted CA. See Obtaining and Installing a Trusted Server Certificate on page 247.

Symptom A user tries to launch a published application by clicking the application icon in the WI (NFuse) portal. During the launch, the progress bar freezes:
Chapter 10
Optionally, followed by the popup:
Cause In order of likelihood: Connectra's server certificate is issued to an FQDN that is not routable from the client side. Connectra's server certificate is issued to an FQDN that does not match the FQDN of Connectra. There is more than one machine with the specified FQDN, either rightfully or due to DNS problems or asymmetric routing problems.
Solution Make sure Connectra's server certificate is issued to an FQDN that fully matches the FQDN of the Connectra server. Make sure that the FQDN of the Connectra server is routable from the client side.

330
Cause Connectra's server certificate is issued to a host-name (such as example) instead of an FQDN (such as www.example.com). Solution Make sure Connectra's server certificate is issued to an FQDN that fully matches the FQDN of the Connectra server. Make sure the FQDN of the Connectra server is routable from the client side.

Cause In order of likelihood: Connectra's server certificate have not yet become valid. This often happens when administrators issue the new server certificate and immediately afterwards try to test valid Citrix operation. Because of small time differences between server and client machines, the certificate may still be considered invalid. Connectra's server certificate is out of date and needs to be renewed.
Solution Make sure your client machines' time and date settings are in synch with Connectra's time & date settings. If necessary, replace Connectra's server certificate with a valid one.
Chapter 10

Cause In order of likelihood: Connectra's server certificate is issued to a host-name host-name (such as example) instead of an FQDN (such as www.example.com). The client-side machine has an unclean environment. For example, ICA Web Client had previously been installed and you are trying to install the ICA Java Client or vice versa.
Solution 1. Make sure Connectra's server certificate is issued to an FQDN that fully matches the FQDN of the Connectra server. Make sure the FQDN of the Connectra server is routable from the client side. 2. Uninstall all Citrix (ICA) clients (from Add >Remove Programs) 3. Delete the browser cache and ActiveX objects (In Internet Explorer, Tools > Internet Options) 4. Remove the \Program Files\Citrix folder 5. Re-deploy the ICA client from the Web Interface (NFuse) server.
332
Connectra utilizes many built-in security features that effectively screen the inner networks from external threats. In addition, Connectra's endpoint security features guard customers' privacy on each particular client device. Note - Occasionally, protection mechanisms may hamper legitimate user activities. In order to eliminate this possibility, Check Point recommends switching off all security features during troubleshooting. User experiences may vary widely so they are not detailed here. Try the following steps in order: 1. Modify the Endpoint Compliance page of the Connectra Web Application to Allow caching of all content. This could be especially helpful in the following cases: when working with non-standard ICA clients. when working with non-standard client versions. when using the MetaFrame Presentation Server Client Packager.
2. Switching off Web Intelligence protections. 3. Switching off SmartDefense protections. 4. Switching off Endpoint Security protections.
3. External STA servers

Connectra supports WI (NFuse) servers configured to work in ticketed mode. This means Connectra can work with external STA servers. Connectra can also work alongside other gateways, such as Citrix Secure Gateway (CSG). Note 1. In order to work with external STA servers and other gateways, Connectra must be configured in a manner similar to the CSG. Specifically, Connectra must know the IDs and the addresses of the STA servers used by each particular WI (NFuse) server. 2. Connectra can work with STA servers via HTTP on port 80 only.
Chapter 10
Use case #7 (External STA servers)

Cause In order of likelihood: Connectra's configuration of the Citrix Service lacks STA server configuration, or the STA configuration is invalid. Connectra encountered a problem while connecting to an STA server The STA protocol version is not supported by Connectra
Solution Make sure Connectra's configuration of the Citrix Service includes STA servers' configuration, exactly matching the configuration of the WI (NFuse) server in question. Make sure all relevant STA servers are up and functioning. Make sure all relevant STA servers are routable from Connectra.
334
Use case #8 (External STA servers)

Cause In order of likelihood: Connectra encountered a problem while connecting to an STA server Connectra's configuration of the Citrix Service has an invalid STA server configuration The STA protocol version is not supported by Connectra
Solution Make sure Connectra's configuration of the Citrix Service includes STA servers' configuration, exactly matching the configuration of the WI (NFuse) server in question. Make sure all relevant STA servers are up and functioning. Make sure all relevant STA servers are routable from Connectra.
4. Java Packages
When using Java clients, it is possible to specify what packages will be used by the Java client. Java packages are modules capable of supporting various added functionalities of the client. For example, SSL/TLS, ICA Encryption, or Seamless Windows. Note - Connectra enforces some of the added functionalities of the Java client, for example, SSL/TLS encryption and ICA encryption. Connectra is capable of adding the enforced packages automatically, however, in various non-standard cases (for example. custom-designed applets), this might not be sufficient.
Use case #9 (Java Packages)

Cause The WI (NFuse) server is configured to deploy ICA Java clients without [some] package. In this example, Java client is lacking the ICA Encryption package. Solution Configure the WI (NFuse) server to deploy ICA Java clients together with the required package.
336
Use case #10 (Java Packages

Symptom A user tries to launch a published application by clicking the application icon in the WI (NFuse) portal. During the launch, Java applet deployment gets stuck:
Cause Causes may vary. In one particular case, the WI (NFuse) server was configured to deploy ICA Java clients without the SSL package. Solution Make sure that WI (NFuse) server is configured to deploy ICA Java clients together with the SSL and ICA Encryption packages. Try selecting all possible packages and then one by one determine which one is lacking.
Chapter 10
5. JVM Environments
When using Java clients, a Java Virtual Machine (JVM) is required to run on the endpoint. Each particular version of Citrix Java client has a certain matrix of JVMs it supports and JVMs it does not support. Each particular JVM may also need to be configured in a certain way, in order for ICA Java client to function properly. When introducing Connectra into a Citrix topology, all traffic between the ICA clients and Connectra becomes SSL-encrypted. This changes the way ICA Java client interacts with a JVM. It might be that particular versions of ICA Java clients must work with a different JVM when utilizing SSL/TLS. Connectra and Citrix administrators should be mindful of this fact and make sure Java clients are able to utilize SSL/TLS before introducing Connectra into Citrix topology. If at any point during Connectras introduction into the Citrix deployment, ICA Java client malfunctions or fails to deploy, make sure the JVM requirements are up to Citrix specifications. Tip According to Check Point findings:
1. Citrix Java clients 8.2 and earlier, utilizing SSL in IE - function only using Microsoft JVM - this is a Citrix restriction, not Connectra's. 2. Citrix Java clients 9.0 and later, utilizing SSL in IE - function only using SUN JVM - this is a Citrix restriction, not Connectra's. 3. Please note that ICA clients 9.x or later are supported only through the use of the SSL Network Extender Network mode client. This is because Citrix changed the underlying communication protocol and canceled backward compatibility.
6. Published Links to Web Content

Citrix allows publishing of applications as well as Web content through URL links. Connectra administrators might not be informed about the nature of applications and/or Web content published by Citrix administrators. This poses a problem since Connectra will not allow any Web content to pass through unless the particular user is granted access to the Web resource. Note - To allow Citrix users to browse to Citrix-published Web content, Connectra
administrators must define special Connectra Web applications.
338
Use case #11 (Published links to Web content)

Symptom A user clicks the aaa icon in the WI (NFuse) portal. The icon is a published URL link pointing to a Web resource on a secure Web Server:
After clicking the aaa icon, the user gets the following window:
Cause The URL under the aaa icon has not been configured as a Web application in Connectra, therefore, access to this URL has been blocked by Connectra.
Chapter 10
Solution Make sure that such URLs are accessible via Connectra by configuring corresponding Web applications in the SmartDashboard Connectra tab.
340
Troubleshooting SSL Network Extender Connectivity
Troubleshooting SSL Network Extender Connectivity

General SSL Network Extender Issues
1. If a connection is made from Internet Explorer via SSL Network Extender to a Web site (including the Connectra administration portal), existing open connections may stop responding. This happens if Internet Explorer is configured to work with an HTTP proxy. To solve this, reload the page from a new browser session. 2. SSL Network Extender does not function properly if SecuRemote/SecureClient software is installed on the endpoint computer and SecuRemote/SecureClient is configured to work in Transparent Mode, and the applications made available by SecuRemote/SecureClient and SSL Network Extender overlap. 3. In order to allow a SharePoint Services application that is accessed via SSL Network Extender to function, turn off the following SmartDefense Web Intelligence > HTTP Protocol inspection protections: ASCII Only Request: Uncheck the Block non ASCII characters in form fields option. HTTP Methods: Ensure the OPTIONs method is not blocked.
SSL Network Extender Application Mode Issues

1. In SSL Network Extender Application Mode, when users launch an application from another application, for example, a Web browser from an email application or a Web browser from Word (clicking on links), if the launching application is already open and was not originally launched by SSL Network Extender Application Mode, the launched application will not be encrypted. To overcome this, you should recommend to users that they ensure an application is closed before launching it from another application. 2. Running the Firefox browser through the SSL Network Extender Application Mode, when another instance of Firefox is already running is not supported. The user must close all other instances of Firefox before launching it through the SSL Network Extender client. 3. When McAfee Anti Virus is installed and the On-Access Scanner McAfee feature is enabled, launching mail applications with SSL Network Extender Application Mode might not work. As a workaround, disable the On-Access Scanner, or use SSL Network Extender in Network Mode.
SSL Network Extender Application Mode Issues
4. When trying to launch the Lotus Notes 6.0 and 6.5 client with SSL Network Extender Application Mode without having the Lotus server configured on the DNS server, a connection will not be established. It is required to have the server configured on the organization's DNS server or in the hosts file on the user's machine. 5. For some applications (Rational ClearQuest is one), connections stay idle for a time, and when communication is resumed after a connection timeout, reset (RST) packets are sent to the client and server. Without this RST they may hang or behave unexpectedly. Connectra records all TCP connections with a certain timeout. The default timeout is one hour. When this timeout is reached, the connection is deleted from Connectra. By default, Connectra does not send a RST packet upon TCP connection expiration. As a workaround, either change this setting so that a RST is sent upon expiration of a connection, or change the timeout for the specific service. To change the setting, follow the instructions in SecureKnowledge solution sk31904.
342
Ensuring Application Connectivity with Web Intelligence

Some Web Intelligence protections prevent the normal operation of certain applications. For example, if Web Intelligence is configured to block HTTP WebDav extensions, Outlook Web Access (OWA) connections are blocked, because OWA inherently uses WebDav. In order to allow those applications to work normally, when Connectra detects connections from those applications, Connectra automatically disables certain protections (if active), as detailed in Table 10-1. When those applications are accessed via SSL Network Extender rather than via the Connectra portal, the Web Intelligence protections that interfere with them are not blocked. It is therefore recommended that end users access their iNotes and OWA applications via Connectra and not via SSL Network Extender. Accessing iNotes and OWA through SSL Network Extender using the default Web Intelligence configuration may cause false positives in Web Intelligence. If users must access those applications through SSL Network Extender, it is recommended to manually disable the protections listed in Table 10-1 for iNotes and OWA. Table 10-1 Automatically Disabled Web Intelligence protections Per Application Detected Connectra Application iNotes File Shares Disabled Protection(s) Cross Site Scripting Command Injection SQL Injection Block WebDAV HTTP methods Block Unsafe HTTP methods (only the OPTIONS, PUT, and DELETE methods are disabled)
Chapter 10
Table 10-1 Automatically Disabled Web Intelligence protections Per Application (continued) Detected Connectra Application File Shares via the Web-based file viewer Outlook Web Access Disabled Protection(s) Web Mail SQL Injection SQL Injection Command Injection, Block WebDAV HTTP methods Block Unsafe HTTP methods (only the OPTIONS, PUT, and DELETE methods are disabled) SQL Injection Command Injection
Note - The HTTP method TRACE is always blocked by Connectra, irrespective of the
protections configured in Web Intelligence.
344
11 Chapter SecurePlatform CLI Reference

In This Chapter
Check Point SecurePlatform Overview Managing SecurePlatform Copying Files Using SCP Secure Shell SecurePlatform Shell Commands page 346 page 347 page 348 page 349 page 350
345
Check Point SecurePlatform Overview
Check Point SecurePlatform Overview

The Connectra gateway utilizes a customized and hardened operating system: Check Point SecurePlatform. The system is pre-configured and optimized to facilitate the task of enabling secure access to remote users, requiring only minimal user input of basic configuration elements, such as IP addresses and routing information An easy-to-use shell provides a set of commands required for easy configuration and routine administration of a security system, including: network settings, backup and restore utilities, upgrade utility, system log viewing and control. A Web interface enables most of the administration configuration, as well as the first time installation setup.
346
Managing SecurePlatform
Managing SecurePlatform
This section provides information on how to manage your Connectra system, using the SecurePlatform Command Shell. The Command Shell provides a set of commands required for configuration, administration and diagnostics of various system aspects. SecurePlatform Command Shell uses standard shell command line editing conventions. SecurePlatform Shell includes two permission levels (Modes): Standard and Expert.
Standard Mode
Standard Mode is the default mode when logging in to a SecurePlatform system. In Standard Mode the SecurePlatform Shell provides a set of commands required for easy configuration and routine administration of a SecurePlatform system. Standard Mode displays this prompt: [hostname]#, where hostname is the host name of the machine.
Expert Mode
Expert Mode provides the user with full system root permissions and a full system shell. Switching from Standard Mode to Expert Mode requires a password. The first time you switch to Expert mode you will be asked to select a password. Until then, the password is the same as the one you set for Standard Mode. To exit Expert Mode run the command exit. Expert Mode displays this prompt: [Expert@hostname]# where hostname is the host name of the machine. Note - Expert Mode should be used with caution. The flexibility of an open shell with a root permission exposes the system to the possibility of administrative errors.
Chapter 11
SecurePlatform CLI Reference 347
Copying Files Using SCP
Copying Files Using SCP

You can use the SCP (SecureCopy) command to copy files to and from SecurePlatform over a secured channel. To copy a file to SecurePlatform you must create the file /etc/scpusers that contains a list of SecurePlatform users who have SCP access to SecurePlatform. This means that a user must first be configured in SecurePlatform before it can be used for SCP, The admin user may be used because it is already defined. Enter each username in a separate line. Note - For more detailed information, refer to the SecurePlatform NGX R65 User Guide.
348
Secure Shell
Secure Shell
Connectra enables SSH access, allowing secured, authenticated and encrypted access to the SecurePlatform system. SSH (or Secure SHell) is a protocol for creating a secure connection between two systems. In the SSH protocol, the client machine initiates a connection with a server machine. The following safeguards are provided by SSH: After an initial connection, the client can verify that it is connecting to the same server during subsequent sessions. The client can transmit its authentication information to the server, such as a username and password, in an encrypted format. All data sent and received during the connection is transferred using strong encryption, making it extremely difficult to decrypt and read.
The SSH service runs by default. Granular control of permitted IP addresses that are allowed access to the SecurePlatform system using SSH can be set using the Connectra administration portal. SSH login is allowed using the Standard Mode account user name and password only.
Chapter 11
SecurePlatform Shell Commands
SecurePlatform Shell Commands

In This Section:
Expert Mode Command Backup and Restore Snapshot Image Management Web Administration Server Control Check Point Commands Network Diagnostics Commands page 350 page 350 page 351 page 352 page 353 page 354
This section describes commonly used SecurePlatform shell commands. These commands are required for configuration, administration and diagnostics of various system aspects. Note - All commands are case sensitive.
Expert Mode Command

Switch from Standard Mode to Expert Mode.
Syntax expert Description

After issuing the expert command supply the expert password, after password verification you will be switched into expert mode.
Backup and Restore

Connectra provides a command line or Web GUI capability for conducting backups of your system settings and products configuration. The backup utility can store backups either locally on the SecurePlatform machine hard drive or remotely to a TFTP server or SCP server. The backup can be performed on request, or it can be scheduled to take place at set intervals. The backup files are kept in tar gzipped
350
Snapshot Image Management
format (.tgz). Backup files saved locally are kept in /var/CPbackup/backups. The restore command line utility is used for restoring SecurePlatform settings and/or product configuration from backup files. Note - Only administrators with Expert permission can directly access directories of a Connectra system.
backup
Backup the system configuration. The backup command, run by itself, without any additional flags, will use default backup settings and will perform a local backup. Syntax:
backup [-h] [-d] [--purge DAYS] [--sched [on hh:mm <-m DayOfMonth> | <-w DaysOfWeek>] | off] [[--tftp <ServerIP> [<Filename>]] | [--scp <ServerIP> <Username> <Password> [<Filename>]] | [--file <Filename>]]
restore
Restore the system configuration. Syntax:
restore [-h] [-d][[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]
Snapshot Image Management

The snapshot utility makes it possible to take a snapshot image of the entire system, and to restore the system from the previously created snapshots. The system can be restored at any time. At boot time the user is given the option of booting from any of the available snapshots. This feature greatly reduces the risks involved in configuration changes. The snapshot and revert commands can use a TFTP server, SCP Server to store snapshots, or snapshots can be stored locally.
snapshot
This command creates a snapshot file. The snapshot command, run by itself, without any additional flags, will use default backup settings and will create a local snapshot.
Chapter 11
Web Administration Server Control
Syntax:
snapshot [-h] [-d] [[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]
revert
Reboot the system from a snapshot file. The revert command, run by itself, without any additional flags, will use default backup settings and will reboot the system from a local snapshot. Syntax:
revert [-h] [-d] [[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]
Web Administration Server Control

cpadmin
In SecurePlatform expert mode, you can start, stop and restart the Web administration server that manages the Connectra administration portal. Syntax:
cpadmin { start | stop | restart }
cpadminip
In SecurePlatform expert mode, you may limit access of administrators to specific IPs or networks. Note - In SecurePlatform machines, SSH access to the Connectra gateway is also governed
by this setting.
Syntax:
cpadminp { -add | -rem | -allowAll | -print}
352
Check Point Commands
Parameters: Table 11-1 cpadminip Parameters parameter meaning Adds an IP or network to the list of allowed addresses. Removes an IP or a network from the list of allowed addresses. If True, would allow to connect from any address. If False, would allow only addresses, specified in the list of allowed addresses. Shows the allowed IPs (all, or a list).
-add -rem -allowAll
-print
Check Point Commands

The following commands start and stop all Connectra module processes (not including the Web administration server).
cpstart
cpstart starts all the Check Point applications running on a machine (other than cprid, which is invoked upon boot and keeps on running independently). cpstart implicitly invokes fwstart (or any other installed Check Point product, such as etmstart and uagstart).
When this command is invoked from an SSH shell prompt, the connection to Connectra is reset, because the resulting policy installation resets all connections to the machine. Syntax: cpstart
cpstop
cpstop stops all the Check Point applications running on a machine (other than cprid, which is invoked upon boot and keeps on running independently). cpstop implicitly invokes fwstop (or any other installed Check Point product, such as etmstop and uagstop).
Syntax: cpstop
Chapter 11
Network Diagnostics Commands
cplic
Show, add or remove Check Point licenses. Syntax: cplic { put | del | print | check }
Network Diagnostics Commands

ping
send ICMP ECHO_REQUEST packets to network hosts. Syntax:
ping [-dfnqrvR] [-c count] [-i wait] [-l preload] [-p pattern] [-s packetsize]
354
SecureClient Mobile - VPN Client
Chapter Introduction to SecureClient Mobile

In This Chapter
SecureClient Mobile Overview SecureClient Mobile Features Security Policies and Central Enforcement Clustered Gateway Support
12
page 358 page 360 page 361 page 362
357
SecureClient Mobile Overview

SecureClient Mobile is a client application for mobile devices that includes a VPN and a firewall. SecureClient Mobile enables easy customization and central management and enforcement. SecureClient Mobile's VPN is based on SSL (HTTPS) tunneling and enables handheld devices to securely access resources behind Check Point gateways. The administrator defines the list of networks and hosts accessible for the client once connected to the gateway. This list, the encryption domain, or VPN domain, is downloaded to the client after the initial connection and is used by the client to define what network traffic should be tunneled, encrypted to the gateway, and what traffic should not. SecureClient Mobile retains the details of the gateways to which it was previously connected. This enables users to more readily access a gateway without having to re-enter the gateways information. Upon authentication, the client is assigned a session ID that is valid for a configurable duration. During this time if the client's VPN connection drops, such as when entering an elevator, the client uses its session ID to seamlessly reconnect the VPN tunnel and maintain connections above the VPN tunnel. The same occurs when the user moves Internet connectivity between interfaces, such as from GPRS/UMTS to WiFi. SecureClient Mobile has the following two modes of operation: Enforcement Mode: When SecureClient Mobile connects to a gateway with a SecureClient Mobile license, it downloads a set of policies. The client then enforces these policies on the device, even when no longer connected to the gateway. Gateway policies can be centrally managed by a SmartCenter server or Provider-1, or can be configured directly on the gateway. Connectivity Mode: For backwards compatibility, SecureClient Mobile can securely connect to gateways that either cannot be configured for SecureClient Mobile, or do not have a SecureClient Mobile license. The client does not download policies, but uses a set of policies predefined upon client installation (see SecureClient Mobile Package Management on page 425). The client works with any gateway configured for SSL Network Extender Network mode (available on VPN-1 Pro R55 HF10 versions and above, and on Connectra 2.0 versions and above). This mode enables a subset of the client features without upgrading corporate infrastructure. SmartDashboard configuration options are those of SSL Network Extender, not of SecureClient Mobile.
358
Note - If the gateway is a Connectra NGX R66, SecureClient Mobile cannot connect at all unless the gateway is configured for SecureClient Mobile support (see Setting Up SecureClient Mobile Support for Connectra Gateways on page 366) and is not affected by the Endpoint Security On Demand and Secure Workspace settings. In this case, if the gateway is licensed for SecureClient Mobile, enforcement mode is available. If the gateway is not licensed for SecureClient Mobile, enforcement mode is not available, but SecureClient Mobile will be allowed to connect to the gateway. All configuration instructions in this book are for Central Enforcement. For information on configuring SSL Network Extender on a VPN-1 gateway, see the VPN Administration Guide. For information on configuring SSL Network Extender on a Connectra gateway, see the Connectra Web Security Gateway Administration Guide. In a Central Managed deployment, the enforcement policy is defined centrally on the SmartCenter or Provider-1 CMA, using SmartDashboard, and the enforcement policy is installed from there onto the gateways.
Chapter 12
Introduction to SecureClient Mobile 359
SecureClient Mobile Features
SecureClient Mobile Features

SecureClient Mobile has the following features: Secure Connectivity: Secure connectivity is guaranteed by the combination of authentication, encryption and data integrity procedures employed for every connection. Personal Firewall: Prevents unwanted connections to and from the device. Interface Blocking: The SecureClient Mobile client can be configured to block or allow traffic granularly for each interface (such as wireless and bluetooth) on the device. Application Versatility: SecureClient Mobile can access the organization from various locations, even if it is behind a NAT device, proxy or firewall. The range of available applications includes web, mail-push, VoIP, and file sharing applications, in addition to other more specialized applications. Central Management and Enforcement: Policies can SmartDashboard and installed on multiple gateways SecureClient Mobile units when they connect to the policies can also be deployed through Over The AIR be configured centrally in to be enforced on gateway. Configured (OMA DM) systems.
Seamless Connectivity: If SecureClient Mobile's VPN connection drops, such as when entering an elevator, or the user moves Internet connectivity between interfaces, the client seamlessly reconnects the VPN tunnel. Automatic Connectivity: SecureClient Mobile can be configured to automatically connect to the last-connected gateway, to initiate a dialup connection in the absence of another Internet connection, or to connect to a gateway upon application request. Usability: SecureClient Mobile menus and visual elements are designed for user friendliness, minimal user intervention, and seamless connectivity. API: SecureClient Mobile can respond to third-party applications through a programmable and extensible interface.
360
Security Policies and Central Enforcement
Security Policies and Central Enforcement

SecureClient Mobile supports several centrally managed policies that define the behavior of the client through sets of properties. When the client connects to the organization's gateway to establish a VPN tunnel, the policies are downloaded to the device and enforced by the client. The policies that are actually enforced by the client are those downloaded from the last connected gateway and they are enforced regardless if the client is currently connected, or not. The administrator may wish to enforce on the clients some of the properties, while others may be left for the end user to define. This is enabled by the Configured on endpoint client option available in most of the properties that can be applied to the client. If the gateway does not offer the client to download policies (see SSL Network Extender mode above) then the client enforces the packaged predefined policy. If that policy does not exist it enforces a Master non-configurable pre-defined policy. The client updates its policies each time it connects to a gateway. A timeout is applied for policy validity, after which the client polls the gateway for an updated policy.
Chapter 12
Introduction to SecureClient Mobile 361
Clustered Gateway Support
Clustered Gateway Support

SecureClient Mobile supports two methods for high availability and load sharing. Clustering: Two or more gateways are logically placed behind one IP address providing full session continuation and load balancing in case of hardware failure. DNS based clustering: Two or more gateways that provide the same topology and named with one DNS name. SecureClient Mobile can resolve a DNS name to all of its IP addresses. SecureClient Mobile can attempt to connect to up to 10 IP addresses per DNS name. SecureClient Mobile attempts to connect to each IP address until it succeeds. Support for this feature is transparent to any algorithm used by the DNS server for load sharing or priority ordering (e.g Round Robin) enabling effective load-sharing. Note - SecureClient Mobile does not support traditional MEP (Multiple Entry Points), but the equivalent of MEP with fully-overlapping-encryption-domain can be achieved using the DNS based clustering.
362
Chapter SecureClient Mobile Installation and Setup

In This Chapter
Gateway Setup Client Installation
13
This chapter describes how to install SecureClient Mobile in a Check Point VPN-1 and a Connectra environment.
page 364 page 372
363
Gateway Setup
Gateway Setup
In This Section
Overview Requirements for Central Management Setting Up SecureClient Mobile Support for VPN-1 Gateways page 364 page 365 page 367
Setting Up SecureClient Mobile Support for Connectra Gateways page 366
Overview
Gateway support for Central Enforcement for the current version of SecureClient Mobile is built-in on the Connectra NGX R66 gateway, and may be included in future HFAs for other versions of Connectra and for VPN-1 NGX R65 gateways as well. In these deployments, no further gateway setup is required. SecureClient Mobile support can be added to gateways of the following versions: VPN-1 NGX R60 HFA_04 or later VPN-1 NGX R61 HFA_01 or later VPN-1 NGX R62 or later Connectra NGX R62 or later
Install SecureClient Mobile support on these gateways as follows: 1. Obtain a SecureClient Mobile installation zip file. 2. Extract the zip file, and locate the three .ttm files. 3. Copy the three .ttm files to the gateway, into:
$FWDIR/conf
If the filenames already exist on the gateway, replace them with the new ones. 4. Overwrite the .ttm files default values with the values you configured by logging into SmartDashboard and initiating Install Policy on the gateway. Earlier versions of VPN-1 or Connectra do not support Enforcement Mode. However, SecureClient Mobile can connect to these gateways in SSL Network Extender mode. See SecureClient Mobile Overview on page 358 for details.
364
Requirements for Central Management
To change a policy, find the policys property name in the list of properties in Advanced Configuration on page 397. Open the required ttm file and change the default value of the required property. Save the file and install the policy on the gateway. For example, if you want to change the neo_replace_http_proxy (in vpn_client_1.ttm) to have the value of 192.164.111.1, change neo_replace_http_proxy ( :gateway ( :default ("") to :neo_replace_http_proxy ( :gateway ( :default ("192.164.111.1"))).
Requirements for Central Management

Central management (SmartCenter or Provider-1) of SecureClient Mobile enables simple management with SmartDashboard (setup and most authentication, connectivity, and enforcement features) and advanced management with the Database Tool (see Advanced Configuration on page 397). To centrally manage the current versions new features, you must have one of the following: The Connectra NGX R66 Management Plug-in on SmartCenter or Provider-1, with a compatible version of SmartConsole. For details on management versions for which the Plug-in is supported, and for Plug-in installation instructions, see the Connectra NGX R66 Getting Started Guide. A Locally Managed Connectra NGX R66. A SmartCenter server version NGX R65.
If you have lower-version management (SmartCenter or Provider-1), that is capable of managing SecureClient Mobile NGX R65, you will be able to centrally manage only legacy SecureClient Mobile features. Features new to the current version of SecureClient Mobile will not be centrally manageable. With management that does not conform to SecureClient Mobile NGX R65 requirements, you cannot use SmartDashboard to centrally manage SecureClient Mobile at all. Central Enforcement of SecureClient Mobile without appropriate management, or of features that cannot be centrally managed, can be locally configured at the gateway by directly editing gateway TTM files. For details, see Managing Central Enforcement on a Non-Centrally Managed Gateway on page 398. All setup and configuration instructions in this guide assume Central Management capability for the features under discussion, except where specified otherwise.
Chapter 13
SecureClient Mobile Installation and Setup 365
Setting Up SecureClient Mobile Support for Connectra Gateways
Setting Up SecureClient Mobile Support for Connectra Gateways

This section assumes Central Management capability as discussed in Requirements for Central Management on page 365. Otherwise, see SecureClient Mobile Support on a Non-Centrally Managed Gateway on page 397. To configure SecureClient Mobile support, perform the following for each gateway: 1. For a locally managed Connectra NGX R66, in the Connectra tab, go to Additional Settings and select VPN Clients. For other Connectra gateways, in SmartDashboard, in the gateway objects properties, go to Additional Settings and select VPN Clients. 2. In the VPN Clients page, select SecureClient Mobile. 3. In the VPN Clients page, click Advanced, and ensure that Office Mode is configured. Click OK. 4. Install Policy. 5. Configure users in the same manner as Connectra users are configured. For more information on Configuring users, see the Authorization chapter of the Connectra Administration Guide. 6. If your deployment is configured for SecureClient with several gateways and Multiple Entry Points (MEP), note the following: In some configurations the remote-access topology ("domain for remote access") is based on the gateway-to-gateway topology. If there are a number of gateways with non-fully-overlapping encryption domain, this may be a challenge for SecureClient Mobile as the topology downloaded to this client only "knows" of the remote-access encryption domain of the (one) connected gateway. SecureClient Mobile does not in addition support MEP. To overcome this limitation it is recommended to use Hub Mode when connecting to any of the gateways. The client's packets will be routed through the connected gateway to other parts of the network using site-to-site VPN and will be routed to the Internet as necessary. See Routing All Traffic To the Gateway (Hub Mode) on page 388 for details.
366
Setting Up SecureClient Mobile Support for VPN-1 Gateways

This section assumes Central Management capability (SmartCenter or Provider-1) as discussed in Requirements for Central Management on page 365. Otherwise, see SecureClient Mobile Support on a Non-Centrally Managed Gateway on page 397. 1. In the gateway objects General Properties, in Check Point products box, select VPN.
Chapter 13
2. In the navigation tree, select Remote Access. In the Remote Access page, select Support Visitor Mode.
Configuring Visitor Mode does not interfere with regular SecureClient user functionality, but permits SecureClient users to enable visitor mode. 3. In the navigation tree, under Remote Access, select SSL Clients. In the SSL Clients page, select SecureClient Mobile.
368
4. In the navigation tree, select VPN. Click Add, and add the gateway to a Remote Access community.
5. In the navigation tree, select Topology. Configure the VPN Domain in the same way as for SecureClient.For details, see the VPN Administration Guide. Note - To create a different encryption domain for remote access clients that connect to the gateway, click Set domain for Remote Access Community. 6. In the navigation tree, under Remote Access, select Office Mode. Configure Office Mode as described in the Office Mode chapter of the VPN Administration Guide. Note - If the gateway is in a Load Sharing Cluster, only the Manual (IP pool) method is supported. 7. If the gateway is in a Load Sharing Cluster, enable the Sticky Decision Function as follows: a. In the navigation tree, select ClusterXL. b. In the ClusterXL page, click Advanced. c. Select Use Sticky Decision Function. d. Click OK.
Chapter 13
For more information on the Sticky Decision Function, see the ClusterXL Administration Guide. 8. Click OK. 9. Install Policy. 10. Configure users in the same manner as SecureClient users are configured. For more information on configuring users, see the VPN Administration Guide. 11. If the gateway is configured for SecureClient, and you have SCV (Secure Configuration Verification) enforcement configured for SecureClient users, it is necessary to exempt VPN Clients from SCV, as follows: a. In SmartDashboard, from the Policy menu, select Global Properties. b. In the navigation tree, under Remote Access, select Secure Configuration Verification (SCV). c. Click Exceptions. The Secure Configuration Verification Exceptions window opens.
d. Select Do not apply Secure Configuration Verification on SSL clients connections. e. Click OK. 12. SecureClient Mobile uses TCP port 443 (SSL) to establish a secure connection with the VPN, and for remote administration purposes. This may conflict with SecurePlatforms or Nokias web user interfaces. Another port may be assigned to SecureClient Mobile; however, this is not recommended because most
370
proxies do not allow ports other than 80 and 443. Instead, it is recommended that you assign SecurePlatforms or Nokias web user interface to a port other than 443 as follows: On SecurePlatform, do one of the following: To change the WebUI port, run:
webui enable <port number>

(For example: webui enable 4433). To disable WebUI, run:
webui disable
On a Nokia platform, to change a Voyager port run:
voyager e <encryption level> S <port number>

13. Configure authentication, connectivity, security, and other settings as explained in the following chapter, Central Management of SecureClient Mobile on page 377. 14. If your deployment is configured for SecureClient with several gateways and Multiple Entry Points (MEP), note the following: In some configurations the remote-access topology ("domain for remote access") is based on the gateway-to-gateway topology. If there are a number of gateways with non-fully-overlapping encryption domain, this may be a challenge for SecureClient Mobile as the topology downloaded to this client only "knows" of the remote-access encryption domain of the (one) connected gateway. SecureClient Mobile does not in addition support MEP. To overcome this limitation it is recommended to use Hub Mode when connecting to any of the gateways. The client's packets will be routed through the connected gateway to other parts of the network using site-to-site VPN and will be routed to the Internet as necessary. See Routing All Traffic To the Gateway (Hub Mode) on page 388 for details.
Chapter 13
Client Installation
Client Installation
In This Section
Client Deployment Overview Supported Platforms Installation Prerequisites Installing SecureClient Mobile Importing Personal Certificate Uninstalling SecureClient Mobile page 372 page 372 page 373 page 373 page 375 page 375
Client Deployment Overview

SecureClient Mobile is packaged as a self-installing CAB (cabinet) or MSI (Microsoft Installer) file package. Users can install either package without specifying configuration details. This ensures the proper configuration of SecureClient Mobile software. A CAB file package contains compressed files, which are mainly used to distribute software. The CAB file package is installed directly on the mobile device and has a .cab file extension. The MSI package is installed on the user's personal computer and has a .msi file extension. It is used for a silent (unattended) installation. During installation, the CAB file package is extracted from the MSI package and installed on a connected mobile device using ActiveSync services. For more information about client packaging and deployment, see Client Deployment, Repackaging and Upgrading on page 426.
Supported Platforms
An updated list of supported devices and operating systems can be found in the Release Notes for the current version of SecureClient Mobile.
372
Installation Prerequisites
Installation Prerequisites
This prerequisite applies to all previous versions of SecureClient Mobile. Before installing SecureClient Mobile on a Widows Mobile device, you have to install Check Point certificates into the devices Trusted Certificates and SCP Store. This allows the client installer and executables, which are signed by Check Point certificates, to be installed and run. The Check Point certificates are packaged in a small CAB installer that needs to be installed once on the target device before any Check Point product is installed. Install the certificates as follows: 1. Find cpcert.cab in the SecureClient Mobile installation zip file, in the unlock_smartphone directory. 2. Copy cpcert.cab to the device while in ActiveSync. 3. On the device, in File Explorer, tap cpcert.cab . When the installation is complete, a message appears: cpcert.cab was successfully installed on your device. Continue to Installing SecureClient Mobile, below.
Installing SecureClient Mobile

There are two ways to install SecureClient Mobile: Self-installing CAB Package - Install one of the following files directly on the mobile device: SecureClient_Mobile.cab - Windows Mobile 5.0, 6.0 and 6.1 for Pocket PCs and SmartPhones SecureClient_Mobile2003.cab - Pocket PC 2003 Self-installing MSI Package - This file is installed on the users personal computer. During installation, the installer extracts a CAB file package from within the MSI package and installs it on a connected mobile device using ActiveSync services.
Installing a SecureClient Mobile CAB Package

The supplied SecureClient .cab file can be stored anywhere on the mobile device or on an attached storage card. The installation can be automated using configuration tools such as Over The Air (OTA).
Chapter 13
Installing SecureClient Mobile
To install the SecureClient CAB package: 1. On the mobile device, in File Explorer, navigate to the folder where the SecureClient .cab file was placed and tap it. 2. If there is an existing installation of SecureClient Mobile, a message appears that the previous version will be removed. Tap OK to install the new version. Existing configuration settings will be kept for the new version. 3. If prompted to select an installation location, select Device (installing on storage cards is not supported).
4. Tap Install. 5. Tap Yes to reboot.
Installing a SecureClient Mobile MSI Package

The supplied SecureClient .msi file package can be stored anywhere on the PC. The installation can be automated using tools such as Microsoft SMS Server. To install the SecureClient MSI package: 1. On the Windows PC computer, run the SecureClient .msi file . 2. Follow the instructions in the wizard to complete the installation. During installation, the ActiveSync service prompts to install the software on the device.
374
Importing Personal Certificate
If there is an existing installation, a message appears that the previous version will be removed. Click OK to install the new version. Existing configuration settings will be kept for the new version.
Importing Personal Certificate

After installing SecureClient Mobile on the device, import your personal certificate with the following steps: 1. Copy your .p12 file to the My Documents directory on the device. Note - If it is not located in the My Documents directory, you can import the .p12 file by browsing to its location using File Explorer and tapping on it. 2. Tap Menu > Manage... > Certificates > Import. 3. Click on your certificate .p12 file and enter your password.
Uninstalling SecureClient Mobile

To uninstall SecureClient Mobile: 1. If you installed the MSI package on a Windows PC, remove SecureClient Mobile from the PC in Control Panels Add or Remove Programs. 2. On the mobile device, from the Start menu, select Settings. 3. In the System tab, select Remove Programs. 4. Select Check Point SecureClient Mobile and tap Remove.
Chapter 13
Uninstalling SecureClient Mobile
376
Chapter Central Management of SecureClient Mobile

In This Chapter
Introduction Authentication Settings Connectivity Settings Routing All Traffic To the Gateway (Hub Mode) Firewall Policy Configuration and Version Management Certificates Topology Update Advanced Configuration
14
Most configuration procedures in this chapter assume Central Management capabilities. For details, see Requirements for Central Management on page 365.
page 378 page 379 page 383 page 388 page 389 page 392 page 394 page 396 page 397
377
Introduction
Introduction
For all Gateways that support Central Management, the settings of SecureClient Mobile can be configured from the SecureClient Mobile page of the SmartDashboard.
\
In SmartDashboard, the SecureClient Mobile page can be found by going to Global Properties > Remote Access > SecureClient Mobile. When using a SmartDashboard with the Connectra plug-in, the SecureClient Mobile page can also be found by going to the Connectra tab > Additional Settings > VPN Clients and clicking on the SecureClient Mobile Edit... button.
378
Authentication Settings
In This Section
Supported Authentication Schemes Configuring the Authentication Method Password Caching Authentication Timeout page 379 page 380 page 381 page 382
Supported Authentication Schemes

The client supports most of the common authentication schemes supported by Check Point gateways such as Active Directory and RADIUS. There are several ways to authenticate the user and the connected device: Client Certificates (for example, X.509, Smartcards) One Time Password (for example, RSA, SecureID, SoftID) User/Password combinations and multi-challenge-response ("legacy")
A connectivity policy downloaded to the device enables the administrator to define the amount of user interaction required to carry out the authentication process. Some of these schemes can be configured to achieve seamless authentication (no user prompt for credentials): Certificates (through CAPI). User/Pass with credential caching: As long as the password cached, the user is not prompted to re-enter it when the client authenticates. OTP with SoftID and credential caching: The client reads the token code from the SoftID application transparently and the PIN can be cached. Warning - When credential caching is enabled, the password/PIN is stored locally on the device. This poses a security threat because the password can be retrieved if the device is lost, stolen or hacked. Some of these schemes can be configured to provide 2 factor authentication: Certificates with device-login (authenticate user to device login first, then use CAPI installed certificates to authenticate the device to CA), OTP Tokens including SoftID.
Chapter 14
Central Management of SecureClient Mobile 379
Configuring the Authentication Method
Configuring the Authentication Method

For VPN-1 gateways, to configure the authentication method: 1. In the SecureClient Mobile page, select one of the following User authentication methods: Certificate: The system authenticates the user through a certificate. Enrollment is not permitted. Certificate with enrollment: The system authenticates the user through a certificate. Enrollment is permitted. If the user does not have a certificate, enrollment is permitted using a registration key provided by the system administrator. Legacy: The system authenticates the user through their username and password as well as other challenge-response options (for example, SecurID). Mixed: The system attempts to authenticate the user through a certificate. If the user does not have a valid certificate, the system attempts to authenticate the user through one of the legacy methods.
Note - The Certificate with enrollment feature is currently not implemented by the client. It will have the same effect as selecting Certificate option. 2. Click OK and Install Policy. Note - When a gateway is configured for both SecureClient Mobile support and for SSL
Network Extender, the SSL Network Extender setting overrides the SecureClient Mobile setting for that gateway.
SecureClient supports a secure authentication (SAA) OPSEC interface that allows third-party extensions to the standard authentication schemes. For this scheme to work Legacy scheme should be selected here. The neo_saa_guilibs property should also be updated with the SAA DLL name using the GuiDBEdit tool. For additional information, refer to Client-Gateway Authentication Schemes in the VPN User Guide.
380
Password Caching
Note - RSA SoftID is an authentication method that generates a unique, one time passcode every 60 seconds used for secure access over the Internet. The passcode is generated using the PIN and obtained automatically. SecureClient Mobile gets the passcode from SoftID by communicating directly with the SoftID application. The SoftID application must be installed on the device but does not have to be running. When the user has no PIN, either because the tokencard is new or the administrator reset the PIN, the PIN field is left blank. Once logged in, the user is directed to a page that requires a PIN to be created. This PIN is used for subsequent logins. Prior to logging in, the token file (containing the shared token) must be imported into the SoftID application. This file is required for the authentication between the Authentication server (ACE/Server) and the SoftID application. The token file is protected by the pass_phrase. The pass_phrase may be obtained from the system administrator.
Password Caching
You can centrally configure password caching on the SecureClient Mobile devices. With password caching enabled, authentication information is stored on the device, so that a user does not need to manually authenticate each time he or she connects. However, a different user using the device will be automatically authenticated. With password caching, passwords are stored for a configurable duration. Past this time limit, the user is required to re-authenticate upon connection or authentication timeout. To configure password caching: 1. In the SecureClient Mobile page, configure Enable password caching. The following options are available: No: Password caching is disabled. Yes: Password caching is enabled. Configured on endpoint client: The device configuration determines whether password caching is enabled or disabled.
2. If you selected Yes or Configured on endpoint client, configure the caching duration by setting Cache password for in minutes. 3. Click OK and Install Policy. The next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.
Chapter 14
Authentication Timeout
Authentication Timeout
User authentication credentials are only valid for a configurable time duration. Upon timeout, the user is disconnected from the server. SecureClient Mobile checks for authentication credentials (cached or by prompt) five minutes before the session is timed-out. Once these credentials are accepted, the time-out interval is initialized. To configure the timeout duration: 1. In the SecureClient Mobile page, configure a value for Re-authenticate user every ... minutes. 2. Click OK and Install Policy. Note - When a gateway is configured for both SecureClient Mobile support and for SSL
Network Extender, the re-authentication settings will behave according to the following:
VPN-1: If SSL Network Extender is enabled, the SSL Network Extender setting overrides the SecureClient Mobile re-authentication period. Otherwise, the SecureClient Mobile re-authentication period will be applied. Connectra pre-NGX R66: The portal session timeout setting will determine the SecureClient Mobile re-authentication period. Connectra NGX R66: The SecureClient Mobile re-authentication period will be applied. The next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.
382
Connectivity Settings
The following sections describe connectivity features that can be centrally configured and enforced.
In This Section
Connect Mode Automatic Dialup Initiation Automatic Disconnect Encryption Methods page 383 page 385 page 386 page 387
Connect Mode
SecureClient Mobile can be configured to automatically establish the VPN tunnel with the last gateway to which it was connected when one of the following conditions are met: The device has a valid IP address. For example, when turning WLAN/WiFi on. The device exits standby mode or loads after a softreset/shutdown. After a condition that caused the device to automatically disconnect ceases to exist. For example, when the client has automatically disconnected as a result of putting the device in ActiveSync and has then been released from ActiveSync.
This mode of operation is recommended, as it relieves the end user from the need to manually establish the VPN tunnel. Combining this mode with automatic dialup initiation keeps the client connected at all times. This allows push protocols such as VoIP.
Application Request Mode

SecureClient Mobile can be configured to allow traffic from a third-party application to trigger initiation of a VPN connection, in the event that a VPN connection is not already established. When the client Connect Mode is set to On application request, Internet Explorer Mobile and Email traffic, or traffic from another configured application, directed to a server in the encryption domain will trigger SecureClient Mobile to initiate a connection to the gateway so that the traffic reaches its destination server.
Chapter 14
Connect Mode
To configure the SecureClient Mobile connect mode: 1. In the SecureClient Mobile page, configure Connect mode. The following options are available: Manual: Automatic SecureClient Mobile connectivity is disabled. Always Connected: Automatic SecureClient Mobile connectivity is enabled. On application request: When an application opens a connection with a destination in the encryption domain, SecureClient Mobile automatically connects to the gateway. For more information, see Application Request Mode on page 383. Configured on endpoint client: The device configuration will determine which mode will be used.
2. Click OK and Install Policy. The next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.
Application Request Mode - Advanced

The HKLM\Software\CheckPoint\Neo\Hook contains the full list of applications which, by default, can initiate a connection to the gateway. SecureClient Mobile can can be configured to allow other applications to take advantage of Application Request Mode.
Adding an Application to Application Request Mode via the Registry

To manually configure an third-party application for Application Request Mode: 1. Open the Windows Mobile registry. 2. Browse to the HKLM\Software\CheckPoint\Neo\Hook registry key. 3. Add a DWORD value. 4. Enter the third-party applications executable filename as the name of the registry parameter. 5. Enter 1 as the decimal data for the parameters value. 6. Close the Windows Mobile registry. 7. Restart the third-party application.
384
Automatic Dialup Initiation
Adding an Application to Application Request Mode via the Package

A third-party application can be added to Application Request Mode during the installation process for SecureClient Mobile by modifying a file in the installation package. This registry change adding the registry entry to the SecureClient_Mobile_Setup_<build number>.inf in the SecureClient Mobile zip file in the NEO_HOOK_Registry section as follows:
[NEO_HOOK_Registry] HKLM,Software\CheckPoint\Neo\Hook,iexplore.exe,0x00010001,0x1 HKLM,Software\CheckPoint\Neo\Hook,opera.exe,0x00010001,0x1001
add:
HKLM,Software\CheckPoint\Neo\Hook,[executable],0x00010001,0x1001
The registry change can also be included in the _setup.xml file in the SecureClient Mobile cab file as follows:
<characteristic type="HKLM\Software\CheckPoint\Neo\Hook"> <parm name="iexplore.exe" value="1" datatype="integer" /> <parm name="opera.exe" value="1" datatype="integer" />
add:
<parm name="[executable]" value="1" datatype="integer" />
Note - Some applications will require other registry values. If after following the above
procedures your application does not trigger SecureClient Mobile to initiate a connection to the gateway, contact Check Point Support. Some applications may not be compatible with Application Request Mode.
Removing Third-Party Application from Application Request Mode

To manually configure an additional application for Application Request Mode: 1. Open the Windows Mobile registry. 2. Browse to the HKLM\Software\CheckPoint\Neo\Hook registry key. 3. Delete the applications registry parameter or change the registry value to 0. 4. Close the Windows Mobile registry.
Automatic Dialup Initiation

SecureClient Mobile can be configured to initiate a dialup connection (for example, GPRS), if the device is not already connected to the Internet. When enabled, automatic dialup is initiated in the following cases:
Chapter 14 Central Management of SecureClient Mobile 385
Automatic Disconnect
When the user attempts to establish a SecureClient VPN tunnel. When an established dialup connection fails, in which case SecureClient Mobile waits for a configurable time period and, if the problem has not yet been resolved, initiates dialup. The default time period is 10 seconds. To change the time period, see and configure the variable.
When a dialup connection is attempted and fails, SecureClient Mobile makes successive additional attempts, each time after waiting for a configurable time period (see below). Before each subsequent retry, the waiting time is doubled, to a maximum of 60 seconds.
To configure automatic dialup initiation: 1. In the SecureClient Mobile page, configure Automatically initiate dialup. The following options are available: No: Automatic dialup initiation is disabled. Yes: Automatic dialup initiation is enabled. Configured on endpoint client: The device configuration determines whether automatic dialup initiation is enabled or disabled.
2. Click OK, OK, and Install Policy. The next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.
Automatic Disconnect
SecureClient Mobile can also be configured to automatically disconnect when the connection has been idle for a defined duration. The default value is 5 minutes and can be changed by modifying the neo_disconnect_when_idle_timeout property. For more information, see Advanced Configuration on page 397. To configure Automatic Disconnect: 1. In the SecureClient Mobile page, configure Disconnect when device is idle. The following options are available: No: Automatic disconnect is disabled. Yes: Automatic disconnect is enabled.
386
Encryption Methods
Configured on endpoint client: The device configuration determines whether automatic disconnect is enabled or disabled.
2. Click OK and Install Policy. The next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.
Encryption Methods
There are two encryption methods available: 3DES RC4
You can configure SecureClient Mobile to support 3DES only or to support both methods. Note - When a gateway is configured for both SecureClient Mobile support and for SSL Network Extender, the SSL Network Extender setting overrides the SecureClient Mobile setting for that gateway. To configure the encryption method: 1. In the SecureClient Mobile page, configure Supported encryption methods. The following options are available: 3DES only (default) 3DES or RC4
Chapter 14
Routing All Traffic To the Gateway (Hub Mode)
Routing All Traffic To the Gateway (Hub Mode)

You can configure SecureClient Mobile to route all of the devices traffic to the gateway. The gateway acts as a router for the remote client. All connections the client opens, either to the internal network or to other parts of the Internet, pass through the gateway. When traffic from remote access clients is routed to the gateway, it can be filtered, inspected and kept in compliance. The packets are encrypted between the client and the gateway but pass "in clear" between the gateway and the client's peer. If the final destination of the connection is a machine behind another gateway, and a VPN link is defined between both gateways, the connection is routed along this link. To enable Hub Mode: 1. For VPN-1 gateways, in the gateway properties navigation tree, select Remote Access. 2. In the Remote Access page, select Allow SecureClient to route traffic through this gateway. 3. Click OK. 4. For all gateways, in the SecureClient Mobile page, configure Route all traffic to gateway. The following options are available: No: Only traffic whose destination is in the encryption domain will be sent to the gateway. Yes: All traffic will be sent to the gateway. Configured on endpoint client: The device configuration determines whether routing all traffic to the gateway is enabled or disabled.
Note - For more information, see SecureKnowledge solutions sk31873 and sk31367.
388
Firewall Policy
Firewall Policy
SecureClient Mobile includes a built-in firewall, which enforces a downloaded or locally configured security policy. The firewall can separately block or enable different types of traffic: incoming or outgoing, VPN-domain (encrypted) or non-encrypted. The firewall can also block device interfaces, such as PC synchronization, Firewire, and Bluetooth. To configure the Firewall Policy: 1. In the SecureClient Mobile page, under Security Settings, configure Enable Firewall Policy. The following options are available: No: The firewall is disabled. Yes: The firewall is enabled. Configured on endpoint client: The device configuration determines whether the firewall is enabled or disabled.
2. Click Configure.... The Firewall Settings page opens.
Chapter 14
Firewall Policy
3. In the Firewall Settings section, select a Firewall Policy setting. The following options are available: Allow All: All traffic is allowed. The client will still be protected by implicit, non-configurable firewall rules. Outgoing Only: All outbound connections are permitted and all inbound connections are blocked. This policy will prevent incoming connections from being established from both the non-VPN hosts and VPN hosts. Outgoing and Encrypted: Permits incoming and outgoing encrypted traffic to and from the VPN domain. Also permits outgoing non-VPN connections that are initiated from the handheld. This policy is the recommended setting. Allow Encrypted Only: Only VPN traffic originating from or destined to the encryption domain are permitted (and only when the client is connected). Block All: All inbound and outgoing connections are blocked. The device will only be permitted to connect to the Gateway for the purpose of updating the client configuration. Configured on Endpoint Client: The device configuration determines the configuration of the Firewall Policy.
4. Configure Allow sync with PC. The following options are available: No: Connections to a PC with ActiveSync are disabled. Yes: Connections to a PC with ActiveSync are enabled. Configured on endpoint client: The device configuration determines whether PC synchronization is enabled or disabled.
5. Configure Allow VPN connections via PC Sync. The following options are available: No: VPN connections setup through ActiveSync are enabled. Yes: VPN connections setup through ActiveSync are disabled. Configured on endpoint client: The device configuration determines whether VPN connections setup through ActiveSync are enabled or disabled.
6. (Available when using version NGX R66 of SmartCenter and SmartDashboard) To change Interface Blocking settings, select an interface, and click Edit. In the resulting Interface Details window, configure the Interface State.
390
Firewall Policy
For interfaces other than Bluetooth, the following options are available: Disable: The interface is disabled. Enable: The interface is enabled. Configured on endpoint client: The device configuration determines whether the interface is enabled or disabled.
For Bluetooth, the following options are available: Off: The Bluetooth interface is disabled. Discoverable: The device user can initiate a Bluetooth connection, and other Bluetooth devices can discover this device. Connectable: The device user can initiate a Bluetooth connection, but other Bluetooth devices cannot discover this device. Configured on endpoint client: The device configuration determines whether the Bluetooth interface is enabled or disabled .
Chapter 14
Configuration and Version Management

SecureClient Mobile support the use of over the air deployment of client configurations through third-party Open Mobile Alliance (OMA) Device Management (DM) systems. To configure the OMA DM policy: 1. In the SecureClient Mobile page, click on Configuration and Version Management.... The Configuration and Version Management window opens.
2. (Available when using version NGX R66 of SmartCenter and SmartDashboard) Configure Enable over the air (OMA DM) client. The following options are available: No: Use of over the air methods to update client configurations are disabled. Yes: Use of over the air methods to update client configurations are enabled.
3. (Available when using version NGX R66 of SmartDashboard) Configure Enable export of client configuration. GUIdbEdit can be used to configure this setting on previous versions of the VPN-1 gateway. The following options are available: No: VPN connections setup through ActiveSync are disabled. Yes: VPN connections setup through ActiveSync are enabled. Configured on endpoint client: The device configuration determines whether the export of client configurations is enabled or disabled.
392
4. Configure Client upgrade mode. The following options are available: Do not upgrade: Do not upgrade SecureClient Mobile to the latest version available upon establishing a VPN connection. Ask user: Prompt the user to choose whether to upgrade SecureClient Mobile to the latest version available upon establishing a VPN connection. Always upgrade: Upgrade SecureClient Mobile to the latest version available upon establishing a VPN connection.
5. In the Upgrade clients to version field, enter the version number of the client configuration that will be distributed to clients. 6. In the Client download URL, enter the link where clients can download the file needed for the upgrade. 7. Click OK, OK, OK, and Install Policy. The next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.
Chapter 14
Certificates
Certificates
The SmartCenter server uses the same certificate for both SSL Network Extender and SecureClient Mobile clients when SSL Network Extender is enabled. In SmartDashboard, open the gateway object and select Remote Access > SSL Clients. Select the appropriate certificate from the The gateway authenticates with this certificate drop down menu.
Certificate Nickname
To view the certificate nickname: 1. In SmartDashboard, open the VPN tab of the relevant network object. 2. In the Certificates List section, the nickname is listed next to each certificate.
Management of Internal CA Certificates

If the administrator has configured Certificate with Enrollment as the user authentication scheme, the user can create a certificate by using a registration key provided by the system administrator. To create a user certificate for enrollment: 1. Follow the procedure described in The Internal Certificate Authority (ICA) and the ICA Management Tool in the SmartCenter User Guide. Note - In this version, enrollment to an External CA is not supported.
2. Browse to the ICA Management Tool site, https://<mngmt IP>:18265, and select Create Certificates. 3. Enter the username, and click Initiate to send a registration key to the user. When the user connects using SecureClient Mobile without a certificate, the Enrollment window opens, and the user can create a certificate by entering the registration key they received from the system administrator.. Note - The system administrator can direct the user to the URL, http://<IP>/registration.html, to receive a registration key and create a certificate even if
they do not wish to use the SSL Network Extender at that time.
394
Importing a Certificate in the Device
Importing a Certificate in the Device

To import a certificate using SecureClient Mobile, the certificate must already be on the Pocket PC and located in the My Documents directory. To import a certificate: 1. Tap Menu > Manage... > Certificates > Import. 2. Tap the certificate to be imported. 3. Enter the certificate password. The Import issuer to Root CA checkbox should be selected to import the certificate of the CA that issued the certificate being imported. It is recommended to use this feature when user certificates and server certificates are issued by the same CA, such as in the case of a Check Point internal CA. 4. Tap OK. A window opens stating that the certificate was imported successfully. 5. Tap OK. Certificates can be viewed by tapping Menu > Manage... > Certificates > View or by tapping Start > Settings > System tab > Certificates.
Chapter 14
Topology Update
Topology Update
When SecureClient Mobile clients connect to a VPN-1 gateway, topology updates are downloaded or updated to the client automatically each time a user connects to a gateway, and when a user reconnects after an authentication timeout occurs. It is also updated on a regular basis, as defined by the administrator. To define the frequency with which updated site details are downloaded to the client: 1. In SmartDashboard, select Policy > Global Properties > Remote Access. 2. In Topology Update, select Update topology every ... hours. 3. Enter the frequency (in hours) with which the policy should be updated.
396
Advanced Configuration
Advanced Configuration
In This Section
Configuring a Non-Centrally Managed Gateway SecureClient Mobile Database Properties page 397 page 399
Configuring a Non-Centrally Managed Gateway

This section describes setup and configuration for gateways that are not Centrally Managed. For Central Management requirements, see Requirements for Central Management on page 365.
SecureClient Mobile Support on a Non-Centrally Managed Gateway

To enable SecureClient Mobile support: 1. From the command prompt, run #ckp_regedit -a SOFTWARE\\CheckPoint\\VPN1 neo_enable 1. 2. Run cpstop and cpstart. To disable SecureClient Mobile support: 1. From the command prompt, run
#ckp_regedit -d SOFTWARE\\CheckPoint\\VPN1 neo_enable

To configure a certificate to be used by gateway SSL (only if SSL Network Extender is disabled), proceed as follows: 1. Add the neo_gw_certificate key to SOFTWARE/CheckPoint/VPN1 in the registry on each gateway. To add the certificate, run the following command from the command prompt:
#ckp_regedit -a SOFTWARE/CheckPoint/VPN1 neo_gw_certificate "cert_nickname"

To remove the certificate, run the following command from the command prompt:
#ckp_regedit -d SOFTWARE/CheckPoint/VPN1 neo_gw_certificate

If SSL Network Extender is disabled, and no certificate for SecureClient Mobile clients is defined, a certificate issued by the internal CA is used.
Chapter 14
Configuring a Non-Centrally Managed Gateway
Managing Central Enforcement on a Non-Centrally Managed Gateway

The policy is defined on each gateway individually using the TTM (Transform Template) files. TTM files are found on each gateway in the $FWDIR/conf folder. Note - Edit TTM files directly only when appropriate central management (SmartCenter or
Provider-1) is unavailable. Otherwise, your changes may be overwritten at Install Policy. For details on appropriate central management, see Requirements for Central Management on page 365.
There are three TTM files on each gateway. The configurable variables in each file are listed in a separate table, located in the previous section:
vpn_client_1.ttm in Table 14-1 fw_client_1.ttm in Table 14-3 neo_client_1.ttm in Table 14-4
To configure the security policy using TTM files: 1. Open a TTM file using any text editor. 2. Set the default value for the property you are changing. For example: :neo_request_policy_update ( :gateway ( :default (true)))
or
:neo_request_policy_update ( :gateway ( :map ( :false (false) :true (true) :client_decide (client_decide) ) :default (true) ) )
3. Change the default setting, true, to create a new default setting for the security policy. 4. Save the file and select install policy. 5. The following property is used to set the policy expiration timeout for all policies, except the firewall policy: :expiry ( :gateway ( :default (100))). The following property is used to set the firewall policy expiration timeout: :expiry ( :gateway (neo_policy_expire :default (100))).
398
SecureClient Mobile Database Properties

Additional client attributes can be configured with the Check Point Database Tool. See the following tables for the available configuration variables: Table 14-1 VPN Properties Table 14-2 Gateway Properties Table 14-3 Firewall Properties Table 14-4 General Properties
The tables include both variables that are configurable from SmartDashboard, and variables that are not. The values that appear in the table in Bold are the gateway default values, so if these are desired, there is no need to change the values. The client_decide value means the device user can configure the setting. The device default value appears in the table in Italics. Database Tool configuration is dependent on Central Management capabilities. For details, see Requirements for Central Management on page 365. For more information on the Database Tool, see SecureKnowledge solution SK13009. To configure client attributes with the Check Point Database Tool: 1. On a host with SmartConsole installed, run the Database executable, by default located at: C:\Program Files\CheckPoint\SmartConsole\<version>\PROGRAM\GuiDBedit.exe 2. In the Database Tools navigation tree, under Global Properties, select properties. 3. Select the firewall_properties object. 4. In the Field Name column, find mobile_remote_access_preferences. The SecureClient Mobile properties appear below this field. 5. Double-click a field and Edit its Value. Click OK. 6. To save the changes to the management database, from the File menu, select Save All. To have the changes installed on the gateway, Install Policy from SmartDashboard. Then, the next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.
Chapter 14
Note - There are properties which exist in the database but are not listed in the tables
below. These properties will be implemented in later releases.
Table 14-1 VPN Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) false, true, client_decide
neo_remember_user _password
Remembers the user password/PIN (password caching). So long as the password is cached, the user should not be prompted to enter a password when the client connects, reconnects or re-authenticates. The password/PIN caching timeout (in minutes) since the user has entered their credentials. An authentication attempt after this timeout expires requires the user to re-enter their credentials.
neo_remember_user _password_timeout
-1 (infinite), 1 MAX_INT, 1440
400
neo_clear_in_acti vesync
Enables clear traffic during ActiveSync. When set to true if the device is cradled (for example, when ActiveSync is activated to a PC using Bluetooth), the client automatically disconnects and the firewall settings permit clear traffic to exit the device to the encryption domain. This is required when the connected PC is located inside the encryption domain and the encryption of data is not necessary. A message appears when the client disconnects. Always connected. The client automatically connects to the last connected gateway: When the device has a valid IP address. When the device "wakes up" after it had low-power and after a soft-reset. When the value is application_request and an application initiates a connection to the encryption domain.
neo_always_connec ted
false, true, application_request, client_decide
Chapter 14
Table 14-1 VPN Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) 1 - MAX_INT
neo_always_connec ted_retry
The always connected retry timeout (in minutes). If an automatic connection fails, the client tries to reconnect again and again on an interval set by this value. The client also tries to reconnect after the IP address of the client changes, or if the user manually requests a connection. This flag instructs the client to automatically initiate an existing dialup connection (for example, GPRS) when the always connected flag is set to true, the user requests a connection, and there is no valid IP on the machine. Timeout for dialup successful completion (seconds) Disconnect when idle. Automatically disconnects the tunnel when the user does not interact with the device over a defined time period. A message appears when the client disconnects. Disconnect when idle timeout (in minutes).
neo_initiate_dial up
false, true, client_decide
neo_initiate_dial up_timeout neo_disconnect_wh en_idle
1 -MAX_INT; 15 false, true, client_decide
neo_disconnect_wh en_idle_timeout
1 (default) -MAX_INT; 15
402
Table 14-1 VPN Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) once, always, never, client_decide
neo_user_approve_ server_fp
Requests user approval of server Finger Print (FP) before the client enters its credentials. The server FP is part of the gateway certificate provided in the SSL interaction with the client. The following options are available: Once: If the FP is seen for the first time by the client and not stored in the client database. Always: Prompts the user to approve the FP for every connection. Never: Always accepts the FP. Enables the client to connect to a new gateway. When this flag is set to false, the client can only connect using the list of gateways configured in the client setup package. Blocks a connection upon the removal of passwords. If set to true, when the user clears the Remember Password option in the Options dialog, or selects the Erase Passwords menu option, the tunnel is automatically disconnected. A message appears when the client disconnects.
Chapter 14
neo_allow_site_cr eation
neo_block_conns_o n_erase_passwords
neo_disconnect_wh en_in_enc_domain
If the client is connected to a site and an interface has an IP address located within one of the VPN encryption domains, the client disconnects. A message appears when the client disconnects. Change the http/s proxy settings returned to applications that request access to resources inside the enc-domain while the client is connected. The value should be a URL of the format http://host:port. If the proxy requires user/pass than use the format ftp://user:pass@host:port (must be FTP although its an HTTP proxy!). A heartbeat is sent to the server even if data was sent. If no other data was sent to the server. Value should not be more than 600 (10 minutes) if SCV traversal is used.
neo_replace_http_ proxy
neo_keep_alive_ma x_timeout
10-MAX_INT 600
404
Table 14-1 VPN Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold)
neo_script_wm_con nect
Windows Mobile post connect script url (starting with http://). The file should be a Windows Mobile XML provisioning file (starting with <wap-provisioningdoc>). Note: flag must be part of a policy downloaded to the client from a server to be execute. Client does not "run" a locally defined flag (global configuration). Windows Mobile post connect script - show window while running script. Windows Mobile post connect script - MD5 of script. If MD5 of script is different then the MD5 of the script file an security warning is displayed to the user. Windows Mobile post disconnect script url (starting with http://). The file should be a Nokia XML provisioning file (starting with <wap-provisioningdoc>). Note: flag must be part of a policy downloaded to the client from a server to be execute. Client does not "run" a locally defined flag (global configuration). Windows Mobile post disconnect script - show window while running script
Chapter 14
neo_script_wm_con nect_show neo_script_wm_con nect_md5
false, true
neo_script_wm_dis connect
neo_script_wm_dis connect_show
false, true
Table 14-1 VPN Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold)
neo_script_wm_dis connect_md5
Windows Mobile post disconnect script - MD5 of script. If MD5 of script is different then the MD5 of the script file an security warning is displayed to the user. Windows Mobile run-once script url (starting with http://). The file should be a Windows Mobile XML provisioning file (starting with <wap-provisioningdoc>). Note: flag must be part of a policy downloaded to the client from a server to be execute. Client does not "run" a locally defined flag (global configuration). Windows Mobile run-once script - show window while running script Windows Mobile run-once script - MD5 of script. If MD5 of script is different then the MD5 of the script file an security warning is displayed to the user. Retry to establish tunnel until this timeout elapse (in minutes). 1 - MAX_INT; 2 false, true
neo_script_wm_run once
neo_script_wm_run once_show neo_script_wm_run once_md5
neo_implicit_disc onnect_timeout
406
Table 14-2 Gateway Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) false, true certificate, certificate_with_enroll ment, legacy, mixed 3des_only, 3des_or_rc4 no upgrade, ask user, force upgrade a number in hexadecimal format 10-MAX_INT 20
neo_enable neo_user_auth_met hods neo_encryption_me thods neo_upgrade_mode neo_upgrade_versi on neo_upgrade_url neo_keep_alive_ti meout
A gateway property which activates neo support. Client authentication methods.
Client encryption methods. Client upgrade mode. The client required version. Client download absolute URL. Client to server heartbeat interval (in seconds). A heartbeat is sent if no other data was sent to the server. The gateway allows only clients with these package IDs to connect (comma separated list). The session validity timeout (in minutes). The DLL name or full path that is loaded for authentication with the server. The relative URL for SAA authentication.
neo_package_id
neo_user_re_auth_ timeout neo_saa_guilibs
10~1440 480
neo_saa_url
Chapter 14
Table 14-3 Firewall Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) false, true, client_ decide client_decide, allow_all, outgoing_only, outgoing_and_encrypte d, encrypted_only, block_all false, true, client_ decide false, true, client_ decide -1 (infinite); 10-MAX_INT 525600
neo_enable_firewal l_policy neo_firewall_polic y
Enables the firewall policy. The supported firewall policies: Apply clients setting Allow-all Outgoing only Outgoing and encrypted Encrypted only Block all (never disabled) Enables ActiveSync to PC (disabled if firewall is not installed). Enables IP forwarding (when firewall is enabled). The policy expiration timeout (in minutes).
neo_enable_actives ync neo_enable_ip_forw arding neo_policy_expire
408
Table 14-3 Firewall Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) false, true, client_ decide
neo_route_all_traf fic_through_gatewa y
Routes all traffic through a gateway (in hub mode). This flag sets the routing in the IP routing table to send all traffic to the connected gateway, which results in all traffic leaving the machine (except for specific routes) to be encrypted and possibly re-routed from the gateway to the outside Internet. It allows for the inspection of all client data received that is examined by the connected gateway. This will only work if the gateway also supports routing all traffic. To configure the gateway, seeRouting All Traffic To the Gateway (Hub Mode) on page 388. Enables clear traffic to the encryption domain when the client is disconnected. The client prevents clear traffic to the encryption domain from exiting the machine at all times except if this flag is set to true. Note: In an IPSEC client, this functionality is achieved using the VPN chain in the firewall. In SecureClient Mobile, this functionality is achieved using the firewall rule setting.
neo_allow_clear_wh ile_disconnected
Chapter 14
Table 14-3 Firewall Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) {neo_basic_interface,n eo_ip_with_allowed_ap n_list_interface,neo_bt _interface,NULL}
neo_interface_bloc king_list
List of supported interfaces and their status and details (where available). Status can be false,true,client_decide. For BlueTooth it can also be connectable. When the list is empty all is allowed. Basic class for Interface blocking. Type of the Interface (currently only P2P and IP). State of the Interface. True = allowed, false = blocked. Class for Bluetooth blocking with profiles specified. State of the Interface. True = discoverable, false = blocked, connectable = allowed but not discoverable.
neo_basic_interfac e interface_type interface_state neo_bt_interface interface_state
Name of the interface (= name of the object)
false, true, client_decide Name of the interface (= name of the object) false, true, client_decide, connectable
Table 14-4 General Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) false, true, client_decide false, true, client_decide
neo_run_client_on _device_startup neo_enable_kill
Runs the client on device startup. Specifies whether the user can stop the client. If this option is set to false, the quit option does not appear in the client menu. Enables the client troubleshooting window.
neo_allow_client_ debug_logs
410
Table 14-4 General Properties Property Description Valid Values (Gateway Default value in Italics; Device Default Value in Bold) false, true, client_decide
neo_allow_client_ db_export
Enables the client to export its local database to a clear text file is used to create a customized installation package. Allow provisioning of the client through Registry Configuration Service Provider (OMA DM and XML Provisioning). Available options: Update configuration with a startup.C file Turn debug logging on/off. Run CLI commands through scm.exe. Displays the today item. Displays the taskbar icon. Displays the flash icon, which monitors VPN tunnel activity (traffic). Displays the flash icon, which monitors firewall packet dropping activity.
neo_allow_provisi oning_via_registr y
false, true
neo_show_today_it em neo_show_taskbar_ item neo_flash_icon_on _encrypting neo_flash_icon_on _fw_packet_drop
false, true, client_decide false, true, client_decide false, true, client_decide false, true, client_decide
Chapter 14
412
15 Chapter SecureClient Mobile Client Configuration

In This Chapter
VPN Connections Client Configuration Troubleshooting Additional Resources page 414 page 416 page 420 page 423
413
VPN Connections
VPN Connections
In This Section
Status Page Initiating a VPN Connection Closing SecureClient Mobile page 414 page 414 page 415
Status Page
SecureClient Mobile can be opened either from the Start menu or by tapping on the SecureClient Mobile icon in the bottom-right corner of the screen. The Status page is displayed in the Basic Details view. Basic Details view contains: Server: Displays the VPN servers name or IP address. VPN: Displays whether the client is connected to a VPN server. Firewall policy: Displays whether the firewall policy is enabled or disabled.
More Details view contains: Office mode IP: Displays the Virtual Network Adapter IP address that was assigned by the server. Duration: Displays the duration of the current session. Sync to PC: Displays whether the PC Sync Policy is allowed or disallowed.
Initiating a VPN Connection

To connect to a gateway: 1. On the toolbar, tap Menu > Connect > New. The Connect to a new Server window opens. 2. In the Server address or name field, enter the gateway information. If you are connecting to a port other than the default (TCP port 443), enter "<gateway information>:<port>". 3. Tap OK. The first time you connect to a server, the credentials need to be verified.
414
Closing SecureClient Mobile
4. When prompted, enter your credentials. Note - If you connected to a gateway previously, then tap Connect on the toolbar to connect to the most recently connected gateway. The user may be prompted for authentication credentials five minutes before the session is timed-out. Once these credentials are accepted, the time-out interval is initialized. If the user does not provide valid credentials in time, the client is disconnected from the server. The user must reconnect and re-authenticate the client manually. The user can also manually end its session by disconnecting the client.
Closing SecureClient Mobile

To close SecureClient Mobile, tap Menu > Quit. SecureClient Mobile will be listed on the Today/Home Screen as Not Running. SecureClient Mobile can be opened either from the Start menu or by tapping the SecureClient Mobile listing on the Today/Home Screen .
Chapter 15
SecureClient Mobile Client Configuration 415
Client Configuration
Client Configuration
In This Section
Connectivity Options Configuring Display Settings Firewall Policy Controlling Device Connections page 416 page 417 page 418 page 418
Connectivity Options
Tap Menu > Manage... > VPN Client and scroll down to the Connectivity section. The options are: Connect Mode: Determines when SecureClient Mobile will initiate a VPN connection. The options are: Manual: VPN connections will not be initiated automatically. App. Request: Applications requiring access to resources through the VPN will be able to initiate a VPN connection. To configure App. Request behavior for email accounts or the Opera web browser, tap the Configure App. Request button. Always Connected: SecureClient Mobile will automatically establish a connection to the last connected gateway under the following circumstances: (a) the device has a valid IP address, (b) when the device "wakes up" from a low-power state or a soft-reset, or (c) after a condition that caused the device to automatically disconnect ceases to exist (i.e. Device is out of PC Sync or Disconnect is not idle). Don't connect in PC Sync (cradle): Forces the VPN connection to terminate when the device is connected to a PC using ActiveSync (USB, Bluetooth). This setting is unrelated to performing ActiveSync with an Exchange Server. Initiate dialup: When selected, the client will initiate a GPRS dialup connection before attempting to establish the VPN connection. Note that if a local IP address is already available through any network interface, then the GPRS dialup is not initiated.
416
Configuring Display Settings
Route all traffic to gateway: Operates the client in Hub Mode, sending all traffic to the VPN server for routing, filtering, and processing. If this is set, the firewall policy should also be set to 'Allow Encrypted Only'. Disconnect when device is idle: When the device is idle (screen or keys untouched), disconnect the VPN connection and allow the device to go into stand-by mode, if necessary.
To prevent SecureClient Mobile from running automatically at device startup, uncheck Run client on device startup found at the bottom of the VPN Client configuration page.
Note - The administrator has the ability to prevent the user from changing these settings.
Configuring Display Settings

To configure display settings on the mobile device: 1. Tap Menu > Manage... > VPN Client. 2. Scroll down to Display Settings, and configure the following: Notification Level: Select from the drop down menu one of the following options: All - All pop-ups from all categories (information, progress, warnings and errors) sent by the client are allowed. Progress, Warnings and Errors - Select this option to eliminate Information pop-ups from appearing. Warnings and Errors (default) - Select this option to allow only Warnings and Errors pop-ups to appear. Errors only - Select this option to eliminate all pop-ups except those in the Errors category from appearing. None - Select this option to prevent all pop-ups from appearing.
Play sound effects: Selecting this option enables the SecureClient Mobile sound effects including Connect and Disconnect notifications. Show Today Item: Select this option to display SecureClient Mobile in the Today Item menu. Show Taskbar icon: Select this option to display the SecureClient Mobile icon on the taskbar when the client is running.
Chapter 15 SecureClient Mobile Client Configuration 417
Firewall Policy
Rotate icon on VPN activity: By selecting this option, the key in the icon displayed on the taskbar rotates when information is in the process of being sent or received. Flash icon on firewall packet drop: Select this option to display the lock in the icon on the taskbar, which flashes when packets are dropped.
Firewall Policy
Tap Menu > Manage... > Network Control. In the Firewall section, click the Enable firewall policy checkbox to enforce the Firewall settings listed. The options for Allowed traffic enforcement are: Allow all: All traffic is allowed. The client will still be protected by implicit firewall rules. Outgoing only: All outbound connections are permitted and all inbound connections are blocked. This policy will prevent incoming connections from being established from both the non-VPN hosts and VPN hosts. Outgoing and encrypted: Permits incoming and outgoing encrypted traffic to and from the VPN domain. Also permits outgoing non-VPN connections that are initiated from the handheld. This policy is the recommended setting. Encrypted only: Only VPN traffic originating from or destined to the encryption domain are permitted. Block all: All network traffic is blocked. The device will only be permitted to connect to the Gateway for the purpose of updating the client configuration.
Note - The administrator has the ability to prevent the user from changing these settings.
Controlling Device Connections

SecureClient Mobile can limit the connectivity through some of its interfaces through the settings on the Menu > Manage... > Network Control screen. Allowed interfaces displays the interfaces allowed as a result of the rules set in the SmartDashboard. Blocked interfaces displays the interfaces blocked as a result of the rules set in the SmartDashboard. To enable connections to a PC with ActiveSync, tap the Allow PC Sync checkbox.
418
Controlling Device Connections
To enable the device to connect to unknown types of interfaces, tap the Allow Unknown type of interfaces checkbox. To configure which Bluetooth functions SecureClient Mobile will allow, select one of the modes listed in the Bluetooth policy dropdown box. The options listed are: Off: SecureClient Mobile will block all Bluetooth functionality. Connectable: SecureClient Mobile will allow Bluetooth connections but will not allow the device to advertise its presence. Discoverable: SecureClient Mobile will allow the device to advertise its presence and connect to other Bluetooth devices.
Note - The administrator has the ability to disable these options.
Chapter 15
Troubleshooting
Troubleshooting
In This Section
Enabling Log Files Viewing Network Configuration Error Messages page 420 page 420 page 421
Enabling Log Files

Log files are files that record client activity, which are useful when troubleshooting various issues. To enable logs tap Menu > Help & Tools > Troubleshooting. Tap the Clear Logs command to remove any existing log files. Logs may be enabled for each of the following: Client, VNA Kernel (Virtual Network Adapter) and Firewall Kernel (packet drop log). Because enabling all three log files can noticeably slow down SecureClient Mobile performance, it is recommended to first enable just the Client log to gather troubleshooting information. If that is not sufficient, then enable the other logs as well.
Viewing Network Configuration

To troubleshoot network connectivity issues, view the device's network configuration by tapping Menu > Help & Tools > Troubleshooting. Under the Show section, you can click on Routing Table, IP Configuration, and TCP Connections Table to display any of these details. Tap OK to exit the Networking Configuration screens.
420
Error Messages
Error Messages
Table 15-1 provides a list of error messages, their possible causes and a suggested solutions. Table 15-1 Error Messages Troubleshooting Error Message Cannot find the server (server name). Please check the server name and try again. Error while negotiating with the server (server name). Please try again. You are not permitted to access the server. Possible Cause There is an error resolving the server name. Error in client-server negotiation. The user is not authorized. Solution Check the server name and verify that the IP address is valid. Try to connect again.
Check that the user certificate is installed and is valid. Connect the device to a network. Check that your dialup settings are configured properly.
Your device is not connected to any network. Your device is not connected to any network. Dialup connection is not available.
The network is not available for connection. The network is not available for connection and dialup cannot be initiated. The settings may not be configured properly. Wrong credentials supplied.
Access denied. Wrong username or password.
Ensure that the credentials are current and retry. If the credentials are cached, use the clear passwords button.
Chapter 15
Error Messages
Table 15-1 Error Messages Troubleshooting Error Message User is not permitted to have an office mode IP address. Possible Cause The user attempting to connect is not configured to have an office mode IP address and therefore the connection failed. Invalid certificate provided. Solution Ensure that the user is configured to receive an office mode IP address.
The certificate provided is invalid. Please provide the username and password.
Either install a new user certificate or connect with a username and password. Try to reconnect.
Connection to the server (server name) was lost.
There is no connection to the server, and the client disconnected. Server validation failed and therefore the connection failed. Another client has connected to the gateway with the same credentials. The client's Firewall policy is configured to block all network traffic.
Security warning! Server fingerprint has changed during connection. Contact your administrator. Possible identity theft. User credentials used from another client. Client Disconnected. Client firewall policy is set to Block all. Client has disconnected.
Contact your administrator.
422
Additional Resources
For additional resources on setting up SecureClient Mobile, refer to: How to add your own root certificate via CAB file. How to add root certificates to Windows Mobile 2003 Smartphone and to Windows Mobile 2002 Smartphone. Windows Mobile 5.0 Security Model FAQ. ActiveSync 4.x Troubleshooting Guide.
Chapter 15
424
16 Chapter SecureClient Mobile Package Management

In This Chapter
Client Deployment, Repackaging and Upgrading Post-Installation / Post-Uninstallation Scripts Package Customization page 426 page 426 page 427
425
Client Deployment, Repackaging and Upgrading
Client Deployment, Repackaging and Upgrading

SecureClient Mobile comes packaged as a self-installing CAB file, which is signed for integrity. The CAB package can be customized before it is distributed to users to include predefined topology, settings, credentials, and a default firewall policy. The CAB can also be re-packaged with a supplied MSI package (Windows Installer) to be installed through ActiveSyncs installer service from a Windows PC. During version upgrades, the installer preserves the existing client policies and credentials unless they are specifically overridden by the upgrade package. When the client is installed on the mobile device, another applet called Certificate Import Wizard is also installed. This applet enables the importing of PKCS#12 certificate files to the device CAPI store for use for client authentication. Configuring an upgrade is done using SmartDashboard.
Post-Installation / Post-Uninstallation Scripts

Scripts can be included in installation packages to run commands after client installation or before client uninstallation. The scripts can be written in command format or in OMA DM format and must be placed in either the PostInstall.conf or the PreUninstall.conf file in the package. For example, this feature can be used to install a certificate on the device by entering into the PostInstall.conf file the following command:
<Certificate Filename> [-p Password] [-silent] [-csp Provider]
426
Package Customization
Package Customization
The administrator obtains the SecureClient Mobile distribution package from the Check Point Download Center. The distribution package is located in a .zip file, which contains the following folders and files: Folder/File client_api client_pkg tools unlock_smartphone Explanation SecureClient Mobile API plus sample code. SecureClient Mobile components for package customization. SecureClient Mobile tools (for instance MSI package and MSI packaging tool). This folder contains the Check Point certificate. Installing cpcert.cab enables the device to trust Check Point software, and successfully deploy SecureClient Mobile on locked Windows Mobile devices. Readme file. Sample provisioning scripts. Latest version of the TTM files for the client in case you want to update the TTM files on the gateway.
readme.txt samples ttm
The unpacked client files are the same as those in the CAB package. The administrator can customize and package these files into a new CAB or MSI file package before distributing it to users. The customized package can include predefined topology and credentials, a default firewall policy and other settings. During version upgrades, the installer retains the existing client policies and credentials that were not predefined in the upgrade package. The administrator can client upgrade using the neo_upgrade_mode, neo_upgrade_version and neo_upgrade_url flags. When the client is installed on a PocketPC 2003 or Windows Mobile 5.0 device, another applet, called Certificate Import Wizard, is also installed. This applet enables you to import PKCS#12 certificates to the device. The CAB and MSI packages can be edited by the administrator to customize the settings for SecureClient Mobile. The administrator can edit the package : Adding a file to the CAB package, for example, a user certificate file or a Secure Authentication (SAA) plug-in. For additional information, refer to Adding a File to a CAB Package on page 428.
Chapter 16
SecureClient Mobile Package Management 427
Adding a File to a CAB Package
Deleting a file from the CAB package, for example, the Cert_import utility may not be needed for some configurations. For additional information, refer to Deleting a File from a CAB Package on page 429. Preconfiguring the client database parameters. For additional information, refer to Exporting the Client Configuration on page 429. Defining the client installation version. For additional information, refer to Defining the Client Installation Version on page 430.
Adding a File to a CAB Package

To add a file to a CAB package: 1. Obtain the SecureClient Mobile distribution .zip file from the Check Point Download Center site or from the CD. 2. Save the distribution .zip file to your local machine and extract its contents. One of the files is the SecureClient_Mobile_<build number>.zip file. 3. Extract SecureClient_Mobile_<build number>.zip to a folder (for example, SCM). This creates a number of subfolders. 4. Copy and paste the file(s) to be included in the package to the conf folder (one of the extracted subfolders created in step 3). 5. In the SCM folder, open the SecureClient_Mobile_Setup_<build number>.inf file using a text editor. 6. In the SecureClient_Mobile_Setup_<build number>.inf file, add the name(s) of the file(s) to be included in the package to the following sections: In the [conf] section, add the name(s) of the file(s) starting on the line immediately after startup.C. In the [SourceDisksFiles] section, add the name(s) of the file(s) starting on the line immediately after startup.C. Every file in this section ends with an equal sign and a number, for example, startup.C=7. Add an equal sign and a number to the end of each file name that is added. The number represents the folder the file is placed in and corresponds to the [SourceDisksNames] section numbers.
7. Save the file. 8. Continue to Creating a CAB Package on page 431.
428
Deleting a File from a CAB Package
Deleting a File from a CAB Package

To delete a file from a CAB package: 1. Obtain the SecureClient Mobile distribution .zip file from the Check Point Download Center site or from the CD. 2. Save the distribution .zip file to your local machine and extract its contents. One of the files is the SecureClient_Mobile_Setup_<build number>.zip file. 3. Extract SecureClient_Mobile_Setup_<build number>.zip to a folder (for example, SCM). This creates a number of subfolders. 4. In the SCM folder, open the SecureClient_Mobile_Setup_<build number>.inf file using a text editor. 5. In the SecureClient_Mobile_Setup_<build number>.inf file, delete references to the file(s) to be deleted in the following sections: In the [conf] section, delete the name(s) of the unwanted file(s). In the [SourceDisksFiles] section, delete the name(s) of the unwanted file(s).
Exporting the Client Configuration

The administrator can provide all users with customized settings that are pre-configured on a SecureClient Mobile installation package. This is done by exporting an existing client configuration into a config file that is then added to a customized client CAB package. This customized package can then be installed/upgraded to the connecting devices. To export the client configuration: 1. When using version NGX R66 of SmartDashboard, to allow exporting of the configuration: a. In SmartDashboard, from the Policy menu, select Global Properties. b. In the Global Properties navigation tree, under Remote Access, select SecureClient Mobile. c. In the SecureClient Mobile page, click Configuration and Version Management. d. In the Configuration and Version Management window, set Enable export of client configuration to Yes.
Chapter 16 SecureClient Mobile Package Management 429
Defining the Client Installation Version
e. Click OK, OK, and Install Policy. 2. When using a previous of SmartDashboard, allow exporting of the configuration by using GUIdbEdit to change the neo_allow_client_db_export value to true. 3. Connect SecureClient Mobile on a device to the gateway in order to download the policy. 4. Configure SecureClient Mobile on the device with the required configuration to be exported. For example, configure the clients firewall options and connection to the gateways. 5. Copy the database.C file to the client folder. 6. Restart the client. 7. In SecureClient Mobile, select Menu > Help & Tools > Export db. This exports the current settings to the startup.C file, which contains the nonconfidential data in the database. 8. Replace the startup.C file that is located in the conf folder of the preconfigured package. This file may be edited manually using a text editor in order to add or remove flags. Note - Exporting startup.C will also export the global property neo_allow_client_db_export with the value set to true. To restrict users from exporting the client configuration, edit the startup.C and remove the property or set it to false.
Defining the Client Installation Version

The default client installation version is the client build number defined by Check Point. To change the client installation version: 1. Obtain the SecureClient Mobile distribution .zip file from the Check Point Download Center site or from the CD. 2. Save the distribution .zip file to your local machine and extract its contents. One of the files is the SecureClient_Mobile_Setup_<build number>.zip file. 3. Extract SecureClient_Mobile_Setup_<build number>.zip to a folder (for example, SCM). This creates a number of subfolders. 4. In the SCM folder, open the SecureClient_Mobile_Setup_<build number>.inf file using a text editor.
430
Creating a CAB Package
5. Change the following attribute to the desired build number:
NEO_VERSION_NUMBER= <build number>

Creating a CAB Package

A CAB package is created from the application files using the Cabwiz utility. Cabwiz can be downloaded and installed from the Microsoft Pocket PC 2003 SDK. To create a CAB package: 1. To obtain the Cabwiz utility Download the Microsoft Pocket PC 2003 SDK from here. Install the SDK on your PC. After the SDK is installed, the Cabwiz utility is normally located at: C:\Program Files\Windows CE Tools\wce420\POCKET PC 2003\Tools.
2. Edit the package by exporting the client configuration and removing and/or adding files (for additional information, refer to Adding a File to a CAB Package on page 428, Deleting a File from a CAB Package on page 429 and Exporting the Client Configuration on page 429). 3. Copy the Cabwiz.exe and the Cabwiz.ddf files to the SCM folder created when extracting the SecureClient_Mobile_Setup_<build number>.zip file (this file was originally extracted from the SecureClient Mobile distribution .zip file). 4. Copy the makecab.exe from the Windows system directory (by default: C:\WINDOWS\system32) to the SCM folder. 5. Run the Cabwiz SecureClient_Mobile_Setup_<build number>.inf file. The created CAB package has a .cab extension.
Creating an MSI Package

The customizable install package (ZIP file) includes a Windows Installer package (MSI file) with a placeholder for a new client installer (CAB file). Once a client CAB is attached to the MSI file it can be installed on a Windows machine (PC) - the attached CAB would then be installed onto a connected PDA though the ActiveSync service. To attach a client CAB file to a MSI file, proceed as follows: 1. Obtain the SecureClient Mobile distribution .zip file from the Check Point Download Center site or from the CD.
Chapter 16 SecureClient Mobile Package Management 431
Configuring the SAA Plug-in
2. Save the distribution .zip file to your local machine and extract its contents. One of the files is the SecureClient Mobile MSI file. 3. Run /tools/neo_msi_tool.exe SecureClient_Mobile.MSI SecureClient_Mobile.CAB Neo

Enabling the SAA plug-in enables the ability to implement additional authentication schemes (for example, SoftID.) The plug-in also allows customizing the login page. To enable the SAA plug-in using GuiDBedit: 1. Set the property neo_saa_guilibs to the SAA plug-in name, for example, SAAPlugin.dll. 2. Save the change and exit GuiDBEdit. 3. Install the updated policy. Once the SAA plug-in is enabled on the gateway, the client can be configured in one of two ways: 1. Manually 2. Using a predefined package
Configuring the SAA Plug-in on the Client Manually

On the device: 1. Copy the SAA plug-in into the following folder:
\Program Files\CheckPoint\SecureClient_Mobile
2. Connect to the gateway. During the connection process, the defined SAA plug-in popup opens. In the event you receive the following error message, "Configuration Error: Failed to load SAA plug-in," use the client login page (username-password) to connect. Once connected, quit and relaunch the client again.
432
Using a Predefined Package

This configuration is for situations where all the users use the SAA plug-in to connect. In the event that only certain users are required to use the plug-in, set the neo_saa_guilibs property to an empty string after you complete the creation of the customized package. As a result, only the users using the customized package will be using the SAA plug-in. 1. Follow the steps described in Configuring the SAA Plug-in on the Client Manually on page 432. 2. Establish a connection with each gateway that will be included in the package. This will store each gateway into the clients database. 3. Export the client configuration. To export the database, see Exporting the Client Configuration on page 429. 4. Use the exported startup.C to create the customized CAB file (include the SAA plug-in in the CAB too). To create a CAB file, see Creating a CAB Package on page 431.
Chapter 16
SecureClient Mobile Package Management 433
434
17 Chapter SecureClient Mobile Client API

In This Chapter
Introduction Function Return Codes Functions page 436 page 437 page 438
435
Introduction
Introduction
This appendix describes the API functions that are exported by the neo_api.dll file. The function prototypes are defined in the neo_api.h file. In order to use the client API, download the client zip file which contains the neo_api.dll, the header file neo_api.h, and the API usage sample neo_test.cpp. Note - The client API is C based. Exported functions must have a C-style declaration. If you wish to access these API functions from C++, use the extern C declaration.
436
Function Return Codes

The possible return values for the functions are: name meaning The operation was successful. Client services are not running. The client is not responding. An invalid argument was given. The supplied buffer is too small. Invalid state for request. Unauthorized function. A general failure had occurred. Resource ran out. An API internal error occurred.
NEOERR_SUCCESS NEOERR_CLIENT_NOT_RUNNING NEOERR_CLIENT_NOT_RESPONSDING NEOERR_INVALID_ARGS NEOERR_BUFFER_TOO_SMALL NEOERR_INVALID_STATE NEOERR_ACCESS_DENIED NEOERR_GENERAL_FAIL NEOERR_OUT_OF_RESOURCE NEOERR_INTERNAL_ERROR
Appendix 17
SecureClient Mobile Client API 437
Functions
Functions
neo_api_version
This function retrieves the API version.
Prototype NEOERR neo_api_version( ulong* version ) Arguments

argument version IN/OUT OUT meaning Contains the API version.
neo_client_version
This function retrieves the client version and version string.
Prototype NEOERR neo_client_version( ulong* ver, char* version, ulong cbversion ) Arguments
argument IN/OUT OUT OUT IN meaning Contains the client version. Buffer that holds the client version string. Version buffer length.
ver version cbversion
neo_set_log_file
This function turns on/off the logging and determines the log file name, maximum file size, file cycling, and logging level.
Prototype NEOERR neo_set_log_file( const char* filename, ulong size_kb, ulong cycle, ulong lvl )
438
Functions
Arguments
argument IN/OUT IN IN IN meaning Gives a name to the log file. Determines the maximum size of the log file in KB. The number of files that are created before starting again at logfile0. The upper limit for the number of possible files is 20. Severity level of logs required (1-5, 1 = critical and 5 = low).
filename size_kb cycle
lvl
IN
neo_log_outln
Write the given line to the log file. A level is also assigned to the logging action of this line.
Prototype NEOERR neo_log_outln( ulong lvl, const char* line ) Arguments

argument lvl line IN/OUT IN IN meaning The level assigned to this line determines if it is logged into the log file. The string that is written into the log.
The following functions can only be called after a successful initialization.
neo_api_init
This function initializes a connection with the client for command processing.
Prototype NEOERR neo_api_init( ulong api_version, const char* application_name )
Appendix 17
Functions
Arguments
argument IN/OUT IN IN meaning The API version in use. The application used to communicate with the client.
api_version application_name
neo_api_fini
This function terminates the connection with the client for command processing. This should be called before exiting the application.
Prototype NEOERR neo_api_fini()

Arguments None.
neo_set_user_passwd
This function is called to set the username and password to be used the next time the client attempts to authenticate to the active gateway. Note - For this function to work, the neo_remember_user_password property must be set to true and the neo_remember_user_password_timeout property must be set to >0.
Prototype NEOERR neo_set_user_passwd( const char *user, const char *passwd )
440
Functions
Arguments
argument user passwd IN/OUT IN IN meaning The username used by the client. The password used by the client.
neo_set_cert_passwd
This function is called to set the password for the certificate used for connecting to the gateway. This functionality is not implemented in this client version. Note - For this function to work, the neo_remember_user_password property must be set to true and the neo_remember_user_password_timeout property must be set to >0.
Prototype NEOERR neo_set_cert_passwd( const char *cert_cn, const char *passwd ) Arguments
argument IN/OUT IN IN meaning Thew certificate identifier name. The password used for the certificate.
cert_cn passwd
neo_get_state
This function is called to retrieve the state of the client.
Prototype NEOERR neo_get_state( NEO_STATE *state )
Appendix 17
Functions
Arguments
argument IN/OUT OUT meaning An object that defines the state of the client
state
neo_get_last_message
This function is called to retrieve the last client message (for example, error, failure).
Prototype NEOERR neo_get_last_message( char* message, ulong messagecb ) Arguments

argument IN/OUT OUT IN meaning The string that contains the last client message. The size, in bytes, of the message buffer.
message messagecb
neo_clear_passwds
This function is called to clear all saved credentials.
Prototype NEOERR neo_clear_passwds() Arguments

None.
neo_get_gateway_list
This function is called to retrieve a list of gateways known and available to the client.
Prototype NEOERR neo_get_gateway_list( char*** gateways, ulong* num )
442
Functions
Arguments
argument IN/OUT OUT OUT meaning Pointer to a list of gateways available to the client. The number of gateways in the list.
gateways num
neo_free_gateway_list
This function is called to delete the list of available gateways for the client.
Prototype NEOERR neo_free_gateway_list( char** gateways ) Arguments

argument IN/OUT IN meaning The list of gateways.
gateways
The following functions are called to set the Read/Write configuration parameters.
neo_get_property_int
This function retrieves the value of the int property name.
Prototype NEOERR neo_get_property_int( const char* name, int* value ) Arguments

argument IN/OUT IN OUT meaning The name of the property. The value of the property.
name value
neo_get_property_str
This function retrieves the value of the str property name.
Appendix 17
Functions
Prototype NEOERR neo_get_property_str( const char* name, char* value, ulong valuecb ) Arguments
argument IN/OUT IN OUT IN meaning The name of the property. The value of the property. The size, in bytes, of value buffer.
name value valuecb
neo_set_property_int
This function assigns a value to a int property name.
Prototype NEOERR neo_set_property_int( const char* name, int value ) Arguments

argument IN/OUT IN IN meaning The name of the property. The value of the property.
name value
neo_set_property_str
This function assigns a value to a str property name.
Prototype NEOERR neo_set_property_str( const char* name, const char* value )
444
Functions
Arguments
argument IN/OUT IN IN meaning The name of the property. The value of the property.
name value
neo_connect_gw
This function is called to connect to a gateway using the DNS name. If the port is not 443, use name:port. If the gateway is NULL, connect to the last active gateway.
Prototype NEOERR neo_connect_gw( const char *gw ) Arguments

argument IN/OUT IN meaning This is the DNS name of the gateway.
gw
neo_disconnect_gw
This function is called to disconnect from the gateway.
Prototype NEOERR neo_disconnect_gw() Arguments

None.
neo_register_state_change_callback
This function is called to register for notification on tunnel state changes. Each pair <func, opaque> can be registered only once.
Prototype NEOERR neo_register_state_change_callback( void (*func)(void *), void *opaque )
Appendix 17
Functions
Arguments
argument IN/OUT IN IN meaning Called when the tunnel state changes. An opaque object that is transferred to func.
func opaque
neo_unregister_state_change_callback
This function is called to unregister for notification on tunnel state changes.
Prototype NEOERR neo_unregister_state_change_callback( void (*func)(void *), void *opaque ) Arguments

argument IN/OUT IN IN meaning The function that is being unregistered. An opaque object that is transferred to func.
func opaque
446
Endpoint Connect - VPN Client
Chapter Endpoint Connect

In This Chapter:
Introduction Configuring the Gateway Using the Packaging Tool
18
page 450 page 454 page 465
This chapter explains how to configure the Connectra gateway to work with Endpoint Connect.
449
Introduction
Introduction
Endpoint Connect is Check Points new lightweight remote access client. Providing seamless, secure (IPSec) VPN connectivity to corporate resources, the client works transparently with Connectra, the Check Point remote access gateway solution.
Why Endpoint Connect?

With their requirement to repeatedly reconnect and authenticate to the corporate gateway, traditional IPSec clients can be slow and cumbersome. Even SSL VPNs with their explicit login requirements through a browser, are a less than optimal solution for highly mobile laptop users. Providing a highly secured, low footprint VPN technology with advanced security scanning capabilities, Endpoint Connect uses intelligent Auto-Connect and roaming technologies to facilitate seamless and transparent interaction with the Connectra gateway at the perimeter of the corporate network. Designed for corporate users who prefer to use their native desktop to launch business applications rather than the Connectra SSL portal, Endpoint Connect users do not have to authenticate each time they connect. Through interface roaming technologies, client users are always connected to the resources available behind the Connectra gateway. As corporate users move around, an auto connect mode discovers whether users are outside of a secure environment, and implements the best way to connect, using either NAT-T or Visitor Mode. In practical terms, if client users outside of the internal network open their mail programs a connection is transparently established to the mail server behind the Connectra gateway. If client users have mapped drives to servers on the internal network, those mapped drives remain functional even as users roam in and out of the network. Note - While Endpoint Connect can reside on the same host with SecureClient or Endpoint
Security, users should avoid connecting with the two VPN clients to the same network at the same time
Capabilities
Resident on the users desktop or laptop, Endpoint Connect provides various capabilities for connectivity, security, installation and administration.
450
Capabilities
Connectivity
Network Layer Connectivity An IPSec VPN connection to the Connectra gateway for secure encrypted communication. If the network connection is lost, the client seamlessly reconnects without user intervention. Intelligent Auto detect and connect Whenever the Connectra gateway or clients location changes, Endpoint Connect autodetects the best method to establish a connection, using either NAT-T or Visitor mode, intelligently auto-switching between the two modes as necessary. Smart location awareness Endpoint Connect intelligently detects whether it is inside or outside of the VPN domain (Enterprise LAN), and automatically connects or disconnects as required. Proxy detection Proxy servers between the client and the Connectra gateway are automatically detected, authenticated to, and replaced when no longer valid. Transparent Network and Interface Roaming If the IP address of the client changes, for example if the client is using a wireless connection then physically connects to a LAN that is not part of the VPN domain, interface roaming maintains the logical connection. Multiple Sites Endpoint Connect connects to any one of a number of user defined gateways. Dead Gateway Detection If the client fails to receive an encrypted packet within a specified time interval, it sends a special tunnel test packet to the Connectra gateway. If the tunnel test packet is acknowledged, then the gateway is active. If number of tunnel test packets remain unacknowledged, the gateway is considered inactive or dead.
Security
Endpoint Security on Demand Provides a full, effective end point compliance check (for required software updates, anti virus signatures, presence of malware) when connecting, and repeat scans at specified time intervals. Clients that fail the initial scan when connecting gain access to remediation sources.
Chapter 18 Endpoint Connect 451
Installation and Use
Full IPSec VPN Internet Key Change (version 1) support for secure authentication.
Support for strong authentication schemes such as: a. Username and passwords (including cached passwords) b. SecurID c. Challenge-Response d. CAPI software and hardware tokens
Hub Mode Increases security by routing all traffic, such as traffic to and from the Internet, through the Connectra gateway, where the traffic can be inspected for malicious content before being passed to the client.
Visitor Mode When the client needs to connect through a gateway that limits connections to port 80 or 443, encrypted (IPSec) traffic between the client and the gateway is tunneled inside a regular TCP connection.
Installation and Use

Small footprint Offline and Web deployment Endpoint Connect is easily distributed through the Connectra portal. Automatic upgrades Endpoint Connect upgrades are automatic, transparent to the user, and do not require administrator privileges or a client reboot. Site and Create New Site connection wizards For quickly configuring connections to corporate resources. CLI Scripting For automation and internal testing, and use as an embedded headless client. OPSEC API Available for embedded applications, Endpoint Connect is also designed to be part of specialized customer integrations and deployments, for example, organizations that build their own corporate presence applications that require
452
Administration
VPN components. The clients intelligent auto-detect and disconnect features make it ideal for remote unmanned devices that need multiple High Availability options, such as embedded Windows ATMs. For such scenarios, Endpoint Connect offers a native Command Line Interface and OPSec API for configuration and monitoring, as well as the ability to be installed and run as a service.
Administration
Unified Central Management Advanced User Management Unified updates Regulatory Compliance with Advanced Monitoring, Logging and Reporting DLL version numbers collected in a special file for troubleshooting purposes.
Chapter 18
Endpoint Connect 453
Configuring the Gateway
Configuring the Gateway

In This Section:
Configuring the Gateway for Endpoint Connect Working with RSA Hard and Soft Tokens Configuring Logging Options for Client Users Disabling CAPI Authentication Disabling DNS-based Geo-Cluster Name Resolution Configuring Endpoint Compliance Checks NAT Traversal page 454 page 460 page 461 page 461 page 462 page 463 page 463
Configuring the Gateway for Endpoint Connect

In SmartDashboard: 1. On the Connectra tab > Additional Settings > VPN Clients page select the Connectra gateway. The Connectra Properties window opens showing the VPN Clients page:
454
2. Select Endpoint Connect. 3. In the VPN Client Traffic section, select which services and interfaces handle client traffic. 4. In the Advanced section, click Edit.... The Advanced window opens.
In this window, advanced settings for all VPN clients are configured, for example the Office Mode settings. Enable Office Mode when the remote client may be working with an IP address that clashes with an IP address on the network behind the Connectra gateway. When working with Office Mode, Endpoint Connect takes an Office IP address from the same reserved pool of IP addresses as SecureClient Mobile or SSL Network Extender. For an explanation of all options, click Help. 5. Select Public IP address that VPN Clients Connect to if the IP address of the Connectra gateway is hidden behind a NAT address or resolved using DNS. 6. On the Connectra tab > Additional Settings > VPN Clients page > Advanced Settings for Endpoint Connect Client page > click Edit.... The Endpoint Connect Advanced Settings window opens:
Chapter 18
The window is divided into four sections: Authentication Settings Connectivity Settings Security Settings Configuration and Version Settings
Use the settings in this section to configure password caching, and how often the user needs to re-authenticate. If you do not open this window and configure options, then the clients default value takes affect: Table 18-1 Default Authentication values Option Enable password caching Cache password for Reauthenticate user every SmartDashboard default value No 1440 (minutes) 480 (minutes) Endpoint Connect default value No 1440 480
456
Use the settings in this section to determine connect and disconnect options. Connect mode covers whether the user should manually connect each time, the user is always connected, or whether the decision can be made on the client side. If the decision is left to the client, the user can select the Enable Always Connect option on the Settings tab of the site properties window. If you do not open this window, then default values apply: Table 18-2 Default Connectivity values Option Connect mode Location Aware Connectivity Disconnect when no connectivity to network Disconnect when device is idle SmartDashboard default value Client decide Client decide Client decide Client decide Endpoint Connect default value Yes Yes No No
Location Aware Connectivity

Endpoint Connect intelligently detects whether it is inside or outside of the VPN domain (Enterprise LAN), and automatically connects or disconnects as required. When the client is detected within the internal network, the VPN connection is terminated. If the client is in Always-Connect mode, the VPN connection is established again when the client exits.
Configuring Location Aware Connectivity

To configure Location Aware Connectivity: 1. Select Yes from the drop-down box and click Configure....
Chapter 18
The Location Awareness Settings window opens:
2. Select the criteria by which the client determines whether it is within the internal network: Client can access its defined domain controller Client connection arrives from within the following network If necessary, click Manage to define a new Simple Group, Group With Exclusion, or Network. 3. Click Advanced....
458
The Location Awareness - Fast Detection of External Locations window opens:
Use these options to identify external networks. For example, create a list of wireless networks or DNS suffixes that are known to be external. Or cache (on the client side) names of networks that were previously determined to be external. Selecting one or more of these options enhances the performance of location awareness.
Security Settings
Use the settings in this section to determine whether or not traffic to and from Endpoint Connect is routed through the Connectra gateway, and therefore subject to content inspection. If the system administrator decides to Route all traffic through gateway, all outbound traffic on the client is encrypted and sent to the Connectra gateway but only traffic directed at site resources is passed through; all other traffic is dropped. If this option is not selected, only traffic directed at site resources is encrypted and sent to the gateway. All other outbound client traffic passes in the clear.
Chapter 18
Working with RSA Hard and Soft Tokens
For the Connectra gateway to act as a hub for content inspection of all inbound and outbound client traffic, regardless of destination, the administrator needs to a define a network application that includes the range: 0.0.0.1 > 255.255.255.254. If you do not open this window, then default values apply:
Table 18-3 Default Security Settings Option Route all traffic through gateway SmartDashboard default value No Endpoint Connect default value No
Configuration and Version Settings

Use the settings in this section to configure how the client is upgraded. The upgrade procedure remains transparent to the user, and does not require administrator privileges on the endpoint or a reboot after the upgrade is complete. If you do not open this window, then default values apply: Table 18-4 Default configuration and version settings Option Client upgrade mode SmartDashboard default value ask user Endpoint Connect default value do not upgrade
Note - All of the above settings for Endpoint Connect are also available through Global Properties > Remote Access > Endpoint Connect.
Working with RSA Hard and Soft Tokens

If SecurID is used for authentication, you must manage the users on RSAs ACE management server. ACE manages the database of RSA users and their assigned hard or soft tokens. The client contacts the sites gateway. The gateway contacts the ACE Server for user authentication information. This means: Remote users must be defined as RSA users on the ACE Server. On the Connectra gateway, SecurID users must be placed in a group with an external user profile account that specifies SecurID as the authentication method.
460
Configuring Logging Options for Client Users
For remote users to successfully use RSAs softID: 1. Create a remote users group on the Ace Server 2. Distribute the SDTID token file (or several tokens) to the remote users out of band. 3. Instruct remote users on how to import the tokens.
Configuring Logging Options for Client Users

The Options window, Advanced tab of the client enables users to send log using their default mail client. Administrators can: Define an email address for these log files by modifying the send_client_logs attribute in $FWDIR/conf/trac_client_1.ttm on the Connectra gateway.
:send_client_logs ( :gateway ( :default ("email@example.com") ) )
If an email address is not defined in trac.client_1.ttm, clicking Collect Logs in the Options > Advanced window collects all the client logs into a single CAB file, which the user can save and then send to the network administrator as an attachment.
Disabling CAPI Authentication

Endpoint Connect supports user authentication through the use of PKCS#12 certificates. A PKCS#12 certificate can be accessed directly or imported to the CAPI store and accessed from there. If, for security reasons, you do not wish users to authenticate using certificates within the CAPI store: 1. On the Connectra gateway, open the $FWDIR/conf/trac_client_1.ttm file for editing.
Chapter 18
Disabling DNS-based Geo-Cluster Name Resolution
2. Modify the enable_capi attribute to FALSE.

enable_capi ( :gateway ( :map ( :false (false) :true (true) :client_decide (client_decide) ) :default (true) ) )
By default, the value is TRUE. Modify the :default (true) line.
Disabling DNS-based Geo-Cluster Name Resolution

Each time Endpoint Connect connects to the Connectra gateway, the client performs, by default, DNS name resolution. For a deployment consisting of a single Connectra gateway, there is no need to perform DNS resolution every time the first time the client connects, it caches the IP address of the gateway and reuses it on each subsequent connect operation. In this kind of deployment, the default behavior of the client can be safely modified. To prevent the gateway from performing name resolution each time Connect connects: 1. On the Connectra gateway, open the $FWDIR/conf/trac_client_1.ttm file for editing. 2. Modify the enable_gw_resolving attribute to FALSE:
:enable_gw_resolving ( :gateway ( :map ( :false (false) :true (true) :client_decide (client_decide) ) :default (true) ) )
By default, the value is TRUE. Modify the :default (true) line.
462
Configuring Endpoint Compliance Checks
However, in a deployment consisting of multiple Connectra gateways, for example in a cluster (load sharing) or primary-backup (high availability) configuration, it is important that the client performs DNS resolution each time it connects to the site. Based on geographical proximity or the load-sharing requirements of the gateway, the DNS server might return to the client a different IP address each time: the IP address of the nearest available gateway. This IP address may not be the same as the IP address cached during the first connect operation. Resolving DNS names each time: Enables DNS to be used for High availability (the IP address of the backup gateway is returned when the primary fails to respond) Adds to the client a functionality similar to MEP (Multiple Entry Points) Note - This is not a regular cluster environment, as the two or more Connectra gateways are
not synchronized.
Configuring Endpoint Compliance Checks

While Endpoint Compliance scanner provides an effective endpoint compliance check when connecting, it might prove resource intensive to the Connectra gateway. For improved speed, it is recommended to scan only for the presence of antivirus and firewall software.
NAT Traversal
When a remote user initiates a VPN (IPSec encrypted) session with the Connectra gateway, during the initial negotiation, both gateway and remote client attempt to detect whether the traffic between them passed through a NAT device. For a number of reasons NAT is incompatible with IPSec: IPSec assures the authenticity of the sender and the integrity of the data by checking to see that the data payload has not been changed in transit. A NAT device alters the IP address of the remote client. The Internet Key Exchange (IKE) protocol used by IPSec embeds the clients IP address in its payload, and this embedded address, when it reaches the Connectra gateway, will fail to match the source address of the packet, which is now that of the NAT device. When addresses dont match, the Connectra Gateway drops the packet. TCP and UDP checksums in the TCP header are sometimes used to verify the packets integrity. The checksum contains the IP addresses of the remote client and gateway, and the port numbers used for the communication. IPSec
NAT Traversal
encrypts the headers with the Encapsulating Security Payload (ESP) protocol. Since the header is encrypted, the NAT device cannot alter it. This results in an invalid checksum. The Connectra gateway again rejects the packet. The Endpoint Connect Client resolves these and other NAT related issues by using NAT-Traversal (NAT-T) as a way of passing IPSec packets through the NAT device. On the Connectra gateway, default ports are: Internet Key Exchange (IKE) - User Datagram Protocol (UDP) on port 500 Note - only IKEv1 is supported IPsec NAT-T - UDP on port 4500 Encapsulating Security Payload (ESP) - Internet Protocol (IP) on 50
If a NAT device is detected during the initial negotiation, communication between gateway and client switches to UDP port 4500. Port 4500 is used for the entire VPN session. Note - NAT-T packets (or the packets of any other protocol) need to return to the client
through the same interface they came in on. While the recommended deployment is to place the Connectra gateway in a public DMZ with a single interface for all traffic, it is also possible to deploy Connectra with inbound and outbound interfaces, the default route being the outbound route towards the Internet. Endpoint Connect only connects to the Connectra gateways default outbound interface.
464
Using the Packaging Tool

Endpoint Connect supports a special administration mode that enables the creation of preconfigured packages. The administrator opens one instance of the client, configures all settings then saves the client as an .msi package for further distribution to end point users. To create a preconfigured package: 1. Open the Endpoint Connect client in administration mode: Click on AdminMode.bat file in c:\Program Files\Checkpoint\Endpoint Connect, or: From a command prompt, run: c:\Program Files\Checkpoint\Endpoint Security\trgui.exe /admin
2. Right-click the client icon in the system tray, and select VPN Options. The VPN Options window opens showing the administration tab:
3. Using the options on the Site and Advanced tabs, configure: Site definitions Authentication method Logging Proxy server settings Always-connect mode
VPN tunneling
4. On the Administration tab: a. Select a folder for the new package b. Decide whether to override the previous configuration when upgrading c. Click Generate to create the .msi package in the designated folder. 5. Distribute this package to Endpoint Connect users. For a direct link to the .msi package to appear on the Native Applications page of the Connectra portal, place the .msi file in the $CVPNDIR/htdocs/SNX/ folder.
466
Chapter Endpoint Connect API

In This Chapter:
Introduction to the Client OPSEC API Function Return Codes Client Functions Communicating with Service Notification Identifiers Functions from Service to Client
19
page 468 page 469 page 470 page 479 page 485
This section covers the OPSEC API for embedded custom client integrations. The API contains functions exported by the TrAPI.dll library, an API infrastructure employed to transfer messages between the client and the tracsrvwrapper service. The API exposes functions that form synchronic actions, for example retrieving the status for a specific connection. The API also contains functions that enable the client to register to receive various notifications from the service. Because the notifications can arrive at any time, these functions are considered asynchronic. API calls to the client block the client until the function completes. When the API calls any API function, the API infrastructure sends the corresponding message to the service and waits for the services response. Function prototypes are defined in the TrAPITypes.h header file. To use the client API, first download the client zip file from the Check Point Support Center. The zip file contains the library file TrAPI.dll, and the header files TrAPITypes.h and TrAPI.h.
467
Introduction to the Client OPSEC API
Introduction to the Client OPSEC API

The client API is C based. Exported functions must have a C-style declaration. To access these API functions from C++, use the extern C declaration. The API supports:
Two General Functions for Error Tracing

TrInitNewExceptionFilter TrCloseExceptionFilter
Use these functions to print the stack when a process terminates unexpectedly.
Functions to transfer messages to the service:

TrAPIInit TrAPIInitDebug TrAPIDebug TrStart TrStop TrIsTracActive TrConnEnum TrConnGetInfo TrConnConnect TrConnCancelConnect TrConnCreate TrConnDelete TrGetInformation TrGetConfiguration TrSetConfiguration TrSendLogs TrGetStatus TrAPIGetVersion TrSendNotification
468
TrRegisterErrorCallback
Functions to Receive Notifications from the Service

Use the following functions to receive notifications from the trac service. All notifications are described in TrAPIType.h. The client can register with the service to receive only specific notifications. By default, the client receives all notifications. TrRegisterNotificationCallback TrUnregisterNotificationCallback

The return codes and numerical equivalents for API Functions are as follows: Function Return Code TrOK TrFAIL TrConnAlreadyConnected TrConnNameAlreadyExisted TrConnAddrAlreadyExisted Equivalent 0 -1000 -999 -998 -997 Meaning... Function executed without error. Function failed. Connect function failed because the client is already connected. Connect function failed because a site with this name already exists. Connect function failed because a site with this IP address already exists. Function failed because a wrong parameter was passed to it. Function failed because of a memory shortage. Function failed to establish communication with the service Function failed to communicate with the service
TrParamsFAIL TrAllocFAIL TrComSendFAIL TrAPIInitFAIL
-996 -995 -994 -993
Chapter 19
Endpoint Connect API 469
Client Functions Communicating with Service
Function Return Code TrICSNoCompliance TrProxyAuthFailed TrProxyAuthRequired
Equivalent -992 -991 -990
Meaning... Function failed because the user failed the end point compliance test. Function failed because proxy authentication failed Function failed because proxy authentication credentials were not presented.

In This Section:
TrAPIInit TrAPIInitDebug TrAPIDebug TrStart TrStop TrIsTracActive TrConnEnum TrConnGetInfo TrConnConnect TrConnCancelConnect TrConnCreate TrConnDelete TrGetInformation TrGetConfiguration TrSetConfiguration TrAPIGetVersion TrSendNotification TrRegisterErrorCallback page 471 page 471 page 471 page 472 page 472 page 472 page 472 page 473 page 474 page 475 page 475 page 475 page 476 page 476 page 477 page 477 page 478 page 478
470
TrAPIInit
The first function called after loading TrAPI.dll. Only run once and before calling any other function. If the service goes down, the function needs to be initialized again.
Prototype TRAPI_CPAPI TrStatus TrAPIInit();
TrAPIInitDebug
This function creates logs.
Prototype TRAPI_CPAPI TrStatus TrAPIInitDebug(TrString filename,int max_size, int max_files,int TopicLevel); Arguments
Argument IN/OUT in in in in Meaning... The name of the log file. Maximum size of log in Bytes. Maximum number of files. The number of topics the logs should contain.
filename max_size max_files TopicLevel
TrAPIDebug
This function writes a text message to the log file.
Prototype TRAPI_CPAPI void TrAPIDebug(const char *TopicNames,int TopicLevel,int err, const char *fmt,...);
Chapter 19
Arguments
Argument IN/OUT in in in in Meaning... the names of topics used in the logs. the number of topics. Error level number, for example fatal error=1, informative error message=5. The text message to be inserted in the log file.
TopicNames TopicLevel err fmt
TrStart
Starts the service.
Prototype TRAPI_CPAPI TrStatus TrStart();
TrStop
Stops the service.
Prototype TRAPI_CPAPI TrStatus TrStop();
TrIsTracActive
Checks whether the trac service is active.
Prototype TRAPI_CPAPI bool TrIsTracActive();
TrConnEnum
Ennumerates all configured sites. Returns a connection handle according to the given index, starting from zero. When there are no more sites in the list, a NULL value is returned.
Prototype TRAPI_CPAPI TrConn TrConnEnum(int connIndex);
472
Arguments
Argument IN/OUT in Meaning... the connection handle representing the connection for the site
connIndex
TrConnGetInfo
According to a given connection handle, this function retrieves information from the connection STRUCT.
Prototype TRAPI_CPAPI TrStatus TrConnGetInfo(TrConn connHandle, TrConnStruct* connStruct);
Chapter 19
Arguments
Argument IN/OUT in out Meaning... The handle for the connection The connection information as contained in the STRUCT:
connHandle TrConnStruct
char mDisplayName[PARAM_MAX_LEN]; the same of the site, as given by the user. char mGwIP[PARAM_MAX_LEN]; the IP address of the sites gateway. char mGwHostname[PARAM_MAX_LEN]; the FQDN of the site. int mConnStatus; the status of the connection: connecting, connected, reconnecting, or terminated (when the service is down). Idle=0. bool mIsActiveSite; TRUE if this connection is the active site, meaning the last site to which the user successfully connected. TrAuthInformation mAuthInfo; the authentication scheme for the given site. TrConn mConnHandle; the connection handle.
TrConnConnect
Connects to the site according to the given connection handle. Also checks to see whether the user cancels the action at any point.
Prototype TRAPI_CPAPI TrStatus TrConnConnect(IN TrConnStruct * connStruct);
474
Arguments
Argument IN/OUT in Meaning... Specifically, only the connhandle and authentication information inside the STRUCT are required.
connStruct
TrConnCancelConnect
Cancels the connection to the given site.
Prototype TRAPI_CPAPI TrStatus Arguments

Argument IN/OUT in Meaning... Handle of the site to cancel.
TrConnCancelConnect(TrConn connHandle);
connHandle
TrConnCreate
Creates a new site according to the data given in connStruct, and returns a connection handle.
Prototype TRAPI_CPAPI TrStatus TrConnCreate(IN TrConnStruct * connStruct); Arguments

Argument IN/OUT in Meaning... the STRUCT that contains the display name, IP address of the sites gateway, and the FQDN.
connStruct
TrConnDelete
Deletes a site according to the given connection handle.
Prototype TRAPI_CPAPI TrStatus TrConnDelete(TrConn connHandle);
Chapter 19
Arguments
Argument IN/OUT in Meaning... the handle of the site to be deleted.
connHandle
TrGetInformation
This function returns a list of all Domain Names. The service obtains the list of DNs from certificates in the certificate store.
Prototype TRAPI_CPAPI TrStatus TrGetInformation(TrParam paramType, TrMsg** pParamValue); Arguments

Argument IN/OUT in Meaning... Two types are available: TR_USE_DN_LIST. Returns list of DNs. TR_ICS_REPORT_FILENAME. Returns location of the compliance check report.
paramType
pParamValue
out
the returned message.
TrGetConfiguration
Retrieves information related to site variables. The function expects an argument list. The first argument must be the IP address of the gateway if referring to a specific gateway, otherwise an empty string. Each argument must be a string that holds the name of the requested configuration variable.
Prototype TRAPI_CPAPI TrStatus pConfiguration); TrGetConfiguration(TrMsg* pParams, TrMsg **
476
Arguments
Argument IN/OUT in out Meaning... Message that contains attributes to retrieve, such as default time out. Returns requested attribute
pParams pConfiguration
TrSetConfiguration
This function saves the users configuration as an attribute / value pair, for example: Attribute IP Address Authentication scheme The function expects an argument list. The first argument must be the IP address of the gateway if referring to a specific gateway, otherwise an empty string. Each argument must be a string that holds the name of the attribute. Value 192.168.x.x
Prototype TRAPI_CPAPI TrStatus TrSetConfiguration(TrMsg* pConfiguration); Arguments

Argument IN/OUT in Meaning... configuration to be stored.
pConfiguration
TrAPIGetVersion
Returns the client version.
Prototype TRAPI_CPAPI TrStatus TrAPIGetVersion(TrVersion* version);
Chapter 19
Arguments
Argument IN/OUT out Meaning... Returns major version, minor version, and build number
version
TrSendNotification
Sends a notification from the client to the service. All notifications are described in TrAPIType.h. The client can register with the service to receive only specific notifications. By default, the client receives all notifications.
Prototype TRAPI_CPAPI TrStatus TrSendNotification(TrNotification * pClientNotification); Arguments

Argument IN/OUT in Meaning... Notifications to send to the service.
pClientNotification
TrRegisterErrorCallback
When communication with the service is lost, the client registers a callback to be called by TrAPI.dll.
Prototype TRAPI_CPAPI void TrRegisterErrorCallback(ErrorCbFunctor cb, void* clientOpaque);
478
Notification Identifiers
Arguments
Argument IN/OUT in in Meaning... the registered callback clients opaque to the callback
ErrorCbFunctor cb clientOpaque
TrNotificationID
Identifiers for each notification.
Prototype enum TrNotificationID
NotificationID
TR_NOTIFICATION_NETWORK_OUT TR_NOTIFICATION_NETWORK_IN TR_NOTIFICATION_NETWORK_NO_ NETWORK TR_NOTIFICATION_CONNECTION_ DISCONNECTED
Meaning and Format... The client is located outside of the VPN domain The client is located within the VPN domain No network available Connection disconnected Disconnect reason: type - eTrArgTypeStr val - a string representing the disconnect reason default_text - NULL Reconnecting Reconnecting reason: type - eTrArgTypeStr val - a string representing the reconnecting reason default_text - NULL
TR_NOTIFICATION_CONNECTION_ RECONNECTING
Chapter 19
NotificationID
TR_NOTIFICATION_TRAC_STOP TR_NOTIFICATION_LOG
Meaning and Format... Service is stopped Logs message Log string: type - eTrArgTypeStr val - the log's string default_text - NULL Client upgrade is required. upgrade string type - eTrArgTypeStr val - the upgrade's string default_text - NULL Upgrade notification sent by the client to the service. Perform upgrade type - eTrArgTypeInt32 val - an integer represents whether the user wishes to upgrade: 1 for upgrade, 0 for no_upgrade. default_text - NULL End point failed the endpoint compliance test
TR_NOTIFICATION_UPGRADE
TR_NOTIFICATION_CLIENT_UPGR ADE
TR_NOTIFICATION_ICS_NO_COMP LIANCE
480
NotificationID
TR_NOTIFICATION_AUTH_SUPPLY _CREDS
Meaning and Format... Supply authentication credentials. The number of arguments depends on the authentication scheme: 1. GW: type - eTrArgTypeStr val - a string representing the gateways name default_text - NULL 2. Authentication type (TrAuthType): type - eTrArgTypeInt32 val - an integer represents the authentication type default_text - NULL 3. Number of parameters: type - eTrArgTypeInt32 val - an integer represents the number of parameters (e.g. 2 for username+password, 1 for certificate dn, 3 for username+pin+passcode) default_text - NULL #) Param number # type - eTrArgTypeStr val - a string representing the parameter (e.g. "username" or "passcode", etc) default_text - NULL
Chapter 19
NotificationID
TR_NOTIFICATION_CLIENT_CRED ENTIALS
Meaning and Format... Authentication credentials sent from the client to the service. The number of arguments depends on the authentication scheme. 1. Gateway type - eTrArgTypeStr val - a string representing the gateway's ip address default_text - NULL 2. Authentication type (TrAuthType): type - eTrArgTypeInt32 val - an integer represents the authentication type default_text - NULL 3. Number of values: type - eTrArgTypeInt32 val - an integer represents the number of values (e.g. 2 for username+password, 1 for certificate dn, 3 for username+pin+passcode) default_text - NULL #) Value number # type - eTrArgTypeStr val - a string representing the value (e.g. the username value, the pin code value, etc) default_text - NULL
482
NotificationID
TR_NOTIFICATION_CONNECTION_ PROGRESS
Meaning and Format... Progress of the connection operation. Takes six arguments: 1. Flows type: type - eTrArgTypeInt32 val - an integer indicating the flow type: PRIMARY_CONN_FLOW = 0 RECONNECT_FLOW = 1 DISCONNECT_FLOW = 2 DOWNLOAD_CL_SETTINGS_FLOW =3 default_text - NULL 2. Steps status: val - an integer indicating the TrStatus of the step default_text - NULL 3. Steps name: type - eTrArgTypeStr val - a string representing the step's name default_text - NULL 4. Steps reason for error: type - eTrArgTypeStr val -a string representing the reason for the step's failure. This value is only relevant when the step fails. If the step's status is success, this value equals to the empty string. default_text - NULL
Chapter 19
NotificationID
Meaning and Format... 5. Total progress: type - eTrArgTypeInt32 val - an integer indicating the connect progress in percentages default_text - NUL 6. Next steps name: type - eTrArgTypeStr val - a string representing the next step's name (empty string if this is the last step) default_text - NULL
484
Functions from Service to Client

In This Section:
TrRegisterNotificationCallback TrUnregisterNotificationCallback TrMsgCreate TrMsgConstruct TrMsgDestroy TrMsgGetVersion TrMsgGetID TrMsgGetDefaultMsg TrMsgArgIterCreate TrMsgArgIterDestroy TrNotificationArgIterGetArgNum TrMsgArgIterGetNextArg TrMsgSetIntArg TrMsgSetStrArg TrNotificationConstruct TrNotificationGetID TrNotificationClone TrNotificationDestroy TrNotificationArgIterCreate TrNotificationArgIterGetArgNum TrNotificationArgIterGetNextArg TrNotificationSetIntArg TrNotificationSetStrArg TrNotificationSetDoubleArg TrArgGetType TrArgGetIntVal TrArgGetDoubleVal TrArgGetStrVal TrArgGetDefText page 486 page 488 page 488 page 488 page 489 page 489 page 490 page 490 page 490 page 491 page 495 page 491 page 492 page 492 page 493 page 493 page 494 page 494 page 494 page 495 page 496 page 496 page 497 page 497 page 498 page 498 page 499 page 499 page 499
Chapter 19
The various types of notifications are described in TrAPITypes.h.
TrRegisterNotificationCallback
This function registers with the service notifications to be sent to the client.
Prototype TRAPI_CPAPI TrStatus TrRegisterNotificationCallback(NotificationCbFunctor cb,void* clientOpaque, int eNotificationType = TR_NOTIFICATION_ALL);
486
Arguments
Argument IN/OUT in in in Meaning... the registered callback clients opaque. the notification type: TR_NOTIFICATION_NETWORK_TYPE = (1<<16) TR_NOTIFICATION_CONNECTION_TY PE = (1<<17) TR_NOTIFICATION_SUGGEST_CONNE CT_TYPE = (1<<18) TR_NOTIFICATION_TRAC_STOP_TYPE = (1<<19) TR_NOTIFICATION_LOG_TYPE = (1<<20) TR_NOTIFICATION_AUTH_TYPE = (1<<21) TR_NOTIFICATION_DOWNLOAD_TYPE = (1<<22) TR_NOTIFICATION_CLIENT_TYPE = (1<<23) TR_NOTIFICATION_ICS_TYPE = (1<<24) TR_NOTIFICATION_ALL = 32767 << 16
NotificationCbFunctor cb clientOpaque eNotificationType
For example, to receive only notifications of type network, connection and stop notifications then eNotificationType should be equal to: TR_NOTIFICATION_NETWORK_TYPE | TR_NOTIFICATION_CONNECTION_TYP E| TR_NOTIFICATION_TRAC_STOP_TYPE
Chapter 19
TrUnregisterNotificationCallback
Unregisters the notification callback.
Prototype TRAPI_CPAPI TrStatus TrUnregisterNotificationCallback();
TrMsgCreate
This function creates an array of parameters included in the message.
Prototype TRAPI_CPAPI TrMsg* TrMsgCreate(int version, char *ID, char *def_msg, unsigned int arguments_num,...); Arguments
Argument IN/OUT in in in in Meaning... version number of the message ID of the message The message text Number of parameters
version ID def_msg arguments_num,...
Currently, these arguments should be zero or empty strings.
TrMsgConstruct
This function creates a message without arguments.
Prototype TRAPI_CPAPI TrMsg *TrMsgConstruct(int version, char *ID, char *def_msg, unsigned int arguments_num);
488
Arguments
Argument IN/OUT in in in in Meaning... Version number of the message ID of the message The message text Number of parameters
version ID def_msg arguments_num
TrMsgDestroy
This function destroys a given message.
Prototype TRAPI_CPAPI void Arguments

Argument IN/OUT in Meaning... the message to destroy
TrMsgDestroy(TrMsg *message);
message
TrMsgGetVersion
This function gets the version of a given message.
Prototype TRAPI_CPAPI TrStatus TrMsgGetVersion(TrMsg *message, int *version); Arguments

Argument IN/OUT in out Meaning... the message to destroy version number of the message
message version
Chapter 19
TrMsgGetID
This function gets the ID of the message.
Prototype TRAPI_CPAPI TrStatus TrMsgGetID(TrMsg *message, char **ID); Arguments

Argument IN/OUT in out Meaning... the message ID of the message
message ID
Currently, these arguments should be empty strings.
TrMsgGetDefaultMsg
This function fills the given message, and returns the status of the operation.
Prototype TRAPI_CPAPI TrStatus TrMsgGetDefaultMsg(TrMsg *message, char **def_msg); Arguments

Argument IN/OUT in out Meaning... Given message Return message
message def_msg
Currently, these arguments should be empty strings.
TrMsgArgIterCreate
This function creates an iterator for a given message, returns NULL for failure.
Prototype TRAPI_CPAPI TrMsgArgIter *TrMsgArgIterCreate(TrMsg *message);
490
Arguments
Argument IN/OUT in Meaning... Given message
message
TrMsgArgIterDestroy
This function destroys an iterator.
Prototype TRAPI_CPAPI void TrMsgArgIterDestroy(TrMsgArgIter *iter); Arguments

Argument IN/OUT in Meaning... the iterator
iter
TrMsgArgIterGetArgNum
This function fills the argument number, and returns the status of the operation.
Prototype TRAPI_CPAPI TrStatus TrMsgArgIterGetArgNum(TrMsgArgIter *iter, int *arg_num); Arguments

Argument IN/OUT in out Meaning... the iterator to get number of arguments
iter arg_num
TrMsgArgIterGetNextArg
This functions fills the next TrArg in theTrMsg. If there are no more TrArgs, fills arg with NULL, and the return code is TrOK. If the function fails, an appropriate TrStatus error code is returned, and arg is NULL.
Chapter 19
Prototype TRAPI_CPAPI TrStatus TrMsgArgIterGetNextArg(TrMsgArgIter *iter, TrArg **arg); Arguments

Argument IN/OUT in out Meaning... the iterator the next argument
iter arg
TrMsgSetIntArg
This function sets the argument in the given position to int argument, and overrides the current argument that exists in the given position.
Prototype TRAPI_CPAPI TrStatus TrMsgSetIntArg(TrMsg *message,int pos, int val, char * default_txt); Arguments
Argument IN/OUT in in in in Meaning... the message position of the message value of the message the message text
message pos
val default_text
TrMsgSetStrArg
This function sets the argument in the given position to a str argument, and overrides the current argument that exists in the given position.
Prototype TRAPI_CPAPI TrStatus TrMsgSetStrArg(TrMsg *message, int pos, char * val, char * default_txt);
492
Arguments
Argument IN/OUT in in in in Meaning... the message the position of the message the value of the message the message text
message pos
val default_text
TrNotificationConstruct
This function creates a new TrNotification, and return NULL upon error.
Prototype TRAPI_CPAPI TrNotification* TrNotificationConstruct(TrNotificationID ID, unsigned int arguments_num); Arguments

Argument IN/OUT in in Meaning... ID of the notification number of arguments
ID arguments_num
TrNotificationGetID
This function fills the notification ID, and return the status of the operation.
Prototype TRAPI_CPAPI TrStatus TrNotificationGetID(TrNotification *notification, TrNotificationID *ID);
Chapter 19
Arguments
Argument IN/OUT in out Meaning... the given notification the ID of the notification
notification ID
TrNotificationClone
This function clones a given TrNotification Prototype
TRAPI_CPAPI TrNotification* *notification); Arguments

Argument IN/OUT in
TrNotificationClone(TrNotification
Meaning... the notification to be cloned
notification
TrNotificationDestroy
This function destroys a given TrNotification
Prototype TRAPI_CPAPI void TrNotificationDestroy(TrNotification *notification); Arguments

Argument IN/OUT in Meaning... the notification to be destroyed
notification
TrNotificationArgIterCreate
This function creates a TrNotificationArgIter for a given notification, and returns NULL on failure.
494
Prototype TRAPI_CPAPI TrNotificationArgIter *TrNotificationArgIterCreate(TrNotification * notification); Arguments

Argument IN/OUT in Meaning... the given notification
notification
TrNotificationArgIterDestroy
This function destroys a given TrNotificationArgIter.
Prototype TRAPI_CPAPI void TrNotificationArgIterDestroy(TrNotificationArgIter *iter); Arguments

Argument IN/OUT in Meaning... the iterator
iter
TrNotificationArgIterGetArgNum
This function fills the argument number, and returns the status of the operation.
Prototype TRAPI_CPAPI TrStatus TrNotificationArgIterGetArgNum(TrNotificationArgIter *iter, int *arg_num);
Chapter 19
Arguments
Argument IN/OUT in in Meaning... the iterator the number of arguments
iter
arg_num
TrNotificationArgIterGetNextArg
This function fills the next TrArg in the TrNotification. When there are no more TrArgs, arg is filled with NULL, and the return code is TrOK. When failure occurs, the function returns the appropriate TrStatus error code, and arg is NULL.
Prototype TRAPI_CPAPI TrStatus TrNotificationArgIterGetNextArg(TrNotificationArgIter *iter, TrArg **arg); Arguments

Argument IN/OUT in in Meaning... the iterator the argument
iter
arg
TrNotificationSetIntArg
This function sets the argument in the given position to int argument, and overrides the current argument that exists in the given position.
Prototype TRAPI_CPAPI TrStatus TrNotificationSetIntArg(TrNotification *notification,int pos, int val, char * default_txt);
496
Arguments
Argument IN/OUT in in in in Meaning... the given notification position of the notification the value of the notification notification text
notification pos val default_text
TrNotificationSetStrArg
This function sets the argument in the given position to str argument, and overrides the current argument that exists in the given position.
Prototype TRAPI_CPAPI TrStatus TrNotificationSetStrArg(TrNotification *notification, int pos, const char * val, char * default_txt); Arguments
Argument IN/OUT in in in in Meaning... the given notification position of the notification value of the notification notification text
TrNotificationSetDoubleArg
This function sets the argument in the given position to double argument, and overrides the current argument that exists in the given position.
Prototype TRAPI_CPAPI TrStatus TrNotificationSetDoubleArg(TrNotification *notification, int pos, double val, char * default_txt);
Chapter 19
Arguments
Argument IN/OUT in in in in Meaning... the given notification position of the notification value of the notification notification text
TrArgGetType
This functions fills the TrArg type, and returns the status of the operation.
Prototype TRAPI_CPAPI TrStatus TrArgGetType(TrArg *arg, TrArgType *type); Arguments

Argument IN/OUT in out Meaning... the argument the argument type: string, int, double etc.
arg type
TrArgGetIntVal
This functions fills the int value, and returns the status of the operation. If TrArg is not an int, an error is returned.
Prototype TRAPI_CPAPI TrStatus TrArgGetIntVal(TrArg *arg, int *val);
498
Arguments
Argument IN/OUT in out Meaning... the argument value of the argument
arg val
TrArgGetDoubleVal
This function fills the double value, and return the status of the operation. If TrArg is not double, an error is returned.
Prototype TRAPI_CPAPI TrStatus TrArgGetDoubleVal(TrArg *arg, double *val); Arguments

Argument IN/OUT in out Meaning... the argument value of the argument
arg val
TrArgGetStrVal
This function fills the string value, and returns the status of the operation. If TrArg is not a string, an error is returned.
Prototype TRAPI_CPAPI TrStatus TrArgGetStrVal(TrArg* arg, char **str); Arguments

Argument IN/OUT in out Meaning... the argument the value of the string
arg str
TrArgGetDefText
This function fills the TrArg default text, and returns the status of the operation.
Chapter 19
Prototype TRAPI_CPAPI TrStatus TrArgGetDefText(TrArg *arg, char **def_text); Arguments

Argument IN/OUT in out Meaning... the argument the default text
arg def_text
500
Index
Numerics
3DES 387, 407 CAB Package 373, 431 Uninstall 375 cable failure 285 Certificates 394 Certified embedded applications 124 Citrix Configuring 71 Services 66 Troubleshooting 326 Client Installation 372 Client Side Security 180 Client Side Security Highlights 37 Cluster configuration in SmartDashboard 295 preparing the machines 293 ClusterXL for Connectra 265 command expert 350 Command Line Interface 345 Compression concept 262 configuration 263 Configuring Authentication 177 Authentication and Authorization 177 Connectra what is it? 28
E
Email Services 78 Embedded applications 123 add-on 124 certified 124 configuring 138 Endpoint Compliance Internet Explorer settings 209 Endpoint Compliance Scanner 33 end-user Experience 208 Enforcement Mode 358 Error Messages 421 Expert Mode 350
A
Accessing Applications 40 accounting synchronization 273 ActiveSync 373, 374, 408 Add-on embedded applications 124 Application Request Mode 383 Applications 43, 89, 107 accessing 40 Associating Citrix Applications with User Groups 76 File Shares with User Groups 64 Mail Services with User Groups 60 mail services with user groups 83 Web Applications with User Groups 58 Authentication 33 Authentication & Authorization 157, 173 Authorization 33, 175 Automatic Connect 383
F
failover definition 266 when does it occur 285 File shares configuration of 60 File shares in Connectra 60 Firewall Policy 389 FTP 125 FTP embedded application 144
G D
Gateway History 358 Data compression concept 262 configuration 263 Digest authentication limitation 92 support 91
B
Basic authentication 91
H
Hub Mode 409
C
CAB file 426 January 2009
501
I
Initial Setup 40 interface failure 285 Internal CA Certificates 394 IP change of a standalone gateway 260, 306
P
Protection Level 34 editing 46 Protection-levels configuring 45 PuTTY 125 embedded application 143
J
Jabber 125 Jabber embedded application 143
R
RC4 387, 407 Re-authenticate Users 382 Remote Access Community 369 Remote Desktop 125
Telnet embedded application 139 Terminal (Putty) 125 TN3270 124 embedded application 140 TN5250 124 embedded application 141 Topology Update 396 Transform Template Files (TTM) 398 Troubleshooting 309 Citrix 326
U
User Workflow 38
M
Mail services configuration of 80 definition 78 MSI Package 373, 374
S
Scanning the Client Machine 213 Scripts running automatically 135 Secure Workspace Client-side security 37 Concept 34 Configuration 216 SecureClient Mobile and SSL Network Extender 112 SecurID 380 Security Features 36 Server Side Security Highlights 36 Session 35 Signing In 38 SSH 124 SSH embedded application 140 SSL Network Extender 32 SSL Network Extender Mode 358 Sticky Decision Function 369 Synchronization restrictions 273
V
Visitor Mode 368
N
Native Applications associating with User Groups 129 configuring 127 explained 108 Network drives automatically maping 135, 136 NTLM authentication support 91
W
Web Applications 49 Web applications configuration 50 explained 48 Web Intelligence automatically disabled protections 343 Webmail definition 78 Workflow 38
O
Office mode 116 Outlook Web Access configuring 50 features 50 troubleshooting 311
T
Telnet 124
502

Check Point Connectra NGX R66 CM Admin Guide

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Check Point Connectra NGX R66 CM Admin Guide

Caricato da

Copyright:

Formati disponibili

Connectra Central Management

Administration Guide Version NGX R66

January 11, 2009

2003-2009 Check Point Software Technologies Ltd.

Applications for Clientless Access

Native Applications for Client-Based Access

Endpoint Security On Demand

Connectra Gateway Configuration

Connectra Gateway Clusters

SecurePlatform CLI Reference

SecureClient Mobile - VPN Client

SecureClient Mobile Installation and Setup

Central Management of SecureClient Mobile

SecureClient Mobile Client Configuration

SecureClient Mobile Package Management

SecureClient Mobile Client API

Endpoint Connect - VPN Client

Endpoint Connect API

Who Should Use This Guide

Who Should Use This Guide

Section 1 Connectra Gateway

Chapter 7, Endpoint Security On Demand

Chapter 8, Connectra Gateway Configuration

Section 2: SecureClient Mobile

Chapter Chapter 9, Connectra Gateway Clusters

Chapter 10, Troubleshooting Connectra

Chapter 11, SecurePlatform CLI Reference

Section 2: SecureClient Mobile

Section 3: Endpoint Connect

Section 3: Endpoint Connect

Title Internet Security Product Suite Getting Started Guide

SmartCenter Administration Guide

Firewall and SmartDefense Administration Guide

Virtual Private Networks Administration Guide

Title Eventia Reporter Administration Guide

SecurePlatform/ SecurePlatform Pro Administration Guide

Provider-1/SiteManager-1 Administration Guide

Chapter Introduction to Connectra

Features: Unified, flexible remote access Unified security management

SSL Network Extender

SSL Network Extender

SSL Network Extender Network Mode

SSL Network Extender Application Mode

Commonly Used Concepts

Commonly Used Concepts

Endpoint Compliance Scanner

Connectra Security Features

Connectra Security Features

Server Side Security Highlights

Client Side Security Highlights

Client Side Security Highlights

First time Installation of ActiveX and Java Components

First time Installation of ActiveX and Java Components

Getting Started With Connectra

Getting Started With Connectra

2 Chapter Applications for Clientless Access

Using Protection Levels

Applications for Clientless Access

Defining Protection Levels

Defining Protection Levels

Defining Protection Levels

Applications for Clientless Access

What is a Web Application?