VPN - Check Point

VPN-1NG with Application Intelligence (R55)For additional technical information about Check Point products, consult Check Point’s SecureKnowledge at:http://support.checkpoint.com/kb/See the latest version of this document in the User Center at:http://www.checkpoint.com/support/technical/documents/docs_r55.htmlPart No.: 700830October 2003

© 2002-2004 Check Point Software Technologies Ltd.All rights reserved. This product and related documentation are protected by copyrightand distributed under licensing restricting their use, copying, distribution, anddecompilation. No part of this product or related documentation may be reproduced inany form or by any means without prior written authorization of Check Point. Whileevery precaution has been taken in the preparation of this book, Check Point assumesno responsibility for errors or omissions. This publication and features described hereinare subject to change without notice.RESTRICTED RIGHTS LEGEND:Use, duplication, or disclosure by the government is subject to restrictions as set forthin subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clauseat DFARS 252.227-7013 and FAR 52.227-19.TRADEMARKS:Check Point, the Check Point logo, ClusterXL, ConnectControl, FireWall-1, FireWall-1GX, FireWall-1 SecureServer, FireWall-1 SmallOffice, FireWall-1 VSX, FireWall-1 XL,FloodGate-1, INSPECT, INSPECT XL, IQ Engine, MultiGate, Open Security Extension,OPSEC, Provider-1, SecureKnowledge, SecurePlatform, SecureXL, SiteManager-1,SmartCenter, SmartCenter Pro, SmartDashboard, SmartDefense, SmartLSM,SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter,SmartView Status, SmartView Tracker, SmartConsole, TurboCard, ApplicationIntelligence, SVN, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1Accelerator Card, VPN-1 Net, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote,VPN-1 SecureServer, VPN-1 SmallOffice and VPN-1 VSX are trademarks or registeredtrademarks of Check Point Software Technologies Ltd. or its affiliates. All other productnames mentioned herein are trademarks or registered trademarks of their respectiveowners.The products described in this document are protected by U.S. Patent No. 6,496,935,5,606,668, 5,699,431 and 5,835,726 and may be protected by other U.S. Patents,foreign patents, or pending applications.THIRD PARTIES:Entrust is a registered trademark of Entrust Technologies, Inc. in the United States andother countries. Entrust’s logos and Entrust product and service names are also trademarksof Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary ofEntrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate managementtechnology from Entrust.Verisign is a trademark of Verisign Inc.The following statements refer to those portions of the software copyrighted by University ofMichigan. Portions of the software copyright © 1992-1996 Regents of the University ofMichigan. All rights reserved. Redistribution and use in source and binary forms arepermitted provided that this notice is preserved and that due credit is given to the Universityof Michigan at Ann Arbor. The name of the University may not be used to endorse orpromote products derived from this software without specific prior written permission. Thissoftware is provided “as is” without express or implied warranty. Copyright © Sax Software(terminal emulation only).The following statements refer to those portions of the software copyrighted by CarnegieMellon University.Copyright 1997 by Carnegie Mellon University. All Rights Reserved.Permission to use, copy, modify, and distribute this software and its documentation for anypurpose and without fee is hereby granted, provided that the above copyright notice appearin all copies and that both that copyright notice and this permission notice appear insupporting documentation, and that the name of CMU not be used in advertising or publicitypertaining to distribution of the software without specific, written prior permission.CMUDISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALLIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALLCMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES ORANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUSACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCEOF THIS SOFTWARE.The following statements refer to those portions of the software copyrighted by The OpenGroup.THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANYCLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THESOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.The following statements refer to those portions of the software copyrighted by TheOpenSSL Project. This product includes software developed by the OpenSSL Project foruse in the OpenSSL Toolkit (http://www.openssl.org/).* THIS SOFTWARE IS PROVIDED BYTHE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLEFOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; ORBUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OROTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IFADVISED OF THE POSSIBILITY OF SUCH DAMAGE.The following statements refer to those portions of the software copyrighted by Eric Young.THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS ORIMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSEARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLEFOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; ORBUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OROTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IFADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright © 1998 The OpenGroup.The following statements refer to those portions of the software copyrighted byJean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly andMark Adler. This software is provided 'as-is', without any express or impliedwarranty. In no event will the authors be held liable for any damages arising fromthe use of this software. Permission is granted to anyone to use this software forany purpose, including commercial applications, and to alter it and redistribute itfreely, subject to the following restrictions:1. The origin of this software must not be misrepresented; you must not claim thatyou wrote the original software. If you use this software in a product, anacknowledgment in the product documentation would be appreciated but is notrequired.2. Altered source versions must be plainly marked as such, and must not bemisrepresented as being the original software.3. This notice may not be removed or altered from any source distribution.The following statements refer to those portions of the software copyrighted by theGnu Public License. This program is free software; you can redistribute it and/ormodify it under the terms of the GNU General Public License as published by theFree Software Foundation; either version 2 of the License, or (at your option) anylater version. This program is distributed in the hope that it will be useful, butWITHOUT ANY WARRANTY; without even the implied warranty ofMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNUGeneral Public License for more details.You should have received a copy of theGNU General Public License along with this program; if not, write to the FreeSoftware Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.The following statements refer to those portions of the software copyrighted by Thai OpenSource Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers.Permission is hereby granted, free of charge, to any person obtaining a copy of thissoftware and associated documentation files (the "Software"), to deal in the Softwarewithout restriction, including without limitation the rights to use, copy, modify, merge,publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons towhom the Software is furnished to do so, subject to the following conditions: The abovecopyright notice and this permission notice shall be included in all copies or substantialportions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTYOF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THEWARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERSBE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN ANACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR INCONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THESOFTWARE.Check Point Software Technologies Ltd.U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, info@CheckPoint.comInternational Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com

Indicator Justification CCG existing investment and furtheractions to be takensmoking at both mother and child. The adverse effects of smoking during in 2012-13time of pregnancy can result in the increased risk of miscarriage, pretermdelivery birth, low birth weight and stillbirth. It is associated with sudden Ensure this is embedded within the KPIs (incl.(SATOD) infant death syndrome, childhood respiratory illnesses etc. sanctions) for 13-14.Risk of non deliveryand level of riskaccurate reporting bypatient. Smoking atbooking data is currentlyCO monitored.MAPs TODOMAIN 1 OFTHE NHSOUTCOMESFRAMEWORKSATOD is included within the Public Health Outcomes Framework.Aligns with Coventry’s Joint Health and Wellbeing Strategypriorities relating to giving every child the best start in life andreducing smoking rates in Coventy. Smoking is the major factorbehind the health inequalities that exist in the city’s poorest andmore affluent wards.Making Every Contact Count included withincommissioning intentions for 2013-14.Work with GP practices on pre-conceptualadvice regarding smokingThere is quarterlyvariation in SATOD rateswhich may be affected by% of women booking inas smokers. If smoking atbooking rates increase,this may have an effecton smoking at delivery.Aligns to Warwickshire’s JSNA and annual public health report.Rapid increase in birth rate in most deprived communitiesidentified in EIA of commissioning plan.Impact of stop smoking inpregnancy team on quitrates during pregnancy.Flagged on corporate performance reportAccuracy of codingMEDIUM3

Enrollment – Step-By-Step 49Certificate Revocation (All CA Types) 53Certificate Recovery and Renewal 53Adding Matching Criteria to the Validation Process 54CRL Cache Usage 54Modifying the CRL Pre-Fetch Cache 55Configuring CRL Grace Period 55Chapter 4Chapter 5Understanding and Customizing IKEThe Need for Advanced IKE Configuration 57Check Point Solution for Advanced IKE Configuration 57IKE Overview 57Methods of Encryption and Integrity 61Phase I modes 61Renegotiating IKE & IPSec Lifetimes 62Perfect Forward Secrecy 63IP Compression 64Subnets and Security Associations 64Configuring Advanced IKE Properties 66On the VPN Community Network Object 66On the Gateway network object 67VPN-1 Advanced ConfigurationConfiguring a VPN with External Gateways Using PKI 69Configuring a VPN with External Gateways Using a Pre-Shared Secret 72How to Authorize FireWall-1 Control Connections in VPN Communities 75Why turning off FireWall-1 Implied Rules Blocks Control Connections 75How to allow FireWall-1 control connections inside a VPN 76How to find out which services are used for Control Connections 76How to Convert a Traditional Policy to a Community Based Policy 76Introduction to Converting to Simplified VPN Mode 77How Traditional VPN Mode Differs from a Simplified VPN Mode 77How an Encrypt Rule Works in Traditional Mode 78Principles of the Conversion to Simplified Mode 80Placing the Gateways into the Communities 80Conversion of Encrypt Rule 81When the Converted Rule Base is too Restrictive 81Conversion of Client Encrypt Rules 82Conversion of Auth+Encrypt Rules 83How the Converter Handles Disabled Rules 83After Running the Wizard 84IKE DOS Protection 85Understanding DoS Attacks 85IKE DoS Attacks 85Defense Against IKE DoS Attacks 86SmartDashboard IKE Dos Attack Protection Settings 87Advanced IKE Dos Attack Protection Settings 874

Chapter 6Chapter 7Chapter 8Chapter 9Traditional Mode VPNsIntroduction to Traditional Mode VPNs 91VPN Domains and Encryption Rules 91Defining VPN Properties 93Internally and Externally Managed Gateways 93Considerations for VPN Creation 93Choosing the Authentication Method 93Choosing the Certificate Authority 94Configuring Traditional Mode VPNs 94Editing a Traditional Mode Policy 94Configuring a VPN Between Internal Gateways using ICA Certificates 95VPN Between Internal Gateways Using Third Party CA Certificates 95Configuring a VPN with Externally Managed Gateways Using Certificates 96Configuring a VPN using a Pre-Shared Secret 98VPN-1 NetThe Need for a VPN Dedicated Module 103The Check Point Solution — VPN-1 Net 103VPN-1 Net Overview 103Access Control 104VPN-1 Net and NAT 104VPN-1 Net Considerations 105Deployment 105VPN-1 Net Configuration 105SSH and HTTPS Connections to VPN-1 Net Modules 106VPN-1 Accelerator CardsThe Need for VPN-1 Acceleration 107The VPN-1 Accelerator Card Solution 107Accelerator Driver Installation and Uninstallation 109Pre-Installation Instructions 109Installing the Software 109Uninstalling the Software 110Enabling and Disabling the VPN-1 Accelerator Card 111Acceleration Diagnostics 112Windows NT Performance Monitor 115VPN for Remote ClientsNeed for Remote Access VPN 119The Check Point Solution for Remote Access 120Enhancing SecuRemote with SecureClient Extensions 120Establishing a Connection between a Remote User and a Gateway 121Remote Access Community 122Identifying Elements of the Network to the Remote Client 122Connection Modes 123User Profiles 124Access Control for Remote Access 124Table of Contents 5

Client-Gateway Authentication Schemes 124Advanced Features 126Remote Access VPN Considerations 127Policy Definition for Remote Access 127User Certificate Creation Methods when Using the ICA 127User Management – Internal Database vs. LDAP Server 127NT Group/Radius Class Authentication Feature 128Remote Access Configuration 129Establishing Remote Access VPN 130Creating the Gateway and Defining Gateway Properties 131Defining User and Authentication methods in LDAP 132Defining User Properties and Authentication Methods in the Internal Database. 132Initiating User Certificates in the ICA Management Tool 132Generating Certificates for Users in SmartDashboard 132Initiating Certificates for Users in SmartDashboard 133Configuring Certificates for Users and Gateway (Using Third Party PKI) 133Enabling Hybrid Mode and Methods of Authentication 135Configuring Authentication for NT groups and Radius Classes 135Using a Pre-Shared Secret 135Defining an LDAP User Group 136Defining a User Group 136Defining a VPN Community and its Participants 136Defining Access Control Rules 136Installing the Policy 137User Certificate Management 137Modifying encryption properties for Remote Access VPN 138Working with RSA’S Hard and Soft Tokens 139Chapter 10Office ModeThe Need for Remote Clients to be Part of the LAN 143Office Mode Solution 144Introducing Office Mode 144How Office Mode Works 145Assigning IP Addresses 147IP Address Lease duration 147Using name resolution - WINS and DNS 148Anti Spoofing 148Using Office Mode with multiple external interfaces 148Advanced Features 149Office Mode Considerations 149IP pool Versus DHCP 149Routing Table Modifications 149Using the Multiple External Interfaces Feature 150Configuring Office Mode 150Office Mode — IP Pool Configuration 150Office Mode via ipassignment.conf File 153Office Mode — DHCP Configuration 154Office Mode Configuration on the Client Side 1566

Chapter 11Chapter 12Chapter 13Resolving Remote Access Connectivity IssuesThe Need for Remote Access Connectivity Resolution Features 157Check Point Solution for Connectivity Issues 157Other Connectivity Issues 158Overcoming NAT Related Issues 158During IKE phase I 160During IKE phase II 160During IPSec 161NAT and Load Sharing Clusters 164Overcoming Restricted Internet Access 165Visitor Mode 165Configuring Remote Access Connectivity 168Configuring IKE Over TCP 168Configuring Small IKE phase II Proposals 168Configuring NAT Traversal (UDP Encapsulation) 169Configuring Visitor Mode 169Configuring Remote Clients to Work with Proxy Servers 171Clientless VPNThe Need for Clientless VPN 175The Check Point Solution for Clientless VPN 176How it works 176Special considerations for Clientless VPN 178Certificate Presented by the Gateway 178Number of Security Servers to Run 179Level of Encryption 179Configuring Clientless VPN 179Configuring the Gateway 179Configuring the Client 182Third Party Remote Access ClientsThe Need for Third Party IPSec Clients 183Solution - Working with Third Party IPSec Clients 183Introduction to Third Party IPSec Clients 184Establishing a VPN between a Microsoft IPSec/L2TP client and a Check Point Gateway184Behavior of an L2TP Connection 185VPN-1 Pro Gateway Requirements for IPSec/L2TP 186Authentication of Users and Client Machines 186User Certificate Purposes 187Considerations for Choosing Microsoft IPSec/L2TP Clients 188Configuring Remote Access for Microsoft IPSec/L2TP Clients 188General Configuration Procedure 189Configuring a Remote Access Environment 189Defining the Client Machines and their Certificates 189Configuring Office Mode and L2TP Support 189Preparing the Client Machines 190Table of Contents 7

Placing the Client Certificate in the Machine Certificate Store 190Placing the User Certificate in the User Certificate Store 191Setting up the Microsoft IPSec/L2TP client Connection Profile 191Configuring User Certificate Purposes 192Making the L2TP Connection 193For More Information... 193Chapter 14Chapter 15Remote Access Advanced ConfigurationNon-Private Client IP Addresses 195Remote Access Connections 195Solving Remote Access Issues 196Enabling IP Address per User (Office Mode) 196The Problem 196The Solution 196How to Prevent a Client Inside the Encryption Domain from Encrypting 199The Problem 199The Solution 199Authentication Timeout and Password Caching 201The Problem 201The Solution 201SecuRemote/SecureClient and Secure Domain Logon (SDL) 202The Problem 202The Solution 202Configuring SDL Timeout 203Cached Information 204Configuring Secure Domain Logon 204Using Secure Domain Logon 205Back Connections (Server to Client) 205Sending Keep-Alive Packets to the Server 205Auto Topology Update (Connect Mode only) 206How to Work with non-Check Point Firewalls 206Early SecuRemote/SecureClients Versions 206Resolving Internal Names with the SecuRemote DNS Server 207The Problem 207The Solution 207Userc.C and Product.ini Configuration FilesIntroduction to Userc.C and Product.ini 211The Userc.C File 211The Product.ini file 212Userc.C File Parameters 213SecureClient 213Encryption 215Multiple Entry Point 218Encrypted Back Connections 219Topology 219NT Domain Support 220Miscellaneous 2218

Product.ini Parameters 224Chapter 16Chapter 17Chapter 18Chapter 19VPN RoutingThe Need for VPN Routing 229Check Point Solution for Greater Connectivity and Security 230Site-to-Site Solutions 230Hub Mode (VPN routing for Remote Clients) 233VPN Routing and Access Control 237Special Considerations for VPN Routing 238Configuring VPN routing 238Configuring VPN Routing for Gateways via SmartDashboard 238Enabling Hub Mode for Remote Access clients 239Configuration of Client to Client Routing by Including the Office Mode Range ofAddresses in the VPN Domain of the Gateway 240Configuration via editing the VPN configuration File 240Configuring Multiple Hubs 241Client to Client via Multiple Hubs Using Hub Mode 244VPN Routing HOWTODefining a Default Route Through a Spoke That Also Acts As a Hub 245Defining VPN Routing via two Gateways for SecureClient 247IP Resolution in VPNThe Need for IP Resolution 249Check Point Solution for Interface Resolution 249Static IP resolution 250Dynamic IP resolution 251Special Considerations for IP Resolution 253Configuring IP Resolution 253Configuring Static IP Resolution 254Configuring Dynamic IP Resolution 255IP Resolution and ISP Redundancy 257Multiple Entry Point VPNsThe Need for Multiple Entry Point Gateways 259The Check Point Solution for Multiple Entry Points 259Three Basic MEP Configurations - an Overview 260How It Works 261Routing Return Packets 264Visitor Mode and MEP 267SecureClient Connect Profiles and MEP 267Special Considerations for MEP 268MEP versus Clustering 268IP pool NAT versus RIM 268Considerations for RIM 268Configuring MEP 269Configuring Primary-Backup 269Table of Contents 9

Configuring MEPed Gateways with Equal Priority 270Configuring Return Packets 271Chapter 20Chapter 21Chapter 22Chapter 23Advanced VPN Connectivity ScenariosDMZ Connections to the Internal Network When VPN routing is enabled 277Defining a default Route for the DMZ 279VPN Routing with External Gateways Functioning as Spokes 279Load Distribution between Gateways with Partially Overlapping VPN Domains 280Configuring Partially Overlapping VPN Domains 281Cross Primary Backup 281Configuring Cross Primary Backup 282Desktop Security - Protecting Remote ClientsThe Need to Protect Remote Clients 285Desktop Security Solution 286Introducing Desktop Security 286The Desktop Security Policy 287Policy Server 288Policy Download 289Logs and Alerts 290Desktop Security Considerations 290Planning the Desktop Security Policy 290Avoiding Double Authentication for Policy Server 291Configuring Desktop Security 291Server Side Configuration 291Client Side Configuration 292Secure Configuration Verification - SCVThe Need to Verify Remote Client’s Security Status 295The Secure Configuration Verification Solution 296Introducing Secure Configuration Verification 296How does SCV work? 296SCV Checks 299Considerations regarding SCV 300Planning the SCV Policy 300User Privileges 301Using pre-NG Clients with SCV 301Configuring SCV 302Server Side Configuration 302Client Side Configuration 303SCV Policy Syntax 303The local.scv sets 307A complete example of a local.scv file 309Common Attributes 314Packaging Tool - Simplified Remote Client InstallationThe Need to Simplify Remote Client Installations 32710

The Packaging Tool Solution 328Overview 328How the Packaging Tool Works 328Automatic Software Distribution 329Configuring the Packaging Tool 330ASD Server Configuration 330The Packaging Tool Installation and Configuration 331Client Side Configuration 334Appendix AVPN-1 Command Line InterfaceVPN-1 commands 337SecureClient Commands 339Index 341Table of Contents 11

CHAPTER 1Introduction to VirtualPrivate Networks (VPN)In This ChapterThe Connectivity Challenge page 13The Check Point Solution page 14What’s in the Book page 19The Connectivity ChallengeWith the explosive growth in computer networks and network users, IT managers arefaced with the task of consolidating existing networks, remote sites, and remote usersinto a single secure structure.Branch offices need to be connected with other branch offices as well as the centralorganization. Remote users need enhanced connectivity features to cope with today’schanging networking environments. New partnership deals mean business to businessconnections with external networks.Typically, consolidation needs to take place using existing infrastructure. For many, thismeans connectivity established via the Internet as opposed to dedicated leased lines.Remote sites and users must be unified while at the same time maintaining high levelsof security. Once connectivity has been established, the connections must remain secure,offering high levels of privacy, authentication, and integrity while keeping costs low.In addition, only legitimate traffic must be allowed to enter the internal network.Possibly harmful traffic must be inspected for content. Within the internal network,different levels of access must also exist so that sensitive data is only available to theright people.13

The Check Point SolutionThe Check Point SolutionVirtual Private Networking technology leverages existing infrastructure (the Internet) asa way of building and enhancing existing connectivity in a secure manner. Based onstandard Internet secure protocols, VPN implementation enables secure links betweenspecial types of network node: the VPN module. Site to Site VPN ensures secure linksbetween Gateways. Remote Access VPN ensures secure links between Gateways andremote access clients.Understanding the TerminologyA number of terms are used widely in Secure VPN implementation, namely:• Encryption algorithm. A set of mathematically expressed processes for renderinginformation into a meaningless form, the mathematical transformations andconversions controlled by a special key. In VPN, various encryption algorithms suchas 3DES and AES ensure that only the communicating peers are able to understandthe message.• Integrity. Integrity checks (via hash functions) ensure that the message has notbeen intercepted and altered during transmission.• Trust. Public key infrastructure (PKI), certificates and certificate authorities areemployed to establish trust between Gateways. (In the absence of PKI, Gatewaysemploy a pre-shared secret, which is less secure.)• IKE & IPSec. Refer to the secure VPN protocols used to manage encryption keys,and exchange encrypted packets.• Key Exchange. The process by which communicating parties negotiate the keysand methods for exchanging data. In VPN-1, this negotiation takes place using theIKE protocol.• VPN Tunnel. An exclusive channel or link created using existing Internetinfrastructure. The link is created using the agreed upon methods and keys.• VPN Gateway. The endpoint for the encrypted connection. Gateways can besingle standalone modules or arranged into clusters. Clustered Gateways provideboth “high availability” and “load sharing”.• VPN Domain. Around each Gateway a protected area is built. The Gatewayprotects the hosts machines within the area — the VPN domain.• VPN Topology. The basic element of VPN is the link or encrypted tunnel. Linksare created between Gateways. A collection of links is a topology. The topologyshows the layout of the VPN. Two basic topologies found in VPN are Mesh andStar.• Site to Site VPN. Refers to VPN between Gateways.14

What is VPN-1• Remote Access VPN. Refers to remote users accessing the network with clientsoftware such as SecuRemote/SecureClient or third party IPSec clients. TheVPN-1 Gateway provides a Remote Access Service to the remote clients.What is VPN-1Check Point’s VPN-1 is an integrated software solution that provides secureconnectivity to corporate networks, remote and mobile users, branch offices andbusiness partners on a wide range of open platforms and security appliances. FIGURE1-1 shows the variety of applications and appliances suitable for VPN, from hand-heldPDAs and wireless laptops to mission critical networks and servers:FIGURE 1-1VPN solutionsVPN-1 integrates access control, authentication, and encryption to guarantee thesecurity of network connections over the public Internet.A typical deployment places a VPN-1 Gateway at the entrance to the corporatenetwork and remote access software on the laptops of mobile users. Remote sites areguarded by other VPN-1 Gateways and communication between all componentsregulated by a strict security policy.VPN-1 ComponentsVPN-1 is composed of:• VPN endpoints, such as Gateways, clusters of Gateways, or remote client software(for mobile users) which negotiate the VPN link. The VPN endpoint can be eitherVPN-1 (a VPN module with a Security Policy) or VPN-1 Net (the basic VPNmodule without a Security Policy).Chapter 1 Introduction to Virtual Private Networks (VPN) 15

The Check Point Solution• VPN trust entities, for example the Check Point Internal Certificate Authority. TheICA is part of the VPN-1 FireWall-1 suite used for establishing trust for SICconnections between Gateways, authenticating administrators and third OPSECsolutions. The ICA provides certificates for internal Gateways and remote accessclients which negotiate the VPN link.• VPN Management tools. SmartCenter Server and SmartDashboard. SmartDashboardis the SmartConsole used to access the SmartCenter Server Management. TheVPN-1 Manager is part of SmartDashboard:SmartDashboard enables organizations to define and deploy Intranet, Extranet, andremote Access VPNs.• Smart DataBase for keeping track of defined network objects, services, resources,servers and OPSEC applications, users, and VPN communities.Building VPN LinksAt the center of VPN is the encrypted tunnel (or VPN link) created using theIKE/IPSec protocols. The two parties are either VPN Gateways or remote accessclients. The VPN peers negotiating a link first create a trust between them. This trustis established via PKI or pre-shared secrets. Methods are exchanged and keys created.The encrypted tunnel is established and then maintained for multiple connections,exchanging key material to refresh the keys when needed. A single Gateway maintainsmultiple tunnels simultaneously with its VPN peers. Traffic in each tunnel is encryptedand authenticated between the VPN peers, ensuring integrity and privacy. Data istransferred in bulk via these virtual-physical links.16

Features of VPN-1 ConnectivityFeatures of VPN-1 ConnectivityVPN-1 has a number of features for site to site, routing, and remote access connectivity.Site to Site ConnectivityVPN sites are configured into two basic topologies - Mesh and Star. A topology is thecollection of enabled VPN links in a system of Gateways, their VPN domains, hostslocated behind each Gateway and the remote clients external to them.In a Mesh topology, every Gateway has a link to every other Gateway, as shown inFIGURE 1-2:FIGURE 1-2VPN-1 Gateways in a Mesh topologyIn a Star topology, only Gateways defined as Satellites (or “spokes”) are allowed tocommunicate with a central Gateway (or “Hub”) but not with each other:Chapter 1 Introduction to Virtual Private Networks (VPN) 17

The Check Point SolutionFIGURE 1-3VPN-1 Gateways in a Star topologyAs shown in FIGURE 1-3, it is possible to further enhance connectivity by meshingcentral Gateways. This kind of topology is suitable for deployments involving Extranetsthat include networks belonging to business partners.Advanced Topologies with VPN RoutingMore complex connections between VPN sites are available by enabling VPN routing onthe Gateway. VPN Gateways and clients are manually configured to route VPN trafficfrom tunnel to tunnel rather than forward traffic to their domains. This meansgeographically spaced hosts achieve connectivity via more than one link. This is usefulin a number of scenarios, for example:• Connecting between Gateways that have dynamically assigned IP addresses; thetraffic is routed via a central Gateway.• Enabling connectivity between two remote access clients by routing through acentral Gateway.• Enhancing security in an organization that employs a number of VPN-1 Netmodules. Routing connections through a VPN-1 Gateway allows traffic to beinspected for content, and a more granular security policy applied.Remote Access ConnectivityFor remote access clients, there are two VPN scenarios:• Client to Gateway, where the remote client connects with servers on thecorporate LAN via a Gateway.• Client to Client, where the remote client connects with other remote clients byrouting through the corporate Gateway.18

Features of VPN-1 ConnectivityMultiple Entry Point VPN.VPN Primary-backup, Load Distribution, and First-to-Respond, are high availabilityand load sharing solutions for remote access VPN connections.If a Gateway fails in Primary-backup scenario, new VPN connections automaticallycontinue through the remaining VPN-1 Gateways defined in the Multiple Entry Point(MEP) configuration.In a Load Distribution scenario, inbound VPN connects are distributed across a numberof VPN-Gateways.In First-to-Respond, the first Gateway to respond to a probe from the remote VPNpeer takes the connection.Additional VPN-1 TechnologyVPN-1 performance is enhanced via a range of accelerator cards.Accelerator CardsVPN-1 Accelerator Cards improve Gateway performance by off loading encryption andpublic key operations from the host CPU to a dedicated processor on a card. Thisexpands Gateway capacity for VPN communications, and frees system resources forFireWall operations. This dual benefit means that accelerator cards are a good solutionfor any VPN-1 applications where CPU utilization is high.What’s in the BookThe VPN book is divided into five sections:• Building VPN covers building VPN between Gateways, advanced configurationissues, and PKI. See: “Building VPNs” on page 21.• VPN-1 Gateway Products covers VPN-1 NET and Accelerator Cards. See:“VPN-1 Gateway Products” on page 101.• Remote Access VPN covers remote clients, advanced configuration issues, andclientless VPN. See: “Remote Access VPN” on page 117.• Advanced VPN Connectivity covers VPN routing, Multiple Entry Point VPNand IP resolution. See: “Advanced VPN Connectivity” on page 227.• Desktop Security covers protecting remote clients, secure configurationverification, and software distribution via the packaging tool. See: “DesktopSecurity” on page 283.Chapter 1 Introduction to Virtual Private Networks (VPN) 19

Building VPNsThis section covers the creation and management of Site-to-Site Virtual Private Networks.

CHAPTER 2Building a VPN BetweenGatewaysIn This Chapter:The Need for Virtual Private NetworksCommunicating parties need a connectivity platform that is not only fast, scalable, andresilient but also provides:• Confidentiality• Authentication• IntegrityConfidentialityOnly the communicating parties must be able to read the private informationexchanged between them.AuthenticationThe Need for Virtual Private Networks page 23The Check Point Solution for VPN page 24Special Considerations for Planning a VPN Topology page 34Configuring a VPN Between Gateways page 35The communicating parties must be sure they are connecting with the intended party.23

The Check Point Solution for VPNIntegrityThe sensitive data passed between the communicating parties is unchanged, and this canbe proved with an integrity check.The Check Point Solution for VPNA Virtual Private Network (VPN) is a secure connectivity platform that both connectsnetworks and protects the data passing between them. For example, an organization mayhave geographically spaced networks connected via the Internet; the company hasconnectivity but no privacy. VPN provides privacy by encrypting those connectionsthat need to be secure. Another company may connect all parts of its geographicallyspaced network through the use of dedicated leased lines; this company has achievedconnectivity and privacy but at great expense. VPN offers a cheaper connectivitysolution by connecting the different parts of the network via the public Internet.A Virtual Private Network is a network that employs encrypted tunnels to exchangesecurely protected data. VPN-1 creates encrypted tunnels by using the Internet KeyExchange (IKE) and IP Security (IPSec) protocols. IKE creates the VPN tunnel, and thistunnel is used to transfer IPSec encoded data.Think of IKE as the process that builds a tunnel, and IPSec packets as trucks that carrythe encrypted data along the tunnel.FIGURE 2-1Simplified VPN tunnelHow it WorksIn FIGURE 2-2, host 1 and host 6 need to communicate. The connection passes in theclear between host 1 and the local Gateway. From the source and destination addressesof the packet, the Gateway determines that this should be an encrypted connection. Ifthis is the first time the connection is made, the local Gateway initiates an IKEnegotiation with the peer Gateway in front of host 6. During the negotiation, bothGateways authenticate each other, and agree on encryption methods and keys. After asuccessful IKE negotiation, a VPN tunnel is created. From now on, every packet thatpasses between the Gateways is encrypted according to the IPSec protocol. IKE supplies24

VPN Communitiesauthenticity (Gateways are sure they are communicating with each other) and createsthe foundation for IPSec. Once the tunnel is created, IPSec provides privacy (throughencryption) and integrity (via one-way hash functions).FIGURE 2-2Confidentiality, integrity, and authentication via IPSec.After a VPN tunnel has been established (FIGURE 2-2), packets are dealt with in thefollowing way:• A packet leaves the source host and reaches the Gateway.• The Gateway encrypts the packet.• The packet goes down the VPN tunnel to the second Gateway. In actual fact, thepackets are standard IP packets passing through the Internet. However, because thepackets are encrypted, they can be considered as passing through a private “virtual”tunnel.• The second Gateway decrypts the packet.• The packet is delivered in the clear to the destination host. From the hostsperspective, they are connecting directly.For more information regarding the IKE negotiation, see: Understanding andCustomizing IKE.VPN CommunitiesCreating VPN tunnels between Gateways is made easier through the configuration ofVPN communities. A VPN community is a collection of VPN enabled Gatewayscapable of communicating via VPN tunnels.To understand VPN Communities, a number of terms need to be defined:Chapter 2 Building a VPN Between Gateways 25

The Check Point Solution for VPN• VPN Community member. Refers to the Gateway that resides at one end of a VPNtunnel.• VPN domain. Refers to the hosts behind the Gateway. The VPN domain can be thewhole network that lies behind the gateway or just a section of that network. Forexample a Gateway might protect the corporate LAN and the DMZ. Only thecorporate LAN needs to be defined as the VPN domain.• VPN Site. Community member plus VPN domain. A typical VPN site would bethe branch office of a bank.• VPN Community. The collection of VPN tunnels/links and their attributes.FIGURE 2-3VPN TerminologyThe methods used for encryption and ensuring data integrity determine the type oftunnel created between the Gateways, which in turn is considered a characteristic ofthat particular VPN community.SmartCenter Server can manage multiple VPN communities, which meanscommunities can be created and organized according to specific needs.Remote Access CommunityA Remote Access Community is a type of VPN community created specifically forusers that usually work from remote locations, outside of the corporate LAN. This typeof community ensures secure communication between users and the corporate LAN.For more information, see: “VPN for Remote Clients”.26

VPN TopologiesVPN TopologiesThe most basic topology consists of two Gateways capable of creating a VPN tunnelbetween them. SmartCenter Server’s support of more complex topologies enables VPNcommunities to be created according to the particular needs of an organization.SmartCenter Server supports two main VPN topologies:• Mesh• StarMesh VPN CommunityA Mesh is VPN community in which a VPN site can create a VPN tunnel with anyother VPN site:FIGURE 2-4Basic Mesh communityStar VPN CommunityA star is a VPN community consisting of central Gateways (or “hubs”) and satelliteGateways (or “spokes”). In this type of community, a satellite can create a tunnel onlywith other sites whose Gateways are defined as central.Chapter 2 Building a VPN Between Gateways 27

The Check Point Solution for VPNFIGURE 2-5Star VPN communityA satellite Gateway cannot create a VPN tunnel with a Gateway that is also defined asa satellite Gateway.Central Gateways can create VPN tunnels with other Central Gateways only if theMesh center gateways option has been selected on the Central Gateways page of the StarCommunity Properties window.Choosing a topologyWhich topology to choose for a VPN community depends on the overall policy of thethe organization. For example, a mesh community is usually appropriate for an Intranetin which only Gateways which are part of the internally managed network are allowedto participate; Gateways belonging to company partners are not.A Star VPN community is usually appropriate when an organization needs to exchangeinformation with networks belonging to external partners. These partners need tocommunicate with the organization but not with each other. The organization’sGateway is defined as a “central” Gateway; the partner Gateways are defined as“satellites”.For more complex scenarios, consider a company with headquarters in two countries,London and New York. Each headquarters has a number of branch offices. The branchoffices only need to communicate with the HQ in their country, not with each other;only the HQ’s in New York and London need to communicate directly. To complywith this policy, define two star communities, London and New York. Configure theLondon and New York Gateways as “central” Gateways. Configure the Gateways of28

The Check Point Solution for VPNFIGURE 2-7Different means of encryption in separate Mesh communitiesIn this solution, Gateways in the Washington mesh are also defined as satellites in theLondon star. In the London star, the central Gateways are meshed. Gateways inWashington build VPN tunnels with the London Gateways using DES. Internally, theWashington Gateways build VPN tunnels using 3DES.Special Condition for VPN GatewaysIndividually, Gateways can appear in many VPN communities; however, two Gatewaysthat can create a VPN link between them in one community cannot appear in anotherVPN community in which they can also create a link. For example:30

VPN TopologiesFIGURE 2-8Special conditionThe London and New York Gateways belong to the London-NY Mesh VPNcommunity. To create an additional VPN community which includes London, NewYork, and Paris is not allowed. The London and New York Gateways cannot appear“together” in more than one VPN community.Two Gateways that can create a VPN link between them in one community can appearin another VPN community provided that they are incapable of creating a link betweenthem in the second community. For example:FIGURE 2-9Three VPN communitiesChapter 2 Building a VPN Between Gateways 31

The Check Point Solution for VPNIn FIGURE 2-9, The London and New York Gateways appear in the London-NYmesh. These two Gateways also appear as Satellite Gateways in the Paris Star VPNcommunity. In the Paris Star, satellite Gateways (London and NY) can onlycommunicate with the central Paris Gateway. Since the London and New York satelliteGateways cannot open a VPN link between them, this is a valid configuration.Authentication Between Community MembersBefore Gateways can exchange encryption keys and build VPN tunnels, they first needto authenticate to each other. Gateways authenticate to each other by presenting one oftwo types of “credentials”:• Certificates. Each Gateway presents a certificate which contains identifyinginformation of the Gateway itself, and the Gateway’s public key, both of which aresigned by the trusted CA. For convenience, VPN-1 has its own Internal CA thatautomatically issues certificates for all internally managed Gateways, requiring noconfiguration by the user. In addition, VPN-1 supports other PKI solutions. Formore information, see: Using PKI Solutions.• Pre-shared secret. A pre-shared is defined for a pair of Gateways. Each Gatewayproves that it knows the agreed upon pre-shared secret. The pre-shared secret canbe a mixture of letters and numbers, a password of some kind.Considered more secure, certificates are the preferred means. In addition, since theInternal CA on the SmartCenter Server automatically provides a certificate to eachVPN-1 Gateway it manages, it is more convenient to use this type of authentication.However, if a VPN tunnel needs to be created with an externally managed Gateway (aGateway managed by a different SmartCenter Server) the externally managed Gateway:• Might support certificates, but certificates issued by an external CA, in which caseboth Gateways need to trust the other’s CA. (See: “Using PKI Solutions”.”Formore information, see: “Configuring a VPN with External Gateways Using PKI”on page 69.)• May not support certificates; in which case, VPN-1 supports the use of a“pre-shared secret”. For more information, see: “Configuring a VPN with ExternalGateways Using a Pre-Shared Secret” on page 72.A “secret” is defined per external Gateway. If there are five internal Gateways andtwo externally managed Gateways, then there are two pre-shared secrets. The twopre-shared secrets are used by the five internally managed Gateways. In other words,all the internally managed Gateways use the same pre-shared secret whencommunicating with a particular externally managed Gateway.32

Access Control and VPN CommunitiesAccess Control and VPN CommunitiesConfiguring Gateways into a VPN community does not create a de facto access controlpolicy between the Gateways. The fact that two Gateways belong to the same VPNcommunity does not mean the Gateways have access to each other.The configuration of the Gateways into a VPN community means that if theseGateways are allowed to communicate via an access control policy, then thatcommunication is encrypted. Access control is configured in the Security Policy RuleBase.Using the VPN column of the Security Policy Rule Base, it is possible to create accesscontrol rules that apply only to members of a VPN community, for example:TABLE 2-1Source Destination VPN Service ActionAny Any Community_A HTTP AcceptThe connection is matched only if all the conditions of the rule are true, that is - itmust be an HTTP connection between a source and destination IP address within VPNCommunity A. If any one of these conditions is not true, the rule is not matched. If allconditions of the rule are met, the rule is matched and the connection allowed.It is also possible for a rule in the Security Policy Rule Base to be relevant for bothVPN communities and host machines not in the community. For example:FIGURE 2-10 Access control in VPN communitiesChapter 2 Building a VPN Between Gateways 33

Special Considerations for Planning a VPN TopologyThe rule in the Security Policy Rule base allows an HTTP connection between anyinternal IP with any IP:Source Destination VPN Service ActionAny_internal_machine Any Any HTTP AcceptIn FIGURE 2-10, an HTTP connection between host 1 and the Internal web serverbehind Gateway 2 matches this rule. A connection between the host 1 and the webserver on the Internet also matches this rule; however, the connection between host 1and the internal web server is a connection between members of a VPN communityand passes encrypted; the connection between host 1 and the Internet web server passesin the clear.In both cases, the connection is simply matched to the Security Policy Rule; whetheror not the connection is encrypted is dealt with on the VPN level. VPN is another levelof security separate from the access control level.Accepting all Encrypted TrafficIf you select Accept all encrypted traffic on the General page of the VPN communityProperties window, a new rule is added to the Security Policy Rule Base. This rule isneither a regular rule or an implied rule, but an automatic community rule, and can bedistinguished by its “beige” colored background.Excluded ServicesIn the VPN Communities Properties window Excluded Services page, you can selectservices that are not be encrypted, for example FireWall-1control connections. Servicesin the clear means “do not make a VPN tunnel for this connection”. For furtherinformation regarding control connections, see: “How to Authorize FireWall-1 ControlConnections in VPN Communities” on page 75”.Special Considerations for Planning a VPN TopologyWhen planning a VPN topology it is important to ask a number of questions:1 Who needs secure/private access?2 From a VPN point of view, what will be the structure of the organization?3 Internally managed Gateways authenticate each other using certificates, but howwill externally managed Gateways authenticate?• Do these externally managed Gateways support PKI?• Which CA should be trusted?34

Enabling Simplified ModeConfiguring a VPN Between GatewaysVPN communities can be configured in either traditional or simplified mode. InTraditional mode, one of actions available in the Security Policy Rule Base is Encrypt.When encrypt is selected, all traffic between the Gateways is encrypted. VPN is moreeasily configured through the use of VPN communities, otherwise known as workingin Simplified Mode. For more information regarding traditional mode, see: “TraditionalMode VPNs”.Enabling Simplified ModeTo switch from Traditional mode to Simplified:1 In Global Properties > VPN-1 Pro page, select either Simplified mode to all newSecurity Policies, or Traditional or Simplified per new Security Policy.Note - If you upgrade VPN-1 from 4.1 to NG, select in the Global Properties window:Simplified mode to all new security policies. This means new policies are created usingSimplified mode.2 File > Save. (If you do not save, you are prompted to do so).3 File > New... The New Policy Package window opens.4 Create a name for the new security policy package and select Security and AddressTranslation.5 For the VPN configuration method, select Simplified mode (if you selectedTraditional or Simplified per new Security policy in Global Properties). Click OK.In the Security Policy Rule base, a new column marked VPN appears and the Encryptoption is no longer available in the Action column. You are now working in SimplifiedMode.Configuring a Mesh Community Between Internally ManagedGatewaysInternally managed VPN communities have one of two possible topologies; mesh orstar. (For externally managed Gateways, see: VPN-1 Advanced Configuration.) Toconfigure an internally managed VPN mesh community, create the network objects(Gateways) first and then add them to the community:1 In the Network Objects tree, right click Network Objects > New > Check Point >Gateway...Select Simple mode (wizard) or Classic mode. The Check Point Gatewayproperties window opens.Chapter 2 Building a VPN Between Gateways 35

Configuring a VPN Between Gatewaysa On the General Properties page, after naming the object and supplying anIP address, select VPN-1 Pro or VPN-1 Net and establish SIC communication.b On the Topology page, click Add to add interfaces. Once an interfaceappears in the table, clicking Edit... opens the Interface Properties window.c In the Interface Properties window, define the general properties of theinterface and the topology of the network behind it.diiiStill on the Topology page, VPN Domain section, define the VPN domain aseither all the machines behind the Gateway based on the topologyinformation or manually defined:As an address range.As a network.iii As a group, which can be a combination of address ranges, networks, andeven other groups.(There are instances where the VPN domain is a group which contains only theGateway itself, for example where the Gateway is acting as a backup to a primaryGateway in a MEPed environment.)The network Gateway objects are now configured, and need to be added to a VPNcommunity.Note - There is nothing to configure on the VPN page, regarding certificates, since internallymanaged Gateways automatically receive a certificate from the internal CA.2 On the Network objects tree, select the VPN Communities tab.A Right-click Site to Site.B From the short-cut menu, select New Site To Site... > Meshed. The MeshedCommunities Properties window opens.C On the General page, select Accept all encrypted traffic if you need all trafficbetween the Gateways to be encrypted. If not, then create appropriate rules inthe Security Policy Rule Base that allows encrypted traffic betweencommunity members.D On the Participating Gateways page, add the Gateways created in step 1.A VPN tunnel is now configured. For more information on other options, such as VPNProperties, Advanced Properties, and Shared Secret, see: “Understanding andCustomizing IKE”, and “VPN-1 Advanced Configuration”.36

Configuring a Star VPN Community3 If you did not select Accept all encrypted traffic in the community, build an accesscontrol policy, for example:TABLE 2-2Source Destination VPN Service ActionAny Any Meshed community Any AcceptWhere “Meshed community” is the VPN community you have just defined.Configuring a Star VPN CommunityA star VPN community is configured in much the same way as a mesh community, thedifference being the options presented on the Star Community Properties window:• On the General page, Enable VPN routing for satellites section, select a To centeronly. For more information on VPN routing, see the “VPN Routing”.• On the Central Gateways page, Add... the central Gateways.• On the Central Gateways page, select Mesh central gateways if you want the centralgateways to communicate.• On the Satellite Gateways page, Add... the satellite Gateways.Confirming a VPN Tunnel Successfully OpensTo confirm a VPN tunnel has successfully opened:1 Edit a rule in the Security Policy Rule base that encrypts a specific service betweenMember Gateways of a VPN community, for example FTP.2 Select log as the tracking option.3 Open an appropriate connection, in this example FTP session from a host behindthe first Gateway to an FTP server behind the second.4 Open SmartView Tracker and examine the logs. The connection appears asencrypted, as in FIGURE 2-11.FIGURE 2-11 Sample logChapter 2 Building a VPN Between Gateways 37

Configuring a VPN Between Gateways38

CHAPTER 3Using PKI SolutionsIn This ChapterNeed for Integration with Different PKI solutions page 39Solution - Supporting a Wide Variety of PKI Solutions page 40PKI Considerations page 46Configuration of PKI Operations page 47Need for Integration with Different PKI solutionsX.509-based PKI solutions provide the infrastructure that enables entities to establishtrust relationships between each other based on their mutual trust of the CertificateAuthority (CA). The trusted CA issues a certificate for an entity, which includes theentity’s public key. Peer entities that trust the CA can trust the certificate — becausethey can verify the CA’s signature — and rely on the information in the certificate, themost important of which is the association of the entity with the public key.IKE standards recommend the use of PKI in VPN environments, where strongauthentication is required.A VPN-1 module taking part in a VPN tunnel establishment must have an RSA keypair and a certificate issued by a trusted CA. The certificate contains details about themodule’s identity, its public key, CRL retrieval details, and is signed by the CA.When two entities try to establish a VPN tunnel, each side supplies its peer with someinformation signed by its private key and with the certificate that contains the publickey. The certificate enables the establishment of a trust relationship between thegateways; each gateway uses the peer gateway’s public key to verify the source of thesigned information and the CA’s public key to validate the certificate’s authenticity. Inother words, the validated certificate is used to authenticate the peer.39

Solution - Supporting a Wide Variety of PKI SolutionsEvery deployment of Check Point SmartCenter server includes an Internal CertificateAuthority (ICA) that issues VPN certificates for the VPN-1 modules it manages. TheseVPN certificates simplify the definition of VPNs between these modules. For moreinformation about the ICA, see Chapter 3, “The Internal Certificate Authority (ICA)and the ICA Management Tool” in the SmartCenter Guide.In some situations, integration with other PKI solutions is required, for example:• A VPN must be established with a VPN-1 module managed by an externalSmartCenter server. For example, the peer gateway belongs to another organizationwhich utilizes Check Point products, and its certificate is signed by its ownSmartCenter server’s ICA.• A VPN must be established with a non-Check Point VPN entity. In this case, thepeer’s certificate is signed by a third-party CA.• An organization may decide, for whatever reason, to use a third party CA togenerate certificates for its VPN-1 modules.Solution - Supporting a Wide Variety of PKI SolutionsVPN-1 supports many different scenarios for integrating PKI in VPN environments.• Multiple CA Support for Single VPN Tunnel – Two Check Point VPN-1 modulespresent a certificate signed by different ICAs.• Support for non-ICA CAs – In addition to ICA, VPN-1 supports the following CAs:• External ICA - The ICA of another SmartCenter• Other OPSEC certified PKI solutions• Entrust CA• CA Hierarchy – CAs are often arranged in an hierarchical structure where multipleCAs are subsidiary to the root CA. VPN-1 supports a CA hierarchy of as many as32 levels.PKI and Remote Access UsersVPN-1 supports certificates not only for gateways but for users as well. See “VPN forRemote Clients”” for information about user certificates.PKI Deployments and VPNFollowing are some examples of CA deployments and the respective typical VPNscenarios. Since VPN-1 can establish VPN tunnels with various other VPN solutions(internally managed, externally managed and non-Check Point VPN solutions) andwith different CA types, a wide variety of VPN scenarios is possible.40

PKI Deployments and VPNSimplest Deployment – Internal CAWhen the VPN tunnel is established between gateways managed by the sameSmartCenter server, each peer has a certificate issued by the SmartCenter server’s ICA.CA of An External SmartCenter ServerIf a VPN gateway is managed by an external SmartCenter server (for example, whenestablishing a VPN tunnel with another organization’s VPN-1 modules), each peer hasa certificate signed by its own SmartCenter server’s ICA.FIGURE 3-1Two gateways managed by different SmartCenter serversCA Services Over the InternetIf a VPN gateway’s certificate is issued by a third party CA accessible over the Internet,CA operations such as registration or revocation are usually performed through HTTPforms. CRLs are retrieved from an HTTP server functioning as a CRL repository.FIGURE 3-2 depicts a CA and CRL repository accessible over the Internet.Chapter 3 Using PKI Solutions 41

Solution - Supporting a Wide Variety of PKI SolutionsFIGURE 3-2CA services are on the InternetCA is located on the LANIf the peer VPN gateway’s certificate is issued by a third party CA on the LAN, theCRL is usually be retrieved from an internal LDAP server. FIGURE 3-3 depicts such asituation.FIGURE 3-3Third Party CA deployed locallyTrusting a CA – OverviewA trust relationship is a crucial prerequisite for establishing a VPN tunnel. However, itis possible only if the CA that signs the peer’s certificate is trusted. The followingsections describe how to configure support for PKI operations and X.509 certificates inVPN-1.42

Enrolling a Managed EntityTrusting a CA means obtaining and validating the CA’s own certificate. Once this isdone, the details on the CA certificate and its public key can be used both to obtainand validate certificates issued by the CA.The Check Point Internal CA (ICA) is automatically trusted by all modules managedby the SmartCenter server that deploys the ICA. Other CAs are not automaticallytrusted, so a module must first obtain the CA’s certificate and validate it.To obtain a CA’s certificate, proceed as follows:• ICA of an external SmartCenter server — See Chapter 3, “The Internal CertificateAuthority (ICA) and the ICA Management Tool in the SmartCenter Guide forinformation on how to do this.• OPSEC Certified CA — Use the CA tools.• Entrust CA — Because the Entrust CA certificate is delivered during theenrollment process, there are two possibilities:• If the Entrust CA issues certificates for modules managed by the SmartCenterserver, then the SmartCenter server already has the Entrust CA’s certificate.• If the Entrust CA issues certificates only for other VPN entities, then the CAcertificate must be obtained from those entities.Enrolling a Managed EntityEnrollment means obtaining a certificate from a CA, that is, requesting that the CAissue a certificate for an entity.The process of enrollment begins with generation of key pair. A certificate request isthen created out of the public key and additional information about the module. Thetype of the certificate request and the rest of the enrollment process depends on the CAtype.The case of an internally managed gateway is the simplest, because the ICA is locatedon the SmartCenter server machine. The enrollment process is completed with noadministrator intervention.To obtain a certificate from an OPSEC Certified CA, SmartCenter server takes themodule details and the public key and encodes a PKCS#10 request. The request (whichcan include SubjectAltName for OPSEC certificates and Extended Key Usage extensions)is delivered to the CA manually by the administrator. Once the CA issues the certificatethe administrator can complete the process by importing the certificate to theSmartCenter server.Chapter 3 Using PKI Solutions 43

Solution - Supporting a Wide Variety of PKI SolutionsIn the case of an Entrust CA, the CA administrator supplies the SmartCenter serveradministrator with a Reference Number and Authorization code. The SmartCenterserver communicates with the Entrust CA directly, authenticates with this informationand completes the enrollment.An Entrust CA is supported for versions 3.0. 4.0, 5.0, and 6.0. By default, a certificateis enrolled using the Entrust CMS library. For Entrust 5.0 and 6.0, certificates areenrolled using the standard CMP protocol.Validation of CertificateWhen an entity receives a certificate from another entity, it must validate it as follows:• Verify the certificate signature, i.e. verify that the certificate was signed by a trustedCAIf the certificate is not signed directly by a trusted CA, but rather by a subsidiary ofa trusted CA, the path of CA certificates is verified up to the trusted CA.• Verify that the certificate chain is not expired.• Verify that the certificate chain is not revoked. A CRL is retrieved to confirm thatthe serial number of the validated certificate is not included among the revokedcertificates.In addition, VPN-1 verifies the validity the certificate’s use in the given situation,confirming that:• The certificate is authorized to perform the action done. If, for example, theprivate key was used to sign some data (e.g., for authentication) the KeyUsageextension on the certificate – if it is present – is checked to see if this is permitted.• The peer used the correct certificate in the negotiation. When creating a VPNtunnel with externally managed module, the administrator may decide that only acertificate signed by a specific CA from among the trusted CAs is accepted.Acceptance of certificates with specific details such as Distinguished Name (DN) ispossible as well.Revocation CheckingVPN-1 can retrieve the CRL from either an HTTP server or an LDAP server. If theCRL repository is an HTTP server, the module uses the URL published in the CRLDistribution Point extension in the certificate and opens an HTTP connection to theCRL repository to retrieve the CRL.If the CRL repository is an LDAP server, VPN-1 attempts to locate the CRL in one ofthe LDAP account units defined. In this case, definition of LDAP account unit isrequired. If the CRL Distribution Point extension exists, it publishes the DN of the44

Validation of CertificateCRL, namely, the entry in the Directory under which the CRL is published or theLDAP URI. If the extension does not exist, VPN-1 tries to locate the CRL in theentry of the CA itself in the LDAP server.CRL Prefetch-CacheSince the retrieval of CRL takes a long time in comparison to the entire IKEnegotiation process, VPN-1 stores the CRLs in a CRL cache so that later IKEnegotiations do not require repeated CRL retrievals.The cache is pre-fetched:• every two hours• on policy installation• when the cache expiresIf the pre-fetch fails, the previous cache is not erased.Note - The ICA requires the use of a CRL cache.An administrator can shorten the lifetime of a CRL in the cache or even to cancel theuse of the cache. If the CRL Cache operation is cancelled, the CRL must be retrievedfor each subsequent IKE negotiation, thus considerably slowing the establishment of theVPN tunnel. Because of these performance implications, it is recommend that CRLcaching be disabled only when the level of security demands continuous CRL retrieval.See also: “Modifying the CRL Pre-Fetch Cache” on page 55.Special Considerations for the CRL Pre-fetch MechanismThe CRL pre-fetch mechanism makes a “best effort” to obtain the most up to date listof revoked certificates. However, after the cprestart command has been executed, thecache is no longer updated. The Gateway continues to use the old CRL for as long asthe old CRL remains valid (even if there is an updated CRL available on the internalCA). The pre-fetch cache mechanism returns to normal functioning only after the oldCRL expires and a new CRL is retrieved from the internal CA.To manually update the CRL:• After exececuting cprestart, run crl_zap to empty the cache, or:Chapter 3 Using PKI Solutions 45

PKI Considerations• In Global properties > SmartDashboard Customization > Configure > Check Point CAproperties > select: flush_crl_cache_file_on_install.When a new policy is installed, the cache is flushed and a new CRL is retrieved fromthe internal CA.CRL Grace PeriodTemporary loss of connection with the CRL repository or slight differences betweenclocks may cause valid of CRLs to be considered invalid—and thus the certificates to beinvalid as well—although the problem is momentary. VPN-1 offers a way to overcomethis problem by supplying a CRL Grace Period. During this period, a CRL isconsidered as valid although if strictly adhering to the CRL validity time it not.PKI ConsiderationsIn This SectionUsing the Internal CA vs. Deploying a Third Party CA page 46Storing Private Keys on the Module page 47Using the Internal CA vs. Deploying a Third Party CAThe Internal CA makes it very easy to use PKI for Check Point applications such assite-to-site and remote access VPNs. However, an administrator may prefer to continueusing a CA that is already used within the organization, for generalized applicationssuch as secure email, and disk encryption.46

Storing Private Keys on the ModuleStoring Private Keys on the ModuleSince the Policy Install is performed on a secure channel, the private keys and thesensitive data are securely delivered to the modules. Using a hardware storage on themodule, where the keys generated and stored locally, has the benefit of extra securitybut is more expensive.See “Key Generation and Storage on the Module” on page 50 for more information.Configuration of PKI OperationsIn This SectionTrusting a CA – Step-By-Step page 47Enrollment – Step-By-Step page 49Certificate Revocation (All CA Types) page 53Certificate Recovery and Renewal page 53Adding Matching Criteria to the Validation Process page 54CRL Cache Usage page 54Modifying the CRL Pre-Fetch Cache page 55Configuring CRL Grace Period page 55This chapter supplies the details of PKI operations, but does not supply details fordefinition of VPN using certificates. The details about VPN configuration in variouscases are dealt with in “Building a VPN Between Gateways” on page 23 and in“VPN-1 Advanced Configuration” on page 69.Trusting a CA – Step-By-StepThis section describes the procedures for obtaining a CA’s own certificate, which is aprerequisite for trusting certificates issued by that CA.In order to trust a CA, a CA server object has to be defined. The following sectionsdeal with the various configuration steps required in the various cases.Trusting an ICAA VPN-1 module automatically trusts its own ICA, and there is no need to performany configuration.Trusting an Externally Managed CAThe CA certificate has to be handed to the administrator in advance.Chapter 3 Using PKI Solutions 47

Configuration of PKI OperationsProceed as follows:1 Open Manage > Servers...The Servers window is opened.2 Choose New > Certificate Authority.3 Enter the Name of the CA object and select the External Management Server CAtype.4 Go to the External Management Server tab and click Get...5 Browse to the path in which you saved the peer CA certificate and select it.VPN-1 reads the certificate and displays its details. It is possible to verify thecertificate’s details. If required, the SHA-1 and MD5 fingerprints of the CAcertificate are displayed.6 Click OK.Trusting an OPSEC Certified CAThe CA Certificate must be retrieved either by downloading it using the CA tools orby obtaining it from the peer administrator in advance.Then define the CA object according to the following steps:1 Open Manage > Servers...The Servers window is displayed.2 Choose New > Certificate Authority.3 Enter the Name of the CA object and select the OPSEC PKI CA type.4 Go to the OPSEC PKI tab.This tab defines the way of CRL retrieval and enables import of the CA certificate.5 Choose the method for retrieving CRLs from this CA.If this CA publishes CRLs on HTTP server choose HTTP Server(s). In this case,certificates issued by the CA must contain the CRL location in a URL in the CRLDistribution Point.If the CA publishes CRL on LDAP server, choose LDAP Server(s). In this case, youmust define an LDAP Account Unit as well. See Chapter 8, “SmartDirectory(LDAP) and User Management” in the SmartCenter guide for more details aboutdefining such an object. Make sure that CRL retrieval is checked in the General tabof the LDAP Account Unit Properties window.6 Click Get...48

Enrollment – Step-By-Step7 Browse to the path in which you saved the peer CA certificate and select it.VPN-1 reads the certificate and displays its details. It is possible to verify the details.If required, the SHA-1 and MD5 fingerprints of the CA certificate are displayed.8 Click OK.Trusting an Entrust CAWhen Entrust CA is trusted a CA configuration file is required. This file, usuallynamed Enrust.ini, includes a number of parameters used when VPN-1 connects tothe CA for the enrollment process. Obtain this file from the CA administrator inadvance.If the CA is defined only for validating certificates sent by VPN peers, then the CAcertificate must also be obtained in advance.In order to define the CA, proceed as follows:1 Open Manage > Servers...The Servers window is displayed.2 Choose New > Certificate Authority.3 Enter the Name of the CA object and select the Entrust PKI CA type.4 Go to the Entrust PKI tab.This tab includes specific details about the Entrust CA.5 Choose the appropriate Entrust CA version.VPN-1 Pro supports Entrust 3.0, 4.0, 5.0 and 6.0. (For Entrust 6.0 select version 5.0).6 In the Configuration field click Get..., browse to the Entrust.ini location andselect the file.7 If the Entrust CA is trusted only for validation of certificates sent to the VPN-1modules managed by this SmartCenter server, browse to the path in which yousaved the peer CA certificate and select it.VPN-1 reads the certificate and displays its details. It is possible to verify the details.If required, the SHA-1 and MD5 fingerprints of the CA certificate are displayed.8 Click OK.Enrollment – Step-By-StepThe enrollment process for gateways is different for each CA type. Following are thesteps to follow for obtaining a certificate for a module per CA type.Chapter 3 Using PKI Solutions 49

Configuration of PKI OperationsKey Generation and Storage on the ModuleUsually, the SmartCenter server generates the key pair and downloads the keys and thecertificate to the module when the policy is installed. Sometimes the securityrequirements demand that the private key be created and stored on the module andnever leave the module. In this case, SmartCenter server asks the module to create thekey pair. The module stores the private key locally and sends the public key to theSmartCenter server. The SmartCenter server then downloads the certificate to themodule during policy installation.To cause the keys to be generated and stored on the module, the administrator mustchoose Store Keys on the Module in the Certificate Properties window during thecertificate generation process.Local key storage is supported for all CA types except Entrust.Note - Local key storage requires that the key be stored on a hardware token on the module.Enrollment with Internal CASince every internally managed entity with VPN-1 Pro or VPN-1 Net installed on it isa candidate for creation of VPN tunnels, a certificate is automatically issued by the ICAfor all these objects. This happens immediately after the SmartCenter server identifiesthat an entity fulfills this condition, namely, when the administrator checks one of theVPN-1 Pro or VPN-1 Net boxes in the General Properties tab of a network object.Enrollment with OPSEC Certified PKITo create a PKCS#10 Certificate Request proceed as follows:1 Open the VPN tab of the relevant Network Object.2 In the Certificate List field click Add...The Certificate Properties window is displayed.3 Enter the Certificate NicknameThe nickname is only an identifier and has no bearing on the certificate content.4 Choose the OPSEC Certified Certificate Authority from which you would like toget the certificate.The Certificate Authority object must be defined in advance. Refer to “Trusting anOPSEC Certified CA” on page 48 for more details.50

Enrollment – Step-By-Step5 Choose the appropriate method for Key Pair creation and storage. The Store KeysOn Module option is relevant only if hardware storage is installed on the module.See “Storing Private Keys on the Module” on page 47 for more information.6 Click Generate...The Generate Certificate Properties window is displayed.7 Enter the desired DN.Please note that the final DN in the certificate is a subject for the CA administratordecision.FIGURE 3-4An example DN.8 If for some reason the Subject Alternate Name extension is required to appear inthe certificate and contain the DN, check the Define Alternate Name check box.9 Click OK.According to your setting about the key store location, the SmartCenter server orthe module generate the key pair. The public key and the DN are then used toDER-encode a PKCS#10 Certificate Request.10 Once the Certificate Request is ready, click View...The Certificate Request View window appears with the encoding.11 Copy the whole text in the window and deliver it to the CA.The CA administrator must now complete the task of issuing the certificate. DifferentCAs provide different ways of doing this, such as an advanced enrollment form (asopposed to the regular form used by users). The issued certificate may be delivered invarious ways, such as email. Once the certificate is available, proceed as follows to storethe certificate in VPN-1 Pro.1 Go to the VPN tab of the network object, select the appropriate certificate objectand click Edit...The Certificate Properties window is displayed.2 Click Get... and browse to the location in which the certificate was saved.Chapter 3 Using PKI Solutions 51

Configuration of PKI Operations3 Select the appropriate file and verify the certificate details.4 Close the object and save.Enrollment with Entrust CAIn order to get an Entrust certificate proceed as follows:1 Obtain the Reference Number and Authorization Code from the CAadministrator.These numbers are created by the Entrust CA when willing to make an entity‘Entrust Enabled’ and presented to the CA administrator who may deliver them tothe VPN-1 administrator. They will be used by the CA to authenticate the requestand issue the certificate.2 Open the VPN tab of the relevant Network Object3 In the Certificate List field click Add...The Certificate Properties window is displayed.4 Enter the Certificate NicknameThe nickname is only an identifier and has no bearing on the certificate content.5 Choose the Entrust Certificate Authority from which you would like to get thecertificate.6 The Certificate Authority object must be defined in advance. Refer to “Trusting anEntrust CA” on page 49 for more details about definition of the Entrust CA object.7 Click Generate...The Generate Keys and Get Entrust Certificate is displayed.8 Make sure the Generate Mode is set to Initialize.9 Enter the Reference Number and Authorization Code.SmartCenter server generates the Key Pair and connects the Entrust CA using theappropriate protocol to obtain the certificate. If this is the first certificate issued toa module managed by this SmartCenter server, the Entrust CA certificate is saved aswell. It is recommended to re-open later the Entrust CA object and verify that theCA Certificate was stored by clicking View... in the Entrust PKI tab of the CertificateAuthority Properties window.10 Close the Object and Save.52

Certificate Revocation (All CA Types)Enrollment with Entrust 5.0 and 6.0When working with Entrust 5.0 or 6.0, VPN-1 Pro enrolls the certificate using thestandard CMP protocol rather than using the CMS Entrust proprietary protocol andlibrary.From the administrator’s perspective there is no change in the enrollment process.However, communication with the Entrust CA takes place via the CMP protocol whenrequesting a new certificate for the gateway.To enable CMP support, edit the object_5_0.C file and change the value of thefollowing attribute: entrustProtocolType to ‘cmp’.Certificate Revocation (All CA Types)If the certificate is issued by the Internal Certificate Authority it is revoked when thecertificate object is removed. Otherwise, the certificate revocation is done by the CAadministrator using the CA tools. Still, the certificate must be removed from VPN-1 toprevent the module from using it.To remove the certificate proceed as follows:1 Open the VPN tab of the relevant Network Object.2 In the Certificate List field select the appropriate certificate and click Remove.A certificate cannot be removed if Smart Center server infers from other settingsthat the certificate is in use, for example, that the module belongs to one or moreVPN communities and this is the module’s only certificate.Certificate Recovery and RenewalWhen a certificate is revoked or becomes expired, it is necessary to create another oneor to refresh the existing one.Recovery and Renewal with Internal CARemoval of a compromised or expired certificate automatically triggers creation of anew certificate, with no administrator intervention.Chapter 3 Using PKI Solutions 53

Configuration of PKI OperationsRecovery and Renewal with OPSEC Certified CARenewal of a certificate as well as recovery are done by creation of a certificate usingthe same procedure for creation of a new one. See “Enrollment with OPSEC CertifiedPKI” on page 50 for more information.Note - A module can have only one certificate signed by a particular CA. Thus, when thenew certificate is issued, you will be asked whether to replace any existing certificate signedby the same CA.Recovery and Renewal with Entrust CARecovery and Renewal are performed similarly to the procedure or generation of anew certificate. See “Enrollment with Entrust CA” on page 52 for more details. In theGeneration Mode field, select either Recover or Refresh as appropriate. In the case ofRenewal, there is no need to supply Reference Number and Authorization Code.Adding Matching Criteria to the Validation ProcessThe certificates of an externally managed VPN entity are not handled by the localSmartCenter server. However, you can force a peer to present a particular certificatewhen creating a VPN tunnel, as follows:1 Open the VPN page of the externally managed VPN entity.2 Click Matching Criteria...3 Choose the desired characteristics of the certificate the peer is expected to present,including:• the CA that issued it• the exact DN of the certificate• select the IP address that appears in the Subject Alternate Name extension of thecertificate.This IP address is compared to the IP address of the VPN peer itself as it appearsto the VPN-1 Pro module during the IKE negotiation.• the e-mail address appearing in the Subject Alternate Name extension of thecertificateCRL Cache UsageSee “CRL Prefetch-Cache” on page 45 for information about CRL caching.To modify the behavior of the CRL Cache or cancel its use proceed as follows:1 Open the Advance Tab of the Certificate Authority object.54

Modifying the CRL Pre-Fetch Cache2 To enable the CRL cache, check Cache CRL on the module.The cache should not be disabled for the ICA. In general, it is recommended thatthe cache always be enabled for all CA types. The cache should be disabled (fornon-ICA) only if stringent security requirements mandate continual retrieval of theCRL.Note - The ICA requires the use of a CRL cache.3 If CRL Cache is enabled, choose whether a CRL is deleted from the cache whenit expires or after a fixed period of time (unless it expires first). The second optionencourages retrieval of a CRL more often as CRLs may be issued more frequentlythen the expiry time. By default a CRL is deleted from the cache after 24 hours.Modifying the CRL Pre-Fetch CacheThe behavior of the Pre-fetch catch can be altered via1 Global Properties > SmartDashboard Customization > Configure... buttonThe Advanced Configuration window opens.2 Check Point CA Properties:Configuring CRL Grace PeriodSet the CRL Grace Period values by selecting Policy > Global Properties > VPN-1 Pro, inthe Advanced page. The Grace Period can be defined for both the periods before andafter the specified CRL validity period.Chapter 3 Using PKI Solutions 55

Configuration of PKI Operations56

CHAPTER 4Understanding andCustomizing IKEIn This ChapterThe Need for Advanced IKE ConfigurationVPN-1 is designed to employ secure and reliable default methods during lPSec.However, the security requirements of a particular organization may require otherencryption or integrity methods. Or perhaps Check Point VPN-1 Pro Gateways areinteroperating with VPN solutions provided by third party vendors which do notsupport the Check Point default methods. In such instances, the way the IKEnegotiation is performed needs to be modified.Check Point Solution for Advanced IKE ConfigurationBy supporting different IKE modes and methods, VPN-1 has the ability to configurethe way IKE is negotiated between VPN peers.IKE OverviewThe Need for Advanced IKE Configuration page 57Check Point Solution for Advanced IKE Configuration page 57Configuring Advanced IKE Properties page 66In symmetric cryptographic systems, both communicating parties use the same key forencryption and decryption. The material used to build these keys must be exchanged ina secure fashion. Information can be securely exchanged only if the key belongsexclusively to the communicating parties.57

Check Point Solution for Advanced IKE ConfigurationThe goal of the Internet Key Exchange (IKE) is for both sides to independently producethe same symmetrical key. This key then encrypts and decrypts the regular IP packetsused in the bulk transfer of data between VPN peers. IKE builds the VPN tunnel byauthenticating both sides and reaching agreement on methods of encryption andintegrity. The outcome of an IKE negotiation is a Security Association (SA).This agreement upon keys and methods of encryption must also be performed securely.For this reason IKE is composed of two phases. The first phase lays the foundations forthe second.Diffie-Hellman is that part of the IKE protocol used for exchanging the material fromwhich the symmetrical keys are built. The Diffie-Hellman algorithm builds anencryption key known as a “shared secret” from the private key of one party and thepublic key of the other. Since the IPSec symmetrical keys are derived from this DH keyshared between the peers, at no point are symmetric keys actually exchanged via theInternet.IKE Phase IDuring IKE Phase I:• The peers authenticate, either by certificates or via a pre-shared secret. (Pre-sharedsecrets are less secure. More authentication methods are available when one of thepeers is a remote access client.)• A Diffie-Hellman key is created. The nature of the Diffie-Hellman protocol meansthat both sides can independently create the shared secret, a key which is knownonly to the peers.• Key material (random bits and other mathematical data) as well as agreement onmethods for IKE phase II are exchanged between the peers.In terms of performance, the generation of the Diffie Hellman Key is slow and heavy.The outcome of this phase is the IKE SA, an agreement on keys and methods for IKEphase II. FIGURE 4-1 illustrates the process that takes place during IKE phase I butdoes not reflect the actual order of events.58

IKE OverviewFIGURE 4-1IKE phase IIKE Phase II (Quick mode)IKE phase II is encrypted according to the keys and methods agreed upon in IKEphase I. The key material exchanged during IKE phase II is used for building the IPSeckeys. The outcome of phase II is the IPSec Security Association. The IPSec SA is anagreement on keys and methods for IPSec, thus IPSec takes place according to the keysand methods agreed upon in IKE phase II.Chapter 4 Understanding and Customizing IKE 59

Check Point Solution for Advanced IKE ConfigurationFIGURE 4-2IKE Phase IIOnce the IPSec keys are created, bulk data transfer takes place:60

Methods of Encryption and IntegrityMethods of Encryption and IntegrityTwo parameters are decided during the negotiation:• Encryption algorithm• Hash algorithmTABLE 4-1 displays the number of methods for encryption and integrity supported byVPN-1 Pro:TABLE 4-1Methods of Encryption/integrity for IKEParameter IKE Phase I (IKE SA) IKE Phase II (IPSec SA)EncryptionIntegrityAES -256(default)3DESDESCASTMD5 (default)SHA1AES -128 (default)AES - 256DESCASTDES - 40CPCAST -40NULLMD5 (default)SHA1NULL means perform an integrity check only; packets are not encrypted.Diffie Hellman GroupsThe Diffie-Hellman key computation (also known as exponential key agreement) isbased on the Diffie Hellman (DH) mathematical groups. TABLE 4-2 shows the DHgroups supported by VPN-1 Pro during the two phases of IKE:TABLE 4-2DH groupsParameter IKE Phase I (IKE SA) IKE Phase II (IPSec SA)Diffie Hellman GroupsGroup2 (1024 bits) (default)Group1 (768 bits)Group5 (1536 bits)Group2 (1024 bits) (default)Group1 (768 bits)Group5 (1536 bits)A group with more bits ensures a key that is harder to break, but carries a heavy cost interms of performance, since the computation requires more CPU cycles.Phase I modesVPN-1 supplies two modes for IKE phase I between Gateways:• Main ModeChapter 4 Understanding and Customizing IKE 61

Check Point Solution for Advanced IKE Configuration• Aggressive ModeIf aggressive mode is not selected, VPN-1 defaults to main mode, performing the IKEnegotiation using six packets; aggressive mode performs the IKE negotiation with threepackets.Main mode is preferred because:• Main mode is partially encrypted, from the point at which the shared DH key isknown to both peers.• Main mode is less susceptible to Denial of Service (DoS) attacks. In main mode, theDH computation is performed after authentication. In aggressive mode, the DHcomputation is performed parallel to authentication. A peer that is not yetauthenticated can force processor intensive Diffie-Hellman computations on theother peer. For more information on IKE DoS attacks, see: “IKE DOSProtection””Note - Aggressive mode is provided for backwards compatibility with pre-NG remote accessclients. Also use aggressive mode when a VPN-1 Pro Gateway needs to negotiate with thirdparty VPN solutions that do not support main mode.When dealing with remote access, IKE has additional modes:• Hybrid mode. Hybrid mode provides an alternative to IKE phase I, where theGateway is allowed to authenticate using certificates and the client via some othermeans, such as SecurID. For more information on Hybrid mode, see: “VPN forRemote Clients””.• Office mode. Office mode is an extension to the IKE protocol. Office Mode is usedto resolve routing issues between remote access clients and the VPN domain.During the IKE negotiation, a special mode called config mode is inserted betweenphases I and II. During config mode, the remote access client requests an IP addressfrom the Gateway. After the Gateway assigns the IP address, the client creates avirtual adapter in the Operating System. The virtual adapter uses the assigned IPaddress. For further information, see: “Office Mode””.Renegotiating IKE & IPSec LifetimesIKE phase I is more processor intensive than IKE phase II, since the Diffie-Hellmankeys have to be produced and the peers authenticated each time. For this reason, IKEphase I is performed less frequently. However, the IKE SA is only valid for a certainperiod, after which the IKE SA must be renegotiated. The IPSec SA is valid for an evenshorter period, meaning many IKE phase II’s take place.62

Perfect Forward SecrecyThe period between each renegotiation is known as the lifetime. Generally, the shorterthe lifetime, the more secure the IPSec tunnel (at the cost of more processor intensiveIKE negotiations). With longer lifetimes, future VPN connections can be set up morequickly. By default, IKE phase I occurs once a day; IKE phase II occurs every hour. Butthe time-out for each phase is configurable.The IPSec lifetime can also be configured according to Kilo Bytes by using dbedit toedit the objects_5_0.c file. The relevant properties are under the community set:• ike_p2_use_rekey_kbytes. Change from false (default) to true.• ike_p2_rekey_kbytes. Modify to include the required rekeying value (default 50000).Perfect Forward SecrecyThe keys created by peers during IKE phase II and used for IPsec are based on asequence of random binary digits exchanged between peers, and on the DH keycomputed during IKE phase I.The DH key is computed once, then used a number of times during IKE phase II.Since the keys used during IKE phase II are based on the DH key computed duringIKE phase I, there exists a mathematical relationship between them. For this reason, theuse of a single DH key may weaken the strength of subsequent keys. If one key iscompromised, subsequent keys can be compromised with less effort.In cryptography, Perfect Forward Secrecy (PFS) refers to the condition in which thecompromise of a current session key or long-term private key does not cause thecompromise of earlier or subsequent keys. VPN-1 Pro meets this requirement with aPFS mode. When PFS is enabled, a fresh DH key is generated during IKE phase II, andrenewed for each key exchange.However, because a new DH key is generated during each IKE phase I, no dependencyexists between these keys and those produced in subsequent IKE Phase I negotiations.Enable PFS in IKE phase II only in situations where extreme security is required.The DH group used during PFS mode is configurable between groups 1, 2, and 5, withgroup 2 (1042 bits) being the default.Note - PFS mode is supported only between Gateways, not between Gateways and remoteaccess clients.Chapter 4 Understanding and Customizing IKE 63

Check Point Solution for Advanced IKE ConfigurationIP CompressionIP compression is a process that reduces the size of the data portion of the TCP/IPpacket. Such a reduction can cause significant improvement in performance. IPsecsupports the Flate/Deflate IP compression algorithm. Deflate is a smart algorithm thatadapts the way it compresses data to the actual data itself. Whether to use IPcompression is decided during IKE phase II. IP compression is not enabled by default.IP compression is important for SecuRemote/SecureClient users with slow links, forexample dialup. Dialup modems do compression as a way of speeding up the link. VPNencryption makes TCP/IP packets look “mixed up”. This kind of data cannot becompressed. Bandwidth is lost as a result. If IP compression is enabled, packets arecompressed before encryption. This has the effect of recovering the lost bandwidth.Subnets and Security AssociationsBy default, a VPN tunnel is never created just for the hosts machines involved in thecommunication, but for the complete subnets the hosts reside on.FIGURE 4-3VPN per subnetIn FIGURE 4-3, a Gateway protects a network consisting of two subnets (10.10.10.x,and 10.10.11.x, with netmask 255.255.255.0 for both). A second Gateway, the remoteVPN peer, protects subnets 10.10.12.x and 10.10.13.x, with netmask 255.255.255.0.Because a VPN tunnel is created by default for complete subnets, four SA’s existbetween the Gateway and the peer Gateway. When Host A communicates with Host B,an SA is created between Host A’s subnet and Host B’s subnet.64

Subnets and Security AssociationsUnique SA Per Pair of PeersBy disabling the Support Key exchange for subnets option on each Gateway, it ispossible to create a unique Security Association per pair of peers.FIGURE 4-4SA per IP addressIn FIGURE 4-4, if the Gateway is configured to Support key exchange for subnets andthe option remains unsupported on the remote VPN peer, when host A communicateswith host C, a Security Association (SA 1) will be negotiated between host A’s subnetand host C’s IP address. The same SA is then used between any host on the 10.10.11.xsubnet and Host C.When host A communicates with host B, a separate Security Association (SA 2) isnegotiated between host A’s subnet and host B. As before, the same SA is then usedbetween any host in 10.10.11.x subnet and Host B.Chapter 4 Understanding and Customizing IKE 65

Configuring Advanced IKE PropertiesFIGURE 4-5SA per hostIn other words, when Support Key exchange for subnets is not enabled oncommunicating Gateways, then a security association is negotiated between individualIP addresses; in effect, a unique SA per host.Configuring Advanced IKE PropertiesIKE is configured in two places:• On the VPN community network object (for IKE properties).• On the Gateway network object (for subnet key exchange).On the VPN Community Network Object1 VPN Properties page, select:• Encryption methods for IKE phase I and II• Integrity methods for IKE phase I and II2 On the Advanced Properties page, select:• Which Diffie-Hellman group to use.• When to renegotiate the IKE Security Associations.• Whether to use aggressive mode (Main mode is the default).• Whether to use Perfect Forward Secrecy, and with which Diffie-Hellman group.• When to renegotiate the IPSec security associations.• Whether to support Site to Site IP compression.66

On the Gateway network objectOn the Gateway network objectOn the VPN Advanced page, deselect Support Key exchange for subnets if you want theSA to be calculated per host. The default is to support key exchange for subnets.Chapter 4 Understanding and Customizing IKE 67

Configuring Advanced IKE Properties68

CHAPTER 5VPN-1 AdvancedConfigurationIn This ChapterConfiguring a VPN with External Gateways Using PKI page 69Configuring a VPN with External Gateways Using a Pre-Shared Secret page 72How to Authorize FireWall-1 Control Connections in VPN Communities page 75How to Convert a Traditional Policy to a Community Based Policy page 76IKE DOS Protection page 85Configuring a VPN with External Gateways Using PKIConfiguring a VPN with external gateways (those managed by a different SmartCenterServer) is more complicated than configuring a VPN with internal Gateways (managedby the same SmartCenter Server). This is because:• Configuration is done separately in two distinct systems.• All details must be agreed and coordinated between the administrators. Details suchas the IP address or the VPN domain topology cannot be detected automaticallybut have to be supplied manually by the administrator of the peer VPN Gateways.• The gateways are likely to be using different Certificate Authorities (CAs). Even ifthe peer VPN Gateways use the Internal CA (ICA), it is still a different CA.There are various scenarios when dealing with externally managed gateways. Thefollowing description tries to address typical cases but assumes that the peers work withcertificates. If this is not the case refer to “Configuring a VPN with External GatewaysUsing a Pre-Shared Secret” on page 72.69

Configuring a VPN with External Gateways Using PKINote - Configuring a VPN using PKI and certificates is considered more secure than usingpre-shared secrets.Although an administrator may choose which community type to use, the StarCommunity is more natural for a VPN with externally managed gateways. The Internalgateways will be defined as the central gateways while the external ones will be definedas the satellites. The decision whether to mesh the central, internal Gateways or notdepends on the requirements of the organization. The diagram below shows this typicaltopology.Note that this is the Topology from the point of view of the administrator of GatewaysA1 and A2. The Administrator of Gateways B1 and B2 may well also define a StarTopology, but with B1 and B2 as his central Gateways, and A1 and A2 as satellites.FIGURE 5-1External Gateways as Satellites in a Star VPN CommunityThe configuration instructions require an understanding of how to build a VPN. Thedetails can be found in: “Building a VPN Between Gateways”.”You also need to understand how to configure PKI. See “Using PKI Solutions” onpage 39.To configure a VPN using certificates, with the external Gateways as satellites in a starVPN Community, proceed as follows:70

1 Obtain the certificate of the CA that issued the certificate for the peer VPNGateways, from the peer administrator. If the peer gateway is using the ICA, youcan obtain the CA certificate using a web browser from:http://:182642 In SmartDashboard, define the CA object for the CA that issued the certificate forthe peer. See “Trusting a CA – Step-By-Step” on page 47.3 Define the CA that will issue certificates for your side if the Certificate issued byICA is not appropriate for the required VPN tunnel.You may have to export the CA certificate and supply it to the peer administrator.1 Define the Network Object(s) of the Gateway(s) that are internally managed. Inparticular, be sure to do the following:• In the General Properties page of the Gateway object, select VPN-1 Pro or VPN-1Net.• In the Topology page, define the Topology, and the VPN Domain. If the VPNDomain does not contain all the IP addresses behind the gateway, define theVPN domain manually by defining a group or network of machines and settingthem as the VPN Domain.2 If the ICA certificate is not appropriate for this VPN tunnel, then in the VPN page,generate a certificate from the relevant CA (see “Enrollment – Step-By-Step” onpage 49).3 Define the Network Object(s) of the externally managed gateway(s).• If it is not a Check Point Gateway, define an Interoperable Device object from:Manage > Network Objects... > New... > Interoperable Device...• If it is a Check Point Gateway, In the Network Objects tree, right click and selectNew > Check Point > Externally Managed Gateway....4 Set the various attributes of the peer gateway. In particular, be sure to do thefollowing:• In the General Properties page of the Gateway object, select VPN-1 Pro or VPN-1Net (for an Externally Managed Check Point Gateway object only).• in the Topology page, define the Topology and the VPN Domain using the VPNDomain information obtained from the peer administrator. If the VPN Domaindoes not contain all the IP addresses behind the gateway, define the VPNdomain manually by defining a group or network of machines and setting themas the VPN Domain.Chapter 5 VPN-1 Advanced Configuration 71

Configuring a VPN with External Gateways Using a Pre-Shared Secret• In the VPN page, define the Matching Criteria. specify that the peer must presenta certificate signed by its own CA. If feasible, enforce details that appear in thecertificate as well.5 Define the Community. The following details assume that a Star Community waschosen, but a Mesh Community is an option as well. If working with a Meshcommunity ignore the difference between the Central Gateways and the SatelliteGateways.• Agree with the peer administrator about the various IKE properties and set themin the VPN Properties page and the Advanced Properties page of the communityobject.• Define the Central Gateways. These will usually be the internally managed ones.If there is no another Community defined for them, decide whether or not tomesh the central gateways. If they are already in a Community, do not mesh thecentral Gateways.• Define the Satellite Gateways. These will usually be the external ones.6 Define the relevant access rules in the Security Policy. Add the Community in theVPN column, the services in the Service column, the desired Action, and theappropriate Track option.7 Install the Security Policy.Configuring a VPN with External Gateways Using aPre-Shared SecretConfiguring a VPN with external gateways (those managed by a different SmartCenterServer) is more complicated than configuring a VPN with internal Gateways (managedby the same SmartCenter Server). This is because:• Configuration is done separately in two distinct systems.• All details must be agreed and coordinated between the administrators. Details suchas the IP address or the VPN domain topology cannot be detected automaticallybut have to be supplied manually by the administrator of the peer VPN Gateways.There are various scenarios when dealing with externally managed gateways. Thefollowing description tries to address typical cases but assumes that the peers work withpre-shared secrets. If this is not the case refer to “Configuring a VPN with ExternalGateways Using PKI” on page 69.Note - Configuring a VPN using PKI and certificates is considered more secure than usingpre-shared secrets.72

Although an administrator may choose which community type to use, the StarCommunity is more natural for a VPN with externally managed gateways. The Internalgateways will be defined as the central gateways while the external ones will be definedas the satellites. The decision whether to mesh the central, internal Gateways or notdepends on the requirements of the organization. The diagram below shows this typicaltopology.Note that this is the Topology from the point of view of the administrator of GatewaysA1 and A2. The Administrator of Gateways B1 and B2 may well also define a StarTopology, but with B1 and B2 as his central Gateways, and A1 and A2 as satellites.FIGURE 5-2External Gateways as Satellites in a Star VPN CommunityThe configuration instructions require an understanding of how to build a VPN. Thedetails can be found in: “Building a VPN Between Gateways”.”To configure a VPN using pre-shared secrets, with the external Gateways as satellites ina star VPN Community, proceed as follows:1 Define the Network Object(s) of the Gateway(s) that are internally managed. Inparticular, be sure to do the following:• In the General Properties page of the Gateway object, select VPN-1 Pro or VPN-1Net.• In the Topology page, define the Topology, and the VPN Domain. If the VPNDomain does not contain all the IP addresses behind the gateway, define theVPN domain manually by defining a group or network of machines and settingthem as the VPN Domain.Chapter 5 VPN-1 Advanced Configuration 73

Configuring a VPN with External Gateways Using a Pre-Shared Secret2 Define the Network Object(s) of the externally managed gateway(s).• If it is not a Check Point Gateway, define an Interoperable Device object from:Manage > Network Objects... > New... > Interoperable Device...• If it is a Check Point Gateway, In the Network Objects tree, right click and selectNew > Check Point > Externally Managed Gateway....3 Set the various attributes of the peer gateway. In particular, be sure to do thefollowing:• In the General Properties page of the Gateway object, select VPN-1 Pro or VPN-1Net (for an Externally Managed Check Point Gateway object only).• in the Topology page, define the Topology and the VPN Domain using the VPNDomain information obtained from the peer administrator. If the VPN Domaindoes not contain all the IP addresses behind the gateway, define the VPNdomain manually by defining a group or network of machines and setting themas the VPN Domain.4 Define the Community. The following details assume that a Star Community waschosen, but a Mesh Community is an option as well. If working with a Meshcommunity ignore the difference between the Central Gateways and the SatelliteGateways.• Agree with the peer administrator about the various IKE properties and set themin the VPN Properties page and the Advanced Properties page of the communityobject.• Define the Central Gateways. These will usually be the internally managed ones.If there is no another Community defined for them, decide whether or not tomesh the central gateways. If they are already in a Community, do not mesh thecentral Gateways.• Define the Satellite Gateways. These will usually be the external ones.5 Agree on a pre-shared secret with the administrator of the external Communitymembers. Then, in the Shared Secret page of the community, select Use OnlyShared Secret for all External Members. For each external peer, enter the pre-sharedsecret.6 Define the relevant access rules in the Security Policy. Add the Community in theVPN column, the services in the Service column, the desired Action, and theappropriate Track option.7 Install the Security Policy.74

Why turning off FireWall-1 Implied Rules Blocks Control ConnectionsHow to Authorize FireWall-1 Control Connections in VPNCommunitiesCheck Point Nodes communicate with other Check Point Nodes by means of controlconnections. For example, a control connection is used when the Security Policy isinstalled from the SmartCenter Server to FireWall-1 Gateways. Also, logs are sent fromVPN-1 Pro Gateways to the SmartCenter Server across control connections. Controlconnections use Secure Internal Communication (SIC).Control connections are allowed using Implied Rules in the Security Rule Base.Implied Rules are added to or removed from the Security Rule Base, by checking orunchecking options in the FireWall-1 Implied Rules page of the SmartDashboard GlobalProperties.Some administrators prefer not to rely on implied rules, and instead prefer to defineexplicit rules in the Security Rule Base.Why turning off FireWall-1 Implied Rules Blocks ControlConnectionsIf you turn off implicit rules, you may not be able to install a Policy on a Remote VPNGateway. Even if you define explicit rules in place of the implied rules, you may stillnot be able to install the policy. FIGURE 5-3 and the following explanation illustratethe problem.FIGURE 5-3Turning off control connections can cause Policy installation to failThe administrator wishes to configure a VPN between Gateways A and B byconfiguring SmartDashboard. To do this, the administrator must install a Policy fromthe SmartCenter Server to the Gateways.1 The SmartCenter successfully install the Policy on Gateway A. As far as Gateway Ais concerned, Gateways A and B now belong to the same VPN Community.However, B does not yet have this Policy.2 The SmartCenter Server tries to open a connection to Gateway B in order to installthe Policy.Chapter 5 VPN-1 Advanced Configuration 75

How to Convert a Traditional Policy to a Community Based Policy3 Gateway A allows the connection because of the explicit rules allowing the controlconnections, and starts IKE negotiation with Gateway B to build a VPN tunnel forthe control connection.4 Gateway B does not know how to negotiate with A because it does not yet havethe Policy. Therefore Policy installation on Gateway B fails.The solution for this is to make sure that control connections do not have to passthrough a VPN tunnel.How to allow FireWall-1 control connections inside a VPNIf you turn off implied rules, you must make sure that control connections are notchanged by the VPN-1 Pro Gateways. To do this, add the services that are used forcontrol connections to the Excluded Services page of the Community object.Note - Even though control connections between the SmartCenter Server and the Gatewayare not encrypted by the community, they are nevertheless encrypted and authenticatedusing Secure Internal Communication (SIC).How to find out which services are used for ControlConnections1 In the main menu, select View > Implied Rules.2 In the Global Properties FireWall-1 Implied Rules page, select Accept VPN-1 &FireWall-1 control Connections.3 Examine the Security Rule Base to see what Implied Rules are visible. Note theservices used in the Implied Rules.How to Convert a Traditional Policy to a CommunityBased PolicyIn This SectionIntroduction to Converting to Simplified VPN Mode page 77How Traditional VPN Mode Differs from a Simplified VPN Mode page 77How an Encrypt Rule Works in Traditional Mode page 78Principles of the Conversion to Simplified Mode page 80Placing the Gateways into the Communities page 80Conversion of Encrypt Rule page 8176

Introduction to Converting to Simplified VPN ModeWhen the Converted Rule Base is too Restrictive page 81Conversion of Client Encrypt Rules page 82Conversion of Auth+Encrypt Rules page 83How the Converter Handles Disabled Rules page 83After Running the Wizard page 84Introduction to Converting to Simplified VPN ModeBuilding VPNs using Simplified Mode has many benefits. Simplified Mode makes itpossible to maintain and create simpler, and therefore less error prone and more secureVPNs.Simplified Mode separates the VPN definitions from the Access Control SecurityPolicy. This makes it easier to understand the VPN topology of an organization, and tounderstand who is allowed to securely communicate with who. In addition, new VPNfeatures, such as VPN routing or VPN-1 Net modules are supported only with aSimplified Mode Security Policy.In order to manage all existing policies in a unified way and utilize the latest features ofVPN-1, it is recommended to convert Traditional Mode Security Policies to SimplifiedMode. For new policies, it is recommended to use Simplified Mode, which is thedefault for new versions of VPN-1.A VPN policy configured in Traditional Mode can be converted to the Simplified VPNMode using the Security Policy Converter Wizard.After using the converter wizard, it is possible to greatly simplify many VPN policies bymoving rules and grouping rules together.The process is simple, and both automatic and manual changes are explained here indetail. The intention is to give you the confidence to move your Traditional VPNPolicies to the Simplified VPN Mode.To start the converter wizard, save the Policy, and from the SmartDashboard mainmenu, select Policy > Convert to > Simplified VPN…How Traditional VPN Mode Differs from a Simplified VPNModeA Traditional Mode Security Policy differs from a Simplified Mode Policy in thefollowing ways:In Traditional VPN Mode, a single rule, with the Encrypt rule action, deals with bothaccess control and encryption. VPN properties are defined per Gateway.Chapter 5 VPN-1 Advanced Configuration 77

How to Convert a Traditional Policy to a Community Based PolicyIn Simplified VPN Mode, the Security Rule Base deals only with access control. Inother words, the Rule Base determines only what is allowed. VPN properties, on theother hand, are dealt with per VPN community.VPN communities are groups of gateways. The community defines the encryptionmethods for the VPN. All communication between community members is encrypted,and all other communication is not encrypted.Simplified VPN Mode and communities are described in Chapter 2, “Building a VPNBetween Gateways.The simplified VPN policy makes it easier for the administrator to configure a VPN.However, Traditional policies allow VPNs to be created with greater granularity thanSimplified policies, because• Whether or not to encrypt can be defined per rule (source, destination and service)• Simplified policies requires all the connections between two gateways to encryptedusing the same methods, using the Community definitions.What this means is that after running the wizard, some manual optimization of theRule Base may be required.Note - The terms “VPN Domain” and “Encryption Domain” mean the same thing. Usually,“VPN Domain” is used in the context of Simplified policies, and “Encryption Domain” forTraditional policies.How an Encrypt Rule Works in Traditional ModeWhen a Traditional policy is converted to a Simplified policy, an Encrypt rule isconverted to rules that use communities. In order to understand the conversion, it isimportant to understand how an Encrypt rule works.FIGURE 5-4 will be used to understand the conversion, and the limitations of theconversion process. It shows a VPN between Gateways, and the Encryption Domain ofeach Gateway. Net_A and Net_B are the encryption Domain of Gateway 1, and Net_Dis the encryption Domain of Gateway 2.78

How an Encrypt Rule Works in Traditional ModeFIGURE 5-4A VPN between Gateways, and the Encryption (VPN) Domain of each GatewayTABLE 5-1 shows how the VPN is implemented in an Encrypt rule.TABLE 5-1Sample Encrypt rule in a Traditional Rule BaseSource Destination Service Action Track Install OnX Y My_Services Encrypt Log Policy TargetsA connection that matches an Encrypt rule is encrypted (or decrypted) and forwarded bythe Gateways enforcing the policy. There are two exceptions:1 If the source or the destination are behind the VPN-1 Pro Gateway, but are not inthe VPN Domain of the gateway, the connection is dropped.For example, referring to FIGURE 5-4 and TABLE 5-1, if Source X is in Net_Cand Destination Y is in Net_D, Gateway 1 drops the connection. This is becausethe Action says Encrypt but the connection cannot be encrypted because the sourceis not in the Encryption Domain of Gateway 1.2 If the source and destination are inside the encryption Domain of the sameGateway. In this case, the connection is accepted in the clear.Chapter 5 VPN-1 Advanced Configuration 79

How to Convert a Traditional Policy to a Community Based PolicyFor example, referring to FIGURE 5-4 and TABLE 5-1, if Source X is in Net_Aand Destination Y is in Net_B, the connection originates at X and reaches thegateway, which forwards the response back to Y. The connection is not encryptedbecause there is no peer gateway for Y that could decrypt the connection. ASmartView Tracker log is issued “Both endpoint are in the EncryptionDomain”.Principles of the Conversion to Simplified ModeThe converter Wizard attempts to maintain the best possible balance betweenconnectivity and security, by using the following principles:• Refuse all traffic that could have been refused in traditional Mode. This may meanthat some connections may be dropped that were allowed by the traditional rulebase.• Encrypt at least all traffic that would be encrypted in traditional policy. This meansthat the converted policy may encrypt more connections than the original policy.What this means is that not all traditional policies can be converted in a way thatexactly preserves the policy that is specified in the Security Rule Base. The convertedrule(s) in the Simplified VPN can under certain circumstances behave somewhatdifferently than the encryption rule for Traditional VPNs (described in “How anEncrypt Rule Works in Traditional Mode” on page 78).Running the converter is a simple two or three step process. After running the wizard,you should review the Security Rule Base to make sure that it has maintained itsrequired functionality, and optimize it if needed.Placing the Gateways into the CommunitiesThe first step in converting a traditional VPN to a simplified VPN is to create VPNcommunities that describe the topology of the organization. The conversion wizardrequires the administrator to place Gateways into communities. It cannot do thisautomatically because it is very difficult to deduce from the traditional policy whatcommunities should be defined between Gateways.The wizard allows you define communities, and to drag-and-drop Gateways into thecommunities. Referring to FIGURE 5-4, the administrator must make Gateway 1 andGateway 2 members of the same community by dragging both the Gateway objects intothe same site-to-site community object.You may prefer to create several communities with different encryption properties toreflect the way that the traditional VPN policy works.80

Conversion of Encrypt RuleIf no communities have been previously defined, there are by default two predefined,empty community objects. One is a site-to-site VPN “intranet” community (a Meshcommunity), and the other is a remote access community. If these are the only twoCommunities, the wizard gives you the choice of simply placing all Gateways into theSite-to-Site Community, and placing all Remote Access Gateways into the RemoteAccess Community.Conversion of Encrypt RuleAfter Gateways have been placed into Communities, the Encrypt rules are converted.The converted rule base preserve the behavior of the Encrypt rule in Simplified VPNMode to the greatest extent possible.Encrypt rules are converted by the Conversion wizard to two rules:TABLE 5-2A converted rule in a simplified Rule BaseSrc. Dest. VPN Service Action Track Install OnX Y All_GW_to_GW My_Services Accept Log PolicyTargetsX Y Any My_Services Drop Log PolicyTargetsThe first rule says that the connection is matched and is allowed, if the connectionoriginates at X and its destination is Y, within any Site-to-Site Community.The second rule says that if a connection originates at X and has the destination Y, butis not encrypted (or decrypted) by any site-to-site community, the connection shouldbe dropped.The second rule (the Drop rule) is needed where either the source or the destinationare not in the VPN Domain. In the Traditional policy, the Encrypt rule would dropthis connection. If there were no drop rule in the Simplified policy, the connection maybe matched to and allowed by a rule further down in the Rule Base.When the Converted Rule Base is too RestrictiveThis translation of Encrypt rules into two Simplified Mode rule is at least as restrictiveas the original rule. However, in the converted Rule Base shown in TABLE 5-2, someconnections that were matched to and allowed by the original rule (TABLE 5-1) maybe dropped. This may happen with connections between two hosts in the encryptiondomain of the same gateway. For example, referring to FIGURE 5-4, connections fromChapter 5 VPN-1 Advanced Configuration 81

How to Convert a Traditional Policy to a Community Based Policya node in Net_A to a Node in Net_B will be dropped by the converted Rule Base.This is because community rules define traffic between VPN Domains, and do notrelate to traffic within a VPN Domain.To allow these connections in the converted rule-base, you must explicitly allow them.To do this, add one rule between the first rule and the second rule, for each policytarget appearing in the “install on” field. For example, the two Rules in TABLE 5-2become three rules, as in TABLE 5-3.TABLE 5-3Manually Added Rule in the converted Encrypt Rule BaseSrc. Dest. VPN Service Action Track Install OnX Y All_GW_to_GW My_Services Accept Log PolicyTargetsNet_A Net_B Any My_Services Accept Log Gateway 1X Y Any My_Services Drop Log PolicyTargetsIn most cases it is not necessary to add these rules. Only add them when connectionsinside the encryption domain are matched by the Encrypt rule. An indication of this isthe appearance of the log in SmartView Tracker "Both endpoint are in theEncryption Domain".Conversion of Client Encrypt RulesEach Client Encrypt rule translates to a single rule that preserves the behavior of theclient Encrypt rule. For example, the Traditional Mode rule in TABLE 5-4 allowsRemote Access users to access Net_D.TABLE 5-4Remote Access Rule in Traditional ModeSource Destination Service Action TrackAll_Users@alaska Net_D My_Services Client Encrypt LogThe translated rule is shown in TABLE 5-5. The Remote Access community is put inthe VPN field, and the Action of the rule is Accept:TABLE 5-5Translated Remote Access Rule in Simplified ModeSource Dest. VPN Service Action TrackAll_Users@alaska Net_D Remote Access My_Services Accept LogCommunity82

Conversion of Auth+Encrypt RulesConversion of Auth+Encrypt RulesIn a Traditional Mode policy, Auth+Encrypt Rules are rules with User, Client orSession Authentication, together with Add Encryption selected in the Action of theRule.For Auth+Encrypt rules, as shown in TABLE 5-6 with Client Authentication, theSource specifies both a restriction on the source location, and also the authorized users.Any connection matching the rule must be authenticated and encrypted. If encryptionis not possible, the connection is dropped.TABLE 5-6Auth+Encrypt Rule in Traditional ModeSource Destination Service Action TrackAll_Users@alaska Net_D My_Services Client_Auth LogSince the identification of users is possible only in authentication rules, and not in droprules, it is not possible to define a rule that drops connections that were not encrypted.Because of this, Auth+Encrypt rules cannot be automatically translated in such a waythat the translated Rule Base is at least as restrictive as the original rule. Instead, theConverter wizard translates Auth+Encrypt rules to a single rule, and does not add aDrop rule, as shown in TABLE 5-7. This is a security problem, because connectionsthat match the Source location, where the users authenticated successfully, but were notencrypted, may be accepted further down in the translated Rule Base if some later rulespecifies Accept for the same Source.TABLE 5-7Insecure Translated Auth+Encrypt Rule in Simplified ModeSource Dest. VPN Service Action TrackAll_Users@alaska Net_D All_GwToGw My_Services Client Auth LogWhen the converter encounters Auth+Encrypt rules, it warns the administrator bydisplaying an error stating that the converter cannot translate such rules automatically.In this case it is important to review the translated rule base before installing it, in orderto avoid security breaches. It may be necessary to add rules to make sure that all thetraffic that was previously dropped by the original Rule Base is dropped in thetranslated Rule Base.How the Converter Handles Disabled RulesIf a rule in the Traditional VPN Rule Base was disabled, the translated rule in thesimplified Rule Base will also be disabled.Chapter 5 VPN-1 Advanced Configuration 83

How to Convert a Traditional Policy to a Community Based PolicyAfter Running the WizardAfter running the Wizard, examine the Rule Base to see that it has retained the desiredfunctionality, and if necessary, optimize the Rule Base, and make other changes, asfollows. These points have been covered in the earlier discussion, but are summarizedhere for convenience:Take out unneeded Drop rulesIn some cases you can delete the second Drop rule generated by the conversion of anEncrypt rule because it will never match any connection, and the first rule is sufficient.This is the case for rules where the following are true:• The source and destination are located in the encryption domain of gatewaysappearing in the “Installed on” column of the rule.• A Community links all gateways protecting addresses in the Source and also linksgateways protecting addresses in the Destination.Another case where you can delete the second Drop rule generated by the conversionof an Encrypt rule is where connections that do not match the first rule are dropped byrules that appear later in the Rule Base. Sometimes you can group several Drop rulesgenerated by the conversion of several Encrypt rules into a single Drop rule.Add Rules Allowing Communication Inside the VPN DomainConnections matching Encrypt rules where both endpoints are located inside theencryption domain of the same gateway, are accepted in a Traditional Rule Base. Toachieve the same effect in the simplified VPN rule base, you must manually add rulesthat accept the traffic inside the encryption domains of the gateways. In most cases it isnot necessary to add these rules. Add them if you see the SmartView Tracker logmessage: “Both endpoint are in the Encryption Domain”.Auth+Encrypt RulesAuth+Encrypt rules are not converted automatically. When such rules appear in theRule Base, review the converted Rule Base and make sure that the security of theserules are maintained.Add Services to the “Excluded Services” ListAdd the Services that should not be encrypted inside the Community to the ExcludedServices list. For example, if you have explicitly defined implied rules in the TraditionalPolicy. See “How to Authorize FireWall-1 Control Connections in VPNCommunities” on page 75.84

Understanding DoS AttacksIKE DOS ProtectionIn This SectionUnderstanding DoS Attacks page 85IKE DoS Attacks page 85Defense Against IKE DoS Attacks page 86SmartDashboard IKE Dos Attack Protection Settings page 87Advanced IKE Dos Attack Protection Settings page 87Understanding DoS AttacksDenial of Service (DoS) attacks are intended to reduce performance, block legitimateusers from using a service, or even bring down a service. They are not direct securitythreats in the sense that no confidential data is exposed, and no user gains unauthorizedprivileges. However, they consume computer resources such as memory or CPU.Generally, there are two kinds of DoS attack. One kind consists of sending malformed(garbage) packets in the hope of exploiting a bug and crashing the service. In the otherkind of DoS attack, an attacker attempts to exploit a vulnerability of the service orprotocol by sending well-formed packets. IKE DoS attack protection deals with thesecond kind of attack.IKE DoS AttacksThe IKE protocol requires that the receiving Gateway allocates memory for the firstIKE Phase 1 request packet that it receives. The Gateway replies, and receives anotherpacket, which it then processes using the information gathered from the first packet.An attacker can send many IKE first packets, while forging a different source IP addressfor each. The receiving Gateway is obliged to reply to each, and assign memory foreach. This can consume all CPU resources, thereby preventing connections fromlegitimate users.The attacker sending IKE packets can pretend to a machine that is allowed to initiateIKE negotiations, such as a VPN Gateway. This is known as an identified source. Theattacker can also pretend to have an IP address that the receiving Gateway does notknow about, such as a SecuRemote/SecureClient, or a VPN Gateway with a dynamicIP address. This is known as an unidentified source.Chapter 5 VPN-1 Advanced Configuration 85

IKE DOS ProtectionDefense Against IKE DoS AttacksWhen the number of IKE negotiations handled simultaneously exceeds a thresholdabove the capacity of VPN-1, it concludes that it is either under load or experiencing aDenial of Service attack. In such a case VPN-1 can filter out peers that are the probablesource of a potential Denial of Service attack. There are two kinds of protection:Stateless Protection Against IKE DoS AttacksVPN-1 prevents IKE DoS Attacks by delaying allocation of Gateway resources until thepeer proves itself to be legitimate. The following process is called stateless protection:1 If the Gateway concludes that it is either under load or experiencing a Denial ofService attack, and it receives an IKE request, it replies to the alleged source with apacket that contains a number that only the Gateway can generate. The Gatewaythen “forgets” about the IKE request. In other words, it does not need to store theIKE request in its memory (which is why the protection is called “Stateless”).2 The machine that receives the packet is required to reinitiate the IKE request bysending an IKE request that includes this number.3 If the Gateway receives an IKE request that contains this number, the Gateway willrecognize the number as being one that only it can generate, and will only thencontinue with the IKE negotiation, despite being under load.If the VPN Gateway receives IKE requests from many IP addresses, each address is senta different unique number, and each address is required to reinitiate the IKE negotiationwith a packet that includes that number. If the peer does not reside at these IPaddresses, this unique number will never reach the peer. This will thwart an attackerwho is pretending to send IKE requests from many IP addresses.IKE DoS attack protection is not available for third party Gateways. Under heavy load,third party gateways and clients (such as Microsoft IPSec/L2TP clients) may be unableto connect.Using Puzzles to Protect Against IKE DoS AttacksStateless protection is appropriate where the IKE packet appears to come from anidentified source, that is, a machine that is allowed to initiate IKE negotiations, such asa VPN Gateway.An unidentified source is an IP address that the receiving Gateway does not recognize,such as a SecuRemote/SecureClient, or a VPN Gateway with a dynamic IP address. Anattacker may well have control of many unidentified IP addresses, and may be able toreply to stateless packets from all these addresses. Therefore, if an attack comes from anunidentified source, another approach is required.86

SmartDashboard IKE Dos Attack Protection SettingsThe Gateway can require that the source of the IKE request solves a computationallyintensive puzzle. Most computers can solve only a very few of these puzzles per second,so that an attacker would only be able to send very few IKE packets per second. Thisrenders a DoS attack ineffective.IKE DoS attack protection is not available for Third party Gateways. Under heavy load,they may be unable to connect.SmartDashboard IKE Dos Attack Protection SettingsTo protect against IKE Dos attacks, edit the SmartDashboard IKE Denial of ServiceProtection settings, in the VPN-1 Pro >Advanced page of the Global Properties.• Support IKE DoS protection from identified source — The default setting foridentified sources is Stateless. If the Gateway is under load, this setting requires thepeer to respond to an IKE notification in a way that proves that the IP address ofthe peer is not spoofed. If the peer cannot prove this, VPN-1 will not begin theIKE negotiation.If the source is identified, protecting using Puzzles is over cautious, and may affectperformance. A third possible setting is None, which means no DoS protection.• Support IKE DoS protection from unidentified source — The default setting forunidentified sources is Puzzles. If the Gateway is under load, this setting requiresthe peer to solve a mathematical puzzle. Solving this puzzle consumes peer CPUresources in a way that makes it difficult to initiate multiple IKE negotiationssimultaneously.For unidentified sources, Stateless protection may not be sufficient because anattacker may well control all the IP addresses from which the IKE requests appear tobe sent. A third possible setting is None, which means no DoS protection.Advanced IKE Dos Attack Protection SettingsAdvanced IKE DoS attack protection can be configured on the SmartCenter Serverusing the dbedit command line or using the graphical Database Tool. Configure theprotection by means of the following Global Properties.ike_dos_thresholdValues: 0-100. Default: 70. Determines the percentage of maximum concurrentongoing negotiations, above which the Gateway will request DoS protection. If thethreshold is set to 0, the Gateway will always request DoS protection.Chapter 5 VPN-1 Advanced Configuration 87

IKE DOS Protectionike_dos_puzzle_level_identified_initiatorValues: 0-32. Default: 19. Determines the level of the puzzles sent to known peerGateways. This attribute also determines the maximum puzzle level a Gateway is willingto solve.ike_dos_puzzle_level_unidentified_initiatorValues: 0-32. Default: 19. Determines the level of the puzzles sent to unknown peers(such as SecuRemote/SecureClients and DAIP Gateways). This attribute alsodetermines the maximum puzzle level that DAIP Gateways andSecuRemote/SecureClients are willing to solve.ike_dos_max_puzzle_time_gwValues: 0-30000. Default: 500. Determines the maximum time in milliseconds aGateway is willing to spend solving a DoS protection puzzle.ike_dos_max_puzzle_time_daipValues: 0-30000. Default: 500. Determines the maximum time in milliseconds a DAIPGateway is willing to spend solving a DoS protection puzzle.ike_dos_max_puzzle_time_srValues: 0-30000. Default: 5000. Determines the maximum time in milliseconds aSecuRemote is willing to spend solving a DoS protection puzzle.ike_dos_supported_protection_srValues: None, Stateless, Puzzles. Default: Puzzles. When downloaded toSecuRemote/SecureClient, it controls the level of protection the client is willing tosupport.Gateways use the ike_dos_protection_unidentified_initiator property (equivalentto the SmartDashboard Global Property: Support IKE DoS Protection from unidentifiedSource) to decide what protection to require from remote clients, butSecuRemote/SecureClient clients use the ike_dos_protection. This same clientproperty is called ike_dos_supported_protection_sr on the Gateway.88

Advanced IKE Dos Attack Protection SettingsClient PropertiesSome gateway properties change name when they are downloaded toSecuRemote/SecureClient. The modified name appears in the Userc.C file, as follows:TABLE 5-8Property Name on Gatewayike_dos_protection_unidentified_initiator(Equivalent to the SmartDashboard GlobalProperty: Support IKE DoS Protection fromunidentified Source)ike_dos_supported_protection_srike_dos_puzzle_level_unidentified_initiatorike_dos_max_puzzle_time_srUserc.C Property Name onSecuRemote/SecureClientike_dos_protection orike_support_dos_protectionike_dos_protectionike_dos_acceptable_puzzle_levelike_dos_max_puzzle_timeChapter 5 VPN-1 Advanced Configuration 89

IKE DOS Protection90

CHAPTER 6Traditional Mode VPNsIn This ChapterIntroduction to Traditional Mode VPNs page 91VPN Domains and Encryption Rules page 91Defining VPN Properties page 93Internally and Externally Managed Gateways page 93Considerations for VPN Creation page 93Configuring Traditional Mode VPNs page 94Introduction to Traditional Mode VPNsSimplified Mode makes it possible to maintain and create simpler, and therefore lesserror prone and more secure VPNs. It also makes it easier to understand the VPNtopology of an organization, and to understand who is allowed to communicate withwho. In addition, new VPN features, such as VPN routing or VPN-1 Net modules aresupported only with a Simplified Mode Security Policy.However, organizations that have large VPN-1 deployments with complex networksmay prefer to maintain existing VPN definitions and continue to work withinTraditional Mode until they are able to migrate their policies to Simplified Mode.For guidelines on how to convert Traditional Mode VPNs to Simplified Mode, see“How to Convert a Traditional Policy to a Community Based Policy” on page 76.VPN Domains and Encryption RulesFIGURE 6-1 shows a VPN between Gateways, and the VPN Domain of each Gateway.Net_A and Net_B are the VPN Domain of Gateway 1, Net_D is the VPN Domain ofGateway 2, and Net_E is the VPN Domain of Gateway 3.91

VPN Domains and Encryption RulesFIGURE 6-1A VPN between Gateways, and the Encryption (VPN) Domain of each GatewayTABLE 6-1 shows how the VPN is implemented in a rule. In Traditional VPN Mode,a single rule with the Encrypt rule action, deals with both access control andencryption.TABLE 6-1An example Encrypt rule in a Traditional Rule BaseSource Destination Service Action Track Install OnNet_ANet_ENet_ANet_EMy_Services Encrypt Log Gateway 1Gateway 3A connection that matches an Encrypt rule is encrypted (or decrypted) and forwarded bythe gateways enforcing the policy.Sometimes, a connection may match the encrypt rule, but will not be encrypted.Consider the following rule:TABLE 6-2An Encrypt rule where encryption does not take placeSource Destination Service Action Track Install OnX Y My_Services Encrypt Log Policy Targets1 If the source or the destination are behind the VPN-1 Pro Gateway, but are not inthe VPN-1 Domain of the gateway, the connection is dropped.92

Choosing the Authentication MethodFor example, referring to FIGURE 6-1 and TABLE 6-2, if Source X is in Net_Cand Destination Y is in Net_D, Gateway 1 drops the connection. This is becausethe Action says Encrypt but the connection cannot be encrypted because the sourceis not in the VPN Domain of Gateway 1.2 If the source and destination are inside the VPN Domain of the same Gateway. Inthis case, the connection is accepted in the clear.For example, referring to FIGURE 6-1 and TABLE 6-2, if Source X is in Net_Aand Destination Y is in Net_B, the connection originates at X and reaches thegateway, which forwards the response back to Y. The connection is not encryptedbecause there is no peer gateway for Y that could decrypt the connection. ASmartView Tracker log is issued “Both endpoints are in the EncryptionDomain”.Defining VPN PropertiesIt is possible to use different encryption methods between the same gateways. Differentconnections between two gateways can be encrypted using different methods. This isbecause different IKE phase 2 properties can be defined per Encrypt rule.IKE Phase 1 properties are defined per gateway.Internally and Externally Managed GatewaysThe gateways at each end of a VPN tunnel can be managed by the same SmartCenterServer or by different SmartCenter Servers. A VPN-1 Pro Gateway that is managed bythe SmartCenter Server is called an internal gateway. If it is managed by a differentSmartCenter Server it is called an external gateway.If the peer VPN-1 Pro Gateway is external, you must obtain certain details about thatGateway from the peer administrator, and configure them in SmartDashboard.Considerations for VPN CreationThere are many ways of setting up a VPN. Before starting, a number of issues need tobe considered, such as:Choosing the Authentication MethodBefore the VPN-1 Pro Gateways can create a VPN tunnel, they need to authenticate toeach other. This authentication is performed either by means of certificates or with apre-shared secret. Certificates are considered to be a stronger form of authentication.Chapter 6 Traditional Mode VPNs 93

Configuring Traditional Mode VPNsChoosing the Certificate AuthorityIf the gateways use certificates, the certificates can be issued either by the InternalCertificate Authority (ICA) on the SmartCenter Server, or by a third party OPSECcertified CA.The Internal CA makes it very easy to use PKI for Check Point applications such assite-to-site and remote access VPNs. However, an administrator may prefer to continueusing a CA that is already used within the organization, for generalized applicationssuch as secure email, and disk encryption.If the gateways are both internally managed and use certificates for authentication, theeasiest strategy is for both gateways to present a certificate signed by the Internal CA.Configuring Traditional Mode VPNsIn This SectionEditing a Traditional Mode Policy page 94Configuring a VPN Between Internal Gateways using ICA Certificates page 95VPN Between Internal Gateways Using Third Party CA Certificates page 95Configuring a VPN with Externally Managed Gateways Using Certificates page 96Configuring a VPN using a Pre-Shared Secret page 98Editing a Traditional Mode PolicyAn existing Traditional Mode policy will open in Traditional Mode. To start a newTraditional Mode policy, proceed as follows.1 In the Global Properties window, VPN-1 Pro page, select either Traditional mode toall new Security Policies or Traditional or Simplified per new Security Policy, and savethe policy.Assuming you selected Traditional or Simplified per new Security Policy:2 From the File menu, select New. The New Policy Package window opens.3 Give the new policy package a name.4 Select Security and Address Translation.5 In the VPN configuration method area, select Traditional mode and click OK.In the Security Policy Rule Base, notice that one of the available Actions is Encrypt.94

Configuring a VPN Between Internal Gateways using ICA CertificatesConfiguring a VPN Between Internal Gateways using ICACertificatesDefining the Gateways1 For each gateway that is to be part of the VPN define a Check Point Gatewayobject. In the Network Objects tree, right click and select New > Check Point >Gateway....2 In the General Properties page of the Check Point Gateway object, select VPN-1 Pro.3 In the Communication window, establish Secure Internal Communication.4 In the Topology page, define the IP address, network mask, and anti-spoofing forevery Gateway interface5 Still on the Topology page, define the VPN Domain. select either:• All IP Addresses behind gateway based on Topology information or• Manually defined. Either select an existing network or group from thedrop-down list or create a new group of machines or networks by clickingNew...6 In the VPN page, Certificate List area, Add a certificate issued by the ICA.7 Still on the VPN page, click Traditional mode configuration. The Traditional modeIKE properties window opens.• In the Support authentication methods area, select Public Key Signatures. Tospecify that the gateway will only use certificates issued by the ICA, click Specifyand select the ICA.• Select IKE Phase 1 encryption and data integrity methods or accept the checkeddefaults.Defining the Encrypt Rule8 In the Security Rule Base, define the Encrypt rule(s).9 If you wish to change the IKE Phase 2 properties for this rule, double click theEncrypt action and make the required changes.VPN Between Internal Gateways Using Third Party CACertificates1 Obtain the CA certificate, and define the Certificate Authority (CA) object. Fordetails, see “Trusting a CA – Step-By-Step” on page 47.Chapter 6 Traditional Mode VPNs 95

Configuring Traditional Mode VPNsDefining the Gateways2 Define the Check Point Gateway object. In the Network Objects tree, right clickand select New> Check Point> Gateway....3 In the General Properties page, select either VPN-1 Pro.4 In the Communication window, establish Secure Internal Communication.5 In the Topology page, define the IP address, network mask, and anti-spoofing forevery gateway interface.6 Still on the Topology page, define the VPN Domain. select either:• All IP Addresses behind gateway based on Topology information or• Manually defined. Either select an existing network or group from thedrop-down list, or create a new network or group by clicking New....7 In the VPN page, Certificate List area, Add a certificate issued by the certificateauthority defined in step 1. For details, see “Enrollment – Step-By-Step” onpage 49.8 Still on the VPN page, click Traditional mode configuration. The Traditional modeIKE properties window opens.• In the Support authentication methods area, select Public Key Signatures. Tospecify that the gateway will only use certificates issued by the CA specified instep 1, click Specify and select the CA.• Select IKE Phase 1 encryption and data integrity methods or accept the checkeddefaults.9 Repeat step 2 to step 8 for each gateway taking part in the VPN.Defining the Encrypt Rule10 In the Security Rule Base, define the Encrypt rule(s).11 If you wish to change the IKE Phase 2 properties for this rule, double click theEncrypt action and make the required changes.Configuring a VPN with Externally Managed Gateways UsingCertificatesObtain Information from the Peer AdministratorObtain the gateway topology and VPN Domain information about the externallymanaged gateways from the peer administrator.96

Configuring a VPN with Externally Managed Gateways Using CertificatesYou must also agree on authentication, encryption and data integrity methods for theVPN.You must also obtain the CA certificate of the peer, either from the peer administratoror directly from the peer CA.Defining the CAs1 Obtain the CA certificate and create the Certificate Authority (CA) object for theinternally managed gateways. For details, see “Trusting a CA – Step-By-Step” onpage 47.2 Define the CA object for the externally managed gateways, and configure it usingthe peer CA certificate.Defining the Internally Managed Gateways3 Create the Check Point Gateway object. In the Network Objects tree, right clickand select New > Check Point > Gateway....4 In the General Properties page, select either VPN-1 Pro.5 In the Communication window, establish Secure Internal Communication.6 In the Topology page, define the IP address, network mask, and anti-spoofing forevery gateway interface.7 Still on the Topology page, define the VPN Domain. select either:• All IP Addresses behind gateway based on Topology information or• Manually defined. Either select an existing network or group from thedrop-down list, or create a new network or group by clicking New....8 In the VPN page, Certificate List area, Add a certificate issued by the certificateauthority defined in step 1. For details, see “Enrollment – Step-By-Step” onpage 49.9 Still on the VPN page, click Traditional mode configuration. The Traditional modeIKE properties window opens.• In the Support authentication methods area, select Public Key Signatures. Tospecify that the gateway will only use certificates issued by the CA specified instep 1, click Specify and select the CA.• Select IKE Phase 1 encryption and data integrity methods or accept the checkeddefaults.10 Repeat step 3 to step 9 for each internally managed gateway.Chapter 6 Traditional Mode VPNs 97

Configuring Traditional Mode VPNsDefining the Externally Managed Gateways11 Create the externally managed gateway object:• If it is a Check Point Gateway, in the Network Objects tree, right click and selectNew > Check Point > Externally Managed Gateway....• If it is not a Check Point Gateway, select Manage > Network Objects.. .> New...>Interoperable Device....12 For an external Check Point Gateway only: In the General Properties page, selecteither VPN-1 Pro or VPN-1 Net.13 Using the topology information supplied by the peer administrator, in the Topologypage, manually define the IP address and network mask for every gateway interface.14 Using the VPN Domain information supplied by the peer administrator, define theVPN domain in the VPN Domain section of the Topology page. Either select All IPAddresses behind gateway based on Topology information or manually define agroup of machines or a network and set them as the VPN domain.15 On the VPN page, click Traditional mode configuration. The Traditional mode IKEproperties window opens.• Select IKE Phase 1 encryption and integrity methods (in coordination with thepeer Gateway’s administrator) or accept the defaults.• In the Support authentication methods area, select Public Key signatures.16 On the VPN page, click Matching Criteria.... The Certificate Matching Criteriawindow opens. The configurations settings in this window force the externallymanaged gateway to present a certificate from a defined CA, and require that thedetails on the certificate match those specified here. This is enforced by theinternally managed gateways during IKE negotiation.Defining the Encrypt Rule17 In the Security Rule Base, define the Encrypt rule(s).18 If you wish to change the IKE Phase 2 properties for this rule, double click theEncrypt action and make the required changes.Configuring a VPN using a Pre-Shared SecretWhen using a pre-shared secret to authenticate gateways, you need to enable eachgateway in the VPN for pre-shared secrets. Then, on each gateway, define a pre-sharedsecret for each of the other gateways. However, for each pair of gateways, you onlyneed to define the pre-shared secrets for the pair on one of the gateways.98

Configuring a VPN using a Pre-Shared SecretFor example, in a VPN with four gateways, A,B, C and D, there will be six secrets:A-B, A-C, A-D, B-C, B-D and C-D.• On A define the secrets for B, C and D.• On B define the secrets for C and D.• On C define the secret for D.The following procedure applies to both internal and external VPN-1 Gateways. Whenworking with externally managed gateways, the administrator of the peer externalgateways must configure his or her gateways appropriately.Obtain Information from the Peer AdministratorIf working with externally managed gateways, obtain from the peer administrator theexternal gateway topology and VPN Domain information.You must also agree on the pre-shared secrets, and on authentication, encryption anddata integrity methods for the VPN.Defining the Gateways1 Define the gateway object.• If the gateway is an internal Gateway, define a Check Point Gateway object. Inthe Network Objects tree, right click and select New > Check Point > Gateway....• If the gateway is externally managed:• If it is a Check Point Gateway, In the Network Objects tree, right click andselect New > Check Point > Externally Managed Gateway....• If it is not a Check Point Gateway, select Manage > Network Objects... > New...> Interoperable Device....2 For an internally managed gateway or for a Check Point externally managedgateway, in the General Properties page of the gateway object, select VPN-1 Pro.3 For an internally managed gateway only, in the Communication window, establishSecure Internal Communication.4 In the Topology page, define the IP address, network mask, and anti-spoofing forevery Gateway interface5 Still on the Topology page, define the VPN Domain. select either:• All IP Addresses behind gateway based on Topology information or• Manually defined. Either select an existing network or group from thedrop-down list or create a new group of machines or networks by clickingNew...Chapter 6 Traditional Mode VPNs 99

Configuring Traditional Mode VPNs6 In the VPN page, click Traditional mode configuration. The Traditional mode IKEproperties window opens.• In the Support authentication methods area, select Pre-shared Secret, click EditSecrets.... Only peer gateways which support pre-shared secrets appear in thelist.• Type a secret for each peer gateway.• Select IKE phase 1 encryption and data integrity methods or accept the checkeddefaults.7 Repeat step 1 to step 6 for each gateway taking part in the VPN.Defining the Encrypt Rule8 In the Security Rule Base, define the Encrypt rule(s).9 If you wish to change the IKE Phase 2 properties for this rule, double click theEncrypt action and make the required changes.100

VPN-1 Gateway ProductsThis section covers VPN products that complement Check Point’s VPN-1 solution.

CHAPTER 7VPN-1 NetIn This ChapterThe Need for a VPN Dedicated Module page 103The Check Point Solution — VPN-1 Net page 103VPN-1 Net Considerations page 105VPN-1 Net Configuration page 105The Need for a VPN Dedicated ModuleVPN-1 Pro addresses both security and privacy requirements, but in some networkconfigurations, these needs are best implemented on different machines — one providessecurity functionality while the other provides the VPN functionality.The motivations for separating security (access control functionality) from VPN mightbe administrative, security (separating security management from VPN management) oreven economic.The Check Point Solution — VPN-1 NetVPN-1 Net OverviewVPN-1 Net provides an economical VPN solution in these network deployments,enabling an organization to focus on VPN topology separately from the securitytopology. A VPN-1 Net Module implements most VPN-1 Pro related features: it isfully compatible with VPN communities and enables both site-to-site and remote accessVPNs.Remote access connections and connections in the context of a VPN community areencrypted, while other connections are not.103

The Check Point Solution — VPN-1 NetAccess ControlAlthough VPN-1 Net is not an Access Control module and has no Rule Base, it canenforce one of four pre-defined policies:1 Accept all connections.2 Accept only encrypted connections.Accept only the following connections:• remote access connections• connections in the context of a Site-to-Site VPN community of which theVPN-1 Net Module is a memberAll other connections are blocked.3 Accept encrypted and outbound connections.Accept only the following connections:• remote access connections• connections in the context of a Site-to-Site VPN community of which theVPN-1 Net Module is a member• outgoing connection initiated by machines behind the VPN-1 Net Module.All other connections are blocked.4 Block all connections.Implied rules (specified in the Global Properties windows) are supported on VPN-1 Netas well.Some more granularity is added to the policy in order to enable remote configurationof the VPN-1 Net machine. Although connections directed at the VPN-1 Net machineare allowed only by the first pre-defined policy out of the ones mentioned above, it ispossible to allow HTTPS and SSH connections directed at this machine even if one ofthe other pre-defined policies is installed.VPN-1 Net and NATIn the VPN-1 Net page of the Global Properties window, you can configure one of threeNAT options:• no NAT• hide all connections• hide only non-encrypted connectionsAlternatively, you can configure NAT in the NAT page of the VPN-1 Net object. Inthis way, you can configure either static or dynamic (Hide) NAT. See FireWall-1 andSmartDefence for more information.104

DeploymentNAT can only be configured automatically, since there is no Rule Base.VPN-1 Net ConsiderationsDeploymentBecause VPN-1 Net provides only minimal security functionality (see “Access Control”on page 104), it is essential that the network be configured so that adequate security isprovided elsewhere. Careful configuration is required to ensure that security is notcompromised by deploying VPN-1 Net instead of VPN-1 Pro on a specific gateway.FIGURE 7-1VPN routing with VPN-1 Net modules.One possibility for providing security for the VPN-1 Net machines is to implementVPN routing, as shown in FIGURE 7-1. For more information, see the chapter: “VPNRouting”.VPN-1 Net ConfigurationThe process of installing VPN-1 Net is very similar to the process of installing a VPN-1Pro Module. See: SmartCenter overview of SmartCenter Guide for information regardinginstallation and configuration.Once VPN-1 Net is installed on a gateway, proceed as follows:1 Define the Network Object and initiate SIC communication with it.Chapter 7 VPN-1 Net 105

VPN-1 Net Configuration2 In the General page of the object’s Properties window, select the VPN-1 Net.This adds the pages dealing with various issues and features supported by VPN-1Net.3 Configure the VPN communities and other parameters in the same way as forVPN-1.4 In the VPN-1 Net page of the Global Properties window, specify the pre-definedpolicy to enforce on the VPN-1 Net Module (see “Access Control” on page 104).5 If you did not define NAT on the objects representing the machines behind theVPN-1 Net modules, define the appropriate NAT method under NAT.6 Specify the desired Tracking Options.7 If Security Policy is not set to Accept all connections, and you want to be able toconfigure the VPN-1 Net machine from a remote location using HTTPS or SSH,enable the relevant options under Remote Device Configuration.8 Install the policy.SSH and HTTPS Connections to VPN-1 Net ModulesUnder Global properties, VPN-1 Net, in the Remote Device Configuration section, aretwo settings for:• Enable HTTP connections to VPN-1 Net modules• Enable SSH connections to VPN-1 modulesIf you enable these options, you must also define the Net-1 modules as “gui clients” onthe SmartCenter Server — that is, as machines/IP addresses which are allowed toconnect with the SmartCenter Server.106

CHAPTER 8VPN-1 Accelerator CardsIn This ChapterThe Need for VPN-1 Acceleration page 107The VPN-1 Accelerator Card Solution page 107Accelerator Driver Installation and Uninstallation page 109Enabling and Disabling the VPN-1 Accelerator Card page 111Acceleration Diagnostics page 112The Need for VPN-1 AccelerationOrganizations are rapidly deploying Virtual Private Networks (VPNs) to deliver secureconnectivity to remote offices, mobile users, and business partners. However, as thevolume of VPN traffic grows, performance becomes an increasingly important concern.The VPN must secure network communications without degrading performance. Thecomputationally intensive tasks required by some encryption algorithms, such as 3 DES,can exhaust host CPU resources, causing the VPN gateway to become a performancebottleneck.The VPN-1 Accelerator Card SolutionVPN-1 Accelerator Cards are PCI compatible add-in cards that accelerate VPN-1gateway performance by off loading intensive cryptographic operations from the hostCPU to a dedicated processor on the card itself.Three VPN-1 Accelerator cards are available, in order of the most recent:• VPN-1 Accelerator Card III• VPN-1 Accelerator Card II• VPN-1 Accelerator Card I107

The VPN-1 Accelerator Card SolutionAn additional software-based VPN driver called VPN-1 Accelerator Driver, is anintegral part of VPN-1. This software accelerator loads itself if there are multiple CPUsand uses the idle processors for encryption operations.This chapter deals with Accelerator Cards II and III.TABLE 8-1VPN-1 Accelerator Card AttributesAttributesEncryptionAlgorithmAuthenticationAlgorithmVPN-1 ProversionVPN AcceleratorCard III3DESDESVPN AcceleratorCard II3DESDESVPN-1AcceleratorDriver3DESDESAES-128AES-256MD5, SHA1 MD5, SHA1 MD5,SHA1NG FP3 or higher4.1 SP3 or higherFor Accelerator Card III with 3DES, the throughput is 400 Mbps, whereas forAccelerator Card II with 3DES, the throughput is 175 Mbps.Even when VPN traffic is moderate, accelerator cards improve overall gatewayperformance by freeing resources for other security tasks like access control, attackprotection, and bandwidth management.VPN-1 Accelerator Cards are PCI-compatible cards providing plug-and-play supportwith VPN-1. The Software drivers for these cards are installed as part of the VPN-1installation process, providing seamless integration with Check Point’s VPN solution.Cards are administered directly by the gateway and can be installed on new or existingVPN-1 gateways with no reconfiguration. Auto-detection of hardware failures promptsVPN-1 to bypass hardware encryption facilities to utilize software encryptioncapabilities of the gateway. This exceptional level of fault tolerance ensures VPNup- time.The VPN-1 Accelerator Cards also support PKCS11 API and can be used by CheckPoint products for acceleration of public key operations and for the generation ofrandom numbers. See Chapter 3, “Using PKI Solutions” for more information.108

Pre-Installation InstructionsAccelerator Driver Installation and UninstallationPre-Installation InstructionsBefore installing VPN-1 Accelerator Card for VPN-1 Pro, proceed as follows:1 Install VPN-1 Pro.2 Uninstall any previously installed drivers for other Check Point Accelerator Cards(Luna, software-based VPN-1 Accelerator Driver or VPN -1 Accelerator II [ifinstalling VPN-1 Accelerator III]).Make sure the conf directory of your VPN-1 Pro does not contain the filevpn_accel.conf.Installing the SoftwareSolaris1 Mount the card to an available PCI slot.2 Download the latest acceleration package from Check Point Web DownloadCenter, or copy the acceleration package from the CD.3 For the VPN-1 Accelerator Card III, enter the following commands:hostname# gunzip CPacc3-10.tgzhostname# tar -xvf CPacc3-10.tarhostname# pkgadd -d . CPacc3-10For the VPN-1 Accelerator Card II, enter the following commands:hostname# gunzip CPacc2-10.tgzhostname# tar -xvf CPacc2-10.tarhostname# pkgadd -d . CPacc2-104 When done, reboot the machine.Windows1 Download the latest acceleration package from Check Point Web DownloadCenter, or copy the acceleration package from the CD.2 Run SETUP.Chapter 8 VPN-1 Accelerator Cards 109

Accelerator Driver Installation and Uninstallation3 Mount the card to an available PCI slot.Note - For the platforms, Windows 2000 and XP a special plug-and-play procedure should beexecuted. The user needs to locate an appropriate cryptonet.inf file and point to itduring the device installation procedure of the OS. The installation package places this file inthe $FWDIR/conf folder.4 When done, reboot the machine.Linux1 Mount the card to an available PCI slot.2 Download the latest acceleration package from Check Point Web DownloadCenter, or copy the acceleration package from the CD.3 For the VPN-1 Accelerator Card III, enter the following commands (the CDversion is already in the rpm format, there is no need to decompress and tar thefiles.):hostname# gunzip CPacc3-10-00.i386.tgzhostname# tar -xvf CPacc3-10-00.i386.tarhostname# rpm -i CPacc3-10-00.i386.rpmFor the VPN-1 Accelerator Card II, enter the following commands (the CD versionis already in the rpm format, there is no need to decompress and tar the files.):hostname# gunzip CPacc2-10-00.i386.tgzhostname# tar -xvf CPacc2-10-00.i386.tarhostname# rpm -i CPacc2-10.rpmNokiaTo install VPN-1 Accelerator card on a Nokia-based gateway, see the supportdocumentation of your Nokia vendor.Uninstalling the SoftwareSolarisTo uninstall VPN-1 Accelerator Card on Solaris, proceed as follows:1 For the VPN-1 Accelerator Card III, enter the following command:pkgrm CPacc3-10For the VPN-1 Accelerator Card II, enter the following command:pkgrm CPacc2-102 When done, reboot the machine.110

Uninstalling the SoftwareWindowsTo uninstall VPN-1 Accelerator Card on Windows NT, proceed as follows:1 Click on Add/Remove Programs in the Control Panel.2 Select VPN-1 Accelerator Card.3 Click Add/Remove and follow the instructions.4 When done, reboot the machine.LinuxTo uninstall VPN-1 Accelerator Card on Linux, proceed as follows:1 For the VPN-1 Accelerator Card III, enter the following command:rpm -e CPacc3-10-00For the VPN-1 Accelerator Card II, enter the following command:rpm -e CPacc2-10-002 When done, reboot the machine.Enabling and Disabling the VPN-1 Accelerator CardIf a VPN-1 Accelerator Card is installed, it is enabled by default when VPN-1Pro starts.You can also enable or disable it manually as well as obtain its status. vpn accel is usedto enable/disable both VPN-1 Accelerator Cards.When you enable or disable the VPN-1 Accelerator Card, current connections are notdropped. Instead, encryption continues in the hardware or software, accordingly.VPN accelSyntaxvpn accel on | off | stat [-l]Chapter 8 VPN-1 Accelerator Cards 111

Acceleration DiagnosticsOptionsTABLE 8-2parameteronoffstatVPN accel attributesmeaningEnable VPN-1 Accelerator CardDisable VPN-1 Accelerator CardObtain the status of the VPN-1 Accelerator CardOptionsparametermeaningAcceleration Diagnostics-1 long format (letter ell)Acceleration diagnostics can be performed on the following platforms as follows:• Window via the GUI (FIGURE 8-1)• Solaris and Linux via the command lineThere are two separate diagnostics utilities• VPN-1 Accelerator Card III - acc3diag• VPN-1 Accelerator Card II - bcmdiagTo run these utilities on Windows, double-click on the VPN-1 Accelerator Diagnosticsshortcut on the desktop.The path for this utility is located for Solaris and Linux - acc3diag is located in$ACDIR/bin for the VPN-1 Acceleration Card III and bcmdiag is located in$FWDIR/bin for the VPN-1 Accelerator Card II.Stop the VPN-1 Accelerator Card by running vpn accel off, prior to running thediagnostics utilities.112

Uninstalling the SoftwareFIGURE 8-1Diagnostics utility windowSyntaxFor the VPN-1 Accelerator Card III:acc3diag {-hvs}For the VPN-1 Accelerator Card II:bcmdiag {-hvs}TABLE 8-3Usageparametermeaning-h Help on options-v verbose-s Run “self-test” on device; this option causes thedevice to be resetYou can run the utilities without specifying any parameter in order to verify that theVPN-1 Accelerator Cards device is installed.Runtime MessagesThe following messages are output from acc3diag and bcmdiag. In these messages:• VPN Accelerator Card represents VPN-1 Accelerator Card IIIChapter 8 VPN-1 Accelerator Cards 113

Acceleration Diagnostics• CryptoNet device represents VPN-1 Accelerator Card IITABLE 8-4Runtime MessagesmessageVPN Accelerator Card IIIdevice installed/CryptoNetdeviceDevice type BCM58xxRevision x. Driver versionx.xx. Diagnostic versionx.xxVPN Accelerator Card IIIdevice selftest passed/CryptoNet deviceOptions: h (help) v(verbose) s (selftest)descriptionThis is printed when acc3diag or bcmdiag is invokedand a VPN Accelerator Card device is found.This message which displays the driver, hardware, anddiagnostic information, is displayed when the -v optionis used.This message is displayed when the selftest routine issuccessful.This message is displayed when the -h or an invalidoption is used for acc3diag or bcmdiag.Error MessagesThe following messages are output from acc3diag and bcmdiag.In these messages:• VPN Accelerator Card represents VPN-1 Accelerator Card III• CryptoNet device represents VPN-1 Accelerator Card II:TABLE 8-5Error MessagesmessageVPN-1 AcceleratorCard III deviceinstalled/No CryptoNetdeviceVPN-1 AcceleratorCard III device selftestfailed/CryptoNetdeviceVPN-1 AcceleratorCard III device notresponding/CryptoNetdevicedescriptionThis message is displayed when no VPN-1 AcceleratorCard device can be found.This message is displayed when the selftest routine fails.Technical support should be contacted if this problempersists.This message is displayed when a VPN-1 AcceleratorCard device is installed but is not responding to thebcmdiag/acc3diag request.114

Windows NT Performance MonitorWindows NT Performance MonitorWindows NT Performance Monitor is used to monitor the card performance. To openthe application, go to Program Files>Administrative Tools>Performance Monitor.The Performance Monitor window (FIGURE 8-2) is displayed:FIGURE 8-2Performance Monitor windowTo insert a chart with counters of the card performance, proceed as follows:1 In the Performance Monitor window, select Add to Chart from the Edit menu.The Add to Chart window is displayed (FIGURE 8-3):FIGURE 8-3Add to Chart window2 From the Objects drop-down window select Security Accelerator.The following counters are available:• Bits decrypted per sec• Bits encrypted per secChapter 8 VPN-1 Accelerator Cards 115

Acceleration Diagnostics• Blocks decrypted per sec• Blocks encrypted per sec• Crypto operation error• Crypto resources• Key operation errors• Key request per sec116

Remote Access VPNThis section covers with VPN-1 solutions for remote users who are connecting to the Check PointGateway from various locations, using different Client solutions.

CHAPTER 9VPN for Remote ClientsIn This ChapterNeed for Remote Access VPN page 119The Check Point Solution for Remote Access page 120Remote Access VPN Considerations page 127Remote Access Configuration page 129Need for Remote Access VPNWhenever users access the organization from remote locations, it is essential that theusual requirements of secure connectivity be met but also the special demands ofremote clients, for example:• The IP of a remote access client might be unknown.• The remote access client might be connected to a corporate LAN during theworking day and connected to a hotel LAN during the evening, perhaps hiddenbehind some kind of NATing device.• The remote client might need to connect to the corporate LAN via a wirelessaccess point.• Typically, when a remote client user is out of the office, they are not protected bythe current security policy; the remote access client is both exposed to Internetthreats, and can provide a way into the corporate network if an attack goes throughthe client.To resolve these issues, a security framework is needed that ensures remote access to thenetwork is properly secured.119

The Check Point Solution for Remote AccessThe Check Point Solution for Remote AccessIn This SectionEstablishing a Connection between a Remote User and a Gateway page 121Remote Access Community page 122Access Control for Remote Access page 124Client-Gateway Authentication Schemes page 124Identifying Elements of the Network to the Remote Client page 122Advanced Features page 126VPN-1 SecuRemote — Check Point’s Remote Access VPN solution — enables you tocreate a VPN tunnel between a remote user and your organization’s internal network.The VPN tunnel guarantees:• Authenticity, by using standard authentication methods• Privacy, by encrypting data• Integrity, by using industry-standard integrity assurance methodsSecuRemote/SecureClient extends VPN functionality to remote users, enabling usersto securely communicate sensitive information to networks and servers over the VPNtunnel, using both dial-up (including broadband connections), and LAN (and wirelessLAN) connections. Users are managed either in the internal database of the FireWall-1Gateway or via an external LDAP server.After a SecuRemote user is authenticated, a transparent secured connection isestablished.SecuRemote works with:• VPN-1 Gateways.• VPN-1 Net Gateways.• VPN-1 Edge/Embedded devices provided that SecuRemote is running intransparent mode. (see: “Connection Modes”.)Enhancing SecuRemote with SecureClient ExtensionsSecureClient is a remote access client that includes and extends SecuRemote by addinga number of features:• Security features• Connectivity features• Management features120

Establishing a Connection between a Remote User and a GatewaySecurity Features• A Desktop Security Policy. See: “Desktop Security - Protecting Remote Clients”.• Logging and Alerts• Secure Configuration Verification (SCV); (see: “Secure Configuration Verification -SCV”Connectivity Features• Office mode addresses (see: “Office Mode”).• Visitor mode (see: “Resolving Remote Access Connectivity Issues”.)• Hub mode. (see: “VPN Routing”.)Management Features• Automatic software distribution. (see: “Packaging Tool - Simplified Remote ClientInstallation”.)• Diagnostic toolsEstablishing a Connection between a Remote User and aGatewayTo allow the user to access a network resource protected by a VPN-1 Gateway, a VPNtunnel establishment process is initiated. An IKE (Internet Key Exchange) negotiationtakes place between the peers.During IKE negotiation, the peers’ identities are authenticated. The Gateway verifiesthe user’s identity and the client verifies that of the Gateway. The authentication can beperformed using several methods, including digital certificates issued by the InternalCertificate Authority (ICA). It is also possible to authenticate using third-party PKIsolutions, pre-shared secrets or third party authentication methods (for example,SecurID, Radius etc.).After the IKE negotiation ends successfully, a secure connection (a VPN tunnel) isestablished between the client and the Gateway. All connections between the client andthe Gateway’s VPN domain (the LAN behind the Gateway) are encrypted inside thisVPN tunnel, using the IPSec standard. Except for when the user is asked toauthenticate in some manner, the VPN establishment process is transparent.Chapter 9 VPN for Remote Clients 121

The Check Point Solution for Remote AccessFIGURE 9-1Remote to GatewayIn FIGURE 9-1, the remote user initiates a connection to Gateway 1. Usermanagement is not performed via the VPN-1 database, but an LDAP server belongingto VPN Site 2. Authentication takes place during the IKE negotiation. Gateway 1verifies that the user exists by querying the LDAP server behind Gateway 2. Once theuser’s existence is verified, the Gateway then authenticates the user, for example byvalidating the user’s certificate. Once IKE is successfully completed, a tunnel is created;the remote client connects to Host 1.If the client is behind the Gateway (for example, if the user is accessing the corporateLAN from a company office), connections from the client to destinations that are alsobehind the LAN Gateway are not encrypted.Remote Access CommunityA Check Point Remote Access community enables you to quickly configure a VPNbetween a group of remote users and VPN-1 gateways. A Remote Access communityis a virtual entity that defines secure communications between VPN-1 gateways andremote users. All communications between the remote users and the gateways’ VPNdomains are secured (authenticated and encrypted) according to the parameters definedfor Remote Access communications and SmartDashboard Global Properties.Identifying Elements of the Network to the Remote ClientSecuRemote/SecureClient needs to know the elements of the organization’s internalnetwork before it can handle encrypted connections to and from network resources.These elements, known as a topology, are downloaded from any VPN-1 Pro modulemanaged by the SmartCenter Server.122

Connection ModesA site’s topology information includes IP addresses on the network and host addresses inthe VPN domains of other Gateways controlled by the same SmartCenter Server. If adestination IP is inside the site’s topology, the connection is passed in a VPN tunnel.When the user creates a site, the client automatically contacts the site and downloadstopology information and the various configuration properties defined by theadministrator for the client. This connection is secured and authenticated using SSLover IKE. If the site’s topology changes, the user is instructed to update the site’stopology. The network administrator can also configure an automatic topology updatefor remote clients. This requires no intervention by the user.Connection ModesThe remote access client has two modes for connecting with Gateways:• Transparent mode.• Connect mode.Transparent modeIn transparent mode, a VPN tunnel is created only when an encrypted connection isneeded. For example, a remote user opens a mail program to retrieve emails. Theremote client software determines this should be an encrypted connection to the mailserver inside the organization and initiates IKE. The user is not aware that an encryptedconnection is taking place (except for when prompted to authenticate). For this reason,this mode is referred to as “transparent”.Connect modeDuring connect mode, the remote user deliberately initiates a VPN link to a specificsite. Subsequent connections to any host behind the Gateway use the existing VPNlink.Connect mode offers a number of features not available in transparent mode:• Office mode, to resolve routing issues between the client and the Gateway.• Visitor mode, for when the client needs to tunnel all client to Gateway trafficthrough a regular TCP connection on port 443.• Routing all traffic through Gateway (Hub mode), to achieve higher levels ofsecurity and connectivity.• User profiles. See: “User Profiles”.These features are only available in SecureClient.Chapter 9 VPN for Remote Clients 123

The Check Point Solution for Remote AccessUser ProfilesMobile users are faced with a variety of connectivity issues. During the morning theyfind themselves connected to the LAN of a partner company; during the evening,behind some kind of NATing device employed by the hotel where they are staying.Different user profiles are used to overcome changing connectivity conditions. Userscreate their own profiles, or the network administrator creates a number of profiles forthem. If the administrator creates a profile, the profile is downloaded to the client whenthe user updates the site topology. The user selects which profile to work with from alist. For example, a profile that enables UDP encapsulation in order to cope with someNATing device, or a profile that enables Visitor mode when the remote client musttunnel the VPN connection over port 443. Also, from which policy server to downloadthe Desktop Security Policy is contained in the profile.Access Control for Remote AccessTypically the administrator needs to define a set of rules that determines access controlto and from the network. This is also true for remote access clients belonging to aremote access community. Policy rules must be created in order to control the wayremote clients access the internal network via the Gateway. (Membership of acommunity does not give automatic access to the network.)The Gateway’s Security Policy Rule Base defines access control; in other words,whether a connection is allowed. Whether a connection is encrypted is determined bythe community. If both the source and the destination belong to the community, theconnection is encrypted; otherwise, it is not encrypted. For example, consider a rulethat allows FTP connections. If a connection matching the rule is between communitymembers, the connection is encrypted. If the connection is not between communitymembers, the connection is not encrypted.The Gateway’s Security Policy controls access to resources behind the Gateway, andprotects the VPN-1 Gateway and the networks behind it. Since the remote client is notbehind the Gateway, it is not protected by the Gateway’s Security Policy. The remoteclient is protected instead by a Desktop Security Policy.Client-Gateway Authentication SchemesAuthentication is a key factor in establishing a secure communications channel amonggateways and remote clients. Various authentication methods are available, for example:• Digital certificates• Pre-shared secrets• Other authentication methods (made available via Hybrid mode)124

Client-Gateway Authentication SchemesDigital CertificatesDigital Certificates are the most secure and recommended method for authentication.Both parties present certificates as a means of proving their identity. Both parties verifythat the peer’s certificate is valid (i.e. that it was signed by a known and trusted CA, andthat the certificate has not expired or been revoked).Digital certificates are issued either by Check Point’s Internal Certificate Authority orthird-party PKI solutions. Check Point’s ICA is tightly integrated with VPN-1 and isthe easiest way to configure a Remote Access VPN. The ICA can issues certificatesboth to VPN-1 gateways (automatically) and to remote users (generated or initiated).Using the ICA, generate a certificate and securely transfer it to the user. Alternatively,initiate the certificate generation process on SmartCenter Server. The process iscompleted independently by the user. The administrator can also initiate a certificategeneration on the ICA management tool (the only option available if users are definedon an LDAP server).It is also possible to use third-party Certificate Authorities to create certificates forauthentication between VPN-1 Gateways and remote users. The supported certificateformats are PKCS#12, CAPI, and Entrust.Users can also be provided with a hardware token for storing certificates. This optionoffers the advantage of higher level of security, since the private key resides only on thehardware token.As part of the certificate validation process during the IKE negotiation, both the clientand the Gateway check the peer’s certificate against the Certificate Revocation List (CRL)published by the CA which issued the certificate. If the client is unable to retrieve aCRL, the Gateway retrieves the CRL on the client’s behalf and transfers the CRL tothe client during the IKE negotiation (the CRL is digitally signed by the CA forsecurity).Pre-Shared SecretThis authentication method has the advantage of simplicity, but it is less secure thancertificates. Both parties agree upon a password before establishing the VPN. Thepassword is exchanged “out-of-band”, and reused multiple times. During theauthentication process, both the client and Gateway verify that the other party knowsthe agreed-upon password.Note - Pre-shared secrets are supported only for backward compatibility with 4.1 remoteclients.Chapter 9 VPN for Remote Clients 125

The Check Point Solution for Remote AccessOther Authentication methods available via Hybrid ModeDifferent organizations employing various means of user authentication may wish tocontinue using these methods. Hybrid mode is an IKE mode that supports anasymmetrical way of authentication to address this requirement. Using Hybrid mode,the user employs one of the methods listed below to authenticate to the Gateway. Inreturn, the Gateway authenticates itself to the client using strong, certificate-basedauthentication. Authentication methods which can be used in Hybrid mode are allthose supported for normal user authentication in VPN-1, namely:• SecurID — The user is challenged to enter the number displayed on the SecurityDynamics SecurID card. There are no scheme-specific parameters for the SecurIDauthentication scheme. The FireWall-1 Module acts as an ACE/Agent 5.0. Foragent configuration.The software version of RSA’s SecurID (SoftID) is also supported, a softwareapplication that runs directly from the user's desktop and doesn't require the use ofactual hardware cards.• VPN-1 Pro-1 Password — The user is challenged to enter his or her internal VPN-1Pro password.• OS Password — The user is challenged to enter his or her Operating Systempassword.• RADIUS — The user is challenged for the correct response, as defined by the Radiusserver.• TACACS — The user is challenged for the correct response, as defined by theTACACS or TACACS+ server.• SAA. SAA is an API extension to SecuRemote/SecureClient that enables thirdparty authentication methods, such as biometrics, to be used withSecuRemote/SecureClient.For additional information regarding authentication methods that are not based oncertificates or pre-shared secrets see: Authentication in FireWall-1 and SmartDefense.Advanced FeaturesRemote Access VPN supports other advanced features such as:• Resolving connectivity and routing issues. See: “Office Mode”, and “ResolvingRemote Access Connectivity Issues”.• IP-per-user/group.• L2PT clients.126

Policy Definition for Remote AccessRemote Access VPN ConsiderationsIn This SectionPolicy Definition for Remote Access page 127User Certificate Creation Methods when Using the ICA page 127User Management – Internal Database vs. LDAP Server page 127NT Group/Radius Class Authentication Feature page 128When designing Remote Access VPN, consider the following issues:Policy Definition for Remote AccessThere must be a rule in the Security Policy Rule Base that grants remote users accessto the LAN. Consider which services are allowed. Restrict those services that need tobe restricted with an explicit rule in the Security Policy Rule Base.User Certificate Creation Methods when Using the ICACheck Point’s Internal Certificate Authority (ICA) offers two ways to create andtransfer certificates to remote users:1 The administrator generates a certificate in SmartCenter Server for the remoteuser, saves it to removable media and transfers it to the client out of band.2 The administrator initiates the certificate process on the SmartCenter Server (orICA management tool), and is given a registration key. The administrator transfersthe registration key to the user “out of band”. On receiving the registration key, theuser inputs the key to his client. The client establishes an authenticated connectionto the ICA (using the CMC protocol) and completes the certificate generationprocess. In this way:• Private keys are generated on the client• Hardware tokens can be used for certificatesThis method is especially suitable for geographically spaced-remote users.User Management – Internal Database vs. LDAP ServerRemote Access functionality includes a flexible user management scheme. Users aremanaged in number of ways:• On the internal database of the SmartCenter Server (uploaded to VPN-1 ProGateways during a policy install).Chapter 9 VPN for Remote Clients 127

Remote Access VPN Considerations• On an LDAP (Lightweight Directory Access Protocol) Server.• RADIUSNote - RADIUS is essentially an authentication protocol. If the user is matched by the VPN-1Gateway (consulting either its own internal database or external LDAP server) and theauthentication scheme for that user is defined as RADIUS, then the authentication process ispassed onto the RADIUS server. If the user is not found by the VPN-1 Gateway but matchedto the “generic” user account, which specifies RADIUS, then once more authentication ispassed to the RADIUS server. Either way, if RADIUS provides authentication services forremote access clients the RADIUS server also needs to manage the users, since differentusers almost certainly present different authentication credentials.• SecurID Token Management ACE/ServerNote - If you use SecurID, you must manage the users on the ACE server, since each user isassociated with a specific token. On the VPN-1 Gateway, put the SecurID users into a groupwith an External user profile (generic*) account that redirects the authentication process tothe ACE server.When choosing whether to manage the remote users on the VPN-1 database or on anexternal LDAP Server, take into consideration:• An LDAP Server can be used by many applications whereas the VPN-1 Prodatabase cannot.• An LDAP Server requires additional software and maintenance resources. TheVPN-1 Pro database, as a rule, does not.NT Group/Radius Class Authentication FeatureAuthentication can take place according to an NT groups or Radius classes. In this way,remote access users are authenticated according to the remote access community groupthey belong to.Note - Only NT groups are supported, not Active Directory.128

NT Group/Radius Class Authentication FeatureRemote Access ConfigurationIn This Section:Establishing Remote Access VPN page 130Defining User and Authentication methods in LDAP page 132Defining User Properties and Authentication Methods in the Internal Database.page 132Initiating User Certificates in the ICA Management Tool page 132Generating Certificates for Users in SmartDashboard page 132Initiating Certificates for Users in SmartDashboard page 133Configuring Certificates for Users and Gateway (Using Third Party PKI) page 133Enabling Hybrid Mode and Methods of Authentication page 135Configuring Authentication for NT groups and Radius Classes page 135Using a Pre-Shared Secret page 135Defining an LDAP User Group page 136Defining a User Group page 136Defining a VPN Community and its Participants page 136Defining Access Control Rules page 136Installing the Policy page 137User Certificate Management page 137Modifying encryption properties for Remote Access VPN page 138Working with RSA’S Hard and Soft Tokens page 139The following configuration assumes you are working in the Simplified mode. If not, goto Policy > Global Properties >VPN-1 Pro, select Simplified mode to all new SecurityPolicies and create a new Security Policy.Establishing Remote Access VPN requires configuration on both the Gateway side (viaSmartCenter server) and remote user side.For the Gateway side, the administrator needs to:1 Define the Gateway2 Decide how to manage users3 Configure the VPN community and its participantsChapter 9 VPN for Remote Clients 129

Remote Access Configuration4 Set appropriate access control rules in the Security Policy Rule Base5 Install the policy on the GatewayOn the remote client side, the user needs to:1 Define a site2 Register to the internal CA to receive a certificate (if required)3 Connect to the site.For more information see the SecuRemote/SecureClient User Guide.Establishing Remote Access VPNThe general workflow for establishing remote access VPN is shown in FIGURE 9-2.Start at the top, with Create Gateway and define Gateway properties, and trace a routedown to Install policy.Sections following the chart detail step-by-step procedures for each phase.FIGURE 9-2 displays a general workflow for establishing remote access VPN:130

Creating the Gateway and Defining Gateway PropertiesFIGURE 9-2Work Flow for establishing remote access VPNCreating the Gateway and Defining Gateway Properties1 In SmartDashboard, create the Gateway network object.2 On the General Properties page of the network object, select VPN-1 Net or VPN-1Pro.Chapter 9 VPN for Remote Clients 131

Remote Access Configuration3 Initialize a secure communication channel between the VPN module and theSmartCenter Server by clicking Communication...4 On the Topology page of Gateway, define the Gateway’s interfaces and the VPNdomain.A certificate is automatically issued by the Internal CA for the Gateway.Defining User and Authentication methods in LDAP1 Obtain and install a license that enables the VPN-1 Pro module to retrieveinformation from an LDAP server.2 Create an LDAP account unit.3 Define users as LDAP users. A new network object for LDAP users is created onthe Users tree. (The LDAP users also appear in the objects list window to theright.)For more information see: LDAP and User Management in the SmartCenter book.Defining User Properties and Authentication Methods in theInternal Database.Refer to Smart Overview in the SmartCenter Guide.Initiating User Certificates in the ICA Management Tool1 Double click a user to open that user’s property window. On the Encryption tabclick Edit... The IKE phase 2 properties window opens. On the Authentication tabof this window, select Public Key.2 Initiate the user certificate in the ICA management tool. For more information see:“The Internal Certificate Authority (ICA) and the ICA Management Tool” in theSmartCenter Guide.Generating Certificates for Users in SmartDashboard1 On the User properties window, Encryption tab, click Edit... The IKE phase 2properties window opens. On the Authentication tab, select Public key.2 In the Certificates tab of the User Properties window, click Generate and Save.132

Initiating Certificates for Users in SmartDashboard3 Enter and confirm a PKCS #12 password.PKCS #12 is a portable format for storing or transporting a user’s private keys,certificates, etc. The PKCS #12 file and the password should be securely transferredto the user out of band, preferably via diskette.4 In Global Properties, Authentication window, add or disable suffix matching.For users with certificates, it is possible to specify that only certificates with aspecified suffix in their DN are accepted. This feature is enabled by default, and isrequired only if the user names are not the full DN. All certificates DN’s arechecked against this suffix.Initiating Certificates for Users in SmartDashboardAn alternative to generating certificates for remote users is to only initiate the certificategeneration process. The process is then completed by the user.To initiate the certificate creation process:1 On the User properties window, Encryption tab, click Edit... The IKE phase 2properties window opens. On the Authentication tab, select Public key.2 In the Certificates tab of the User Properties window, click Initialize and selectCopy to clipboard. The registration key is copied to the clipboard.3 Open a text editor (for example, Notepad) and paste in the registration key.4 Transfer the registration key to the user “out-of-band”.5 In Global Properties, Authentication window, add or disable suffix matching.For users with certificates, it is possible to specify that only certificates with aspecified suffix in their DN are accepted. This feature is enabled by default, and isrequired only if the user names are not the full DN. All certificates DN’s arechecked against this suffix.Configuring Certificates for Users and Gateway (Using ThirdParty PKI)Using third party PKI involves creating:• A certificate for the user and• A certificate for the GatewayYou can use a third-party OPSEC PKI certificate authority that supports thePKCS#12, CAPI or Entrust standards to issue certificates for VPN-1 Gateways andusers. The Gateway must trust the CA and have a certificate issued by the CA.Chapter 9 VPN for Remote Clients 133

Remote Access ConfigurationFor users managed on an LDAP server, the full distinguished name (DN) which appearson the certificate is the same as the user’s name. But if the user is managed on theinternal database, the user name and DN on the certificate will not match. For thisreason, the user name in the internal database must be either the full DN which appearson the certificate or just the name which appears in the CN portion of the certificate.For example, if the DN which appears on the certificate is:CN=John, OU=Finance, O=Widget Enterprises, C=USThe name of the user on the internal database must be either:• John, or:• CN=John, OU=Finance, O=Widget Enterprises, C=USNote - The DN on the certificate must include the user’s LDAP branch. Some PKI solutions donot include (by default) the whole branch information in the subject DN, for example the DNonly includes the common name. This can be rectified in the CA configuration.To use a third-party PKI solution:1 On the User properties window, Encryption tab, click Edit... The IKE phase 2properties window opens. On the Authentication tab, select Public key.2 Define the third party Certificate Authority as an object in SmartDashboard. See“Trusting a CA – Step-By-Step”.3 Generate a certificate for your VPN-1 Pro Gateway from the third party CA. Formore information, see: “Enrollment – Step-By-Step”.4 Generate a certificate for the remote user from the third party CA. (Refer torelevant third party documentation for details.) Transfer the certificate to the user.5 In Global Properties, Authentication window, add or disable suffix matching.For users with certificates, it is possible to specify that only certificates with aspecified suffix in their DN are accepted. This feature is enabled by default, and isrequired only if:• Users are defined in the internal database, and• The user names are not the full DN.All certificates DN’s are checked against this suffix.Note - If an hierarchy of Certificate Authorities is used, the chain certificate of the user mustreach the same root CA that the Gateway trusts.134

Enabling Hybrid Mode and Methods of AuthenticationEnabling Hybrid Mode and Methods of AuthenticationHybrid mode allows the Gateway and remote access client to use different methods ofauthentication. To enable Hybrid Mode:From Policy > Global Properties > Remote Access >VPN - Basic select Hybrid Mode (VPN-1& FireWall-1 authentication).Defining User Authentication Methods in Hybrid Mode1 On the User Properties window, Authentication tab, select an appropriateauthentication scheme.2 Enter authentication credentials for the user.3 Supply the user (out of band) with these credentials.For information regarding authentication methods for users, authentication servers, andenabling authentication methods on the Gateway, see the chapter on “Authentication”in the FireWall-1 and SmartDefense book.Configuring Authentication for NT groups and Radius ClassesTo enable this group authentication feature:1 Set the add_radius_groups property in objects.C to “true”,2 Define a generic* profile, with Radius as the authentication method.3 Create a rule in the Policy rule base whose “source” is this group of remote usersthat authenticate using NT Server or Radius.Office mode ipassignment fileThis method also works for Office mode. The group listed in the ipassignment.conffile points to the group that authenticates using NT group authentication or Radiusclasses. See: “Office Mode via ipassignment.conf File” on page 153.Using a Pre-Shared SecretWhen using pre-shared secrets, the Remote User and VPN-1 Gateway authenticateeach other by verifying that the other party knows the shared secret: the user’spassword. To enable the use of pre-shared secrets:1 In Policy > Global Properties > Remote Access > VPN — Basic, select Pre-Shared Secret(For SecuRemote/SecureClient users)2 Deselect Hybrid Mode.Chapter 9 VPN for Remote Clients 135

Remote Access Configuration3 For each user, go to the Encryption tab of the User Properties window, select IKEand click Edit... to display the IKE Phase 2 Properties window.4 In the Authentication tab, enable Password (Pre-Shared Secret) and enter thepre-shared secret into the Password (Pre-shared secret) and Confirm Password fields.5 Inform the user of the password “out-of-band”.Defining an LDAP User GroupSee: LDAP and User Management in the SmartCenter book.Defining a User GroupIn SmartDashboard, create a group for remote access users. Add the appropriate users tothis group.Defining a VPN Community and its Participants1 On the VPN Communities tree, double-click Remote_Access_Community. TheRemote Access Community Properties window opens.2 On the Participating Gateways page, Add... Gateways participating in the RemoteAccess Community.3 On the Participating User Groups page, Add... the group that contains the remoteaccess users.Defining Access Control RulesAccess control is a layer of security not connected with VPN. The existence of aremote access community does not mean that members of that community have freeautomatic access to the network. Appropriate rules need to be created in the SecurityPolicy Rule Base blocking or allowing specific services.1 Create a rule in the Security Policy Rule Base that deals with remote accessconnections.136

Installing the Policy2 Double-click the entry in the VPN column. The VPN Match Conditions windowopens:3 Select Only connections encrypted in specific VPN Communities.4 Click Add... to include a specific community in this Security Policy Rule.5 Define services and actions. For example, to allow remote access users to access theorganization’s SMTP server, called SMTP_SRV, create the following rule:Source Destination VPN Service Action TrackAny SMTP_SRV Remote_Access_Community SMTP Accept LogInstalling the PolicyInstall the policy and instruct the users to create or update the site topology.User Certificate ManagementManaging user certificates involves:• Tracing the status of the user’s certificate• Automatically renewing a certificate• Revoking certificatesTracing the Status of User’s CertificateThe status of a user’s certificate can be traced at any time in the Certificates tab of theuser’s Properties window. The status is shown in the Certificate state field. If thecertificate has not been generated by the user by the date specified in the Pending untilfield, the registration key is deleted.Chapter 9 VPN for Remote Clients 137

Remote Access ConfigurationIf the user is defined in LDAP, then tracing is performed by the ICA management tool.Automatically Renewing a Users’ CertificateICA certificates for users can be automatically renewed a number of days before theyexpire. The client initiates a certificate renewal operation with the CA before theexpiration date is reached. If successful, the client receives an updated certificates.To configure automatic certificate renewal:1 Select Policy > Global Properties > Remote Access > Certificates.2 Select Renew users internal CA certificates and specify a time period. The timeperiod is the number of days before the user’s certificate is about to expire in whichthe client will attempt to renew the certificate.3 Install the Security Policy.4 Instruct the user to update the site’s topology.Revoking CertificatesThe way in which certificates are revoked depends on whether they are managedinternally or externally, via LDAP.For internally managed UsersWhen a user is deleted, their certificate is automatically revoked. Certificates can bedisabled or revoked at any time.If you initiated a certificate generation that was not completed by the user, you candisable the pending certificate by clicking Disable in the Certificates tab of the UserProperties window.If the certificate is already active, you can revoke it by clicking Revoke in theCertificates tab of the User Properties window.For Users Managed in LDAPIf users are managed in LDAP, certificates are revoked using the ICA management tool.Modifying encryption properties for Remote Access VPNThe encryption properties of the users participating in a Remote Access community areset by default. If you must modify the encryption algorithm and/or the data integritymethod, you can either do this globally for all users or configure the properties peruser.To modify the user encryption properties globally:138

Working with RSA’S Hard and Soft Tokens1 Select Policy > Global Properties > Remote Access > VPN - Advanced.2 In the User Encryption section, configure the global encryption and data integrityalgorithms.3 Select Enforce Encryption Algorithm and Data Integrity on all users.To enforce the global encryption properties for some users while being able to modifythem for specific users:1 Set the required properties on the VPN-Advanced page of the Global Propertieswindow and disable Enforce Encryption Algorithm and Data Integrity on all users.2 In the Encryption tab of the User Properties window select IKE and click Edit.The IKE Phase 2 Properties window is displayed.3 Select the Encryption tab.4 If you want the encryption and data integrity algorithms of the user to be takenfrom the Global Properties definitions, select Defined in the Remote Access VPN pageof the Global Properties window. If you want to customize the algorithms for thisuser, select Defined below and select the appropriate encryption and data integrityalgorithms.Working with RSA’S Hard and Soft TokensIf you use SecurID for authentication, you must manage the users on RSA’s ACEmanagement server. ACE manages the database of RSA users and their assigned hard orsoft tokens. SecureClient contacts the site’s Gateway. The Gateway contacts the ACEServer for user authentication information. This means:• The remote users must be defined as RSA users on the ACE Server.• On the VPN-1 Gateway, the SecurID users must be placed into a group with anexternal user profile account that specifies SecurID as the authentication method.SecurID Authentication DevicesSeveral versions of SecurID devices are available. The older format is a small device thatdisplays a numeric code, called a tokencode, and time bars. The token code changesevery sixty seconds, and provides the basis for authentication. To authenticate, the usermust add to the beginning of the tokencode a special password called a PIN number.The time bar indicates how much time is left before the next tokencode is generated.The remote user is requested to enter both the PIN number and tokencode intoSecureClient’s connection window.Chapter 9 VPN for Remote Clients 139

Remote Access ConfigurationThe newer format resembles a credit card, and displays the tokencode, time bars and anumeric pad for typing in the PIN number. These type of device mixes the tokencodewith the entered PIN number to create a Passcode. SecureClient requests only thepasscode.SoftID operates the same as the passcode device but consists only of software that sits onthe desktop.The Advanced view displays the tokencode and passcode with COPY buttons, allowingthe user to cut and paste between softID and SecureClient.SoftID and SecureClientFor remote users to successfully use RSA’s softID:1 The administrator creates the remote users on the Ace Server2 Out of band, the administrator distributes the SDTID token file (or several tokens)to the remote users.3 The remote user imports the tokens.4 The following userc.c property on SecureClient must be set in the OPTIONSsection:support_rsa_soft_tokens (true)140

Working with RSA’S Hard and Soft TokensThe remote user sees three windows:In this window, the remote user needs to enter the Token Serial Number and PIN. Ifthe remote user does not enter a PIN number, the following window appears:The PIN must be entered.Chapter 9 VPN for Remote Clients 141

Remote Access ConfigurationIf the token requires a passphrase, the remote user sees this window:142

CHAPTER10Office ModeIn This ChapterThe Need for Remote Clients to be Part of the LAN page 143Office Mode Solution page 144Office Mode Considerations page 149Configuring Office Mode page 150The Need for Remote Clients to be Part of the LANAs remote access to internal networks of organizations becomes widespread, it isessential that remote users are able to access as many of the internal resources of theorganization as possible.Typically, when remote access is implemented, the client connects using an IP addresslocally assigned by, for example, an ISP. The client may even receive a non-routable IPwhich is then hidden behind a NATing device. Because of this, several problems mayarise:• Some networking protocols or resources may require the client’s IP address to be aninternal one. Router ACLs (access lists), for example, might be configured to allowonly specific or internal IP addresses to access network resources. This is difficult toadjust without knowing the a remote client’s IP address in advance.• When assigned with a non-routable IP address a conflict may occur, either withsimilar non-routable addresses used on the corporate LAN, or with other clientswhich may receive the same IP address while positioned behind some other hidingNAT device.For example, SecuRemote/SecureClient receives an IP of 10.0.0.1 which is enteredinto the headers of the IPSec packet. The packet is NATed. The packet’s newsource IP is 192.168.17.5. The Gateway decapsulates the NATed IP and decrypts143

Office Mode Solutionthe packet. The IP address is reverted to its original source IP of 10.0.0.1. If thereis an internal host with the same IP, the packet will probably be dropped (ifanti-spoofing is turned on). If there is no duplicate IP, and the packet is forwardedto some internal server, the server will then attempt to reply to an non-existentaddress.• Two remote users are assigned the same IP address by an ISP (for example, twousers are accessing the organization from hotels which provide internal addressesand NAT them on the outbound). Both users try to access the internal networkwith the same IP address. The resources on the internal network of theorganization may have difficulty distinguishing between the users.Office Mode SolutionIn This SectionIntroducing Office Mode page 144How Office Mode Works page 145Assigning IP Addresses page 147IP Address Lease duration page 147Using name resolution - WINS and DNS page 148Anti Spoofing page 148Using Office Mode with multiple external interfaces page 148Introducing Office ModeOffice Mode enables a VPN-1 Pro gateway to assign a remote client an IP address. Theassignment takes place once the user connects and authenticates. The assignment lease isrenewed as long as the user is connected. The address may be taken either from ageneral IP address pool, or from an IP address pool specified per user group. Theaddress can be specified per user, or via a DHCP server, enabling the use of a nameresolution service. With DNS name resolution, it is easier to access the client fromwithin the corporate network.It is possible to allow all your users to use Office Mode, or to enable the feature for aspecific group of users. This can be used, for example, to allow privileged access to acertain group of users (e.g., administrators accessing the LAN from remote stations). Itis also useful in early integration stages of Office Mode, allowing you time to “pilot”this feature on a specific group of users, while the rest of the users continue to work inthe traditional way.144

How Office Mode WorksHow Office Mode WorksWhen you connect to the organization, an IKE negotiation is initiated automaticallyfrom the SecureClient to the VPN-1 Pro gateway. When using Office Mode, a specialIKE mode called config mode is inserted between phase 1 and phase 2 of IKE. Duringconfig mode, the client requests an IP from the gateway. Several other parameters arealso configurable this way, such as a DNS server IP address, and a WINS server IPaddress.After the gateway allocates the IP address, the client assigns the IP to a Virtual Adapteron the Operating system. The routing of packets to the corporate LAN is modified togo through this adapter. Packets routed in this way bear the IP address assigned by thegateway as their source IP address. Before exiting through the real adapter, the packetswill be IPSec encapsulated using the external IP address (assigned to the real adapter) asthe source address. In this way, non-routable IP addresses can be used with OfficeMode; the Office Mode non-routable address is concealed within the IPSec packet.For Office Mode to work, the IP address assigned by the VPN-1 Pro gateway needs tobe routable to that gateway from within the corporate LAN. This will allow packets onthe LAN being sent to the client to be routed back through the gateway. (See also:“Office Mode and Static Routes in a Non-flat Network”).Note - Only SecureClient works with Office Mode. A client with SecuRemote only is notsupported.A Closer LookThe following steps illustrate the process taking place when a remote user connectedthrough Office Mode wishes to exchange some information with resources inside theorganization:• The user is trying to connect to some resource on the LAN, thus a packet destinedfor the internal network is to be sent. This packet is routed through the virtualinterface that Office Mode had set up, and bears the source IP address allocated forthe remote user.• SecureClient encrypts the packet and builds a new encapsulating IP header for it.The source IP of the encapsulating packet is the remote client’s original IP address,and its destination is the IP address of the VPN-1 Pro gateway. The encapsulatedpacket is then sent to the organization through the Internet.• The VPN-1 Pro gateway of the organization receives the packet, decapsulates anddecrypts it, revealing the original packet, which bears the source IP allocated forthe remote user. The gateway then forwards the decapsulated packet to itsdestination.Chapter 10 Office Mode 145

Office Mode Solution• The internal resource gets a packet seemingly coming from an internal address. Itprocesses the packet and sends response packets back to the remote user. Thesepackets are routed back to the (internal) IP address assigned to the remote user.• The gateway gets the packet, encrypts and encapsulates it with the remote users’original (routable) IP address and returns the packet back to the remote user:FIGURE 10-1 Packets routed correctly to the remote client.In FIGURE 10-1:• SecuRemote/SecureClient uses the Office mode address in the encapsulated packetand 10.0.0.1 in the encapsulating header.• The packet is NATed to the new source address: 192.168.17.5• The Gateway decapsulates the NATed IP address and decrypts the packet. Thesource IP address is the Office Mode address.• The packet is forwarded to the internal server, which replies correctly.Office Mode and Static Routes in a Non-flat NetworkA flat network is one in which all stations can reach each other without going througha bridge or a router. One segment of a network is a “flat network”. A static route is aroute that is manually assigned by the system administrator (to a router) and needs to bemanually updated to reflect changes in the network.If the LAN is non-flat (stations reach each other via routers and bridges) then the OMaddress of the remote client must be statically assigned to the routers so that packets onthe LAN, destined for the remote client, are correctly routed to the Gateway.146

Assigning IP AddressesAssigning IP AddressesThe internal IP addresses assigned by the gateway to the remote user can be allocatedusing one of the following methods:• IP Pool• DHCP ServerIP PoolThe System Administrator designates a range of IP addresses to be utilized for remoteclient machines. Each client requesting to connect in Office Mode is provided with aunique IP address from the pool.DHCP ServerA Dynamic Host Configuration Protocol (DHCP) server is used to allocate IP addressesfor Office Mode clients. When a remote user connect to the gateway using OfficeMode, the gateway requests the DHCP server to assign the user an IP address from arange of IP addresses designated for Office Mode users.DHCP servers can allocate IP addresses from different ranges. This is done by includinga single IP address from the requested range in the DHCP request. In Office Mode, thegateway requests the IP address for the remote client. In this request, the gatewayindicates to the DHCP server it wishes to get an IP address from the Office Moderange by specifying an unused, virtual IP address from that range. After receiving thisrequest, the DHCP server allocates an IP address from this range (if available), and sendsthe DHCP reply packets to this virtual IP address.In Office Mode, the VPN-1 Pro gateway acts as a DHCP relay and should receive thesepackets so it can pass the allocated IP address to the client. To make sure that thegateway is able to act as a DHCP relay, it is essential that the network is configured toroute packets destined to the specified virtual IP address through the gateway, inaddition to the other addresses that fall within the Office mode range.IP Address Lease durationWhen a remote user’s machine is assigned an IP address, that machine can use it for acertain amount of time. This time period is referred to as the “IP address leaseduration”. The remote client automatically asks for a lease renewal after half of the IPlease duration period has elapsed. Hence, if the IP lease duration time is set to 60minutes, a renewal request will be sent after 30 minutes. If a renewal is granted, theclient will request a renewal again after 30 minutes and so on. If the renewal fails, theclient attempts again after half of the remaining time, e.g. 15 minutes, then 7.5 minutes,etc. If no renewal is granted and the 60 minutes of the lease duration times out, theChapter 10 Office Mode 147

Office Mode Solutiontunnel link terminates. This event is logged and can be viewed in the SecureClientDiagnostics. To renew the connection the remote user must reconnect to the gateway.Upon reconnection, an IKE renegotiation is initiated and a new tunnel created.When the IP address is allocated from a predefined IP pool on the gateway, the gatewaydetermines the IP lease duration period, default being 15 minutes.When using a DHCP server to assign IP addresses to users, the DHCP server’sconfiguration determines the IP lease duration. When a user disconnects and reconnectsto the gateway within a short period of time, it is likely that the user will get the sameIP address as before.Using name resolution - WINS and DNSTo facilitate access of a remote user to resources on the internal network, theadministrator can specify WINS and DNS servers for the remote user. This informationis sent to the remote user during IKE config mode along with the IP address allocationinformation, and is used by the remote user’s operating system for name-to-IPresolution when the user is trying to access the organization’s internal resources.Anti SpoofingWith Anti Spoofing, a network administrator configures which IP addresses areexpected on each interface of the firewall. Anti-spoofing ensures IP addresses are onlyreceived or transmitted in the context of their respective gateway interfaces. OfficeMode poses a problem to the anti-spoofing feature, since a client machine can connectand authenticate through several interfaces, e.g. the external interface to the Internet,or the wireless LAN interface; thus an Office Mode IP address may be encountered onmore than one interface. Office Mode enhances Anti Spoofing by making sure anencountered Office Mode IP address is indeed assigned to the user, authenticated onthe source IP address on the IPSec encapsulating packet, i.e. the external IP.Using Office Mode with multiple external interfacesTypically, routing is performed before encryption in VPN-1. In some complexscenarios of Office Mode, where the gateway may have several external interfaces, thismight cause a problem. In these scenarios, packets destined at a remote user’s virtual IPaddress will be marked as packets that are supposed to be routed through one externalinterface of the gateway. Only after the initial routing decision is made do the packetsundergo IPSEC encapsulation. After the encapsulation, the destination IP address ofthese packets is changed to the original IP address of the client. The routing path thatshould have been selected for the encapsulated packet might be through a different148

Advanced Featuresexternal interface than that of the original packet (since the destination IP addresschanged), in which case a routing error occurs. Office Mode has the ability to makesure that all Office Mode packets undergo routing after they are encapsulated.Advanced FeaturesAdvanced features such as IP per user and working with L2TP clients are covered inChapter 14, “Remote Access Advanced Configuration”.Office Mode ConsiderationsIn This SectionIP pool Versus DHCP page 149Routing Table Modifications page 149Using the Multiple External Interfaces Feature page 150IP pool Versus DHCPThe question of whether IP addresses should be assigned by the Firewall (using IPpools) or by a DHCP server is a network administration and financial issue. Somenetwork administrators may prefer to manage all of their dynamic IP addresses from thesame location. For them, a central DHCP server might be preferable. Moreover, DHCPallows a cluster to assign all the addresses from a single pool, rather than have a differentpool per cluster member as you have to with Firewall IP pools. On the other hand,purchasing a DHCP server can be viewed by some as an unnecessary financial burden,in which case the IP pool option might be preferred.Routing Table ModificationsIP addresses, assigned by Office Mode need to be routed by the internal LAN routersto the gateway (or gateway cluster) that assigned the address. This is to make surepackets, destined to remote access Office Mode users, reach the gateway in order to beencapsulated and returned to the client machine. This may require changes to theorganization’s routing tables.Chapter 10 Office Mode 149

Configuring Office ModeUsing the Multiple External Interfaces FeatureEnabling this feature instructs Office Mode to perform routing decisions after thepackets are encapsulated using IPSEC, to prevent routing problems discussed in UsingOffice Mode with multiple external interfaces page 148. This feature adds new checks andchanges to the routing of packets through the gateway, and has an impact onperformance. As a result, it is recommended to use this feature only when:• The gateway has multiple external interfaces, and• Office Mode packets are routed to the wrong external interface.Configuring Office ModeIn This SectionOffice Mode — IP Pool Configuration page 150Office Mode via ipassignment.conf File page 153Office Mode — DHCP Configuration page 154Office Mode Configuration on the Client Side page 156Before configuring Office Mode the assumption is that standard VPN Remote Accesshas already been configured. For more details on how to configure VPN RemoteAccess, see “VPN for Remote Clients”.”Before starting the Office Mode configuration, you must select an internal address spacedesignated for remote users using Office Mode. This can be any IP address space, aslong as the addresses in this space do not conflict with addresses used within theenterprise domain. It is possible to choose address spaces which are not routable on theInternet, such as 10.x.x.x.The basic configuration of Office Mode is using IP pools. The configuration of OfficeMode using DHCP for address allocation can be found in Office Mode — DHCPConfiguration page 154.Office Mode — IP Pool ConfigurationTo deploy the basic Office Mode (using IP pools):1 Create a network object to represent the IP Pool, by selecting Manage > NetworkObjects > New > Network.In the Network Properties — General tab, set the IP pool range of addresses asfollows:• In Network Address specify the first address to be used (e.g. 10.130.56.0).150

Office Mode — IP Pool Configuration• In Net Mask enter the subnet mask according to the amount of addresses youwish to use (entering 255.255.255.0, for example, this will designate all 254 IPaddresses from 10.130.56.1 till 10.130.56.254 for SecureClient Office Modeaddresses.)• Changes to the Broadcast Address section and the Network Properties — NAT tabare not necessary.• Close the network object properties window.2 Open the Gateway object through which the remote users will connect to theinternal network and select the Remote Access > Office Mode page. Enable OfficeMode for either all users or for a certain group.FIGURE 10-2 Office Mode page• In the Allocate IP from network select the IP Pool network object you havepreviously created.• IP lease duration — specify the duration in which the IP is used by theSecureClient machine.Chapter 10 Office Mode 151

Configuring Office Mode• Under Multiple Interfaces, specify whether you want routing to be done afterthe encapsulation of Office Mode packets, allowing traffic to be routed correctlywhen your gateway has multiple external interfaces.• Select Anti-Spoofing if you wish the firewall to check that Office Mode packetsare not spoofed.It is possible to specify which WINS and DNS servers Office Mode users should use.Note - WINS and DNS servers should be set on the SmartCenter machine only when IP poolis the selected method.To specify WINS and/or DNS servers, continue to step 3. Otherwise skip to step 6.3 Create a DNS server object, by selecting Manage >Network objects >New >Node >Host and specify the DNS machine’s name, IP address and subnet mask. Repeat thisstep if you have additional DNS servers.4 Create a WINS server object, by selecting Manage >Network objects >New >Node >Host and specify the WINS machine’s name, IP address and subnet mask. Repeatthis step if you have additional WINS servers.5 In the Check Point Gateway — Remote Access > Office Mode page, in the IP Poolsection click the “optional parameters” button.• In the IP Pool Optional Parameters window, select the appropriate objects for theprimary and backup DNS and WINS servers.• In the Domain name field, specify the suffix of the domain where the internalnames are defined. This instructs the Client as per what suffix to add when itaddresses the DNS server (e.g. example.com).6 Install the Policy.7 Make sure that all the internal routers are configured to route all the traffic destinedto the internal address space you had reserved to Office Mode users through theVPN-1 Pro Gateway. For instance, in the example above it is required to add routesto the class C sub network of 10.130.56.0 through the gateway’s IP address.In addition to the steps mentioned for the gateway side configuration, a fewconfiguration steps have to be performed on the client side in order to connect to thegateway in Office mode.See: “Office Mode Configuration on the Client Side” on page 156.152

Office Mode via ipassignment.conf FileOffice Mode via ipassignment.conf FileIt is possible to over-ride the Office Mode settings created on SmartCenter Server byediting a plain text file called ipassignment.conf in the \FWDIR\conf directory of theFirewall module. The module uses these Office Mode settings and not those defined forthe object in SmartCenter Server.Ipassignment.conf can specify:• An IP per user/group, so that a particular user or user group always receives thesame Office Mode address. This allows the administrator to assign specific addressesto users, or particular IP ranges/networks to groups when they connect usingOffice Mode.• A different WINS server for a particular user or group• A different DNS server• Different DNS domain suffixes for each entry in the file.Checking the SyntaxThe syntax of the ipassignment file can be checked using the commandipafile_check.From a shell prompt use issue: vpn ipafile_check ipassignment.confThe two parameters are:• warn. Display errors• detail. Show all detailsChapter 10 Office Mode 153

Configuring Office ModeFor example:Office Mode — DHCP Configuration1 When DHCP is the selected mode, DNS and WINS parameters are downloadedfrom the DHCP server. If using Office Mode in DHCP mode and you wish tosupply the user with DNS and/or WINS information, make sure that the DNSand/or WINS information on your DHCP server is set to the correct IP addresses.2 On your DHCP server’s configuration, make sure that you have designated an IPaddress space for Office Mode users (e.g., 10.130.56.0).3 Create a new node object by selecting Manage >Network objects >New >Node >Host,representing the DHCP server and specify the machine’s name, IP address andsubnet mask.4 Open the Gateway object through which the remote users will connect to theinternal network and select the Remote Access > Office Mode page. Enable OfficeMode to either all users or to a certain group.• Check the Automatic (use DHCP) option.• Select the DHCP object you have previously created.154

Office Mode — DHCP Configuration• In the Virtual IP address for DHCP server replies, specify an IP address from thesub network of the IP addresses which are designated for Office Mode usage(e.g. 10.130.56.254). Since Office Mode supports DHCP Relay method for IPassignment, you can direct the DHCP server as to where to send its replies. Therouting on the DHCP server and that of internal routers must be adjusted sothat packets from the DHCP server to this address are routed through thegateway.• Under Multiple Interfaces, specify whether you want routing to be done afterthe encapsulation of Office Mode packets, to allow traffic to be routed correctlywhen your gateway has multiple external interfaces.If you wish to use the Anti-Spoofing feature, continue to step 5, otherwise skip tostep 7.5 Create a network object to represent the address space you’ve allocated for OfficeMode on your DHCP server, by selecting Manage >Network Objects >New >Network.In the Network Properties — General tab, set the DHCP address range as follows:• In Network Address specify the first address that is used (e.g. 10.130.56.0).• In Net Mask enter the subnet mask according to the amount of addresses that isused (entering 255.255.255.0, for example, designates that all 254 IP addressesfrom 10.130.56.1 until 10.130.56.254 are set aside for SecureClient OfficeMode addresses on the DHCP server).• Changes to the Broadcast Address section and the Network Properties — NAT tabare not necessary.• Close the network object properties window.6 Return to the Gateway object, open the Remote Access > Office Mode page. In theAdditional IP addresses for Anti-Spoofing, select the network object you havecreated with the IP address range you have set aside for Office Mode on the DHCPserver.7 Install the policy.8 Make sure that all the internal routers are configured to route all the traffic destinedto the internal address space you had reserved to Office Mode users through theVPN-1 Pro Gateway. For instance, in the example above it is required to add routesto the class C sub network of 10.130.56.0 through the gateway’s IP address.Chapter 10 Office Mode 155

Configuring Office ModeIn addition to the steps mentioned for the gateway side configuration, a fewconfiguration steps have to be performed on the client side in order to connect to thegateway in Office mode. See Office Mode Configuration on the Client Side page 156.Note - Office Mode is supported only in Connect Mode.Office Mode Configuration on the Client SideOn the client’s machine the following steps should be performed in order to connect tothe gateway in Office mode:1 Right click the SecureClient icon in the system tray. From the pop-up menu, selectConfigure.2 Select Tools > Configure Connection Profile > Advanced and select Support OfficeMode.3 Click OK, Save and Close and then select Exit from your File menu.4 Double click your SecureClient icon on the bottom right side of your screen. Ifyou’re using a dial-up connection to connect to the gateway select Use Dial-up andchoose the name of your dial-up connection profile from the drop-down menu (itis assumed that such a profile already exists. If dial-up is not used (i.e. connection tothe gateway is done through a network interface card) proceed to step 5.5 Select Connect to connect to the organization using Office Mode.The administrator can simplify configuration, by configuring a profile in advance andproviding it to the user.156

CHAPTER11Resolving RemoteAccess ConnectivityIssuesIn This ChapterThe Need for Remote Access Connectivity Resolution Features page 157Check Point Solution for Connectivity Issues page 157Overcoming NAT Related Issues page 158Overcoming Restricted Internet Access page 165Configuring Remote Access Connectivity page 168The Need for Remote Access Connectivity ResolutionFeaturesWhile there are a few connectivity issues regarding VPN between Gateways, remoteaccess clients present a special challenge. Remote clients are, by their nature, mobile.During the morning they may be located within the network of a partner company, thefollowing evening connected to a hotel LAN or behind some type of enforcement orNATing device. Under these conditions, a number of connectivity issues can arise:• Issues involving NAT devices that do not support fragmentation.• Issues involving service/port filtering on the enforcement deviceCheck Point Solution for Connectivity IssuesCheck Point resolves NAT related connectivity issues with a number of features:• IKE over TCP• Small IKE phase II proposals157

Overcoming NAT Related Issues• UDP encapsulation• IPSec Path Maximum Transmission Unit (IPSec PMTU)Check Point resolves port filtering issues with Visitor Mode (formally: TCP Tunneling).Other Connectivity IssuesOther connectivity issues can arise, for example when a remote client receives an IPaddress that matches an IP on the internal network. Routing issues of this sort areresolved using Office mode. For more information see: “Office Mode””.Other issues, such as Domain Name Resolution involving DNS servers found on aninternal network protected by a Gateway, are resolved with Split DNS. For moreinformation on Split DNS see: “Remote Access Advanced Configuration”.”Overcoming NAT Related IssuesNAT related issues arise with hide NAT devices that do not support packetfragmentation.When a remote access client attempts to create a VPN tunnel with its peer Gateway,the IKE or IPSec packets may be larger than the Maximum Transmission Unit (MTU)value. If the resulting packets are greater than the MTU, the packets are fragmented atthe Data Link layer of the Operating System’s TCP/IP stack.Problems arise when the remote access client is behind a hide NAT device that doesnot support this kind of packet fragmentation:158

Other Connectivity IssuesFIGURE 11-1 UDP FragmentationHide NAT not only changes the IP header but also the port information contained inthe UDP header. In FIGURE 11-1, the UDP packet is too long so the remote clientfragments the packet. The first fragment consists of the IP header plus the UDP headerand some portion of the data. The second fragment consists of only the IP header andthe second data fragment. The NATing device does not know how to wait for all thefragments, reassemble and NAT them.When the first fragment arrives, the NAT device successfully translates the addressinformation in the IP header, and port information in the UDP header and forwardsthe packet. When the second fragment arrives, the NATing device cannot translate theport information because the second packet does not contain a UDP header; the packetis dropped. The IKE negotiation fails.Chapter 11 Resolving Remote Access Connectivity Issues 159

Overcoming NAT Related IssuesDuring IKE phase ITo understand why large UDP packets arise, we need to take a closer look at the firstphase of IKE. During IKE phase I, the remote access client and Gateway attempt toauthenticate each other. One way of authenticating is through the use of certificates. Ifthe certificate or Certificate Revocation List (CRL) is long, large UDP packets result,which are then fragmented by the operating system of the remote client.Note - If the VPN peers authenticate each other using pre-shared secrets, large UDP packetsare not created; however, certificates are more secure, and thus recommended.IKE Over TCPIKE over TCP solves the problem of large UDP packets created during IKE phase I.The IKE negotiation is performed using TCP packets. TCP packets are notfragmented; in the IP header of a TCP packet, the DF flag (“do not fragment”) isturned on. A full TCP session is opened between the peers for the IKE negotiationduring phase I.During IKE phase IIA remote access client does not have a policy regarding methods of encryption andintegrity. Remote access clients negotiate methods for encryption and integrity via aseries of proposals, and need to negotiate all possible combinations with the Gateway.This can lead to large UDP packets which are once again fragmented by the remoteclient’s OS before sending. The NAT device in front of the remote client drops thepacket that has no UDP header (containing port information). Again, the IKEnegotiation fails.Why not use IKE over TCP again, as in phase I?IKE over TCP solves the fragmentation problem of long packets, but in phase II thereare times when the Gateway needs to initiate the connection to the remote client.(Only the remote client initiates phase I, but either side can identify the need for aphase II renewal of keys; if the Gateway identifies the need, the Gateway initiates theconnection.)If the Gateway initiates the connection, the Gateway knows the IP address of theNATing device, but cannot supply a port number that translates to the remote clientbehind the NATing device. (The port number used during previous connections is onlytemporary, and can quickly change.) The NATing device cannot forward theconnection correctly for the remote client; the connection initiated by the Gatewayfails.160

During IPSecIt is possible to use IKE over TCP, but this demands a TCP connection to be alwaysopen; the open session reserves the socket on the Gateway, taking up valuable systemresources. The more reasonable solution is to keep open the port on the NATingdevice by sending UDP “keep alive” packets to the Gateway, and then performing IKEphase II in the usual way. However, there is still a need to shorten the UDP packets toprevent possible fragmentation.Small IKE Phase II ProposalsBoth Gateway and remote peer start the IKE negotiation by proposing a small numberof methods for encryption and integrity. The more common methods are included inthe small proposals.If proposals match between the remote client and the Gateway, the proposed methodsare used; if no match is found, a greater number of proposals are made. Usually a matchis found with the small proposals, and fragmentation is no longer an issue. However,there are cases where a match is not found, and a larger number of proposals need tobe made. (This will most likely happen in instances where the remote Gateway usesAES-128 for encryption, and AES-128 is not included in the small proposals.)A greater number of proposals can result in larger UDP packets. These larger packetsare once again fragmented at the Data Link Layer of the TCP/IP stack on the client,and then discarded by the hide NAT device that does not support fragmentation. In thecase of AES-128, this method of encryption can be included in the small proposals bydefining AES-128 as the preferred method.During IPSecNAT traversal (UDP Encapsulation for Firewalls and Proxies)Having successfully negotiated IKE phases I and II, we move into the IPSec stage. Datapayloads encrypted with (for example) 3DES and hashed (for integrity) with MD5, areplaced within an IPSec packet. However, this IPSec packet no longer contains a TCPor UDP header. A hide NAT device needs to translate the port information inside theheader. The TCP/UDP header has been encrypted along with the data payload and canno longer be read by the NATing device.A port number needs to be added; UDP Encapsulation is a process that adds a specialUDP header that contains readable port information to the IPSec packet:Chapter 11 Resolving Remote Access Connectivity Issues 161

Overcoming NAT Related IssuesFIGURE 11-2 UDP Encapsulation:The new port information is not the same as the original. The port number 2746 isincluded in both the source and destination ports. The NAT device uses the sourceport for the hide operation but the destination address and port number remains thesame. When the peer Gateway sees 2746 as the port number in the destination address,the Gateway calls a routine to decapsulate the packet.IPSec Path Maximum Transmission UnitsIPSec Path MTU is a way of dealing with IPSec packet fragmentation. The Data Linklayer imposes an upper limit on the size of the packets that can be sent across thephysical network, the Maximum Transmission Unit, or MTU. Before sending a packet,the TCP/IP stack of the operating system queries the local interface to obtain its MTU.The IP layer of the TCP/IP stack compares the MTU of the local interface with thesize of the packet and fragments the packet if necessary.When a remote client is communicating across multiple routers with a Gateway, it isthe smallest MTU of all the routers that is important; this is the path MTU (PMTU),and for remote access clients there is a special IPSec PMTU discovery mechanism toprevent the OS of the client from fragmenting the IPSec packet if the IPSec packet istoo large.However, the PMTU between the remote client and the Gateway will not remainconstant, since routing across the Internet is dynamic. The route from Gateway toclient may not be the same in both directions, hence each direction may have its ownPMTU. VPN-1 handles this in two ways:• Active IPSec PMTU• Passive IPSec PMTU162

During IPSecActive IPSec PMTUAfter IKE phase II but before the IPSec stage, the remote access client sends specialdiscovery IPSec packets of various sizes to the Gateway. The DF (do not fragment) biton the packet is set. If a packet is longer than any router’s MTU, the router drops thepacket and sends an ICMP error message to the remote client. From the largest packetnot fragmented, the remote client resolves an appropriate PMTU. This PMTU is notconveyed directly to the OS. Unknown to the operating system, during the TCPthree-way handshake, the Maximum Segment Size (MSS) on the SYN and SYN-ACKpackets are changed to reflect the PMTU. This is known as Active IPSec PMTU.FIGURE 11-3 IPSec discover packetsPassive IPSec PMTUPassive IPSec PMTU solves the problem of dynamic Internet routing. Passive IPSecPTMU is a process that occurs when either side receives an ICMP error messageresulting from a change in the routing path. Since routes change dynamically on theInternet, if a different router needs to fragment the packet that has the DF bit set, therouter discards the packet and generates an ICMP “cannot fragment” error message.The error message is sent to the VPN peer that sent the packet. When the peer receivesthis error message, the peer decreases the PMTU and retransmits.Note - From the system administrator’s perspective, there is nothing to configure for PMTU;the IPSec PMTU discovery mechanism, both active and passive, runs automatically.Chapter 11 Resolving Remote Access Connectivity Issues 163

Overcoming NAT Related IssuesNAT and Load Sharing ClustersIn FIGURE 11-4, the remote client is behind a NATing device and connecting to aload-sharing cluster:FIGURE 11-4 NAT & Load Sharing ClustersFor the connection to survive a failover between cluster members, the “keep alive”feature must be enabled in Global Properties > Remote Access > Enable Back connectionsfrom gateway to clientThis is also true if the NATing is performed on the Gateway cluster side.164

Visitor ModeOvercoming Restricted Internet AccessWhen a user connects to the organization from a remote location such as hotel or theoffices of a customer, Internet connectivity may be limited to web browsing using thestandard ports designated for HTTP, typically port 80 for HTTP and port 443 forHTTPS. Since the remote client needs to perform an IKE negotiation on port 500 orsend IPSec packets (which are not the expected TCP packets; IPSec is a differentprotocol), a VPN tunnel cannot be established in the usual way. This issue is resolvedusing Visitor Mode, formally known as TCP Tunneling.Visitor ModeVisitor Mode tunnels all client-to-Gateway communication through a regular TCPconnection on port 443.FIGURE 11-5 Visitor ModeAll required VPN connectivity (IKE, IPsec, etc.) between the Client and the Server istunneled inside this TCP connection. This means that the peer Gateway needs to run aVisitor Mode (TCP) server on port 443.Note -• Even if the remote location’s Gateway in FIGURE 11-5 is not a Check Pointproduct (a Gateway from another vendor) Visitor mode will still tunnel aconnection through it.• While in Visitor Mode, you can not define a new site.• Topology update takes place only if the last connection used a profile thatenabled Visitor Mode.Chapter 11 Resolving Remote Access Connectivity Issues 165

Overcoming Restricted Internet AccessNumber of UsersTo obtain optimal performance of the Visitor Mode server:• Minimize the number of users allowed Visitor Mode if performance degrades• Increase the number of sockets available on the OS by editing the appropriatevalues, for example the socket descriptor on Linux systemsAllocating Customized PortsThe organization decides that it would like to use a customized port for the VisitorMode Server other than the typically designated port 443. In this scenario, another portthat is mutually agreed upon by all the remote locations and the home organization, canbe used for Visitor Mode. This solution works well with business partners; the partnersimply agrees to open a port for the visitor Mode connections. If the chosen port is notrepresented by a pre-defined service in SmartDashboard, this service must be created inorder for the port to be used. If a port has been mutually agreed upon, and there is aproxy, configure the proxy to allow traffic destined to this port.Note - All partner Gateways must agree on the same allocated port, since the visitor Modeserver on the peer Gateway will be listening on only one port.Visitor Mode and Proxy ServersVisitor Mode can still be utilized in instances where the remote location runs a proxyserver. In this scenario, the remote user enables Visitor Mode connections to passthrough the proxy server.FIGURE 11-6 Incorporating a Proxy Server166

Visitor ModeVisitor Mode When the Port 443 is Occupied By an HTTPS ServerIf the designated port is already in use, for example reserved for HTTPS connections bya Server at the organization’s Gateway, a log is sent “Visitor Mode Server failed to bindto xxx.xxx.xxx.xxx:yy (either port was already taken or the IP address does not exist)” toSmartCenter Server.If the peer Gateway is already running a regular HTTP server that also listens on thestandard HTTPS port 443, then it must be set up with two external interfaces, both ofwhich have public IP addresses — one for the HTTP server, and one for the VisitorMode server. This second routable address can be achieved in two ways:• installing an additional network interface for the Visitor Mode server, or• by utilizing a virtual IP on the same network interface which is blocking the port.On the Gateway object running the Visitor Mode server, General Properties > RemoteAccess page > there is a setting for Allocated IP address. All the available IP addressescan be configured to listen on port 443 for Visitor Mode connections.Visitor Mode with SecurePlatform/NokiaSecurePlatform running on Linux and Nokia boxes are installed with a pre-configuredHTTPS server; the server runs on the Gateway and listens on port 443. Installing anadditional network interface or utilizing a virtual IP for the Visitor Mode server is notrelevant since these HTTPS servers automatically bind to all available IP addresses.In this case, it is preferable to reserve 443 for Visitor Mode, since users connecting, forexample, from a hotel, may only be allowed to connect via ports 80 and 443. Thesepre-configured HTTPS servers need to be allocated ports that do not conflict with theVisitor Mode server.Visitor Mode in a MEPed EnvironmentVisitor Mode also works in a MEPed environment. For more information, see: “VisitorMode and MEP” on page 267.Interface ResolutionFor interface resolution in a Visitor Mode environment, it is recommended to use static IPresolution or dedicate a single interface for Visitor Mode. For more informationregarding IP resolution, see: “IP Resolution in VPN”.Note - Visitor mode is only supported for Internet Explorer 4.0 and up.Chapter 11 Resolving Remote Access Connectivity Issues 167

Configuring Remote Access ConnectivityConfiguring Remote Access ConnectivityIn this Section:Configuring IKE Over TCP page 168Configuring Small IKE phase II Proposals page 168Configuring NAT Traversal (UDP Encapsulation) page 169Configuring Visitor Mode page 169Configuring Remote Clients to Work with Proxy Servers page 171Configuring IKE Over TCP1 For the Gateway, open Global Properties > Remote Access page > VPN-Basicsub-page > IKE over TCP section. Select Gateways support IKE over TCP.2 Enable IKE over TCP in a connection profile; the remote user works in connectmode to automatically receive the profile. To configure:A From the file menu, Manage > Remote Access > Connection profiles... theConnection Profiles window opens. Click New...B Connection Profile Properties window opens. On the Advanced tab, selectSupport IKE over TCP.If the user is not working in connect mode, the user has to manually enable IKE overTCP on the client. On the client’s file menu, Tools > Advanced IKE Settings, selectSupport IKE over TCP.When IKE over TCP is enabled on the Gateway, the Gateway continues to support IKEover UDP as well. For remote clients, IKE over TCP is supported only for as long asthe client works with a profile that enables IKE over TCP.Configuring Small IKE phase II ProposalsSmall phase II IKE proposals always include AES-256, but not AES-128. Suppose youwant to include AES-128 in the small proposals:1 Open the command line database editing tool dbedit. There are two propertiesthat control whether small proposals are used or not, one for pre-NG withApplication Intelligence, the other for NG with Application Intelligence.• phase2_proposal - determines whether an old client (pre-NG with ApplicationIntelligence) will try small proposals - default “false”.• phase2_proposal_size - determines whether a new client (for NG withApplication Intelligence) will try small proposals - default “true”.168

Configuring NAT Traversal (UDP Encapsulation)2 In Global Properties > Remote Access page > VPN -Advanced subpage > UserEncryption Properties section, select AES-128. This configures remote users to offerAES-128 as a small proposal.Configuring NAT Traversal (UDP Encapsulation)On the Gateway network object, enable UDP encapsulation, and decide on a port tohandle UDP encapsulation:1 General Properties > Remote Access page > NAT Traversal section, select SupportNAT traversal mechanism (UDP encapsulation).2 From the Allocated port drop-down box, select a port. VPN1_IPSec_encapsulation isthe default.3 IKE phase II proposals are offered both with and without UDP encapsulation whendealing with remote access. (There is no UDP encapsulation between Gateways).There is no need to enable UDP on the client unless you want to shorten theexisting small IKE phase II proposals. Enable UDP encapsulation in a connectionprofile; the remote user works in connect mode to automatically receive the profile.To configure:A From the file menu, Manage > Remote Access > Connection profiles... theConnection Profiles window opens. Click New...B Connection Profile Properties window opens. On the Advanced tab, selectForce UDP Encapsulation.If the user is not working in connect mode, the user has to manually enable UDPEncapsulation on the client. On the client’s file menu, Tools > Advanced IKE Settings,select Force UDP Encapsulation.Selecting UDP encapsulation on the Gateway means that the Gateway supports bothencapsulated VPN traffic and traffic that is not encapsulated.Note - Microsoft L2TP IPSec clients cannot work with Check Point gateways when UDPencapsulation is required.Configuring Visitor ModeVisitor Mode requires the configuration of both the Server and the Client. See also:“Visitor Mode and MEP” on page 267Chapter 11 Resolving Remote Access Connectivity Issues 169

Configuring Remote Access ConnectivityServer ConfigurationTo enable the TCP tunnelling feature on VPN-1 Pro:On the Gateway object running the Visitor Mode Server, Remote Access page > VisitorMode section, select Support Visitor Mode.• If port 443 is the assigned port for TCPT server, do not change the tcp httpsdefault in the Allocated Port section.• If a customized port (other than the default port) is agreed upon, from thedrop-down menu select the service that corresponds to this port. If the chosen portis not represented by a pre-defined service in SmartDashboard, create this service.• In Allocated IP Address the default is All IPs. To avoid port conflicts, select theappropriate routable valid IP for the Visitor Mode server. If the server has DynamicInterface Resolving Configuration... enabled (on the VPN - Advanced page) it isrecommended to allocate a specific address for visitor mode instead of All IPs.Note - When Visitor Mode is activated on the Gateway, the RDP interface discoverymechanism does not work. A Visitor Mode handshake is used instead.These settings configure a Visitor Mode server to run on the Gateway.Visitor Mode and Gateway ClustersCluster support is limited. The high availability and Load Sharing solutions mustprovide “stickiness”. That is, the visitor mode connection must always go through thesame cluster member.Failover from cluster member to cluster member in a High Availability scenario is notsupported.Enabling Visitor Mode Using a Connection ProfileCreate a customized connection profile for Visitor Mode users. This profile enables theVisitor Mode feature on the Client side. To create the profile:1 In SmartDashboard, Manage > Remote Access > Connection profiles... theConnection Profiles window opens.2 Click New... to create a new connection profile or Edit... to alter an existing profile.The Connection Profile Properties window opens.3 On the Advanced tab, select Visitor Mode.On the remote client, configure the user to work in connect mode.170

Configuring Remote Clients to Work with Proxy ServersConfiguring Remote Clients to Work with Proxy Servers1 In SecureClient, select Detect Proxy from Internet Explorer SettingsIn previous versions, the proxy had to be manually defined.2 Provide a username and password for proxy authentication. This information islatter transferred with the “connect” command to the proxy server.FIGURE 11-7 Proxy settings in Internet ExplorerNow Secure Client can read any of the settings shown in FIGURE 11-7 but only if:• SecureClient is connected to a LAN or WLAN (not dial-up)Chapter 11 Resolving Remote Access Connectivity Issues 171

Configuring Remote Access Connectivity• Secure Domain Logon (SDL) is not enabled.Note - Visitor mode attempts to connect to the proxy server without authenticating. If a username and password is required by the proxy, the error message “proxy requiresauthentication appears”.Windows Proxy ReplacementIf SecureClient is on a LAN\WLAN and a proxy server is configured on the LAN,SecureClient replaces the proxy settings so that new connections are not sent to theVPN domain via the proxy but go directly to the LAN\WLAN’s Gateway. This featureworks with and without Visitor Mode. SecureClient must be on a WAN\WLAN andnot using a dial-up connection.When SC replaces the proxy file, it generates a similar plain script PAC file containingthe entire VPN domain IP ranges and DNS names (to be returned as “DIRECT”).This file is stored locally, since the windows OS must receive this information as a plainscript PAC file. This file replaces the automatic configuration script as defined inInternet Explorer:Special Considerations for Windows Proxy ReplacementSensitive information regarding the site’s IP Address and DNS settings are contained inSecureClient’s userc.C file. For this reason, the file is obfuscated by an algorithm thathides the real content (but does not encrypt it). When the proxy replacement feature isused, the same information is written to the plain text PAC file. For this reason,administrators should be aware that the Windows Proxy Replacement feature exposesthe VPN domain by writing Site IP addresses and DNS settings as Java Script code inthis plain text PAC file, which can be viewed by any end user.172

Configuring Remote Clients to Work with Proxy ServersConfiguring windows Proxy ReplacementWindows proxy replacement is configured either on the Gateway or SecureClientClient.On the Gateway1 Global Properties > SmartDashboard Customization2 Click ConfigureThe Advanced Configuration window opens:3 Select either:• ie_proxy_replacement. If option is selected, windows proxy replacement is alwaysperformed, even if visitor mode is not enabled.• ie_proxy_replacement_limit_to_tcpt. If this option is selected, then proxyreplacement takes place only when visitor mode is enabled.When SecureClient performs an update, the policy regarding windows proxyreplacement is downloaded and put into effect.On SecureClientAlternatively, these two properties can be set in the userc.c file on the remote client::ie_proxy_replacement (true):ie_proxy_replacement_limit_to_tcpt (true)Chapter 11 Resolving Remote Access Connectivity Issues 173

Configuring Remote Access Connectivity174

CHAPTER12Clientless VPNIn This ChapterThe Need for Clientless VPN page 175The Check Point Solution for Clientless VPN page 176Special considerations for Clientless VPN page 178Configuring Clientless VPN page 179The Need for Clientless VPNWhile VPN-1 and SecuRemote technologies provide a comprehensive solution to theproblem of securing and protecting data, there are instances where the administratorneeds to enable secure communication with client machines that are not configured forVPN. For example, an employee might unexpectedly need to log into the companymail server from an Internet cafe. The employee cannot install software on the browseror even configure it, yet the connection to the company mail server must still be secure,and the employee must have some means of authentication.Consider a software company wishing to provide its beta sites with access to bugtracking software via a web server. The beta peers do not employ VPN technology. Theconnection must be secure and the beta users must be authenticated.Another scenario: an e-commerce company is suffering attacks over the Internet. Thecompany needs to be able to monitor incoming packets for harmful content, yet packetsin a standard SSL-based connection passing directly between client and server areencrypted. The administrator must both secure this connection and make the packetsavailable for monitoring.The common factor in these scenarios is that a secure connection must be established ina situation where VPN technology is not available on the client side. A solution isrequired that:175

The Check Point Solution for Clientless VPN• Supports secure connections• Does not involve installation or configuration of software on the client side• Allows users to be authenticated• Allows packets to be inspected by the GatewayThe Check Point Solution for Clientless VPNSecuring connections when VPN technology is not available to the client (and softwarecan be neither installed or configured on the client side) is accomplished through theuse of Clientless VPN. Clientless VPN provides secure SSL-based communicationbetween clients and servers that support HTTPS. In addition:• The Gateway accepts any encryption method that is proposed by the client andsupported in VPN-1• The Gateway can enforce the use of strong encryption, for example 3DES• Clientless VPN supports user authenticationHow it worksClientless VPN connections can be broken down into two clear phases:• Establishing a Secure Channel• Communication PhaseEstablishing a Secure ChannelA secure connection is established in the following way:1 The client’s browser makes an HTTPS request to the web server.2 The request reaches the VPN-1 Pro Gateway.3 The VPN-1 Pro Gateway checks the Security Policy to see if the connectionmatches a rule for HTTPS.4 If a rule is matched, and Clientless VPN is enabled on the gateway, the Gatewaydiverts the connection to the Clientless VPN Security Server.Clientless VPN makes use of a special Security Server on the Gateway. TheClientless VPN Security Server is a daemon process invoked by the Gateway tohandle Clientless VPN connections. Once invoked, the Clientless VPN SecurityServer continues to run as a background process.5 SSL negotiation takes place between the client and the VPN-1 Pro Gateway, duringwhich the Gateway authenticates itself to the client. The Gateway uses a certificatesigned by a Certificate Authority that the client trusts.176

How it works6 A secure channel is established between the VPN-1 Pro Gateway and the client.Communication PhaseIn FIGURE 12-1, the VPN Security Server opens a connection to the web server. Theclient connects to the server via the VPN-1 Pro Gateway. From now on, allconnections from the client to the VPN-1 Pro Gateway are encrypted. Every packet issent encrypted to the Gateway. The Gateway decrypts the packets and forward thepackets “in clear” to the web server. From the client’s perspective, the client and webserver appear to be communicating directly, but in fact the SSL secure channelterminates at the gateway.FIGURE 12-1 Communication phaseContent Security with Clientless VPNSince the VPN-1 Pro Gateway now sees the packet in clear, the packet can be inspectedfor content, if content security is required.User AuthenticationUsers can authenticate if this is required. Consider the example the employee needingto read company email from an Internet cafe. Typically:1 The user is presented with a pop-up window requesting a user name and password.2 The user supplies login details.3 The Gateway verifies the user name and authenticates the password.Alternatively, the user can authenticate through the use of certificates.Chapter 12 Clientless VPN 177

Special considerations for Clientless VPNUser certificatesClientless VPN supports the use of certificates for user authentication. The client’scertificate is validated during the SSL phase. In addition, the client’s identificationdetails are extracted from the certificate and then processed during the userauthentication phase. In this way, the user does not have to enter a user name andpassword or keep authenticating on each connection. Authentication is handled throughthe certificates.Special considerations for Clientless VPNThere are a number of considerations for Clientless VPN:• Which certificate does the Gateway present?• How many Security Servers should be run?• What level of encryption is required?Certificate Presented by the GatewayThis consideration is related to the certificate the Gateway presents to the client inorder to authenticate itself during the SSL negotiation. The easiest option, from theclient side, is for the Gateway to present to the client a certificate signed by a CA thatthe client is configured to trust by default, for example a certificate supplied by Verisign.This requires no configuration on the client side. But if the company has a policy thatrequires a much higher level of security, it might be preferable for the certificate tocome from a CA owned by the company itself.If the administrator decides to use a certificate from the internal CA (known andtrusted) the CA certificate must be supplied to the client and the client configured totrust it. If the administrator decides to work with an external Certificate Authority, theadministrator must:1 Obtain the CA certificate.2 Configure the SmartCenter Server to trust this CA.3 Obtain and configure a certificate for the Gateway.4 Supply the CA certificate to the client.The administrator must now instruct the user to configure the client to trust this CA.178

Number of Security Servers to RunNumber of Security Servers to RunIn order to balance the load when there are many Clientless VPN connections, theadministrator will have to decide how many Security Servers to run. Up to ten SecurityServers can be run on the same gateway. Check Point recommends running one VPNSecurity Server per 150 active users. Be careful not to confuse active users with allregistered users. For example, if you have 700 registered Clientless VPN users in thedatabase yet only an average of 70 users make Clientless VPN connections concurrently,run only one Security Server.Level of EncryptionWhile the Gateway can be configured to enforce the use of strong encryption such as3DES, the use of 3DES can affect performance of the Gateway machine. The clientbrowser must also support 3DES.Configuring Clientless VPNFor the most part, Clientless VPN is configured on the Gateway. Exceptions occurwhen:• The Gateway authenticates itself to the client using a certificate which is not one ofthe client’s default certificates.• User authentication is required, and that authentication is done through the use ofcertificates.In both cases, the relevant certificates must be supplied to the client out of band and theclient configured to work with them.Configuring the GatewayGeneral OverviewTo configure the Gateway for Clientless VPN:• Obtain a certificate for the Gateway; this is the certificate the Gateway uses toauthenticate itself to the client during the initial connection.• Configure the Gateway for Clientless VPN on the Clientless VPN page of theGateway object.• Define users and user authentication schemes.• Create appropriate rules in the Security Policy Rule Base.Chapter 12 Clientless VPN 179

Configuring Clientless VPNImplementationObtaining a Certificate for the GatewayIf you decide to use a certificate issued by an external Certificate Authority instead ofthe certificate issued by the internal CA:• Configure VPN-1 Pro to trust this CA• Obtain and configure a certificate for the GatewayFor more information, refer to Third Party PKI.Configuring Clientless VPN on the Gateway ObjectOn the Clientless VPN page of the gateway object’s property window:1 Select Support Clientless VPN.2 Select a Certificate for gateway authentication.3 Select an option for Client authentication:• Select Require the client to present a certificate if user authentication is requiredand that authentication is performed through the use of certificates.• Select Ask the client to present a certificate if user authentication is required butyou know that not all of the Clientless VPN users have certificates, and thatsome are authenticating in other ways.• Select Do not ask the client to present a certificate if user authentication throughcertificates is not required or performed through other means.4 Number of concurrent servers/processes refers to the number of VPN SecurityServers to run. Depending on the load, the administrator can run more than oneSecurity Server.See the section on “Number of Security Servers to Run” on page 179.5 Accept 3DES for Clientless VPN connections when strong encryption must beenforced.Defining UsersIf user authentication is required:1 Define users, either in the internal database or external LDAP server.For more information, refer to the SmartCenter User Guide.2 Enable authentication methods by:• Configuring the Gateway to support the required authentication methods180

Configuring the Gateway• Configuring the appropriate authentication methods for users, for example username/password or through the use of certificates.If the user authenticates through certificates, obtain the certificate from therelevant CA and supply the user with the certificate. If the certificate is acertificate issued by the Internal CA, refer to VPN for Remote clients on how toissue these certificates.• Configuring authentication servers, such as Radius, if authentication servers areemployed.Refer to: Authentication in the FireWall-1 and SmartDefense book.Creating Appropriate Rules in the Security Policy Rule BaseA requirement of Clientless VPN is that, for every connection, the Security Servermust be employed. This fact influences how rules allowing Clientless VPN are createdin the Security Policy Rule Base.For no User AuthenticationIf user authentication is not required, a rule must be defined that implements the URIresource. For example:Source Destination Service ActionAny Web server HTTPS - URI resource AcceptThe rules states that when any source attempts an HTTPS connection to the webserver the connection is accepted. A “URI resource” is required in order to force theSecurity Server to be employed on every connection, as required by Clientless VPN.For more information on defining URI resources refer to Content Security in theFireWall-1 Guide.For User AuthenticationIn the Security Policy Rule base, define a rule for either Client authentication or Userauthentication:Source Destination Service ActionAny Web server HTTPS User AuthThe rule states that when any source tries to connect to the web server using HTTPS,then user authentication must be performed. Select User Auth as the action if you needusers to be authenticated but no content security performed on incoming packets (Fora detailed explanation of User authentication see: authentication in Check Point FireWall-1and SmartDefense)Chapter 12 Clientless VPN 181

Configuring Clientless VPNAlternatively:Source Destination Service ActionAny Web server HTTPS - URI resource Client AuthThe rule states that when any source tries to connect to the web server using HTTPS,then client authentication must be performed. Select Client Auth as the action if usersneed to be authenticated and incoming packets inspected for content. (For a detailedexplanation of Client authentication see: authentication in the FireWall-1 Guide.)Configuring the ClientIf one of the following conditions are true:• The Security Server authenticates itself to the client using a certificate which is notsigned by one of the client’s default Certificate Authorities or• If user authentication is required, and that authentication is performed viacertificates.then these certificates must be supplied to the client out of band, and the client’sbrowser configured to use them. Otherwise, no configuration needs to be performedon the client side.Configuring the Client’s BrowserThe certificate can be installed on the client’s browser in two ways:1 The client receives the certificate on a diskette.2 The client right-clicks the certificate, selects “Install Certificate”.Alternatively:1 The client inserts the diskette containing the certificate.2 The client opens the browser.3 From Tools >Internet options > select Contents tab.4 Click certificates.5 Click Import.The Certificate Import Wizard opens.6 Import the Certificate from the diskette.182

CHAPTER13Third Party RemoteAccess ClientsIn This ChapterThe Need for Third Party IPSec Clients page 183Solution - Working with Third Party IPSec Clients page 183Considerations for Choosing Microsoft IPSec/L2TP Clients page 188Configuring Remote Access for Microsoft IPSec/L2TP Clients page 188The Need for Third Party IPSec ClientsFor some organizations there are clear benefits to be gained by using the MicrosoftIPSec client for remote access to internal network, rather than the more feature richand secure Check Point SecuRemote/SecureClient.Reasons for using the Microsoft L2TP IPSec client include the fact that is an inherentpart of the Windows 2000 and Windows XP operating systems, does not requires anadditional client to be installed, and is free.Solution - Working with Third Party IPSec ClientsIn This SectionIntroduction to Third Party IPSec Clients page 184Establishing a VPN between a Microsoft IPSec/L2TP client and a Check PointGateway page 184Behavior of an L2TP Connection page 185183

Solution - Working with Third Party IPSec ClientsVPN-1 Pro Gateway Requirements for IPSec/L2TP page 186Authentication of Users and Client Machines page 186User Certificate Purposes page 187Introduction to Third Party IPSec ClientsCheck Point VPN-1 Pro Gateways can create VPNs with a number of third party IPSecclients. This explanation focuses on the Microsoft IPSec/L2TP client.You can access a private network through the Internet by using a virtual privatenetwork (VPN) connection with the Layer Two Tunneling Protocol (L2TP). L2TP isan industry-standard Internet tunneling protocol.Check Point supports the Microsoft IPSec/L2TP client on Windows 2000 andWindows XP machines. The client is an integral part of the Windows operating system.Creating a Remote Access environment for users with Microsoft IPSec/L2TP clients isbased on the same principles as those used for setting up Remote Access forSecuRemote/SecureClients. It is highly recommended to read and understandChapter 9, “VPN for Remote Clients” before attempting to configure Remote Accessfor Microsoft IPSec/L2TP clients.Establishing a VPN between a Microsoft IPSec/L2TP client anda Check Point GatewayTo allow the user at the Microsoft IPSec/L2TP client to access a network resourceprotected by a VPN-1 Gateway, a VPN tunnel is established between the MicrosoftIPSec/L2TP client and the Gateway, as shown in FIGURE 13-1.FIGURE 13-1 IPSec Client to Check Point Gateway Connection184

Behavior of an L2TP ConnectionThe process of the VPN establishment is transparent to the user, and works as follows:1 A user at an Microsoft IPSec/L2TP client initiates a connection to a VPN-1Gateway.2 The Microsoft IPSec/L2TP client starts an IKE (Internet Key Exchange)negotiation with the peer Gateway in order to initiate construction of an encryptedtunnel.3 During IKE negotiation, the identities of the remote client machine and theVPN-1 Gateway are authenticated. This authentication is performed by means ofcertificates. Both sides send their certificates to each other as means of proving theiridentity. This ensures that a connection can be made only from the authenticatedmachine.4 Both peers exchange encryption keys, and the IKE negotiation ends.5 Encryption is now established between the client and the gateway. All connectionsbetween the client and the gateway are encrypted inside this VPN tunnel, using theIPSec standard.6 The Client starts a short L2TP negotiation, at the end of which the client can passto the Gateway L2TP frames that are IPSec encrypted and encapsulated.7 The VPN-1 Gateway now authenticates the user at the Microsoft IPSec/L2TPclient. This authentication is in addition to the client machine authentication instep 3. This identification can happen via two methods.• A Certificate• An MD5 challenge, whereby the user is asked to enter a username and apassword (pre-shared secret)8 The VPN-1 Gateway allocates to the remote client an Office Mode IP address tomake the client routable to the internal network. The address can be allocated froman IP Pool, or from a DHCP server.9 The Microsoft IPSec/L2TP client connects to the Gateway, and can browse andconnect to locations in the internal network.Behavior of an L2TP ConnectionWhen using an IPSec/L2TP client, it is not possible to connect to organization and tothe outside world at the same time.Chapter 13 Third Party Remote Access Clients 185

Solution - Working with Third Party IPSec ClientsThis is because when the client is connected to the gateway, all traffic that leaves theclient is sent to the gateway, and is encrypted, whether or not it is intended to reach theprotected network behind the gateway. The gateway then drops all encrypted traffic thatis not destined for the encryption domain of the gateway.VPN-1 Pro Gateway Requirements for IPSec/L2TPIn order to use Microsoft IPSec/L2TP clients, the VPN-1 Pro Gateway must be set upfor remote access. The setup is very similar to that required for remote access usingSecuRemote/SecureClient, and involves creating a Remote Access community thatincludes the VPN-1 Pro Gateway(s) and the user groups.An additional requirement is to configure the VPN-1 Gateway to supply addresses tothe clients by means of the Office Mode feature.Authentication of Users and Client MachinesDuring the process of establishing the L2TP connection, two sets of authentication areperformed. First, the client machine and the VPN-1 Pro Gateway authenticate each other’sidentity using certificates. Then, the user at the client machine and the VPN-1 ProGateway authenticate each other using either certificates or a pre-shared secret.The Microsoft IPSec/L2TP client keeps separate certificates for IKE authentication ofthe client machine, and for user authentication.On the VPN-1 Pro Gateway, if certificates are used for user authentication, then theVPN-1 Gateway can use either the same certificate or different certificates for userauthentication and for the IKE authentication.Certificates for both clients and users can be issued by the same CA or a different CA.The users and the client machines are defined separately as users in SmartDashboard.Certificates can be issued by:• The Internal Certificate Authority (ICA) on the SmartCenter Server, or• An OPSEC certified Certificate Authority.The certificates must use the PKCS#12 format, which is a portable format for storingor transporting private keys and certificates. The certificates are transferred to andstored on the client machine.Authenticating the Client Machine During IKEThe Microsoft IPSec/L2TP client machine needs a certificate to authenticate itself tothe VPN-1 Gateway during IKE negotiation.186

User Certificate PurposesIt is recommended to generate a certificate for every client machine. It is possible tohave only one certificate for all client machines, but you will then not be able toidentify the machine that the user logged on from. For example, SmartView Trackerwould show “user=bob, machine=generic_laptop” rather than “user=bob,machine=bob_laptop”. This is bad practice. Instead: Provide a different machine certificatefor every client machine.The client machine administrator must install the certificate in the machine certificatestore.Authenticating the UserConnecting with Microsoft IPSec/L2TP clients requires that every user beauthenticated. Users can be authenticated with:• certificates, or• using an MD5 challenge, whereby the user is asked to enter a username and apassword (pre-shared secret). The user must be informed of the password“out-of-band”The user certificate can be easily added to the user certificate store. If the usercertificate is on a Smart Card, plugging it into the client machine will automaticallyplace the certificate into the certificate store.User Certificate PurposesIt is possible to make sure that PKI certificates are used only for a defined purpose. Acertificate can have one or more purposes, such as “client authentication”, “serverauthentication”, “IPSec” and “email signing”. Purposes appear in the Extended KeyUsage extension in the certificate.The certificates used for IKE authentication do not need any purposes. For the userauthentication, the Microsoft IPSec/L2TP client requires that• The user certificate must have the “client authentication” purpose.• The gateway certificate must have the “server authentication” purpose.Most CAs (including the ICA) do not specify such purposes by default. This means thatthe CA that issues certificates for IPSec/L2TP clients must be configured to issuecertificates with the appropriate purposes (in the Extended Key Usage extension).It is possible to configure the ICA on the SmartCenter Server so that the certificates itissues will have these purposes. For OPSEC certified CAs, it is possible to configure theSmartCenter Server to create a certificate request that includes purposes (in theExtended Key Usage extension).Chapter 13 Third Party Remote Access Clients 187

Considerations for Choosing Microsoft IPSec/L2TP ClientsIt is also possible to configure the Microsoft IPSec/L2TP clients so that they do notvalidate the gateway’s certificate during the L2TP negotiation. This is not a securityproblem because the client has already verified the gateway certificate during IKEnegotiation.Considerations for Choosing Microsoft IPSec/L2TPClientsSecureClient is much more than a personal firewall. It is a complete desktop securitysolution that allows the administrator to define a full desktop security policy for theclient. IPSec clients are more basic remote clients, and for some organizations mayprovide an adequate set of capabilities.When using an IPSec/L2TP client, it is not possible to connect to organization and tothe outside world at the same time. For some organizations, this may be an appropriateconnection policy as it effectively dedicates the machine to being connected to theorganization. SecuRemote/SecureClient on the other hand, makes it possible to beconnected to the organization and to the internet at the same time.Configuring Remote Access for Microsoft IPSec/L2TPClientsIn This SectionGeneral Configuration Procedure page 189Configuring a Remote Access Environment page 189Defining the Client Machines and their Certificates page 189Configuring Office Mode and L2TP Support page 189Preparing the Client Machines page 190Placing the Client Certificate in the Machine Certificate Store page 190Placing the User Certificate in the User Certificate Store page 191Setting up the Microsoft IPSec/L2TP client Connection Profile page 191Configuring User Certificate Purposes page 192Making the L2TP Connection page 193For More Information... page 193188

General Configuration ProcedureGeneral Configuration ProcedureEstablishing a Remote Access VPN for Microsoft IPSec/L2TP clients requiresconfiguration to be performed both on the VPN-1 Pro Gateway and on the clientmachine. The configuration is the same as setting up Remote Access forSecuRemote/SecureClients, with a few additional steps. It is highly recommended toread and understand Chapter 9, “VPN for Remote Clients” before configuringRemote Access for Microsoft IPSec/L2TP clients.The general procedure is as follows:1 Using SmartDashboard, configure a Remote Access environment, includinggenerating authentication credentials (normally certificates) for the users.2 Generate certificates to authenticate the client machines.3 Configure support for Office Mode and L2TP on the VPN-1 Pro Gateway.4 On the client machine, place the user certificate in the User Certificate Store, andthe client machine certificate in the Machine Certificate Store.5 On the client machine, set up the Microsoft IPSec/L2TP client connection profile.Configuration details are described in the following sections.Configuring a Remote Access Environment1 Follow the instructions in “Remote Access Configuration” on page 129.Defining the Client Machines and their Certificates2 Define a user that corresponds to each client machine, or one user for all machines,and generate a certificate for each client machine user. The steps are the same asthose required to define users and their certificate (see “Remote AccessConfiguration” on page 129).3 Add users that correspond to the client machines to a user group, and add the usergroup to the Remote Access VPN community.Configuring Office Mode and L2TP Support4 Configure Office Mode. For detailed instructions, see “Configuring Office Mode”on page 150.5 In the Gateway object, Remote Access page, check Support L2TP.6 Select the Authentication Method for the users:Chapter 13 Third Party Remote Access Clients 189

Configuring Remote Access for Microsoft IPSec/L2TP Clients• To use certificates, choose Smart Card or other Certificates (encryption enabled).• To use a username and a shared secret (password), choose MD5-challenge.7 For Use this certificate, select the certificate that the gateway presents in order toauthenticate itself to users. This certificate is used if certificates are the chosenAuthentication Method for users, in step 6.Preparing the Client Machines1 In the Windows Services window of the client machine, make sure that the IPSecPolicy Agent is running. It should preferably be set to Automatic.2 Make sure that no other IPSec Client (such as SecuRemote/SecureClient) isinstalled on the machine.Placing the Client Certificate in the Machine Certificate Store3 Log in to the client machine with administrator permissions.4 Run the Microsoft Management Console. Click Start > Run5 Type: MMC, and press Enter.6 Select Console >Add/Remove Snap-In.7 In the Standalone tab, click Add.8 In the Add Standalone Snap-in window, select Certificates.9 In the Certificates snap-in window, select Computer account.10 In the Select Computer window select the computer (whether local or not) wherethe new certificates have been saved.11 Click Finish to complete the process and click Close to close the Add/RemoveSnap- in window.12 The MMC Console window is displayed, where a new certificates branch has beenadded to the Console root.13 Right-click on the Personal entry of the Certificates branch and select All Tasks>Import. A Certificate Import Wizard is displayed.14 In the Certificate Import Wizard, browse to the location of the certificate.15 Enter the certificate file password.16 In the Certificate Store window make sure that the certificate store is selectedautomatically based on the certificate type.190

Placing the User Certificate in the User Certificate Store17 Select Finish to complete the Import operation.Using the MMC, the certificate can be seen in the certificate store for the “LocalComputer”.Placing the User Certificate in the User Certificate Store18 On the client machine, double-click on the user’s certificate icon (the .p12 file) inthe location where it is saved. A Certificate Import Wizard is displayed19 Enter the password.20 In the Certificate Store window make sure that the certificate store is selectedautomatically based on the certificate type.21 Select Finish to complete the Import operation.Using the MMC, the certificate can be seen in the certificate store for the “currentuser”.Setting up the Microsoft IPSec/L2TP client Connection ProfileOnce the Client machine’s certificate and the user’s certificate have been properlydistributed, set up the L2TP connection profile.1 In the client machine, right-click on the My Network Places icon on the desktopand select Properties.2 In the Network and Dial-up Connections window, select Make New Connection. TheNetwork Connection Wizard is displayed.3 In the Network Connection Type window: On Windows 2000 machines selectConnect to a private network through the Internet. On Windows XP machines selectVPN or dial-up, and in the next window select VPN.4 In the Destination Address window, enter the IP address or the resolvable hostname of the Gateway.5 In the Connection Availability window, make the new connection available For allusers or Only for myself.6 In the closing window, provide a name for the new connection, for example,L2TP_connection.7 The Connect window for the new connection type is displayed.To complete the L2TP connection configuration, proceed as follows. Note that theorder is important:Chapter 13 Third Party Remote Access Clients 191

Configuring Remote Access for Microsoft IPSec/L2TP Clients8 In the Connect window, click Properties.9 In the Networking tab, select the L2TP server.10 In the Security tab, choose Advanced > Settings, and select Use extensibleAuthentication protocols. Choose either MD5-challenge, or Smart Card or otherCertificates (encryption enabled). Make the same choice as made on the gateway(see “Configuring Office Mode and L2TP Support” on page 189).11 Click OK to save the configured settings and to return to the Connect window.12 In the Connect window, enter the user name and password or select a certificate.Configuring User Certificate PurposesTo configure the CA to issue certificates with purposes1 If using the ICA, run the ICA Management Tool (for more details about the tool,see the chapter “The Internal Certificate Authority (ICA) and the ICAManagement Tool” in the SmartCenter Guide), and in the Configure the CA page:• Change the property IKE Certificate Extended Key Usage property to the value 1,to issue gateway certificates with the “server authentication” purpose.• Change the property IKE Certificate Extended Key Usage to the value 2 to issueuser certificates with the “client authentication” purpose.If using an OPSEC certified CA to issue certificates, use the dbedit command lineor the graphical Database Tool to change the value of the global propertycert_req_ext_key_usage to 1. This will cause the SmartCenter Server to requesta certificate that has purposes (Extended Key Usage extension) in the certificate.2 Using SmartDashboard, issue a new certificate for the VPN-1 Pro Gateway. (In theVPN page, in the Certificate List section click Add. A new Certificate Propertieswindow opens.) Look at the certificate properties and check that the Extended KeyUsage Extension appears in the certificate.3 In the Remote Access page of the VPN-1 Pro Gateway object, in the L2TP Supportsection, select the new certificate.To Configure the Microsoft IPSec/L2TP Clients so that they donot check for the “Server authentication” PurposeThe following procedure tells the Microsoft IPSec/L2TP Client not to require the“Server Authentication” purpose on the gateway certificate.1 In the client machine, right-click on the My Network Places icon on the desktopand select Properties.192

Making the L2TP Connection2 In the Network and Dial-up Connections window, double click the L2TP connectionprofile.3 Click Properties, and select the Security tab.4 Select Advanced (custom settings), and click Settings.5 In the Advanced Security Settings window, under Logon security, select UseExtensible Authentication Protocol (EAP), and click Properties.6 In the Smart Card or other Certificate Properties window, uncheck Validate servercertificate, and click OK.Note - The client validates all aspects of the gateway certificate, during IKE authentication,other than the “Server Authentication” purpose.Making the L2TP Connection7 Click on Connect to make the L2TP connection.8 To view the IP address assigned to the connection, either view the Details tab inthe connection Status window, or use the ipconfig /all command.For More Information...For more information about how to configure advanced capabilities for MicrosoftIPSec/L2TP clients, see• “Non-Private Client IP Addresses” on page 195.• “Enabling IP Address per User (Office Mode)” on page 196.• “Back Connections (Server to Client)” on page 205.The L2TP protocol is defined in RFC 2661. Encryption of L2TP using IPSec isdescribed in RFC 3193. For information about the L2TP protocol and the MicrosoftIPSec/L2TP client, see the Network and Dial Up Connections Help in Windows 2000and XP.Chapter 13 Third Party Remote Access Clients 193

Configuring Remote Access for Microsoft IPSec/L2TP Clients194

CHAPTER14Remote AccessAdvanced ConfigurationIn This ChapterNon-Private Client IP Addresses page 195Enabling IP Address per User (Office Mode) page 196How to Prevent a Client Inside the Encryption Domain from Encrypting page 199Authentication Timeout and Password Caching page 201SecuRemote/SecureClient and Secure Domain Logon (SDL) page 202Back Connections (Server to Client) page 205Auto Topology Update (Connect Mode only) page 206How to Work with non-Check Point Firewalls page 206Early SecuRemote/SecureClients Versions page 206Resolving Internal Names with the SecuRemote DNS Server page 207Non-Private Client IP AddressesRemote Access ConnectionsSuppose a SecuRemote/SecureClient user connects from behind a NAT device, using anon-private IP address that belongs to another organization. During the life of theconnection, the gateway routes all traffic intended for that non-private IP address to theSecuRemote/SecureClient user, even traffic intended for the real owner of the IPaddress.195

Enabling IP Address per User (Office Mode)Solving Remote Access IssuesSet the vpn_restrict_client_phase2_id in the Objects_5_0.C file to theappropriate value, as follows:TABLE 14-1vpn_restrict_client_phase2_idvalueom_onlyprivate_and_omnonemeaningSecuRemote/SecureClient behind NAT devices can onlyconnect using Office Mode.SecuRemote/SecureClient can connect using either:• using Office Mode, or• when using private IP addresses (where the meaning of“private” is specified in the NAT page of the GlobalProperties window)This setting (the default) does not address the problemdescribed above.Note - If the user is restricted to Office Mode or to the use of a private IP address, andattempts another type of connection, the connection will be dropped and a log will besent to the SmartView Tracker.Enabling IP Address per User (Office Mode)The ProblemIn some configurations, a router or other device restricts access to portions of thenetwork to specified IP addresses. A SecuRemote/SecureClient user connecting inOffice Mode must be able to ensure that he or she is allocated an IP address which willallow the connection to pass through the router.Note - If this feature is implemented, it is imperative to enable anti-spoofing for OfficeMode. See “Anti Spoofing” on page 148 for more information.The SolutionThere are two ways to implement this feature, depending on whether IP addresses areallocated by a DHCP server or IP Pool.196

The SolutionDHCP ServerIf Office Mode addresses are allocated by a DHCP server, proceed as follows:1 Open the Check Point object from the Objects Tree.2 In the Object Properties > Remote Access >Office Mode page:• Enable Office Mode (either for all users or for the relevant group)• Select a DHCP server and under MAC address for DHCP allocation, selectcalculated per user name3 Install the Policy on the Module.4 On the Module, run the following command to obtain the MAC address assignedto the user.vpn macutil 5 On the DHCP Server make a new reservation, specifying the IP address and MACaddress, assigning the IP address for the exclusive use of the given user.ipassignment.conf FileThe $FWDIR/conf/ipassignment.conf file on the Module, is used to implement theIP-per-user feature. It allows the administrator to assign specific addresses to specificusers or specific ranges to specific groups when they connect using Office Mode orL2TP clients.For an explanation of the file’s syntax, see the comments (the lines beginning with the# character) in the sample file below.Note - This file must be manually added to all the modules.Chapter 14 Remote Access Advanced Configuration 197

Enabling IP Address per User (Office Mode)Sample ipassignment.conf File# This file is used to implement the IP-per-user feature. It allows the# administrator to assign specific addresses to specific users or specific# ranges to specific groups when they connect using Office Mode or L2TP.## The format of this file is simple: Each line specifies the target# gateway, the IP address (or addresses) we wish to assign and the user# (or group) name as in the following examples:## Gateway Type IP Address User Name# ============= ===== =========================== ========================# Paris-GW, 10.5.5.8, Jean# Brasilia, addr 10.6.5.8, Joao # comments are allowed# Miami, addr 10.7.5.8, CN=John,OU=users,O=cpmgmt.acme.com.gibeuu# Miami range 100.107.105.110-100.107.105.119/24 Finance# Miami net 10.7.5.32/28 Accounting## Note that real records do not begin with a pound-sign (#), and the commas# are optional. Invalid lines are treated as comments. Also, the# user name may be followed by a pound-sign and a comment.## The first item is the gateway name. This could be a name, an IP# address or an asterisk (*) to signify all gateways. A gateway will# only honor lines that refer to it.## The second item is a descriptor. It can be 'addr', 'range' or 'net'.# 'addr' specifies one IP for one user. This prefix is optional.# 'range' and 'net' specify a range of addresses. These prefixes are# required.## The third item is the IP address or addresses. In the case of a single# address, it is specified in standard dotted decimal format.# ranges can be specified either by the first and last IP address, or using# a net specification. In either case you need to also specify the subnet# mask length ('/24' means 255.255.255.0). With a range, this is the subnet# mask. With a net it is both the subnet mask and it also determines the# addresses in the range.## The last item is the user name. This can be a common name if the# user authenticates with some username/password method (like hybrid# or MD5-Challenge) or a DN if the user authenticates with a# certificate.198

The ProblemHow to Prevent a Client Inside the Encryption Domainfrom EncryptingThe ProblemIf a SecuRemote/SecureClient located inside the VPN domain of one gateway opens aconnection to a host inside the VPN domain of another gateway, the connection willbe encrypted twice (once by the SecuRemote/SecureClient and again by the gateway)and decrypted only once (by the peer gateway).The SolutionTo prevent this from happening, configure the SecuRemote/SecureClient not toencrypt if both the SecuRemote/SecureClient and the host (the end-points of theconnection) are in the VPN domains of gateways managed by the same SmartCenterServer.To do this, enable the send_clear_traffic_between_encryption_domains propertyin objects_5_0.C.Note - If you enable this feature, ensure that a VPN is defined between the Gateways. Thisfeature is disabled when more than one site is defined in SecuRemote/SecureClient.When the Client Has a Private AddressIf the send_clear_traffic_between_encryption_domains property is enabled, aproblem can arise when the gateway’s VPN domain includes private addresses, wherethe meaning of “private” is specified in the Non Unique IP Address Ranges page of theGlobal Properties window.If the SecuRemote/SecureClient connects from outside the VPN domain (for example,from a hotel) and is assigned (by the ISP or a NAT device) a private IP address whichhappens to be in the gateway’s VPN domain, then SecuRemote/SecureClient will notencrypt when connecting to the VPN domain, and the connection will be droppedbecause it is in the clear.You can configure SecuRemote/SecureClient to encrypt this traffic as follows:• To encrypt traffic from private addresses, enable thesend_clear_except_for_non_unique property in objects_5_0.C.• To encrypt traffic from specific IP addresses, proceed as follows:1 Define a group consisting of those addresses.Chapter 14 Remote Access Advanced Configuration 199

How to Prevent a Client Inside the Encryption Domain from Encrypting2 Enable the send_clear_except_for_specific_addresses property inobjects_5_0.C.3Set send_clear_except_for_address_group to the name of the groupdefined in step 1.Note - This feature is disabled when more than one site is defined inSecuRemote/SecureClient.Working in Connect Mode While Not ConnectedFor users connected in SecuRemote/SecureClient Connect Mode, you can reduce thefrequency of authentication by enabling theallow_clear_traffic_while_disconnected property in objects_5_0.C.SecuRemote/SecureClient will then not encrypt traffic to the peer encryption domainwhen not connected. This will prevent unnecessary authentication when connecting tounencrypted services in the peer encryption domain.For example, if the site includes both private and public HTTP servers, there is no needto encrypt traffic to the public site. To prevent a user from unnecessarily authenticatingonly because she is an internal user, configure the following two rules in the DesktopPolicy:TABLE 14-2.Source Destination Service Actionencryption domain encryption domain Any AcceptAny encryption domain Any EncryptNote -• If you enable this feature, you must ensure that a VPN is defined between the gateways.• This feature applies only to Connect Mode.• This feature is disabled when more than one site is defined in SecuRemote/SecureClient.200

The ProblemAuthentication Timeout and Password CachingThe ProblemUsers consider multiple authentications during the course of a single session to be anuisance. At the same time, these multiple authentications are an effective means ofensuring that the session has not been hijacked (for example, if the user steps away fromthe client for a period of time). The problem is finding the correct balance betweenconvenience and security.The SolutionMultiple authentication can be reduced by two means:• Increasing the authentication timeout interval• Caching the user’s passwordAuthentication Timeout IntervalTo specify the length of time between re-authentications, select Policy> GlobalProperties - Remote Access and in the Authentication Timeout section, enter a value inValidation timeout. Alternatively, check Use default value.The value is interpreted differently for Connect Mode and Transparent Mode,respectively. For Connect Mode, the countdown to the timeout begin from the timethat the Client is connected. For Transparent Mode, the countdown to the timeoutbegin from the time SecuRemote/SecureClient starts after the boot.Password CachingWhen the timeout expires, the user will be asked to authenticate again. Ifpassword-caching is enabled, SecuRemote/SecureClient will supply the cachedpassword automatically and the authentication will take place transparently to the user.In other words, the user will not be aware that re-authentication has taken place.Password caching is possible only for multiple-use passwords. If the user’s authenticationscheme implement one-time passwords (for example, SecurID), then passwords cannotbe cached, and the user will be asked to re-authenticate when the authenticationtime-out expires. For these schemes, this feature should not be implemented.Password caching is specified in the SecureClient’s Authentication window.Chapter 14 Remote Access Advanced Configuration 201

SecuRemote/SecureClient and Secure Domain Logon (SDL)SecuRemote/SecureClient and Secure Domain Logon(SDL)The ProblemWhen a SecuRemote/SecureClient user logs on to a domain controller, the user hasnot yet entered his or her SecuRemote/SecureClient credentials and so the connectionto the domain controller is not encrypted.The SolutionWhen the Secure Domain Logon (SDL) feature is enabled, then after the user entersthe OS user name and password (but before the connection to the domain controller isstarted), SecuRemote Client User Authentication window is displayed. When the userenters the SecuRemote/SecureClient credentials, the connection to the domaincontroller takes place over an encrypted tunnel.Enabling and Disabling Secure Domain LogonTo enable Secure Domain Logon (SDL), select Enable Secure Domain Logon from theSecuRemote/SecureClient Passwords menu.Note the following:• For Windows NT and Windows 2000:• SDL can only be enabled by the administrator, and only if the machine isconfigured as part of a domain.• You must reboot after enabling or disabling SDL.• If you are using WINS (see “WINS (Connect Mode Only)” on page 203),configure WINS before enabling SDL.• Do not change the machine domain configuration when Secure Domain Logon isenabled.Domain Controller Name ResolutionIf SecuRemote/SecureClient is configured in Connect Mode and Office Mode,SecuRemote/SecureClient automatically resolves the NT domain name using dynamicWINS.Otherwise, SecuRemote/SecureClient resolves the NT domain name using eitherLMHOSTS or WINS.202

Configuring SDL TimeoutLMHOSTSThe LMHOSTS name resolution service can be used in both LAN and dial-upconfigurations as follows:Enter the relevant information (see FIGURE 14-1) the $FWDIR/conf/dnsinfo.C fileon the VPN-1 Pro gateway, and install the policy.FIGURE 14-1 Syntax():LMdata(:()):():ipaddr ():name ():domain ():ipaddr ():name ():domain ()When SecuRemote/SecureClient updates the topology, the name resolution data willbe automatically transferred to the dnsinfo entry of the SecuRemote/SecureClientuserc.C file and then to its LMHOSTS file.WINS (Connect Mode Only)The WINS name resolution service can be used in dial-up configurations only. It is notsupported on Win 9x platforms.To use the WINS, proceed as follows on the SecuRemote/SecureClient virtual adapter:Warning - You must do this before enabling SDL (see “Enabling and Disabling Secure DomainLogon” on page 202).1 Specify the primary and, optionally, the secondary WINS servers protected byVPN-1 Pro.2 Reboot the SecuRemote/SecureClient machine.Configuring SDL TimeoutBecause SDL depends on the synchronization of concurrent processes, flexibility indefining timeouts is important.Chapter 14 Remote Access Advanced Configuration 203

SecuRemote/SecureClient and Secure Domain Logon (SDL)The SDL Timeout feature of Secure Domain Logon allows you to define the periodduring which a user must enter his or her domain controller credentials. When theallocated time expires and no cached information is used (if applicable), the logon fails.The timeout is controlled by the sdl_netlogon_timeout ()parameter in the file Objects_5_0.C.Note - This feature is not applicable if the Auto Local Logon option is enabled (ConnectMode Only).Cached InformationWhen the SecuRemote/SecureClient machine successfully logs on to a domaincontroller, the user’s profile is saved in cache. This cached information will be used ifsubsequent logons to the domain controller fail, for whatever reason.To configure this option in the client registry, proceed as follows:1 Go to HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon.2 Create a new key CachedLogonCount with the valid range of values from 0 to 50.The value of the key is the number of previous logon attempts that a server willcache.A value of 0 disables logon caching and any value above 50 will only cache 50logon attempts.Configuring Secure Domain Logon1 Configure the SecuRemote Client to use LMHOSTS (all platforms) or WINS (allplatforms except Win 9x).2 For Win NT and Win 2000, configure the SDL timeout.3 Define the site where the domain controller resides and download/update thetopology.4 If the client is not already a domain member, configure the machine as a domainmember.5 For Win NT and 2000:• Enable Auto Local Logon (optional)• Enable Secure Domain Logon6 Reboot the computer and logon.204

Using Secure Domain LogonUsing Secure Domain LogonAfter you have rebooted the computer:1 When the Windows NT Logon window is displayed, enter the operating systemcredentials.2 Click OK.The SecuRemote Logon window is displayed.3 Enter the SecuRemote credentials in the defined time (see “Configuring SDLTimeout” on page 203).If you fail to logon and no cached information is used, wait one minute and try again.If SDL is already configured on the client, the administrator can customizeSecuRemote/SecureClient installation packages with SDL enabled by default, therebyrelieving the user of the need to configure SDL manually. This can be done in twoways:• Create a self-extracting client package using the SecureClient Packaging Tool (see“Packaging Tool - Simplified Remote Client Installation””) and select EnableSecure Domain Logon (SDL) in the Operating System Logon window or• Edit the product.ini file in the SecuRemote installation package by setting thevalue of EnableSDL to 1. See “Userc.C and Product.ini Configuration Files”” formore information.Back Connections (Server to Client)Back connections (connections from the server to the client) are required by certainapplications, such as Xterm. These connections do not have to be explicitly defined inthe Rule Base. To achieve this, when a user logs on to a site, the username and IPaddress are stored in an authentication database for 15 minutes (this time frame isconfigurable). During this time, all back connections from server to client are allowed.After this time, back connections are sent in clear.Sending Keep-Alive Packets to the ServerTo enable the 15 minute interval, configure back connections so that Keep Alivetransmissions are sent by the client to the server. This is especially necessary when aNAT device is used.By sending Keep Alive packets, the IP Address maintained in the authenticationdatabase is constantly renewed. In the Remote Access page of the Global Propertieswindow, check Enable back connections (from gateway to client) and specify a value forSend Keep-Alive packet to the Gateway.Chapter 14 Remote Access Advanced Configuration 205

Auto Topology Update (Connect Mode only)Auto Topology Update (Connect Mode only)You can configure SecuRemote Clients to automatically update a site’s topology eitherwhen starting SecuRemote or just before the IKE key exchange in the Remote Accesspage of the Global Properties window.In this window, the system administrator can:• Update topology every ... hours — The site’s topology will be updated before thenext key exchange if the defined period has elapsed since the last topology update.The following features become available if Update topology every ... hours is enabled:• Automatic update — If enabled, the site will be updated after the key exchange(according to the value of Update topology every ... hours). This will allow to avoidprompting the user to update sites.• Upon VPN-1 SecuRemote/SecureClient startup — If enabled, the user will beprompted to update the topology when the SecuRemote Client starts. If the user isnot connected to the network when the SecuRemote Client starts, he or she canreject the prompt. In this case the topology will be automatically updated after thenext key exchange with the site.How to Work with non-Check Point FirewallsIf a SecuRemote/SecureClients is located behind a non-Check Point firewall, thefollowing ports must be opened on the firewall to allow SecuRemote/SecureClienttraffic to pass:TABLE 14-3ports to open for non-Check Point firewallsportUDP port 500TCP port 500IP protocol 50 ESPUDP port 2746UDP port 259explanationalways, even if using IKE over TCPonly if using IKE over TCPunless always using UDP encapsulationconfigurable; only if using UDP encapsulationonly if using MEP, interface resolving or interface HighAvailabilityEarly SecuRemote/SecureClients VersionsCheck Point’s recommended upgrade sequence is SmartCenter Server followed byModules followed by SecuRemote/SecureClients. There will then be a period of timeduring which earlier version SecuRemote/SecureClients will be connecting to206

The Problemupgraded Modules. If any of these SecuRemote/SecureClients are Version 4.1,backwards compatibility must be enabled in the Early Versions Compatibility page(under Remote Access) of the Global Properties window.Required policy for all desktops defines the type of policy that will be enforced onVersion 4.1 Clients. From NG forward the security policy applied toSecuRemote/SecureClient is automatically the policy defined in the Desktop SecurityRule Base. For Version 4.1 Clients, you must decide whether or not to enforce apolicy, and if yes, whether or not to allow:• all outgoing and all encrypted connections• only outgoing connections• only encrypted connectionsIf you select Client is enforcing required policy, an additional SCV check which verifiesthe Client’s security policy is performed.Resolving Internal Names with the SecuRemote DNSServerThe ProblemThe SecuRemote/SecureClient must resolve the names of internal hosts (behind theVPN-1 Pro gateway) with non-unique IP addresses using an internal DNS server.The SolutionThe simplest solution is to use Connect Mode and Office Mode. Otherwise, use thesplit DNS feature by defining a SecuRemote DNS Server.The SecuRemote DNS Server is an object that represents an internal DNS server thatcan be used to resolve internal names with unregistered, (RFC 1981-style) IP addresses.It is best to encrypt the DNS resolution of these internal names. Not all DNS trafficshould be encrypted, as this would mean that every DNS resolution would requireauthentication.Configuring the SecuRemote DNS Server1 Create a new SecuRemote DNS Server from the Objects Tree (FIGURE 14-2).Chapter 14 Remote Access Advanced Configuration 207

Resolving Internal Names with the SecuRemote DNS ServerFIGURE 14-2 Create a SecuRemote DNS Server2 In the SecuRemote DNS Properties window• General tab — Configure the general settings of the SecuRemote DNS Server aswell as the host on which the SecuRemote DNS Server.• Domains tab — Add new domains or edit and remove existing domains.FIGURE 14-3 Domain tab3 In the Domain tab (FIGURE 14-3), define the domain suffix and the matchingrule. Names in the domain that correspond to the rule will be resolved by theSecuRemote DNS Server. All other names will be resolved by the SecuRemoteclient’s default DNS server.• Specify the Domain Suffix for which the SecuRemote DNS Server will resolvethe internal names (for example, checkpoint.com).• Select Match only *.suffix to specify that the maximum number of labels resolvedwill be 1.For example, if Domain Suffix is “checkpoint.com” and Match only *.suffix isselected (that is, the maximum prefix label count is in effect 1) then theSecuRemote DNS Server will be used to resolve “www.checkpoint.com” and“whatever.checkpoint.com” but not “www.internal.checkpoint.com.”• Select Match up to...labels preceding the suffix to increase the number of labelsto be matched.208

The SolutionFor example, if Domain Suffix is “checkpoint.com” and Match up to...labelspreceding the suffix is selected and set to 3, then the SecuRemote DNS Serverwill be used to resolve “www.checkpoint.com” and“www.internal.checkpoint.com” but not“www.internal.inside.checkpoint.com”.Additional ConsiderationsSplit DNS is disabled in the following cases:• In Connect mode, while disconnected.To overr ide, set disable_split_dns_when_disconnected in theSecuRemote/SecureClient userc.C file to false.• In connect mode, while connected in Office Mode.To overr ide, set disable_split_dns_in_om in the SecuRemote/SecureClientuserc.C file to false.Chapter 14 Remote Access Advanced Configuration 209

Resolving Internal Names with the SecuRemote DNS Server210

CHAPTER15Userc.C and Product.iniConfiguration FilesIn This ChapterIntroduction to Userc.C and Product.iniThe VPN-1 administrator can use the Packaging Tool to produce customizedSecuRemote/SecureClient packages for distribution to end-users. The Packaging Toolchanges the behavior of SecuRemote/SecureClient by changing the values of theproperties in the Userc.C and Product.ini files contained in the package.However, not all of the properties in these files can be changed using the PackagingTool. It is possible to changes the behavior of SecuRemote/SecureClient by manuallyediting the Userc.C and Product.ini files in the SecuRemote/SecureClient package,before distributing the package to end users.The Userc.C FileIntroduction to Userc.C and Product.ini page 211Userc.C File Parameters page 213Product.ini Parameters page 224Structure of Userc.CThe Userc.C configuration text file contains has three sections. Global, Managers, andGateways.• Global—Properties that are not specific to the site (managed by a singleSmartCenter Server) or to the peer gateway. It does not change on the clientmachine. To change the Global Properties section of the objects database, do not211

Introduction to Userc.C and Product.inimake any manual changes to the Global section of userc.C. Either edit theSmartDashboard Global Properties, or use the dbedit command line or thegraphical Database Tool on the SmartCenter Server.• Managers—Properties that apply per SmartCenter Server. Updated whenever theend user performs a Site Update.• Gateway—Properties that are specific to a particular Gateway. Updated wheneverthe end user performs a Site Update.The section of the file where each parameter resides is indicated in the Userc.C fileparameter tables (below), in the column labelled Location in Userc.C.How Userc.C Is Automatically UpdatedWhen the Security Policy is installed on the Gateways, the objects database is alsoinstalled on the Gateways. The part of the database that relates to remote clients is sentto the Topology Server on the Gateway. When the clients perform a Site Update, theyare actually downloading the Topology information from the Topology server, whichupdates the Managers and Gateway sections of userc.C on the clients. The file isstored on the client machine in the SecuRemote\database directory. The parametersappear in the options section.How to Manually Edit Userc.CDo not make any manual changes to the Global section of userc.C.Manually edit the Managers and Gateway sections of userc.C as follows:1 Extract userc.C from the original SecuRemote/SecureClient tgz formatinstallation package.2 Edit the userc.C parameters, as needed.Warning - SecuRemote/SecureClient performs minimal syntax checking for the userc.Cfile. If a parameter is edited incorrectly, the file may become corrupted, and sites mayneed to be redefined.3 Recreate the tgz file.The Product.ini fileThe Product.ini configuration text file contains mostly properties that relate to thepackage installation. The properties are fixed. The Product.ini file is read only uponinstallation of the SecuRemote/SecureClient.To change products.ini use the Packaging Tool, or if necessary, edit the file manuallyas follows:212

SecureClient1 Extract products.ini from the original SecuRemote/SecureClient tgz formatinstallation package.2 Perform the required manual editing of products.ini.3 Recreate the tgz file. This is the SecuRemote/SecureClient package for end-users.Userc.C File ParametersSecureClientIn This SectionSecureClient page 213Encryption page 215Multiple Entry Point page 218Encrypted Back Connections page 219Topology page 219NT Domain Support page 220Miscellaneous page 221Note - Bold indicates the default value. Global, Managers, or Gateway indicates the locationin Userc.C. See “Structure of Userc.C” on page 211. Do not manually edit Global properties.• default_ps (n.n.n.n) — Specifies the IP address of the default Policy Server. Ifthis property exists, SecureClient will automatically log on to the Policy Server(with IP n.n.n.n) when it is launched, relieving the user of the need to manuallylog on to the Policy Server — Global.• manual_slan_control (true, false) — Disabling this property will remove theDisable Policy menu items from the Policy menu — Global.• allow_clear_in_enc_domain (true, false) — If enabled, unencrypted connectionswill be accepted by SecureClient NG over Encrypt desktop rules and bySecureClient 4.1 running Encrypted Only or Outgoing and Encrypted policy, as longas both the source and the destination IP addresses are in the encryption domain ofa single VPN-1 gateway — Global.• disable_stateful_dhcp (true, false) — As long as this attribute is false, DHCPpackets will be allowed by SecureClient regardless of the enforced Desktop Securitypolicy. If you set this attribute to true, DHCP will be allowed only if the DesktopChapter 15 Userc.C and Product.ini Configuration Files 213

Userc.C File ParametersSecurity policy allows it explicitly. This requires SecureClient version 4.1 to run apolicy of Allow All and SecureClient NG to have DHCP enabled through specificrules — Global.• block_conns_on_erase_passwords (true, false) — If true, the Close VPN optionwill replace Erase Password in the SecureClient’s Passwords menu and the buttonwill appear in the toolbar. Selecting Close VPN or clicking the above buttonwill result in blocking all encrypted connections — Managers.• enable_automatic_policy_update (true, false) — Specifies whether AutomaticPolicy Update is enabled or not — Managers.• silent_policy_update (true, false) — If true, the client will not prompt the userto update the policy upon client startup, even if the time specified inautomaic_policy_update_frequency has passed. The client will still attempt toupdate the policy after successful key exchange — Managers.• PS_HA (true, false) — Use backup Policy Servers on logon failure — Managers.• PS_LB (true, false) — If true will randomize policy server — list so not all clientswill try to connect to the same policy server — Managers.• LB_default_PS (true, false) — If true, when default_ps(x.x.x.x) is set it will go toa random Policy Server in the same site (found by examining topology) —Managers.• no_policy (true, false) — Indicates disable policy state — Global.• revert_to_backup (true, false) — If logon to Policy Server failed, try to logonto backup Policy Server (for transparent mode only). This property can also becontrolled in SmartDashboard — Managers.• policy_expire (60) — Timeout of policy, in minutes. This property can also becontrolled in SmartDashboard — Managers.• retry_frequency (30) — If logged in to a Policy Server, but failed to re-logonafter half the expiry time, this parameter (in seconds) specifies the amount of timebefore retrying logon. On each attempt all Policy Servers are tried — Managers.• pol_frequency (30) — This property is relevant to transparent mode only. Ifre-logon to Policy Servers failed, this timeout specifies how frequently to reattemptto logon — Managers.• skip_automatic_policy_update_if_authentication_required (true, false) —This property is relevant for transparent mode only. If true, Automatic PolicyUpdate will not take place when an authentication popup is supposed to bedisplayed to the user —• automaic_policy_update_frequency (10080) — Controls how frequently (inseconds) SecureClient should update policy files — Managers.214

EncryptionEncryptionNote - Bold indicates the default value. Global, Managers, or Gateway indicates the locationin Userc.C. See “Structure of Userc.C” on page 211. Do not manually edit Global properties.• use_cert (true, false) — Specifies whether Use Certificate will be checked in theIKE Authentication window — Global.• use_entelligence (true, false) — Specifies whether SecuRemote shouldattempt to use the Entrust Entelligence toolkit, if installed — Global.• entrust_inifile — Full path to a non-default entrust.ini file, to be used bySecuRemote/SecureClient when working with entrust certificates — Global.• certfile — Name of the last certificate used — Global.• gettopo_port (264) — Which port to use for topology update — Global.• pwd_erase_on_time_change (true, false) — Performs Erase Passwords when theuser changes the system clock — Global.• force_udp_encapsulation (true, false) — Indicates whether UDP encapsulationis used (transparent, and active profile in connect mode). Also used in ConnectMode to create the default profile — Global.• support_tcp_ike (true, false) — Indicates whether TCP over IKE is used(transparent, and active profile in connect mode). Also used in Connect Mode tocreate the default profile — Global.• support_tcp_ike (true/false/use_site_default) — Determine whether or not toattempt IKE over TCP — Gateway.• support_ip_assignment (true, false) — Indicates whether Office Mode is used(transparent, and active profile in connect mode). Also used in connect mode tocreate the default profile — Global.• ChangeUDPsport (true, false) — If the value of both flags ChangeUDPsport andforce_udp_encapsulation is true, a random source port is used for IKE packets, andanother random source port is used for UDP encapsulation packets — Global.• uencapport (2746) — Specifies the port to be used on the UDP encapsulatedpackets when using UDP encapsulation — Gateway.• ChangeIKEPort (true, false) — If true, do not bind to port 500. Instead, userouter port and use address translation to make it seem as if the connectionoriginated from port 500. This parameter allows other client applications (such asNokia and Microsoft) to use that port. Note if the port is taken, another port willbe used — Global.Chapter 15 Userc.C and Product.ini Configuration Files 215

Userc.C File Parameters• send_clear_traffic_between_encryption_domains (true, false) — if true andthe source and the destination are behind encryption domains (not same domains),packets will be sent clear. This feature is enabled only if a single site is defined —Managers.• send_clear_except_for_non_unique (true, false) — If true,send_clear_traffic_between_encryption_domains will not function for IPaddresses which are defined as NAT private addresses.• send_clear_except_for_specific_addresses (true, false)— If true,send_clear_traffic_between_encryption_domains will not function for IP addresseswhich are defined in send_clear_except_for_address_group — Managers.• send_clear_except_for_address_group — Address group specification forsend_clear_except_for_specific_addresses — Managers.• dns_encrypt (true, false) — Overwrites the encrypting attribute received in thetopology in the dnsinfo section. May be relevant for workarounds prior to versionNG FP3 — Global.• disable_split_dns_when_in_om (true, false) — Disable split DNS when in OfficeMode — Global.• disable_split_dns_when_disconnected (true, false) — Disable split DNS whendisconnected — Global.• disconnect_on_IKE_SA_expiry (true, false) — In connect mode, if the IKEtimeout expires and this property is true, disconnect instead of erasing thepasswords — Global.• renew_users_ica_cert (true, false) — Specifies whether users be able to renewtheir certificates (explicitly or implicitly) — Managers.• renew_users_ica_cert_days_before (1-1000) 60 — How many days beforeexpiration to start and perform an implicit renewal — Managers.• upgrade_fp1_and_below_users_ica_cert (true, false) — Whether or not toimplicitly renew certificates that were issued before NG FP2 — Managers.• ike_negotiation_timeout (36) — Determines the maximum time in secondsthat the IKE engine will wait for a response from the peer before timing out. Thisis the maximum interval between successive packets, and not the maximumnegotiation lifetime — Managers.• phase2_proposal (large, small) — Determines the size of the proposal sent bythe client in Quick Mode, packet 1. This property is for backwards compatibility.NG FP3 and higher clients use phase2_proposal_size — Managers.216

Encryption• phase2_proposal_size (large, small) — Determines the size of the proposalsent by NG FP3 or higher clients in Quick Mode, packet 1. If the value is missingthe value of phase2_proposal is taken instead. NG FP3 clients will try a largeproposal after a small proposal attempt fails — Managers.• vpn_peer_ls (true, false) — In a MEP fully overlapping encryption domainconfiguration, if this property is TRUE, a Gateway will be chosen randomlybetween the MEP Gateways and will be given priority — Managers.• ike_support_dos_protection (true, false) — Determines whether the client iswilling to respond to a DoS protection request, by restarting Main Mode using astateless protection. Equivalent to the SmartDashboard Global Property: SupportIKE DoS Protection from unidentified Source — Managers.• sr_don’t_check_crl (true, false) — Do not check the CRL of the certificate— Managers.• crl_start_grace (610200) — SecuRemote/SecureClient may accept CRLs thatare not yet valid — Managers.• crl_end_grace (1209600) — SecuRemote/SecureClient may accept CRLs thathave recently expired — Managers.• site_default_tcp_ike (true, false) — Determines the site default forattempting IKE over TCP. Each Gateway has a property: “supports_tcp_ike”(true, false or use_site_default). If the value is set to 'use_site_default' then themanagement property site_default_tcp_ike is used by the client to determinewhether to attempt IKE over TCP or not — Managers.• suppress_ike_keepalive (true, false) — If the IPsec keepalive is turned on,and the value of the property “suppress_ike_keepalive” is false, empty UDPpackets will be sent to the Gateway (destination port 500). The UDP keepalivepackets are sent only if there is an IKE SA with the peer and if UDP encapsulationwas chosen — Managers.• default_phase1_dhgrp — This field indicates which DH group to use for IKEphase 1 before the client has a topology. If the flag does not exist, group 2 will beused — Global.• to_expire (true, false) — Whether or not to have a timeout for the phase2 IKEauthentication. This property can also be controlled in SmartDashboard —Managers.• expire (120) — Timeout of IKE phase2. This property can also be controlled inSmartDashboard — Managers.• ICA_ip_address — The IP address of the Internal CA — Global.• allow_capi (true, false) — Allow the disabling of CAPI storage to Internal CAregistration — Global.Chapter 15 Userc.C and Product.ini Configuration Files 217

Userc.C File Parameters• allow_p12 (true, false) — Allow the disabling of p12 file storage to Internal CAregistration — Global.• trust_whole_certificate_chain (true, false) — This attribute improveconnectivity where there is a Certificate hierarchy, and the CA trusted by theGateway is a subordinate CA (not necessarily a direct subordinate) of the clienttrusted CA. Without this flag, both the Gateway and the client must trust exactlythe same CA — Global.• is_subnet_support (true, false) — If turned on, IPsec SA will be valid for asubnet, otherwise it will be valid for a specific address — Gateway.• ISAKMP_hybrid_support (true, false) — If turned on, when the authenticationpop up appears, the user will have the option to choose between Hybrid mode andcertificates as an authentication mode. (Otherwise the user will have the option tochoose between certificates and pre-shared secret) — Gateway.• resolve_multiple_interfaces (true, false) — If 'resolve_interface_ranges'(static interface resolving) is disabled or failed, and this property is turned on, thendynamic interface resolving will be done when addressing this Gateway. In this casethe interfaces of the Gateway will be probed once — Gateway.• interface_resolving_ha (true, false) — If dynamic interface resolving is used(see resolve_multiple_interfaces) and this property is turned on- the interfaces ofthe Gateway will be probed per connection to see if they are live — Gateway.• isakmp.ipcomp_support (true, false) — If the peer Gateway is a least NG andthe client is SecureClient (and not SecuRemote) then: — If the client is in “sendsmall proposal” mode and this property is turned on then IP compression will beproposed. (If the client is in “send large proposal” mode then IP compression willbe offered regardless of the value of this property) — Gateway.• supports_tcp_ike (use_site_default) — If IKE over TCP is configured on theclient AND either this property is 'true' or it's 'use_site_default' andsite_default_tcp_ike is 'true', then IKE phase 1 will be done over TCP —Gateway.• supportSRIkeMM (true, false) — When the authentication method is PKI, if thisproperty is false, Main mode is not supported — Gateway.Multiple Entry PointNote - Bold indicates the default value. Global, Managers, or Gateway indicates the locationin Userc.C. See “Structure of Userc.C” on page 211. Do not manually edit Global properties.resolver_ttl (10) — Specifies how many seconds SecuRemote will wait beforedeciding that a gateway is down — Global.218

Encrypted Back Connectionsactive_resolver (true, false) — Specifies whether SecuRemote should periodicallycheck the gateway status. Active gateway resolving may cause the dial-up connection totry to connect to an ISP. Turning this property off will avoid problems associated withthis behavior — Global.resolver_session_interval (60) — Specifies for how many seconds the gatewaystatus (up or down) remains valid — Global, Managers.Encrypted Back ConnectionsNote - Bold indicates the default value. Global, Managers, or Gateway indicates the locationin Userc.C. See “Structure of Userc.C” on page 211. Do not manually edit Global properties.• keep_alive (true, false) — Specifies whether the VPN-1 Pro enforcementmodules will maintain session key information for the Client, to allow encryptedback connections at any time. This property can also be controlled inSmartDashboard — Global, Managers.• keep_alive_interval (20) — When keep_alive is true, SecuRemote will pingthe VPN-1 Pro module every n seconds, where n is the number specified by thekeep_alive_interval property. This property can also be controlled inSmartDashboard — Global.TopologyNote - Bold indicates the default value. Global, Managers, or Gateway indicates the locationin Userc.C. See “Structure of Userc.C” on page 211. Do not manually edit Global properties.• topology_over_IKE (true, false) — Specifies whether New Site in SecuRemotewill use IKE to authenticate the user. If this property is set to true, IKE will beused, either using Hybrid Authentication (i.e., any authentication method chosenin the Authentication tab of the user properties) or using certificates. If this propertyis set to False, SSL will be used (as in version 4.1), and users will need IKEpre-shared secret or certificate configured to define a new site — Global, Managers.• encrypt_db (true, false) — Specifies whether the topology information inuserc.C is maintained in encrypted format — Global.• silent_topo_update (true, false) — Used for backwards compatibility, whenworking with servers that do not pass the property per site. This property can alsobe controlled in SmartDashboard — Global, Managers.Chapter 15 Userc.C and Product.ini Configuration Files 219

Userc.C File Parameters• silent_update_on_connect (true, false) — Tries to perform an update with theGateway to which a connection is being attempted, before connecting (applies toNokia clients) — Global.• update_topo_at_start (true, false) — If the timeout expires, update thetopology upon start up of the SecuRemote/SecureClient GUI application —Global, Managers.NT Domain SupportNote - Bold indicates the default value. Global, Managers, or Gateway indicates the locationin Userc.C. See “Structure of Userc.C” on page 211. Do not manually edit Global properties.• no_clear_tables (true, false) — Setting this property to true will enable theopening of new encrypted connections with the Encryption Domain afterSecuRemote/SecureClient has been closed by logoff or shutdown, as long asencryption keys have been exchanged, and are still valid. This may be necessarywhen using a Roaming Profile with NT domains, since the PC tries to save theuser's profile on the Domain Controller during logoff and shutdown, afterSecuRemote/SecureClient has been closed by Windows. This feature should beused in conjunction with “keep_alive” (see “Encrypted Back Connections” onpage 219), to ensure that valid encryption keys exist at all times — Global.• connect_domain_logon (true, false) — Global. Setting this attribute to trueenables clients using Connect Mode to log on to a Domain Controller via SDL.The user should do the following in order to logon to the Domain Controller:Note -1 Log on to the local Windows machine.2 Connect to the organization.3 Logoff and log back on (within five minutes after logoff) to the protectedDomain Controller, using the encrypted connection.1. Enabling this setting will keep the client Connected to the organization for five minutesafter the user logs off Windows.2. This feature was introduced before SDL in connect mode in was supported in NG FP2 HF2.In versions where SDL is supported, this property is used only for domain roaming profilesupport.220

Miscellaneous• sdl_main_timeout (60000) — In Transparent mode, this is the amount of time (inmilliseconds) to wait for the GUI application to get up and running after user clicksOK on the Windows logon dialog box. In connect mode this property specifies theamount of time to wait for user to successfully connect or cancel the connect dialog— Global.MiscellaneousNote - Bold indicates the default value. Global, Managers, or Gateway indicates the locationin Userc.C. See “Structure of Userc.C” on page 211. Do not manually edit Global properties.• enable_kill (true, false) — Specifies whether the user can StopSecuRemote/SecureClient. If this option is set to false, Stop VPN-1 SecuRemote orStop VPN-1 SecureClient does not appear in the File menu or when right-clicking onthe system tray icon — Global.• use_ext_auth_msg (true, false) — Specifies whether SecuRemote/SecureClientwill show custom messages in the authentication window upon success or failure.The messages should be placed in a file named AuthMsg.txt located in theSecuRemote directory (typically in Program Files\CheckPoint). See theAuthMsg.txt file in the SecuRemote package for more details — Global.• use_ext_logo_bitmap (true, false) — Specifies whetherSecuRemote/SecureClient will show a custom bitmap in the authenticationwindow. The file should be named logo.bmp and should be placed in theSecuRemote directory (usually located under Program Files\CheckPoint) —Global.• guilibs — Used to specify SAA DLL, and is documented in this context —Global.• pwd_type (now, later) — Used internally to indicates now or later auth dialog state.Do not modify — Global.• connect_mode_erase_pwd_after_update (true, false) — Erase password after asite update in Connect Mode. Used with silent_update_on_connect — Global.• disable_mode_transition (true, false) — Do not enable user to switchbetween modes via GUI or command line — Global.• connect_api_support (true, false) — Indicates SecuRemote/SecureClientmode.Set to true in order to work with the Connect API — Global.• connect_mode — Indicates SecuRemote/SecureClient mode. True for connectmode, false for transparent mode — Global.Chapter 15 Userc.C and Product.ini Configuration Files 221

Userc.C File Parameters• allow_clear_traffic_while_disconnected (true, false) — Topology is notloaded when disconnected, ensuring that there are no popups on the LAN whendisconnected — Global.• stop_connect_when_silent_update_fails (true, false) — If trying to connectin silent_update_on_connect mode, and the topology update fails, the connectionwill fail — Global.• go_online_days_before_expiry (0) — The number of days before Entrust automatic keyrollover (certificate renewal). Zero equals never — Global.• go_online_always (true, false) — When true, will attempt the LDAP(entrust.ini) protocol after successful IKE negotiation — Global.• implicit_disconnect_threshold (900) — When losing connectivity on physicaladapter, SecuRemote/SecureClient keeps the connected state for the amount oftime (in seconds) specified by implicit_disconnect_threshold. If the time elapses, orif connectivity resumes with a different IP address, SecuRemote/SecureClientdisconnects. This is useful in network environments with frequent networkdisconnection, such as wireless — Global.• active_test — Active tests configuration — Global.• log_all_blocked_connections — Used internally to indicates the mode, andreflects the state of the GUI checkbox. Do not modify — Global.• cache_password — Used internally to save the state of the checkbox called“Remember password, as per site settings”. Do not modify — Global.• dns_xlate (true, false) — Turn off the split DNS feature. May be needed inversions prior to NG FP3. In later versions, split DNS is not used by default whenin Office Mode — Global.• FTP_NL_enforce (0, 1, 2) — Indicates the strictness of the FTP inspection (0 -nocheck, 1- default check: Multiple newline characters allowed, 2-strict check: nomultiple newline characters allowed — Global.• show_disabled_profiles (true, false) — In connect mode, if the IKE timeoutexpires and this property is TRUE, disconnect instead of erasing the passwords —Global.• post_connect_script — Specify full path for a script thatSecuRemote/SecureClient will run after a connection has been established(Connect Mode only) — Managers.• post_connect_script_show_window (true, false) — Specifies whether or not thepost-connect script will run in a hidden window — Managers.• list_style — How the site icons are presented in the main frame window —Global.222

Miscellaneous• mac_xlate (true, false) — Needs to be set to true to support Split DNS wheretraffic to the “real” DNS server may not be routed the same way as traffic to the“split” DNS server. The most common scenario is “real” DNS server on the samesubnet as the client. Split DNS modifies the IP destination of the packet, but notthe MAC destination. With mac_xlate set to true, the MAC destination address isset to the address of the default gateway — Global.• mac_xlate_interval — How frequently a check is made for the default gateway'sMAC address (see mac_xlate) — Global.• sda_implicit (true, false) — The working mode of the Software DistributionAgent (SDA). True = implicit, false = explicit — Global, Managers.• sda_imlicit_frequency — The frequency (in minutes) with which the SoftwareDistribution Agent (SDA) connects to ASD server to check for updates — Global,Managers.• sr_build_number, sr_sw_url_path, sr_sw_url_path_9x,sr_build_number_9x, sr_sw_url_path_nt,sr_build_number_nt,sr_sw_url_path_w2k,sr_build_number_w2k — On the SmartCenter Servermachine, the names are desktop_sw_version, desktop_build_number, etc. Theseattributes help SecureClient decide if it needs to upgrade itself — Managers.• install_id_nt,install_id_9x,install_id_w2k — Installation IDs — Managers.Chapter 15 Userc.C and Product.ini Configuration Files 223

Product.ini ParametersProduct.ini ParametersTABLE 15-1Parameters for Product.iniParameter (bold indicatesthe default)ShowWelcome=0/1OverwriteConfiguration=0/1ShowUpdateOverwrite=0/1PathAskUser=0/1MeaningShow the Welcome window to the user during installation.Sets the value for Update or Overwrite choice during upgrade.The default value (0) means Update is chosen.Show the Update or Overwrite window to the user duringinstallation. If the window is not shown to the user, the valueplaced in OverwriteConfiguration will be used.Show the Choose Installation Destination window to the userduring installation. If the window is not shown to the user, thedefault value chosen by InstallShield will be used (usually thiswill be C:\Program Files\CheckPoint\SecuRemote).DesktopSecurityAskUser=0/1 Show the Desktop Security window to the user duringinstallation. If the window is not shown to the user, the valueplaced in DesktopSecurityDefault will be used.DesktopSecurityDefault=0/1 Sets the value for Desktop Security installation. A value of 1means that SecureClient will be installed, while a value of 0means that SecuRemote will be installed.InstallDialupOnly=0/1 Sets the value for binding to All Adapters or to Dialup Adaptersonly. A value of 0 means that the installation will bind to AllAdapters.ShowNetworkBindings=0/1ShowReadmeFile=0/1ShowBackgroundImage=0/1ShowSetupInfoDialogs=0/1Show the Adapter Bindings window to the user duringinstallation. If the window is not shown to the user, the valueplaced in InstallDialupOnly will be used.Show the Readme window to the user - this window asks theuser whether he/she would like to view the readme file beforefinishing the installation. A value of 0 means that the windowwill not be shown to the user, and the readme file will not beread during installation.Determine whether the background image will be displayedduring installation.Determine whether informative InstallShield dialogs (whichrequire no user interaction) will be displayed.224

MiscellaneousTABLE 15-1Parameters for Product.iniParameter (bold indicatesthe default)DisableCancelInstall=0/1ShowRestart=0/1RestartAfterInstall=0/1ShowRebootWarning=0/1IncludeBrandingFiles=0/1EnableSDL=0/1SdlNetlogonTimeout(Seconds/0)Support3rdPartyGina=0/1EnablePolicyView=0/1EnableLogView=0/1EnableDiagnosticsView=0/1OverwriteEntINI=0/1DefaultPath (Full path)ConnectMode=0/1MeaningAn option to disable the Cancel operation from the installationdialogs.Determine whether Do you want to restart dialog will beshown.0 - Do no restart after installation, 1- Restart after installation.Suppress the message “The installation will complete afterreboot”.Determines whether the files authmsg.txt and logo.bmp (usedfor customizing the Authentication dialog) will be copied duringinstallation. See the userc.C options section for more details onuse_ext_auth_msg and use_ext_logo_bitmap.Sets the value of Secure Domain Logon (SDL) during installation.If the value is 1, SDL will be enabled during installation.Set timeout for the operating system Net Logon, if 0 do notchange the current value.SecuRemote Client NG allows using third party GINA DLLsfor authentication. If this property is not selected, the WindowsGINA DLL will be used by default. Enabling this property mayconflict with SDL operation if a third party GINA DLL is used.Enable the Policy View in the SecureClient Diagnosticsapplication.Enable the Log View in the SecureClient Diagnosticsapplication.Enable the Diagnostics View in the SecureClient Diagnosticsapplication.Determines whether existing entrust.ini files will be overwrittenby the entrust.ini files in the installation. A value of 1indicates that the existing entrust.ini file will be overwritten.Default: C:\Program Files\CheckPoint\SecuRemote.Set default client mode: 0 - transparent, 1- connect mode.Chapter 15 Userc.C and Product.ini Configuration Files 225

Product.ini Parameters226

Advanced VPN ConnectivityThis section covers complex VPN-1 environments.

CHAPTER16VPN RoutingIn This ChapterThe Need for VPN Routing page 229Check Point Solution for Greater Connectivity and Security page 230Special Considerations for VPN Routing page 238Configuring VPN routing page 238The Need for VPN RoutingThere are a number of scenarios in which a Gateway or remote access clients cannotconnect directly to another Gateway (or clients). Sometimes, a given Gateway or clientis incapable of supplying the required level of security. For example:• Two Gateways with dynamically assigned IP addresses (DAIP Gateways). Hosts behindeither Gateway need to communicate; however, the changing nature of the IPaddresses means the two DAIP Gateways cannot open VPN tunnels. At themoment of tunnel creation, the exact IP address of the other is unknown.• SecuRemote/SecureClient users wish to have a private conversation usingVoice-over-IP (VoIP) software or utilize other client-to-client communicationsoftware such as Microsoft NetMeeting. Remote access clients cannot openconnections directly with each other, only with configured Gateways.• VPN-1 Net is a VPN-1 module that does not contain a security policy; to protectthe hosts behind VPN-1 Net modules, a way is needed to perform contentinspection on the packets passing between them and through them to the Internet.In all cases, a method is needed to enhance connectivity and security.229

Check Point Solution for Greater Connectivity and SecurityCheck Point Solution for Greater Connectivity andSecurityVPN routing provides a way of controlling how VPN traffic is directed. VPN routingcan be implemented with Gateway modules and remote access clients. Configurationfor VPN routing is performed either directly through SmartDashboard (in simple cases)or by editing the VPN routing configuration files on the Gateways (in more complexscenarios).FIGURE 16-1 Simple VPN routingIn FIGURE 16-1, one of the host machines behind Gateway A needs to connect witha host machine behind Gateway B. For either technical or policy reasons, Gateway Acannot open a VPN tunnel with Gateway B. However, both Gateways A and B canopen VPN tunnels with Gateway C, so the connection is routed through Gateway C.As well as providing enhanced connectivity and security, VPN routing can ease networkmanagement by hiding a complex network of Gateways behind a single Hub.VPN solutions of this kind can be broken down into:• Site-to-Site• Client solutionsSite-to-Site SolutionsHubs and SpokesReturn to the scenario involving two DAIP Gateways. The two DAIP Gateways cannotbe configured to open communication directly, but each can be separately configured toopen communication with a third Gateway that possesses a static IP address.230

Site-to-Site SolutionsIn this instance, the Gateway with the static IP is referred to as a “Hub”. The DAIPGateways are the Hub’s “Spokes”. A Hub is a Gateway through which VPN traffic isredirected. A spoke is the final VPN Gateway before the destination host is reached:FIGURE 16-2 DAIP to DAIPWhen the host in FIGURE 16-2 attempts to reach the server behind Gateway2:• The DAIP Gateway initiates the connection to the Gateway with the static IPAddress (Hub), opening a VPN tunnel.• The Hub decrypts the connection, encrypts the connection again, and sends itthrough a second separate tunnel to Gateway2.The connection is not simply forwarded “as is”, since each spoke uses differentencryption and integrity methods with the Hub.The scenario in FIGURE 16-2 assumes that a tunnel already exists between theGateway with the static IP and the destination DAIP Gateways. (This assumption isnecessarily, since the Gateway with the static IP is incapable of initiating a connectionwith the DAIP Gateway).VPN routing only connects the VPN domain of one DAIP Gateway to the VPNdomain of another DAIP Gateway - that is, hosts within one encrypted domain canconnect with hosts within the other. Connections whose source or destination IPaddress is the IP address of the DAIP Gateway are not allowed to route through theHub.Chapter 16 VPN Routing 231

Check Point Solution for Greater Connectivity and SecurityScenario with VPN-1 Net Modules Functioning as SpokesA typical company policy requires that all traffic between Gateways be inspected forcontent. Consider the case of a company that employs many VPN-1 Net modules;VPN-1 Net modules cannot perform content inspection, yet the traffic to the Internetstill needs to be inspected in accordance with company policy.To comply with company policy, route all VPN traffic through a single VPN-1 ProGateway. The VPN-1 Pro Gateway (defined as the Hub) inspects the traffic passingbetween the VPN-1 Net “Spoke” modules, as in FIGURE 16-3:FIGURE 16-3 Content inspection for NET-1 modulesConnections originating with hosts in Domain 2 are directed towards the centralVPN-1 Pro Gateway for content inspection before being forwarded to the HTTPserver on the Internet. Return packets follow the same path but in reverse.Take into consideration that:• The server on the Internet needs to route return packets through the Hub. Theeasiest way to achieve this is via a hide NAT rule on the Hub that hides the satelliteVPN domains behind the Hub address.• The IP address of the satellites external interface must be a valid public (routable)address so that the central Gateway can return packets to the satellite.Suppose the company in the previous example now enters into a business partnershipwith a second company that performs the same kind of VPN routing - that is, routes alltraffic between VPN-1 Net spokes through a central VPN-1 Pro Hub as in FIGURE16-4. VPN routing is achieved in three stages:232

Hub Mode (VPN routing for Remote Clients)FIGURE 16-4 VPN routing in three stages.1 A connection initiated by host 1 is forwarded from local VPN-1 net module to theVPN-1 Pro Gateway where the content is inspected.2 The connection is then routed to the VPN-1 Pro Gateway of the partner.3 The partner Gateway passes the connection to the local VPN-1 Net module infront of host 2.This kind of routing is configured by editing a special file, vpn_route.conf, that isfound on the Gateway. The path is: $FWDIR\conf\vpn_route.conf.Hub Mode (VPN routing for Remote Clients)VPN routing for remote access clients is enabled via Hub Mode. In Hub mode, alltraffic is directed through a central Hub. The central Hub acts as a kind of router forthe remote client. Once traffic from remote access clients is directed through a Hub,connectivity with other clients is possible as well as the ability to inspect the subsequenttraffic for content.When using Hub mode, enable Office mode. If the remote client is using an IP addresssupplied by an ISP, this address might not be fully routable. When Office mode is used,rules can be created that relate directly to Office mode connections.Note - Office mode is only supported in SecureClient, not SecuRemote.Chapter 16 VPN Routing 233

Check Point Solution for Greater Connectivity and SecurityAllowing SecureClient to Route all traffic Through a GatewayIn FIGURE 16-5, the remote client needs to connect with a server behind a VPN-1Net module. Company policy states that all connections to this server must beinspected for content. The VPN-1 Net enforcement module cannot perform therequired content inspection. When all the traffic is routed through the Gateway,connections between the remote client and the server can be inspected.FIGURE 16-5 Monitoring traffic to a Remote ClientSuppose the same remote client needs to access an HTTP server on the Internet. Thesame company policy regarding security still applies.FIGURE 16-6 Remote client to Internet234

Hub Mode (VPN routing for Remote Clients)The remote client’s traffic is directed to the VPN-1 Pro Gateway where it is directed tothe UFP (URL Filtering Protocol) server to check the validity of the URL and packetcontent, since the Gateway does not possess URL-checking functionality. The packetsare then forwarded to the HTTP server on the Internet.NATing the address of the remote client behind the VPN-1 Pro Gateway prevents theHTTP server on the Internet from replying directly to the client. If the remote client’saddress is not NATed, the remote client will not accept the clear reply from the HTTPserver.Remote Client to Client CommunicationRemote client to client connectivity is achieved in two ways:• By routing all the traffic through the Gateway.• Including the Office Mode range of addresses in the VPN domain of the Gateway.Routing all Traffic through the GatewayTwo remote users use VoIP software to hold a secure conversation. The traffic betweenthem is directed through a central Hub, as in FIGURE 16-7:FIGURE 16-7 Hub mode for remote access clientsFor this to work:• Allow SecureClient to route traffic through this Gateway must be enabled on theGateway.• The remote client must be configured with a profile that enables all traffic to berouted through the Gateway.• Remote clients are working in connect mode.If the two remote clients are configured for Hub mode with different Gateways, therouting takes place in three stages - each remote client to its designated Gateway, thenbetween the Gateways:Chapter 16 VPN Routing 235

Check Point Solution for Greater Connectivity and SecurityFIGURE 16-8 Remote clients to different hubsIn FIGURE 16-8, remote client 1 is configured for Hub mode with Gateway A.Remote client 2 is configured for Hub mode with Gateway B. For the connection tobe routed correctly:• Office mode must be enabled.• VPN configuration files on both Gateways must include the Office Mode addressrange used by the other. In FIGURE 16-8, the VPN configuration file on GatewayA directs all traffic aimed at an Office Mode IP address of Gateway B towardsGateway B. A connection leaves Remote Client1 and is sent to GatewayA. FromGateway A the connection is redirected to GatewayB. GatewayB once moreredirects the traffic towards Remote Client2. The reply from Remote Client2follows the same path but in reverse.• Office mode addresses used by both Gateways must be non-overlapping.Including the Office Mode Range of Addresses in the VPN Domain of theGatewayAnother way to achieve client to client communication is by defining an Office Moderange of addresses for remote clients, and including this range of addresses in the VPNdomain of the Gateway that acts as the Hub. Each remote client directs communicationto the remote peer via the Gateway; from the remote client’s perspective, its peerbelongs to the VPN domain of the Gateway.Note - Including the Office mode address range within the VPN domain of a Gateway is onlypossible with NG with Application Intelligence.236

VPN Routing and Access ControlVPN Routing and Access ControlVPN routing connections are subject to the same access control policy as any otherconnection. If VPN routing is correctly configured but a Security Policy rule exists thatdoes not allow the connection, the connection is dropped. For example: the client isconfigured for Hub mode; on the Hub Gateway is a rule which forbids all FTP trafficfrom inside the internal network to anywhere outside. When the remote client opensan FTP connection with an external machine, the connection is dropped.For VPN routing to succeed, a single rule in the Security Policy Rule base must covertraffic in both directions, inbound and outbound, on the central Gateway. This meansthe single rule must apply to traffic:• from the source IP address to the Hub and• from the Hub to the final IP destination.Suppose there is a rule that enables members of a remote access community tocommunicate with each other, and another rule that enables remote access clients toaccess a server on the Internet. These two rules relate to the same VPN routingconnection. The connection fails.A valid rule is shown in FIGURE 16-9. In FIGURE 16-9, the Hub and Spoke and allthe host machines behind them, as well as the Office mode addresses of remote accessclients, belong to a single group called “Internal machines”. This single rule allowshosts behind each Gateway as well as remote access clients to access HTTP servers onthe Internet.FIGURE 16-9 One rule in Policy Rule Base for VPN routingChapter 16 VPN Routing 237

Special Considerations for VPN RoutingSpecial Considerations for VPN RoutingGenerally, if you decide to route all VPN traffic through a single Hub to inspectconnections on the network, take into consideration how this will affect overallnetwork performance.See also:“VPN Routing HOWTO”.Configuring VPN routingCommon VPN routing scenarios can be configured through a VPN star community,but not all VPN routing configuration is handled through SmartDashboard. VPNrouting between Gateways that are not members of a VPN community is configured byediting the configuration file $FWDIR\conf\vpn_route.conf.Configuring VPN Routing for Gateways via SmartDashboardFor simple hubs and spokes (or situations in which there is only one Hub) the easiestway is to configure a VPN star community in SmartDashboard:1 On the Star Community properties window, Central Gateways page, select theVPN-1 Pro Gateway that functions as the “Hub”.2 On the Satellite Gateways page, select the DAIP Gateways as the “spokes”, orsatellites.3 On the General page, Enable VPN routing for satellites section, select one of theseoptions:• To center and to other Satellites through center. This allows connectivitybetween the Gateways, for example if the spoke Gateways are DAIP Gateways,and the Hub is a Gateway with a static IP address.• To center, or through the center to other satellites, to internet and other VPNtargets. This allows connectivity between the Gateways as well as the ability toinspect all communication passing through the Hub to the Internet. This isuseful in the example of the hosts behind a VPN-1 Net Gateway that access theInternet, and the connections needs to be inspected.238

Enabling Hub Mode for Remote Access clientsFIGURE 16-10Satellites communicating through the center4 Create an appropriate access control rule in the Security Policy Rule Base.Remember: one rule must cover traffic in both directions.5 NAT the satellite Gateways on the Hub if the Hub is used to route connectionsfrom Satellites to the Internet.The two DAIP Gateways can securely route communication through the Gateway withthe static IP address.Enabling Hub Mode for Remote Access clients1 On the Remote Access page of the Gateway properties window, Hub Modeconfiguration section, select Allow SecureClient to route all traffic through thisgateway.2 On the Properties window of the Remote Access community, ParticipatingGateways page, set the Gateway that functions as the “Hub”.3 On the Participant User Groups page, select the remote clients.Chapter 16 VPN Routing 239

Configuring VPN routing4 Create an appropriate access control rule in the Security Policy Rule Base. VPNrouting traffic is handled in the Security Policy Rule Base as a single connection,matched to one rule only.5 Configure the profile on the remote client to route all communication through thedesignated Gateway.Configuration of Client to Client Routing by Including theOffice Mode Range of Addresses in the VPN Domain of theGatewayTo configure VPN routing for remote access clients via the VPN domain, add theOffice mode range of addresses to the VPN domain of the Gateway:1 In SmartDashboard, create an address range object for the Office Mode addresses.2 Create a group that contains both the VPN domain and Office mode range.3 On the General properties window of the Gateway object > Topology page > VPNdomain section, select Manually defined.4 Select the group that contains both the VPN domain of the Gateway and the Officemode addresses.The remote clients must connect to the site and perform a site update before they cancommunicate with each other.Configuration via editing the VPN configuration FileFor more granular control over VPN routing, edit the vpn_route.conf file in the confdirectory of the SmartCenter Server.The configuration file, vpn_route.conf, is text file that contains the name of networkobjects, not dotted decimal IP addresses. The format is: Destination, Next hop,Install on Gateway (with tabbed spaces separating the elements).Consider a simple VPN routing scenario consisting of Hub and two Spokes (FIGURE16-11). All machines are controlled from the same SmartCenter Server, and all VPN-1modules are members of the same VPN community. You want only Telnet and FTPservices to be encrypted between the Spokes and routed through the Hub:240

Configuring Multiple HubsFIGURE 16-11Filtering Telnet and FTPAlthough this could be done easily by configuring a VPN star community, the samegoal can be achieved by editing vpn_route.conf:Destination Next hop router interface Install OnSpoke_B_VPN_Dom Hub_C Spoke_ASpoke_A_VPN_Dom Hub_C Spoke_BIn this instance, Spoke_B_VPN_Dom is the name of the network object group thatcontains spoke B’s VPN domain. Hub C is the name of the VPN-1 Pro Gatewayenabled for VPN routing. Spoke_A_VPN_Dom is the name of the network object thatrepresents Spoke A’s encryption domain. The actual file looks like this:FIGURE 16-12vpn_route.confConfiguring Multiple HubsFIGURE 16-13 shows two Hubs, A and B. Hub A has two spokes, spoke_A1, andspoke_A2. Hub B has a single spoke, spoke_B. In addition, Hub A is managed fromSmartCenter Server 1, while Hub B is managed via SmartCenter Server 2, as shown inFIGURE 16-13:Chapter 16 VPN Routing 241

Configuring VPN routingFIGURE 16-13Configuring multiple vpn_route.conf filesFor the two VPN star communities, based around Hubs A and B:• Spokes A1 and A2 need to route all traffic going outside of the VPN communitythrough Hub A• Spokes A1 and A2 also need to route all traffic to one another through Hub A, thecenter of their star community• Spoke B needs to route all traffic outside of its star community through Hub BA_community is the VPN community of A plus the spokes belonging to A.B_community is the VPN community. Hubs_community is the VPN community ofHub_A and Hub_B.Configuring VPN Routing and Access Control on SmartCenter Server AThe vpn_route.conf file on SmartCenter Server 1 looks like this:Destination Next hop router interface Install OnSpoke_B_VPN_Dom Hub_A A_SpokesSpoke_A1_VPN_Dom Hub_A Spoke_A2Spoke_A2_VPN_Dom Hub_A Spoke _A1Spoke_B_VPN_Dom Hub_B Hub_A242

Configuring Multiple HubsSpokes A1 and A2 are combined into the network group object “A_spokes”. Theappropriate rule in the Security Policy Rule Base looks like this:Source Destination VPN Service ActionAny Any A_CommunityB_CommunityHubs_CommunityAnyAcceptConfiguring VPN Routing and Access Control on SmartCenter Server BThe vpn_route.conf file on SmartCenter Server 2 looks like this:Destination Next hop router interface Install OnSpoke_A1_VPN_Dom Hub_B Spoke_BSpoke_A2_VPN_Dom Hub_B Spoke_BSpoke_A1_VPN_Dom Hub_A Hub_BSpoke_A2_VPN_Dom Hub_A Hub_BThe appropriate rule in the Security Policy Rule Base looks like this:Source Destination VPN Service ActionAny Any B_CommunityA_CommunityHubs_CommunityAnyAcceptFor both vpn_route.conf files:• “A_Community” is a star VPN community comprised of Hub_A, Spoke_A1, andSpoke_A2• “B_Community” is a star VPN community comprised of Hub_B and Spoke_B• “Hubs-Community” is a meshed VPN community comprised of Hub_A andHub_B (it could also be a star community with the central gateways meshed).Chapter 16 VPN Routing 243

Configuring VPN routingClient to Client via Multiple Hubs Using Hub ModeFIGURE 16-14 shows two remote clients each configured to work in Hub mode witha different Gateway:FIGURE 16-14Remote clients with different HubsRemote Client 1 works in Hub mode with Hub 1. Remote Client 2 works in Hubmode with the Hub 2. In order for VPN routing to be performed correctly:• Remote clients must be working in Office mode• Office mode address range of each Gateway must be included in the vpn_route.conffile installed on the other Gateway.Destination Next hop router interface Install OnHub1_OfficeMode_range Hub1 Hub2Hub2_OfficeMode_range Hub2 Hub1When Remote Client 1 communicates with Remote Client 2:• The traffic first goes to the Hub 1, since Remote Client 1 is working in Hub modewith Hub 1.• Hub 1 identifies Remote Client 2’s IP address as belonging to the Office moderange of Hub 2.• The vpn_route.conf file on Hub 1 identifies the next hop for this traffic as Hub 2.• The traffic reaches the Hub 2; Hub 2 redirects the communication to RemoteClient 2.244

CHAPTER17VPN Routing HOWTOIn This ChapterDefining a Default Route Through a Spoke That Also Acts As a Hub page 245Defining VPN Routing via two Gateways for SecureClient page 247Defining a Default Route Through a Spoke That Also ActsAs a HubConsider the following scenario: Gateway A is a satellite or spoke of a VPN communityfor which To center, or through the center to other satellites, to internet and other VPNtargets has been enabled for the VPN community.Gateway A has two interfaces, one for the internal (encrypted VPN) domain, and onefor the DMZ. The VPN domain of the Gateway is configured to contain only theinternal network, and not the DMZ. (When the VPN domain of a Gateway is definedmanually, the administrator can choose to include only the IP addresses in the VPNdomain. IP addresses that are not included in the VPN domain are considered asbelonging to the Internet).245

Defining a Default Route Through a Spoke That Also Acts As a HubFIGURE 17-1 Spoke as router scenarioThe VPN routing table on Gateway A in FIGURE 17-1 is configured so that any IPnot in the VPN domain of a known (member) Gateway is considered to be on theInternet. Any communication from that IP should be encrypted by the Hub before itreaches the spoke. By default, any communication received from an IP which is identified as anIP on the internet, and not encrypted, is dropped.Now a connection from the DMZ to an IP in the internal network is initiated. TheDMZ IP addresses are not part of the VPN domain, so the spoke considers themaddresses on the Internet. The spoke expects this connection to be encrypted by thecentral Hub. The connection is not encrypted so the connection is rejected. Nocommunication takes place between the internal network and the DMZ.This problem arises because Gateway A is defined as a spoke in a VPN community yetGateway A also acts as a router to IP addresses outside of the VPN community.Solving the DMZ problemTo solve this problem, define a route through the spoke for IP addresses that are notpart of the VPN domain (in this case, IP addresses in the DMZ). Do this by adding arule in the $CPDIR/Conf/vpn_route.conf file on the SmartCenter Server. The syntaxof the file is:Destination Next hop Router Install onDMZ GatewayA GatewayAThe rule states communication headed for IP addresses which are behind the spoke yetnot part of the VPN community (i.e. the DMZ) can be routed through the spoke’sinterface. This “extra” route is installed only on Gateway A. From Gateway A’sperspective, there is an addition to the routing table that says consider the IP addresses246

of the DMZ as part of Gateway A’s VPN domain. Since this addition is only installed onGateway A, other Gateways will not see that specific DMZ as part of Gateway A’s VPNdomain.When editing the vpn_route.conf file:• All objects in the file must be network objects that already exist in the VPN-1network objects database• Only network object names, and not IP addresses, should be used• In order to configure for more than one network object, create groups in theobjects database and use the group name here• There are no spaces in the names of the network object. Use an underscore wherea space is needed.Defining VPN Routing via two Gateways for SecureClientConsider the following scenario: two SecureClient machines route through twoGateways. The SecureClients and Gateways belong to the same VPN community.VPN routing between Remote Client1 and RemoteClient2 takes place via Gateway Aand GatewayB. In addition:• The IP address of Remote Client1 (from the OM pool or IP NAT pool) is placedwithin Gateway A’s VPN domain.• Office mode IP of Remote Client2 (from the OM pool or IP NAT pool) is placedwithin Gateway B’s VPN domain.When Remote Client1 initiates a connection to Remote Client 2, the connection ismatched by the entry for the VPN community in the “VPN” column of the SecurityPolicy Rule Base. When Remote Client2 replies with a “back connection” to SecureClient 1, this connection is also matched by entry in the VPN column of the rule base.Chapter 17 VPN Routing HOWTO 247

Defining VPN Routing via two Gateways for SecureClientThis back connection has certain security implications. Make sure the “backconnection” is matched by the “Any” option in the VPN column of the security rulebase.248

CHAPTER18IP Resolution in VPNIn This ChapterThe Need for IP Resolution page 249Check Point Solution for Interface Resolution page 249Special Considerations for IP Resolution page 253Configuring IP Resolution page 253The Need for IP ResolutionVPN-1 Gateways usually have more than one IP address, at least one of which must bea valid public address routable on the Internet. When a remote VPN peer, such asanother Gateway or secuRemote/SecureClient, opens a VPN tunnel, the peer needs toconnect with one of these valid IP addresses.Although the Gateway is defined with an IP address on the General Properties page ofthe network object, this IP (while routable for the SmartCenter Server) may not beroutable for other Gateways or machines on the Internet. The remote VPN peer mustbe able to select the correct address.In another instance, suppose that all the IP addresses of a given Gateway are publicaddresses routable on the Internet. This would solve the IP selection problem, but if aninterface fails, the remote VPN peer still needs some kind of recovery mechanism, away of continuing the connection through a second interface.Check Point Solution for Interface ResolutionVPN-1 has two mechanisms for the initial selection of an IP and the selection of asecond IP in case of interface failure:• Static IP resolution249

Check Point Solution for Interface Resolution• Dynamic IP resolutionStatic IP resolutionIn static IP resolution, the remote VPN peer discovers the appropriate IP address of theGateway through the topology information defined in the Gateway’s network object.For this to succeed, all the Gateway’s IP addresses must have their topology properlyconfigured. This means the topology defined for each interface accurately reflects thenetwork behind each interface.For example, FIGURE 18-1 shows Gateway A with three interfaces, one of whichleads to an internal network connected via a router. The second leads to a web serverin the DMZ, and the third leads to the Internet. For VPN-1, the public routableaddress (192.168.13.15) leads to all other addresses. The remote VPN peer consists of oneexternal interface with a valid IP (192.168.140.56) and one internal interface with aprivate IP (10.1.3.0).FIGURE 18-1 Gateway with three interfacesThe remote VPN peer determines which IP to connect to via an algorithm which takesinto consideration:• The IP addresses of the remote VPN peer• The topology of the Gateway as defined in the network objectIn FIGURE 18-1, if a host on the remote peer subnet (10.1.3.0) tries to connect witha host on subnet 10.1.2.0 of the Gateway, the remote VPN peer Gateway:1 Uses an algorithm that compares its own IP addresses (internal and external) withthe IP addresses (internal and external) of the Gateway with which it is trying toconnect.250

Dynamic IP resolution2 The algorithm sees that:• its internal address of 10.1.3.0 does not match with 10.1.1.0 or 10.1.2.0 behindthe Gateway but does match with 10.1.3.0, the DMZ subnet.• its external address 192.168.140.56 does match with 192.168.13.15, since forVPN-1 the public routable address of a Gateway leads to all other addresses.So now the algorithm has two possible matches.3 The algorithm gives “higher priority” to external interfaces, so resolves to open aVPN tunnel between its own external interface and the external interface ofGateway A.Dynamic IP resolutionThere are instances where static IP resolution is insufficient, for example:• Where a Gateway has multiple interfaces that are routable, meaning multiple publicIP addresses. The algorithm used in static IP resolution cannot determine anappropriate IP address to connect to.• A SecuRemote/SecureClient user is located externally to an organization. The IPaddress assigned to it (by the ISP, hotel NAT device, etc.) is identical with an IP onthe organization’s internal network. In such an instance, theSecuRemote/SecureClient may conclude it is already located within the corporateLAN. If the user is trying to connect to a machine on the corporate LAN, theremote access client considers itself already on the LAN and tries to open aconnection directly, without going through the Gateway.In FIGURE 18-2. A SecuRemote/SecureClient user connects a laptop to the networkof a hotel. Static address resolution is configured on the laptop. The hotel NATingsoftware employs a private address range. The VPN domain behind the Gateways usesthe same range of invalid IP addresses for the local network.FIGURE 18-2 Laptop with SecuRemote/SecureClient.The VPN connection fails because:Chapter 18 IP Resolution in VPN 251

Check Point Solution for Interface Resolution• The laptop receives an invalid IP address on the internal network (which is NATedto a valid IP address of the external outbound interface of the hotel Gateway).• Static interface resolution for SecuRemote/SecureClient is calculated according tothe IP address of the client and the topology of the peer Gateway (the number ofinterfaces on the peer gateway and type of network behind each interface)Since the SecuRemote/SecureClient and the VPN domain share the same invalid10.10.10.x address range, the SecuRemote/SecureClient considers itself already“behind” the Gateway, on the local network, and therefore attempts to connect to theinternal interface of the Gateway. The solution is to use dynamic IP resolution.In Dynamic IP resolution, the remote VPN peer uses a proprietary Check Pointprotocol to probe all the available IP addresses with RDP packets, and selects the firstto respond. These RDP packets, sent to port 259 to discover whether an interface isreachable, are proprietary to Check Point and no not conform to RDP as specified inRFC 908/1151.Note - These UDP RDP packets are not encrypted, and only test the availability of a peer andits interfaces.Probing MethodsThe probing takes place in one of two modes:• Single probe• Continuous interface pollingIn the first mode, an interface is probed only once. In the second mode interfaces arepolled continuously. If the remote VPN peer is SecuRemote/SecureClient, anappropriate IP address is selected for every new connection. If the remote VPN peer isa Gateway, an interface IP is selected according to the results of the latest poll. AGateway may even switch between IP addresses in the middle of a connection.Defining a Primary IPIn an environment where dynamic IP resolution is configured, it is still possible to set a“primary” IP address for each Gateway using the database tool (dbedit).252

Dynamic IP resolutionThe property to change is: interface_resolving_ha_primary_if_GW where IP is the IPaddress of the interface. By default, this address is used by remote peers for opening aVPN tunnel. If the given primary address fails, the “first to respond” of the remainingIP addresses is selected.Note - This is only possible when both VPN peers are Gateways; it does not work when oneof the peers is secuRemote/SecureClient.Special Considerations for IP ResolutionThe most important consideration is which IP resolution to use.• Static IP resolution does not depend on the network objects being Check Pointproducts; third party VPN products can be configured for static IP resolution.• Dynamic IP resolution can only be implemented between Check Point networkobjects that are also Check Point products.• Dynamic IP resolution is easier to configure than static, and solves the problem ofmultiple IP addresses on multi homed Gateways.• Dynamic IP resolution exposes the routable and non-routable IP addresses of theGateway to the Internet. The peer Gateway or remote access client sends RDPpackets to all of these addresses. These packets are not encrypted; they pass “in theclear” through the Internet. Anyone capturing the packets could read both theinternal and external IP addresses of the Gateways and possibly use them in anattack involving IP spoofing if anti-spoofing is not enabled on the Gateway. (TheRDP sender does not have enough information to determine how it istopologically related to its peer - in other words, on which side of the Gateway itresides. Thus the RDP packets contain both internal and external addresses and aresent to all possible peer interfaces to determine which of them is routable.)• It is not recommended to use static IP address resolution on the remote peer if aGateway has two external interfaces. If there are two external interfaces, the firstwill be chosen, and if the interface fails, the connection will not be resumed withthe second. If the Gateway has two external interfaces, configure dynamic interfaceresolution instead.Configuring IP ResolutionHow the remote VPN peer selects a Gateway interface depends on:• Whether the remote peer is another Gateway or SecuRemote/SecureClient, and• Whether the resolution is defined as static or dynamic.Interface resolution:Chapter 18 IP Resolution in VPN 253

Configuring IP Resolution• Always takes place on the remote VPN peer.• Is actually an IP resolution. The IP address may be related to a physical interface oran alias.Configuring Static IP ResolutionStatic Interface Resolution When The Remote VPN Peer isAnother GatewayIn this instance, no RDP packets are sent to discover whether the Gateway is up ordown. The remote VPN peer looks at the topology of the network object (the VPNGateway) it is trying to connect to, and makes a calculation based on the properties itfinds there, for example the number and type of interfaces (internal/external) of theGateway, plus the address range behind each interface.1 In the Global Properties window, VPN-1 Pro > Advanced page, Resolving mechanismsection. Select Enable VPN-1 gateways to calculate statically peer gateway’s interfacebased on network topology.2 On the network object representing the Gateway, open the Gateway Propertieswindow > Topology page.3 Define the topology for each interface. Double-clicking an existing interface in thetable opens the Interface properties window.The topology tab shows the “properties” on which the static interface resolutioncalculation is based. The remote VPN peer looks at its own IP address, looks at theaddresses of the machines behind each interface of the Gateway it wants to connect to,and selects the interface behind which is the host IP the connection is destined.When configuring the topology of a particular interface, define the interface as eitherinternal or external.• If an interface is defined as external, it means that all the IP addresses behind thatinterface do not belong to any internal interface.• If an interface is defined as internal, then on the Topology tab of that interface’sproperty window, IP addresses behind this interface section, then you must specifythe IP addresses. Do not select Not Defined.254

Configuring Dynamic IP ResolutionFIGURE 18-3 Interface Topology tab:Static Interface Resolution When The Remote VPN Peer isSecuRemote/SecureClientThis calculation is based on the IP address of the SecuRemote/SecureClient and theGateway topology. The remote VPN peer looks at its own IP address, for example10.10.10.x, looks at the addresses of the machines behind each interface of the Gatewayit wants to connect to, and selects the interface behind which is a matching addressrange. To configure:1 In Global Properties > Remote Access > VPN -Advanced, Resolving mechanismsection, select Enable SecuRemote/SecureClient to calculate statically peer gateway’sbest interface based on network topology.2 Open the Gateway Properties window > Topology page, define the topology foreach interface. Double-clicking an existing interface in the table opens the Interfaceproperties window.Configuring Dynamic IP ResolutionDynamic Interface Resolution When The Remote VPN Peer is aGatewayIn this instance, the status of every IP address is known via a polling mechanism thatchecks which IP addresses are “up” or “down”. The first IP to respond is chosen as theresolved IP for that Gateway. To configure:Chapter 18 IP Resolution in VPN 255

Configuring IP Resolution1 In the Global Properties window, VPN-1 Pro > Advanced page, Resolving mechanismsection. Select Enable dynamic interface resolving per gateway (must be defined pergateway).2 On the Gateway Properties window, VPN > Advanced page click Dynamic interfaceresolving configuration. The Dynamic Interface resolving configuration windowopens.3 Select Enable dynamic resolution by peer VPN-1 gateways.4 Select either:• Upon tunnel initialization. If this option is selected, a single RDP session isopened with all IPs of the Gateway. The first interface to respond is chosen. Ifthe interface goes down, the current connection and subsequent connections donot survive.• Upon fail-over event. If this option is selected, RDP packets are constantlypolling the status of all the Gateway’s interfaces. If an interface goes down, theconnection moves to another interface.Dynamic Interface Resolution When The Remote VPN Peer is aSecuRemote/SecureClient1 In Global Properties > Remote Access > VPN -Advanced, Resolving mechanismsection, select Enable dynamic interface resolving by SecuRemote/SecureClient peers(must be defined per gateway).2 On the Gateway object, Gateway Properties window, VPN > VPN Advanced pageclick Dynamic interface resolving configuration. The Dynamic Interface resolvingconfiguration window opens.3 Select Enable dynamic resolution by SecuRemote/SecureClient.4 Select either:• Upon initial opening. If this option is selected, a single RDP session is openedwith all IPs of the Gateway. The first interface to respond is chosen. If theinterface goes down, the current connection and subsequent connections do notsurvive.• Upon every connection initialization. If this option is selected, RDP packets areconstantly polling the status of all the Gateway’s interfaces. If an interfaces goesdown, the current connection is lost but subsequent connections go through adifferent interface.256

IP Resolution and ISP RedundancyIP Resolution and ISP RedundancyIf the Gateway is also part of a VPN community, then some of the connections will beVPN connections. In order to achieve ISP Redundancy for VPN connections, then theGateway must be configured in a particular way.For further information see: “ISP Redundancy” in “FireWall-1 and SmartDefense.”Chapter 18 IP Resolution in VPN 257

Configuring IP Resolution258

CHAPTER19Multiple Entry PointVPNsIn This ChapterThe Need for Multiple Entry Point Gateways page 259The Check Point Solution for Multiple Entry Points page 259Special Considerations for MEP page 268Configuring MEP page 269The Need for Multiple Entry Point GatewaysThe Gateway on which the VPN-1 module is installed provides a single point of entryto the internal network. It is the Gateway that makes the internal network “available”to remote machines. If the Gateway fails, the internal network is no longer available. Ittherefore makes good sense to have Multiple Entry Points (MEP) to the same network.The Check Point Solution for Multiple Entry PointsIn a MEPed environment, more than one VPN Gateway is both protecting and givingaccess to the same VPN domain. How a remote VPN peer selects a Gateway in orderto reach a destination IP depends on how the MEPed Gateways have been configured,which in turn depends on the requirements of the organization.259

The Check Point Solution for Multiple Entry PointsThe Check Point solution for multiple entry points is based on a proprietary ProbingProtocol (PP) that tests Gateway availability. The MEPed Gateways do not have to be inthe same location; they can be widely-spaced, geographically.Note - In a MEPed Gateway environment, the only remote client supported is the Check PointSecuRemote/SecureClient.Three Basic MEP Configurations - an Overview• Primary-Backup, in which one or multiple backup gateways provide “highavailability” for a primary Gateway. The remote VPN peer is configured to workwith the primary Gateway, but switches to the backup Gateway if the primary goesdown. An organization might decide to use this configuration if it has twomachines in a MEP environment, one of which is stronger than the other. It makessense to configure the stronger machine as the primary. Or perhaps both machinesare the same in terms of strength of performance, but one has a cheaper or fasterconnection to the Internet. In this case, the machine with the better Internetconnection should be configured as the primary. See: “Primary-Backup Gateways”.• Load Distribution, in which the remote VPN peer randomly selects a Gateway withwhich to open a VPN peer. For each IP source/destination address pair, a newGateway is randomly selected. An organization might have a number of machineswith equal performance abilities. In this case, it makes sense to enable loaddistribution. The machines are used in a random and equal way. See: “LoadDistribution”.• First to Respond, in which the first Gateway to reply to the peer Gateway ischosen. An organization would choose this option if, for example, the organizationhas two Gateways in a MEPed configuration - one in London, the other in NewYork. It makes sense for VPN peers located in England to try the London Gatewayfirst and the NY Gateway second. Being geographically closer to VPN peers inEngland, the London Gateway is the first to respond, and becomes the entry pointto the internal network. See: “First to Respond”.260

How It WorksHow It WorksMEP is implemented via a proprietary Probing Protocol (PP) that sends special RDPUDP packets to port 259 to discover whether an IP is reachable. This protocol isproprietary to Check Point and does not conform to RDP as specified in RFC908/1151. (PP is used to provide both MEP functionality and dynamic IP resolution.For more information regarding IP resolution, see: IP Resolution in VPN).Note - These UDP RDP packets are not encrypted, and only test the availability of a peer.The remote VPN peer continuously probes or polls all MEPed Gateways in order todiscover which of the Gateways are “up”, and chooses a Gateway according to theconfigured selection mechanism. For example, if the MEP selection mechanism isPrimary-Backup, the VPN tunnel is opened with the Primary Gateway.If the Gateway goes down, the remote VPN peer chooses a different Gateway, adifferent entry point to the internal network. Since RDP packets are constantly beingsent, the status of all Gateways is known and updated when changes occur. This meansthere is no delay while a Gateway that is “up” is searched for. All Gateways that are“up” are known.Primary-Backup GatewaysBackup Gateways provide redundancy for primary Gateways. If the primary Gatewayfails, connections go through the backup.In FIGURE 19-1, the first Gateway is configured as the “primary”, and the secondGateway as the “backup”. The backup Gateway inherits the complete VPN domain ofthe primary. If the primary Gateway fails, for whatever reason, the remote VPN peerdetects that the link has gone down and works through the backup Gateway. Failoverwithin an existing connection is not supported; the current connection is lost.When the primary Gateway is restored, new connections go through the primaryGateway while connections that already exist will continue to work through the backupGateway.Chapter 19 Multiple Entry Point VPNs 261

The Check Point Solution for Multiple Entry PointsFIGURE 19-1 Basic MEP configuration with Primary Gateway definedThe MEPed Gateways may also lead to more than one VPN domain, as in FIGURE19-2. In the scenario, in order for the backup Gateway to be able to reach the VPNdomain of the primary, there must be some other form of connection, such as adedicated leased line.FIGURE 19-2 MEPed GatewaysA VPN domain is defined for the primary Gateway and a VPN domain is defined onthe backup Gateway. The backup Gateway has its own VPN domain but also inheritsthe VPN domain of the primary. The backup serves both its own VPN domain and theVPN domain of the primary if the primary Gateway fails.262

How It WorksThe VPN domains of the primary and backup Gateways must always be“non-overlapping”, which means no IP address belongs to both VPN domains. In ascenario with one primary and multiple backup Gateways, the remote VPN peer selectsthe primary Gateway first. If the primary fails, a backup Gateway is chosen based on thefirst to respond.The mechanism is the same if the remote VPN peer is another Gateway orSecuRemote/SecureClient.First to RespondWhen there is no primary Gateway, all Gateways share “equal priority”. When allGateway’s share “equal priority”, as in FIGURE 19-3:• Remote VPN peers send RDP packets to all the Gateways in the MEPconfiguration.• The first Gateway to respond to the probing RDP packets gets chosen as the entrypoint to network. The idea behind first to respond is “proximity”. The Gatewaywhich is “closer” to the remote VPN peer responds first.• A VPN tunnel is opened with the first to respond. All subsequent connections passthrough the chosen Gateway.• If the Gateway ceases to respond, a new Gateway is chosen.FIGURE 19-3 No primary, equal priority, overlapping VPN domainThe mechanism is the same if the remote VPN peer is another Gateway orSecuRemote/SecureClient.Load DistributionTo prevent any one Gateway from being flooded with connections, the connections canbe evenly shared amongst all the Gateways to distribute the load. When all Gatewaysshare equal priority (no primary) and are MEPed to the same VPN domain, it ispossible to enable load distribution between the Gateways. The Gateways are probedChapter 19 Multiple Entry Point VPNs 263

The Check Point Solution for Multiple Entry Pointswith RDP packets, as in all other MEP configurations, to create a list of respondingGateways. A Gateway is randomly chosen from the list of responding Gateways. If aGateways stops responding, a new Gateway is (randomly) chosen.The way load distribution is handled depends on whether the remote VPN peer is aGateway or SecuRemote/SecureClient.If the remote VPN peer is a Gateway, a new Gateway is randomly selected for everysource/destination IP pair. While the source and destination IP’s remain the same, theconnection continues through the chosen Gateway.If the remote VPN peer is SecuRemote/SecureClient, the remote peer randomlychooses a Gateway and stays with that Gateway for all connections to host machineswithin the VPN domain. In other words, connections to host 1, host 2, or host 3 in theVPN domain all go through the chosen Gateway. Load distribution takes place on the“level of different clients”, rather than the level of “endpoints in a connection”.Routing Return PacketsIf there are two or more Gateways providing access to the internal network, how doesa host on the internal network know through which Gateway to send replies? Whenthe destination host replies, a router on the internal network can route the reply packetthrough any of the MEPed Gateways. To keep the connection alive, the reply packetsmust be returned along the same route they came in.To make sure return packets are routed correctly, the MEPed Gateway makes use ofeither:• IP pool NAT (which means static NAT)• Route Injection MechanismMEP with Static IP Pool NATReply packets from hosts inside the internal VPN domain are routed to the correctMEP Gateway through the use of static IP pool NAT addresses. In FIGURE 19-4, theremote VPN peer chooses the primary Gateway as the entry point to the internalnetwork.264

Routing Return PacketsFIGURE 19-4 IP pool NATThe remote VPN peer’s IP address is NATed to a reserve address from the PrimaryGateway’s IP NAT pool. The IP pool addresses of the primary Gateway are routableonly through the primary Gateway, so all reply packets from the target host are returnedto the primary Gateway, and not the backup. For this reason, it is important that the IPNAT pools of the primary and backup Gateway do not overlap.When the packet returns to the primary Gateway, the Gateway restores the remotepeer’s source IP address. Once an address from the IP NAT pool is assigned to theremote machine, all subsequent connections to the remote machine use the sameNATed address.In addition, the routing tables on the routers that lie behind MEPed Gateways must beedited so that addresses from a Gateway IP pool are returned to the correct Gateway.MEP with RIMRoute Injection Mechanism (RIM) is a feature of the VPN module used to overcome linkdown time; for example, when a link becomes unavailable, an alternative path is sent or“injected” to the appropriate router in order to update its routing table. Routeinjection is integrated with MEP functionality, providing an alternative to IP pool NATin situations where large numbers of static IP addresses are not available.When a VPN tunnel is opened with a MEPed Gateway, the Gateway injects theappropriate “return path” to the routers that lie behind it. When the destination hostreplies, the host’s reply packets are routed to the correct Gateway. The route is injectedusing the OSPF protocol. When another Gateway is selected, the new Gateway injectsan updated “return route” to the router. In this way, the routing tables are constantlyChapter 19 Multiple Entry Point VPNs 265

The Check Point Solution for Multiple Entry Pointskept up to date. The reverse is also true. When a tunnel to a Gateway goes down, theGateway removes or deactivates the appropriate “return route” on the router byrunning a route-changing script.FIGURE 19-5 Route Injection MechanismIn a MEP environment that uses the Route Injection Mechanism to route reply packetsto the correct Gateway, Gateways are configured as either pingers or listeners. A pingerGateway, typically the remote peer, uses the VPN daemon to send encrypted “tunneltesting” packets to Gateways configured to listen for them. A listener Gateway isconfigured to listen on port 18234 for the special tunnel testing packets. A Gatewaythat receives a tunnel test packet:• Turns it around (reversing the source and destination IP addresses) and sends it backto the pinger.• Knows it has been chosen as the entry point to the internal network and updatesthe router behind it by running the route-changing script.Which Gateways to ping or which pingers to listen to are contained in theconfiguration file tnlmon.conf which is read and reloaded by the VPN daemon everytime a new policy package is installed.Currently, RIM is configured by manually editing the pinger configuration filetnlmon.conf on the Gateway. If a number of Gateways appear in the same line in thePinger configuration file, the pinger considers those Gateways as MEPed. Assumingthey are actually configured as MEP in SmartCenter Server, then the Route InjectionMechanism consults MEP for the currently chosen Gateway and only the chosenGateway is pinged.266

Visitor Mode and MEPIf a listener Gateway appears by itself on a separate line in tnlmon.conf (on the pingerGateway) then the listener, from the pinger’s perspective, is considered a single entrypoint to the network; in this case, the pinger “pings” the listener without consultingthe MEP configuration.Visitor Mode and MEPSince the RDP Gateway discovery mechanism used in a MEPed environment runs overUDP, this creates a special challenge for SecureClient in Visitor Mode, since all traffic istunnelled over a regular TCP connection.In a MEPed environment:• The RDP probing protocol is not used; instead, a special Visitor Mode handshakeis employed.• When a MEP failover occurs in a First to Respond/Load Sharing configuration,SecureClient disconnects and the user needs to reconnect to the site in the usualway.• In a Primary-backup configuration, if a failover continues to the backup Gateway, theconnection continues through the backup Gateway until the backup Gateway stopsresponding. Even if the Primary Gateway is restored, there is not fail-back to thePrimary.• All the Gateways in the MEP:1 Must support visitor mode.2 The user must be working with a Visitor Mode enabled profile.SecureClient Connect Profiles and MEPWhen SecureClient connects to a Gateway that is part of a MEP configuration, the“connect” action gives higher priority to the Gateway configured as the “connect to”Gateway in the profile, and not to the “Primary Gateway” of the MEP -- except in thecase of loadsharing.• First to reply. In a First to Reply MEP environment, SecureClient attempts to theconnect to the Gateway configured in the profile. If the configured Gateway doesnot reply, the first Gateway to respond is chosen.• Primary Backup. In a Primary Backup MEP environment, SecureClient first triesto connect to the Gateway configured in the profile. If this Gateway is a defined asa backup Gateway in the MEP configuration, and does not reply, then theconnection fails. If the Gateway configured in the profile is the Primary Gateway ofthe MEP, SecureClient fails over to the backup Gateway.Chapter 19 Multiple Entry Point VPNs 267

Special Considerations for MEP• Load Sharing. In a Load Sharing MEP environment, SecureClient randomlyselects a Gateway and assigns the Gateway priority. In other words, SecureClientignores whatever Gateway is configured as the “connect to Gateway” in the profile.Special Considerations for MEPMEP versus ClusteringBoth MEP and Clustering are ways of achieving High Availability and load sharing.However:• Unlike the members of a ClusterXL Gateway Cluster, there is no physicalrestriction on the location of MEPed Gateways. MEPed Gateways can begeographically separated machines. In a FireWall cluster, the clustered Gatewaysneed to be in the same location, directly connected via a sync interface.• MEPed Gateways can be managed by different SmartCenter Servers; Clustermembers must be managed by the same SmartCenter Server.• In a MEP configuration there is no “state synchronization” between the MEPedGateways. In a FireWall cluster, all of Gateways know the “state” of all theconnections to the internal network. If one of the Gateways fails, the connectionpasses seamlessly over (failsover) to another Gateway, and the connection continues.In a MEPed configuration, if a Gateway fails, the current connection is lost and oneof the backup Gateways picks up the next connection.• In a MEPed environment, the decision which Gateway to use is taken on theremote side; in a cluster, the decision is taken on the Gateway side.IP pool NAT versus RIMThe advantage of RIM over IP pool NAT is twofold:• No need to change the routing tables of the internal routers• No need to maintain large pools of static IP addresses on each GatewayDisadvantages of RIM over IP pool NAT are:• If Load Distribution is enabled on the MEPed Gateways, RIM cannot be used todirect return packets to the appropriate Gateway. See: “Configuring RIM” onpage 272.Considerations for RIM• A Gateway with an dynamically assigned IP address (DAIP) can only be a “pinger”.• Scripts are optional, regardless of the configuration.268

Configuring Primary-Backup• Gateways do not have to be defined as “listeners” in order to listen. By default,every Gateway replies to tunnel testing packets. When a gateway is configured aslistener, the Gateway maintains state information for each pinger in order toidentify changes of status.Configuring MEPTo configure MEP, decide on:1 The MEP selection method• Primary-Backup.• Equal Priority, which means First to Reply or Load Distribution.2 Method for returning reply packets:• IP pool NAT• RIMConfiguring Primary-Backup1 In the Global Properties window, VPN-1 Pro > Advanced page, select Enable BackupGateway.2 In the network objects tree, Groups section, create a group consisting of Gatewaysthat act as backup Gateways.3 On the Properties window of the network object selected as the Primary Gateway,Topology page > VPN Domain section, select Manually defined and define the VPNdomain. Verify that the IP address of the backup Gateway is not included.4 On the VPN page, select Use Backup Gateways, and select the group of backupGateways from the drop-down box. This Gateway now functions as the primaryGateway for a specific VPN domain.5 Define the VPN for the backup Gateway(s). Backup Gateways do not always have aVPN domain of their own. They simply back-up the primary. If the backupGateway does not have a VPN domain of its own, the VPN domain should includeonly the backup Gateway itself:A On the Properties window of the backup network object, Topology page >VPN Domain section, select Manually defined.B Select a group or network that contains only the backup Gateway.If the backup does have a VPN domain:Chapter 19 Multiple Entry Point VPNs 269

Configuring MEPA Verify that the IP address of the backup Gateway is not included in the VPNdomain of the primary.B For each backup Gateway, define a VPN domain that does not overlap withthe VPN domain of any other backup Gateway.Note - There must be no overlap between the VPN domain of the primary Gateway and theVPN domain of the backup Gateway(s); that is, no IP address can belong to both.6 Configure IP pool NAT or RIM to handle return packets. See: ConfiguringReturn Packets.Configuring MEPed Gateways with Equal PriorityFirst to Respond in a Fully Overlapping Encryption DomainWhen more than one Gateway leads to the same (overlapping) VPN domain, they areconsidered MEPed by the remote VPN peer, and the first Gateway to respond to theprobing protocol is chosen. To configure first to respond, define that part of the networkthat is shared by all the Gateways into a single group and assign that group as the VPNdomain.On the Properties window of each Gateway network object, Topology page > VPNDomain section, select Manually defined, and define the same VPN domain for allGateways.Load Distribution for a Fully Overlapping Encryption DomainHow load distribution is configured depends on whether the remote VPN peer is aGateway or SecuRemote/SecureClient.Configuring Load Distribution when the VPN Peer is a Gateway1 In the Global Properties window, VPN-1 Pro > Advanced page, select Enable loaddistribution for Multiple Entry Point configurations (Site to Site connections).Checking this options also means that in MEP configurations, the remote VPNpeer randomly select a MEPed Gateway to work with.2 Define the same VPN domain for all the Gateways.270

Configuring Return PacketsConfiguring Load distribution when the VPN Peer isSecuRemote/SecureClient1 In the Global Properties window, Remote Access > VPN Basic page, Load distributionsection, select Enable load distribution for Multiple Entry Point configurations(Remote Access connections).2 Define the same VPN domain for all Gateways.Checking this option also means that load distribution is dynamic, that is the remoteclient randomly selects a Gateway.Configuring Return PacketsReturn packets can be handled either with IP pool NAT addresses belonging to theGateway, or by running a script on the Gateway that updates the routing tables of theinternal router (RIM).Configuring IP pool NATIn Global Properties > NAT page, select Enable IP Pool NAT for SecuRemote/SecureClientand gateway to gateway connections. Then:1 For each Gateway, create a network object that represents the IP pool NATaddresses for that Gateway. The IP pool can be a network, group, or address range.For an address range, for example:• On the network objects tree, right-click Network Objects branch > New >Address Range... The Address Range Properties window opens.• On the General tab, enter the first IP and last IP of the address range.• Click OK. In the network objects tree, Address Ranges branch, the new addressrange appears.2 On the Gateway object where IP pool NAT translation is performed, GatewayProperties window, NAT page, IP Pools (for Gateways) section, select either (orboth):• Use IP Pool NAT for VPN client connections.• Use IP Pool NAT for gateway to gateway connections.• In the Allocate IP Addresses from field, select the address range you created.• Decide after how many minutes unused addressees are returned to the IP pool.• Click OK.3 Edit the routing table of each internal router, so that packets with an a IP addressassigned from the NAT pool are routed to the appropriate Gateway.Chapter 19 Multiple Entry Point VPNs 271

Configuring MEPConfiguring RIMGateways are configured as either pingers or listeners.RIM is enabled when the configuration file tnlmon.conf is placed in the directory$FWDIR/conf.Rim is disabled when:• The configuration file tnlmon.conf is removed from CPDIR/conf.• If Load Distribution is enabled on the Gateway.In FIGURE 19-6, RIM is enabled between the MEPed Gateways A and B, and theremote VPN peer X:FIGURE 19-6 RIM scenarioThe RIM configuration files for A, B, and X look like this:tnlmon.conf for Gateway A#Sample configuration file for gateway A#configuration: listenerpeer: Xup_interval: 15down_interval: 2scripts_path /etc/fw/conf/tnlmon_scriptsscript: monitor.shtnlmon.conf for Gateway B#Sample configuration file for gateway B#272

Configuring Return Packetsconfiguration: listenerpeer: Xup_interval: 15down_interval: 2scripts_path /etc/fw/conf/tnlmon_scriptsscript: monitor.shtnlmon.conf for Gateway X (X is the name of the pinger as it appears inSmartDashboard)#Sample configuration file for gateway X#configuration: pingerpeer: A Bup_interval: 15down_interval: 2Each line of tnlmon.conf is read and parsed until either a new line or the #(comment) character is reached. Each line starts with an attribute, a colon, and isfollowed by a value for this attribute.Notice that there is no script path or script file defined for Gateway X. This is optionalon the pinger. However, to receive an email when a MEPed Gateway goes down,define a script path and script name in the configuration file. For a pinger Gateway thathas such a script,• the script is executed when all the MEPed Gateways change status, for example ifall of the MEPed Gateways fail the script is executed for the down event.• the script is executed if only one of the MEPed Gateways goes up; this indicates theMEP is back up and the script is executed.If the MEPed Gateways are already up and a single Gateway (that went down) comesback up, then no event is executed since the MEPed Gateways as a whole did notchange status.Chapter 19 Multiple Entry Point VPNs 273

Configuring MEPFor an explanation of the attributes:Attribute Value Default Exampleconfiguration Either ‘listener” or “pinger’ No default configuration:pingerMust be setup_interval Number of seconds to waitbefore sending a packet toinform the Gateway that itis the chosen entry point;in other words, the intervalbetween tunnel test packets.15 up_interval:15down_intervalpeerNumber of seconds to waitif providing HighAvailability, but currentlynot active. Down_intervalis only relevant for clustermembers that are alsopingers. For each givenperiod, only one of thecluster members is selectedto send tunnel test packets.Each cluster memberchecks whether he is theselected member forsending tunnel test packets.In other words,down_interval is theinterval (seconds) betweensuch member queries.White space separated listof peers (VPN-1 objectnames) to ping or listen to.If “pinger” configuration isset, each list represents agroup of MEPed gateways.2 down_interval:2No default.At least oneentry.peer: gw1 gw2274

Configuring Return Packetsscripts_pathscriptExecuted for each gatewayor MEP group after everypolicy install. The fullabsolute path is required.Executed whenever a peerchanges its status with theparameters: peerIP actionHAstatus firstTimePeerEncDomainNo actionexecutedNo actionexecutedscripts_path:/etc/fw/conf/tnlmon_scripts/monitor.shscript: monitor.shpeerIPThe peer with the changedstatusactionEither “up” or “down”HAstatusHA status - “active” or“standby”. If no HA isdefined, the default value is“active”firstTimeEither “1” or “0” for thefirst time in a specificaction, not the first timeever; see: Monitor.shConsiderationsPeerEncDomainOne of the peer VPNdomain network objectsscript_initExecuted on every policyreload with the parameters:peerIP rangeListNo actionexecutedscript_init: init.shMonitor.sh Considerations1 The file monitor.sh must be created specifically for RIM and placed in the path.Chapter 19 Multiple Entry Point VPNs 275

Configuring MEP2 The RIM configuration file tnlmon.conf tells the VPN daemon which file to run,namely monitor.sh.3 When a peer changes its status (goes up or down), the script monitor.sh isexecuted.4 When a peer is identified as “down” or has just come “up”, monitor.sh isactivated with the following parameters:• peerIP. The IP of the Gateway whose status has changed.• action. The change in status, either “up” or “down”.• HAstatus. If High Availability is enabled, whether the current member is activeor not is indicated. If High Availability is not defined, then the parameter willhave the value “active”.• firstTime. Indicates whether this is the first time the script is called. This scriptmight be called several times, depending on the number of subnets in the VPNdomain. The first time the script is called, firstTime is set to “1”, meaning this isthe first time the script has been invoked for the peer gateway, and with one ofthe VPN domains subnets as a value for the PeerEncDomain argument. If theVPN domain contains more than one subnet, the next time the script isinvoked, firstTime is set to “0” meaning this is not the first time the script hasbeen called for this specific action, and a different value for PeerEncDomain.• PeerEncDomain. A subnet of the VPN Domain if the domain has subnets.276

CHAPTER20Advanced VPNConnectivity ScenariosIn This ChapterDMZ Connections to the Internal Network When VPN routing is enabled page 277VPN Routing with External Gateways Functioning as Spokes page 279Load Distribution between Gateways with Partially Overlapping VPN Domainspage 280Cross Primary Backup page 281DMZ Connections to the Internal Network When VPNrouting is enabledVPN routing in the DMZ can provide a special challenge. Consider the scenario inFIGURE 20-1. Gateway A is a satellite or “spoke” of a VPN community for which Tocenter, or through the center to other satellites, to internet and other VPN targets hasbeen enabled for the VPN community.277

DMZ Connections to the Internal Network When VPN routing is enabledFIGURE 20-1 VPN routing in the DMZGateway A has three interfaces, one for the internal (encrypted VPN) domain, one forthe DMZ, and one for the Internet. The VPN domain of the Gateway is configured tocontain only the internal network, and not the DMZ.VPN routing on Gateway A in FIGURE 20-1 is configured so that any IP not in theVPN domain of a known (member) Gateway is considered to be on the Internet. Anycommunication from that IP should be encrypted by the Hub before it reaches thespoke.By default, any communication received from an IP which is identified as an IP on the internet,and not encrypted, is dropped by the Spoke.Now a connection from the DMZ to an IP in the internal network is initiated. TheDMZ IP addresses are not part of the VPN domain, so the spoke considers themaddresses on the Internet. The spoke expects this connection to be encrypted by thecentral Hub. The connection is not encrypted so the connection is dropped. Nocommunication takes place between the DMZ and the internal network.This problem arises because Gateway A is defined as a spoke in a VPN community yetGateway A also acts as a router to IP addresses outside of the VPN community. Thisproblem is resolved by defining a default route for the DMZ.278

Defining a default Route for the DMZDefining a default Route for the DMZTo solve this problem, define a route through the spoke for IP addresses that are notpart of the VPN domain (in this case, IP addresses in the DMZ). Add a rule in the$CPDIR/Conf/vpn_route.conf file on the SmartCenter Server. The syntax of the fileis:Destination Next hop Router Install onDMZ Gateway_A Gateway_AThe rule states communication headed for IP addresses which are behind the spoke yetnot part of the VPN community (i.e. the DMZ) can be routed through the spoke’sinterface. This “extra” route is installed only on Gateway A. From Gateway A’sperspective, there is an addition to the routing table that defines the IP addresses of theDMZ as part of Gateway A’s VPN domain. Since this addition is only installed onGateway A, other Gateways will not see that specific DMZ as part of Gateway A’s VPNdomain.VPN Routing with External Gateways Functioning asSpokesVPN routing is also possible with external Gateways that are third party Gateways orGateways that are pre-NG with Application Intelligence. FIGURE 20-2 shows three VPNdomains arranged as Hubs and Spokes. Hub A and Spoke A are internally managedGateways. Spoke B is external. Spoke B is configured through a third partymanagement server that cannot process a vpn_route.conf file.FIGURE 20-2 External Gateway acting as a spokeChapter 20 Advanced VPN Connectivity Scenarios 279

Load Distribution between Gateways with Partially Overlapping VPN DomainsTo enable VPN routing between the spokes:• The SmartCenter Server of Hub A and Spoke A should be configured for VPNrouting in the usual way.• On the Management Server of Spoke B, include the VPN domain of spoke A intothe VPN domain of Hub A. From Spoke B’s perspective, traffic to hosts behindSpoke A terminates with Hub A. Hub A continues to route the traffic as required.Configuring an External Gateway as a Spoke1 On the SmartCenter Server for Hub A and Spoke A - configure VPN routing inthe usual way.2 On the external management server, define the VPN domain of Hub A to includeboth the hosts behind Hub A, and the VPN domain of Spoke A. (From Spoke B’sperspective, the Spoke A Gateway does not exist).Load Distribution between Gateways with PartiallyOverlapping VPN DomainsConsider the scenario presented in FIGURE 20-3. An organization consists of threeVPN domains: London, Paris, and New York. The organization has a number of vitalservers which must be accessible by hosts behind the New York Gateway. In order toensure high availability and load distribution for these servers, a dedicated leased lineconnects the London and Paris networks.Typically, hosts behind the New York Gateway reach these servers according to theconfigured selection mechanism, either Load distribution or First to Respond. However, ifthe London Gateway goes down, a host behind the New York Gateway can still accessthe servers by going through the Paris Gateway and across the dedicated leased line.For this to work, the IP addresses of the servers must be included in both the LondonVPN domain and the Paris VPN domain. The server’s IP addresses are common toboth. The VPN domain of London and Paris are said to be “partially overlapping”.280

Configuring Partially Overlapping VPN DomainsFIGURE 20-3 Partially overlapping VPN domainsConfiguring Partially Overlapping VPN DomainsTo configure two Gateways with a partially overlapping VPN domain1 On the network object representing the first Gateway, General Properties window >Topology page, VPN Domain section, click New...2 Create a new group that contains the hosts machines of the VPN domain.3 On the network object representing the second Gateway, General Propertieswindow > Topology page, VPN Domain section, click New...4 Create a new group that contains the host machines of the second VPN domainplus those machines that will belong to both domains.Both Gateways have VPN domains; a number of hosts belong to both.Cross Primary BackupIn this scenario, each primary Gateway in a Primary-Backup (MEPed) environmentfunctions as the backup of its own Backup Gateway. In FIGURE 20-4, London hasParis selected as its Backup Gateway, which makes London a Primary. Paris has Londonselected as its Backup Gateway, which makes Paris also a Primary. In this way, Londonand Paris are both Primary Gateways and Backup Gateways.Chapter 20 Advanced VPN Connectivity Scenarios 281

Cross Primary BackupFIGURE 20-4 Cross Primary BackupConfiguring Cross Primary BackupIn the network object Properties window for both Gateways, VPN page, select Usebackup Gateways. From the drop-down list, select the other as the backup. Selecting abackup Gateway turns the current Gateway into a Primary.282

Desktop SecurityThis section covers solutions for protecting remote access clients.

CHAPTER21Desktop Security -Protecting RemoteClientsIn This ChapterThe Need to Protect Remote Clients page 285Desktop Security Solution page 286Desktop Security Considerations page 290Configuring Desktop Security page 291The Need to Protect Remote ClientsA Check Point FireWall Module protects a network by enforcing a Security Policy onthe traffic to and from that network that passes through the FireWall Module. A remoteclient, located outside the protected network, is vulnerable to attack because traffic tothe remote client does not pass through the FireWall Module — no Security Policy isenforced on this traffic.There is a further danger: an attacker might gain access to a protected network bycompromising a remote client, which may in turn compromise the protected network(for example, by relaying a virus through the VPN tunnel). Even if the FireWallModule enforces a very restrictive Security Policy, the LAN remains vulnerable toattacks routed through unprotected remote clients.285

Desktop Security SolutionDesktop Security SolutionIn This SectionIntroducing Desktop Security page 286The Desktop Security Policy page 287Policy Server page 288Policy Download page 289Introducing Desktop SecurityCheck Point VPN-1 SecureClient protects remote clients by enforcing a DesktopSecurity Policy on the remote client. The administrator defines the Desktop SecurityPolicy in the form of a Rule Base. Rules can be assigned either to specific user groupsor to all users, enabling the definition of flexible policies.The Desktop Security Policy is downloaded by the SmartCenter Server to a PolicyServer, a module installed on a VPN-1 Pro gateway, which serves as a repository for theDesktop Security Policy. SecureClient machines download their Desktop SecurityPolicies from the Policy Server.When a SecureClient connects to the organization’s gateway to establish a VPN, it canconnect to a Policy Server as well and retrieve its Desktop Security Policy and beginenforcing it. SecureClient can accept, encrypt or drop connections depending on theirSource, Destination and Service.FIGURE 21-1 Retrieving the Desktop Security Policy from a Policy Server286

The Desktop Security PolicyThe Desktop Security PolicyThe Desktop Security Policy is divided into two parts:• inbound rules — enforced on connections destined to the SecureClient machine• outbound rules — enforced on connections originating from the SecureClientmachineA rule in a Desktop Security Policy specifies the following:• source• destination• service• action (accept, drop, encrypt)• track (log, alert)Connections to machine inside the organization (i.e. all the machines in the VPNdomain of the gateway) are automatically encrypted, even if the rule allowing them topass is an accept rule.Implied RulesIn addition to the inbound and outbound rules explicitly defined by the administrator,implicit “cleanup” rules are automatically appended at the end of both the inbound andoutbound policies:• The outbound implicit rule allows all connections originating from theSecureClient machine, thus allowing connections which do not match any of theprevious rules.• The inbound implicit rule blocks all connections destined to the SecureClientmachine which do not match any of the previous rules, on the assumption thatwhat is not explicitly allowed is to be rejected.User GranularityYou can define different rules for remote users based on location and user groups:Location — For example, you can define a less restrictive policy for a userconnecting from within the organization (e.g., a user with SecureClient installed onhis laptop connecting from within the organization), and a more restrictive policy forthe same user connecting from outside the organization (from a hotel room). This isdone in the user’s security Rule Base by configuring the location of the users forwhich the rule should be implemented.User Groups — For example, you can define restrictive rules for ordinary users, butallow system administrators more access privileges.Chapter 21 Desktop Security - Protecting Remote Clients 287

Desktop Security SolutionIn addition, you can define rules to be enforced for all remote users, by not specifyinga specific user group, but rather all users.Rules do not specify individual users but rather user groups. Because SecureClient doesnot know to which groups the currently logged-in user belongs, it must obtain thisinformation from the Policy Server as follows: after SecureClient authenticates itself tothe Policy Server, the Policy Server resolves the user groups to which the user belongsand sends this information to SecureClient. Once SecureClient knows to which groupsthe user belongs, it is able to enforce the rules defined for that user.Default PolicyWhen SecureClient is started, and before it connects to the Policy Server, it enforces a“default policy”, which consists of the rules defined for all users in the last policydownloaded from the Policy Server. This is because at this point, SecureClient does notknow to which user groups the user belongs. The default policy is enforced until theuser downloads an updated policy (and the current user’s groups information) from aPolicy server.If a SecureClient loses its connection to the Policy Server, it enforces the default policyuntil the connection is restored and a Policy is downloaded.Policy ServerWhat is a Policy Server?A Policy Server is a module installed on a VPN-1 Pro gateway, which serves as arepository for the Desktop Security Policy. SecureClient machines download theirDesktop Security Policies from the Policy Server.High Availability and Load BalancingFor load balancing and high availability, you can configure multiple Policy Servers. Loadbalancing can be especially important at times of high load, for example, when a largenumber of users log in at the beginning of the work day.Connect Mode• High Availability between all Policy Servers, trying selected first — SecureClientwill always try the specified Policy Server first. If this server is unavailable, theSecureClient will randomly choose a different server from among the remainingservers.• High Availability only among selected Policy Servers — SecureClient willrandomly choose a Policy Server from the specified group. This option providesLoad Balancing as well, since the load will be more equally distributed amongthe Policy Servers.288

Policy DownloadTransparent ModeSecureClient will connect to a Policy Server based on the setting for Transparent Mode:• Choose next Policy Server - SecureClient will attempt to connect to the nextPolicy Server defined. This option provides High Availability.• Choose Policy Server randomly - SecureClient will attempt to connect to arandomly chosen Policy Server. This option provides both High Availability andLoad Balancing.FIGURE 21-2 SecureClient fails to retrieve a policy from a Policy server, selects alternative.Policy DownloadWhen is a Policy Downloaded?When a user creates a site in SecureClient, a list of Policy Servers is downloaded to theclient’s machine. If the user is using Connect mode (the default mode), a policy will beautomatically downloaded from a Policy Server when the SecureClient machineconnects to the site. The automatic policy download can also be disabled — thisconfiguration is controlled in the user’s profile.In Transparent mode, the policy download is manually initiated by the user. However,SecureClient can be configured to automatically download a policy from a PolicyServer when SecureClient starts.Policy RenewalIf a time-out is defined for a policy (default is 60 minutes), SecureClient will reconnectto the Policy Server to download a new policy when half specified time period haselapsed. If more than one Policy Server is defined (see “High Availability and LoadChapter 21 Desktop Security - Protecting Remote Clients 289

Desktop Security ConsiderationsBalancing” on page 288) SecureClient will try to reconnect to the Policy Server fromwhich it last successfully downloaded a policy. If it cannot connect to that PolicyServer, it will try the others.If SecureClient cannot download a new policy from any Policy Server, it will try againafter a fixed interval (default is 5 minutes). If SecureClient fails to download a newpolicy after the timeout expires, it will revert to the default policy.Logs and AlertsLogs and alert specified Desktop Security Policy can be viewed using the SecureClientDiagnostics. In addition, all alerts are saved and uploaded to the SmartCenter Server.When the client connects to a Policy Server, it uploads the alerts to a spooling process,which passes the alerts to the SmartCenter Server, where they can be viewed by theSmartView Tracker.Desktop Security ConsiderationsIn This SectionPlanning the Desktop Security Policy page 290Avoiding Double Authentication for Policy Server page 291Planning the Desktop Security PolicyYou should carefully plan your users policy, properly balancing considerations ofsecurity and convenience. The policy should allow the desktop users to work as freelyas possible, but at the same time make it hard to attack the remote user’s desktop. Hereare some points to consider:• You should not explicitly allow any service to be opened to the SecureClient (i.e.allow a service in the inbound policy), unless the user has a specific server runningon that port. Even if you do allow connections to be opened to the client, be verycareful about who is allowed to open the connection, and from where.• A restrictive policy (e.g., allow only POP3, IMAP and HTTP and block all therest) will make it more difficult for your users to work. If you allow only specificservices in the outbound policy and block all the rest, every time you will find outthat a certain service is needed by your users, you will have to change the outboundpolicy and make sure the clients poll the new policy. The best way to implementthe outbound policy is to use rules only to block specific problematic services (suchas Netbus) and allow the rest.290

Avoiding Double Authentication for Policy Server• Outbound connections to the encryption domain of the organization are alwaysencrypted, even if the outbound rule for the service specifies “accept”.• Keep in mind that the implied rules (see “Implied Rules” on page 287) may allowor block services which were not explicitly handled in previous rules. For example,if your client runs a server on his machine, you must create an explicit rule allowingthe connection to the client’s machine. If you do not, the connection will beblocked by the inbound implicit block rule.Avoiding Double Authentication for Policy ServerWhen using Policy Server High Availability, it is possible that users will connect to theorganization through one gateway and to a Policy Server which is installed on adifferent module. In this case they will be prompted twice for authentication — oncefor the gateway module and the other for the Policy Server. If a user usually connectsto the organization through a specific gateway, and this gateway has a Policy Servermodule installed on it, this double authentication can be avoided by configuring theuser’s profile to use the High Availability among all Policy Servers, trying selected firstoption, and selecting the primary Policy Server as that one the gateway through whichthe user usually connects to the organization. This way, after the user authenticates tothe gateway, he will automatically be authorized to download the security policy fromthe Policy Server installed on that gateway.Configuring Desktop SecurityIn This SectionServer Side Configuration page 291Client Side Configuration page 292Server Side Configuration1 Install the Policy Server add-on module from the Check Point installation CD. ThePolicy Server add-on should be installed only on machines that have VPN-1 Progateway modules installed on them.2 Open the Gateway object on which you have installed a Policy Server and selectthe General Properties tab. In the Check Point Products section select SecureClientPolicy Server.3 Go to the Authentication tab. In the Policy Server>Users section select a group ofusers that is allowed to retrieve policies from this Policy Server.4 Repeat steps 2 and 3 for each additional Policy Server.Chapter 21 Desktop Security - Protecting Remote Clients 291

Configuring Desktop Security5 Go to Policy>Global Properties and select the Remote Access tab. In Revert todefault policy after, select the time-out for desktop security policies (see “PolicyRenewal” on page 289 for more information).6 In the Use Backup Servers on Logon Failure (Transparent Mode only) section you canspecify that clients connected in transparent mode will attempt to connect toanother Policy Server if the initial logon attempt to a Policy Server failed. Choosebetween two High Availability modes: Choose next Policy Server and Choose PolicyServer randomly.7 In the policy selection toolbar, select Desktop Security.8 Configure the inbound rules. Using the Rules>Add Rule menu item, you can addrules to the policy.In inbound rules, the SecureClient (the desktop) is the destination, and you canspecify the users to which the rule is to be applied.9 Configure the outbound rules.In outbound rules, the SecureClient (the desktop) is the source, and you can specifythe users to which the rule is to be applied.10 Install the policy. Be sure to install both the Advanced Security policy on thegateways and the Desktop Security policy on your Policy Servers.Client Side ConfigurationConnect Mode1 Double click your SecureClient icon at the bottom right side of you desktop andpress Properties.2 Choose Logon to Policy Server if you wish to logon to a Policy Server automaticallyafter connecting to a site.3 Select Support Policy Server High Availability if your site has several Policy Serversand you want SecureClient to attempt to load balance between them. If you chooseto use this feature you must select one of the following:• High Availability among all servers, trying selected first — Select the primaryPolicy Server.• High Availability only among selected servers — Select the servers to which youwish to connect.As an administrator, you can eliminate the user’s need to configure these steps bycreating a custom profile for them.292

Client Side ConfigurationTransparent ModeTo logon to a Policy Server, proceed as follows:1 Create a site for the organization. If you already have a site for the organization,double click its icon and press Update, to update the topology.2 Go to Policy>Logon to Policy Server and select a Policy Server to which to connect.If the menu item is disabled, then your administrator had not defined a PolicyServer for you.Chapter 21 Desktop Security - Protecting Remote Clients 293

Configuring Desktop Security294

CHAPTER22Secure ConfigurationVerification - SCVIn This ChapterThe Need to Verify Remote Client’s Security Status page 295The Secure Configuration Verification Solution page 296Considerations regarding SCV page 300Configuring SCV page 302The Need to Verify Remote Client’s Security StatusNetwork and Firewall administrators can easily control computers inside theirorganization. In a Microsoft domain based environment, this is done by controlling theuser’s privileges through the network domain controller. The administrator can disablehazardous components such as Java and ActiveX controls in browsers, install anti-viruscheckers and make sure they are running correctly.In the case of remote users, the administrator’s options are limited, because remote usersaccess the organization from outside the LAN (e.g., across the Internet), and are usuallyunable to connect to the domain. The administrator cannot control and verify theirconfiguration through the domain controller.For example, suppose the remote user has ActiveX enabled, and connects to a websitecontaining a malicious ActiveX control which infects his or her computer. When theremote user connects to the organization’s LAN, the LAN becomes vulnerable as well.Even a properly configured Desktop Security Policy, important as it is, does not affordprotection against this type of attack, because the attack does not target a vulnerabilityin the access control to the user’s machine, but rather takes advantage of the vulnerableconfiguration of applications on the client.295

The Secure Configuration Verification SolutionThe Secure Configuration Verification SolutionIn This SectionIntroducing Secure Configuration Verification page 296How does SCV work? page 296SCV Checks page 299SCV Policy Syntax page 303The local.scv sets page 307A complete example of a local.scv file page 309Introducing Secure Configuration VerificationSecure Configuration Verification (SCV) enables the administrator to monitor theconfiguration of remote computers, to confirm that the configuration complies withthe organization’s Security Policy, and to block connectivity for machines that do notcomply. SCV does not replace the Desktop Security Policy, but complements it. SCVstrengthens enterprise security by ensuring SecureClient machines are configured inaccordance with the enterprise Security Policy.SCV is a platform for creating and using SCV checks. SCV checks include sets ofconditions that define a securely configured client system, such as the user’s browserconfiguration, the current version of the anti-virus software installed on the desktopcomputer, the proper operation of the personal firewall policy, etc. These securitychecks are performed at pre-defined intervals by SecureClient. Depending on theresults of the SCV checks, the VPN-1 Pro Gateway decides whether to allow or blockconnections from the client to the LAN.Check Point’s SCV solution comes with a number of predefined SCV checks for theoperating system and user’s browser, and it also allows OPSEC partners, such asanti-virus software manufacturers, to add SCV checks for their own products.How does SCV work?SCV works in six steps:1 Installing SCV plugins on the client.2 Configuring and SCV Policy on the SmartCenter Server.3 Downloading the SCV Policy to the Client.4 Verifying the SCV Policy296

How does SCV work?5 Runtime SCV checks6 Making the organizational Security Policy SCV awareInstalling SCV Plugins on the ClientSCV checks are performed through special DLLs which check elements of the client’sconfiguration and return the results of these checks. An SCV application registers itsSCV DLLs in the system registry.The first step in configuring SCV is for the administrator to install the applications thatprovide the SCV checks on the client. During installation, these applications registerthemselves as SCV plug-ins and write a hash value of their SCV DLLs to preventtampering.Configuring an SCV Policy on the SmartServerAn SCV Policy is a set of rules or conditions based on the checks that the SCV plug-insprovide. These conditions define the requested result for each SCV check, and on thebasis of the results, the client is classified as securely configured or non-securelyconfigured. For example, an administrator who wishes to disallow a file-sharingapplication would define a rule in the SCV Policy verifying that the file-sharingapplication process is not running.Note - The SCV check described in this example is among the pre-defined SCV checksincluded with SmartCenter Server (see “Check Point SCV Checks” on page 299). This checkmust be configured to test for the specific process.If all the SCV tests return the required results, the client is considered to be securelyconfigured. If even one of the SCV tests returns an unexpected result, the client isconsidered to be non-securely configured.Downloading the SCV Policy to the ClientWhen SecureClient downloads its Desktop Policy from the Policy Server, it downloadsits SCV Policy at the same time.Verifying the SCV PolicyAfter downloading the SCV Policy, SecureClient confirms that the SCV DLL’s specifiedin the SCV Policy have not been tampered with by calculating their hash values andcomparing the results with the hash values specified for the DLLs when they wereinstalled (see Installing SCV Plugins on the Client).Chapter 22 Secure Configuration Verification - SCV 297

The Secure Configuration Verification SolutionRuntime SCV ChecksAt regular intervals (default is every 15 seconds), SecureClient performs the SCVchecks specified in the SCV Policy by invoking the SCV DLLs, and compares theresults to the SCV Policy. The SCV Policy can be configured to display a popupnotification on non-securely configured clients and/or send a log to the SmartCenterServer.Making the Organizational Security Policy SCV-AwareSecureClient is now able to determine whether the client is securely configured. Onceall the organization’s clients have been configured according to the previous steps, theadministrator specifies the actions to be taken on the VPN gateway based on the client’sSCV status. For example, the administrator can specify that non-securely configuredclients cannot access some or all of the resources on the corporate LAN, protecting theorganization from the dangers associated with the client’s poor security configuration.The administrator can choose whether to enforce SCV for remote clients. If SCV isenforced, only securely configured clients are allowed access under the rule. If SCV isnot enforced, all clients are allowed access under the rule.In simplified mode, this is configured globally. In traditional mode, this is configuredindividually for each rule. See “Server Side Configuration” on page 302 for moreinformation.When the client connects to a VPN-1 Pro gateway, an IKE negotiation takes placebetween SecureClient and the gateway. If the gateway’s Security Policy requires an SCVcheck to be made, the gateway holds the connection while it checks if the client issecurely configured (SCVed). If the gateway already knows the client’s SCV status (i.e.,the SCV status was checked in the last 5 minutes), then:• If the client is securely configured, the gateway allows the connection.• If the client is not securely configured, the gateway either drops the connection, oraccepts and logs it (this behavior is configurable).If the gateway does not know the client’s SCV status, it initiates an SCV check bysending an ICMP unreachable error message containing an SCV query to the client.When a client gets this SCV query, it tries to determine its SCV status. In Connectmode, the client also connects to a Policy Server to download an updated SCV Policy.In parallel, when the client gets the SCV query, it starts sending SCV status replies tothe gateway via UDP port 18233 every 20 seconds for 5 minutes. These replies are usedas a keep-alive mechanism, in order to keep the user’s connection alive in the gateway’sstate tables while the client is trying to determine its SCV status. The keep alive packetsalso allow the user to open subsequent connections in the 5 minute period in whichthey are sent without a need for further SCV queries. When the client determines its298

SCV ChecksSCV status, it sends an SCV reply containing the status back to the gateway via UDPport 18233. When the gateway receives the SCV status of the user, it decides how tohandle the user’s connection.SCV ChecksCheck Point SCV ChecksA number of SCV checks are provided as part of the SecureClient installation,including:• SC_VER_SCV — a version check that verifies that the SecureClient version is upto date, according to the administrator’s specification.• Network Configuration Monitor — verifies that:• the Desktop Policy is enforced by SecureClient on all network interface cards• non-IP protocols are not enabled on any interface• OS Monitor — verifies the remote user’s Operating System version, Service Pack,and Screen Saver configuration (activation time, password protection, etc.).• HotFix Monitor — verifies that operating system security patches are installed, ornot installed.• Group Monitor — verifies whether the user had logged on the machine and thatthe user is a member of certain Domain User Groups specified by the administrator.• Process Monitor — checks whether a specified process is running on the clientmachine (e.g. that a file sharing application is not running, or that anti-virussoftware is running). Process Monitor may also check whether a process is notrunning.• user_policy_scv — checks the state of the desktop policy, i.e. whether the user islogged on to a policy server, and whether the desktop policy is recent.• Browser Monitor — verifies the Internet Explorer version and specific IEconfiguration settings, such as various Java and ActiveX options.• Registry Monitor — verifies that a certain key or value is present in the systemregistry. RegMonitor may check not only for the existance/exclusion of keys butalso their content.• ScriptRun — runs a specified executable on SecureClient machine and tests thereturn code of the executable (e.g. a script that checks whether a certain file ispresent and sets a return code accordingly). ScriptRun can run a script whichperforms additional configuration checks.• Anti-Virus Monitor — detects whether an anti-virus program is running andchecks its version. Supported anti-virus programs: Norton, Trend Office Scan, andMcAfee.Chapter 22 Secure Configuration Verification - SCV 299

Considerations regarding SCV• SCVMonitor — verifies the version of the SCV product, specifically the versionsof the SCV DLLs installed on the client’s machine.• HWMonitor — verifies the CPU type, family, and model.Third Party SCV ChecksSCV checks can be written by third party vendors using Check Point’s OPSEC SCVSDK. After these applications are installed, the administrator can use these SCV checksin the SCV Policy.Additional Script Elements• SCVpolicy — selects SCV checks out of the ones defined in SCVNames (see:“SCVNames” on page 308) that will run on the user’s desktop.• SCVGlobalParams — is used to define general SCV parameters.A network administrator can easily enable a set of specific SCV checks (e.g. only checkthat the user’s SecureClient is enforcing a security policy) or as many SCV checks asrequired (e.g. all of the above SCV checks). The SCV checks are performedindependently by the SCV Dynamic Link Libraries, and SecureClient checks theirstatus through the SCV plugins every 15 seconds, and determines whether the user issecurely configured or not. If one or more of the tests fails, the SecureClient isconsidered to be non-securely configured.Note - To enforce a specific SCV check, set the parameters of the check in the SCVNamessection, and include the name of the check in SCVPolicy.Considerations regarding SCVIn This SectionPlanning the SCV Policy page 300User Privileges page 301Using pre-NG Clients with SCV page 301Planning the SCV PolicyThe file $FWDIR/conf/local.scv on the SmartCenter Server contains a sample of abasic SCV policy for checks that are supplied with any SCV installation. You canreview this file to help you decide which SCV tests to perform. If you need additionalSCV checks for OPSEC products, such as anti-virus and integrity SCV checks, visit:http://www.opsec.com.300

User PrivilegesUser PrivilegesTo implement SCV effectively, it is suggested that you consider not to allow yourremote users to have administrative privileges on their desktops. Giving the usersadministrative privileges can allow them to change system settings and cause SCV teststo fail. A desktop which fails an SCV check is a potential security threat to theorganization.For example, as an administrator you may want to configure the user’s browser not toallow him to download Java applets from websites. A normal user will not be able todownload these applets, but a user with administrative privileges can override thebrowser’s configuration. A properly defined SCV policy can indicate that the browser’sconfiguration had changed and trigger a proper action on the gateway side. However, ifthe user is allowed by the gateway to pass to the LAN - either by a wrong configurationof the SCV policy or lack of enforcement of the user’s SCV status on the gateway side- then the user’s desktop will become a potential security risk to the LAN.The SCV policy itself is protected. Users can not change the SCV policy definition filesthey receive, even if they have administrative rights. The SCV policy files supplied tothe client are signed before arriving to the client and checked against their signature bySecureClient. If the signatures do not match, the SCV check fails.Using pre-NG Clients with SCVPre-NG clients do not include the SCV mechanism described above. Version 4.1clients, for example, can perform only a limited set of SCV tests:• check that one of several predefined Security Policies is installed on all interfaces• check that IP forwarding is not enabled• check that non TCP/IP protocols are not installedUsing SCV with these clients is limited to these tests only, and does not offer thecomplete SCV functionality described above. It is possible to configure the gateway torely on these tests to determine the SCV status of the client, however this is somewhatmisleading, since it doesn’t offer an indication about the security level of the user’sdesktop in the parameters that were not covered by these basic tests.In general, it is recommended to upgrade earlier clients to the latest versions, in orderto benefit from the enhancements added to the SCV mechanism in the new versions.Chapter 22 Secure Configuration Verification - SCV 301

Configuring SCVConfiguring SCVIn This SectionServer Side Configuration page 302Client Side Configuration page 303SCV Policy Syntax page 303Server Side Configuration1 First you need to configure several general parameters regarding SCV. Open yourSmartDashboard and go to Policy > Global Properties and select the Remote Access> Secure Configuration Verification (SCV) tab. This tab has several options:• Apply Secure Configurations on Simplified Mode - specifies whether all remoteaccess rules in the simplified policy mode should have the SCV flag turned on.• Upon Verification failure - specifies the action that should be performed whenthe client fails one or more SCV checks. The options are to Block the client’sconnection or to Accept it and send a log about the event.• Basic configuration verification on client’s machine - specifies whetherSecureClient should perform SCV checks to determine whether the policy isinstalled on all network interfaces cards on the client’s desktop, and whetheronly TCP/IP protocols are installed on these interfaces.• Configurations Violation Notification on client’s machine - specifies whether a logrecord should be saved on the SmartCenter machine indicating that a remoteuser is not SCVed (this is a general indication, without a specification of acertain SCV check the user’s desktop had failed).2 To configure whether earlier clients, prior to NG, are considered SCVed, go toPolicy>Global Properties and select the Remote Access>Early Version Compatibilitytab. In this tab you can choose the Required policy for all desktops from the list ofpredefined policies. Select Client is enforcing required policy if you wish that earlierclients that do not enforce the selected policy will not be considered SCVed.3 Close the Global Properties screen.4 If you are using simplified mode (the mode that supports VPN communities), skipthis step. If you are using traditional mode, edit your Security Policy Rule base andadd SCV checks for your remote access rules (Client Encrypt or Client Auth rules).To enable SCV for a remote access rule, right click on the action tab of the ruleand choose Edit properties>Apply rule Only if Desktop Configuration is Verified.Close the properties screen by pressing OK.302

Client Side Configuration5 Edit the local.scv file in the $FWDIR/conf directory and configure the SCVpolicy. For more information, see SCV Policy Syntax page 303 and The local.scv setspage 307.6 Install the policy - in the policy install dialog box select the Advanced Securitypolicy for the gateways and the Desktop Security policy for the Policy Servers.Client Side Configuration1 If you intend to use an OPSEC SCV application, install the application on theclient and enable the application’s integration with SCV (see the application’sdocumentation for information on how to do this).2 Start SecureClient and connect to the gateway to receive the SCV Policy. If you areusing transparent mode on the client, you must manually select to download theSecurity Policy from the Policy Server, unless the client is specifically configured toconnect automatically to a Policy Server. See: “Desktop Security - ProtectingRemote Clients”” for more information.SCV Policy SyntaxThe SCV Policy is configured by the administrator in the text file$FWDIR/conf/local.scv. This file can be edited either manually by the administratorusing a text editor or using a tool called SCVEditor, available at:http://www.opsec.com. The local.scv file is a policy file, containing sets, subsets andexpressions.Note - In general, you can use the pre-defined checks (in the SCVNames section of thelocal.scv file) as templates and list the modified checks in the SCVPolicy section, withoutwriting new SCV subsets.Sets and Sub-setsEach set has a certain purpose which was predefined for it. For example, one set can beused to define certain parameters, another could specify certain actions that should takeplace in a certain event etc. Sets are differentiated by their names and hierarchy in arecursive manner. Each set can have a sub-set, and each sub-set can have a sub-set of itsown and so on. Subsets can also contain logical expressions. Sets and sub-sets with moreChapter 22 Secure Configuration Verification - SCV 303

Configuring SCVthan one sub-sets/conditions are delimited by left and right parentheses (), and startwith the set/sub-set name. Differentiation between sub-sets/expressions with the samehierarchy is done using the colon :. For example:(SetName:SubSetName1 (:ExpressionName1_1 (5):ExpressionName1_2 (false)):SubSetName2 (:ExpressionName2_1 (true):SubSetName2_1 (:ExpressionName2_1_1 (10))))In the example above the set named SetName has two subsets: SubSetName1 andSubSetName2. SubSetName1 has two conditions in it (ExpressionName1_1 andExpressionName1_2). SubSetName2 has one condition (ExpressionName2_1) and onesubset (SubSetName2_1) in it. SubSetName2_1 has one condition as well(ExpressionName2_1_1).ExpressionsExpressions are evaluated by checking the value of the expression (which correspondsto an SCV check) and comparing it with the value defined for the expression (the valuein the parentheses). For example, in the browser monitor SCV check provided withSecureClient, you can specify the following expression::browser_major_version (5)This expression checks whether the version of the Internet Explorer browser installedon the client is 5.x. If the (major) version is 5, this expression is evaluated as true,otherwise it is evaluated as false. The name of the expression (e.g.“browser_major_version”) is determined by the SCV application and is supplied bymanufacturer.If several expressions appear one after the other, they are logically ANDed, meaningthat only if all expressions are evaluated as true, then the value of all of them takentogether is true. Otherwise (if even one of the expressions is false), the value of all ofthem is false. For example::browser_major_version (5):browser_minor_version (0)304

SCV Policy SyntaxThese expressions are ANDed. If the version of Internet Explorer is 5 AND the minorversion is 0 (i.e. version 5.0), then the result is true, otherwise it is false. If the versionof Internet Explorer is, for example, 4.0, then the first expression is false and the secondone is true, and the result of both of them is false.Sometimes, some expressions can influence the way in which others are evaluated. Forexample::browser_major_version (5):browser_minor_version (0):browser_version_operand (">=")These expressions are ANDed, but the third expression influences the way that the firstand second ones are evaluated. In the example above, if the version of Internet Exploreris greater than or equal to (“>=”) 5.0, then the result is true, otherwise it is false. If theversion of Internet Explorer is, for example, 4.5, then the result is false, if the version is5.1 or higher then the result is true.Logical SectionsAs mentioned earlier, subsequent expressions are automatically ANDed. However,sometimes it is necessary to perform a logical OR between expressions, instead oflogical AND. This is done by using labels:The begin_or (orX) label - this label starts a section containing several expressions. Theend of this section is marked by a end (orX) label (X should be replaced with a numberwhich differentiates between different sections OR sections). All of expressions insidethis section are logically ORed, producing a single value for the section. For example::begin_or(or1):browser_major_version (5):browser_major_version (6):end(or1)This section checks whether the version of Internet Explorer is 5 OR 6 - if it is thenthe result is true, otherwise it is false.The begin_and (andX) label - this label is similar to the begin_or (orX) label, but theexpressions inside are evaluated and logically ANDed. The end of this section is markedby a end (andX) or the end (orX) label. As mentioned earlier, simple subsequentexpressions are automatically ANDed. The reason that this label exists is to allow nestedANDed sections inside ORed sections. For example, if an administrator considers oldChapter 22 Secure Configuration Verification - SCV 305

Configuring SCVbrowsers as secure since they do not have a lot of potentially unsafe components, andnew browsers as secure, since they contain all the latest security patches, he can definethe following SCV rules::begin_or (or1):begin_and (and1):browser_major_version (5):browser_minor_version (0):browser_version_operand (">="):end (and1):begin_and (and2):browser_major_version (3):browser_minor_version (0):browser_version_operand ("

The local.scv setsFor example::browser_major_version (5):browser_minor_version (0):browser_version_operand (">="):begin_admin (admin):send_log (alert):mismatchmessage ("The version of your Internet Explorer browseris old. For security reasons, users with old browsers are notallowed to access the local area network of the organization.Please upgrade your Internet Explorer to version 5.0 or higher.If you require assistance in upgrading or additional informationon the subject, please contact your network administrator”):end (admin)In this example, if the user’s IE browser’s version is lower than 5.0, an alert is sent to theSmartCenter machine and a popup message is shown to the user with indication of theproblem.The local.scv setsThe local.scv policy files contains one set called SCVObject. This set must always bepresent and contains all the subsets which deal with the SCV checks and parameters.Currently SCVObject has 3 subsets:• SCVNames - This section is the main SCV policy definition section, in which allof the SCV checks and actions are defined. This is the definition part of theSCV policy, and doesn’t actually determine the SCV checks that will beperformed. In this section sets of tests are defined. Later on, the administratorwill choose from these sets those he wants to run on the user’s desktop.• SCVPolicy - This section specifies the names of the SCV checks that shouldactually be performed on the client’s machine, from the SCV checks defined inSCVNames.• SCVGlobalParams - This section contains some global SCV parameters.Chapter 22 Secure Configuration Verification - SCV 307

Configuring SCVSCVNamesIn this section the administrator specifies the names and different checks for the SCVproducts. Here is a general definition of an SCV check subset of SCVNames:: (SCVCheckName1:type (plugin):parameters (:Expression1 (value):Expression2 (value):begin_admin (admin):send_log (alert):mismatchmessage ("Failure Message"):end (admin)))The test section begins with the name of the SCV check (SCVCheckName1).SCVCheckName1 defines the name of the set of tests. It is defined in the SCVapplication and should be provided by the SCV manufacturer. The type (plugin)expression specifies that the test is performed by an SCV DLL plugin. The parameterssubset is where the SCV rules and actions are defined. The type (plugin) expression andthe parameters subset should always be specified when defining a subset of SCV checks(such as SCVCheckName1).SCVPolicyThis section defines the names of the SCV checks that should be enforced (the namesare part of the SCV check names specified in SCVNames). This section’s generalstructure is::SCVPolicy (:(SCVCheckName1):(SCVCheckName2))Note - there is a space between the colon (:) and the opening brace.The Difference between SCVNames and SCVPolicy• The SCVNames section defines the different parameters for the checks.• The SCVPolicy section states which checks are enforced.To enforce a specific SCV check:• Set the check’s parameters in SCVNames.• Include the name of the check in SCVPolicy.308

A complete example of a local.scv fileSCVGlobalParamsThis section includes global parameters for SCV.:SCVGlobalParams (:enable_status_notifications (true):status_notifications_timeout (10):disconnect_when_not_verified (false):block_connections_on_unverified (false):scv_policy_timeout_hours (24):enforce_ip_forwarding (true):not_verified_script ("myscript.bat"):not_verified_script_run_show (true):not_verified_script_run_admin (false):not_verified_script_run_always (false))A complete example of a local.scv fileFollowing is a complete example of a policy.scv file.Note that in the following example the internal syntax of some of the SCV subsetsdiffers from the syntax described earlier. SCV policy syntax has evolved in recentversions, while these SCV checks were written using the old syntax. For example, inthe sc_ver_scv subset, the begin_admin (admin) - end (admin) section does not exist. Inaddition, the mismatchmessage expression which was in this section is replaced withMismatchMessage (using capital letters) expression. The syntax and operation ofMismatchMessage is similar to the one specified for mismatchmessage, although it doesnot appear in a begin_admin (admin) - end (admin) section.Another difference in the sc_ver_scv subset compared to the syntax explained aboveconcerns the EnforceBuild_XX_Operand and SecureClient_XX_BuildNumberexpressions. These expressions are not ANDed but rather evaluated automatically inaccordance with the operating system the user has. For example, if the user has aWindows 2000 system, only the EnforceBuild_2K_Operand andSecureClient_2K_BuildNumber expressions are evaluated, and the expressions relatingto different operating systems are not.Some other minor changes from the described syntax appear in the local.scv policyfile. You can review the changes in the default local.scv policy file. In general, youcan use the pre-defined checks (in the SCVNames section) as templates and list themodified checks in the SCVPolicy section, without writing new SCV subsets.Note - To enforce a specific SCV check, set the parameters of the check in the SCVNamessection, and include the name of the check in SCVPolicy.Chapter 22 Secure Configuration Verification - SCV 309

Configuring SCVSample(SCVObject:SCVNames (: (user_policy_scv:type (plugin):parameters ()): (BrowserMonitor:type (plugin):parameters (:browser_major_version (5):browser_minor_version (0):browser_version_operand (">="):browser_version_mismatchmassage ("Please upgrade your Internetbrowser."):intranet_download_signed_activex (disable):intranet_run_activex (disable):intranet_download_files (disable):intranet_java_permissions (disable):trusted_download_signed_activex (disable):trusted_run_activex (disable):trusted_download_files (disable):trusted_java_permissions (disable):internet_download_signed_activex (disable):internet_run_activex (disable):internet_download_files (disable):internet_java_permissions (disable):restricted_download_signed_activex (disable):restricted_run_activex (disable):restricted_download_files (disable):restricted_java_permissions (disable):send_log (alert):internet_options_mismatch_message ("Your Internet browser settingsdo not meet policy requirements\nPlease check the following settings:\n1.In your browser, go to Tools -> Internet Options -> Security.\n2. For eachWeb content zone, select custom level and disable the following items:DownLoad signed ActiveX, Run ActiveX Controls, Download Files and JavaPermissions."))): (OsMonitor:type (plugin):parameters (:os_version_mismatchmessage ("Please upgrade your operating system."):enforce_screen_saver_minutes_to_activate (3)310

A complete example of a local.scv file:screen_saver_mismatchmessage ("Your screen saver settings do notmeet policy requirements\nPlease check the following settings:\n1. Rightclick on your desktop and select properties.\n2. Select the Screen Savertab.\n3. Under Wait choose 3 minutes and check the Password Protectionbox."):send_log (log):major_os_version_number_9x (4):minor_os_version_number_9x (10):os_version_operand_9x (">="):service_pack_major_version_number_9x (0):service_pack_minor_version_number_9x (0):service_pack_version_operand_9x (">="):major_os_version_number_nt (4):minor_os_version_number_nt (0):os_version_operand_nt ("=="):service_pack_major_version_number_nt (5):service_pack_minor_version_number_nt (0):service_pack_version_operand_nt (">="):major_os_version_number_2k (5):minor_os_version_number_2k (0):os_version_operand_2k ("=="):service_pack_major_version_number_2k (0):service_pack_minor_version_number_2k (0):service_pack_version_operand_2k (">="):major_os_version_number_xp (5):minor_os_version_number_xp (1):os_version_operand_xp ("=="):service_pack_major_version_number_xp (0):service_pack_minor_version_number_xp (0):service_pack_version_operand_xp (">="))): (ProcessMonitor:type (plugin):parameters (:begin_or (or1):AntiVirus1.exe (true):AntiVirus2.exe (true):end (or1):IntrusionMonitor.exe (true):ShareMyFiles.exe (false):begin_admin (admin):send_log (alert):mismatchmessage ("Please check that the following processes arerunning:\n1. AntiVirus1.exe or AntiVirus2.exe\n2.IntrusionMonitor.exe\n\nPlease check that the following process is notrunning\n1. ShareMyFiles.exe"):end (admin)))Chapter 22 Secure Configuration Verification - SCV 311

Configuring SCV: (groupmonitor:type (plugin):parameters (:begin_or (or1):begin_and (1):"builtin\administrator" (false):"BUILTIN\Users" (true):end (1):begin_and (2):"builtin\administrator" (true):"BUILTIN\Users" (false):end (and2):end (or1):begin_admin (admin):send_log (alert):mismatchmessage ("You are using SecureClient with a non-authorizeduser.\nMake sure you are logged on as an authorized user."):securely_configured_no_active_user (false):end (admin))): (HotFixMonitor:type (plugin):parameters (:147222 (true):begin_admin (admin):send_log (alert):mismatchmessage ("Please install security patch Q147222."):end (admin))): (AntiVirusMonitor:type (plugin):parameters (:type ("Norton"):Signature (">=20020819"):begin_admin (admin):send_log (alert):mismatchmessage ("Please update your AntiVirus (use the LiveUpdateoption)."):end (admin))): (HWMonitor:type (plugin):parameters (:cputype ("GenuineIntel"):cpumodel ("9"):cpufamily ("6")312

A complete example of a local.scv file:begin_admin (admin):send_log (alert):mismatchmessage ("Your machine must have an\nIntel(R) Centrino(TM)processor installed."):end (admin))): (ScriptRun:type (plugin):parameters (:exe ("VerifyScript.bat"):begin_admin (admin):send_log (alert):mismatchmessage ("Verification script has determined that yourconfiguration does not meet policy requirements."):end (admin))): (RegMonitor:type (plugin):parameters (:value("Software\TrendMicro\PC-cillinNTCorp\CurrentVersion\Misc.\PatternVer>=414"):begin_admin (admin):send_log (alert):mismatchmessage ("Please update your AntiVirus (use the LiveUpdateoption)."):end (admin))): (SCVMonitor:type (plugin):parameters (:scv_version ("54014"):begin_admin (admin):send_log (alert):mismatchmessage ("Please upgrade your Secure ConfigurationVerification products package."):end (admin))): (sc_ver_scv:type (plugin):parameters (:Default_SecureClientBuildNumber (52032):Default_EnforceBuildOperand ("=="):MismatchMessage ("Please upgrade your SecureClient."):EnforceBuild_9X_Operand (">="):SecureClient_9X_BuildNumber (52030)Chapter 22 Secure Configuration Verification - SCV 313

Configuring SCV:EnforceBuild_NT_Operand ("=="):SecureClient_NT_BuildNumber (52032):EnforceBuild_2K_Operand (">="):SecureClient_2K_BuildNumber (52032):EnforceBuild_XP_Operand (">="):SecureClient_XP_BuildNumber (52032)))):SCVPolicy (: (BrowserMonitor): (HWMonitor): (AntiVirusMonitor)):SCVGlobalParams (:enable_status_notifications (false):status_notifications_timeout (10):disconnect_when_not_verified (false):block_connections_on_unverified (false):scv_policy_timeout_hours (24):enforce_ip_forwarding (true):not_verified_script (""):not_verified_script_run_show (false):not_verified_script_run_admin (false):not_verified_script_run_always (false)))When using this file, it is important to maintain the sameindentation/nesting format.Common AttributesTypically, an administrator might need to change only a few of the common parameters(SCV checks) contained in the SCV policy file.SCV Checks1 Anti-virus monitorParameters:• Type (“av_type”)Type of anti-virus. For example, “Norton”, “VirusScan”, or “OfficeScan”314

Common Attributes• Signature(x)Required Virus definition file signature. The signature’s format depends onthe AntiVirus type. For example, on Norton Antivirus the signature maybe be“>=20031020”. (The format for Norton’s AV signature is “yyyymmdd”).For TrendMicro Officescan, the signature maybe “404291”) for a signature greaterthan 4.0.4291AntiVirusMonitor does not support “begin_or” and the “begin_and” syntax. See:“Expressions and labels with special meanings”.2 BrowserMonitorParameters:• browser_major_version (5)Major version number of Internet Explorer. If this field does not exist in thelocal.scv file, or if this value is 0, the IE’S version will not be checked aspart of the BrowserMonitor check.• browser_minor_version (0)Internet Explorer’s minor version number.• browser_version_operand (“>=”)The operator used for checking the Internet Explorer’s version number.• browser_version_mismatchmessage (“Please upgrade your InternetBrowser.”)Message to be displayed in case of a non-verified configuration for theInternet Explorer’s version.• intranet_download_signed_activex (enable)The maximum permission level that IE should have for downloading signedActiveX controls from within the local Intranet.• intranet_run_activex (enable)The maximum permission level that IE should have for running signedActiveX controls from within the local Intranet.• intranet_download_files (enable)The maximum permission level that IE should have for downloading filesfrom within the local Intranet.Chapter 22 Secure Configuration Verification - SCV 315

Configuring SCV• intranet_java_permissions (low)The maximum security level that IE Explorer should have for running javaapplets from within the local Intranet.(low) means a low security level.• trusted_download_signed_activex (enable)The maximum permission level that IE should have for downloading signedActiveX controls from trusted zones.• trusted_run_activex (enable)The maximum permission level that IE should have for running signedActiveX controls from trusted zones.• trusted_download_files (enable)The maximum permission level that IE should have for downloading filesfrom trusted zones.• trusted_java_permissions (medium)The maximum security level that IE should have for running java applets fromtrusted zones.• internet_download_signed_activex (disable)The maximum permission level that IE should have for downloading signedActiveX controls from the Internet.• Internet_run_activex (disable)The maximum permission level that IE should have for running signedActiveX controls from the Internet.• internet_download_files (disable)The maximum permission level that IE should have for downloading filesfrom the Internet.• internet_java_permissions (disable)The maximum security level that IE should have for running java applets fromthe Internet.• restricted_download_signed_activex (disable)The maximum permission level that IE should have for downloading signedActiveX controls from restricted zones.• restricted_run_activex (disable)The maximum permission level that IE should have for running signedActiveX controls from restricted zones.316

Common Attributes• restricted_download_files (disable)The maximum permission level that IE should have for downloading filesfrom restricted zones.• restricted_java_permissions (disable)The maximum security level that IE should have for running java applets fromrestricted zones.• send_log (type)Determines whether to send a log to SmartCenter Server for specifying thatthe client is not “SCVed.”This SCV check does not support the “begin admin/end admin” parametersection.The (type) section should be replaced by (log) or (alert)• internet_options_mismach_message (“Your Internet browser settingsdo not meet policy requirements”)Mismatch message for the Internet Explorer settings.BrowserMonitor can be configured to check only Internet Explorer’s version, or onlythe browser’s settings for a certain zone. For example, if none of the followingparameters appear:iiirestricted_download_signed_activexrestricted_run_activexiii restricted_download_filesiv restricted_java_permissionsthen BrowserMonitor will not check the restricted zones’ security settings. In similarfashion, if the parameter “browser_major_version” does not appear or is equal tozero, then IE’s version number is not checked.BrowserMonitor does not support the “begin_or” and the “begin_and” syntax, anddoes not support the admin parameters. See also: “Expressions and labels with specialmeanings”.3 GroupmonitorParameters• “builtin\administrator” (false)A name of a user group. The user has to belong to this group in order for themachine configuration to be verified.Chapter 22 Secure Configuration Verification - SCV 317

Configuring SCV• securely_configured_no_active_user (true)Specifies whether the machine’s configuration may be considered verifiedwhen no user is logged on. The default value is false.4 HotFixMonitorParameters• HotFix_Number (true)A number of a system HotFix to be checked. In order for the machine to beverified, the HotFix should be installed, for example: “823980(true)” verifiesthat Microsoft’s RPC patch is installed on the operating system.• HotFix_Name (true)The full name of a system HotFix to be checked. In order for the machine tobe verified, the HotFix should be installed, for example: “KB823980(true)”verifies that Microsoft’s RPC patch is installed on the operating system.Not all the mentioned fields for HotFixMonitor need to appear in the local.scv file.Some of them may not appear at all, or may appear more than once. These fields mayalso be ORed and ANDed. In this way, multiple HotFixes can be checked, and theresults ORed or ANDed for extra flexibility.5 HWMonitorParameters• cputype (“GenuineIntel”)The CPU type as described in the vendor ID string. The string has to beexactly 12 characters long. For example: “GenuineIntel”, or“AuthenticAMD”, or “aaa bbb ccc ” where spaces count as a character.• cpufamily(6)The CPU family.• cpumodel(9)The CPU model.HWMonitor does not support the “begin_or” and the “begin_and” syntax. See also:“Expressions and labels with special meanings”.6 OsMonitorParameters318

Common Attributes• enforce_screen_saver_minutes_to_activate (3)Time in minutes for the screen saver to activate. If the screen saver does notactivate within this time period, then the client is not considered verified. Inaddition, the screen saver must be password protected.• screen_saver_mismatchmessage (“Your screen saver settings do notmeet policy requirements”)Mismatch message for the screen saver check. The screen saver will not bechecked if the property “enforce_screen_saver_minutes_to_activate”does not appear, or if the time is set to zero.• send_log (type)Determines whether to send a log to SmartCenter Server for specifying thatthe client is not “SCVed.”This SCV check does not support the “begin admin/end admin” parametersection.The (type) section should be replaced by (log) or (alert)• major_os_version_number_9x (4)Specifies the major version required for 9x operating systems to be verified.• minor_os_version_number_9x (10)Specifies the minor version required for 9x operating systems to be verified.• os_version_operand_9x (“>=”)Operator for checking the operating system’s version on 9x.• service_pack_major_version_number_9x (0)Specifies the major service pack’s version required for 9x operating system’s tobe verified.• service_pack_minor_version_number_9x (0)Specifies the minor service pack’s version required for 9x operating systems tobe verified.• service_pack_version_operand_9x (“>=”)Operator for checking the operating system’s service pack on 9x.• major_os_version_number_nt (4)Specifies the major version required for Windows NT operating systems to beverified.• minor_os_version_number_nt (10)Specifies the minor version required for Windows NT operating systems to beverified.Chapter 22 Secure Configuration Verification - SCV 319

Configuring SCV• os_version_operand_nt (“>=”)Operator for checking the operating system’s version on Windows NT.• service_pack_major_version_number_nt (0)Major service pack version required for Windows NT operating systems to beverified• service_pack_minor_version_number_nt (0)Minor service pack version required for Windows NT operating systems to beverified• service_pack_version_operand_nt (“>=”)Operator for checking the operating system’s service pack on Windows NT• major_os_version_number_2k (4)Specifies the major version required for Windows 2000 operating systems tobe verified.• minor_os_version_number_2k (10)Specifies the minor version required for Windows 2000 operating systems tobe verified.• os_version_operand_2k (“>=”)Operator for checking the operating system’s version on Windows 2000• service_pack_major_version_number_2k (0)Specifies major service pack version required for Windows 2000 operatingsystems to be verified.• service_pack_minor_version_number_2k (0)Specifies minor service pack version required for Windows 2000 operatingsystems to be verified.• service_pack_version_operand_2k (“>=”)Operator for checking the operating system’s service pack on Windows 2000• major_os_version_number_xp (4)Specifies the major version required for Windows XP operating systems to beverified.• minor_os_version_number_xp (10)Specifies the minor version required for Windows XP operating systems to beverified.• os_version_operand_xp (“>=”)Operator for checking the operating system’s service pack on Windows XP320

Common Attributes• service_pack_major_version_number_xp (0)Specifies the major service pack version required for Windows XP operatingsystems to be verified.• service_pack_minor_version_number_xp (0)Specifies the minor service pack version required for Windows XP operatingsystems to be verified.• service_pack_version_operand_xp (“>=”)Operator for checking the operating system’s service pack on Windows XP.• os_version_mismatches (“Please upgrade your operating system”)Message to be displayed in case of a non-verified configuration for theoperating system’s version/service pack. The operating system’s version andservice pack will not be checked if none of the parameters appear in the scvfile.OsMonitor can be configured to check only the screen saver’s configuration, or onlythe operating system’s version and service pack. For example, if none of the followingparameters appear:iiimajor_os_version_number_xpminor_os_version_number_xpiii os_version_operand_xpiv service_pack_major_version_number_xpvservice_pack_minor_version_number_xpvi service_pack_version_operand_xpthen OsMonitor will not check the system’s version and service pack on Windows XPplatforms.In similar fashion:if the parameter “enforce_screen_saver_minutes_to_activate” does not appear,then the screen saver’s configuration is not checked.OSMonitor does not support the “begin_or” and the “begin_and” syntax. See also:“Expressions and labels with special meanings”.7 ProcessMonitorParametersChapter 22 Secure Configuration Verification - SCV 321

Configuring SCV• ProcessName.exe (true)A process the administrator would like to check. If the value is true, theprocess needs to be running for the machine to be verified. If the value isfalse, the process should not be running for the machine to be verified.ProcessMonitor can also be used to check for the existance/exclusion of morethan one process. The fields may be ANDed or ORed for flexibility.8 RegMonitorParameters• value (registry_value_path)The path of a registry DWORD, under HKEY_LOCAL_MACHINE, to bechecked. The value should be an operator followed by a number, e.g.“Software\TrendMicro\PC-cillinNTCorp\CurrentVersion\Misc.\PatternVer>=414”The syntax for the value parameter is::value (“pathOPval”)For example::value (“Software\...\PaternVer>=414”)• string (registry_string_path)The path of a registry string, under HKEY_LOCAL_MACHINE, to bechecked. The string’s value is compared to the given value, in the way thatDWORDs are compared.• keyexist (registry_key_path)The path of a registry key to check if the key exists, underHKEY_LOCAL_MACHINE. The key must exist if the machine is to beverified.• keynexist (registry_key_path)The path of a registry key to be checked for exclusion, underHKEY_LOCAL_MACHINE. For the machine to be verified, the key shouldnot exist.HKEY_LOCAL_MACHINE does not need to be included in the path.Not all the mentioned fields for RegMonitor need to appear in the local.scv file.Some of them may not appear at all, or may appear more than once. These fields mayalso be ORed and ANDed. In this way, multiple registry entries can be checked, andthe results ORed or ANDed for extra flexibility.9 SCVMonitor322

Common AttributesParameters• scv_version(“>=541000076”)Represents the SCV product’s build number. This is the version of the DLLsin charge of the SCV checks. This number differs from the build number ofSecureClient. SCV products can be upgraded, and maybe updated withoutupdating SecureClient.The string is an operator followed by the DLL’s version number in the format“vvshhhbbb”. For example, if you want the DLL version to be at least54.1.0.220, the syntax should be: scv_version (“>=541000220”)SCVMonitor does not support the “begin_or” and the “begin_and” syntax. See also:“Expressions and labels with special meanings”.10 ScriptRunParameters• exe (“VerifyScript.bat”)Runs an executable. Supply the name of the executable, and the full path tothe executable.• run_as_admin (“no”)Determines whether the verification script is run with administratorprivileges. The default is “no”. The only other value is “yes”.• run_timeout (10)Time (in seconds) to wait for the executable to finish. If the executable doesnot finish within the set time, the process is considered as a failure, and themachine categorized as “not verified”. The default value is zero, which is thesame as “no timeout”.ScriptRun does not support the “begin_or” and the “begin_and” syntax. See also:“Expressions and labels with special meanings”.11 sc_ver_scvParameters• Default_SecureClientBuildNumber (52032)Build number for SecureClient. This build number is checked (with thespecified operator) only if no specific build number is to be checked for aparticular platform.• Default_EnforceBuildOperand (“==”)Operator for comparing the local.scv’s build number with the client buildnumber.Chapter 22 Secure Configuration Verification - SCV 323

Configuring SCV• MismatchMessage (“Please upgrade your SecureClient”)Mismatch message to be displayed when the SecureClient’s build does notmatch the local.scv’s configuration.• EnforceBuild_9x_Operand (“>=”)Operator for comparing the local.scv’s build number with the client buildnumber on Windows 9x platforms.• SecureClient_9x_BuildNumber (52030)SecureClient build number for windows 9x platforms.• EnforceBuild_NT_Operand (“==”)Operator for comparing the local.scv’s build number with the client buildnumber on WindowsNT platforms.• SecureClient_NT_BuildNumber (52030)SecureClient build number for WindowsNT platforms.• EnforceBuild_2K_Operand (“>=”)Operator for comparing the local.scv’s build number with the client buildnumber on Window 2000 platforms.• SecureClient_2K_BuildNumer (52030)SecureClient build number for Windows 2000 platforms.• EnforceBuild_XP_Operand (“>=”)Operator for comparing the local.scv’s build number with the client buildnumber on Windows XP platforms.• SecureClient_XP_Buildnumber (52030)SecureClient build number for Windows XP platforms.sc_ver_scv does not support the “begin_or” and the “begin_and” syntax. See also:“Expressions and labels with special meanings”.12 user_policy_scvParameters• logged_on_to_policy_server (true/false)Specifies whether the user has to be logged on to a Policy Server to beconsidered SCVed.• policy_refresh_rate (“168”)Time, in hours, for which the desktop policy remains valid. After 168 hoursthe desktop policy is not considered valid, and the user is no longer SCVed. Ifthis parameter is not specified, the policy is not checked for freshness.324

Common Attributes• mismatchmessage (“Place a message here”)The message displayed when the user_policy_scv check fails.• dont_enforce_while_connectingIf this parameter is present, the user is considered SCVed while connecting tothe Gateway. The user is considered SCVed only for the duration of theconnect process.13 SCVGlobalParamsParametersFor all boolean parameters (true or false), the values should not be enclosed inquotation marks.• enable_status_notifications (true/false)If “true”, SecureClient displays a balloon window when the Desktop is notSCVed. On windows 9x and NT, where balloons are not supported, popupsappear.• status_notifications_timeout ()The number of seconds the balloon window (see previous parameter) will bedisplayed.• disconnect_when_not_verified (true/false)If “true”, SecureClient will disconnect from the site when the Desktop is notSCVed.• block_connections_on_unverified (true/false)If “true”, SecureClient will drop all open connections when the Desktop isnot SCVed.Note - This parameter, if true, blocks all connections to the machine, not just thoseconnectionsto and from the VPN site.• scv_policy_timeout_hours ()The period (in hours) during which the SCV policy is considered valid sincethe last logon to the Policy Server. When this timeout is about to expireSecureClient will attempt to logon to the Policy Server to get a new SCVpolicy.Possible values are between 1 and 504 hours(21 days). The default value is 168hours (one week). If you set the value to 0, the SCV policy never expires (notime-out).• enforce_ip_forwarding (true/false)If “true” the IP Forwarding between network interface cards on the user’sdesktop must be disabled for the user to be considered SCVed.Chapter 22 Secure Configuration Verification - SCV 325

Configuring SCV• ip_forwarding_mismatchmessage (“Message string placed here”)The value is a string displayed when ip forwarding is enabled. For example:ip_forwarding_mismatchmessage (“Please....etc”)This is relevant only if ip forwarding is part of the SCV checks, that is, if theparameter is defined as True.• not_verified_script (“script_name.bat”)The name of executable that will be run when the Desktop is not SCVed.The next three parameters provide more options related to the running of theexecutable.• not_verified_script_run_show (true/false)If “true”, the executable’s progress will be displayed in an onscreen window.• not_verified_script_run_admin (true/false)If “true”, the executable will run with administrator privileges.• not_verified_script_run_always (true/false)If “true”, the executable will run every time the Desktop is not SCVed. If“false”, it will run once per SecureClient session.326

CHAPTER23Packaging Tool -Simplified RemoteClient InstallationIn This ChapterThe Need to Simplify Remote Client Installations page 327The Packaging Tool Solution page 328Configuring the Packaging Tool page 330The Need to Simplify Remote Client InstallationsAs remote access to organizations becomes more widespread, administration of remoteclients becomes more difficult. Users often lack the technical expertise to install andconfigure software for themselves, so administrators must provide support for largenumbers of users, of whom many may be geographically dispersed on a wide variety ofplatforms. The administrator’s task is even more difficult if the organization has severalgroups of users, each of which requires a different configuration.Administrators need tools to automate the configuration and distribution of software tolarge user communities. Note that there are two related problems:• Pre-configuring the software, so that users do not have to do this themselves• Automatically distributing the pre-configured software327

The Packaging Tool SolutionThe Packaging Tool SolutionOverviewIn This SectionOverview page 328How the Packaging Tool Works page 328Automatic Software Distribution page 329Check Point’s Packaging Tool enables the administrator to create pre-configuredSecureClient and SecuRemote packages. Users can then install the package withoutbeing required to specify configuration details, ensuring that users cannot inadvertentlymisconfigure their SecureClient and SecuRemote software.In addition, SecureClient packages can be automatically distributed to existingSecureClient users using the Automatic Software Distribution (ASD) feature (See:“Automatic Software Distribution” on page 329).The advantages of this solution are:• Configuration (sites creation, connection and encryption parameter specification,etc.) is performed by professional administrators, rather than by unsophisticated anderror-prone users.• Installation and support overhead are greatly reduced.• Users’ security configurations are more uniform across the organization, becausethey are pre-defined by the administrator rather than specified by each userindividually.• The administrator can more quickly respond to security threats by automaticallyupdating remote users’ security software.How the Packaging Tool WorksOverviewUsing the Packaging tool wizard, an administrator can create custom SecureClient andSecuRemote installation packages. Each package can contain a different combination ofa SecuRemote/SecureClient version and a pre-configured user profile.The administrator can pre-configure the client’s installation and configuration settings,such as the connection mode to the VPN-1 gateway (Connect/Transparent),encryption properties and more. These settings are saved in a package profile.328

Automatic Software DistributionThe administrator can create different package profiles for different user groups. Forexample, the administrator can create one profile with the configuration parameters forWindows XP users, and another for Windows 98 users. All the profiles are saved in acentral database.Packaging Tool combines a client installation package (for example, the genericSecureClient installation package) with a package profile to create a pre-configuredSecureClient package.The SecureClient package can also include scripts to be run after the installation ofSecureClient.Automating Site Definition for usersTo allow the client to connect to the organization from the moment it is installed, theadministrator can specify Partial Topology information for a site, that is, the IP addressof the site or of its SmartCenter Server. This information is included in the package.The first time the user connects to and authenticates to the site, the site’s full topologyis downloaded to the client.Automatic Software DistributionThe Packaging Tool can create both SecuRemote and SecureClient packages. TheAutomatic Software Distribution (ASD) feature enables administrators to automaticallydistribute SecureClient packages in order to update existing SecureClient installations.SecuRemote packages must be manually distributed.SecureClient periodically check for updates by sending its configuration parameters(operating system, current version and service pack of the client installed etc.) to anASD (Automatic Software Distribution) Server, which maps this information to aprofile. If an updated package exists for the profile, it can be automatically downloadedto the client in order to update SecureClient.ASD consists of the following components:• Management Repository — The Management Repository is maintained on theSmartCenter server, and contains the ASD packages created and managed by thePackaging Tool. The ASD packages are downloaded from the ManagementRepository to the ASD Servers.• ASD Server — An ASD Server distributes SecureClient packages to remote clients.ASD Servers are automatically installed with Policy Servers.Note - A SmartCenter server which also hosts a Policy Server cannot also function as an ASDServer.Chapter 23 Packaging Tool - Simplified Remote Client Installation 329

Configuring the Packaging Tool• ASD Agent — The ASD Agent is part of the SecureClient installation, and is startedautomatically by SecureClient if the site’s topology information indicates that anASD Server is installed in the site. The ASD Agent periodically polls the ASDServer to determine whether an updated package exists. If an updated ASD packageis found on the ASD Server, the user is asked whether to install a new package.The user can also manually instruct the ASD Agent to check for updates at anygiven time.FIGURE 23-1 Distributing the Package to SecureClientsConfiguring the Packaging ToolIn This SectionASD Server Configuration page 330The Packaging Tool Installation and Configuration page 331Client Side Configuration page 334In order to use the Packaging Tool to create and distribute packages to clients, youmust configure the Automatic Software Distribution mechanism, install and configurethe Packaging Tool application and make sure remote clients are ready to receiveupdates for the new packages.ASD Server Configuration1 The ASD server is part of the Policy Server installation. If you do not have a PolicyServer installed, install the Policy Server. Note that in order to use the Policy Serveras an ASD server, you must install it on a machine which does not host aSmartCenter Server.330

The Packaging Tool Installation and Configuration2 In the General Properties page of the network object on which you installed theASD Server, select SecureClient Software Distribution Server.3 Install the Security Policy on gateways and ASD Servers.The Packaging Tool Installation and Configuration1 The SecureClient Packaging Tool should be installed from the Check Point CD. Ifyou have not installed the Packaging Tool component, select it in the SmartConsoleclients installation window.2 Start the SecureClient Packaging Tool by selecting Start > Programs > Check PointSmart Client > SecureClient Packaging Tool. The SecureClient Packaging Tool mainwindow is displayed:FIGURE 23-2 The SecureClient Packing Tool main windowCreating a new package profile1 To create a new profile, Select Profile >New. Enter the profile details and press Next.2 The Packaging Tool wizard will guide you through the next several windows, inwhich you should configure different parameters regarding the user’s profile, such aspolicy, encryption, topology (including Partial Topology information), certificates,client installation and logon parameters (SDL/Gina DLLs). For information aboutthese features, see the relevant chapters in the documentation.Chapter 23 Packaging Tool - Simplified Remote Client Installation 331

Configuring the Packaging Tool3 After pre-configuring all of the client’s settings, you will be presented with theFinish screen. In this screen you can decide if Packaging Tool should continue tocreate a new package containing the changes as they appear in the profile or finishthe process of profile generation without creating a new package. The options inthis screen are:• No, Create Profile only — The profile will be created according to the settingyou have pre-defined in the wizard and you will be returned to the mainPackaging Tool window.• Yes, Create profile and generate package — If you choose this option the profileyou’ve created will be saved and you will be taken to the package generationwizard. For instructions regarding this wizard, proceed to Generating Packages andPreparing Them for Distribution page 332.Note that if you choose not to generate a new package at this stage, you can alwayscreate packages from the saved profile at a later time.Generating Packages and Preparing Them for DistributionThis section describes how to generate a SecureClient package according to the settingsdefined in a package profile and upload them to an ASD Server, so they can bedistributed to clients.PreparationIf you have not already prepared a base package, do so now, as follows:1 Obtain an original SecureClient installation package. Please note that this packagewill be the base package, upon which the Packaging Tool will create the newcustom SecureClient package.2 Copy the clean SecureClient package to an empty directory. If the package iszipped or tarred you should unpack the package to the empty directory.WizardOnce you have a base package, proceed as follows:3 Run the SecureClient package generation wizard.You can run the wizard immediately after creating a new package profile (byselecting Yes, Create profile and generate package), or from the main PackagingTool window by highlighting a previously created profile and selectingProfile>Generate.332

The Packaging Tool Installation and Configuration4 To instruct the Packaging Tool to upload the new custom SecureClient package tothe ASD Server, check Save package on ASD servers for automatic distribution inthe Generation Information window (FIGURE 23-3).You can also choose to only generate the package at this point, and to upload it tothe ASD servers later. To do this, do not check Save package on ASD servers forautomatic distribution. Later, when you decide to upload the package, chooseProfile>Save Package from the menu and specify the package to upload (see“Preparing Previously Generated Packages for Automatic Distribution” on page334).FIGURE 23-3 Using the wizard5 Next, you will be asked to enter a package source and destination folders.Under Source folder, select the directory in which the original SecureClientinstallation you prepared in step 2 is located. Make sure you select the directory inwhich the SecureClient setup files actually exist and not a higher level directory.Under Destination folder, select an empty directory, to which the new package willbe copied.Press Next to continue to the next window.6 If the package details can not be extracted from the package, you will be promptedto enter the package details (operating system type, SecureClient version andservice pack). If the package details conflict with another package (for example,you’ve updated the Windows 98 SecureClient package from FP3 to NG withApplication Intelligence), you will be prompted to approve the replacement of theolder package with the newer one.Chapter 23 Packaging Tool - Simplified Remote Client Installation 333

Configuring the Packaging ToolThe Packaging Tool will perform the actions you requested and will show you theresults in a dialog box.Preparing Previously Generated Packages for AutomaticDistributionThis option is used to upload an existing package to the ASD Server. If you choose thisoption, it is assumed that you have already generated and saved the package, but did notsave it on the ASD Servers. To upload the package to the ASD Servers, proceed asfollows:1 In the main Packaging Tool window select Profile>Save Package.The Packaging Tool will present you with a window requesting that you to enterthe full path to the previously created package.Enter the path and click Next to continue to the next window.The Packaging Tool will take the package from the location you have specified, uploadit to the ASD Server and show you the results in a dialog box.Adding Scripts to a PackageTo specify that a script should be run after the user installs or uninstalls SecureClient,proceed as follows:1 Edit the product.ini file.2 To specify a post-installation script, add the file’s name to the [install] section.3 To specify a post-uninstallation script, add the file’s name to the [uninstall]section.The script should be accessible through the OS PATH variable.The script is not part of the package, and should be transferred to the client separately.Client Side ConfigurationAutomatic SecureClient InstallationIn order to get an update to SecureClient, you must have an NG SecureClient runningon the client. To configure of the client to check for updates, proceed as follows:334

Client Side Configuration1 After configuring the Management Repository and ASD Server, updateSecureClient’s topology, so it gets an updated list of ASD Servers.If the site has ASD servers defined, the ASD Agent will be started by SecureClientand its icon will appear in the system tray. From this moment on, the client willcheck for ASD updates and install them automatically.Please note that the topology update is required only after enabling ASD Servers orupdating their configuration in SmartDashboard. It is not necessary to repeat thisstep each time you create a new custom SecureClient package.2 If necessary, you can manually instruct the ASD Agent to check for updates byright clicking on the ASD Agent icon and selecting “Check Updates”.FIGURE 23-4 Checking for Updates manually using the ASD Agent on the ClientManual InstallationManual installation of packages created by the Packaging Tool is necessary when:• The package is a SecuRemote package, which cannot be automatically distributedusing ASD• The user does not have a SecureClient installedIn these scenarios follow these steps:1 Copy the package to the user’s machine.2 Instruct the user to start the package installation on his desktop machine.The user will not be required to intervene in the installation process, unless youhave required him to do so in the package profile.Chapter 23 Packaging Tool - Simplified Remote Client Installation 335

Configuring the Packaging Tool336

Appendix AVPN-1 Command LineInterfaceIn This ChapterVPN-1 commandsVPN-1 commands page 337SecureClient Commands page 339The following command line commands relate to VPN-1 and are also documented inthe Command Line Interface (CLI) Guide.TABLE A-1VPN-1 Command Line interfaceCommandVPNvpn accelvpn compresetDescriptionThis command and subcommands are used for workingwith various aspects of VPN-1. VPN commandsexecuted on the command line generate statusinformation regarding VPN processes, or are used tostop and start specific VPN services.This command performs operations on VPN acceleratorcards (encryption only cards, not the full SecureXLcards) and VPNx. VPNx is a software module that takesadvantage of multiple CPUs to accelerate VPNoperations.This command resets the compression/decompressionstatistics to zero.337

TABLE A-1VPN-1 Command Line interfaceCommandvpn compstatvpn crl_zapvpn crlviewvpn debugvpn drvvpn export_p12vpn macutilvpn nssm_toplogyvpn overlap_encdomDescriptionThis command displays compression/decompressionstatistics.This command is used to erase all CertificateRevocation Lists (CRLs) from the cache.This command retrieves the Certificate Revocation List(CRL) from various distribution points and displays itfor the user.This command instructs the VPN daemon to writedebug messages to the VPN log file: in$FWDIR/log/vpnd.elg.This command installs the VPN-1 kernel (vpnk) andconnects to the FireWall-1 kernel (fwk), attaching theVPN-1 driver to the FireWall-1 driver.This command exports information contained in thenetwork objects database and writes it in the PKCS#12format to a file with the p12 extension.This command is related to Remote Access VPN,specifically Office mode, generating a MAC address perremote user. This command is relevant only whenallocating IP addresses via DHCP.This command generates and uploads a topology (inNSSM format) to a Nokia NSSM server for use byNokia clients.This command displays all overlapping VPN domains.Some IP addresses might belong to two or more VPNdomains. The command alerts for overlappingencryption domains if one or both of the followingconditions exist:• The same VPN domain is defined for both Gateway• If the Gateway has multiple interfaces, and one ormore of the interfaces has the same IP address andnetmask.338

TABLE A-1VPN-1 Command Line interfaceCommandvpn sw_topologyvpn vervpn tuDescriptionThis command downloads the topology for a SofaWareGateway.This command displays the VPN-1 major versionnumber and build number.This command launches the TunnelUtil tool which isused to control VPN tunnels.SecureClient CommandsThe following commands relate to SecureClient.TABLE A-2SecureClient command line interfaceCommandSCCscc connectscc connectnowaitscc disconnectscc erasecredsscc listprofilesscc numprofilesscc restartscscc passcertscc setmode ExplanationVPN commands executed on SecureClient are used togenerate status information, stop and start services, orconnect to defines sites using specific user profiles.This command connects to the site using the specifiedprofile, and waits for the connection to be established.In other words, the OS does not put this command intothe background and executes the next command in thequeue.This command connects asynchronously to the siteusing the specified profile. This means, the OS movesonto the next command in the queue and thiscommand is run in the background.This command disconnects from the site using a specificprofile.This command unsets authorization credentials.This command lists all profiles.This command displays the number of profiles.This command restarts SecureClient services.This command sets the user’s authentication credentialswhen authentication is performed using certificates.This command switches the SecuRemote/SecureClientmode.Appendix A 339

TABLE A-2SecureClient command line interfaceCommandscc setpolicyscc spscc startscscc statusscc stopscscc suppressdialogsscc userpassscc verDescriptionThis command enables or disables the current defaultsecurity policy.This command displays the current default securitypolicy.This command starts SecureClient services.This is command displays the connection status.This command stops SecureClient services.This command enables or suppresses dialog popups. Bydefault, suppressdialogs is off.This commands sets the user’s authentication credentials-- username, and password.This command displays the current SecureClientversion.340

IndexAactive_resolver 219allow_clear_in_enc_domain 213authentication timeout 201automatic topology updateproperties 206Bblock_conns_on_erase_passwords 214Building tunnels 23Access Control 33Authentication 23Choosing a topology 28Confidentiality 23Configuring 35Confirming a VPN TunnelSuccessfully Opens 37encryption issues 29Externally ManagedGateways 32How it Works 24Integrity 24Mesh 27Remote Access Community 26Special Considerations 34Star 27Topologies 27CCAPI 125Clientless VPN 175Certificate Presented by theGateway 178Check Point Solution 176Configuring 179How it works 176Level of Encryption 179Security Servers 179Special considerations 178User Authentication 177Connect Mode 207Ddefault_ps 213DHCP Server 197disable_stateful_dhcp 213DNS Server 207Eenable_automatic_policy_update 214enable_kill 221encrypt_db 219IIKEConfiguring 66Diffie Hellman Groups 61Methods of Encryption andIntegrity 61modes 61Overview 57Phase I 58Phase II (Quick mode) 59Renegotiating lifetimes 62Unique SA Per Pair of Peers 65IP Compression 64IP Resolution 249Check Point Solution 249Configuring 253Kkeep_alive 219keep_alive_interval 219LLMHOSTS 203Mmacutil 197manual_slan_control 213Multiple Entry Point Gateways 259Check Point Solution 259Gateway Failure 261Special Considerations 268with RIM 265with Static IP Pool NAT 264NNATand Office Mode 195no_clear_tables 220non-Check Point firewall 206Oobjects_5_0.C file 199, 200Office Mode 207and NAT 196IP Per User 149one-time password 201OTP 201341

Ppassword caching 201Perfect Forward Secrecy 63PKCS#12 125product.ini file 334pwd_erase_on_time_change 215RRemote Access ConnectivityResolution 157Active IPSec PMTU 163Allocating CustomizedPorts 166Configuring IKE OverTCP 168Configuring NAT Traversal(UDP Encapsulation) 169Configuring Remote Clients towork with ProxyServers 171Configuring Small IKE phase IIProposals 168Configuring Visitor Mode 169IKE Over TCP 160IPSec Path MaximumTransmission Units 162NAT Related Issues 158NAT traversal 161Passive IPSec PMTU 163Proxy Servers 166Small IKE Phase IIProposals 161UDP Encapsulation 161Visitor Mode 165Visitor Mode in a MEPedenvironment 167with SecurePlatform/Nokia 167resolver_session_interval 219resolver_ttl (10) 218RFC 1981 207RoutingConfiguring 238Increasing Granularity 240Through a Spoke That AlsoActs As a Hub 245Sscc connect 339scc connectnowait 339scc listprofiles 339scc numprofiles 339scc passcert 339scc setmode 339scc sp 340scc startsc 340scc status 340scc stopsc 340scc suppressdialogs 340scc userpass 340scc ver 340SDL 202configuring 204SecureClientpost-installation script 334post-uninstallation script 334SecuRemote DNS Server 207SecuRemote/SecureClient behindnon-Check Point firewall 206SecurID 201silent_policy_update 214split DNS 207supported algorithmssoftware 115Ttimeoutauthentication 201topology_over_IKE 219Traditional Mode 91Between Internally ManagedGateways 95Configuring 94with an Externally ManagedGateway 96Uuse_cert 215use_entelligence 215use_ext_auth_msg 221use_ext_logo_bitmap 221userc.C filedescription of parameters 213Vvpn accel 337VPN Accelerator Carddiagnostics 112enabling and disabling 111installation 109uninstallation 110vpn compreset 337vpn compstat 338VPN Connectivity 277Default Route for theDMZ 279DMZ Connections 277Routing with ExternalGateways 279VPN connectivityExternal Gateway as aSpoke 280with Cross Primary Backup 281with Partially Overlapping VPNDomains 280vpn crl_zap 338vpn crlview 338vpn debug 338vpn drv 338vpn export_p12 338vpn macutil 197, 338vpn nssm_toplogy 338vpn overlap_encdom 338vpn sw_topology 339vpn tu 339vpn ver 339VPN-1 Accelerationthe need 107the solution 107VPN-1 Accelerator CardII and III 107WWINS 202, 203342 December 2003