NG with Application Intelligence (R55) See the latest version of this document in the User Center at:

Transcription

1 VPN-1 NG with Application Intelligence (R55) For additional technical information about Check Point products, consult Check Point s SecureKnowledge at: See the latest version of this document in the User Center at: Part No.: October 2003

2 Check Point Software Technologies Ltd. All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS and FAR TRADEMARKS: Check Point, the Check Point logo, ClusterXL, ConnectControl, FireWall-1, FireWall-1 GX, 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, Application Intelligence, SVN, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator 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 registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. 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 and other countries. Entrust s logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust. Verisign is a trademark of Verisign Inc. The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software 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 Carnegie Mellon University. Copyright 1997 by Carnegie Mellon University. All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.cmu DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. The following statements refer to those portions of the software copyrighted by The Open Group. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 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 OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright 1998 The Open Group. The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented 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 the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.you should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The following statements refer to those portions of the software copyrighted by Thai Open Source 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 this software and associated documentation files (the "Software"), to deal in the Software without 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 to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Check Point Software Technologies Ltd. U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) Fax: (650) , info@checkpoint.com International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: Fax: ,

3 Table Of Contents Chapter 1 Chapter 2 Chapter 3 Introduction to Virtual Private Networks (VPN) The Connectivity Challenge 13 The Check Point Solution 14 Understanding the Terminology 14 What is VPN-1 15 Building VPN Links 16 Features of VPN-1 Connectivity 17 What s in the Book 19 Building a VPN Between Gateways The Need for Virtual Private Networks 23 Confidentiality 23 Authentication 23 Integrity 24 The Check Point Solution for VPN 24 How it Works 24 VPN Communities 25 VPN Topologies 27 Authentication Between Community Members 32 Access Control and VPN Communities 33 Excluded Services 34 Special Considerations for Planning a VPN Topology 34 Configuring a VPN Between Gateways 35 Enabling Simplified Mode 35 Configuring a Mesh Community Between Internally Managed Gateways 35 Configuring a Star VPN Community 37 Confirming a VPN Tunnel Successfully Opens 37 Using PKI Solutions Need for Integration with Different PKI solutions 39 Solution - Supporting a Wide Variety of PKI Solutions 40 PKI and Remote Access Users 40 PKI Deployments and VPN 40 Trusting a CA Overview 42 Enrolling a Managed Entity 43 Validation of Certificate 44 PKI Considerations 46 Using the Internal CA vs. Deploying a Third Party CA 46 Storing Private Keys on the Module 47 Configuration of PKI Operations 47 Trusting a CA Step-By-Step 47 Table of Contents 3

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

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

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

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

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

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

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

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

12 12

13 CHAPTER 1 Introduction to Virtual Private Networks (VPN) In This Chapter The Connectivity Challenge page 13 The Check Point Solution page 14 What s in the Book page 19 The Connectivity Challenge With the explosive growth in computer networks and network users, IT managers are faced with the task of consolidating existing networks, remote sites, and remote users into a single secure structure. Branch offices need to be connected with other branch offices as well as the central organization. Remote users need enhanced connectivity features to cope with today s changing networking environments. New partnership deals mean business to business connections with external networks. Typically, consolidation needs to take place using existing infrastructure. For many, this means 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 levels of 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 the right people. 13

14 The Check Point Solution The Check Point Solution Virtual Private Networking technology leverages existing infrastructure (the Internet) as a way of building and enhancing existing connectivity in a secure manner. Based on standard Internet secure protocols, VPN implementation enables secure links between special types of network node: the VPN module. Site to Site VPN ensures secure links between Gateways. Remote Access VPN ensures secure links between Gateways and remote access clients. Understanding the Terminology A number of terms are used widely in Secure VPN implementation, namely: Encryption algorithm. A set of mathematically expressed processes for rendering information into a meaningless form, the mathematical transformations and conversions controlled by a special key. In VPN, various encryption algorithms such as 3DES and AES ensure that only the communicating peers are able to understand the message. Integrity. Integrity checks (via hash functions) ensure that the message has not been intercepted and altered during transmission. Trust. Public key infrastructure (PKI), certificates and certificate authorities are employed to establish trust between Gateways. (In the absence of PKI, Gateways employ 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 keys and methods for exchanging data. In VPN-1, this negotiation takes place using the IKE protocol. VPN Tunnel. An exclusive channel or link created using existing Internet infrastructure. The link is created using the agreed upon methods and keys. VPN Gateway. The endpoint for the encrypted connection. Gateways can be single standalone modules or arranged into clusters. Clustered Gateways provide both high availability and load sharing. VPN Domain. Around each Gateway a protected area is built. The Gateway protects the hosts machines within the area the VPN domain. VPN Topology. The basic element of VPN is the link or encrypted tunnel. Links are created between Gateways. A collection of links is a topology. The topology shows the layout of the VPN. Two basic topologies found in VPN are Mesh and Star. Site to Site VPN. Refers to VPN between Gateways. 14

15 What is VPN-1 Remote Access VPN. Refers to remote users accessing the network with client software such as SecuRemote/SecureClient or third party IPSec clients. The VPN-1 Gateway provides a Remote Access Service to the remote clients. What is VPN-1 Check Point s VPN-1 is an integrated software solution that provides secure connectivity to corporate networks, remote and mobile users, branch offices and business partners on a wide range of open platforms and security appliances. FIGURE 1-1 shows the variety of applications and appliances suitable for VPN, from hand-held PDAs and wireless laptops to mission critical networks and servers: FIGURE 1-1 VPN solutions VPN-1 integrates access control, authentication, and encryption to guarantee the security of network connections over the public Internet. A typical deployment places a VPN-1 Gateway at the entrance to the corporate network and remote access software on the laptops of mobile users. Remote sites are guarded by other VPN-1 Gateways and communication between all components regulated by a strict security policy. VPN-1 Components VPN-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 either VPN-1 (a VPN module with a Security Policy) or VPN-1 Net (the basic VPN module without a Security Policy). Chapter 1 Introduction to Virtual Private Networks (VPN) 15

16 The Check Point Solution VPN trust entities, for example the Check Point Internal Certificate Authority. The ICA is part of the VPN-1 FireWall-1 suite used for establishing trust for SIC connections between Gateways, authenticating administrators and third OPSEC solutions. The ICA provides certificates for internal Gateways and remote access clients which negotiate the VPN link. VPN Management tools. SmartCenter Server and SmartDashboard. SmartDashboard is the SmartConsole used to access the SmartCenter Server Management. The VPN-1 Manager is part of SmartDashboard: SmartDashboard enables organizations to define and deploy Intranet, Extranet, and remote Access VPNs. Smart DataBase for keeping track of defined network objects, services, resources, servers and OPSEC applications, users, and VPN communities. Building VPN Links At the center of VPN is the encrypted tunnel (or VPN link) created using the IKE/IPSec protocols. The two parties are either VPN Gateways or remote access clients. The VPN peers negotiating a link first create a trust between them. This trust is 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 maintains multiple tunnels simultaneously with its VPN peers. Traffic in each tunnel is encrypted and authenticated between the VPN peers, ensuring integrity and privacy. Data is transferred in bulk via these virtual-physical links. 16

17 Features of VPN-1 Connectivity Features of VPN-1 Connectivity VPN-1 has a number of features for site to site, routing, and remote access connectivity. Site to Site Connectivity VPN sites are configured into two basic topologies - Mesh and Star. A topology is the collection of enabled VPN links in a system of Gateways, their VPN domains, hosts located 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 in FIGURE 1-2: FIGURE 1-2 VPN-1 Gateways in a Mesh topology In a Star topology, only Gateways defined as Satellites (or spokes ) are allowed to communicate with a central Gateway (or Hub ) but not with each other: Chapter 1 Introduction to Virtual Private Networks (VPN) 17

18 The Check Point Solution FIGURE 1-3 VPN-1 Gateways in a Star topology As shown in FIGURE 1-3, it is possible to further enhance connectivity by meshing central Gateways. This kind of topology is suitable for deployments involving Extranets that include networks belonging to business partners. Advanced Topologies with VPN Routing More complex connections between VPN sites are available by enabling VPN routing on the Gateway. VPN Gateways and clients are manually configured to route VPN traffic from tunnel to tunnel rather than forward traffic to their domains. This means geographically spaced hosts achieve connectivity via more than one link. This is useful in a number of scenarios, for example: Connecting between Gateways that have dynamically assigned IP addresses; the traffic is routed via a central Gateway. Enabling connectivity between two remote access clients by routing through a central Gateway. Enhancing security in an organization that employs a number of VPN-1 Net modules. Routing connections through a VPN-1 Gateway allows traffic to be inspected for content, and a more granular security policy applied. Remote Access Connectivity For remote access clients, there are two VPN scenarios: Client to Gateway, where the remote client connects with servers on the corporate LAN via a Gateway. Client to Client, where the remote client connects with other remote clients by routing through the corporate Gateway. 18

19 Features of VPN-1 Connectivity Multiple Entry Point VPN. VPN Primary-backup, Load Distribution, and First-to-Respond, are high availability and load sharing solutions for remote access VPN connections. If a Gateway fails in Primary-backup scenario, new VPN connections automatically continue 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 number of VPN-Gateways. In First-to-Respond, the first Gateway to respond to a probe from the remote VPN peer takes the connection. Additional VPN-1 Technology VPN-1 performance is enhanced via a range of accelerator cards. Accelerator Cards VPN-1 Accelerator Cards improve Gateway performance by off loading encryption and public key operations from the host CPU to a dedicated processor on a card. This expands Gateway capacity for VPN communications, and frees system resources for FireWall operations. This dual benefit means that accelerator cards are a good solution for any VPN-1 applications where CPU utilization is high. What s in the Book The VPN book is divided into five sections: Building VPN covers building VPN between Gateways, advanced configuration issues, 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, and clientless VPN. See: Remote Access VPN on page 117. Advanced VPN Connectivity covers VPN routing, Multiple Entry Point VPN and IP resolution. See: Advanced VPN Connectivity on page 227. Desktop Security covers protecting remote clients, secure configuration verification, and software distribution via the packaging tool. See: Desktop Security on page 283. Chapter 1 Introduction to Virtual Private Networks (VPN) 19

20 What s in the Book 20

21 Building VPNs This section covers the creation and management of Site-to-Site Virtual Private Networks.

22

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

24 The Check Point Solution for VPN Integrity The sensitive data passed between the communicating parties is unchanged, and this can be proved with an integrity check. The Check Point Solution for VPN A Virtual Private Network (VPN) is a secure connectivity platform that both connects networks and protects the data passing between them. For example, an organization may have geographically spaced networks connected via the Internet; the company has connectivity but no privacy. VPN provides privacy by encrypting those connections that need to be secure. Another company may connect all parts of its geographically spaced network through the use of dedicated leased lines; this company has achieved connectivity and privacy but at great expense. VPN offers a cheaper connectivity solution by connecting the different parts of the network via the public Internet. A Virtual Private Network is a network that employs encrypted tunnels to exchange securely protected data. VPN-1 creates encrypted tunnels by using the Internet Key Exchange (IKE) and IP Security (IPSec) protocols. IKE creates the VPN tunnel, and this tunnel is used to transfer IPSec encoded data. Think of IKE as the process that builds a tunnel, and IPSec packets as trucks that carry the encrypted data along the tunnel. FIGURE 2-1 Simplified VPN tunnel How it Works In FIGURE 2-2, host 1 and host 6 need to communicate. The connection passes in the clear between host 1 and the local Gateway. From the source and destination addresses of the packet, the Gateway determines that this should be an encrypted connection. If this is the first time the connection is made, the local Gateway initiates an IKE negotiation with the peer Gateway in front of host 6. During the negotiation, both Gateways authenticate each other, and agree on encryption methods and keys. After a successful IKE negotiation, a VPN tunnel is created. From now on, every packet that passes between the Gateways is encrypted according to the IPSec protocol. IKE supplies 24

25 VPN Communities authenticity (Gateways are sure they are communicating with each other) and creates the foundation for IPSec. Once the tunnel is created, IPSec provides privacy (through encryption) and integrity (via one-way hash functions). FIGURE 2-2 Confidentiality, integrity, and authentication via IPSec. After a VPN tunnel has been established (FIGURE 2-2), packets are dealt with in the following 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, the packets are standard IP packets passing through the Internet. However, because the packets 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 hosts perspective, they are connecting directly. For more information regarding the IKE negotiation, see: Understanding and Customizing IKE. VPN Communities Creating VPN tunnels between Gateways is made easier through the configuration of VPN communities. A VPN community is a collection of VPN enabled Gateways capable 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

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

27 VPN Topologies VPN Topologies The most basic topology consists of two Gateways capable of creating a VPN tunnel between them. SmartCenter Server s support of more complex topologies enables VPN communities to be created according to the particular needs of an organization. SmartCenter Server supports two main VPN topologies: Mesh Star Mesh VPN Community A Mesh is VPN community in which a VPN site can create a VPN tunnel with any other VPN site: FIGURE 2-4 Basic Mesh community Star VPN Community A star is a VPN community consisting of central Gateways (or hubs ) and satellite Gateways (or spokes ). In this type of community, a satellite can create a tunnel only with other sites whose Gateways are defined as central. Chapter 2 Building a VPN Between Gateways 27

28 The Check Point Solution for VPN FIGURE 2-5 Star VPN community A satellite Gateway cannot create a VPN tunnel with a Gateway that is also defined as a satellite Gateway. Central Gateways can create VPN tunnels with other Central Gateways only if the Mesh center gateways option has been selected on the Central Gateways page of the Star Community Properties window. Choosing a topology Which topology to choose for a VPN community depends on the overall policy of the the organization. For example, a mesh community is usually appropriate for an Intranet in which only Gateways which are part of the internally managed network are allowed to participate; Gateways belonging to company partners are not. A Star VPN community is usually appropriate when an organization needs to exchange information with networks belonging to external partners. These partners need to communicate with the organization but not with each other. The organization s Gateway 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 branch offices 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 comply with this policy, define two star communities, London and New York. Configure the London and New York Gateways as central Gateways. Configure the Gateways of 28

29 VPN Topologies New York and London branch offices as satellites. This allows the branch offices to communicate with the HQ in their country. Now create a third VPN community, a VPN mesh consisting of the London and New York Gateways. FIGURE 2-6 Two stars and mesh Topology and Encryption Issues Issues involving topology and encryption can arise as a result of an organization s policy on security, for example the country in which a branch of the organization resides may have a national policy regarding encryption strength. For example, policy says the Washington Gateways should communicate using 3DES for encryption. Policy also states the London Gateways must communicate uses DES as the encryption algorithm. In addition, the Washington and London Gateways (as shown in FIGURE 2-7) need to communicate with each other using the weaker DES. Consider the solution in FIGURE 2-7: Chapter 2 Building a VPN Between Gateways 29

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

31 VPN Topologies FIGURE 2-8 Special condition The London and New York Gateways belong to the London-NY Mesh VPN community. To create an additional VPN community which includes London, New York, 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 appear in another VPN community provided that they are incapable of creating a link between them in the second community. For example: FIGURE 2-9 Three VPN communities Chapter 2 Building a VPN Between Gateways 31

32 The Check Point Solution for VPN In FIGURE 2-9, The London and New York Gateways appear in the London-NY mesh. These two Gateways also appear as Satellite Gateways in the Paris Star VPN community. In the Paris Star, satellite Gateways (London and NY) can only communicate with the central Paris Gateway. Since the London and New York satellite Gateways cannot open a VPN link between them, this is a valid configuration. Authentication Between Community Members Before Gateways can exchange encryption keys and build VPN tunnels, they first need to authenticate to each other. Gateways authenticate to each other by presenting one of two types of credentials : Certificates. Each Gateway presents a certificate which contains identifying information of the Gateway itself, and the Gateway s public key, both of which are signed by the trusted CA. For convenience, VPN-1 has its own Internal CA that automatically issues certificates for all internally managed Gateways, requiring no configuration by the user. In addition, VPN-1 supports other PKI solutions. For more information, see: Using PKI Solutions. Pre-shared secret. A pre-shared is defined for a pair of Gateways. Each Gateway proves that it knows the agreed upon pre-shared secret. The pre-shared secret can be a mixture of letters and numbers, a password of some kind. Considered more secure, certificates are the preferred means. In addition, since the Internal CA on the SmartCenter Server automatically provides a certificate to each VPN-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 (a Gateway managed by a different SmartCenter Server) the externally managed Gateway: Might support certificates, but certificates issued by an external CA, in which case both Gateways need to trust the other s CA. (See: Using PKI Solutions. For more 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 External Gateways Using a Pre-Shared Secret on page 72. A secret is defined per external Gateway. If there are five internal Gateways and two externally managed Gateways, then there are two pre-shared secrets. The two pre-shared secrets are used by the five internally managed Gateways. In other words, all the internally managed Gateways use the same pre-shared secret when communicating with a particular externally managed Gateway. 32

33 Access Control and VPN Communities Access Control and VPN Communities Configuring Gateways into a VPN community does not create a de facto access control policy between the Gateways. The fact that two Gateways belong to the same VPN community does not mean the Gateways have access to each other. The configuration of the Gateways into a VPN community means that if these Gateways are allowed to communicate via an access control policy, then that communication is encrypted. Access control is configured in the Security Policy Rule Base. Using the VPN column of the Security Policy Rule Base, it is possible to create access control rules that apply only to members of a VPN community, for example: TABLE 2-1 Source Destination VPN Service Action Any Any Community_A HTTP Accept The connection is matched only if all the conditions of the rule are true, that is - it must be an HTTP connection between a source and destination IP address within VPN Community A. If any one of these conditions is not true, the rule is not matched. If all conditions 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 both VPN communities and host machines not in the community. For example: FIGURE 2-10 Access control in VPN communities Chapter 2 Building a VPN Between Gateways 33

34 Special Considerations for Planning a VPN Topology The rule in the Security Policy Rule base allows an HTTP connection between any internal IP with any IP: Source Destination VPN Service Action Any_internal_machine Any Any HTTP Accept In FIGURE 2-10, an HTTP connection between host 1 and the Internal web server behind Gateway 2 matches this rule. A connection between the host 1 and the web server on the Internet also matches this rule; however, the connection between host 1 and the internal web server is a connection between members of a VPN community and passes encrypted; the connection between host 1 and the Internet web server passes in the clear. In both cases, the connection is simply matched to the Security Policy Rule; whether or not the connection is encrypted is dealt with on the VPN level. VPN is another level of security separate from the access control level. Accepting all Encrypted Traffic If you select Accept all encrypted traffic on the General page of the VPN community Properties window, a new rule is added to the Security Policy Rule Base. This rule is neither a regular rule or an implied rule, but an automatic community rule, and can be distinguished by its beige colored background. Excluded Services In the VPN Communities Properties window Excluded Services page, you can select services that are not be encrypted, for example FireWall-1control connections. Services in the clear means do not make a VPN tunnel for this connection. For further information regarding control connections, see: How to Authorize FireWall-1 Control Connections in VPN Communities on page 75. Special Considerations for Planning a VPN Topology When 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 how will externally managed Gateways authenticate? Do these externally managed Gateways support PKI? Which CA should be trusted? 34