Check Point Connectra NGX R66 CM Admin Guide

Connectra Central ManagementAdministration Guide

Version NGX R66

January 11, 2009

TM

© 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.

http://www.checkpoint.com/copyright.html

http://www.checkpoint.com/3rd_party_copyright.html

Table of Contents 5

Contents

Preface Who Should Use This Guide.............................................................................. 16Summary of Contents ....................................................................................... 17

Section 1 Connectra Gateway....................................................................... 17Section 2: SecureClient Mobile .................................................................... 18Section 3: Endpoint Connect ....................................................................... 19

Related Documentation .................................................................................... 20More Information ............................................................................................. 22Feedback ........................................................................................................ 23

Connectra Gateway

Chapter 1 Introduction to Connectra Overview of Connectra ...................................................................................... 28Connectra Applications..................................................................................... 30Connectra Management .................................................................................... 31SSL Network Extender...................................................................................... 32

SSL Network Extender Network Mode ........................................................... 32SSL Network Extender Application Mode....................................................... 32

Commonly Used Concepts ................................................................................ 33Authentication............................................................................................ 33Authorization.............................................................................................. 33Endpoint Compliance Scanner ..................................................................... 33Secure Workspace....................................................................................... 34Protection Levels ........................................................................................ 34Session...................................................................................................... 35

Connectra Security Features ............................................................................. 36Server Side Security Highlights .................................................................... 36Client Side Security Highlights..................................................................... 37

User Workflow ................................................................................................. 38Signing In .................................................................................................. 38First time Installation of ActiveX and Java Components .................................. 39Language Selection..................................................................................... 40Initial Setup ............................................................................................... 40Accessing Applications................................................................................ 40

Getting Started With Connectra ......................................................................... 42

Chapter 2 Applications for Clientless Access Introduction to Applications.............................................................................. 44

6

Protection Levels ............................................................................................. 45Using Protection Levels ............................................................................... 45Defining Protection Levels ........................................................................... 46

Web Applications............................................................................................. 48What is a Web Application? ......................................................................... 48Connectra Web Applications ........................................................................ 49Web Applications of a Specific Type ............................................................. 49Configuring Web Applications ...................................................................... 50

File Shares...................................................................................................... 60What is a File Share? .................................................................................. 60File Share Viewers ...................................................................................... 60Configuring File Shares ............................................................................... 60Using the $$user Variable in File Shares....................................................... 64

Citrix Services ................................................................................................. 66Understanding Citrix Services ...................................................................... 66Citrix Deployments Modes - Unticketed and Ticketed ..................................... 66Citrix features Supported by Connectra ......................................................... 68Configuring Citrix Services ........................................................................... 71

Web Mail Services ........................................................................................... 78Connectra Web Mail Services ....................................................................... 78Web Mail Services User Experience .............................................................. 79Incoming (IMAP) and Outgoing (SMTP) Mail Servers ...................................... 80Configuring Mail Services ............................................................................ 80

Native Applications.......................................................................................... 84DNS Names .................................................................................................... 85

Why Use DNS Name Objects? ...................................................................... 85DNS Names and Aliases .............................................................................. 85Where DNS Name Objects are Used ............................................................. 86Defining the DNS Server used by Connectra .................................................. 86Configuring 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 .......................................................................... 90Supported SSO Authentication protocols............................................................ 91HTTP Based SSO............................................................................................. 92

HTTP Based SSO Limitation ........................................................................ 92Web Form Based SSO ...................................................................................... 93

Application Requirements for Easy Configuration ........................................... 94Web Form Based SSO Limitations ................................................................ 94

Application and Client Support for SSO ............................................................. 95Connectra Applications that Support SSO ..................................................... 95Applications that Support Web Form SSO ..................................................... 95Connectra Client Support for SSO................................................................. 95

Basic Configuration of SSO............................................................................... 96Basic Configuration of Web Form SSO .......................................................... 97

Advanced Configuration of SSO......................................................................... 98Configuring the Single Sign On Method......................................................... 98

Table of Contents 7

Configuring Login Settings........................................................................... 99Advanced Configuration of Web Form SSO ....................................................... 102

Sign In Success or Failure Detection........................................................... 102Credential Handling .................................................................................. 103

Chapter 4 Native Applications for Client-Based Access Introduction to Native Applications.................................................................. 108VPN Clients................................................................................................... 109

SSL Network Extender............................................................................... 109SecureClient Mobile.................................................................................. 112Endpoint Connect ..................................................................................... 113

Configuring VPN Clients ................................................................................. 114Basic VPN Client Configuration .................................................................. 114Advanced VPN Client configuration............................................................. 115Configuring SSL Network Extender Advanced Options .................................. 117Configuring SecureClient Mobile ................................................................ 119

Endpoint Application Types ............................................................................ 122Application Installed on Endpoint Machine.................................................. 122Application Runs Via a Default Browser....................................................... 122Application Downloaded From Connectra..................................................... 123Ensuring the Link Appears in the End-User Browser ..................................... 125

Configuring a Simple Native Application .......................................................... 127General Properties .................................................................................... 127Authorized Locations................................................................................. 127Applications on the Endpoint Machine ........................................................ 128Completing the Native Application Configuration ......................................... 129

Configuring an Advanced Native Application..................................................... 130Configuring Connection Direction ............................................................... 130Multiple Hosts and Services....................................................................... 131Configuring the Endpoint Application to Run Via a Default Browser ............... 132Automatically Starting the Application ........................................................ 133Making an Application Available in Application Mode ................................... 134Automatically Running Commands or Scripts............................................... 135

Configuring Downloaded-From-Connectra Endpoint Applications ........................ 138Configuring the Telnet Client (Certified Application)..................................... 139Configuring the SSH Client (Certified Application) ....................................... 140Configuring the TN3270 Client (Certified Application).................................. 140Configuring the TN5250 Client (Certified Application).................................. 141Configuring the Remote Desktop Client (Add-On Application)........................ 141Configuring the PuTTY Client (Add-On Application) ...................................... 143Configuring the Jabber Client (Add-On Application)...................................... 143Configuring the FTP Client (Add-On Application).......................................... 144

Adding a New Downloaded-From-Connectra Endpoint Application ...................... 145Downloaded-from-Connectra Application Requirements ................................ 145Procedure: Adding a New Downloaded-From-Connectra Application ............... 145Example: Adding a New SSH Application .................................................... 148Example: Adding a New Microsoft Remote Desktop Profile............................ 150

8

Chapter 5 Two-Factor Authentication Introduction to Two-Factor Authentication........................................................ 158The SMS Service Provider............................................................................... 159SMS Authentication Granularity ...................................................................... 160Basic Two-Factor Authentication Configuration ................................................. 161

Obtaining the SMS provider credentials ...................................................... 161Configuring the Phone Directory ................................................................. 161Basic SmartDashboard Configuration of Two-Factor Authentication................ 164Testing Two-Factor Authentication.............................................................. 165

Advanced Two-Factor Authentication Configuration ........................................... 166Advanced Two-Factor Authentication Configuration Options .......................... 166Two-Factor Authentication Per Gateway (Central management only) ............... 169Two-Factor Authentication Per Application .................................................. 170

Chapter 6 Authorization Identity and Access Management .................................................................... 174Authorization in Connectra.............................................................................. 175Configuring Access To Applications ................................................................. 177

Chapter 7 Endpoint Security On Demand Endpoint Compliance Enforcement.................................................................. 180

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

Secure Workspace ......................................................................................... 215Introduction to Secure Workspace .............................................................. 215Enabling Secure Workspace ....................................................................... 216Applications Permitted by Secure Workspace............................................... 217SSL Network Extender in Secure Workspace................................................ 219Secure Workspace Policy Overview ............................................................. 219Configuring the Secure Workspace Policy .................................................... 221Secure Workspace End-User Experience...................................................... 226

Endpoint Compliance Updates ........................................................................ 231Working with Automatic Updates................................................................ 231Performing Manual Updates....................................................................... 233

Chapter 8 Connectra Gateway Configuration Portal Settings............................................................................................... 236

Portal Customization ................................................................................. 236Alternative Portal Configuration.................................................................. 238

Link Translation............................................................................................. 239

Table of Contents 9

Introduction to Hostname Translation ......................................................... 239Link Translation Per Gateway or Per Application .......................................... 240How Hostname Translation Works............................................................... 240Configuring Link Translation ...................................................................... 242Portal Access with Hostname Translation .................................................... 245Link Translation Issues.............................................................................. 246

Connectra Server Certificates .......................................................................... 247Overview of Server Certificates ................................................................... 247Obtaining and Installing a Trusted Server Certificate .................................... 247Connectra Self-Signed Certificates.............................................................. 250Viewing Connectra Certificate Details.......................................................... 252

Session Settings ............................................................................................ 254Simultaneous Logins to the Portal .............................................................. 254Session Timeouts...................................................................................... 258Roaming .................................................................................................. 258Tracking................................................................................................... 258Securing Authentication Credentials ........................................................... 258

Changing the IP Address of a Connectra Gateway or Cluster ............................... 260At the local machine ................................................................................. 260Using SmartDashboard.............................................................................. 260

VPN Client and Portal Connectivity in a Single Gateway..................................... 261Web Data compression ................................................................................... 262

Understanding Web Data compression ........................................................ 262Configuring Data Compression.................................................................... 263

Chapter 9 Connectra Gateway Clusters The Connectra Gateway Clustering Solution ...................................................... 266

Clustering Definitions and Terms................................................................ 266Load Sharing............................................................................................ 268High Availability ....................................................................................... 268Comparing Load sharing and High Availability ............................................. 268

Geo-Clustering of Connectra Gateways ............................................................. 270Connectra Cluster installation and Licensing Requirements................................ 271Synchronization Between Cluster Members....................................................... 272

Introduction to State Synchronization ......................................................... 272The Synchronization Network ..................................................................... 272Synchronized Cluster Restriction ................................................................ 273

Connectra Cluster Topology............................................................................. 274Example Connectra Gateway Cluster Topology.............................................. 274Cluster Interfaces ..................................................................................... 274SSL Client and Portal Connectivity in a Cluster ............................................ 275The Cluster Member IPs ............................................................................ 276Configuring Member Networks.................................................................... 276The Synchronization Network ..................................................................... 277

How Connectra Clusters Work ......................................................................... 278The Cluster Control Protocol....................................................................... 278How Load Sharing Mode Works .................................................................. 278How High Availability Mode Works.............................................................. 280

10

The Sticky Decision Function.......................................................................... 283Failover ........................................................................................................ 284

What is a Failover?.................................................................................... 284What Happens When Failover Occurs? ........................................................ 284When Does a Failover Occur? ..................................................................... 285Cluster Member Priority............................................................................. 286What Happens When a Cluster Member Recovers? ....................................... 286How a Recovered Cluster Member Obtains the Security Policy....................... 286How Connectra Applications Behave Upon Failover ...................................... 287

Hardware Requirements and Compatibility ....................................................... 289Connectra Cluster Hardware Requirements .................................................. 289Connectra Cluster Hardware Compatibility................................................... 290Example configuration of a Cisco Catalyst Routing Switch............................. 291

Basic Connectra Cluster Configuration ............................................................. 293Cluster Configuration — Deployment Tips ................................................... 293Configuring Cluster Member IP Addresses ................................................... 294If the Switch is Incapable of Forwarding Multicast ....................................... 294SmartDashboard Configuration of a Single Cluster Interface Cluster............... 295Adding a Server Certificate to a New Cluster Member ................................... 301

Advanced Connectra Cluster Configuration ....................................................... 303SmartDashboard Configuration of a Dual Cluster Interface Cluster ................. 303IP Address Migration................................................................................. 306Changing the IP Address of a Connectra Cluster or Single Gateway ................ 306Setting Up the Default Gateway if the Virtual IP is on a Different Subnet than the

Physical IPs........................................................................................... 307Removing a Member from a Cluster ............................................................ 307

Chapter 10 Troubleshooting Connectra Troubleshooting Web Connectivity ................................................................... 310Troubleshooting Outlook Web Access .............................................................. 311

Troubleshooting Checklist.......................................................................... 311Unsupported Feature List .......................................................................... 312Common OWA problems ............................................................................ 3121. Authentication...................................................................................... 3132. Authorization........................................................................................ 3153. Security Restrictions ............................................................................. 3184. Performance Issues............................................................................... 3205. Saving File Attachments........................................................................ 324

Troubleshooting File Shares ............................................................................ 325Troubleshooting Citrix .................................................................................... 326

Troubleshooting Checklist.......................................................................... 326Common Connectra Citrix problems ............................................................ 327

Troubleshooting SSL Network Extender Connectivity ......................................... 341General SSL Network Extender Issues......................................................... 341SSL Network Extender Application Mode Issues........................................... 341

Ensuring Application Connectivity with Web Intelligence ................................... 343

Table of Contents 11

Chapter 11 SecurePlatform CLI Reference Check Point SecurePlatform Overview.............................................................. 346Managing SecurePlatform............................................................................... 347

Standard Mode ......................................................................................... 347Expert Mode............................................................................................. 347

Copying Files Using SCP ................................................................................ 348Secure Shell.................................................................................................. 349SecurePlatform Shell Commands .................................................................... 350

Expert Mode Command ............................................................................. 350Backup and Restore .................................................................................. 350Snapshot Image Management .................................................................... 351Web Administration Server Control ............................................................. 352Check Point Commands............................................................................. 353Network Diagnostics Commands................................................................. 354

SecureClient Mobile - VPN Client

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

Chapter 13 SecureClient Mobile Installation and Setup Gateway Setup .............................................................................................. 364

Overview .................................................................................................. 364Requirements for Central Management ....................................................... 365Setting Up SecureClient Mobile Support for Connectra Gateways................... 366Setting Up SecureClient Mobile Support for VPN-1 Gateways........................ 367

Client Installation .......................................................................................... 372Client Deployment Overview....................................................................... 372Supported Platforms ................................................................................. 372Installation Prerequisites ........................................................................... 373Installing SecureClient Mobile.................................................................... 373Importing Personal Certificate .................................................................... 375Uninstalling SecureClient Mobile................................................................ 375

Chapter 14 Central Management of SecureClient Mobile Introduction .................................................................................................. 378Authentication Settings .................................................................................. 379

Supported Authentication Schemes ............................................................ 379Configuring the Authentication Method ....................................................... 380Password Caching ..................................................................................... 381

12

Authentication Timeout ............................................................................. 382Connectivity Settings ..................................................................................... 383

Connect Mode .......................................................................................... 383Automatic Dialup Initiation........................................................................ 385Automatic Disconnect ............................................................................... 386Encryption Methods .................................................................................. 387

Routing All Traffic To the Gateway (Hub Mode) ................................................ 388Firewall Policy ............................................................................................... 389Configuration and Version Management ........................................................... 392Certificates ................................................................................................... 394

Certificate Nickname................................................................................. 394Management of Internal CA Certificates ...................................................... 394Importing a Certificate in the Device........................................................... 395

Topology Update............................................................................................ 396Advanced Configuration.................................................................................. 397

Configuring a Non-Centrally Managed Gateway ............................................ 397SecureClient Mobile Database Properties .................................................... 399

Chapter 15 SecureClient Mobile Client Configuration VPN Connections ........................................................................................... 414

Status Page.............................................................................................. 414Initiating a VPN Connection....................................................................... 414Closing SecureClient Mobile ...................................................................... 415

Client Configuration ....................................................................................... 416Connectivity Options ................................................................................. 416Configuring Display Settings ...................................................................... 417Firewall Policy .......................................................................................... 418Controlling Device Connections .................................................................. 418

Troubleshooting............................................................................................. 420Enabling Log Files .................................................................................... 420Viewing Network Configuration ................................................................... 420Error Messages ......................................................................................... 421

Additional Resources ..................................................................................... 423

Chapter 16 SecureClient Mobile Package Management Client Deployment, Repackaging and Upgrading ............................................... 426Post-Installation / Post-Uninstallation Scripts ................................................... 426Package Customization................................................................................... 427

Adding a File to a CAB Package ................................................................. 428Deleting a File from a CAB Package............................................................ 429Exporting the Client Configuration .............................................................. 429Defining the Client Installation Version ....................................................... 430Creating a CAB Package ............................................................................ 431Creating an MSI Package........................................................................... 431Configuring the SAA Plug-in ...................................................................... 432

Table of Contents 13

Chapter 17 SecureClient Mobile Client API Introduction .................................................................................................. 436Function Return Codes................................................................................... 437Functions...................................................................................................... 438

Endpoint Connect - VPN Client

Chapter 18 Endpoint Connect Introduction .................................................................................................. 450

Why Endpoint Connect?............................................................................. 450Capabilities .............................................................................................. 450Installation and Use .................................................................................. 452Administration.......................................................................................... 453

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

Using the Packaging Tool ............................................................................... 465

Chapter 19 Endpoint Connect API Introduction to the Client OPSEC API ......................................................... 468Function Return Codes .............................................................................. 469Client Functions Communicating with Service.............................................. 470Notification Identifiers .............................................................................. 479Functions from Service to Client................................................................. 485

Index...........................................................................................................501

14

15

Preface PPreface

In This Chapter

Who Should Use This Guide page 16

Summary of Contents page 17

Related Documentation page 20

More Information page 22

Feedback page 23

Who Should Use This Guide

16

Who Should Use This GuideThis 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.).

Summary of Contents

Chapter Preface 17

Summary of ContentsThis guide contains the following sections and chapters:

Section 1 Connectra Gateway

Chapter Description

Chapter 1, “Introduction to Connectra”

Connectra, feature summary and user workflow summary.

Chapter 2, “Applications for Clientless Access”

Web Applications, File Shares, Citrix Applications and Web Mail services.

Chapter 3, “Single Sign On” HTTP based and Web form based Single Sign On for applications for clientless acess.

Chapter 4, “Native Applications for Client-Based Access”

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.

Chapter 5, “Two-Factor Authentication”

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.

Chapter 6, “Authorization” Access to Application rules define the user groups that are authorized to access Connectra applications, per Conenctra gateway.

Chapter 7, “Endpoint Security On Demand”

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.

Chapter 8, “Connectra Gateway Configuration”

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.

Section 2: SecureClient Mobile

18

Section 2: SecureClient Mobile

Chapter 9, “Connectra Gateway Clusters”

ClusterXL Connectra gateway cluster provide high availability and load sharing to ensure reliable and high performance operation of Connectra.

Chapter 10, “Troubleshooting 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.

Chapter 11, “SecurePlatform CLI Reference”

Command line reference for the Connectra SecurePlatform operating system.

Chapter Description

Chapter Description

Chapter 12, “Introduction to SecureClient Mobile”

Overview of the gateway and client features included in SecureClient Mobile.

Chapter 13, “SecureClient Mobile Installation and Setup”

Initial set up and required configuration of the Gateway and Client.

Chapter 14, “Central Management of SecureClient Mobile”

Understanding and configuring SecureClient Mobile on the gateway.

Chapter 15, “SecureClient Mobile Client Configuration”

Understanding and configuring the SecureClient Mobile client.

Chapter 16, “SecureClient Mobile Package Management”

Configuring SecureClient Mobile client settings by customizing the installation package.

Chapter 17, “SecureClient Mobile Client API”

The API functions available for SecureClient Mobile configuration.

Section 3: Endpoint Connect

Chapter Preface 19

Section 3: Endpoint Connect

Chapter Description

Chapter 18, “Endpoint Connect”

Administering and customizing the Endpoint VPN client.

Chapter 19, “Endpoint Connect API”

The OPSEC API for embedded custom client integrations.

Related Documentation

20

Related DocumentationThis 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 Description

Internet Security Product Suite Getting Started Guide

Contains an overview of NGX R66 and step by step product installation and upgrade procedures. This document also provides information about What’s New, Licenses, Minimum hardware and software requirements.

Upgrade Guide 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.

SmartCenter Administration Guide

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.

Firewall and SmartDefense Administration Guide

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.

Virtual Private Networks Administration Guide

This guide describes the basic components of a VPN and provides the background for the technology that comprises the VPN infrastructure.

Related Documentation

Chapter Preface 21

Eventia Reporter Administration Guide

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.

SecurePlatform™/ SecurePlatform Pro Administration Guide

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.

Provider-1/SiteManager-1 Administration Guide

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.

TABLE P-1 VPN-1 Power documentation suite documentation (continued)

Title Description

More Information

22

More InformationFor 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/.

http://support.checkpoint.com/

Feedback

Chapter Preface 23

FeedbackCheck Point is engaged in a continuous effort to improve its documentation. Please help us by sending your comments to:

[email protected]

mailto:[email protected]?subject=Check Point User Guide feedback

Feedback

24

Connectra Gateway

27

Chapter 1Introduction to Connectra

In This Chapter

Overview of Connectra page 28

Connectra Applications page 30

SSL Network Extender page 32

Commonly Used Concepts page 33

Connectra Security Features page 36

User Workflow page 38

Getting Started With Connectra page 42

Overview of Connectra

28

Overview of ConnectraCheck 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

Overview of Connectra

Chapter 1 Introduction to Connectra 29

• 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

Connectra Applications

30

Connectra ApplicationsConnectra 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.

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.

SSL Network Extender

32

SSL Network ExtenderThe 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 ModeThe 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 ModeThe 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 user’s desktop.

Commonly Used Concepts


Commonly Used ConceptsThis section briefly describes commonly used concepts that you will encounter when dealing with Connectra.

AuthenticationAll 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.

AuthorizationAuthorization 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 ScannerThe 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

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.

Secure Workspace

34

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 WorkspaceEnd-users can utilize Check Point’s 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 LevelsProtection 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.

Session


SessionOnce 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.

Connectra Security Features

36

Connectra Security FeaturesGreater 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 HighlightsThe 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.

Client Side Security Highlights


For more information, refer to “Configuring SSL Network Extender Advanced Options” on page 117.

Client Side Security HighlightsThe 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 Point’s 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.

User Workflow

38

User WorkflowIn This Section:

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

Signing InUsing a browser, the user types in the URL, assigned by the system administrator, for the Connectra Gateway.

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.

Signing In page 38

First time Installation of ActiveX and Java Components page 39

Language Selection page 40

Initial Setup page 40

Accessing Applications page 40

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.

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.

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.

Language Selection

40

Language SelectionThe 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 SetupThe 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.

Accessing Applications


Figure 1-1 Connectra Portal

Getting Started With Connectra

42

Getting Started With ConnectraSee 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.

43

Chapter 2Applications for Clientless Access

In This Chapter

Introduction to Applications page 44

Protection Levels page 45

Web Applications page 48

File Shares page 60

Citrix Services page 66

Web Mail Services page 78

Native Applications page 84

DNS Names page 85

Using the Login Name of the Currently Logged in User page 88

Introduction to Applications

44

Introduction to ApplicationsGiving 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.

Protection Levels

Chapter 2 Applications for Clientless Access 45

Protection LevelsProtection 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 LevelsProtection 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 gatewayRely 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 levelAssociate 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.

Figure 2-1 Protection Level Page of the File Share Application Object

Defining Protection Levels

46

Defining Protection LevelsTo 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.

Defining Protection Levels


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.

Web Applications

48

Web ApplicationsIn This Section

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.

What is a Web Application? page 48

Connectra Web Applications page 49

Web Applications of a Specific Type page 49

Configuring Web Applications page 50

Connectra Web Applications


Connectra Web ApplicationsWhen 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.

The same host with a different directory (Table 2-2) constitutes a separate Web application:

Web Applications of a Specific TypeIt 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.

Table 2-1 Single Web Site

Name DNS Name or

Host IP

Directories Services Endpoint

Compliance

Profile

Example www.example.com Any HTTP, HTTPS

Permissive

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.

Table 2-2 Web Application With The Same Host, Different Directory

Name DNS Name or

Host IP

Directories Services Endpoint

Compliance

Profile

Example www.example.com /wwserver/ HTTP, HTTPS

Permissive

Configuring Web Applications

50

Domino Web AccessIBM 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.

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 AccessOutlook 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.

Configuring Web ApplicationsTo 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.

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



In This Section

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:

Web Application — General Properties Page page 51

Web Application — Authorized Locations Page page 52

Web Application — Link in Portal Page page 53

Using the Login name of the Currently Logged In User page 54

Web Application — Single Sign-On Page page 55

Web Application — Protection Level Page page 55

Web Application — Link Translation Page page 57

Completing the Configuration of the Web Application page 58

Configuring a Proxy per Web Application page 58

Configuring Connectra to Forward Customized HTTP Headers page 58


52

• Domino Web Access is a Web application that provides access to a number of services including mail, contacts, calendar, scheduling, and collaboration services.

• 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.


• 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.

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.



• 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.

• 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.


• 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.

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


54

• 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 UserConnectra 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 user’s 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 user’s login process to the username that is extracted from the certificate and authorized by the directory server.



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.


56


• 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 user’s 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.



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.


58

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 HeadersFor 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.



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"

File Shares

60

File SharesIn This Section

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 ViewersTwo 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 user’s credentials become out of date.

Configuring File SharesTo 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.

What is a File Share? page 60

File Share Viewers page 60

Configuring File Shares page 60

Using the $$user Variable in File Shares page 64

Configuring File Shares


In This Section

File Share Application — General Properties PageGo 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.

File Share Application — General Properties Page page 61

File Share Application — Authorized Locations Page page 61

File Share Application — Authorized Locations Page page 61

File Share Application — Single Sign-On Page page 63

File Share Application — Protection Level Page page 63

Completing the Configuration of the File Share Application page 64


62


• 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.

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.


• 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.

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.



• 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.

• 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.

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).

Using the $$user Variable in File Shares

64





Completing the Configuration of the File Share Application1. Go to the Access to Application page of the Connectra tab.


• User groups.




Using the $$user Variable in File Shares 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.

Using the $$user Variable in File Shares


For more information about the $$user variable, see “Using the Login Name of the Currently Logged in User” on page 88.

Citrix Services

66

Citrix ServicesIn This Section

Understanding Citrix ServicesConnectra 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:

Understanding Citrix Services page 66

Citrix Deployments Modes - Unticketed and Ticketed page 66

Citrix features Supported by Connectra page 68

Configuring Citrix Services page 71

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.

Figure 2-5 Connectra in a Citrix Deployment - Ticketed Mode (using external STA servers)

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.

Citrix features Supported by Connectra

68

Citrix features Supported by ConnectraTable 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 Citrix Features Supported by Connectra

Feature Description Details

Clientless support of Independent Citrix Architecture

When securing an access center, Check Point's proprietary agents are not required to run on the client devices.

Clients supported

ICA Web Client for Windows® based PCs (ActiveX), Versions 6.3 - 8.2.

Clientless Support.

ICA Java Client for any Java-enabled browser (Applet) for UNIX, LINUX Macintosh, Windows, Versions 6.3 - 8.2.

Clientless Support.

Citrix Program Neighborhood client, Versions 6.3 - 8.2.

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.



MetaFrame 1.8 server 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.

Seamless integration. No need to alter existing configurations or Citrix servers' topology.

Firewall traversal

Connections from clients are secured with standard protocols using ports typically open on corporate firewalls.

Zero configuration

No special configuration of Citrix servers is necessary in order to set up Connectra.




70

Seamless integration in preexisting setups.

Unticketed mode

WI (NFuse) server configured to work in un-ticketed mode.

Ticketed mode

WI (NFuse) server configured to work in ticketed mode.

Single point of access

Single point of access to all backend servers including WI (NFuse), MetaFrame, Presentation and third party servers.

Centralized management.

Security & Access restrictions

Restricted access to Citrix backend servers. Access to specific WI (NFuse) MetaFrame, Presentation & STA servers is regulated by Connectra.

Connectra administrator may specify specific MF, WI (NFuse) & STA servers to which access is permitted.

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.

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.



Configuring Citrix Services


Configuring Citrix ServicesTo 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 ServicesConnectra'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.

Before Configuring Citrix Services page 71

Citrix Service — Web Interface (NFuse) page page 72

Citrix Service — Link in Portal Page page 72

Citrix Service — STA Servers Page page 73

Citrix Service — MetaFrame Servers Page page 74

Citrix Service — Single Sign On Page page 75

Citrix Service — Protection Level Page page 75

Completing the Configuration of the Citrix Service page 76


72

Citrix Service — Web Interface (NFuse) page• Go to the Web Interface page of the Citrix Service object.


• 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.


• 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.



• 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.

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.



74

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).



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.


76

Obtain the Host and the STA ID of the Secure Ticketing Authority (STA) servers from the current settings on the Web Interface (WI) server.

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 Service1. Go to the Access to Application page of the Connectra tab.





• User groups.




Web Mail Services

78

Web Mail ServicesIn This Section

Connectra Web Mail ServicesConnectra 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.

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.

Connectra Web Mail Services page 78

Web Mail Services User Experience page 79

Configuring Mail Services page 80

Note - The traffic log does not show actions done by the user through the Web mail interface.

Web Mail Services User Experience


Figure 2-6 Connectra Mail Services

Web Mail Services User ExperienceRemote 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 sender’s address.

• Highlight messages with different background colors, enabling quick differentiation.

• Display preferences.

Incoming (IMAP) and Outgoing (SMTP) Mail Servers

80

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 ServicesTo 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 page 81

Web Mail Service — Link in Portal Page page 81

Web Mail Service — Single Sign-On Page page 82

Web Mail Service — Single Sign-On Page page 82

Completing the Configuration of the Web Mail Service page 83

Enabling LDAP Contacts Search in Web Mail Applications page 83

Configuring Mail Services


Web Mail Service — General Properties Page• Go to the General Properties page of the Web mail service object.


• 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.


82


• 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.







Completing the Configuration of the Web Mail Service1. Go to the Access to Application page of the Connectra tab.


• User groups.




Enabling LDAP Contacts Search in Web Mail ApplicationsBy 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.

Native Applications

84

Native ApplicationsNative 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.

DNS Names


DNS NamesIn This Section

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.

DNS Names and AliasesA 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.

Why Use DNS Name Objects? page 85

DNS Names and Aliases page 85

Where DNS Name Objects are Used page 86

Defining the DNS Server used by Connectra page 86

Configuring DNS Name Objects page 86

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).

Where DNS Name Objects are Used

86

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 UsedDNS 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 ConnectraThe 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.

Configuring DNS Name ObjectsTo 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….

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


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.

Using the Login Name of the Currently Logged in User

88

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 user’s 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 user’s login process to the username that is extracted from the certificate and authorized by the directory server.

For it’s use in configuring File shares, see “Using the $$user Variable in File Shares” on page 64.

89

Chapter 3Single Sign On

In This Chapter

Introduction to Single Sign On page 90

Supported SSO Authentication protocols page 91

HTTP Based SSO page 92

Web Form Based SSO page 93

Application and Client Support for SSO page 95

Basic Configuration of SSO page 96

Advanced Configuration of SSO page 98

Advanced Configuration of Web Form SSO page 102

Introduction to Single Sign On

90

Introduction to Single Sign OnSingle 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 .

Supported SSO Authentication protocols

Chapter 3 Single Sign On 91

Supported SSO Authentication protocolsConnectra 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.

HTTP Based SSO

92

HTTP Based SSOFor 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 LimitationWhere 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.

Web Form Based SSO


Web Form Based SSOMost 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

Application Requirements for Easy Configuration

94

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.

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 LimitationsWeb 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.

Note - Web form SSO is available for Connectra NGX R66 and higher.

Application and Client Support for SSO


Application and Client Support for SSO

Connectra Applications that Support SSOThe two SSO methods are available for Connectra applications to varying degrees, as follows:

Applications that Support Web Form SSOMost 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 SSOSingle 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.

Connectra Application Supports

HTTP Based

SSO

Supports

Web Form Based

SSO

Web applications Yes Yes

File shares Yes No

Citrix services Yes Yes

Web Mail Simplified No

Native applications No No

Basic Configuration of SSO

96

Basic Configuration of SSOSingle 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.

Basic Configuration of Web Form SSO


Basic Configuration of Web Form SSOWeb 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.

Advanced Configuration of SSO

98

Advanced Configuration of SSOThe 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 MethodThere 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….

Configuring Login Settings


Table 3-4 summarizes the available single sign on methods.

Configuring Login SettingsLogin 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….

Table 3-4 Single Sign On Methods

SSO Method Single Sign On is

On/Off

Forward portal

credentials

Learn other

credentials

Turn on Single Sign On for this application - Unchecked

OffUsers are always prompted.

No No

Prompt users for their credentials, and store them for future use

OnDefault method

No Yes

This application reuses the portalcredentials. Users are not prompted.

OnAdvanced method.

Yes No

This application reuses the portal credentials. If authentication fails, Connectra prompts users and stores their credentials.

OnAdvanced method.

Yes Yes


100

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



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.

Advanced Configuration of Web Form SSO

102

Advanced Configuration of Web Form SSOUse 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 DetectionMost 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:

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 HandlingBy 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.

Credential Handling

104

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>]

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.

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 URLIn 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 - This password cannot include special characters. Use ASCII characters only.

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.

Credential Handling

106

107

Chapter 4Native Applications for Client-Based Access

In This Chapter

Introduction to Native Applications page 108

VPN Clients page 109

Configuring VPN Clients page 114

Endpoint Application Types page 122

Configuring a Simple Native Application page 127

Configuring an Advanced Native Application page 130

Configuring Downloaded-From-Connectra Endpoint Applications page 138

Adding a New Downloaded-From-Connectra Endpoint Application page 145

Introduction to Native Applications

108

Introduction to Native ApplicationsA 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.

VPN Clients

Chapter 4 Native Applications for Client-Based Access 109

VPN ClientsThree 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 ExtenderThe 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 ModeThe 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 page 109

SecureClient Mobile page 112

Endpoint Connect page 113


110

SSL Network Extender Application ModeThe 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 user’s 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 IP-based 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 Client Version

Telnet / SSH

Microsoft Microsoft Telnet (Command Line)

2000XP

Microsoft HyperTerminal 5.1

Putty Putty 0.55

VanDyke SecureCRT 4.1

Database Clients

Rational ClearQuest 2003.06.00.436.000

http://www.opsec.com/solutions/snx_support.html



Siebel Siebel Client 7

TN3270

Ericom PowerTerm InterConnect for Windows

6.6.2

IBM Personal Communications Workstation Program

5.8

FTP

Microsoft FTP(Command Line)

2000XP

Ipswitch WS_FTP Home/PRO 9.1.0.429

GlobalSCAPE CuteFTP 4.27

E-Mail (POP3,

IMAP, SMTP)

Microsoft Outlook Express 6

Microsoft Outlook (See note below table)

20002003 SP1XP

QUALCOMM Eudora 6.2

Mozilla Thunderbird 1.0.2

IBM Lotus Notes 6.0.36.5.3

Web Browser (HTTP,

HTTPS, Passive

FTP)

Microsoft Internet Explorer 5.5 and up

Mozilla Mozilla Firefox 1.0.31.0.4

Terminal Services

Microsoft Remote Desktop Connection XP2000

RealVNC VNC Viewer 4.1.1

Table 4-1 SSL Network Extender - Application Mode Support (continued)


SecureClient Mobile

112

SecureClient MobileSecureClient 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.

Famatech Remote Administrator 2.02.1

Citrix

Citrix Program Neighborhood 6.20.9859.0.0.32649

Citrix Java Connection Center 8.0.1672

Citrix JICA 8.2.1684

Citrix ActiveX 8.0.24737.0

Productivity Suites

IBM Lotus Notes 6.0.36.5.3

Table 4-1 SSL Network Extender - Application Mode Support (continued)


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.

Endpoint Connect


Endpoint ConnectEndpoint Connect is Check Point’s 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”.

Configuring VPN Clients

114

Configuring VPN ClientsIn 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

To configure Endpoint Connect clients settings on the gateway, see “Configuring the Gateway for Endpoint Connect” on page 454.

Basic VPN Client ConfigurationTo 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.

• Endpoint Connect. Must be selected if you wish to allow users of the Endpoint Connect pre-installed client to connect to the gateway.

Basic VPN Client Configuration page 114

Advanced VPN Client configuration page 115

Configuring SSL Network Extender Advanced Options page 117

Configuring SecureClient Mobile page 119

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

Advanced VPN Client configuration


VPN clients trafficConnectra 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.

• Machine’s interface is the IP address from which Connectra accepts client SSL connections.

Advanced VPN Client configurationFor advanced VPN client configuration options, select the Connectra Gateway/Connectra Cluster object > VPN Clients > Advanced page.

Defining Which Clients are Downloaded to Endpoint MachinesDefine 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.

Advanced VPN Client configuration

116

• 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 ClientsName 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 Setting

Use the predefined name resolution settings on the endpoint machine.

• Uncheck Download Name Resolution settings to endpoint machines

Download the settings used by Connectra to the endpoint machine when a secure connection is established.

• Check Download Name Resolution settings to endpoint machines

• Select Use the settings from the Name Resolution page

Download customized name resolution settings to endpoint machines when a secure connection is established.

• Check Download Name Resolution settings to endpoint machines

• Select Customize

• Specify up to three DNS servers, DNS Suffixes, and up to three WINS servers.

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.


118

• 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 behaviorThese 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 GroupThe 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.

Configuring SecureClient Mobile



In This Section

SecureClient Mobile Configuration ModesSecureClient 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

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....

SecureClient Mobile Configuration Modes page 119

Configuring SecureClient Mobile on Connectra page 119

Note - To enable devices to connect to Connectra in Enforcement Mode, ensure there are sufficient licenses for SecureClient Mobile on the Connectra gateway.


120

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.



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.

Endpoint Application Types

122

Endpoint Application TypesWhen 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 MachineThese endpoint applications are already installed on the endpoint machines.

Application Runs Via a Default BrowserRun 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.

Application Installed on Endpoint Machine page 122

Application Runs Via a Default Browser page 122

Application Downloaded From Connectra page 123

Ensuring the Link Appears in the End-User Browser page 125

Application Downloaded From Connectra


Application Downloaded From ConnectraDownloaded-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-From-Connectra Endpoint Application” on page 145.

Application Downloaded From Connectra

124

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:

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.

Table 4-2 Downloaded-from-Connectra Certified Applications

Application Description

Telnet Telnet terminal. Provides user oriented command line login sessions between hosts on the Internet.

SSH 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.

TN3270 IBM 3270 terminal emulator tailored to writing screen-scraping applications. TN3270 is the remote-login protocol used by software that emulates the IBM 3270 model of mainframe computer terminal.

TN5250 IBM 5250 terminal emulator that interprets and displays 5250 data streams.

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:

For configuration details, see “Configuring Downloaded-From-Connectra Endpoint Applications” on page 138.

Ensuring the Link Appears in the End-User BrowserIf 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.

Table 4-3 downloaded-from-Connectra Add-On Applications

Application Description

Remote Desktop (RDP)

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.

Terminal (PuTTY)

An implementation of Telnet and SSH for Win32 platforms, including an Xterm terminal emulator.

Jabber Downloaded-from-Connectra Jabber Client is an instant messenger based on the Jabber protocol Runs on every computer with at least Java 1.4.

FTP 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

Ensuring the Link Appears in the End-User Browser

126

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.

Configuring a Simple Native Application


Configuring a Simple Native ApplicationTo 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 PropertiesIn 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.

Applications on the Endpoint Machine

128

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:

• 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

Note - If the endpoint application is not available on the endpoint machine, the link to the application will not be shown in the end user’s browser.

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 exampleftp.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 ConfigurationIf 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.


• User groups.




Configuring an Advanced Native Application

130

Configuring an Advanced Native ApplicationTo 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 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.

Configuring Connection Direction page 130

Multiple Hosts and Services page 131

Configuring the Endpoint Application to Run Via a Default Browser page 132

Automatically Starting the Application page 133

Making an Application Available in Application Mode page 134

Automatically Running Commands or Scripts page 135

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.

Multiple Hosts and ServicesThe 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.

Note - A Client to Client Native Application does not require configuration of a destination address.

Configuring the Endpoint Application to Run Via a Default Browser

132

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:


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.

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:




Making an Application Available in Application Mode

134

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:





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.

Automatically Running Commands or ScriptsConnectra allows you to define a Native Application that runs a program (a command, for example).

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).

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.

Note - The user must have the appropriate privileges on the endpoint machine to run the commands.


136

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.

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-from-Connectra 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 DriveAutomatically 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.

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:





5. Configure the Edit Endpoint Application page as follows:

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.

Note - The net use command is available for SSL Network Mode only.



• 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-From-Connectra Endpoint Application” on page 145.





7. Click Advanced. In the Automatically start this application section of the Advanced page, check When SSL Network Extender is launched.

Configuring Downloaded-From-Connectra Endpoint Applications

138

Configuring Downloaded-From-Connectra Endpoint Applications

In the Endpoint Applications page of the Native Application object:

1. Select Add link in the Connectra portal.


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-from-Connectra 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.

Configuring the Telnet Client (Certified Application)


See the configuration sections below for details of the required parameters :

• “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)

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.

Table 4-4 Telnet Client Configuration

Supported Platforms

All

Parameters field Server name or IP address. Default port is 23.

Parameters usage server [port]

Description Telnet terminal. Provides user oriented command line login sessions between hosts on the Internet.

Home page http://javassh.org

http://javassh.org

Configuring the SSH Client (Certified Application)

140

Configuring the SSH Client (Certified Application)

Configuring the TN3270 Client (Certified Application)

Table 4-5 SSH Client Configuration

Supported Platforms

All

Parameters field Server name or IP address.

Parameters usage server

Description 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.

Home page http://javassh.org

Table 4-6 TN3270 Client Configuration

Supported Platforms

All. Requires Java 1.3.1 or higher.

Parameters field Ignored

Description IBM 3270 terminal emulator tailored to writing screen-scraping applications. TN3270 is the remote-login protocol used by software that emulates the IBM 3270 model of mainframe computer terminal.

Home page http://jagacy.com

http://javassh.org

http://jagacy.com




Configuring the Remote Desktop Client (Add-On Application)

Table 4-7 TN5250 Client Configuration

Supported Platforms

All endpoint machines must have Java 1.4 or higher.

Parameters field 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 [Server [options]]

Description 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 http://tn5250j.sourceforge.net/index.html

Quick Start Guide http://tn5250j.sourceforge.net/quick.html

Table 4-8 Remote Desktop Client Configuration

Supported Platforms All. endpoint machines must have Java 1.4 or higher.

Parameters field Must contain the server name or its IP address.

http://tn5250j.sourceforge.net/quick.html

http://tn5250j.sourceforge.net/index.html

http://tn5250j.sourceforge.net/quick.html

Configuring the Remote Desktop Client (Add-On Application)

142

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.

• -dWindows domain you are connecting to.

• -fShow the window full-screen (requires Java 1.4 for proper operation).

• -g WIDTHxHEIGHT. The size of the desktop in pixels.

• -mKeyboard 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).

• -lcPath to a log4j configuration file.

• -nOverride the name of the endpoint machine.

• -uName of the user to connect as.

• -pPassword for the above user.

• -sShell to launch when the session is started.

• -tPort to connect to (useful if you are using an SSH tunnel, for example).

• -TOverride the window title.

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.

Table 4-8 Remote Desktop Client Configuration (continued)

Configuring the PuTTY Client (Add-On Application)


Configuring the PuTTY Client (Add-On Application)

Configuring the Jabber Client (Add-On Application)

Home page http://properjavardp.sourceforge.net

Table 4-8 Remote Desktop Client Configuration (continued)

Table 4-9 Putty Client Configuration

Supported Platforms

Windows only

Parameters field Optional. Leaving the Parameters field empty leads PuTTY Client to opened in full graphical mode.

Parameters usage [[-ssh | -telnet | -rlogin | -raw] [user@]server [port]]

Description An implementation of Telnet and SSH for Win32 platforms, including an Xterm terminal emulator.

Home page http://www.eos.ncsu.edu/remoteaccess/putty.html

Table 4-10 Jabber Client Configuration

Supported Platforms

All. endpoint machines must have Java 1.4 or higher.


Description Downloaded-from-Connectra Jabber Client is an instant messenger based on the Jabber protocol Runs on every computer with at least Java 1.4.

Home page http://jeti.jabberstudio.org

http://properjavardp.sourceforge.net

http://www.eos.ncsu.edu/remoteaccess/putty.html

http://jeti.jabberstudio.org

Configuring the FTP Client (Add-On Application)

144

Configuring the FTP Client (Add-On Application)

Table 4-11 FTP Client Configuration

Supported Platforms

All. endpoint machines must have Java 1.4 or higher.


Description 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

Home page http://j-ftp.sourceforge.net

http://j-ftp.sourceforge.net

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

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-From-Connectra 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.

Downloaded-from-Connectra Application Requirements page 145

Procedure: Adding a New Downloaded-From-Connectra Application page 145

Example: Adding a New SSH Application page 148

Example: Adding a New Microsoft Remote Desktop Profile page 150


146

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

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.

cabarc.exe -m LZX:20 -s 6144 N ssh2.cab ssh2.jar



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

display_name The application name, which will appear in the drop-down list of downloaded-from-Connectra applications in SmartDashboard, in the Edit Endpoint Application window.

embedded_application_type 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.).

file_name The name of the file you placed in $CVPNDIR/htdocs/SNX/CSHELL (not the .cab version).

server_name_required_params 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.

pre_custom_params Parameters concatenated before the server_name_required_params field. Usually used when configuring a new downloaded-from-Connectra Java application. In that case, specify the Main Class name of the application.

post_custom_params Parameters concatenated after the server_name_required_params field. Can be left blank.

type Leave as embedded_application.

Example: Adding a New SSH Application

148

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-from-Connectra 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.

Example: Adding a New SSH ApplicationThe following example adds two applications to Connectra as new downloaded-from-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.

Example: Adding a New SSH Application


Proceed as follows:

1. Compress the ssh2.jar and WinSsh2.exe application files into ssh2.cab and WinSsh2.cab

Do this by running:

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:

# cabarc.exe -m LZX:20 -s 6144 N ssh2.cab ssh2.jar

# cabarc.exe -m LZX:20 -s 6144 N WinSsh2.cab WinSsh2.exe

Table 4-12 SSH2 Java Application

Field Name Value

display_name Jssh2 Client

embedded_application_type java_applet

file_name ssh2.jar

post_custom_params Empty

pre_custom_params ssh2.Main

server_name_required_params true

type embedded_application

Table 4-13 SSH2 Windows Executable

Field Name Value

display_name Essh2 Client

embedded_application_type windows_executable

file_name WinSsh2.exe

post_custom_params Empty

pre_custom_params Empty

server_name_required_params true

type embedded_application

Example: Adding a New Microsoft Remote Desktop Profile

150

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 ProfileCreate 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.



Create a CAB Package from the Profile1. 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 Application1. 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.

http://msdn2.microsoft.com/en-us/library/aa751974.aspx


152

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



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 ApplicationConfigure the link to Microsoft Remote Desktop that will appear in the SSL Network Extender window. Define it as an Already Installed endpoint 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.


154

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 AutomaticallyIn 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.

• 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 GroupAssign the Native Application to the relevant user group.


156

157

Chapter 5Two-Factor Authentication

In This Chapter

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.

Introduction to Two-Factor Authentication page 158

The SMS Service Provider page 159

SMS Authentication Granularity page 160

Basic Two-Factor Authentication Configuration page 161

Advanced Two-Factor Authentication Configuration page 166

Introduction to Two-Factor Authentication

158

Introduction to Two-Factor AuthenticationTwo-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.

The SMS Service Provider

Chapter 5 Two-Factor Authentication 159

The SMS Service ProviderThe 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.

SMS Authentication Granularity

160

SMS Authentication GranularitySuccessful 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.

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 credentialsObtain 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 DirectoryThe 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.

Configuring the Phone Directory

162

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.

2. Configure the list of phone number on the local gateway.

Note - A different Active Directory field can be configured using Check Point Database Tool GUIDBEdit. Search for the string “PhoneNumberAttr“.

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.

Configuring the Phone Directory


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:

Example

<username | Full DN> <phone number>

Table 5-1 User Details and Phone Number

Parameter Meaning

username or Full DN

Either a username or, for users that log in using a certificate, the full DN of the certificate.

phone number All printable characters can be used in the phone number, excluding the space character, which is not allowed. Only the digits are relevant.

bob +044-888-8888CN=jane,OU=users,O=con1.example.com.qwerty +044-7777777

Basic SmartDashboard Configuration of Two-Factor Authentication

164

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

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.

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 AuthenticationTo 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.

Parameter Meaning

$APIID The value of this parameter is the API ID.

$USERNAME The value of this parameter is the username.

$PASSWORD The value of this parameter is the password.

$PHONE User phone number, as found in Active Directory or in the local file on the gateway.

$MESSAGE The value of this parameter is the message configured in the Advanced Two-Factor Authentication Configuration Options in SmartDashBoard.

Advanced Two-Factor Authentication Configuration

166

Advanced Two-Factor Authentication Configuration

In This Section

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

Advanced Two-Factor Authentication Configuration Options page 166

Two-Factor Authentication Per Gateway (Central management only) page 169

Two-Factor Authentication Per Application page 170



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


168

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.

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.

Table 5-2 Template fields for the SMS provider Message

Parameter Meaning

$NAME User name used in the first phase of authentication to the portal.

$CODE Replaced with the One Time Password. By default, $CODE is added to the end of the message.

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)

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:

Note - This section applies only to centrally managed Connectra.

Two-Factor Authentication Per Application

170

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 Per ApplicationTwo-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.



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 ProtocolBy 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 ("").


172

173

Chapter 6Authorization

In This Chapter

Identity and Access Management page 174

Authorization in Connectra page 175

Configuring Access To Applications page 177

Identity and Access Management

174

Identity and Access ManagementThe 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.

Authorization in Connectra

Chapter 6 Authorization 175

Authorization in ConnectraOnce 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 application’s Protection Level?

Each Connectra gateway or gateway cluster enforces its own Access to Application policy.

Authorization in Connectra

176

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 application’s 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.

Configuring Access To Applications

Chapter 6 Authorization 177

Configuring Access To ApplicationsTo 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.

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.

Note - Nested user groups are not supported by the Access to Applications policy.

Configuring Access To Applications

178

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.

179

Chapter 7Endpoint Security On Demand

In This Chapter

Endpoint Compliance Enforcement page 180

Secure Workspace page 215

Endpoint Compliance Updates page 231

Endpoint Compliance Enforcement

180

Endpoint Compliance Enforcement In This Section:

Introduction to Endpoint Compliance EnforcementThe 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 GranularityThe 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.

Introduction to Endpoint Compliance Enforcement page 180

Endpoint Compliance Policy Rule Types page 181

Endpoint Compliance Logs page 192

Workflow for Endpoint Compliance Configuration page 193

Defining the Endpoint Compliance Policy page 194

Using the ICSInfo Tool page 196

Configuring the Endpoint Compliance Policy page 197

Configuring Endpoint Compliance page 199

Endpoint Compliance Scanner End-User Workflow page 208

Endpoint Compliance Policy Rule Types

Chapter 7 Endpoint Security On Demand 181

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 LicensingTo 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.

Endpoint Compliance Policy Rule TypesThere 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 page 182

Anti-Spyware Application Rule page 183

Anti-Virus Application Rule page 184

Firewall Application Rule page 185

Custom Check Rule page 187

OR Group of Rules page 188

Spyware Scan Rule page 189


182

Windows Security RuleWindows 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.



Figure 7-1 Windows Security Rule Configuration Window

Anti-Spyware Application RuleChoose 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.


184


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.



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.


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.


186

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.


Figure 7-4 Firewall Rule Configuration Window



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.


188

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.




Figure 7-6 OR Group of Rules Rule Configuration Window

Spyware Scan RuleSelect 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.


190

Customizable protection is available for a wide variety of spyware threats, as shown in Table 7-1:

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).

Table 7-1 Spyware Types

Spyware Type Description

Dialer Software that change the user’s 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.

Worm Programs that replicate over a network for the purpose of disrupting communications or damaging software or data.

Keystroke Logger Programs that record user input activity (keystrokes or mouse activity). Some keystroke loggers transmit the recorded information to third parties.

Hacker Tool Tools that facilitate unauthorized access to a computer and/or extraction of data from a computer.

Remote Administration Tool

Commercially developed software that allows remote system access and control.

Trojan Malicious programs that masquerade as harmless applications.

Adware Programs that display advertisements, or record information about Web use habits and forward it to marketers or advertisers without the user’s authorization or knowledge.

Other Any unsolicited software that secretly performs undesirable actions on a user’s computer and does not fit any of the above descriptions.

Screen Logger Software that record what a user’s monitor displays.

Tracking Cookie Cookies that are used to deliver information about the user’s Internet activity to marketers.

Browser Plug-in 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.




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.

Endpoint Compliance Logs

192

Endpoint Compliance LogsIf 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.

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:[email protected].

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.

Workflow for Endpoint Compliance Configuration


Figure 7-8 Example Endpoint Compliance Log

Workflow for Endpoint Compliance ConfigurationThe 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.

Defining the Endpoint Compliance Policy

194

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 PolicyDefining 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 Endpoint Compliance policy

Gateway A Low Security

Web App P Rely on gateway requirements

Web App Q Rely on gateway requirements

File Share R Rely on gateway requirements

Defining the Endpoint Compliance Policy


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:

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:


Gateway A Low Security

Web App P Rely on gateway requirements

Web App Q High Security

File Share R Rely on gateway requirements


Gateway A None

Web App P Low Security

Web App Q High Security

File Share R Medium Security

Using the ICSInfo Tool

196

Example Rules for Endpoint Compliance PoliciesThe following table illustrates Endpoint Compliance policies with different rules, for different security requirements.

Using the ICSInfo ToolWhen 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.

Rule Description High

Security

Endpoint

Compliance

policy

Medium

Security

Endpoint

Compliance

policy

Low

Security

Endpoint

Compliance

policy

1 Default Windows Security rule Yes Yes No

2 Anti-Virus applications check Yes Yes Yes

3 Firewall applications check Yes Yes Yes

4 Spyware Scan rule Yes No No

Configuring the Endpoint Compliance Policy


Figure 7-9 Example Output of ICSinfo

Configuring the Endpoint Compliance PolicyTo 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….

Configuring the Endpoint Compliance Policy

198

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.

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.

Note - This option is grayed out if there is no Spyware Scan rule in the policy.

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.

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.

Configuring Endpoint ComplianceThe 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

Note - For explanations of the meanings of particular fields in the Endpoint Compliance rule configuration windows, see the online help.

Configure the Endpoint Compliance Policy or Policies page 200

Enable the Endpoint Compliance Scan 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


200

Configure the Endpoint Compliance Policy or PoliciesTo 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 ScanFor 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.

Very Advanced Approach: Configuring Individual Policies for Each Application page 202

Configuring Endpoint Compliance Logs page 204

Configuring Advanced Endpoint Compliance Settings page 205

Completing the Endpoint Compliance Configuration page 205

Excluding a Spyware Signature from a Scan page 206

Preventing an Endpoint Compliance Scan Upon Every Login page 208



Basic Approach: Configuring a Common Policy for the Portal and all ApplicationsTo 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 ApplicationsTo 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.


202

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 ApplicationIt 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.



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.


204

6. Repeat steps step 3 to step 5 for all Connectra applications that requires hardened endpoint security.

7. Click OK.

Configuring Endpoint Compliance LogsConnectra 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:[email protected].



Configuring Advanced Endpoint Compliance SettingsIn 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 Configuration1. 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.


206

Figure 7-10 Endpoint Compliance Configuration Summary (Centrally Managed Connectra)

Excluding a Spyware Signature from a ScanIt 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.



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.

Endpoint Compliance Scanner End-User Workflow

208

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 LoginBy 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 page 210

Using Endpoint Security On Demand with Unsupported Browsers page 213



Configuring Internet Explorer for the Endpoint Compliance ScannerThe 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


210

• 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 ExperienceWhen 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.

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.

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.



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.


212

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.



Using Endpoint Security On Demand with Unsupported BrowsersEndpoint 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 administrator’s 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 administrator’s traffic log.

• When an application’s Protection Level is configured to require an Endpoint Compliance scan, users can still gain access to the Connectra Portal, but cannot run that application.


214

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’.

Secure Workspace


Secure Workspace In This Section

Introduction to Secure WorkspaceSecure 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 user’s 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.

Introduction to Secure Workspace page 215

Enabling Secure Workspace page 216

Applications Permitted by Secure Workspace page 217

SSL Network Extender in Secure Workspace page 219

Secure Workspace Policy Overview page 219

Configuring the Secure Workspace Policy page 221

Secure Workspace End-User Experience page 226

Enabling Secure Workspace

216

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


Configuring Advanced Secure Workspace SettingsIn the Endpoint Security On Demand > Secure Workspace page, click Edit....

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 WorkspaceIn 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.

Applications Permitted by Secure Workspace

218

Table 7-2 Applications Permitted by Secure Workspace by Default

Process Name Application DescriptionDW20.EXE, dwwin.exe Dr. Watson A process offers support proper application crash handling.

igfxsrvc.exe Intel video card driver process A process offers support video card functional.iedw.exe Internet Explorer Microsoft Internet Explorer web browserunsecapp.exe Microsoft Windows process A process offers support towards compatibility issues.ieuser.exe Internet Explorer Microsoft Internet Explorer web browserieinstal.exe Internet Explorer Microsoft Internet Explorer web browser

conime.exeMicrosoft Console IME (Input Method Editor) A process is used when the locale of the computer is set to a non-western language.

runner.exe CShell ActiveX component A CShell process required on Windows Vista.

sndvol.exeMicrosoft Windows Volume Control A process associated with the Microsoft Windows OS.

SearchIndexer.exe Content indexing service A Windows Vista service to index modified content.Acrobat.exe Adobe Acrobat Writer A process is used to create and print PDF documents.acrodist.exe Adobe Acrobat Distiller A process is used to create and print PDF documents.

acrotray.exe Acrobat Traybar AssistantA process provides a shortcut to additional configuration options for Adobe products and is used to create PDF documents.

telnet.exe Microsoft Telnet Client A terminal emulation program for TCP/IP networks.hypertrm.exe Microsoft HyperTerminal A Windows utility that offers Telnet facilities.Putty.exe Putty Free implementation of Telnet and SSH client.SecureCRT.exe SecureCRT Telnet and SSH client implementation from VanDyke Software, Inc.ptw32.exe TN3270 Telnet Client TN3270 telnet client.pcsfe.exe TN3270 Telnet Client IBM Personal Communications Session Manager. A TN3270 telnet client.ftp.exe Microsoft FTP Client Microsoft FTP Utility process that provides basic FTP access.

internat.exe Predefined ApplicationWindows 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.

Mstsc.exe Microsoft Remote Desktop Allows initiation of terminal services commands via command line.Vncviewer.exe VNC Viewer Remote administration tool process from TWD Industries.radmin.exe RAdmin Remote Administrator Server from Famatech Corp.

WISPTIS.EXE Predefined ApplicationProcess is installed alongside Microsoft office or comes packaged with Windows update. This process handles Windows Ink Services and often runs with Adobe Acrobat Reader.

MSOHELP.EXE Predefined Application Microsoft Office 2003 suite process.MSTORDB.EXE Predefined Application Microsoft Office 2003 suite process.

imapi.exe Predefined ApplicationMicrosoft 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.

OIS.EXE Predefined Application Microsoft Office Picture Manager process.

CPSWS.exeCheck Point Secure Workspace

Check Point Secure Workspace executable. This executable should be allowed in order to enable Secure Workspace to start.

net.exe Predefined Application Microsoft Windows OS process that offers additional functions to the Local Area Network.net1.exe Predefined Application Microsoft Windows OS process that offers additional functions to the Local Area Network.

svchost.exe Predefined ApplicationGeneric 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.

rundll32.exe Predefined ApplicationProcess that executes DLLs and places their libraries into memory. This program is important for the stable and secure running of the computer.

msiexec.exe Predefined ApplicationWindows Installer Component process. This program is important for the stable and secure running of the computer.

verclsid.exe Predefined ApplicationMicrosoft Windows OS process that verifies a COM object before the COM object is instantiated by Windows Explorer.

AcroRd32Info.exe Predefined ApplicationAdobe Acrobat Reader process. This process starts automatically when opening a PDF file and collects information about this file.

MSOXMLED.exe Predefined Application Microsoft Office InfoPath process used by Microsoft Office to open and edit XML files.java.exe Predefined Application Sun Microsystems Java Runtime componentjavaw.exe Predefined Application Sun Microsystems Java Runtime componentjview.exe Predefined Application Microsoft Java Virtual Machine Command Line Interpreterwjview.exe Predefined Application Microsoft Java Virtual Machine Command Line Interpreter

helpctr.exe Predefined ApplicationMicrosoft Windows OS process. Process is initiated when launching online Help in Windows 2000 or later versions.

unregmp2.exe Predefined Application Windows Media Player component. A process associated with the Microsoft Windows OS.sndvol32.exe Predefined Application Microsoft Windows Volume Control. A process associated with the Microsoft Windows OS.STAProxy.exe Predefined Application Check Point SNX Application Mode component.

ctfmon.exe Predefined ApplicationMicrosoft Office Suite process that activates the Alternative User Input Text Input Processor (TIP) and the Microsoft Office XP Language Bar.

mobsync.exe Predefined Application Microsoft Synchronization Manager. Process associated with Internet Explorer.

netsh.exe Predefined ApplicationMicrosoft Windows OS process that allows display or modification of the network configuration of a computer that is currently running.

notepad.exe Microsoft Notepad Microsoft Notepadcalc.exe Microsoft Calculator Microsoft Calculatorwordpad.exe Microsoft Wordpad Microsoft Wordpadmspaint.exe Microsoft Paint Microsoft Paintwinword.exe Microsoft Word Microsoft MS Office Word

SSL Network Extender in Secure Workspace


SSL Network Extender in Secure WorkspaceWhen using SSL Network Extender inside Secure Workspace, traffic from outside the Secure Workspace is encrypted, as well as Secure Workspace traffic.

Secure Workspace Policy OverviewSecure 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 AdvisorSecure 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.

Secure Workspace Policy Overview

220

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.

http://support.checkpoint.com

Configuring the Secure Workspace Policy



In This Section

Opening the Secure Workspace Policy EditorTo 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….

Opening the Secure Workspace Policy Editor page 221

Portal Protection Settings page 222

User Experience Settings page 223

Configuring Approved Applications page 223

Configuring Allowed Save Locations page 224

Configuring Outbound FireWall Rules page 224

Configuring a Secure Workspace Policy per Gateway page 225

Configuring a Secure Workspace Policy per Gateway page 225


222

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



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 ApplicationsApproved 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.


224

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.

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.

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 a Secure Workspace Policy per Gateway

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 PolicySecureKnowledge solution sk31592 explains how to test a new Secure Workspace policy on a standalone computer, without using Connectra.

Note - Applies to centrally managed Connectra only.

Secure Workspace End-User Experience

226


In This Section

This section provides an overview of the Secure Workspace workflow.

Logging on to the Connectra Portal using Secure WorkspaceSecure 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.

Logging on to the Connectra Portal using Secure Workspace page 226

Working with the Secure Workspace Virtual Desktop page 227

Accessing Endpoint Applications in Secure Workspace page 229

Switching Between Secure Workspace and the “Real” Desktop page 230

Exiting Secure Workspace page 230



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.


228

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.



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...

... is available to Users as a

Path and executable name (already installed)

Shortcut in the Windows Start > Program menu.

Runs via default browser Shortcut on the desktop.

Downloaded-from-Connectra application

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.


230

Switching Between Secure Workspace and the “Real” DesktopYou can switch back and forth between the Secure Workspace virtual workspace and the “real” desktop at any time. To do so, click the icon, located in the tray area of the taskbar.

Exiting Secure WorkspaceTo 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.

Endpoint Compliance Updates


Endpoint Compliance UpdatesCheck 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 UpdatesYou 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.

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.

Note - Before performing an Endpoint Security On Demand update, install a policy at least once.

Working with Automatic Updates

232

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.

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.

Performing Manual UpdatesTo 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.

Performing Manual Updates

234

235

Chapter 8Connectra Gateway Configuration

In This Chapter

Portal Settings page 236

Link Translation page 239

Connectra Server Certificates page 247

Session Settings page 254

Web Data compression page 262

Changing the IP Address of a Connectra Gateway or Cluster page 260

VPN Client and Portal Connectivity in a Single Gateway page 261

Portal Settings

236

Portal Settings In This Section

Portal CustomizationIt 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.

Portal Customization page 236

Alternative Portal Configuration page 238

Portal Customization

Chapter 8 Connectra Gateway Configuration 237

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.

• Clicking the logo redirects to this URL is a URL that can serve as a starting point. Often used for the URL of the organization’s 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.

Note - If the custom logo is changed, end users must refresh their browser cache in order see the new logo image.

Alternative Portal Configuration

238

Alternative Portal ConfigurationIt 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.

Link Translation


Link TranslationIn This Section

Introduction to Hostname TranslationLink 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 organization’s DNS server. Additionally, defining a wildcard SSL certificate for the Connectra gateway is strongly recommended.

Introduction to Hostname Translation page 239

Link Translation Per Gateway or Per Application page 240

How Hostname Translation Works page 240

Configuring Link Translation page 242

Portal Access with Hostname Translation page 245

Link Translation Issues page 246

Link Translation Per Gateway or Per Application

240

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 WorksConnectra 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.

How Hostname Translation Works


How Translated URLs Appear in a BrowserThe 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 Enabledhttps://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,CVPNProtocol=http

Wildcard SSL CertificatesUsing 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 application’s URL is translated to a different Connectra host name.

Wildcard DNS Server RecordsIn 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

Configuring Link Translation

242

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.


In This Section

Preparing Connectra for Hostname TranslationTo prepare your Connectra gateway to use Hostname Translation, perform the following procedures:

1. Obtain and install a wildcard SSL certificate for the Connectra gateway (recommended).

2. Add sub-domain records to the DNS server.

3. 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.

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.

Preparing Connectra for Hostname Translation page 242

SmartDashboard Configuration of Link Translation page 243



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 TranslationLink 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.)


244

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….

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 TranslationWhen 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.

Link Translation Issues

246

Link Translation IssuesThe 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.

Connectra Server Certificates


Connectra Server Certificates In This Section

Overview of Server CertificatesSecure 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:

Overview of Server Certificates page 247

Obtaining and Installing a Trusted Server Certificate page 247

Connectra Self-Signed Certificates page 250

Viewing Connectra Certificate Details page 252


248

Generating the Certificate Signing RequestThe first step is to generate a Certificate Signing Request (CSR) for the Connectra gateway.

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:

This creates the following output:

2. Click Enter to accept the default. The following message appears:

3. Click Enter to encrypt the private key file (default).

4. The following output appears:

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.

csr_gen server1

[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] :

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]:

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:



5. If you chose to encrypt the private key file in step 3, enter a password and confirm. You will see the following message:

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:

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 Certificate1. Obtain the Signed Certificate for Connectra from the certificate authority.

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.

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 blankFor some fields there will be a default value,If you enter '.', the field will be left blank.

csr_gen : Operation Succeeded Your Private Key File is : server1.key Your CSR File is : server1.csr

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.

Connectra Self-Signed Certificates

250

Converting a P12 or a P7B Certificate to PEM formatConnectra 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 ProcedureAfter installing a Connectra server certificate, you must install the policy on Connectra.

Connectra Self-Signed CertificatesSelf signed Connectra certificates are convenient for use during pre-production testing and demonstrating of Connectra.

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.

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.

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.

https://secureknowledge.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?lid=sk30997&partition=PUBLIC&product=Connectra

https://secureknowledge.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?lid=sk31589&partition=INTERNAL&product=Connectra

Connectra Self-Signed Certificates


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

GenerateAndInstallCert — Advanced options

Table 8-1 GenerateAndInstallCert — Basic Options

Option Description

(No flag) Backup existing certificates, and create a self-signed certificates with the server IP as subject.

mymodule.example.com Backup existing certificates, and create a self-signed certificate with mymodule.example.com as subject.

-w mymodule.example.com 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).

–h Display the usage message.

Table 8-2 GenerateAndInstallCert — Advanced Options

Command Description

–o Override existing certificates without backup.

–t mycert 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.

Viewing Connectra Certificate Details

252

Viewing Connectra Certificate DetailsThe 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 CertificateTo 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.

Viewing Connectra Certificate Details


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:

Session Settings

254

Session Settings This section discusses Connectra session related parameters and best practices.

In This Section

Simultaneous Logins to the PortalHaving 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 user’s authentication information used to log in from two different computers, only the later login is considered legitimate, and the earlier session is logged out.

In This Section

Simultaneous Logins to the Portal page 254

Session Timeouts page 258

Roaming page 258

Tracking page 258

Securing Authentication Credentials page 258

Note - Simultaneous login prevention is available for Connectra NGX R66 and higher.

Configuring Simultaneous Login Prevention page 255

Tracking of Simultaneous Logins page 256

Simultaneous Login Issues page 257

Simultaneous Logins to the Portal


Configuring Simultaneous Login PreventionSimultaneous 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


256

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 LoginsTo 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.



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.

Session Timeouts

258

Session TimeoutsOnce 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.

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.

RoamingThe 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.

TrackingConfigure Connectra to log session activity, including login attempts, logouts, timeouts, activity states and license expiration warnings.

Securing Authentication CredentialsHaving 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,

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.

Note - Users connected via SSL Network Extender can always change IP address while connected, irrespective of the roaming setting.

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.

Changing the IP Address of a Connectra Gateway or Cluster

260

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 machine1. 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 SmartDashboard5. 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.

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.

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

Figure 8-1 Connectra Object Portal Customization page

Figure 8-2 Connectra Object VPN Client Page

Web Data compression

262

Web Data compressionIn This Section

Understanding Web Data compressionConnectra 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.

Understanding Web Data compression page 262

Configuring Data Compression page 263

Configuring Data Compression


Figure 8-3 Data Compression by Connectra

Configuring Data CompressionTo configure data compression by Connectra, proceed as follows:

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).

If you want specific mime types, include both bolded words (including the minus):

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

Note - In a Connectra cluster, perform the following steps on every cluster member.

:programArgs ("-DFOREGROUND -DWEBCOMP -E /opt/CPcvpn-R66/log/httpd.starlog -f /opt/CPcvpn-R66/var/httpd.conf-real -k start")

:programArgs ("-DFOREGROUND -DWEBCOMP -DCOMPMIME -E /opt/CPcvpn-R66/log/httpd.starlog -f /opt/CPcvpn-R66/var/httpd.conf-real -k start")

#DeflateCompressionLevel 9

Configuring Data Compression

264

• To change the mime types that are compressed modify the list:

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.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css \text/javascript application/x-javascript

265

Chapter 9Connectra Gateway Clusters

In This Chapter

The Connectra Gateway Clustering Solution page 266

Geo-Clustering of Connectra Gateways page 270

Connectra Cluster installation and Licensing Requirements page 271

Synchronization Between Cluster Members page 272

Example Connectra Gateway Cluster Topology page 274

How Connectra Clusters Work page 278

The Sticky Decision Function page 283

Failover page 284

Hardware Requirements and Compatibility page 289

Basic Connectra Cluster Configuration page 293

Advanced Connectra Cluster Configuration page 303

The Connectra Gateway Clustering Solution

266

The Connectra Gateway Clustering SolutionA 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 TermsDifferent 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.

Clustering Definitions and Terms

Chapter 9 Connectra Gateway Clusters 267

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.

Load Sharing

268

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 AvailabilityIn 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 AvailabilityWhether to choose a Load Sharing (Active/Active) or a High Availability (Active/Standby) configuration depends on the requirements of the organization.

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 High Availability Mode Load Sharing Mode

Performance Good Very Good

Load sharing operation No Yes

Number of members that deal with network traffic

1 n

Geo-Clustering of Connectra Gateways

270

Geo-Clustering of Connectra GatewaysThe 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.

http://www.radware.com/content/products/appdirector/

http://updates.checkpoint.com/fileserver/ID/8453/FILE/appdirector-connectra-1.0.pdf

http://www.f5.com/products/big-ip/

http://updates.checkpoint.com/fileserver/ID/8454/FILE/f5-connectra-1.1.pdf

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.

Synchronization Between Cluster Members

272

Synchronization Between Cluster MembersIn This Section

Introduction to State SynchronizationState 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 NetworkThe 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.

Introduction to State Synchronization page 272

The Synchronization Network page 272

Synchronized Cluster Restriction page 273

Synchronized Cluster Restriction


Synchronized Cluster RestrictionThe 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 object’s Logs and Masters > Additional Logging page, configure the attribute Log forwarding schedule:.

Connectra Cluster Topology

274

Connectra Cluster TopologyIn This Section

Example Connectra Gateway Cluster TopologyTypically, 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 InterfacesConnectra 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,

Example Connectra Gateway Cluster Topology page 274

Cluster Interfaces page 274

SSL Client and Portal Connectivity in a Cluster page 275

The Cluster Member IPs page 276

Configuring Member Networks page 276

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 ClusterSetting 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.

The Cluster Member IPs

276

Figure 9-2 Connectra Cluster with a Dual Cluster Interface

The Cluster Member IPsEach 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 Connectra cluster, for the virtual cluster interface. All cluster member physical IP addresses can be non-routable. In order to achieve this, member networks must be configured, so that the Cluster Interfaces and the cluster member interfaces are on different subnets

This is useful in order to:

The Synchronization Network


• 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.

The Synchronization NetworkTo 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.

How Connectra Clusters Work

278

How Connectra Clusters WorkIn This Section

The Cluster Control ProtocolThe 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 WorksThe 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.

The Cluster Control Protocol page 278

How Load Sharing Mode Works page 278

How High Availability Mode Works page 280

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.

ExampleIn 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 192.168.10.78 to 10.10.0.34 (the Web server).

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 10.10.0.100 as its gateway to the Internet.

6. The Web server issues an ARP request to 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.

How High Availability Mode Works

280

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.

How High Availability Mode WorksThe 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.



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.

ExampleThis scenario describes a user logging from the Internet to a Web server behind the Firewall cluster.

1. The user requests a session from 192.168.10.78 (his computer) to 10.10.0.34 (the Web server).

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 10.10.0.100 as its gateway to the Internet.

6. The Web server issues an ARP request to 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.


282

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

The Sticky Decision Function


The Sticky Decision FunctionA 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.

Failover

284

FailoverIn This Section

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 member’s 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.

What is a Failover? page 284

What Happens When Failover Occurs? page 284

When Does a Failover Occur? page 285

Cluster Member Priority page 286

What Happens When a Cluster Member Recovers? page 286

How a Recovered Cluster Member Obtains the Security Policy page 286

How Connectra Applications Behave Upon Failover page 287

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.

Cluster Member Priority

286

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

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.

How Connectra Applications Behave Upon FailoverTable 9-1 summarizes the end-user experience upon failover for each Connectra application.

Table 9-1 How Applications Behave Upon Failover

Application Survives

failover?

User experience upon failover

• Web browsing through the user portal

• Domino Web Access

• Outlook Web Access

• File Shares

Yes 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.

Citrix No User is disconnected, and the Citrix session is lost. User must actively re-establish a connection.

Endpoint Compliance Scan

Yes Re-scan may be required if user logs out of the portal, or needs to log in again.

Secure Workspace Yes 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.

Multi challenge login No If user is in the middle of a multi-challenge login he/she is redirected to the initial login page.

How Connectra Applications Behave Upon Failover

288

SSL Network Extender Network Mode

Yes The user may notice the connection stalling for a few seconds, as if there was a temporary network disconnection.

SSL Network Extender Application Mode

No 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).

SSL Network Extender— Downloaded-to-Connectra applications

Mode dependant

Network Mode — Survives failover.Application Mode — Does not survive failover.

Table 9-1 How Applications Behave Upon Failover

Application Survives

failover?

User experience upon failover

Hardware Requirements and Compatibility


Hardware Requirements and CompatibilityIn This Section

Connectra Cluster Hardware RequirementsThe 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.

Connectra Cluster Hardware Requirements page 289

Connectra Cluster Hardware Compatibility page 290

Example configuration of a Cisco Catalyst Routing Switch page 291

Table 9-2 Switch Setting for Connectra Clustering

Switch Setting Explanation

IGMP and Static CAMs

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.

Disabling multicast limits

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).

Connectra Cluster Hardware Compatibility

290

The following settings should be configured on the router:

Connectra Cluster Hardware CompatibilityThe 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

Table 9-3 Router Setting for Connectra Clustering

Router Setting Explanation

Unicast MAC 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.

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 snoopingTo disable IGMP snooping run:

no ip igmp snooping

Defining static cam entriesTo 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.


292

Disabling Multicast limitsTo disable multicast limits run:

no storm-control multicast level

Configuring a static arp entry on the routerTo 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 routerTo 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”.

Basic Connectra Cluster Configuration


Basic Connectra Cluster ConfigurationIn This Section

Cluster Configuration — Deployment TipsThe 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.

Cluster Configuration — Deployment Tips page 293

Configuring Cluster Member IP Addresses page 294

If the Switch is Incapable of Forwarding Multicast page 294

SmartDashboard Configuration of a Single Cluster Interface Cluster page 295

Adding a Server Certificate to a New Cluster Member page 301

Configuring Cluster Member IP Addresses

294

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 AddressesUsing 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 MulticastIf 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

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.


296

Figure 9-4 General Properties Page of the Connectra Cluster Object


• 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 Page1. Go to the Cluster Members page.



Figure 9-5 Connectra Cluster Cluster Members Page

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


298

Figure 9-6 Connectra Cluster Cluster Members 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.



Connectra Cluster — Topology Page1. 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.


300

The Network Objectives are explained in the following table:

Network Objective Meaning

Single Cluster Interface

• 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.

Dual Cluster Interface • This network contains IP addresses of:

• 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.

• Cluster member machine interfaces in the same direction as the Dual Cluster Interface.

• To add a Dual Cluster Interface, Click to Edit and enter a name and IP for each IP address.

Sync • 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.

Non-Monitored Private

This network is not cluster related.

Adding a Server Certificate to a New Cluster Member


Connectra Cluster — SSL Clients Page and Portal Page1. 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 configuration1. 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 Member1. 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.


302

Add an Externally Signed Certificate to a New Cluster Member1. 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.

Advanced Connectra Cluster Configuration


Advanced Connectra Cluster Configuration In This Section

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.

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


304

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.



Figure 9-10 General Properties and Cluster Members Pages- Dual Cluster Interface

Figure 9-11 Edit Topology Page Example- Dual Cluster Interface

IP Address Migration

306

Figure 9-12 Listening For Traffic- SSL Clients and Portal Pages- Dual Cluster Interface

IP Address MigrationIf 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

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 ClusterTo 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.

Removing a Member from a Cluster

308

309

Chapter 10Troubleshooting Connectra

In This Chapter

Troubleshooting Web Connectivity page 310

Troubleshooting Outlook Web Access page 311

Troubleshooting File Shares page 325

Troubleshooting Citrix page 326

Troubleshooting SSL Network Extender Connectivity page 341

Ensuring Application Connectivity with Web Intelligence page 343

Troubleshooting Web Connectivity

310

Troubleshooting Web ConnectivityWeb 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.

Troubleshooting Outlook Web Access

Chapter 10 Troubleshooting Connectra 311

Troubleshooting Outlook Web Access

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

VerificationReproduce the scenario without Connectra and ensure the problem does not occur.

ConnectivityMake 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.

ConfigurationMake 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.

Note - This section applies to Outlook Web Access-related issues occurring when working through Connectra without SSL Network Extender.

Unsupported Feature List

312

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.

If you must utilize one of these features, use SSL Network Extender.

Common OWA problemsThe 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

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.

1. Authentication


“4. Performance Issues” on page 320

“5. Saving File Attachments” on page 324

1. AuthenticationAfter 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 problemsIf 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 user’s 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

Tip - Check your traffic logs for errors. The logs may help you to pinpoint the problem.

HBA problems page 313

FBA Problems page 314

Single Sign On Problems page 315

1. Authentication

314

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 ProblemsSome 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.

http://www.microsoft.com/technet/security/Bulletin/MS02-028.mspx

2. Authorization


Single Sign On ProblemsWhen 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. AuthorizationThe 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.

2. Authorization

316

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.

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.

Solution:

Match the OWA Web application configuration defined on Connectra with actual deployment.

Alternative References to OWASome 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.

Tip - When FBA is in use, always set the OWA Web application to allow HTTPS traffic.

3. Security Restrictions

318

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 permissionsUnlike 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).

3. Security RestrictionsConnectra 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.

3. Security Restrictions


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.

4. Performance Issues

320

4. Performance IssuesPerformance 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 IssuesGeneration 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.

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).

Note - Traffic and event logs (that are accessible using the SmartConsole clients) do not degrade the performance of Connectra.



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


OWA over SSL or OWA with Form Based Authentication EnabledThe 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.


322

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 ProblemsIntroducing 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 ProblemsConnectra 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 ProblemsProblems may occur due to failure to apply proper user permissions. For more details, see the Insufficient User permissions section.



SSL Time-out ProblemsSSL 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

For example:

<LocationMatch "CVPNHost=<IP or DNS namedelimited by dots>"> SetEnv nokeepalive</LocationMatch>

<LocationMatch "CVPNHost=208\.77\.188\.166">SetEnv nokeepalive

</LocationMatch>........<LocationMatch "CVPNHost=myhost\.example\.com|CVPNHost=myhost">SetEnv nokeepalive

</LocationMatch>

http://telanis.cns.ualberta.ca/

http://support.microsoft.com/kb/183110/

http://support.microsoft.com/?kbid=831167

http://support.microsoft.com/?kbid=831167

http://httpd.apache.org/docs/2.0/mod/core.html#locationmatch

5. Saving File Attachments

324

2. Run the cvpnrestart command.


5. Saving File AttachmentsWhen 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,CVPNExtension=.PDF

To solve this, configure the Web Application to use Hostname Translation.

See “Configuring Link Translation” on page 242.

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.

Troubleshooting Citrix

326

Troubleshooting Citrix

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 Connectra’s 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

ConnectivityMake 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.

Note - This Citrix troubleshooting section pertains to Citrix-related issues occurring when working through Connectra without the use of SSL Network Extender.

Common Connectra Citrix problems


ConfigurationMake 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.

Common Connectra Citrix problemsThe following topics describe common issues arising when introducing Connectra into a Citrix topology.

1. Server and Root CertificatesWhen 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.

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.

1. Server and Root Certificates page 327

2. Security Restrictions page 333

3. External STA servers page 333

4. Java Packages page 335

5. JVM Environments page 338

6. Published Links to Web Content page 338

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.


328

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.

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.

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.




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:


330

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.


Symptom




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.


Symptom


Cause


• 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.


332


Symptom


Cause


• 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.



2. Security RestrictionsConnectra 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.

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 serversConnectra 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 - Occasionally, protection mechanisms may hamper legitimate user activities. In order to eliminate this possibility, Check Point recommends switching off all security features during troubleshooting.

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.


334

Use case #7 (External STA servers)

Symptom


Cause


• 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.



Use case #8 (External STA servers)

Symptom


Cause


• 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 PackagesWhen 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.


336

Use case #9 (Java Packages)

Symptom


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.



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.


338

5. JVM EnvironmentsWhen 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 Connectra’s introduction into the Citrix deployment, ICA Java client malfunctions or fails to deploy, make sure the JVM requirements are up to Citrix specifications.

6. Published Links to Web ContentCitrix 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.

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.

Note - To allow Citrix users to browse to Citrix-published Web content, Connectra administrators must define special Connectra Web applications.



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.


340

Solution

Make sure that such URLs are accessible via Connectra by configuring corresponding Web applications in the SmartDashboard Connectra tab.

Troubleshooting SSL Network Extender Connectivity


Troubleshooting SSL Network Extender Connectivity

General SSL Network Extender Issues1. 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

342

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.

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

Disabled Protection(s)

iNotes • Cross Site Scripting

• Command Injection

File Shares • SQL Injection

• Block WebDAV HTTP methods

• Block Unsafe HTTP methods (only the OPTIONS, PUT, and DELETE methods are disabled)


344

File Shares via the Web-based file viewer

• SQL Injection

Outlook Web Access • SQL Injection

• Command Injection,

• Block WebDAV HTTP methods

• Block Unsafe HTTP methods (only the OPTIONS, PUT, and DELETE methods are disabled)

Web Mail • SQL Injection

• Command Injection

Table 10-1 Automatically Disabled Web Intelligence protections Per Application (continued)

Detected Connectra

Application

Disabled Protection(s)

Note - The HTTP method TRACE is always blocked by Connectra, irrespective of the protections configured in Web Intelligence.

345

Chapter 11SecurePlatform CLI Reference

In This Chapter

Check Point SecurePlatform Overview page 346

Managing SecurePlatform page 347

Copying Files Using SCP page 348

Secure Shell page 349

SecurePlatform Shell Commands page 350

Check Point SecurePlatform Overview

346

Check Point SecurePlatform OverviewThe 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.

Managing SecurePlatform

Chapter 11 SecurePlatform CLI Reference 347

Managing SecurePlatformThis 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 ModeStandard 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 ModeExpert 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.

Copying Files Using SCP

348

Copying Files Using SCPYou 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.

Secure Shell


Secure ShellConnectra 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.

SecurePlatform Shell Commands

350

SecurePlatform Shell CommandsIn This Section:

This section describes commonly used SecurePlatform shell commands. These commands are required for configuration, administration and diagnostics of various system aspects.

Expert Mode CommandSwitch 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 RestoreConnectra 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

Expert Mode Command page 350

Backup and Restore page 350

Snapshot Image Management page 351

Web Administration Server Control page 352

Check Point Commands page 353

Network Diagnostics Commands page 354

Note - All commands are case sensitive.

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.

backupBackup 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>]]

restoreRestore the system configuration.

Syntax:

restore [-h] [-d][[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]

Snapshot Image ManagementThe 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.

snapshotThis 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.

Note - Only administrators with Expert permission can directly access directories of a Connectra system.

Web Administration Server Control

352

Syntax:

snapshot [-h] [-d] [[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]

revertReboot 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

cpadminIn SecurePlatform expert mode, you can start, stop and restart the Web administration server that manages the Connectra administration portal.

Syntax:

cpadmin { start | stop | restart }

cpadminipIn SecurePlatform expert mode, you may limit access of administrators to specific IPs or networks.

Syntax:

cpadminp { -add | -rem | -allowAll | -print}

Note - In SecurePlatform machines, SSH access to the Connectra gateway is also governed by this setting.

Check Point Commands


Parameters:

Check Point CommandsThe following commands start and stop all Connectra module processes (not including the Web administration server).

cpstartcpstart 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

cpstopcpstop 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

Table 11-1 cpadminip Parameters

parameter meaning

-add Adds an IP or network to the list of allowed addresses.

-rem Removes an IP or a network from the list of allowed addresses.

-allowAll If True, would allow to connect from any address. If False, would allow only addresses, specified in the list of allowed addresses.

-print Shows the allowed IPs (all, or a list).

Network Diagnostics Commands

354

cplicShow, add or remove Check Point licenses.

Syntax: cplic { put | del | print | check }

Network Diagnostics Commands

pingsend ICMP ECHO_REQUEST packets to network hosts.

Syntax:

ping [-dfnqrvR] [-c count] [-i wait] [-l preload] [-p pattern] [-s packetsize]

SecureClient Mobile - VPN Client

357

Chapter 12Introduction to SecureClient Mobile

In This Chapter

SecureClient Mobile Overview page 358

SecureClient Mobile Features page 360

Security Policies and Central Enforcement page 361

Clustered Gateway Support page 362

SecureClient Mobile Overview

358

SecureClient Mobile OverviewSecureClient 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 gateway’s 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.

SecureClient Mobile Overview

Chapter 12 Introduction to SecureClient Mobile 359

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.

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.

SecureClient Mobile Features

360

SecureClient Mobile FeaturesSecureClient 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 be configured centrally in SmartDashboard and installed on multiple gateways to be enforced on SecureClient Mobile units when they connect to the gateway. Configured policies can also be deployed through Over The AIR (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.

Security Policies and Central Enforcement

Chapter 12 Introduction to SecureClient Mobile 361

Security Policies and Central EnforcementSecureClient 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.

Clustered Gateway Support

362

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.

363

Chapter 13SecureClient Mobile Installation and Setup

This chapter describes how to install SecureClient Mobile in a Check Point VPN-1 and a Connectra environment.

In This Chapter

Gateway Setup page 364

Client Installation page 372

Gateway Setup

364

Gateway SetupIn This Section

OverviewGateway 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.

Overview page 364

Requirements for Central Management page 365

Setting Up SecureClient Mobile Support for Connectra Gateways page 366

Setting Up SecureClient Mobile Support for VPN-1 Gateways page 367

Requirements for Central Management

Chapter 13 SecureClient Mobile Installation and Setup 365

To change a policy, find the policy’s 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 ManagementCentral 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 version’s 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.

Setting Up SecureClient Mobile Support for Connectra Gateways

366

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 object’s 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.

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 object’s General Properties, in Check Point products box, select VPN.


368

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.



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.

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.

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.

Note - To create a different encryption domain for remote access clients that connect to the gateway, click Set domain for Remote Access Community.

Note - If the gateway is in a Load Sharing Cluster, only the Manual (IP pool) method is supported.


370

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 SecurePlatform’s or Nokia’s web user interfaces. Another port may be assigned to SecureClient Mobile; however, this is not recommended because most



proxies do not allow ports other than 80 and 443. Instead, it is recommended that you assign SecurePlatform’s or Nokia’s 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.

Client Installation

372

Client InstallationIn This Section

Client Deployment OverviewSecureClient 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 PlatformsAn updated list of supported devices and operating systems can be found in the Release Notes for the current version of SecureClient Mobile.

Client Deployment Overview page 372

Supported Platforms page 372

Installation Prerequisites page 373

Installing SecureClient Mobile page 373

Importing Personal Certificate page 375

Uninstalling SecureClient Mobile page 375

Installation Prerequisites


Installation PrerequisitesThis 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 device’s 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 MobileThere 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 user’s 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 PackageThe 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).

Installing SecureClient Mobile

374

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 PackageThe 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.

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 CertificateAfter 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.

2. Tap Menu > Manage... > Certificates > Import.

3. Click on your certificate .p12 file and enter your password.

Uninstalling SecureClient MobileTo uninstall SecureClient Mobile:

1. If you installed the MSI package on a Windows PC, remove SecureClient Mobile from the PC in Control Panel’s 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.

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.

Uninstalling SecureClient Mobile

376

377

Chapter 14Central Management of SecureClient Mobile

Most configuration procedures in this chapter assume Central Management capabilities. For details, see “Requirements for Central Management” on page 365.

In This Chapter

Introduction page 378

Authentication Settings page 379

Connectivity Settings page 383

Routing All Traffic To the Gateway (Hub Mode) page 388

Firewall Policy page 389

Configuration and Version Management page 392

Certificates page 394

Topology Update page 396

Advanced Configuration page 397

Introduction

378

IntroductionFor 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.

Authentication Settings

Chapter 14 Central Management of SecureClient Mobile 379

Authentication SettingsIn This Section

Supported Authentication SchemesThe 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.

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.

Supported Authentication Schemes page 379

Configuring the Authentication Method page 380

Password Caching page 381

Authentication Timeout page 382

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.

Configuring the Authentication Method

380

Configuring the Authentication MethodFor 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.

2. Click OK and Install Policy.

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.

Note - The Certificate with enrollment feature is currently not implemented by the client. It will have the same effect as selecting Certificate option.

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.

Password Caching


Password CachingYou 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.


The next time each user connects to the gateway, SecureClient Mobile will download and enforce the policy changes.

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.

Authentication Timeout

382

Authentication TimeoutUser 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.



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.

Connectivity Settings


Connectivity SettingsThe following sections describe connectivity features that can be centrally configured and enforced.

In This Section

Connect ModeSecureClient 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 ModeSecureClient 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.

Connect Mode page 383

Automatic Dialup Initiation page 385

Automatic Disconnect page 386

Encryption Methods page 387

Connect Mode

384

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.



Application Request Mode - AdvancedThe 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 application’s executable filename as the name of the registry parameter.

5. Enter 1 as the decimal data for the parameter’s value.

6. Close the Windows Mobile registry.

7. Restart the third-party application.

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:

The registry change can also be included in the _setup.xml file in the SecureClient Mobile cab file as follows:

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 application’s registry parameter or change the registry value to 0.

4. Close the Windows Mobile registry.

Automatic Dialup InitiationSecureClient 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:

[NEO_HOOK_Registry]HKLM,Software\CheckPoint\Neo\Hook,iexplore.exe,0x00010001,0x1HKLM,Software\CheckPoint\Neo\Hook,opera.exe,0x00010001,0x1001

add:HKLM,Software\CheckPoint\Neo\Hook,[executable],0x00010001,0x1001

<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.

Automatic Disconnect

386

• 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.


Automatic DisconnectSecureClient 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.

Encryption Methods


• Configured on endpoint client: The device configuration determines whether automatic disconnect is enabled or disabled.



Encryption MethodsThere are two encryption methods available:

• 3DES

• RC4

You can configure SecureClient Mobile to support 3DES only or to support both methods.

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



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.

Routing All Traffic To the Gateway (Hub Mode)

388

Routing All Traffic To the Gateway (Hub Mode)

You can configure SecureClient Mobile to route all of the device’s 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.

https://secureknowledge.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?id=sk31873

https://secureknowledge.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?lid=sk31367&partition=PUBLIC&product=Connectra,%20VPN-1%20Pro%20(VPN-1/FW-1

Firewall Policy


Firewall PolicySecureClient 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.

Firewall Policy

390

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.

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 .



Configuration and Version Management

392

Configuration and Version ManagementSecureClient 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.

Configuration and Version Management


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.


Certificates

394

CertificatesThe 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 NicknameTo 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 CertificatesIf 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.

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 - In this version, enrollment to an External CA is not supported.

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.

Importing a Certificate in the Device


Importing a Certificate in the DeviceTo 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.

Topology Update

396

Topology UpdateWhen 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.

Advanced Configuration


Advanced ConfigurationIn This Section

Configuring a Non-Centrally Managed GatewayThis 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 GatewayTo 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.

Configuring a Non-Centrally Managed Gateway page 397

SecureClient Mobile Database Properties page 399

Configuring a Non-Centrally Managed Gateway

398

Managing Central Enforcement on a Non-Centrally Managed GatewayThe 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.

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))).

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.

SecureClient Mobile Database Properties


SecureClient Mobile Database PropertiesAdditional 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 Tool’s 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.

https://secureknowledge.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?id=sk13009


400

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)

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.

false, true, client_decide

neo_remember_user_password_timeout

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.

-1 (infinite), 1 - MAX_INT, 1440



neo_clear_in_activesync

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.


neo_always_connected

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.

false, true, application_request, client_decide




402

neo_always_connected_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.

1 - MAX_INT

neo_initiate_dialup

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.


neo_initiate_dialup_timeout

Timeout for dialup successful completion (seconds)

1 -MAX_INT; 15

neo_disconnect_when_idle

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.


neo_disconnect_when_idle_timeout

Disconnect when idle timeout (in minutes).

1 (default) -MAX_INT;15





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.

once, always, never, client_decide

neo_allow_site_creation

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.


neo_block_conns_on_erase_passwords

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.





404

neo_disconnect_when_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.


neo_replace_http_proxy

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!).

neo_keep_alive_max_timeout

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.

10-MAX_INT600





neo_script_wm_connect

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).

neo_script_wm_connect_show

Windows Mobile post connect script - show window while running script.

false, true

neo_script_wm_connect_md5

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.

neo_script_wm_disconnect

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).

neo_script_wm_disconnect_show

Windows Mobile post disconnect script - show window while running script

false, true




406

neo_script_wm_disconnect_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.

neo_script_wm_runonce

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).

neo_script_wm_runonce_show

Windows Mobile run-once script - show window while running script

false, true

neo_script_wm_runonce_md5

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.

neo_implicit_disconnect_timeout

Retry to establish tunnel until this timeout elapse (in minutes).

1 - MAX_INT; 2





Table 14-2 Gateway Properties


neo_enable A gateway property which activates neo support.

false, true

neo_user_auth_methods

Client authentication methods. certificate, certificate_with_enrollment, legacy, mixed

neo_encryption_methods

Client encryption methods. 3des_only, 3des_or_rc4

neo_upgrade_mode Client upgrade mode. no upgrade, ask user, force upgrade

neo_upgrade_version

The client required version. a number in hexadecimal format

neo_upgrade_url Client download absolute URL.

neo_keep_alive_timeout

Client to server heartbeat interval (in seconds). A heartbeat is sent if no other data was sent to the server.

10-MAX_INT 20

neo_package_id The gateway allows only clients with these package IDs to connect (comma separated list).

neo_user_re_auth_timeout

The session validity timeout (in minutes).

10~1440480

neo_saa_guilibs The DLL name or full path that is loaded for authentication with the server.

neo_saa_url The relative URL for SAA authentication.


408

Table 14-3 Firewall Properties


neo_enable_firewall_policy

Enables the firewall policy. false, true,client_ decide

neo_firewall_policy

The supported firewall policies:• Apply client’s setting• Allow-all• Outgoing only• Outgoing and encrypted• Encrypted only• Block all (never disabled)

client_decide, allow_all, outgoing_only, outgoing_and_encrypted, encrypted_only, block_all

neo_enable_activesync

Enables ActiveSync to PC (disabled if firewall is not installed).

false, true,client_ decide

neo_enable_ip_forwarding

Enables IP forwarding (when firewall is enabled).


neo_policy_expire The policy expiration timeout (in minutes).

-1 (infinite); 10-MAX_INT525600



neo_route_all_traffic_through_gateway

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, see“Routing All Traffic To the Gateway (Hub Mode)” on page 388.


neo_allow_clear_while_disconnected

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.





410

neo_interface_blocking_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.

{neo_basic_interface,neo_ip_with_allowed_apn_list_interface,neo_bt_interface,NULL}

neo_basic_interface

Basic class for Interface blocking.

Name of the interface (= name of the object)

interface_type Type of the Interface (currently only P2P and IP).

interface_state State of the Interface. True = allowed, false = blocked.


neo_bt_interface Class for Bluetooth blocking with profiles specified.

Name of the interface (= name of the object)

interface_state State of the Interface. True = discoverable, false = blocked, connectable = allowed but not discoverable.

false, true, client_decide, connectable

Table 14-4 General Properties


neo_run_client_on_device_startup

Runs the client on device startup.


neo_enable_kill 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.


neo_allow_client_debug_logs

Enables the client troubleshooting window.






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.


neo_allow_provisioning_via_registry

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.

false, true

neo_show_today_item

Displays the today item. false, true, client_decide

neo_show_taskbar_item

Displays the taskbar icon. false, true, client_decide

neo_flash_icon_on_encrypting

Displays the flash icon, which monitors VPN tunnel activity (traffic).


neo_flash_icon_on_fw_packet_drop

Displays the flash icon, which monitors firewall packet dropping activity.


Table 14-4 General Properties



412

413

Chapter 15SecureClient Mobile Client Configuration

In This Chapter

VPN Connections page 414

Client Configuration page 416

Troubleshooting page 420

Additional Resources page 423

VPN Connections

414

VPN ConnectionsIn This Section

Status PageSecureClient 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 server’s 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 ConnectionTo 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.

Status Page page 414

Initiating a VPN Connection page 414

Closing SecureClient Mobile page 415

Closing SecureClient Mobile

Chapter 15 SecureClient Mobile Client Configuration 415

4. When prompted, enter your credentials.

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 MobileTo 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 .

Note - If you connected to a gateway previously, then tap Connect on the toolbar to connect to the most recently connected gateway.

Client Configuration

416

Client ConfigurationIn This Section

Connectivity OptionsTap 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.

Connectivity Options page 416

Configuring Display Settings page 417

Firewall Policy page 418

Controlling Device Connections page 418

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.

Configuring Display SettingsTo 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.

Note - The administrator has the ability to prevent the user from changing these settings.

Firewall Policy

418

• 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 PolicyTap 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.

Controlling Device ConnectionsSecureClient 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.

Note - The administrator has the ability to prevent the user from changing these settings.

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.

Troubleshooting

420

TroubleshootingIn This Section

Enabling Log FilesLog 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 ConfigurationTo 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.

Enabling Log Files page 420

Viewing Network Configuration page 420

Error Messages page 421

Error Messages


Error MessagesTable 15-1 provides a list of error messages, their possible causes and a suggested solutions.

Table 15-1 Error Messages Troubleshooting

Error Message Possible Cause Solution

Cannot find the server (server name). Please check the server name and try again.

There is an error resolving the server name.

Check the server name and verify that the IP address is valid.

Error while negotiating with the server (server name). Please try again.

Error in client-server negotiation.

Try to connect again.

You are not permitted to access the server.

The user is not authorized.

Check that the user certificate is installed and is valid.

Your device is not connected to any network.

The network is not available for connection.

Connect the device to a network.

Your device is not connected to any network. Dialup connection is not available.

The network is not available for connection and dialup cannot be initiated. The settings may not be configured properly.

Check that your dialup settings are configured properly.

Access denied. Wrong username or password.

Wrong credentials supplied.

Ensure that the credentials are current and retry. If the credentials are cached, use the clear passwords button.

Error Messages

422

User is not permitted to have an office mode IP address.

The user attempting to connect is not configured to have an office mode IP address and therefore the connection failed.

Ensure that the user is configured to receive an office mode IP address.

The certificate provided is invalid. Please provide the username and password.

Invalid certificate provided.

Either install a new user certificate or connect with a username and password.

Connection to the server (server name) was lost.

There is no connection to the server, and the client disconnected.

Try to reconnect.

Security warning! Server fingerprint has changed during connection. Contact your administrator.

Server validation failed and therefore the connection failed.

Contact your administrator.

Possible identity theft. User credentials used from another client. Client Disconnected.

Another client has connected to the gateway with the same credentials.


Client firewall policy is set to Block all. Client has disconnected.

The client's Firewall policy is configured to block all network traffic.


Table 15-1 Error Messages Troubleshooting

Error Message Possible Cause Solution

Additional Resources


Additional ResourcesFor 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.

http://blogs.msdn.com/windowsmobile/archive/2006/01/28/making_a_root_cert_cab_file.aspx

http://support.microsoft.com/default.aspx?scid=kb;en-us;841060

http://support.microsoft.com/default.aspx?scid=kb;en-us;841060

http://blogs.msdn.com/windowsmobile/archive/2005/12/17/security_model_faq.aspx

http://www.pocketpcfaq.com/faqs/activesync/tshoot-as4x-connection.htm

Additional Resources

424

425

Chapter 16SecureClient Mobile Package Management

In This Chapter

Client Deployment, Repackaging and Upgrading page 426

Post-Installation / Post-Uninstallation Scripts page 426

Package Customization page 427

Client Deployment, Repackaging and Upgrading

426

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 ActiveSync’s 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]

Package Customization

Chapter 16 SecureClient Mobile Package Management 427

Package CustomizationThe 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:

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.

Folder/File Explanation

client_api SecureClient Mobile API plus sample code.

client_pkg SecureClient Mobile components for package customization.

tools SecureClient Mobile tools (for instance MSI package and MSI packaging tool).

unlock_smartphone 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.txt Readme file.

samples Sample provisioning scripts.

ttm Latest version of the TTM files for the client in case you want to update the TTM files on the gateway.

Adding a File to a CAB Package

428

• 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 PackageTo 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.

Deleting a File from a CAB Package


Deleting a File from a CAB PackageTo delete a file from a CAB package:


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.


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).

6. Save the file.


Exporting the Client ConfigurationThe 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.

Defining the Client Installation Version

430

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 client’s 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.

Defining the Client Installation VersionThe default client installation version is the client build number defined by Check Point.

To change the client installation version:


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.


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.

Creating a CAB Package


5. Change the following attribute to the desired build number:

NEO_VERSION_NUMBER= <build number>

6. Save the file.


Creating a CAB PackageA 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 PackageThe 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:


http://www.microsoft.com/downloads/details.aspx?FamilyID=9996b314-0364-4623-9ede-0b5fbb133652&DisplayLang=en

Configuring the SAA Plug-in

432

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

Configuring the SAA Plug-inEnabling 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.



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.


434

435

Chapter 17SecureClient Mobile Client API

In This Chapter


Function Return Codes page 437

Functions page 438

Introduction

436

IntroductionThis 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.

Function Return Codes

Appendix 17 SecureClient Mobile Client API 437

Function Return Codes The possible return values for the functions are:

name meaning

NEOERR_SUCCESS The operation was successful.

NEOERR_CLIENT_NOT_RUNNING Client services are not running.

NEOERR_CLIENT_NOT_RESPONSDING The client is not responding.

NEOERR_INVALID_ARGS An invalid argument was given.

NEOERR_BUFFER_TOO_SMALL The supplied buffer is too small.

NEOERR_INVALID_STATE Invalid state for request.

NEOERR_ACCESS_DENIED Unauthorized function.

NEOERR_GENERAL_FAIL A general failure had occurred.

NEOERR_OUT_OF_RESOURCE Resource ran out.

NEOERR_INTERNAL_ERROR An API internal error occurred.

Functions

438

Functions

neo_api_versionThis function retrieves the API version.

Prototype

NEOERR neo_api_version( ulong* version )

Arguments

neo_client_versionThis function retrieves the client version and version string.

Prototype

NEOERR neo_client_version( ulong* ver, char* version, ulong cbversion )

Arguments

neo_set_log_fileThis 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 )

argument IN/OUT meaning

version OUT Contains the API version.


ver OUT Contains the client version.

version OUT Buffer that holds the client version string.

cbversion IN Version buffer length.

Functions


Arguments

neo_log_outlnWrite 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

The following functions can only be called after a successful initialization.

neo_api_initThis function initializes a connection with the client for command processing.

Prototype

NEOERR neo_api_init( ulong api_version, const char* application_name )


filename IN Gives a name to the log file.

size_kb IN Determines the maximum size of the log file in KB.

cycle IN The number of files that are created before starting again at logfile0. The upper limit for the number of possible files is 20.

lvl IN Severity level of logs required (1-5, 1 = critical and 5 = low).


lvl IN The level assigned to this line determines if it is logged into the log file.

line IN The string that is written into the log.

Functions

440

Arguments

neo_api_finiThis 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_passwdThis function is called to set the username and password to be used the next time the client attempts to authenticate to the active gateway.

Prototype

NEOERR neo_set_user_passwd( const char *user, const char *passwd )


api_version IN The API version in use.

application_name IN The application used to communicate with the client.

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.

Functions


Arguments

neo_set_cert_passwdThis 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.

Prototype

NEOERR neo_set_cert_passwd( const char *cert_cn, const char *passwd )

Arguments

neo_get_stateThis function is called to retrieve the state of the client.

Prototype

NEOERR neo_get_state( NEO_STATE *state )


user IN The username used by the client.

passwd IN The password used by the client.

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.


cert_cn IN Thew certificate identifier name.

passwd IN The password used for the certificate.

Functions

442

Arguments

neo_get_last_messageThis function is called to retrieve the last client message (for example, error, failure).

Prototype

NEOERR neo_get_last_message( char* message, ulong messagecb )

Arguments

neo_clear_passwdsThis function is called to clear all saved credentials.

Prototype

NEOERR neo_clear_passwds()

Arguments

None.

neo_get_gateway_listThis 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 )


state OUT An object that defines the state of the client


message OUT The string that contains the last client message.

messagecb IN The size, in bytes, of the message buffer.

Functions


Arguments

neo_free_gateway_listThis function is called to delete the list of available gateways for the client.

Prototype

NEOERR neo_free_gateway_list( char** gateways )

Arguments

The following functions are called to set the Read/Write configuration parameters.

neo_get_property_intThis function retrieves the value of the int property “name”.

Prototype

NEOERR neo_get_property_int( const char* name, int* value )

Arguments

neo_get_property_strThis function retrieves the value of the str property “name.”


gateways OUT Pointer to a list of gateways available to the client.

num OUT The number of gateways in the list.


gateways IN The list of gateways.


name IN The name of the property.

value OUT The value of the property.

Functions

444

Prototype

NEOERR neo_get_property_str( const char* name, char* value, ulong valuecb )

Arguments

neo_set_property_intThis function assigns a value to a int property “name.”

Prototype

NEOERR neo_set_property_int( const char* name, int value )

Arguments

neo_set_property_strThis function assigns a value to a str property “name.”

Prototype

NEOERR neo_set_property_str( const char* name, const char* value )



value OUT The value of the property.

valuecb IN The size, in bytes, of “value” buffer.



value IN The value of the property.

Functions


Arguments

neo_connect_gwThis 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

neo_disconnect_gwThis function is called to disconnect from the gateway.

Prototype

NEOERR neo_disconnect_gw()

Arguments

None.

neo_register_state_change_callbackThis 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 )



value IN The value of the property.


gw IN This is the DNS name of the gateway.

Functions

446

Arguments

neo_unregister_state_change_callbackThis function is called to unregister for notification on tunnel state changes.

Prototype

NEOERR neo_unregister_state_change_callback( void (*func)(void *), void *opaque )

Arguments


func IN Called when the tunnel state changes.

opaque IN An opaque object that is transferred to func.


func IN The function that is being unregistered.

opaque IN An opaque object that is transferred to func.

Endpoint Connect - VPN Client

449

Chapter 18Endpoint Connect

In This Chapter:

This chapter explains how to configure the Connectra gateway to work with Endpoint Connect.


Configuring the Gateway page 454

Using the Packaging Tool page 465

Introduction

450

IntroductionEndpoint Connect is Check Point’s 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.

CapabilitiesResident on the users desktop or laptop, Endpoint Connect provides various capabilities for connectivity, security, installation and administration.

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

Chapter 18 Endpoint Connect 451

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 client’s 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.

Installation and Use

452

• 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

Administration


VPN components. The client’s 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.

Configuring the Gateway

454

Configuring the GatewayIn This Section:

Configuring the Gateway for Endpoint ConnectIn 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:

Configuring the Gateway for Endpoint Connect page 454

Working with RSA Hard and Soft Tokens page 460

Configuring Logging Options for Client Users page 461

Disabling CAPI Authentication page 461

Disabling DNS-based Geo-Cluster Name Resolution page 462

Configuring Endpoint Compliance Checks page 463

NAT Traversal page 463

Configuring the Gateway for Endpoint Connect


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:


456

The window is divided into four sections:

• Authentication Settings

• Connectivity Settings

• Security Settings

• Configuration and Version Settings

Authentication SettingsUse 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 client’s default value takes affect:

Table 18-1 Default Authentication values

Option SmartDashboard

default value

Endpoint Connect

default value

Enable password caching No No

Cache password for 1440 (minutes) 1440

Reauthenticate user every 480 (minutes) 480



Connectivity SettingsUse 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:

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....

Table 18-2 Default Connectivity values


default value

Endpoint Connect

default value

Connect mode Client decide Yes

Location Aware Connectivity Client decide Yes

Disconnect when no connectivity

to network

Client decide No

Disconnect when device is idle Client decide No


458

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 it’s 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....



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 SettingsUse 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.

Working with RSA Hard and Soft Tokens

460

• 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.


Configuration and Version SettingsUse 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.


Working with RSA Hard and Soft TokensIf SecurID is used for authentication, you must manage the users on RSA’s ACE management server. ACE manages the database of RSA users and their assigned hard or soft tokens. The client contacts the site’s 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.

Table 18-3 Default Security Settings


default value

Endpoint Connect

default value

Route all traffic through gateway No No

Table 18-4 Default configuration and version settings


default value

Endpoint Connect

default value

Client upgrade mode ask user do not upgrade

Note - All of the above settings for Endpoint Connect are also available through Global Properties > Remote Access > Endpoint Connect.

Configuring Logging Options for Client Users


For remote users to successfully use RSA’s 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 UsersThe 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.

• 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 AuthenticationEndpoint 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.

:send_client_logs ( :gateway ( :default ("[email protected]") ) )

Disabling DNS-based Geo-Cluster Name Resolution

462

2. Modify the enable_capi attribute to FALSE.

By default, the value is TRUE.

Modify the :default (true) line.

Disabling DNS-based Geo-Cluster Name ResolutionEach 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:

By default, the value is TRUE.

Modify the :default (true) line.

enable_capi ( :gateway ( :map ( :false (false) :true (true) :client_decide (client_decide) ) :default (true) ) )

:enable_gw_resolving ( :gateway ( :map ( :false (false) :true (true) :client_decide (client_decide) ) :default (true) ) )

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)

Configuring Endpoint Compliance ChecksWhile 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 TraversalWhen 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 client’s 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 don’t match, the Connectra Gateway drops the packet.

• TCP and UDP checksums in the TCP header are sometimes used to verify the packet’s integrity. The checksum contains the IP addresses of the remote client and gateway, and the port numbers used for the communication. IPSec

Note - This is not a regular cluster environment, as the two or more Connectra gateways are not synchronized.

NAT Traversal

464

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 gateway’s default outbound interface.

Using the Packaging Tool


Using the Packaging ToolEndpoint 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

Using the Packaging Tool

466

• 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.

467

Chapter 19Endpoint Connect API

In This Chapter:

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 service’s 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.

Introduction to the Client OPSEC API page 468

Function Return Codes page 469

Client Functions Communicating with Service page 470

Notification Identifiers page 479

Functions from Service to Client page 485

Introduction to the Client OPSEC API

468

Introduction to the Client OPSEC APIThe 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

Function Return Codes

Chapter 19 Endpoint Connect API 469

• TrRegisterErrorCallback

Functions to Receive Notifications from the ServiceUse 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

Function Return CodesThe return codes and numerical equivalents for API Functions are as follows:

Function Return Code Equivalent Meaning...

TrOK 0 Function executed without error.

TrFAIL -1000 Function failed.

TrConnAlreadyConnected -999 Connect function failed because the client is already connected.

TrConnNameAlreadyExisted -998 Connect function failed because a site with this name already exists.

TrConnAddrAlreadyExisted -997 Connect function failed because a site with this IP address already exists.

TrParamsFAIL -996 Function failed because a wrong parameter was passed to it.

TrAllocFAIL -995 Function failed because of a memory shortage.

TrComSendFAIL -994 Function failed to establish communication with the service

TrAPIInitFAIL -993 Function failed to communicate with the service

Client Functions Communicating with Service

470


In This Section:

TrICSNoCompliance -992 Function failed because the user failed the end point compliance test.

TrProxyAuthFailed -991 Function failed because proxy authentication failed

TrProxyAuthRequired -990 Function failed because proxy authentication credentials were not presented.

Function Return Code Equivalent Meaning...

TrAPIInit page 471

TrAPIInitDebug page 471

TrAPIDebug page 471

TrStart page 472

TrStop page 472

TrIsTracActive page 472

TrConnEnum page 472

TrConnGetInfo page 473

TrConnConnect page 474

TrConnCancelConnect page 475

TrConnCreate page 475

TrConnDelete page 475

TrGetInformation page 476

TrGetConfiguration page 476

TrSetConfiguration page 477

TrAPIGetVersion page 477

TrSendNotification page 478

TrRegisterErrorCallback page 478



TrAPIInitThe 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();

TrAPIInitDebugThis function creates logs.

Prototype

TRAPI_CPAPI TrStatus TrAPIInitDebug(TrString filename,int max_size, int max_files,int TopicLevel);

Arguments

TrAPIDebugThis function writes a text message to the log file.

Prototype

TRAPI_CPAPI void TrAPIDebug(const char *TopicNames,int TopicLevel,int err, const char *fmt,...);

Argument IN/OUT Meaning...

filename in The name of the log file.

max_size in Maximum size of log in Bytes.

max_files in Maximum number of files.

TopicLevel in The number of topics the logs should contain.


472

Arguments

TrStartStarts the service.

Prototype

TRAPI_CPAPI TrStatus TrStart();

TrStopStops the service.

Prototype

TRAPI_CPAPI TrStatus TrStop();

TrIsTracActiveChecks whether the trac service is active.

Prototype

TRAPI_CPAPI bool TrIsTracActive();

TrConnEnumEnnumerates 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);


TopicNames in the names of topics used in the logs.

TopicLevel in the number of topics.

err in Error level number, for example fatal error=1, informative error message=5.

fmt in The text message to be inserted in the log file.



Arguments

TrConnGetInfoAccording to a given connection handle, this function retrieves information from the connection STRUCT.

Prototype

TRAPI_CPAPI TrStatus TrConnGetInfo(TrConn connHandle, TrConnStruct* connStruct);


connIndex in the connection handle representing the connection for the site


474

Arguments

TrConnConnectConnects 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);


connHandle in The handle for the connection

TrConnStruct out The connection information as contained in the STRUCT:

• 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 site’s 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.



Arguments

TrConnCancelConnectCancels the connection to the given site.

Prototype

TRAPI_CPAPI TrStatus TrConnCancelConnect(TrConn connHandle);

Arguments

TrConnCreateCreates a new site according to the data given in connStruct, and returns a connection handle.

Prototype

TRAPI_CPAPI TrStatus TrConnCreate(IN TrConnStruct * connStruct);

Arguments

TrConnDeleteDeletes a site according to the given connection handle.

Prototype

TRAPI_CPAPI TrStatus TrConnDelete(TrConn connHandle);


connStruct in Specifically, only the connhandle and authentication information inside the STRUCT are required.


connHandle in Handle of the site to cancel.


connStruct in the STRUCT that contains the display name, IP address of the site’s gateway, and the FQDN.


476

Arguments

TrGetInformationThis 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

TrGetConfigurationRetrieves 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 TrGetConfiguration(TrMsg* pParams, TrMsg ** pConfiguration);


connHandle in the handle of the site to be deleted.


paramType in Two types are available:

• TR_USE_DN_LIST. Returns list of DNs.

• TR_ICS_REPORT_FILENAME. Returns location of the compliance check report.

pParamValue out the returned message.



Arguments

TrSetConfigurationThis function saves the user’s configuration as an attribute / value pair, for example:

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.

Prototype

TRAPI_CPAPI TrStatus TrSetConfiguration(TrMsg* pConfiguration);

Arguments

TrAPIGetVersionReturns the client version.

Prototype

TRAPI_CPAPI TrStatus TrAPIGetVersion(TrVersion* version);


pParams in Message that contains attributes to retrieve, such as default time out.

pConfiguration out Returns requested attribute

Attribute Value

IP Address 192.168.x.x

Authentication scheme


pConfiguration in configuration to be stored.


478

Arguments

TrSendNotificationSends 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

TrRegisterErrorCallbackWhen 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);


version out Returns major version, minor version, and build number


pClientNotification in Notifications to send to the service.

Notification Identifiers


Arguments


TrNotificationIDIdentifiers for each notification.

Prototype

enum TrNotificationID


ErrorCbFunctor cb in the registered callback

clientOpaque in client’s opaque to the callback

NotificationID Meaning and Format...

TR_NOTIFICATION_NETWORK_OUT The client is located outside of the VPN domain

TR_NOTIFICATION_NETWORK_IN The client is located within the VPN domainTR_NOTIFICATION_NETWORK_NO_NETWORK

No network available

TR_NOTIFICATION_CONNECTION_DISCONNECTED

Connection disconnected

Disconnect reason:

type - eTrArgTypeStr

val - a string representing the disconnect reason

default_text - NULLTR_NOTIFICATION_CONNECTION_RECONNECTING

Reconnecting

Reconnecting reason:


val - a string representing the reconnecting reason

default_text - NULL


480

TR_NOTIFICATION_TRAC_STOP Service is stoppedTR_NOTIFICATION_LOG Logs message

Log string:


val - the log's string

default_text - NULLTR_NOTIFICATION_UPGRADE Client upgrade is required.

upgrade string


val - the upgrade's string

default_text - NULLTR_NOTIFICATION_CLIENT_UPGRADE

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 TR_NOTIFICATION_ICS_NO_COMPLIANCE

End point failed the endpoint compliance test




TR_NOTIFICATION_AUTH_SUPPLY_CREDS

Supply authentication credentials. The number of arguments depends on the authentication scheme:

1. GW:


val - a string representing the gateway’s name

default_text - NULL

2. Authentication type (TrAuthType):


val - an integer represents the authentication type default_text - NULL

3. Number of parameters:


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 #


val - a string representing the parameter (e.g. "username" or "passcode", etc)

default_text - NULL



482

TR_NOTIFICATION_CLIENT_CREDENTIALS

Authentication credentials sent from the client to the service. The number of arguments depends on the authentication scheme.

1. Gateway


val - a string representing the gateway's ip address

default_text - NULL

2. Authentication type (TrAuthType):


val - an integer represents the authentication type

default_text - NULL

3. Number of values:


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 #


val - a string representing the value (e.g. the username value, the pin code value, etc)

default_text - NULL




TR_NOTIFICATION_CONNECTION_PROGRESS

Progress of the connection operation. Takes six arguments:

1. Flow’s type:


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. Step’s status:

val - an integer indicating the TrStatus of the step

default_text - NULL

3. Step’s name:


val - a string representing the step's name

default_text - NULL

4. Step’s reason for error:


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



484

5. Total progress:


val - an integer indicating the connect progress in percentages

default_text - NUL

6. Next step’s name:


val - a string representing the next step's name (empty string if this is the last step)

default_text - NULL


Functions from Service to Client



In This Section:

TrRegisterNotificationCallback page 486

TrUnregisterNotificationCallback page 488

TrMsgCreate page 488

TrMsgConstruct page 488

TrMsgDestroy page 489

TrMsgGetVersion page 489

TrMsgGetID page 490

TrMsgGetDefaultMsg page 490

TrMsgArgIterCreate page 490

TrMsgArgIterDestroy page 491

TrNotificationArgIterGetArgNum page 495

TrMsgArgIterGetNextArg page 491

TrMsgSetIntArg page 492

TrMsgSetStrArg page 492

TrNotificationConstruct page 493

TrNotificationGetID page 493

TrNotificationClone page 494

TrNotificationDestroy page 494

TrNotificationArgIterCreate page 494

TrNotificationArgIterGetArgNum page 495

TrNotificationArgIterGetNextArg page 496

TrNotificationSetIntArg page 496

TrNotificationSetStrArg page 497

TrNotificationSetDoubleArg page 497

TrArgGetType page 498

TrArgGetIntVal page 498

TrArgGetDoubleVal page 499

TrArgGetStrVal page 499

TrArgGetDefText page 499


486

The various types of notifications are described in TrAPITypes.h.

TrRegisterNotificationCallbackThis 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);



Arguments


NotificationCbFunctor cb in the registered callback

clientOpaque in client’s opaque.

eNotificationType in the notification type:

• TR_NOTIFICATION_NETWORK_TYPE = (1<<16)

• TR_NOTIFICATION_CONNECTION_TYPE = (1<<17)

• TR_NOTIFICATION_SUGGEST_CONNECT_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

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_TYPE | TR_NOTIFICATION_TRAC_STOP_TYPE


488

TrUnregisterNotificationCallbackUnregisters the notification callback.

Prototype

TRAPI_CPAPI TrStatus TrUnregisterNotificationCallback();

TrMsgCreateThis 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

Currently, these arguments should be zero or empty strings.

TrMsgConstructThis function creates a message without arguments.

Prototype

TRAPI_CPAPI TrMsg *TrMsgConstruct(int version, char *ID, char *def_msg, unsigned int arguments_num);


version in version number of the message

ID in ID of the message

def_msg in The message text

arguments_num,... in Number of parameters



Arguments


TrMsgDestroyThis function destroys a given message.

Prototype

TRAPI_CPAPI void TrMsgDestroy(TrMsg *message);

Arguments

TrMsgGetVersionThis function gets the version of a given message.

Prototype

TRAPI_CPAPI TrStatus TrMsgGetVersion(TrMsg *message, int *version);

Arguments



version in Version number of the message

ID in ID of the message

def_msg in The message text

arguments_num in Number of parameters


message in the message to destroy


message in the message to destroy

version out version number of the message


490

TrMsgGetIDThis function gets the ID of the message.

Prototype

TRAPI_CPAPI TrStatus TrMsgGetID(TrMsg *message, char **ID);

Arguments

Currently, these arguments should be empty strings.

TrMsgGetDefaultMsgThis function fills the given message, and returns the status of the operation.

Prototype

TRAPI_CPAPI TrStatus TrMsgGetDefaultMsg(TrMsg *message, char **def_msg);

Arguments

Currently, these arguments should be empty strings.

TrMsgArgIterCreateThis function creates an iterator for a given message, returns NULL for failure.

Prototype

TRAPI_CPAPI TrMsgArgIter *TrMsgArgIterCreate(TrMsg *message);


message in the message

ID out ID of the message


message in Given message

def_msg out Return message



Arguments

TrMsgArgIterDestroyThis function destroys an iterator.

Prototype

TRAPI_CPAPI void TrMsgArgIterDestroy(TrMsgArgIter *iter);

Arguments

TrMsgArgIterGetArgNumThis function fills the argument number, and returns the status of the operation.

Prototype

TRAPI_CPAPI TrStatus TrMsgArgIterGetArgNum(TrMsgArgIter *iter, int *arg_num);

Arguments

TrMsgArgIterGetNextArgThis 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.


message in Given message


iter in the iterator


iter in the iterator to get

arg_num out number of arguments


492

Prototype

TRAPI_CPAPI TrStatus TrMsgArgIterGetNextArg(TrMsgArgIter *iter, TrArg **arg);

Arguments

TrMsgSetIntArgThis 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

TrMsgSetStrArgThis 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);



arg out the next argument



pos in position of the message

val in value of the message

default_text in the message text



Arguments

TrNotificationConstructThis function creates a new TrNotification, and return NULL upon error.

Prototype

TRAPI_CPAPI TrNotification* TrNotificationConstruct(TrNotificationID ID, unsigned int arguments_num);

Arguments

TrNotificationGetIDThis function fills the notification ID, and return the status of the operation.

Prototype

TRAPI_CPAPI TrStatus TrNotificationGetID(TrNotification *notification, TrNotificationID *ID);



pos in the position of the message

val in the value of the message

default_text in the message text


ID in ID of the notification

arguments_num in number of arguments


494

Arguments

TrNotificationCloneThis function clones a given TrNotification

Prototype

TRAPI_CPAPI TrNotification* TrNotificationClone(TrNotification *notification);

Arguments

TrNotificationDestroyThis function destroys a given TrNotification

Prototype

TRAPI_CPAPI void TrNotificationDestroy(TrNotification *notification);

Arguments

TrNotificationArgIterCreateThis function creates a TrNotificationArgIter for a given notification, and returns NULL on failure.


notification in the given notification

ID out the ID of the notification


notification in the notification to be cloned


notification in the notification to be destroyed



Prototype

TRAPI_CPAPI TrNotificationArgIter *TrNotificationArgIterCreate(TrNotification * notification);

Arguments

TrNotificationArgIterDestroyThis function destroys a given TrNotificationArgIter.

Prototype

TRAPI_CPAPI void TrNotificationArgIterDestroy(TrNotificationArgIter *iter);

Arguments

TrNotificationArgIterGetArgNumThis function fills the argument number, and returns the status of the operation.

Prototype

TRAPI_CPAPI TrStatus TrNotificationArgIterGetArgNum(TrNotificationArgIter *iter, int *arg_num);






496

Arguments

TrNotificationArgIterGetNextArgThis 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

TrNotificationSetIntArgThis 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);



arg_num in the number of arguments



arg in the argument



Arguments

TrNotificationSetStrArgThis 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

TrNotificationSetDoubleArgThis 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);



pos in position of the notification

val in the value of the notification

default_text in notification text




val in value of the notification



498

Arguments

TrArgGetTypeThis functions fills the TrArg type, and returns the status of the operation.

Prototype

TRAPI_CPAPI TrStatus TrArgGetType(TrArg *arg, TrArgType *type);

Arguments

TrArgGetIntValThis 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);




val in value of the notification



arg in the argument

type out the argument type: string, int, double etc.



Arguments

TrArgGetDoubleValThis 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

TrArgGetStrValThis 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

TrArgGetDefTextThis function fills the TrArg default text, and returns the status of the operation.


arg in the argument

val out value of the argument


arg in the argument

val out value of the argument


arg in the argument

str out the value of the string


500

Prototype

TRAPI_CPAPI TrStatus TrArgGetDefText(TrArg *arg, char **def_text);

Arguments


arg in the argument

def_text out the default text

January 2009 501

Index

Numerics3DES 387, 407

AAccessing Applications 40accounting

synchronization 273ActiveSync 373, 374, 408Add-on embedded

applications 124Application Request Mode 383Applications 43, 89, 107

accessing 40Associating

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 33Authentication &

Authorization 157, 173Authorization 33, 175Automatic Connect 383

BBasic authentication 91

CCAB file 426

CAB Package 373, 431Uninstall 375

cable failure 285Certificates 394Certified embedded

applications 124Citrix

Configuring 71Services 66Troubleshooting 326

Client Installation 372Client Side Security 180Client Side Security

Highlights 37Cluster configuration

in SmartDashboard 295preparing the machines 293

ClusterXLfor Connectra 265

commandexpert 350

Command Line Interface 345Compression

concept 262configuration 263

ConfiguringAuthentication 177Authentication and

Authorization 177Connectra

what is it? 28

DData compression

concept 262configuration 263

Digest authenticationlimitation 92support 91

EEmail Services 78Embedded applications 123

add-on 124certified 124configuring 138

Endpoint ComplianceInternet Explorer

settings 209Endpoint Compliance Scanner 33

end-user Experience 208Enforcement Mode 358Error Messages 421Expert Mode 350

Ffailover

definition 266when does it occur 285

File sharesconfiguration of 60

File shares in Connectra 60Firewall Policy 389FTP 125FTP embedded application 144

GGateway History 358

HHub Mode 409

502

IInitial Setup 40interface failure 285Internal CA Certificates 394IP change

of a standalone gateway 260, 306

JJabber 125Jabber embedded

application 143

MMail services

configuration of 80definition 78

MSI Package 373, 374

NNative Applications

associating with User Groups 129

configuring 127explained 108

Network drivesautomatically maping 135,

136NTLM authentication

support 91

OOffice mode 116Outlook Web Access

configuring 50features 50troubleshooting 311

PProtection Level 34

editing 46Protection-levels

configuring 45PuTTY 125

embedded application 143

RRC4 387, 407Re-authenticate Users 382Remote Access Community 369Remote Desktop 125

SScanning the Client Machine 213Scripts

running automatically 135Secure Workspace

Client-side security 37Concept 34Configuration 216

SecureClient Mobileand SSL Network

Extender 112SecurID 380Security Features 36Server Side Security

Highlights 36Session 35Signing In 38SSH 124SSH embedded application 140SSL Network Extender 32SSL Network Extender Mode 358Sticky Decision Function 369Synchronization

restrictions 273

TTelnet 124

Telnet embedded application 139Terminal (Putty) 125TN3270 124

embedded application 140TN5250 124

embedded application 141Topology

Update 396Transform Template Files

(TTM) 398Troubleshooting 309

Citrix 326

UUser

Workflow 38

VVisitor Mode 368

WWeb Applications 49Web applications

configuration 50explained 48

Web Intelligenceautomatically disabled

protections 343Webmail

definition 78Workflow 38