VPN-1 Power VSX. Administration Guide NGX Scalability Pack

Transcription

1 VPN-1 Power VSX Administration Guide NGX Scalability Pack December 21, 2006

2

3 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 Software Technologies Ltd. All rights reserved. Check Point, AlertAdvisor, Application Intelligence, Check Point Express, Check Point Express CI, the Check Point logo, ClusterXL, ConnectControl, Connectra, Connectra Accelerator Card, Cooperative Enforcement, Cooperative Security Alliance, CoSa, DefenseNet, Eventia, Eventia Analyzer, Eventia Reporter, Eventia Suite, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL, Integrity, Integrity Clientless Security, Integrity SecureClient, InterSpect, IQ Engine, MailSafe, NG, NGX, Open Security Extension, OPSEC, OSFirewall, Policy Lifecycle Management, Provider-1, SecureClient, SecureClient Mobile, SecureKnowledge, SecurePlatform, SecurePlatform Pro, SecuRemote, SecureServer, SecureUpdate, SecureXL, SecureXL Turbocard, SiteManager-1, SmartCenter, SmartCenter Express, SmartCenter Power, SmartCenter Pro, SmartCenter UTM, SmartConsole, SmartDashboard, SmartDefense, SmartDefense Advisor, Smarter Security, SmartLSM, SmartMap, SmartPortal, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM, UserAuthority, User-to-Address Mapping, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Express, VPN-1 Express CI, VPN-1 Power, VPN-1 Power VSX, VPN-1, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 UTM, VPN-1 UTM Edge, VPN-1 VSX, Web Intelligence, ZoneAlarm, ZoneAlarm Anti-Spyware, ZoneAlarm Antivirus, ZoneAlarm Internet Security Suite, ZoneAlarm Pro, ZoneAlarm Secure Wireless Router, Zone Labs, and the Zone Labs logo 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. 5,606,668, 5,835,726, 6,496,935, 6,873,988, and 6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending applications. For third party notices, see: THIRD PARTY TRADEMARKS AND COPYRIGHTS.

4

5 Contents Preface Who Should Use This Guide Summary of Contents Appendices Related Documentation More Information Chapter 1 Chapter 2 Chapter 3 Introduction to VSX Overview How It Works Common Uses for Virtual Systems VSX Architecture and Concepts Overview Virtual - Physical Comparison VSX Building Blocks Virtual Systems Virtual Systems in Bridge Mode Virtual Routers Virtual Switches Interfaces The VSX Gateway Managing the VSX Gateway Clustering in VSX Introduction VPN-1 Clustering VSX Clustering VSX Management Introduction Single IP for Cluster Management SmartCenter Management Model Provider-1 Management Model Management Models Summary Management of Virtual Devices VSX Packet Flow Typical Routing Scenario Routing from Virtual System to Virtual System Overlapping IP Address Space Support Deploying VSX Introduction Deploying VSX - an Internal View Table of Contents 5

6 Firewall Deployment in a Physical World Firewall Deployment in a Virtual World Physical Interface for Each Virtual System Virtual Interface (VLAN) for Each Virtual System Internal Virtual Router with Shared Interface Security for Virtual Systems in Bridge Mode Deploying VSX - an External View Core Side Security Enterprise Service Providers Data Centers Chapter 4 Chapter 5 Installing and Configuring VSX Overview Installation Steps VSX Management Installation VSX Management Clients Licensing Obtaining Licenses Understanding License Details VSX Provider-1 Bundle License License Violations Replacing the Trial Period License VSX Gateway/Cluster Configuration Using Provider Adding a CMA to Accommodate a VSX Gateway/Cluster Configuring a VSX Gateway Configuring a VSX Cluster Using the VSX Wizard to Create a VSX Cluster Removing a VSX Gateway/Cluster Dedicated Management Interface (DMI) Using VSX Overview Using Provider-1 to Manage VSX Adding New Customers Editing Customers Adding/Editing Virtual Systems in Provider Obtaining Status Information Using SmartCenter to Manage VSX Adding/Editing Virtual Systems Authentication Options for Virtual Systems Editing the Configuration of a VSX Cluster Adding New Members to a Cluster Removing Members From a Cluster Upgrading Cluster Members to VPN-1 Power VSX Resume Operation Logging VSX Gateway Recovery

7 Network Address Translation in VSX Advanced Routing Scenarios Obtaining Status Information Managing Security and VPN Policies Using SmartDashboard Source-Based Routing Configuring Unnumbered Interfaces Anti-Spoofing on VSX Interfaces Chapter 6 Chapter 7 Chapter 8 VSX Clustering with ClusterXL Introduction Connecting Several Clusters on the Same Layer-2 Segment Source Cluster MAC Addresses Using the cphaprob Command in VPN-1 Power VSX Monitoring all VLANs Single Virtual System Failover Enabling Dynamic Routing Protocols in a Cluster Deployment Components of the System Dynamic Routing in ClusterXL Virtual Switch in a Cluster Clustering Virtual Systems in Bridge Mode (for ClusterXL only) Using PVST+ for Load Sharing ClusterXL Virtual System Load Sharing Introduction to ClusterXL Load Sharing How it Works Introduction to How it Works Backup State Standard Operation A Failure Scenario Another Failure Scenario Recovery Configuration Introduction to Configuration Enable Per Virtual System State Mode Set Up ClusterXL Load Sharing Reviewing Virtual System Distribution Redistributing Virtual Systems Among Cluster Members CLI Commands New Commands in this Release Commands Modified for VPN-1 Power VSX Resource Control Introduction to Resource Control Virtual System Resource Quotas Architecture Configuration File CLI Commands for Resource Control Table of Contents 7

8 fw vsx resctrl enforce fw vsx resctrl monitor fw vsx resctrl traffic_stat fw vsx resctrl reset fw vsx resctrl start fw vsx resctrl stat Chapter 9 Chapter 10 Lightweight QoS Enforcement Overview Architecture Differentiated Services Support Inbound Prioritization Policy with Global Scope QoS Features Bandwidth Allocation Latency WRED QoS Management Class of Service Definitions Priority and LLQs Priority and Drop Precedence User Interface cpqos Command Usage QoS Policy File QoS Default Configuration Sample Differentiated Services Implementation VSX Diagnostics and Troubleshooting Introduction Troubleshooting VSX What to do if you suspect there s a problem Failed to establish Trust with VSX gateway during the VSX Creation Wizard Problem description After pressing Get Configuration button, Sync networks don t match Problem description Failed to install policy on the VSX gateway during VSX Creation Wizard Problem description Failed to establish trust with newly created Virtual System/Virtual Router Problem description Internal host behind Virtual System cannot ping internal IP Address of Virtual System Problem description Internal host behind Virtual System cannot ping external IP address of Virtual System Problem description Internal host behind Virtual System cannot ping an external host Problem description

9 Chapter 11 Appendix A Appendix B Appendix C Command Line Reference Aspects of VSX Networking Overview Supporting Switched Networks IP Routing Dynamic Routing Scenarios Multi-Protocol Environments Internal Connectivity Multicast Routing SmartDefense Protections for VSX Gateways Supported SmartDefense Protections Supported Web Intelligence Protections Finding Out More Adding Members Introduction to Adding a Member to a VSX Cluster Adding a Member to a VSX Cluster Index Table of Contents 9

10 10

11 Preface P Preface In This Chapter Who Should Use This Guide page 12 Summary of Contents page 13 Related Documentation page 15 More Information page 18 11

12 Who Should Use This Guide Who Should Use This Guide This guide is intended for administrators responsible for maintaining network security within an enterprise, including policy management and user support. This guide assumes a basic understanding of: system administration the underlying operating system Internet protocols (IP, TCP, UDP etc.) 12

13 Summary of Contents Summary of Contents This guide contains the following chapters: Chapter Chapter 1, Introduction to VSX Chapter 2, VSX Architecture and Concepts Chapter 3, Deploying VSX Chapter 4, Installing and Configuring VSX Chapter 5, Using VSX Chapter 6, VSX Clustering with ClusterXL Chapter 7, ClusterXL Virtual System Load Sharing Chapter 8, Resource Control Chapter 9, Lightweight QoS Enforcement Chapter 10, VSX Diagnostics and Troubleshooting Chapter 11, Command Line Reference Description Provides an overview of VSX Describes the architecture of a VSX gateway/cluster, compares it to a physical gateway/cluster, and provides examples of typical deployments. The chapter also introduces the two management models available. Covers scenarios related to VSX deployments. Describes how to install and configure a VSX gateway/cluster. Describes how to manage the VSX gateway/cluster using Provider-1 or SmartCenter management models. Describes issues related to ClusterXL. Describes how to distribute Virtual Systems on different members of a cluster. Describes how to distribute a VSX machine s CPU usage between Virtual Systems. Describes how to control the network quality of service in the VSX network environment. Provides diagnostic tools and typical examples of issues that may arise during installation and configuration of the VSX gateway/cluster. Describes commands used for obtaining diagnostic information, status information, and for configuring the deployment. Preface 13

14 Appendices Appendices This guide contains the following appendices: Appendix Chapter A, Aspects of VSX Networking Chapter B, SmartDefense Protections for VSX Gateways Chapter C, Adding Members Description Covers scenarios related to VSX networking. Lists the SmartDefense and Web Intelligence protections supported by VSX. Details the steps necessary to add a member to a VSX cluster. 14

15 Related Documentation Related Documentation The NGX R62 release includes the following documentation TABLE P-1 VPN-1 Power documentation suite documentation Title Getting Started Guide Upgrade Guide SmartCenter Guide Firewall and SmartDefense Guide Eventia Reporter Description Contains an overview of NGX R62 and step by step product installation and upgrade procedures. This document also provides information about What s New, Licenses, Minimum hardware and software requirements, etc. Explains all available upgrade paths for Check Point products from VPN-1/FireWall-1 NG forward. This guide is specifically geared towards upgrading to NGX R62. Explains SmartCenter Management solutions. This guide provides solutions for control over configuring, managing, and monitoring security deployments at the perimeter, inside the network, at all user endpoints. Describes how to control and secure network access; establish network connectivity; use SmartDefense to protect against network and application level attacks; use Web Intelligence to protect web servers and applications; the integrated web security capabilities; use Content Vectoring Protocol (CVP) applications for anti-virus protection, and URL Filtering (UFP) applications for limiting access to web sites; secure VoIP traffic Explains how to monitor and audit traffic, and generate detailed or summarized reports in the format of your choice (list, vertical bar, pie chart etc.) for all events logged by Check Point VPN-1 Power, SecureClient and SmartDefense. Preface 15

16 Related Documentation TABLE P-1 VPN-1 Power documentation suite documentation (continued) Title SmartView Tracker Guide SecurePlatform Guide Provider-1 Guide Description Provides information about how to collect comprehensive information on your network activity in the form of logs. Learn how to use SmartView Tracker to audit these logs at any given time, analyze traffic patterns and troubleshoot networking and security issues. Explains how to install and configure SecurePlatform. This guide will also teach you how to manage your SecurePlatform and explains Dynamic Routing (Unicast and Multicast) protocols. Explains the Provider-1/SiteManager-1 security management solution. This guide provides details about a three-tier, multi-policy management architecture and a host of Network Operating Center oriented features that automate time-consuming repetitive tasks common in Network Operating Center environments. TABLE P-2 Integrity Server documentation Title Integrity Advanced Server Installation Guide Integrity Advanced Server Administrator Console Reference Integrity Advanced Server Administrator Guide Integrity Advanced Server Gateway Integration Guide Description Explains how to install, configure, and maintain the Integrity Advanced Server. Provides screen-by-screen descriptions of user interface elements, with cross-references to relevant chapters of the Administrator Guide. This document contains an overview of Administrator Console navigation, including use of the help system. Explains how to manage administrators and endpoint security with Integrity Advanced Server. Provides information about integrating your Virtual Private Network gateway device with Integrity Advanced Server. This guide also contains information regarding deploying the unified SecureClient/Integrity client package. 16

17 Related Documentation TABLE P-2 Integrity Server documentation (continued) Title Integrity Advanced Server System Requirements Integrity Agent for Linux Installation and Configuration Guide Integrity XML Policy Reference Guide Integrity Client Management Guide Description Provides information about client and server requirements. Explains how to install and configure Integrity Agent for Linux. Provides the contents of Integrity client XML policy files. Explains how to use command line parameters to control Integrity client installer behavior and post-installation behavior. Preface 17

18 More Information More Information 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 18

19 Chapter 1 Introduction to VSX In This Chapter Overview page 20 How It Works page 21 Common Uses for Virtual Systems page 22 19

20 Overview Overview VSX is a high-speed, multi-policy security solution designed for large enterprises, data centers and service provider POPs. By aggregating multiple security domains on a single platform, VPN-1 Power VSX minimizes hardware investment through the use of virtualization. Virtualization utilizes a single pool of physical resources for multiple autonomous systems. Each autonomous system provides identical services and operates as a completely isolated physical entity. 20

21 How It Works How It Works VPN-1 Power VSX provides a set of virtual components acting as real network devices such as Firewall gateways, routers, switches, and network cables. Using these virtual components, network topologies are created that are functionally equivalent to networks built with physical devices. Each Virtual Firewall, called a Virtual System, functions as a separate Firewall. As packets arrive at a VSX gateway, the VSX gateway selects the appropriate Virtual System to handle them. Instead of using multiple VPN-1 gateways (each protecting a single internal network) a single VPN-1 Power VSX gateway is used to protect multiple networks. Figure 1-1 Multiple Virtual Systems. Figure 1-1 shows multiple Virtual Systems sharing an external VLAN while the internal VLANs remain unique. Each network is protected by a separate Virtual System. VSX uses the same patented Stateful Inspection and Application Intelligence technology used in market-leading VPN-1 Power. It can run on one of several gigabit platforms to deliver the required performance in high-bandwidth environments. VPN-1 Power VSX is managed using Check Point's SmartCenter server or Provider-1/SiteManager-1, delivering a unified management architecture that service providers and enterprises can also use to manage all their other Check Point security gateways. Chapter 1 Introduction to VSX 21

22 Common Uses for Virtual Systems Common Uses for Virtual Systems Virtual systems are most commonly used by: Service Providers selling firewall services College campuses isolating departments Enterprises enforcing distinct security policies per department Any large enterprise requiring more than a single firewall In each case, Virtual Systems provide access control, NAT, VPN, logging, and SmartDefense services. For more information on VSX deployments, see: Chapter 3, Deploying VSX. 22

23 Chapter 2 VSX Architecture and Concepts In This Chapter Overview page 24 Virtual - Physical Comparison page 25 VSX Building Blocks page 27 The VSX Gateway page 34 Clustering in VSX page 37 VSX Management page 42 VSX Packet Flow page 46 Overlapping IP Address Space Support page 50 23

24 Overview Overview This chapter describes VSX architecture and the concepts you need to understand in order to plan, install, configure, and operate a VSX deployment. A VSX system provides a set of virtual components acting as physical network devices such as Firewall gateways, routers and network cables. Using these virtual components, you can create network topologies functionally equivalent to the networks you would build using physical devices. The term Virtual Devices refers to Virtual Systems, Virtual Switches, and Virtual Routers. The term virtual components refers to Virtual Devices plus the virtual linking (warp) cables between them. This chapter also compares a physical VPN-1 gateway with a VSX gateway consisting of virtual components. The virtual building blocks of a VSX system are explained, as are their relationship to equivalent physical components. After seeing how a VSX gateway can be built-up, this chapter describes how VSX gateways can be used in cluster mode, for system high availability or load sharing, in the same manner as regular gateways can be clustered. The chapter also introduces some of the advanced capabilities and configurations of VSX gateways/clusters. Finally the chapter describes the alternative management models that you can use to manage the VSX deployment. 24

25 Virtual - Physical Comparison Virtual - Physical Comparison The VSX gateway, a single configurable hardware device, acts as a replacement for network topologies consisting of several physical routers and switches and physical VPN-1 gateways. It enables multiple independent networks to be protected by a single machine. In order to understand the deployment characteristics of a VSX environment this section compares the physical with the virtual. Figure 2-2 shows a classic deployment of three 'physical' firewalls each protecting a different network. Figure 2-2 Separate physical gateways protecting each network Figure 2-3 shows how a single VSX gateway, incorporating in this case three Virtual Systems, can protect these different networks. Chapter 2 VSX Architecture and Concepts 25

26 Virtual - Physical Comparison Figure 2-3 A VPN-1 Power VSX gateway replaces multiple physical gateways Each Virtual System in Figure 2-3 functions as a separate Firewall. Using a VSX gateway/cluster you are able to have Virtual Systems replace physical VPN-1 gateways. The figure also shows: Three Virtual Systems, each handling the traffic of packets to and from discrete networks. One Virtual Switch providing connectivity for all the Virtual Systems to the Internet router. Warp Links, marked as dotted lines, providing point-to-point connection between the Virtual Systems and the Virtual Switch. 26

27 VSX Building Blocks VSX Building Blocks In This Section Virtual Systems page 27 Virtual Systems in Bridge Mode page 28 Virtual Routers page 28 Virtual Switches page 29 Interfaces page 30 This section introduces each of the virtual components, their characteristics and variants. Virtual Systems A Virtual System is a routing and security domain featuring Firewall and VPN capabilities. Multiple Virtual Systems can run concurrently on a single VSX gateway, isolated from one another by their use of separate system resources and data storage. Virtual System Autonomy Since layer-3 and layer-2 networking might need to support different types of Dynamic Routing protocols, each Virtual System (whether in bridge or routing mode) is autonomous, maintaining its own: State Tables - tables holding configuration and runtime information such as Network Address Translation rules, active connections, active IPSec tunnels, etc. Security and VPN policies - each Virtual System enforces its own Security and VPN Policies (including INSPECT code), which are individually downloaded from the management server and kept separately on disk and in the kernel. Configuration Parameters - each Virtual System is configured separately and maintains its own configuration tables, such as SmartDefense settings, TCP/UDP time-outs, etc. Logging - each Virtual System can be configured to log its operations. Chapter 2 VSX Architecture and Concepts 27

28 VSX Building Blocks Each Virtual System can, depending on the management model, have its own separate administrators, or you can define a single administrator for groups of Virtual Systems according to your requirements. For more information on the management models, refer to VSX Management on page 42. Virtual Systems in Bridge Mode A Virtual System in bridge mode is a Virtual System that implements native layer-2 bridging instead of IP routing. This type of Virtual System can be deployed without requiring changes to the existing IP (layer-3) infrastructure. A Virtual System in bridge mode is used to forward traffic at layer-2. A typical network connection in such a scenario will involve an 802.1q VLAN switch on either side of the VSX gateway. The interfaces of the bridge do not require IP addresses. The Virtual System in bridge mode remains transparent to the existing IP network. A Virtual System in Bridge mode: Has the same Firewall security capabilities of a Virtual System except for VPN and NAT Enables easier configuration of Virtual Systems since no IP addresses or routing information is required. Does not segment an existing network. Needs Topology to be manually defined in order to enforce anti-spoofing In a ClusterXL environment, requires a Spanning Tree Protocol to prevent loops. See: Clustering Virtual Systems in Bridge Mode (for ClusterXL only) on page 151 Virtual Routers Virtual Routers are independent routing domains within a VSX gateway that function like physical routers. Virtual Routers are used to route: Packets arriving at the VSX gateway through a shared interface to the relevant Virtual System based on the source or destination IP address of a packet. Traffic arriving from Virtual Systems directed to a shared interface or to other Virtual Systems. Traffic to and from shared network resources such as DMZs. 28

29 VSX Building Blocks As with physical routers, each Virtual Router maintains a Routing Table with a list of route entries describing known networks and directions on how to reach them. Depending on the deployment requirements multiple Virtual Routers can be configured. To protect itself, a Virtual Router conducts a full Firewall security inspection of all traffic directed to or originating from itself (for example, an ICMP ping to the Virtual Router IP address) using its own Security Policy. By default, all such packets are dropped. All other packets are forwarded according to the route table entries. Virtual Switches A Virtual Switch provides layer-2 connectivity between Virtual Systems, and connectivity to a shared interface. As with a physical switch, each Virtual Switch maintains a forwarding table with a list of MAC addresses and their associated ports. In contrast to a Virtual Router, when sharing a physical interface via a Virtual Switch there is no need: To allocate an additional subnet for IP addresses of Virtual Systems connected to the switch. To manually configure the routing on the routers adjacent to the shared interface. Depending on the deployment, multiple Virtual Switches can be configured. Note - When sharing a physical interface via a Virtual Switch, the IP addresses of Virtual Systems connected to the Virtual Switch should be allocated from the same subnet as the shared interface. If the only function the Virtual Switch performs is to connect between Virtual Systems, then the Virtual Switch can be defined without interfaces. Chapter 2 VSX Architecture and Concepts 29

30 VSX Building Blocks Interfaces In This Section Physical Interfaces page 32 Virtual (VLAN) Interfaces page 32 Warp Links page 33 This section describes the three types of interfaces and how they are used in a VSX configuration. The three interface types are: Physical Interface Virtual (VLAN) interface Warp Link, and Unnumbered (a variant of the warp link) Figure 2-4 shows how these interfaces are used to connect Virtual Systems, a Virtual Switch, and protected networks to the Internet. 30

31 VSX Building Blocks Figure 2-4 VSX interface types In Figure 2-4: Warp Links connect the Virtual Switch to each Virtual System A Physical Interface connects the Virtual Switch to an external router leading to the Internet Virtual Interfaces connect Virtual Systems to the VLAN Switch and the protected networks Chapter 2 VSX Architecture and Concepts 31

32 VSX Building Blocks Physical Interfaces A typical VSX gateway in a VSX cluster has four physical interfaces: Dedicated Management Interface - connects the VSX gateway to the management server when locally managed. If the VSX gateway is remotely managed, then the management connection can be through a Virtual Switch or Virtual Router. External interface - connects the VSX gateway to the Internet or other untrusted networks. Internal Interface - connects the VSX gateway to a protected (Trusted) network. Synchronization Interface - connects the VSX gateway to other VSX gateways for State Synchronization in a VSX clustering deployment. Additional Physical Interfaces can be installed and attached to any Virtual Device as required. Virtual (VLAN) Interfaces Virtual Systems usually connect to protected VLAN networks using IEEE 802.1q compliant VLAN Interfaces. The networks are connected to ports of a 802.1q-compliant switch that trunks all traffic over a single physical Ethernet interface to the VSX gateway. Figure 2-5 shows how the 802.1q-compliant switch inserts a tag (known as a VLAN tag) into the Ethernet frames. VSX uses these tags to direct the Ethernet frames to the Virtual System handling each network. As the packets leave the VSX gateway/cluster for an external network, the VLAN tags are stripped. 32

33 VSX Building Blocks Figure q VLAN tagging Warp Links Virtual Systems connect to Virtual Routers or Virtual Switches using Warp Links. A Warp Link is a virtual point-to-point connection between a Virtual System and a Virtual Router or Virtual Switch. On each side of the link there is a Warp Interface. These are normally named wrpn on the Virtual System side and wrpjn on the Virtual Router/Switch side, where N is a number. The numbers assigned to the Warp Links are automatically allocated by the system when the warp link is created. Unnumbered Interfaces An interface of a Virtual System connected to a Virtual Router can be configured as unnumbered. This means the interface borrows an IP address from another interface. An unnumbered interface is a variant of the warp link. For more information see: Configuring Unnumbered Interfaces on page 137. Chapter 2 VSX Architecture and Concepts 33

34 The VSX Gateway The VSX Gateway The VSX gateway: Handles provisioning and configuration of Virtual Devices. Manages Gateway State Synchronization when working with clusters. Provides a single IP for communication with a management entity (Provider-1, or SmartCenter server), and authentication servers such as LDAP, Radius, TACACS, or SNMP. Managing the VSX Gateway The management server - SmartCenter server or Provider-1 - connects with the VSX gateway object to deliver provisioning and configuration commands for Virtual Devices on each VSX gateway. The management server can connect to the VSX gateway object using one of two methods: Local (on-site) management server Remote (off-site) management server Local Management Server In this scenario, management traffic passes through a Dedicated Management Interface, as shown in Figure 2-6. The IP address of the VSX gateway object in this case can be either private or public. 34

35 The VSX Gateway Figure 2-6 Basic VSX with local management station Remote Management Server In this scenario, management traffic passes through an external network. The connection to the VSX gateway object is always through a Warp Link to a Virtual Router or Virtual Switch using a public IP address, as shown in Figure 2-7. This IP address must be assigned from the external network. Chapter 2 VSX Architecture and Concepts 35

36 The VSX Gateway Figure 2-7 Basic VSX deployment with remote management station If the connection is through the Internet, a routable public address must be assigned. 36

37 Clustering in VSX Clustering in VSX In This Section Introduction Introduction page 37 VPN-1 Clustering page 37 VSX Clustering page 38 VSX Management page 42 VSX gateway clustering ensures high system availability through transparent gateway failover. In addition, on some clusters that permit load sharing, performance is enhanced by distributing network traffic between cluster members. If you determine that the benefits of clustering are appropriate for the planned VSX deployment then from the beginning structure the environment to support clustering. A VSX gateway cluster is a group of identical VSX gateways that are connected in such a way that if one fails, another immediately takes its place and traffic continues to flow. Clustering enables high availability, and answers the following needs: Transparent failover in case of machine failure. Zero downtime for mission-critical environments (when using State Synchronization). VPN-1 Clustering Since VSX clustering is based on VPN-1 clustering, this section first reviews physical VPN-1 clustering, and then demonstrates how the same principles are applied on the virtual level in VSX gateways. In VPN-1, as opposed to VSX, the term cluster is applied to an aggregate of Physical gateways - the cluster members. The cluster behaves as a single VPN-1 gateway and is assigned its own IP address, also known as a Virtual IP. This is distinct from the IP addresses of its two cluster members, which are hidden from the networks connected to the cluster. Figure 2-8 shows a basic gateway cluster: Figure 2-8 Basic gateway cluster. Chapter 2 VSX Architecture and Concepts 37

38 Clustering in VSX Figure 2-8 VPN-1 cluster The Internet Physical Router receives packets from the Internet directed to the Internal Networks, and forwards them to the cluster External Virtual IP. Depending on the clustering mode - High Availability or Load Sharing - one of the cluster members picks up the packet for inspection. Following inspection, packets are either sent to their destination on the internal network, or dropped. The internal network sends packets, (whose destination is an IP address on the Internet) to the cluster virtual IP address. The packet is processed by one of the cluster members, inspected, and forwarded to the physical router that leads to the Internet. Each cluster member has unique real IP addresses assigned to all of its interfaces. These IP addresses are used internally by each cluster member for communication between the cluster members and for management tasks such as downloading policies, sending logs and checking the status of individual cluster members. For detailed information on clustering, refer to the ClusterXL Guide. VSX Clustering As with clustering in a physical system, VSX clustering involves connecting two or more VSX gateways in such a way that if one fails, another immediately takes its place. VSX clusters are defined at two levels: The VSX gateway level The Virtual Device level VSX Gateway Level Virtual devices and interfaces are configured identically on each of the VSX cluster members. Figure 2-9 shows a VSX cluster in which each Virtual Device on a particular VSX machine has a corresponding Virtual Device running on each of the other VSX machines that comprise the cluster. 38

39 Clustering in VSX Figure 2-9 VSX clustering Virtual Device Level Virtual Device level clustering enables the VSX cluster to perform operations required for specific Virtual cluster members, such as: Using cluster virtual addresses. Each interface of a Virtual Device has a virtual IP address which is used to communicate with the network. State synchronization. The state tables of each Virtual device are synchronized to its Virtual Device peers on the other members of the cluster. Comprehensive Planning As with any type of network deployment, the IP address allocation for a VSX configuration requires careful planning. This section takes you through the basics of IP address allocation for a VSX environment. Your choice of VSX configuration will affect the number of IP addresses required, both public and private. Chapter 2 VSX Architecture and Concepts 39

40 Clustering in VSX VSX Cluster IP Design VSX IP address design is very much similar to traditional networks - it has real and virtual IP addresses for connectivity, management IP for provisioning, and a network for the state synchronization. While VSX virtualizes the network and security environment, it also simplifies the management process. Configuration is made easier by eliminating redundant tasks such as IP address assignment to the interfaces of a Virtual device. A VSX configuration is built from three components: Synchronization Network Internal Communications Network Virtual IP addresses Synchronization Network The synchronization network, a physical network, is configured during the initial VSX cluster configuration. A VSX gateway in a cluster implements state synchronization. The standby member is continually updated on all concurrent sessions taking place on the active member. If the active member fails, the standby member picks up and continues the session. State Synchronization is used in VSX deployments where both ClusterXL and OPSEC-certified VSX solutions are employed. The synchronization network must be configured using an IP address that is different from the internal communication network. Internal Communication Network The internal communication network is different from the synchronization network, and is only relevant for Check Point ClusterXL environments. Whereas the synchronization network is a physical network, the internal communication network is a logical network used for communication (not synchronization) between VSX components. The address of the internal communication network is assigned during the initial creation of the VSX cluster, and eliminates the need to manually assign IP addresses to each cluster member. This network enables the cluster members to communicate and recognize the state of the environment. While dedicated VPN-1 40

41 Clustering in VSX clusters require the configuration of the physical interfaces, the internal communication network provides a pool for automatic IP assignment. This network is invisible to the external network and contained solely within the cluster. During the cluster creation process, the network is automatically assigned a default IP address range consisting of four class C networks: IP address: Netmask: The default IP address can be modified on the Properties > Cluster members page of the VSX object but only prior to creating Virtual Systems. Once Virtual Systems have been created, the IP range of the internal communication network cannot be modified. Note - To avoid overlapping IP addresses, before creating any Virtual Devices, make sure the default IP address range of the Internal Communication network is not used anywhere else in the external network. Virtual IP Addresses The Virtual IP addresses are the only IP addresses visible to the external network. The IP addresses assigned must correspond to the directly-connected network and pose as a next hop address. These IP addresses are similar to virtual addresses configured across traditional cluster setups. The virtual IP addresses complement the internal communication network. Chapter 2 VSX Architecture and Concepts 41

42 VSX Management VSX Management In This Section Introduction Introduction page 42 Single IP for Cluster Management page 42 SmartCenter Management Model page 43 Provider-1 Management Model page 43 Management Models Summary page 44 Management of Virtual Devices page 45 Check Point offers two management alternatives - SmartCenter server and Provider-1. Both enable centrally configuring, managing and monitoring multiple VSX gateways and Virtual Systems. The choice of management model depends on: The size of the deployment and planned expansion Administrative requirements Operations model and licensing restrictions. According to the Check Point EULA (End User License Agreement), a SmartCenter server can only be used to manage the security policy/policies of VPN-1 gateways and/or Virtual Systems that belong to a single legal entity. In order to manage VPN-1 gateways and/or Virtual Systems that belong to multiple legal entities, you need to have a separate SmartCenter per legal entity or deploy a Provider-1 management solution with a separate CMA per legal entity. For more information regarding Licensing, refer to your Check Point Reseller. Both management models can be used to manage physical VPN-1 gateways together with VSX gateways and Virtual Systems. Single IP for Cluster Management VSX gateways/clusters are managed using either SmartCenter server or Provider-1. Choice of a management model depends on the deployment size, administration requirements, licensing and legal considerations. 42

43 VSX Management SmartCenter Management Model This management model provides a three-tier structure: SmartDashboard connects to SmartCenter server, which in turn manages a Virtual or Physical gateway, as shown in Figure Figure 2-10 VPN-1 Power VSX SmartCenter management model SmartCenter server provides a single management domain with one object database and an unlimited number of policies that can be used to manage Virtual Devices as well as other physical devices. This model supports any number of administrators. Only one administrator at a time can use SmartDashboard to provision Virtual Systems, and configure security policies. The SmartCenter management model is recommended for Enterprise deployments of up to 25 Virtual Systems. For more information refer to the SmartCenter Guide. Provider-1 Management Model Provider-1 is designed to meet the unique challenges of service providers and large enterprises. For service providers, it consolidates customer security policies into a centralized policy management architecture that scales to support thousands of customers while minimizing investment in hardware and labor. For a large enterprise, Provider-1 simplifies a complex security policy by segmenting it into more manageable sub-policies to match geographic, functional, or other logical groupings, each of which can be enforced on a different Virtual System. Figure 2-11 shows an example of a VSX deployment with the Provider-1 Management Model. Chapter 2 VSX Architecture and Concepts 43

44 VSX Management Figure 2-11 VSX Provider-1 Management Model Using the Provider-1 Multi-Domain Graphical User Interface (MDG) you can create and operate multiple management domains (CMAs, or Customer Management Add-Ons). Each CMA domain provides full SmartCenter functionality and can manage one or more Virtual Systems or Physical gateways located at a customer's premises. You can also manage VPN Communities including both of these gateway types. Based on their access permissions, multiple administrators can access different CMAs concurrently. In addition, given the appropriate permissions, customers can manage their Virtual Systems in Read or Write mode and view logs, etc., from their own premises. Management Models Summary Table 2-1 summarizes the capabilities and differences between the Management Models. Table 2-1 VSX Management Model Capacities SmartCenter Provider-1 Management Domains One Unlimited Concurrent Administrators One Unlimited Object Databases One Unlimited Policies Unlimited Unlimited Certificate Authorities One Unlimited Virtual Systems 25 (recommended) Unlimited 44

45 VSX Management Management of Virtual Devices Virtual Devices are easily provisioned and maintained using SmartCenter server and Provider-1/SiteManager-1 VSX systems extend the functionality of these tools by allowing the administrator to configure all network settings (such as interfaces and routing tables) in addition to security. The management server (either SmartCenter or Provider-1) uses a separate communication channel for provisioning Virtual Devices, configuring their networking, and security management. The channel is implemented over a Secure Internal Communication (SIC) connection. Secure Internal Communication Trust between VSX gateway/cluster members and the management server is first established using a one-time password entered when the system is configured. The communication channel is created between the management server and the VSX gateway. In a VSX cluster, the channel is created to each member of the VSX cluster. The SIC communication channel is also used for policy installation, logging and status monitoring. The management server does not distinguish between physical gateways and virtual gateways. In Provider-1, the channel is created to the CMA on which the VSX cluster resides. Provisioning Virtual Devices The provisioning process includes: Creation of a Virtual Device object in the management database Creation of a Secure Internal Communication Certificate for the new Device Creation of the Virtual Device on the VSX gateway/vsx cluster members Transfer and installation of the Secure Internal Communication Certificate for the Virtual Device to the VSX gateway/vsx cluster members Configuration of the Virtual Device Interfaces and Routing Table according to the user settings Once provisioned, a Virtual System appears in SmartDashboard as a regular VPN-1 Network Object (with a different icon). Chapter 2 VSX Architecture and Concepts 45

46 VSX Packet Flow VSX Packet Flow In This Section Typical Routing Scenario page 46 Routing from Virtual System to Virtual System page 48 Typical Routing Scenario In a typical scenario each packet entering the VSX gateway passes through two main processes: Context Determination Security Processing and Forwarding Context Determination When a packet arrives, the VSX gateway determines which Virtual System should handle it. This process is known as Context Determination. If the packet arrives at an interface (either physical or virtual) directly attached to a specific Virtual System, this association determines context and the packet is immediately processed by the Virtual System. In Figure 2-12, VS 2 immediately processes a packet arriving at the 802.1q Virtual Interface eth1.200: 46

47 VSX Packet Flow Figure 2-12 Packet flow -direct interface If the packet arrives at a shared interface attached to a Virtual Router or Virtual Switch (such as when a packet arrives from an external network or the Internet): For a Virtual Switch 1. The Virtual Switch determines which Virtual System should handle the packet by matching the destination MAC address inside the packet to an address in the switch s forwarding table. 2. Based on the forwarding decision, the packet is sent to the relevant Virtual System through a warp link. Chapter 2 VSX Architecture and Concepts 47

48 VSX Packet Flow For a Virtual Router 1. If the packet is targeted at the Virtual Router interface itself (for example, an ICMP ping), the packet is matched against the Virtual Router s security policy, and sent for processing by the Virtual Router (if the policy on the Virtual Router permits). 2. Otherwise, the Virtual Router determines which Virtual System should handle the packet by doing a route lookup on the Virtual Router s route table. The route lookup can be: Destination based, or Source based (see: Internal Virtual Router with Shared Interface on page 58), or Both 3. Based on the route decision, the packet is forwarded to the relevant Virtual System through a warp link. Routing from Virtual System to Virtual System In the same manner that Physical Routers/Switches forward traffic between networks in a physical system, Virtual Routers/Switches are also used to forward traffic between networks. Figure 2-13 shows an example of how Virtual Systems connected to the same Virtual Switch communicate. In Figure 2-13 a host in Network 1 sends information to a server in Network 2: 48

49 VSX Packet Flow Figure 2-13 Routing of virtual traffic between Virtual Systems 1. The packet from Network 1 is tagged by the VLAN Switch and forwarded to the VSX gateway. 2. Based on the VLAN tag, the VSX gateway determines that the packet should be processed by VS1. 3. VS1 examines the packet based on its policy and if the policy permits, forwards the packet to the Virtual Switch. 4. Using its forwarding table the Virtual Switch sends the packet to VS2. 5. VS2 examines the packet and based on its policy, sends the packet to Network 2, through the VLAN Switch. Chapter 2 VSX Architecture and Concepts 49

50 Overlapping IP Address Space Support Overlapping IP Address Space Support A number of networking scenarios require a single VSX gateway to protect several networks that possess the same IP address space. This is possible in a VSX system because Virtual Systems maintain completely separate state and routing tables, which enables the holding of similar entries, but within different contexts. In addition, Virtual Systems support Network Address Translation (NAT). Network Address Translation (NAT) enables mapping of internal IP addresses to one or more external IP addresses. Figure 2-14 shows how traffic is routed between the Internet and internal networks with overlapping IP address ranges using NAT conducted at each Virtual System. Figure 2-14 Forwarding traffic with overlapping IP addresses In Figure 2-14, Network 1, Network 2 and Network 3 all use the same network address, which might result in identical overlapping IP addresses. However, packets originating from or targeted at these networks are processed by their respective Virtual System that uses NAT to translate the original/overlapping addresses to unique routable addresses. 50

51 Chapter 3 Deploying VSX In This Chapter Introduction page 52 Deploying VSX - an External View page 61 51

52 Introduction Introduction This chapter covers a VSX deployment as seen from two points of view: Internally, at the level of the VSX Externally, on the network level 52

53 Deploying VSX - an Internal View In This Section: Firewall Deployment in a Physical World Deploying VSX - an Internal View Firewall Deployment in a Physical World page 53 Firewall Deployment in a Virtual World page 55 Virtual Interface (VLAN) for Each Virtual System page 56 Internal Virtual Router with Shared Interface page 58 Security for Virtual Systems in Bridge Mode page 60 In a large physical network, multiple VPN-1 gateways would be deployed to protect each subnet, as shown in Figure 3-1. Figure 3-1 shows three firewalls connected to a router. In this example, public IP addresses are used for the connection from the gateway to the router and through to the Internet. Internal IP addresses are used for the connection from the gateways to the local networks. Using Network Address Translation (NAT), overlapping internal IP addresses can be used, as shown in the example. Note - In this example and throughout this book, IP addresses starting x.x denote public IP addresses. Chapter 3 Deploying VSX 53

54 Deploying VSX - an Internal View Figure 3-1 Physical firewall deployment using private IP addresses Figure 3-2 shows the same configuration. Instead of private IP addresses for the local networks, public IP addresses are used. In this configuration NAT is not required, and there can be no overlapping of IP addresses since real IP addresses are used. Figure 3-2 Basic firewall deployment using public IP addresses 54

55 Firewall Deployment in a Virtual World Deploying VSX - an Internal View This section looks at three VSX-based configurations where virtual is the alternative to the physical firewall: VSX with a physical interface for each Virtual System (Figure 3-3) VSX with one VLAN interface for each Virtual System Figure 3-4 VSX with an Internal Virtual Router (IVR) and a shared interface (Figure 3-5) All these examples have similar overall network functionality as the physical gateway configurations shown in Figure 3-1 and Figure 3-2, but they highlight the differences in IP addressing requirements. Physical Interface for Each Virtual System Figure 3-3 shows a VSX configuration with physical interfaces for each Virtual System. This VSX deployment retains the same IP addressing configuration as shown in Figure 3-1. This configuration enables overlapping addressing. Its main limitation being that each local network requires its own dedicated physical interface on the VSX. This configuration is not suitable for implementations that require many Virtual Systems. Chapter 3 Deploying VSX 55

56 Deploying VSX - an Internal View Figure 3-3 Basic VSX gateway with separate physical interfaces Virtual Interface (VLAN) for Each Virtual System In this configuration option, instead of multiple physical interfaces as shown in the previous example (Figure 3-3), Virtual Systems are connected to the protected networks using Virtual (VLAN) Interfaces. Figure 3-4 shows this configuration. The VSX gateway is connected to a VLAN Switch using a single physical connection: a VLAN trunk. The trunk is an aggregate of all VLANs that go through it. 56

57 Deploying VSX - an Internal View Figure 3-4 Basic VSX deployment with a VLAN interface This configuration option enables large numbers of networks to be connected to a VSX gateway/cluster. IP addressing is similar to the two previous examples (Figure 3-1 and Figure 3-3). The configuration enables overlapping IP addresses between the protected networks. Chapter 3 Deploying VSX 57

58 Deploying VSX - an Internal View Internal Virtual Router with Shared Interface This configuration enables the connection of Virtual Systems to the protected networks using one physical interface, without using VLAN technology. The Virtual Router uses Advanced Source-Based Routing rules to forward traffic to the relevant Virtual System based on source IP address. Advanced Routing is useful in cases where a single physical interface without VLAN tagging is used to connect to protected networks. These advanced routing rules take precedence over ordinary routing decisions. Advanced routing enables routing according to source IP address or a combination of source IP address and destination IP address. Figure 3-5 shows a VSX configuration with each Virtual System connected (in addition the external Virtual Switch) to a single Virtual Router. The Virtual Router uses Advanced Source-Based Routing rules to forward traffic to the relevant Virtual System based on source IP address. 58

59 Deploying VSX - an Internal View Figure 3-5 Basic VSX using an IVR For this deployment note that: Each Virtual System has a public IP address connecting it to the External Virtual Switch. This address is also used for connecting the Virtual System to the Virtual Router. Each local network that is connected to the Virtual Router also has private IP addresses. It is also possible to use public IP addresses for these Virtual Router connections. A deployment of this type does not support overlapping IP addresses. Chapter 3 Deploying VSX 59

60 Deploying VSX - an Internal View Anti-spoofing is not effective for packets originating from the shared internal interface. Since there is no physical/logical separation of customer traffic that enables a one-to-one mapping between an interface/vlan tag and a customer Virtual System, it is not possible to employ Anti-Spoofing. For more information on advanced (source-based) routing see: Advanced Routing Scenarios on page 125. Security for Virtual Systems in Bridge Mode A Virtual System in Bridge Mode performs the same functions as a Virtual Switch while supplying extra layers of security, as shown in Figure 3-6: Figure 3-6 Virtual System in bridge mode In Figure 3-6, each Virtual System in Bridge Mode provides content inspection for each VLAN switched network without breaking the existing IP infrastructure. Thus VS 1 Bridged protects VLAN 100, VS 2 Bridged protects VLAN 101, and VS 3 Bridged protects VLAN

61 Deploying VSX - an External View Deploying VSX - an External View On the Enterprise, VSX provides security both internally and at the perimeter. For Service Providers: scalability, flexibility, hardware consolidation, and secure connectivity for a range of hosting services. In some deployments VSX provides a security envelope; in others VSX introduces a shim layer for new applications and services. In terms of security, a VSX deployment must not only implement security services for the enterprise infrastructure, but also adapt to the existing structures in the core without affecting core traffic flow. Core Side Security To provide a security layer for existing core networks, VSX offers Virtual Systems in bridge mode. Such Virtual Systems, operating at layer-2, are completely transparent and do not break the existing IP structure, the different control protocols in use for VLAN management, or the protocols used for loop detection. Assigning a Virtual System in bridge mode to the different networks establishes security control points for the different segments. Consider three common deployments: An Enterprise deployment A Service Provider deployment A Data Center deployment Enterprise A VSX deployment in the Enterprise offers both internal security, and security at the perimeter. Internal Security Situated next to the core switches, VSX secures the internal network, adding a security layer at either level-2 or level-3 or both, as shown in Figure 3-7. Chapter 3 Deploying VSX 61

62 Deploying VSX - an External View Figure 3-7 Enterprise deployment In Figure 3-7, the Enterprise is composed of different types of networks with different security and access requirements for each department. VSX communicates with the routed core network using the existing infrastructure language, whichever dynamic and multicast protocols are active. Virtual Systems in bridge mode provide layer-2 security for the various departmental networks, at the same time preventing network segmentation. Finance, Desktops, and R&D networks effectively terminate at the core. Layer-2 access switches are located at the entrance to each department s network. VSX provides connectivity between the core and the endpoint networks, placing the endpoint networks within a security envelope. Security is established per VLAN. Nothing changes in the layer-2 or layer-3 network structure except the addition of this security layer for different VLANs. By controlling traffic into and out of the core, VSX effectively secures the departmental VLANs. In addition, for Virtual Systems in bridge mode, VSX interoperates seamlessly with STP and its variants. VSX does not disrupt layer-2 protocols such as VTP. This interoperability with layer-2 protocols enables load sharing and failovers between the members of the VSX cluster. Figure 3-8 shows an enterprise network with the emphasis on dynamic routing protocols: 62

63 Deploying VSX - an External View Figure 3-8 Dynamic routing on the enterprise In Figure 3-8, BGP neighbor updates in the routed core network are selectively redistributed to application networks. OSPF provides connectivity between Virtual Routers, Virtual systems, the routed core and application networks. Security at the Perimeter In Figure 3-9, security is enforced per VLAN. Dynamic routing protocols OSPF and BGP provide connectivity to multiple security zones along the Perimeter. Chapter 3 Deploying VSX 63

64 Deploying VSX - an External View Figure 3-9 Enterprise deployment In Figure 3-9: Each partner has access to the Enterprise through a dedicated Virtual System. Each partner has a private security policy based on need. Logs and audit information for each partner is collected separately, and saved to a private database. Applications and services are segregated by private Virtual Systems. Multiple Virtual Routers/Switches are used to control the access paths. At the perimeter, VSX secures each DMZ service, VPN peer, customer and partner while providing complete integration with dynamic routing protocols (OSPF/BGP). 64

65 Deploying VSX - an External View Service Providers In Figure 3-10, a Service Provider supplies connectivity and security services to its customers, some of which have users that require remote access. In this service oriented environment, VSX facilitates both connectivity and security without breaking the existing IP design of the - for example - MPLS network. (The MPLS network provides a private WAN across a single core IP network. While VSX does not support MPLS, it does seamlessly integrate into an MPLS environment. By configuring MPLS routers to map MPLS labels to VLAN tags, all tagged traffic is directed via the VSX gateway to appropriate Virtual Systems. Effectively, a VSX security policy is enforced on MPLS labeled packets.) Figure 3-10 Service Provider deployment The VSX cluster resides in a Point of Presence (POP) deployment of a Service Provider. The POP is monitored from the Service Provider s Network Operation s Center (NOC) in a High Availability configuration. Chapter 3 Deploying VSX 65

66 Deploying VSX - an External View Each customer receives a private security policy, and secure VPN connectivity. Provider-1/SiteManager-1 supplies a centralized and granular provisioning system. Each customer s forensic information is collected separately, and logged to a private database on the multi-domain logging module (MLM). Applications and services are segregated by discrete Virtual Systems. Access to these services and applications is based on need. Multiple Virtual Routers/Switches are used to control the access paths. In Figure 3-10, VSX consolidates hardware for the service provider while ensuring privacy and secure connectivity solutions (VPN) for the service provider s customers. To deploy a new security policy, the Service Provider updates the VSX gateway. Data Centers Consider the scenario of a Service Provider supplying infrastructure, connectivity, and security for three customers to the Datacenter shown in Figure 3-11: In Figure 3-11, the MPLS backbone of a Managed Service Provider maintains three separate networks over the same physical infrastructure, ensuring connectivity between these distinct customers and the data center. (The backbone does not have to be MPLS. The backbone could equally be Frame Relay or ATM.) Customer A has connectivity with its web hosting servers and extranet, Customer B with its mail servers, and Customer C with its database deployment. To enhance security and reduce the amount of hardware required, the Service Provider introduces a VSX gateway, as shown in Figure 3-11: 66

67 Deploying VSX - an External View Figure 3-11 VSX protects a datacenter In Figure 3-11, a 802.1q VLAN connects a VSX gateway to the MPLS backbone. Traffic between the data center and Customers A, B, and C is via the VSX gateway. Each customer is associated with a distinct Virtual System. The advantage is scalability. If a remote site needs to be connected to the larger network, MPLS does not provide a cost effective solution. But a VPN connection between the relevant Virtual System and the VPN-1 UTM Edge box (shown in Figure 3-11) guarding the remote site integrates the remote site into the MPLS core. In the same way, the presence of a VSX gateway provides access for intermittent remote users. Chapter 3 Deploying VSX 67

68 Deploying VSX - an External View Data Centers Within the Enterprise By assigning layer-2 connections to Virtual Systems, VSX reduces the number of physically managed devices within the data center while providing the same level of security. In Figure 3-12, the VSX gateway provides users with protected access to the resources of the data center. The objective is to protect network applications (shared resources with differing access permissions) while increasing the modularity of the network. Figure 3-12 Data centers within the enterprise For example, a Virtual System is created to protect the databases against SQL exploits and vulnerabilities. Another Virtual System is created to protect the Web Servers against known vulnerabilities, the appropriate protections in SmartDefense being enabled. When new applications and services are added to the enterprise data center, new Virtual Systems are easily created to secure them. In this way, the Virtual System provides a shim layer into which new applications and services can be plugged. 68

69 Chapter 4 Installing and Configuring VSX In This Chapter Overview page 70 Installation Steps page 71 VSX Management Installation page 72 VSX Management Clients page 73 Licensing page 74 VSX Gateway/Cluster Configuration Using Provider-1 page 79 69

70 Overview Overview This chapter describes how to install and configure a VSX gateway/cluster, and create Virtual Systems and Security Policies. The chapter also contains the licensing requirements for using a VSX gateway/cluster. 70

71 Installation Steps Installation Steps The following steps describe the procedures you should follow to install and configure the VSX deployment according to the dedicated management model. Step 1 Determine which management model you are using. If you are using SmartCenter proceed to step 4; otherwise continue with the next step to install Provider-1. Step 2 Install Provider-1 Multi Domain Server (MDS) on the MDS machine. Install Provider-1 Multi Domain Server on the machine that will be used to manage the VSX gateway/cluster. For more information about Provider-1, refer to the Check Point Provider-1/SiteManager-1 Guide Step 3 Install Provider-1 Multi Domain GUI on the client machine. Install Provider-1 Multi Domain GUI on the client machine that will be used as the management workstation. For more information about Provider-1 refer to the Check Point Provider-1/SiteManager-1 Guide. Proceed to step 6. Step 4 Install SmartCenter on the SmartCenter server. Install SmartCenter software on the SmartCenter server. For more information about SmartCenter, refer to the SmartCenter Guide. Step 5 Install SmartDashboard on the client machine. Install SmartDashboard on the client machine that will be used as the management work station for the VSX gateway/cluster. For more information on SmartDashboard, refer to the SmartCenter Guide. Step 6 Configure the VSX gateway/cluster. Configure the VSX gateway/cluster using Provider-1 or SmartDashboard from the management station. These steps are described in detail in Using the VSX Wizard to Create a VSX Gateway on page 81. And: Using the VSX Wizard to Create a VSX Cluster on page 87. Chapter 4 Installing and Configuring VSX 71

72 VSX Management Installation VSX Management Installation A VSX gateway/cluster is managed using either SmartCenter server or Provider-1. Choice of management depends on the deployment size, administration requirements, existing Check Point product deployments, and licensing restrictions. In accordance with the Check Point EULA (End User License Agreement), a SmartCenter server can only be used to manage the security policy/policies of VPN-1 gateways and/or Virtual Systems that belong to a single legal entity. In order to manage VPN-1 gateways and/or Virtual Systems that belong to multiple legal entities, you need to have a separate SmartCenter per legal entity, or deploy a Provider-1 management solution with a separate CMA per legal entity. For more information regarding Licensing, refer to your Check Point Reseller. Table 4-1 lists the two management models and refers you to the respective documentation to which you should refer for full installation and configuration procedures. Table 4-1 VSX Management Documentation References Management Model SmartCenter Provider-1 Refer to... This Guide SmartCenter Guide Provider-1/SiteManager-1 Guide 72

73 VSX Management Clients VSX Management Clients VSX Management Clients provides a Graphical User Interface to the management server: either SmartCenter or Provider-1. For both management models you must install SmartDashboard on the client machine. If you have chosen Provider-1 as the preferred management tool, install the Multi Domain GUI as well. Chapter 4 Installing and Configuring VSX 73

74 Licensing Licensing Obtaining Licenses All Check Point software is activated by the installation of a license. Licenses are not required for SmartDashboard. Permanent licenses can be obtained from the Check Point User Center: after the Check Point software has been purchased. Licenses can be stored and maintained in the SmartUpdate repository, from which Check Point software can be upgraded. Evaluation Period Check Point software that has not yet been purchased works for a period of fifteen days. You are required to go through the User Center to register this software. During this fifteen day period the software is fully functional. An evaluation period begins: For a gateway when trust is established with the management server For a SmartCenter server when a Certificate Authority (CA) is initialized. Understanding License Details When you create a license in the Check Point User Center, the license will include: The IP address of the machine for which the license is intended. Certificate Key - a string of 12 alphanumeric characters. The string is unique to each product. The expiration date of the license. SKU/Features - the character string that defines an individual product. The license can be installed using the Check Point Configuration Tool. The validation code supplied by the Check Point User center should be compared with the validation code displayed by the Check Point Configuration Tool. These strings should be identical. 74

75 VSX Provider-1 Bundle License VSX Provider-1 Bundle License The VSX Bundle License provides licensing for managing Virtual Systems and CMAs located on an MDS server. The bundle license is installed on the MDS server and permits a specific number of Virtual Systems to be managed. The number of CMAs that can be defined on an MDS equals the number of Virtual Systems permitted plus one. The additional CMA is used for managing the VSX gateway/cluster. The VSX bundle license does not limit the number of VSX gateway/clusters or the number of Virtual Routers and switches. CMAs without a CMA-level license use the bundle license. If a CMA-level license is installed on a specific CMA to allow the management of a regular gateway, (CPPR-CMA-10-NGX, for example), then that CMA stops using the bundle license, and the Virtual Systems located on it are not discounted from the bundle license. When a CMA is managing a non-vsx gateway, both a CMA-level license and container license on the MDS is required. VSX Bundle License for HA CMAs The VSX HA CMA Bundle License is used for HA CMAs on a primary or backup MDS for High Availability. CPPR-VSX-CMA-HA-10-NGX, for example, enables defining 10 Virtual Systems on HA CMAs. HA CMAs can use the regular bundle, but Primary CMAs cannot use the HA bundle. Table 4-2 VSX Bundle License Schemes License CPPR-VSX-CMA-10-NGX CPPR-VSX-CMA-25-NGX CPPR-VSX-CMA-50-NGX CPPR-VSX-CMA-100-NGX CPPR-VSX-CMA-250-NGX CPPR-VSX-CMA-HA-10-NGX CPPR-VSX-CMA-HA-25-NGX Description MDS hosting up to 10 CMAs plus one for the CMA with the VSX MDS hosting up to 25 CMAs plus one for the CMA with the VSX MDS hosting up to 50 CMAs plus one for the CMA with the VSX MDS hosting up to 100 CMAs plus one for the CMA with the VSX MDS hosting up to 250 CMAs plus one for the CMA with the VSX Mirror MDS hosting up to 10 CMAs plus one for the CMA with the VSX Mirror MDS hosting up to 25 CMAs plus one for the CMA with the VSX Chapter 4 Installing and Configuring VSX 75

76 VSX Provider-1 Bundle License Table 4-2 VSX Bundle License Schemes License CPPR-VSX-CMA-HA-50-NGX CPPR-VSX-CMA-HA-100-NGX CPPR-VSX-CMA-HA-250-NGX Description Mirror MDS hosting up to 50 CMAs plus one for the CMA with the VSX Mirror MDS hosting up to 100 CMAs plus one for the CMA with the VSX Mirror MDS hosting up to 250 CMAs plus one for the CMA with the VSX Table 4-3 VSX-CMA Bundle License Schemes License CPPR-VSX-CMA-C10-NGX CPPR-VSX-CMA-C25-NGX CPPR-VSX-CMA-C50-NGX CPPR-VSX-CMA-C100-NGX CPPR-VSX-CMA-C250-NGX CPPR-VSX-CMA-HA-C10-NGX CPPR-VSX-CMA-HA-C25-NGX CPPR-VSX-CMA-HA-C50-NGX CPPR-VSX-CMA-HA-C100-NGX CPPR-VSX-CMA-HA-C250-NGX Description MDS bundle license for 10 Virtual Systems and 11 CMAs MDS bundle license for 25 Virtual Systems and 26 CMAs MDS bundle license for 50 Virtual Systems and 51 CMAs MDS bundle license for 100 Virtual Systems and 101 CMAs MDS bundle license for 250 Virtual Systems and 251 CMAs MDS bundle license for 10 Virtual Systems located on Secondary CMAs and 11 secondary CMAs MDS bundle license for 25 Virtual Systems located on Secondary CMAs and 26 secondary CMAs MDS bundle license for 50 Virtual Systems located on Secondary CMAs and 51 secondary CMAs MDS bundle license for 100 Virtual Systems located on Secondary CMAs and 101 secondary CMAs MDS bundle license for 250 Virtual Systems located on Secondary CMAs and 251 secondary CMAs 76

77 Installing the VSX Bundle License License Violations Installing the VSX Bundle license is similar to installing any other MDS level license. The installation can take place on the MDG from the MDS properties view or from the command line in the MDS using the cplic put command. License Violations When a license violation is detected: Syslog messages are sent Pop-up alerts appear in the MDG. (An indication regarding the nature of the license violation also appears on the MDG status bar) Audit entries are generated in SmartView Tracker stating the nature of the violation While a MDS is in violation, new CMAs, VSX gateways/clusters, or Virtual Devices cannot be added. Replacing the Trial Period License After the trial period expires, a permanent license must be installed. Before installing a new license, make sure the number of CMAs and Virtual Systems do not exceed the number permitted by the new license. Installing a license that permits less CMAs or Virtual Systems than were configured during the trial period is a violation. As a result, the MDS will not start. During the trial license period, up to 200 CMAs and up to five Virtual Systems per CMA can be configured. In order to configure more than five Virtual Systems per CMA, a bundle license or CMA-level license needs to be installed. To successfully install a bundle license before the trial license expires, the trial license must be disabled from the CMA. The command for disabling the trial period license on a CMA before the license expires is: cpprod_util CPPROD_SetPnPDisable 1 Chapter 4 Installing and Configuring VSX 77

78 Replacing the Trial Period License This command needs to be executed on each CMA separately and will only take effect after restarting the CMA. The license violation mechanism is enforced separately for each MDS. If one MDS is in license violation, the other MDSs continue to function. For more information on Licensing, see the Licensing and Deployment section in the Provider-1/SiteManager-1 User Guide. 78

79 VSX Gateway/Cluster Configuration Using Provider-1 VSX Gateway/Cluster Configuration Using Provider-1 In This Section Adding a CMA to Accommodate a VSX Gateway/Cluster page 79 Configuring a VSX Gateway page 80 Configuring a VSX Cluster page 86 Dedicated Management Interface (DMI) page 91 This section describes how to configure the VSX gateway/cluster using the VSX wizard. If you are using SmartCenter for management, skip the next section and continue with Configuring a VSX Gateway on page 80. If you are using Provider-1, you must first add a new customer as a Customer Management Add-on (CMA) that will accommodate the VSX gateway/cluster. The New Customer wizard enables you to define the CMA, its location details, the administrators who can access the CMA and the GUI clients who will use the VSX gateway/cluster. For more information on CMAs refer to the Check Point Provider-1/SiteManager-1 Guide. After creating the CMA you can configure the VSX gateway/cluster using the VSX wizard. Adding a CMA to Accommodate a VSX Gateway/Cluster Provider-1 requires that the VSX gateway/cluster be accommodated by a CMA. This CMA comprises the VSX gateway/cluster, and optional Virtual Routers and Virtual Switches that are created for it. After this procedure, Virtual Devices can be added to the CMA. Additional CMAs can be added for each customer. These CMAs will accommodate the Virtual Devices configured in VSX. These procedures are more fully described in Adding New Customers on page 97 in Chapter 5. Note - You must be logged on as a user with permissions to add CMAs to perform this procedure. Chapter 4 Installing and Configuring VSX 79

80 Configuring a VSX Gateway Using Provider-1 to Define the CMA 1. On the client machine of the MDG use the Customer Add-on Wizard to define a CMA. 2. Set the Company Assigned Administrators and Customer Assigned GUI Clients. 3. In the First Customer Management Add-on window, enter the details of the Multi-Domain Server that will manage the VSX gateway. The CMA is added to the objects tree. Configuring a VSX Gateway This section describes how to create a new VSX gateway using the VSX Wizard. The VSX Wizard is accessible from SmartDashboard. If you are creating a VSX cluster you can skip this section and go to Configuring a VSX Cluster on page 86. Figure 4-1 illustrates a typical VSX gateway configuration. The VSX gateway Creation Wizard guides you through the steps required to configure a VSX gateway. After completing the VSX gateway Creation Wizard, the configuration of the VSX gateway can be further edited. For example, interfaces can be added or removed, or existing interfaces configured to allow 802.1q VLAN. 80

81 Configuring a VSX Gateway Figure 4-1 Example of VSX gateway configuration In this VSX gateway example the interfaces are allocated as follows: eth0 is the dedicated management interface eth1 leads to the Internet and is connected to a Virtual Switch eth2 will be used as VLAN trunk interface leading to internal networks Using the VSX Wizard to Create a VSX Gateway 1. Open the SmartDashboard of the CMA on which you intend to configure the VSX cluster. 2. In the Network Objects tab of the Objects Tree, select Check Point > New Check Point > VPN-1 Power VSX > Gateway. The VPN-1 Power VSX Gateway wizard is displayed. 3. Enter the gateway s name, IP address, and version: Chapter 4 Installing and Configuring VSX 81

82 Configuring a VSX Gateway Figure 4-2 First page of the VSX gateway wizard 4. Click Next. Select one of the creation templates for Virtual Systems, or choose a custom Virtual System if the templates (for shared and separate interfaces) do not meet your needs. At this point, whether an interface is dedicated to management is also determined. See Dedicated Management Interface (DMI) on page 91. Figure 4-3 Second page of the VSX creation wizard 5. Click Next. The VSX gateway s general properties page appears. 82

83 Configuring a VSX Gateway Figure 4-4 Third page of VSX gateway wizard 6. In the Activation Key area, enter the Activation Key that you created when you installed the VSX gateway. Re-enter the activation key in the Confirm Activation Key field and click Initialize. If you entered the correct activation key, the Trust State field changes to Trust established. If the trust failed, click Check SIC Status to determine the reason for the failure and that your management server (MDS or SmartCenter) has connectivity with the VSX gateway/cluster members. You can reset the SIC connection by clicking Reset. For more information on Secure Internal Communication, refer to the SmartCenter Guide. 7. Click Next. The Physical Interfaces window is displayed. Select which physical interfaces will be used as 802.1q VLAN trunks. Figure 4-5 Fourth page of VSX gateway creation wizard Chapter 4 Installing and Configuring VSX 83

84 Configuring a VSX Gateway 8. Click Next. The External Communication window opens: Select an interface that will be used by all Virtual Systems for external communication. 9. Click Next. The management access page opens: Figure 4-6 Fifth page of the VSX gateway creation wizard 10. Select those services which will be accessible on the VSX gateway. 11. Click Next and Finish to complete the VSX creation process and add the newly defined VSX gateway to the objects database. Note - This process may take a minute or more to complete. A message is displayed indicating the successful configuration of the VSX gateway. If you do not get a message that the VSX gateway was properly configured, refer to Chapter 10, VSX Diagnostics and Troubleshooting. 84

85 Editing the Configuration of a VSX Gateway Configuring a VSX Gateway 1. In the network objects tree of SmartDashboard, double-click on the VSX gateway you want to edit. The Check Point VSX Gateway window is displayed. 2. Use this page to configure all aspects of the VSX gateway. Chapter 4 Installing and Configuring VSX 85

86 Configuring a VSX Cluster Configuring a VSX Cluster This section illustrates how to create a new VSX cluster of the type shown in Figure 4-7. A VSX Cluster Wizard guides you through the configuration steps. After completing the Wizard the configuration of the VSX cluster can be edited further. For example interfaces can be added or removed, or existing interfaces configured to allow or disallow 802.1q VLAN. Figure 4-7 Example of VSX cluster configuration In this VSX cluster example, VSXA and VSXB are the cluster members and the interfaces are allocated as follows: eth0 is the dedicated management interface for both cluster members 86

87 Using the VSX Wizard to Create a VSX Cluster eth1 is outward facing towards the Internet and is connected to a Virtual Switch eth2 serves as sync interface eth3 is used as an interface on which VLANs are defined for all cluster members Note - Each interface must have the same role on all cluster members. For example, if eth1 is facing the Internet on the first cluster member, then eth1 on the other cluster members must also face the Internet. Using the VSX Wizard to Create a VSX Cluster Before you create the VSX cluster: If you are using Provider-1 as your management, open SmartDashboard of the CMA on which you intend to configure the VSX cluster. If you intend to build the VSX cluster from existing VSX gateways, you must delete the Virtual Systems on those VSX gateways first. To create a VSX cluster: 1. In the Network Objects tab of SmartDashboard, select New Check Point > VSX > Cluster. The VSX Cluster wizard is displayed. Figure 4-8 First page of VSX cluster wizard Provide a name and IP address for the VSX cluster From the drop-down boxes select the VSX cluster version and type. Click Next. The Virtual System creation template page opens: Chapter 4 Installing and Configuring VSX 87

88 Using the VSX Wizard to Create a VSX Cluster Figure 4-9 Second page of the VSX cluster wizard Select one of the two creation templates for Virtual Systems, or choose a custom configuration for the cluster if one of the templates does not meet your needs. At this point, whether an interface is dedicated to management is also determined. See Dedicated Management Interface (DMI) on page Click Next, the Define Cluster Members page appears: Figure 4-10 Third page of the VSX Cluster Wizard 3. Add at least two cluster members, and establish trust with each cluster member before moving onto the next page in the wizard. Note - A VSX cluster supports up to eight members. 88

89 Using the VSX Wizard to Create a VSX Cluster Figure 4-11 Establishing trust with cluster members: 4. If trust fails, click Check SIC status to determine the reason for the failure. Ensure that your management server (MDS or SmartCenter) has connectivity with the VSX cluster members. You can reset the SIC connection by pressing the Reset button. For more information on Secure Internal Communication, refer to the chapter one of the SmartCenter Guide, the The SIC Solution section. Figure 4-12 Fifth page of the VSX cluster wizard 5. In this window select which physical interfaces will be used as 802.1q VLAN trunks. Click Next. The synchronization network page opens: Chapter 4 Installing and Configuring VSX 89

90 Using the VSX Wizard to Create a VSX Cluster Figure 4-13 Sixth page of the VSX cluster wizard 6. Select the interface that will be used for state synchronization, and enter the IP address and network mask for the selected synchronization interface on each cluster member. Click Next. The Management Access Rules page opens: Figure 4-14 Seventh page of the VSX cluster wizard 7. Select those services for which will be accessible on the VSX cluster. Click Next then Finish to complete the wizard. 90

91 Removing a VSX Gateway/Cluster Removing a VSX Gateway/Cluster To remove a VSX gateway/cluster, delete the object in SmartDashboard. Deleting the VSX object from SmartDashboard removes the VSX object and its related Virtual Systems from the SmartCenter management only. Virtual Systems are not deleted from the VSX gateway/cluster. On the SecurePlatform VPN-1 Power VSX gateway, remove Virtual Systems with the command: fw vsx deletevs [-v q] {vsname vsid} Dedicated Management Interface (DMI) A VSX deployment can be managed: With an interface dedicated to management Without an interface dedicated to management The decision whether to use a dedicated management interface (or not) is made when you select a Virtual System Creation template for the VSX gateway/cluster. (See Second page of the VSX cluster wizard on page 88.) Virtual Systems based on the separate interface template are always in DMI mode. Virtual Systems based on the Customized or Shared interface template can be managed through either a dedicated or non-dedicated interface. If the Shared Interface template is chosen, and the management interface is selected as the interface for external communication, as shown in Figure 4-15, then the VSX assumes a non-dmi mode. Figure 4-15 External communication Chapter 4 Installing and Configuring VSX 91

92 Dedicated Management Interface (DMI) In this case, to enable external communication, the management interface leads to a Virtual Switch or Router. If the Custom Interface template is chosen, and the management interface is selected as the shared physical interface on the Virtual Network Device Configuration page, as show in Figure 4-16, then the Virtual System again assumes a Non-DMI mode. Figure 4-16 Virtual Network configuration page 92

93 Chapter 5 Using VSX In This Chapter Overview page 94 Using Provider-1 to Manage VSX page 97 Using SmartCenter to Manage VSX page 104 Managing Security and VPN Policies Using SmartDashboard page 133 Source-Based Routing page 134 Configuring Unnumbered Interfaces page 137 Anti-Spoofing on VSX Interfaces page

94 Overview Overview This chapter describes how to configure and work with a VSX gateway/cluster, using Provider-1 or SmartCenter. Prior to conducting any of the procedures described in this Chapter you must make sure that both the VSX gateway/cluster and Provider-1 MDS and/or SmartCenter server are up and running and that you have Provider-1 MDG and/or SmartDashboard installed on the client machine. During the course of this chapter you will be shown how to: Add/edit customers (Provider-1 only) Define and edit Virtual Systems and other Virtual Devices Obtain status information about the VSX deployment The procedures for defining and installing security policies on a VSX gateway/cluster are the same as for a physical VPN-1 gateway. For more information on defining and installing security policies refer to the SmartCenter Guide. Figure 5-1 is an example of a VSX gateway that has Virtual Systems and a Virtual Switch configured. The example also shows the VSX gateway with a dedicated interface for management. 94

95 Overview Figure 5-1 Example of VSX deployment In Figure 5-1, VS1, VS2, and VS3 are distinct virtual systems guarding separate networks. Figure 5-2 shows a VSX cluster deployment with multiple Virtual Systems, a Virtual Switch, and the VSX gateway configured for dedicated management. Chapter 5 Using VSX 95

96 Overview Figure 5-2 Example of VSX cluster configuration (uses sample IP addresses) 96

97 Using Provider-1 to Manage VSX Using Provider-1 to Manage VSX Provider-1 is one of the management models that you can use to manage a VSX deployment. Provider-1 is designed to meet the challenges of service providers and large enterprises who manage multiple VPN-1 gateways or Virtual Systems. If you are not using Provider-1 as your management model, you can skip this section and continue with the section Using SmartCenter to Manage VSX on page 104. In This Section Adding New Customers page 97 Editing Customers page 101 Adding/Editing Virtual Systems in Provider-1 page 102 Obtaining Status Information page 102 Adding New Customers This section describes how to add Customers using Provider-1. A Customer is a legal entity whose VPN-1 gateways and Virtual Systems are managed through a Provider-1 management entity known as a Customer Management Add-on (CMA). For more information on CMAs, refer to the Provider-1/SiteManager-1 Guide. Each CMA contains all the Customers Virtual Systems as well as any physical VPN-1 gateways that the Customer may have. For example, Customer A has two branches, Branch A and Branch B, each of which will have their own networks managed on a VSX machine, and Branch C which has its network managed by a physical gateway. Using Provider-1, you define a CMA for Customer A and then define Virtual Systems for Branch A and Branch B. You also define the gateway for Branch C in this CMA. Having defined a CMA, the section Adding/Editing Virtual Systems in Provider-1 on page 102, describes how to define Virtual Systems for a CMA. Throughout this chapter, the configuration sections can be used as a tutorial in which you can follow the configurable items shown in parentheses to complete the entire configuration. Chapter 5 Using VSX 97

98 Adding New Customers To Add a New Customer (CMA) 1. On the client machine, select Start > Programs > Check Point SmartConsole NGX (R62) > Provider-1 NGX (R62). The Check Point Provider-1/SiteManager-1 Login window is displayed. 2. Login using your User Name and Password. The Check Point Provider-1/SiteManager-1 Main window is displayed. 3. In the Customer Contents area, right-click on Provider-1/SiteManager-1 and select New Customer. The Add Customer wizard is displayed. Note - You can also start the Add Customer wizard by selecting New Customer from the Manage menu. 4. Enter a Customer Name (AnyCompany). 5. Click Next. The Customer Properties window is displayed. Enter Customer Properties: Location, Contact Person, Address. 6. Click Next. The Customer Assigned Administrators window is displayed. The left column lists the unassigned administrators while the right column lists those administrators who are already assigned. By default Provider-1 superusers are assigned administrators who can directly manage customers. To assign an administrator, select the name in the Not Assigned column and click Add. The administrator s name is moved to the Assigned column. You can remove any assigned administrator, who is not a superuser, by selecting their name in the Assigned column and clicking Remove. You can also add new administrators to the Not Assigned column by clicking the New Admin... button. You can also assign/unassign administrators by group by clicking the Select by Group... button. All the administrators in the selected group are automatically selected and you can either assign or unassign the entire group. For more information on assigning/unassigning or adding new administrators, refer to the Check Point Provider-1/SiteManager-1 Guide. Figure 5-3 is an example of the Customer Assigned Administrators window. 98

99 Adding New Customers Figure 5-3 Customer Assignment Administrators window 7. Click Next. The Customer Assigned GUI Clients window is displayed. The Customer Assigned GUI Clients window enables you to assign GUI clients to the customer. A GUI client specifies which machines can connect using SmartConsole to the Customer s CMAs. The left column lists the unassigned GUI Clients while the right column lists those GUI Clients who are already assigned. To assign a GUI Client, select the name in the Not Assigned column and click Add. The GUI Client s name is moved to the Assigned column. You can remove any assigned GUI Client by selecting their name in the Assigned column and clicking Remove. You can also add new GUI Clients to the Not Assigned column by clicking the New GUI Client... button. For more information on assigning/unassigning or adding new GUI Clients refer to the Check Point Provider-1/SiteManager-1 Guide. Figure 5-4 is an example of the Customer Assigned GUI Clients window. Chapter 5 Using VSX 99

100 Adding New Customers Figure 5-4 Customer Assigned GUI Clients window 8. Click Next. The Customer Management Add-ons window is displayed in which you must indicate if you want to add new Customer Add-ons now (one or two) or if you want to add them later. If you elect to add the new Customer Add-ons now, the Customer Add-on wizard starts and you should follow the steps described in this section. 9. Click Next. The First Customer Management Add-on window is displayed. Enter the details of the Customer Management Add-on that will manage the VSX gateway/cluster deployment as well as the respective license information for the system. Specify: The name of the Customer Management Add-on The MDS on which this CMA will reside The IP address of the CMA 10. Enter a license for the deployment, either manually by clicking Add, and entering each license or by clicking Fetch From File... to retrieve the details from a stored file. Figure 5-5 is an example of the First Customer Management Add-on window. 100

101 Editing Customers Figure 5-5 First Customer Management Add-on window 11. Click Next. The Customer Completed Definition window is displayed. 12. Click Finish to complete the wizard. The Customer (including the CMA) is added to the Objects Tree. Editing Customers You can edit the properties of any of the Customers that you have defined. To Edit a Customer 1. In Provider-1, in the Customer Contents tree, right-click on the Customer you want to edit and select Configure Customer or double-click on the Customer you want to edit. The Customer Configuration window is displayed. Figure 5-6 Customer Configuration window Chapter 5 Using VSX 101

102 Adding/Editing Virtual Systems in Provider-1 2. Select the tab you want to edit and follow the procedures described in To Add a New Customer (CMA) on page 98 to edit the selected tab. Click OK to save any changes to the selected tab. Note - You cannot edit the Customer Name. 3. Click OK to save your changes. Adding/Editing Virtual Systems in Provider-1 Virtual Systems are added to Provider-1 via the SmartDashboard of a specific CMA. Provider-1 NGX treats Virtual Devices the same as any other physical device. You can add as many Virtual Systems to existing CMAs as your licensing agreement permits. Virtual Systems that are added to a CMA do not have to reside on the same VSX machine. For more information on CMAs, refer to the Provider-1/SiteManager-1 Guide. To Add a Virtual System to a CMA 1. Launch SmartDashboard from the relevant CMA. 2. Create the Virtual System as described in Adding/Editing Virtual Systems on page 105. Obtaining Status Information Provider-1 MDG provides a Network Objects View that enables the monitoring of all gateways and Virtual Systems/Routers. The Network Objects View displays a snapshot of all Check Point products, such as the VSX gateway/cluster, VPN-1, QoS, and ClusterXL. For more information on using MDG and the Network Object View refer to the Provider-1/SiteManager-1 Guide. Where a VSX gateway/cluster is concerned, the Network Object View is a tabular view that lists all Virtual Devices, their IPs, Multi-Domain Servers and the VSX gateways on which they reside. For each VSX gateway/cluster the VSX gateway object provides status information. To get status information: 1. In the General network objects view, right click the relevant object 102

103 Obtaining Status Information 2. Click Get Status Details Click Get Status... The status information includes OS level information as well as CPU, Memory, and Disk Usage. Since the Status View shows each Virtual System as an independent gateway to which it tries to connect and validate, it may well be that on a certain VSX gateway/cluster, a Virtual System is down. Other Virtual Systems on that VSX machine could all be functioning normally. Figure 5-7 shows an example of the Network Objects view: Figure 5-7 General - Network Objects window Obtaining Additional Status Information from Gateways For SNMP users, additional status information can be obtained from gateways by taking advantage of VSX monitoring classes in the Check Point MIB. For more information see the guide to the Check Point MIB at: Chapter 5 Using VSX 103

104 Using SmartCenter to Manage VSX Using SmartCenter to Manage VSX In This Section. Adding/Editing Virtual Systems page 105 Authentication Options for Virtual Systems page 113 Adding New Members to a Cluster page 117 Removing Members From a Cluster page 118 Upgrading Cluster Members to VPN-1 Power VSX page 119 VSX Gateway Recovery page 122 Network Address Translation in VSX page 123 Advanced Routing Scenarios page 125 Obtaining Status Information page 131 In addition to Provider-1, SmartCenter can also be used to manage a VSX deployment of up to 25 Virtual Systems. While 25 Virtual System is the recommended number, more than 25 Virtual Systems can be created if the need arises. In this section you can follow the step-by-step procedure for adding Virtual Systems and other Virtual Devices to a VSX gateway/cluster using the SmartCenter server. Although configured on the same gateway, Virtual Systems separately enforce each customer s Security Policy only on the packet traffic associated with the network they are protecting. A Virtual Router/Switch in the VSX gateway/cluster is the same as an external Router/Switch in a physical configuration and a Virtual System in the VSX gateway/cluster is the same as a VPN-1 gateway in a physical system. 104

105 Adding/Editing Virtual Systems Adding/Editing Virtual Systems This section describes how to add Virtual Systems to a VSX gateway/cluster deployment. A Virtual System in the VSX gateway/cluster is similar to a VPN-1 gateway in a physical system. The type of Virtual System that can be added or edited at this point is determined by which Virtual System creation template you chose when creating the VSX gateway/cluster. See: Using the VSX Wizard to Create a VSX Cluster on page 87. The most common scenario is to create a Virtual System with two interfaces: one leading to the Internet, the other leading to a customer network via a VLAN. If the custom Virtual System template was selected, as many interfaces as necessary can be added. Figure 5-8 shows an example of a VSX gateway deployment with three Virtual Systems, each with two interfaces. Figure 5-8 Example of VSX gateway configuration Chapter 5 Using VSX 105

106 Adding/Editing Virtual Systems Adding a Virtual System 1. In SmartDashboard, select Network Objects > New > Check Point > VPN-1 Power VSX > Virtual System. The Virtual System Wizard opens. 2. Supply a name for the new Virtual System, and select from the drop-down box the VSX gateway to which the new Virtual System belongs. In addition, select whether the Virtual System will run in Bridge mode, as shown in Figure 5-9: Figure 5-9 Virtual System wizard opening page 3. Click Next. The interface configuration screen that appears next depends on: The Virtual System Template you selected when creating the VSX gateway (see: Using the VSX Wizard to Create a VSX Cluster on page 87 for more information on the Virtual System creation templates) Whether the Virtual System will run in Bridge mode If you selected the template for Virtual Systems with separate interfaces, and the Virtual System does not run in Bridge mode, the screen in Figure 5-10 appears: 106

107 Adding/Editing Virtual Systems Figure 5-10 Separate Virtual System not in bridge mode If the same Virtual System does run in Bridge mode, the screen in Figure 5-11 appears: Figure 5-11 Separate Virtual System in bridge mode If you selected the template for Virtual Systems with a shared interface, the screen in Figure 5-12 appears: Chapter 5 Using VSX 107

108 Adding/Editing Virtual Systems Figure 5-12 Virtual System with shared interface Note - There is no Bridge mode for a Virtual System created with the Shared Interface template If you selected the template for a custom Virtual System, and the Virtual System runs in bridge mode, the screen in Figure 5-13 appears: Figure 5-13 Custom Virtual System in bridge mode If you selected the template for a custom Virtual System, and the Virtual System does not run in bridge mode, the screen in Figure 5-14 appears: 108

109 Adding/Editing Virtual Systems Figure 5-14 Custom Virtual System, no bridge mode In all cases, select/add the required interfaces for the Virtual System. 4. Click Next and then Finish to complete the creation of the Virtual System. A message is displayed indicating the successful creation of the Virtual System. If you do not get a message that the Virtual System was properly created, refer to Chapter 10, VSX Diagnostics and Troubleshooting Editing an Existing Virtual System 1. In SmartDashboard, double-click the Virtual System object. The General Properties window opens, as shown in Figure 5-15 Chapter 5 Using VSX 109

110 Adding/Editing Virtual Systems Figure 5-15 General Properties window for Virtual System On the pages linked to this window, settings for Topology, NAT, VPN and others can be edited. 2. Click Topology. The Topology page opens, as shown in Figure 5-16: 110

111 Adding/Editing Virtual Systems Figure 5-16 Check Point Virtual System - Topology page On the Topology page you can change existing settings, add or remove warp interfaces leading to a Virtual Router or Virtual Switch. Based on these interface settings, the system creates a routing table for the VSX gateway. These routes are created automatically and cannot be edited or removed. For explanation of Warp interfaces, refer to Warp Links on page 33. Note - If you change the topology of a specific Virtual System, the topology of the VSX cluster will be updated only after installing a policy on that specific Virtual System. This means that if you delete a warp interface, running the command cphaprob -a if on the gateway will continue to show the warp interface until the next policy install. 3. In the Interfaces section, click Edit. The properties of the interface are displayed on two tabs: the General tab and Topology tab, as shown in Figure 5-17 and Figure Chapter 5 Using VSX 111

112 Adding/Editing Virtual Systems Figure 5-17 Interface General properties On the General tab, you can edit the IP address, netmask, or VLAN tag and set whether this route should be propagated to adjacent Virtual Devices. Figure 5-18 Interface topology properties On the Topology tab, configure whether the interface leads to the Internet or the local network, how the IP addresses are defined, and whether anti-spoofing should be active. Note - A Virtual System can be configured with up to 64 interfaces. 112

113 Authentication Options for Virtual Systems In certain situations the number of IP addresses required for interfaces can be reduced. For example, if the interface leads to a Virtual Router, the interface can be configured as unnumbered. For more information see: Unnumbered Interfaces on page Click OK to save your changes. Note - As the new settings are pushed to the gateway, this editing process may take up to a minute to complete. Authentication Options for Virtual Systems Virtual Systems can authenticate with a range of external authentication servers: LDAP, RADIUS, TACACS, TACACS+ RSA SecureID Authentication Manager (formerly ACE/Server) LDAP, RADIUS, TACACS, TACACS+ In versions previous to NGX, the warp cable (wrp5000) provided a direct link between Virtual Systems and the MVS (the Virtual System reserved for management) which was then used for connecting with external authentication servers such as LDAP, RADIUS, TACACS, and TACACS+. In NGX, two options are available for enabling connectivity between Virtual Systems and external authentication servers: Shared Private Shared When the shared option is configured, all authentication servers are accessible by all Virtual Systems through the VSX gateway. This is the default option. To configure the shared option, use the database tool GuiDBedit to set the shared_external_server property to TRUE (default setting). The Virtual Systems use the IP address of the VSX gateway. Therefore, connections to external servers have the VSX machine s IP address as their source address, a unique IP address for each cluster member. Virtual Systems on the same cluster member have identical source addresses when accessing the external management server. Chapter 5 Using VSX 113

114 Authentication Options for Virtual Systems Verify that the Authentication Server is located on the same network segment as the VSX gateway. Members of the cluster must not perform hide NAT on the external server service. To prevent Hide NAT: 1. On the management server, open the /opt/cpvsxngxcmp-r62/lib/table.def file for editing. 2. To the no_hide_services_ports table, add the service of the authentication scheme you wish to use. For example UDP 5500 for SecurID. The line should read: 3. Reinstall the policy on the Virtual System. Private no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <5500,17> }; When the private option is configured, authentication servers are accessed directly by the Virtual System. The Virtual system and the authentication server are located on the same network segment. Connections to the external authentication server use the Virtual System s cluster IP address as the source address. To configure the private option, use the database tool GUIDBedit to set the shared_external_server property to FALSE. Once the private option has been configured, it is not possible for the Virtual System to connect to other authentication servers in the VSX management network unless an explicit path is created through a Virtual Router or Virtual Switch. There is no need to edit the table.def file. 114

115 SecureID ACE/Server Authentication Options for Virtual Systems There are two options available for enabling connectivity between Virtual Systems and a SecurID ACE/Server: Shared Private In both instances, the SecurID ACE/Server sends a shared key (called a node secret ) to its peer ACE/Clients. This key is unique per IP address, and is sent once for each IP address. Shared To configure the shared option, use the database tool GUIDBedit to set the shared_external_server property to TRUE. Members of the cluster must not perform hide NAT on the external server service. To prevent Hide NAT: 1. On the management server, open the /opt/cpvsxngxcmp-r62/lib/table.def file for editing. 2. To the no_hide_services_ports table, add the UDP 5500 service. The line should read: 3. Reinstall the policy on the Virtual System. Private no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <5500,17> }; If the private option for accessing external servers has been configured, all the members use the same (cluster) IP address as their source address for connections to the ACE/Server. To configure the private option, use the database tool GUIDBedit to set the shared_external_server property to FALSE. After the first connection that uses SecurID authentication, the ACE Server creates a shared key called securid. This node secret key is created only once, and sent to: 1. the /var/ace directory of the active cluster member if the Virtual System that SecureClient connects to is the VSX gateway, VS(0) 2. the $FWDIR/CTX/CTX000X/conf directory of the active cluster member if SecureClient connects to a Virtual System other than VS(0) Chapter 5 Using VSX 115

116 Authentication Options for Virtual Systems To make this shared key available to the other member gateways, manually copy the node secret key from the first gateway. (The ACE/Server will not recreate the key.) For the active cluster member to use the cluster IP address as part of the hash performed on securid traffic, on all cluster members: 1. Create a file named /var/ace/sdopts.rec if SecureClient connects to VS(0), or /$FWDIR/CTX/CTX<VSID>/conf/sdopts.rec if SecureClient connects to a Virtual system other than VS(0) 2. Enter the client IP address: CLIENT_IP=<Virtual System cluster IP> 3. Perform cpstop/cpstart. For Both Shared and Private Options on SecureID Connections For all cluster members: 1. Open the /etc/services file for editing. 2. Add the lines: securid 5500/udp securidprop 5510/tcp On the ACE/Server, generate an sdconf.rec file. 1. If shared, generate the sdconf.rec file with the IP address of the VSX gateway: VS(0). 2. If private, generate the sdconf.rec file with the cluster IP of the Virtual System. 3. Copy the sdconf.rec file to the relevant cluster member. A. If the Virtual System that SecureClient connects to is the VSX gateway (VS(0)), place the sdconf.rec in the /ace/var directory. Create this directory if it does not exist. B. If SecureClient connects to a Virtual System other than VS(0), place sdconf.rec in $FWDIR/CTX/CTX000X/conf. 116

117 Editing the Configuration of a VSX Cluster The Effect of Upgrading on Authentication Processes An existing Virtual System upgraded to VPN-1 Power VSX receives the default settings for authentication with external servers. If the Virtual System was originally created on a management server located on the same network segment as the external authentication server, connectivity may be lost until the private option is enabled. Editing the Configuration of a VSX Cluster 1. In SmartDashboard, in the Network Objects tree, double-click the VSX cluster you want to edit. The VSX Cluster Properties window is displayed. 2. In the Cluster Members window you can change the IP network address that is used for internal communications between cluster members. 3. In the Physical Interfaces tab, you can define which interfaces can be assigned to Virtual Systems or Virtual Routers and whether the interfaces can be used with VLANs. Adding New Members to a Cluster New members are added to an existing cluster using the following series of commands on the management server: 1. vsx_util add_member 2. vsx_util reconf 3. vsx_util redistribute_vsls Note - A VSX cluster can support up to 8 cluster members. To Add a New Member to an Existing Cluster: 1. Install the new gateway on the target machine. 2. Perform local configuration, such as adding the IP address, network mask, and default gateway. 3. Run cpconfig to set the SIC activation key. Remember this key. You will need it later. 4. From a command prompt on the SmartCenter server, run: vsx_util add_member. Chapter 5 Using VSX 117

118 Removing Members From a Cluster Enter when prompted: the name of the SmartCenter server/main CMA IP address the administrator Name the administrator Password the name of the VSX cluster object the name of the member object to add 5. Wait until the add member operation finished successfully summary notice displays. The database is now updated and saved. (In SmartDashboard, an object for the new member is now displayed under the specified cluster.) Note - In a Provider-1 environment, the operation will skip any CMAs locked by an administrator. If this should occur, run the operation again for the relevant CMAs when they become available. 6. Run: vsx_util add_member_reconf Enter when prompted: The name of the SmartCenter server/main CMA IP address The administrator Name The administrator Password Activation key of the gateway 7. Wait until the Reconfigure module operation completed successfully summary notice displays. Note - In a Provider-1 environment, the operation will skip any CMAs locked by an administrator. If this should occur, run the operation again for the relevant CMAs when they become available. 8. Reboot the gateway. The new member has been added. See also Adding Members on page 237. Removing Members From a Cluster Since the remove operation modifies information in the SmartCenter server database, it is recommended to back-up the database before continuing. 118

119 Upgrading Cluster Members to VPN-1 Power VSX To remove a member from a cluster: 1. Run vsx_util remove_member. Enter when prompted: The name of the SmartCenter server/main CMA IP address The administrator Name The administrator Password Confirm that the license has been removed from the specified member. The member cannot be removed if a license is still attached. At this point, if you need to remove a license, the operation can be aborted. The name of the VSX/cluster object The name of the member to remove. 2. Wait until the remove member operation finished successfully summary notice displays. The database is now updated and saved. (In SmartDashboard, the object for the deleted member is no longer displayed under the specified cluster.) Note - In a Provider-1 environment, the operation will skip any CMAs locked by an administrator. If this should occur, run the operation again for the relevant CMAs when they become available. Upgrading Cluster Members to VPN-1 Power VSX The upgrade process is performed using the vsx_util upgrade command. The vsx_util reconfigure command applies settings stored in the management database to a newly installed gateway. If you intend to use a different machine for the upgraded gateway, make sure the old machine and new machine are identical in terms of hardware. For example, the new gateway has the same number (or more) of interfaces as the previous gateway. Before Upgrading the VSX Gateway 1. Make sure that your management server is version NGX R62. (For detailed information on upgrading SmartCenter server/provider-1 see the R62 Upgrade Guide.) 2. If you intend to use a different machine for the upgraded gateway, verify: the new machine meets the minimum hardware requirements as defined in the VPN-1 Power VSX Release Notes. Chapter 5 Using VSX 119

120 Upgrading Cluster Members to VPN-1 Power VSX the new machine has the same number (or more) of interfaces as the old machine, and that each interface has the same name and IP address as before If you intend to use the same machine, backup the current gateway, and save the configuration file to a different server. For detailed information on backing up a VSX gateway, see the backup and restore section of the SecurePlatform / SecurePlatform Pro Guide. Upgrading a Gateway to VPN-1 Power VSX 1. Perform a fresh install of the VPN-1 Power VSX gateway on the designated machine. Make sure the gateway has the same system level configuration as the previous installation. Use the sysconfig utility on the gateway to make sure each interface has the same IP address as before. (The hostname does not have to be the same.) 2. Run cpconfig to set the SIC activation key. This will be needed later. Using the vsx_util Command Before using the vsx_util command: It is recommended to backup the management server Verify that no administrator is connected to the management server. The vsx_util command modifies the management database, and cannot do so if the database is locked by an administrator. 1. From a shell prompt on the SmartCenter server, run: vsx_util upgrade Enter when prompted: The name of the SmartCenter server/ main CMA IP address The administrator Name The administrator Password The name of the VSX gateway/cluster object to be upgraded 2. Wait until the Finished upgrading/database saved successfully is displayed. 3. Run vsx_util reconfigure Enter when prompted: The name of the SmartCenter server/ main CMA IP address The administrator s name 120

121 Upgrading Cluster Members to VPN-1 Power VSX The Administrator s Password The name of the VSX gateway/cluster to reconfigure The SIC Activation Key for the gateway 4. Wait until the Reconfigure module operation completed successfully summary notice appears. In a Provider-1 environment, if one of the CMAs is locked by a customer, the reconfigure operation continues with those CMAs which are available. Later, the user will be prompted to resume the operation for those CMAs that were not available the first time. 5. Reboot the gateway. The gateway has been successfully upgraded Upgrading Clustered Deployments The upgrade and reconfigure options of the vsx_util command need to be executed once per VSX gateway. In the case of a VSX cluster: The upgrade option needs to be run per cluster object only. The reconfigure option needs to be run once per cluster member. For example, for a deployment with two clusters, each cluster having three members, the upgrade option needs to be run twice, once for each cluster object, and the reconfigure option six times, once for each cluster member. Note - Verify that an upgraded and reconfigured cluster member is fully operational before upgrading the remaining members. To preserve the stability of the VSX deployment, the upgrade and reconfigure operations should be run consecutively. 1. First upgrade the cluster object in the management database 2. Then immediately reconfigure the cluster members. Chapter 5 Using VSX 121

122 Resume Operation Resume Operation The vsx_util command is able to resume operations that were initiated previously but did not complete. If an administrator has a lock on a management database, the vsx_util command will not be able to access the database for the operation. Resume means that the operation is not repeated from the start, but continues from that point the operation previously reached before stopping. For example, if the user is reconfiguring the member gateways of a cluster, and a policy installation is also taking place on one of the members, the operation will not complete, and needs to be resumed later. Note - Resume is available only for the reconfigure option. The user is prompted whether to resume the operation or not. Logging All operations performed using vsx_util are logged to vsx_util.log, a file created in the directory from which the vsx_util command was run. VSX Gateway Recovery The vsx_util command is also used to recover inoperable gateways. For example, after a hard disk failure: 1. Replace the hard disk, reinstall the gateway. 2. Perform local configuration: IP addresses, network mask, default gateway. 3. Verify that the interfaces have the same IP addresses as before. 4. Perform SIC with the SmartCenter server. 5. From a command line interface on the SmartCenter server, run vsx_util reconfigure to restore the gateway s previous configuration of Virtual Devices. 122

123 Network Address Translation in VSX Network Address Translation in VSX A Virtual System is capable of Network Address Translation (NAT) the same as a physical Firewall. When a Virtual System is connected to a Virtual Router and the Virtual System performs Static or Hide NAT to a host on a given network, NATed routes have to be forwarded to the Virtual Router, as shown in Figure 5-19: Figure 5-19 Static/Hide NAT in VSX In Figure 5-19, to communicate with Host C on Subnet A, Virtual System VS 3 performs Static NAT. VS 3 is directly connected to Virtual Router EVR1. For this to work, EVR1 needs to be configured with the NATed addresses. The NATed address can be: Manually added to the Virtual Router (Topology page > Routes) Defined on the Virtual System (Topology page > NAT Addresses...) Hide or Static NAT addresses configured on the Virtual System are automatically forwarded to the Virtual Router to which the Virtual System is directly connected. NATed addresses can be: Chapter 5 Using VSX 123

124 Network Address Translation in VSX A single IP (for Hide NAT) A range of addresses (Hide NAT) Complete subnets (Hide NAT) To Enable Automatic Forwarding of NATed Addresses 1. Double-click the Virtual System that is directly connected to the Virtual Router 2. Topology > NAT Addresses... The NAT Address range properties window opens, as shown in Figure 5-20: Figure 5-20 NAT address properties 3. Enter a single IP address, a range of IP addresses, or an IP subnet: For a Static IP NAT address, enter the address twice, in the First and Last fields. For a range of IP addresses, enter the First and Last IP addresses of the range. For a subnet, enter the First and Last IP addresses of the subnet. 124

125 Advanced Routing Scenarios Advanced Routing Scenarios This section describes how to apply Advanced Routing (sourced-based routing) definitions when configuring a VSX environment. With Advance Routing you are able to apply routing definitions that take precedence over ordinary, or policy-based, routing decisions. This enables routing packets according to source IP address or a combination of source IP address and destination IP address. Advanced routing is useful in cases where a single physical interface without VLAN tagging is used to connect protected customer networks. Each protected network is assigned a set of unique IP addresses on the shared network. Traffic is routed by a Virtual Router to the appropriate Virtual System according to the source IP address on the shared network. In This Section Adding/Editing Virtual Routers in VSX Gateways page 125 Adding/Editing Virtual Switches to a VSX Gateway or Cluster page 130 Obtaining Status Information page 131 Adding/Editing Virtual Routers in VSX Gateways This section describes how to define a Virtual Router in a VSX gateway. As with physical routers, each Virtual Router maintains a route table with a list of route entries describing known networks and directions on how to reach them. Virtual Routers can be used for both external and internal communications. However, each Virtual Router has to be defined and configured according to its function and position within the overall VSX system. For clarity, the Virtual Router that faces the Internet can be referred to as the External Virtual Router (EVR), while the Virtual Router that faces the internal protected networks as the Internal Virtual Router (IVR). In real terms there is no difference between them. They are both Virtual Routers. An External Virtual Router normally functions as the default external gateway of all Virtual Systems, allowing them to share a single secure physical interface leading to the Internet and enabling communication between Virtual Systems connected to the same Virtual Router. The Internal Virtual Router is normally defined with one interface connecting to the customer network(s) through a switch, and additional Warp Links to all the Virtual System s configured in that particular VSX gateway. Chapter 5 Using VSX 125

126 Advanced Routing Scenarios Figure 5-21 shows an example of a VSX configuration with both an External Virtual Router (EVR) and an Internal Virtual Router (IVR). The following pages describe how to add the IVR, which only has one internal interface. After creating a new Virtual Router you must add new interfaces to the Virtual Systems that connect to the newly created Virtual Router before proceeding further. Figure 5-21 Basic VSX deployment using an EVR and an IVR To Add Virtual Routers to a VSX Gateway 1. From the File menu in SmartDashboard, select Manage > Network Objects > New > Check Point > Virtual Router. The Virtual Router Wizard opens, as shown in Figure

127 Advanced Routing Scenarios Figure 5-22 Virtual Router Wizard - General Properties 2. In the Name field, enter the Virtual Router s name (IVR). 3. From the drop-down box select the VSX gateway to which the Virtual Router will belong (VSX1). 4. Click Next. The Virtual Router Network Configuration window opens, as shown in Figure 5-23: Figure 5-23 Virtual Router network configuration 5. Add Interfaces and Routes and a Default Gateway. 6. Click Next then Finish to complete the creation of the VSX router. Chapter 5 Using VSX 127

128 Advanced Routing Scenarios A message is displayed indicating the successful creation of the Virtual Router. If you do not see the message, refer to Chapter 10, VSX Diagnostics and Troubleshooting. Editing the Properties of a Virtual Router 1. In SmartDashboard, double-click the object that represents the Virtual Router. The Check Point Virtual Router - General Properties window opens. Figure 5-24 Check Point Virtual Router - General Properties window 2. On the Topology page, define interfaces and routes for the Virtual Router. Based on these interface addresses, the system creates a routing table for the VSX gateway. These routes are created automatically and cannot be edited or removed. Figure 5-25 shows the topology page: 128

129 Advanced Routing Scenarios Figure 5-25 Topology page of Virtual Router From this page, a default gateway and rules for advanced routing are configured. 3. Click OK to save your changes. Chapter 5 Using VSX 129

130 Advanced Routing Scenarios Adding/Editing Virtual Switches to a VSX Gateway or Cluster To add a Virtual Switch to a VSX gateway: 1. From the File Menu in SmartDashboard select Manage > Network Objects > New > Check Point > Virtual Switch. The Virtual Switch Wizard opens, as shown in Figure 5-26: Figure 5-26 Virtual Switch wizard opening page - General Properties 2. Supply a name for the Virtual Switch. 3. From the drop-down box, select the VSX gateway/cluster with which the Virtual Switch is associated. 4. Click Next. The Virtual Switch Network Configuration page opens: Figure 5-27 Virtual Switch Network Configuration 5. Click Add to select an interface for the Virtual Switch and assign, if required, a VLAN tag. 6. Click Next and Finish. 130

131 Obtaining Status Information To Edit an Existing Virtual Switch Double-click the Virtual Switch object. The properties page for that object opens, as shown in Figure 5-28: Figure 5-28 General properties page of a Virtual Switch Additional interfaces can be added in the Topology window. To add new cluster members see: Adding New Members to a Cluster on page 117. Obtaining Status Information SmartView Monitor is the Graphical User Interface application from which all gateway and Virtual Systems/Routers statuses are displayed. SmartView Monitor displays a snapshot of all Check Point products, such as the VSX gateway/cluster, VPN-1, QoS, and ClusterXL. For more information on using SmartView Monitor, refer to the SmartCenter Guide. Chapter 5 Using VSX 131

132 Obtaining Status Information SmartView Monitor SmartView Monitor displays each VSX gateway/cluster as a regular Check Point gateway, but with a different icon. For each VSX gateway/cluster the VSX gateway object shows OS level information as well as CPU Memory and Disk Usage information. SmartView Monitor connects to and validates each Virtual System as an independent gateway. If one Virtual System is down, this information will be reflected in SmartView Monitor (Figure 5-29) even though the other Virtual Systems on the VSX gateway/cluster are functioning normally. Figure 5-29 SmartView Monitor 132

133 Managing Security and VPN Policies Using SmartDashboard Managing Security and VPN Policies Using SmartDashboard If you are defined as a CMA administrator in Provider-1/SiteManager-1, in your SmartDashboard you will only see those Virtual Systems that belong to your company, even though they may reside on a VSX machine that has other company s Virtual Systems as well. Otherwise, the management of security and VPN policies for Virtual Devices in SmartDashboard is identical to that of a regular gateway/cluster. For more information on managing Security and VPN Policies, refer to the SmartCenter Guide and the Provider-1/SiteManager-1 Guide. Chapter 5 Using VSX 133

134 Source-Based Routing Source-Based Routing This section describes how to apply sourced-based routing definitions when configuring the VSX environment. With source-based routing you configure routing definitions that take precedence over ordinary, or policy-based, routing decisions. This enables the routing of packets according to source IP address or a combination of source IP address and destination IP address. Source-based routing is useful in cases where a single physical interface without VLAN tagging is used to connect protected customer networks. Each protected network is assigned a set of unique IP addresses on the shared network with traffic routed by the Virtual Router used for internal communications to the appropriate Virtual System according to the source IP address in the shared network. Figure 5-30 shows an example of a VSX deployment with several Virtual Systems and both External and Internal Virtual Routers. Figure 5-30 Sourced-based routing scenario Advanced Routing Rules, where routing decisions are based on the IP address of the source, can be applied to the Virtual routers. 134

135 Source-Based Routing The process for defining Advanced Routing is the same for Internal Virtual Routers in both VSX gateways and VSX clusters. To Define Advanced Routing 1. In SmartDashboard, in the Network Objects tab of the Objects Tree, select the IVR for which you want to configure Advanced Routing. From the right-click menu select Edit. The Check Point Virtual Router - IVR window is displayed. 2. Select Topology in the Check Point Virtual Router object s Tree. The Topology window is displayed. Figure 5-31 Topology window - basic Virtual Router defined 3. Select Advanced Routing. The Advanced Routing Rules window is displayed. Chapter 5 Using VSX 135

136 Source-Based Routing Figure 5-32 Advanced Routing Rules window 4. Select Add. The Add/Edit Route Rule window is displayed. Figure 5-33 Add/Edit Route window 5. Define both the Source IP Address and Source Net Mask for the selected interface ( and ) and the Destination IP Address and Net Mask according to the specific customer (in this case and ), as well as the Next Hop Gateway, the warp that connects to the specific Virtual System to be used. 6. Click OK to save your settings. Repeat step 4 for all the routes you want to add. 7. Click OK to save the Advanced Routing Rules. 8. Click OK to close the Configure Virtual Router window. 136

137 Configuring Unnumbered Interfaces Configuring Unnumbered Interfaces A Virtual System interface connected to a Virtual Router can be configured as unnumbered. This means the interface borrows an IP address from another interface. Note - Configuring an interface as unnumbered is only possible when the interface leads to a Virtual Router. When an interface is unnumbered, in the Interface Properties (Figure 5-34) window select an interface from which to borrow an IP address. This interface must not be another unnumbered interface. Figure 5-34 Unnumbered interfaces for Virtual Systems Chapter 5 Using VSX 137

138 Anti-Spoofing on VSX Interfaces Anti-Spoofing on VSX Interfaces Anti-spoofing can be configured as long as the topology of each interface is properly configured. When dynamic routing is employed, deselect the Calculate topology automatically based on routing information checkbox, and manually configure the topology of the Virtual System. 138

139 Chapter 6 VSX Clustering with ClusterXL In This Chapter Introduction page 140 Connecting Several Clusters on the Same Layer-2 Segment page 141 Using the cphaprob Command in VPN-1 Power VSX page 143 Monitoring all VLANs page 145 Clustering Virtual Systems in Bridge Mode (for ClusterXL only) page 151 Using PVST+ for Load Sharing page 152 Monitoring all VLANs page 145 Single Virtual System Failover page 146 Enabling Dynamic Routing Protocols in a Cluster Deployment page

140 Introduction Introduction This chapter deals with VSX in a ClusterXL environment. For general information regarding VSX clustering see: Clustering in VSX on page

141 Connecting Several Clusters on the Same Layer-2 Segment Connecting Several Clusters on the Same Layer-2 Segment When configuring a cluster, it is recommended to connect its interfaces to a Layer-2 segment which is isolated from other clusters. When configuring a cluster with two members only, it is also recommended to connect the secured interfaces of the sync network with a crossover cable. However, in a deployment where multiple clusters need to connect to the same Layer-2 segment, be aware that the same MAC address may be used by more than one cluster for CCP communication. This may cause traffic to be processed by the wrong cluster. In this case it is necessary to alter the source MAC address(es) of the clusters. This section describes how source MAC addresses are assigned, and explains how to change them. It applies to both High Availability modes of ClusterXL, and to OPSEC certified clustering products. Source Cluster MAC Addresses Cluster members communicate with each other using the Cluster Control Protocol (CCP). In order to distinguish CCP packets from ordinary network traffic, CCP packets are given a unique source MAC address. The first four bytes of the source MAC address are all zero: The fifth byte of the source MAC address is a magic number, a number that encodes critical information in a way intended to be opaque. Its value indicates its purpose: Default value of fifth byte 0xfe 0xfd Purpose CCP traffic Forwarding layer traffic The sixth byte is the ID of the source cluster member When multiple clusters are connected to the same Layer-2 segment, setting a unique value to the fifth byte of the MAC source address of each cluster allows them to coexist on the same Layer-2 segment. Chapter 6 VSX Clustering with ClusterXL 141

142 Connecting Several Clusters on the Same Layer-2 Segment Changing a Cluster s MAC Source Address To change a cluster s MAC source address, run the following commands on each cluster member: fw ctl set int fwha_mac_magic <value> fw ctl set int fwha_mac_forward_magic <value> The default values of the parameters fwha_mac_magic and fwha_mac_forward_magic appear in the following table: Parameter fwha_mac_magic fwha_mac_forward_magic Default value 0xfe 0xfd Use any value as long as the two gateway configuration parameters are different. To avoid confusion, do not use the value 0x00. Making the Change Permanent These gateway configuration parameters can be configured to survive reboot. For machines running SecurePlatform, do the following: 1. Use a text editor to open the file fwkern.conf, located at $FWDIR/boot/modules/. 2. Add the line Parameter=<value in hex>. Make sure there are no spaces. 142

143 Using the cphaprob Command in VPN-1 Power VSX Using the cphaprob Command in VPN-1 Power VSX Use the cphaprob command to verify that the cluster and the cluster members are working properly, and to define critical devices. A critical device is a process running on a cluster member that enables the member to notify other cluster members that it can no longer function as a member. The device reports to the ClusterXL mechanism regarding its current state or it may fail to report, in which case ClusterXL decides that a failure has occurred and another cluster member takes over. When a critical device (also known as a Problem Notification, or pnote) fails, the cluster member is considered to have failed. There are a number of built-in critical devices, and the administrator can define additional critical devices. The default critical devices are: The cluster interfaces on the cluster members. Synchronization full synchronization completed successfully. Filter the Security Policy, and whether it is loaded. cphad which follows the ClusterXL process called cphamcset. fwd the VPN-1 daemon. These commands can be run automatically by including them in scripts. To produce a usage printout for cphaprob that shows all the available commands, type cphaprob at the command line and press Enter. The following output appears: cphaprob -d <device> -t <timeout(sec)> -s <ok init problem> [-p] register cphaprob -f <file> register cphaprob -d <device> [-p] unregister cphaprob -a unregister cphaprob -d <device> -s <ok init problem> report cphaprob [-i[a]] [-e] [-vs vsid] list cphaprob [-vs vsid] state cphaprob [-a] [-vs vsid] if cphaprob savepnotes cphaprob -vs <vsid> register cphaprob -vs <vsid> unregister cphaprob [-reset] ldstat cphaprob [-reset] syncstat Explanation: Chapter 6 VSX Clustering with ClusterXL 143

144 Using the cphaprob Command in VPN-1 Power VSX Argument cphaprob [-vs vsid] state cphaprob [-a] [-vs vsid] if cphaprob -d <device> -t <timeout (sec) > -s <ok init problem> [-p] register cphaprob -f <file> register cphaprob -d <device> [-p] unregister cphaprob -a unregister cphaprob -d <device> -s <ok init problem > report cphaprob [-i[a]] [-e] list cphaprob [-reset] ldstat cphaprob [-reset] syncstat cphaprob savepnotes Destination View the status of a cluster member, and of all the other members of the cluster. View the state of the cluster member interfaces and the virtual cluster interfaces. Register <device> as a critical process, and add it to the list of devices that must be running for the cluster member to be considered active. Register all the user defined critical devices listed in <file>. Unregister a user defined <device> as a critical process. This means that this device is no longer considered critical. Unregister all user defined devices Report the status of a user defined critical device to ClusterXL. View the list of critical devices on a cluster member, and of all the other machines in the cluster. View sync serialization statistics View sync transport layer statistics Saves problem notifications 144

145 Monitoring all VLANs Monitoring all VLANs By default, ClusterXL monitors the highest and lowest VLANs (for example eth1.10, and eth50.50) for failure. Note - The command line option cphaprob -a if displays the highest and lowest VLANs being monitored. When the highest and lowest VLANs fail, all the VLANs are considered down, and a failover occurs. This means that if a VLAN which is not listed as the highest or lowest goes down, the trunk is still considered up, and no failover occurs. There are instances in which it would be advantageous to monitor all the VLANs in the trunk, not just the highest and lowest, and initiate a failover when one of the virtual interfaces goes down. By enabling the kernel variable fwha_monitor_all_vlans in $FWDIR/boot/modules/fwkern.conf all of the VLANs can be monitored. Although this feature can be enabled by itself, it is recommended to enable it if you wish to use the Single Virtual System Failover feature. Chapter 6 VSX Clustering with ClusterXL 145

146 Single Virtual System Failover Single Virtual System Failover Where there is no Virtual Router configured, each Virtual System can monitor its own interface for failure, as shown in Figure 6-1: Figure 6-1 Per VS failover In Figure 6-1, each member of the cluster contains two Virtual Systems. If the physical interface connected with VS1 goes down, VS1 fails-over to its peer in the cluster. VS2 does not fail over. For this feature to work, each Virtual System must be directly connected to: A distinct physical interface or VLAN interface When working in VSX Load Sharing, the Virtual System failover feature is enabled by default. When not using VSX Load Sharing, the failover feature can be enabled via the following kernel variables: fwha_enable_state_machine_by_vs fwha_monitor_all_vlans Note - The variable fwha_monitor_all_vlans is enabled by default if the user enables it with the command cpconfig. 146

147 Enabling Dynamic Routing Protocols in a Cluster Deployment Enabling Dynamic Routing Protocols in a Cluster Deployment ClusterXL supports Dynamic Routing (Unicast and Multicast) protocols as an integral part of SecurePlatform VPN-1 Power VSX. As the network infrastructure views the clustered gateway as a single logical entity, failure of a cluster member will be transparent to the network infrastructure and will not result in a ripple effect. Components of the System Virtual IP Integration All cluster members use the cluster IP address(es). Routing Table Synchronization Routing information is synchronized among the cluster members using the Forwarding Information Base (FIB) Manager process. This is done to prevent traffic interruption in case of failover, and used for ClusterXL Load Sharing mode. The FIB Manager is the responsible for the routing information. The FIB Manager is registered as a critical device (Pnote), and if the slave goes out of sync, a Pnote will be issued, and the slave member will go down until the FIB Manager is synchronized. Failure Recovery Dynamic Routing on ClusterXL avoids creating a ripple effect upon failover by informing the neighboring routers that the router has exited a maintenance mode. The neighboring routers then reestablish their relationships to the cluster, without informing the other routers in the network. These restart protocols are widely adopted by all major networking vendors. The following table lists the RFC and drafts compliant with Check Point Dynamic Routing: Table 6-1 Compliant Protocols Protocol RFC or Draft OSPF LLS draft-ietf-ospf-lls-00 OSPF Graceful restart RFC 3623 BGP Graceful restart draft-ietf-idr-restart-08 Chapter 6 VSX Clustering with ClusterXL 147

148 Enabling Dynamic Routing Protocols in a Cluster Deployment Dynamic Routing in ClusterXL The components listed above function behind-the-scenes. When configuring Dynamic Routing on ClusterXL, the routing protocols automatically relate to the cluster as they would to a single device. When configuring the routing protocols on each cluster member, each member is defined identically, and uses the cluster IP address(es) (not the member s physical IP address). In the case of OSPF, the router ID must be defined and identical on each cluster member. When configuring OSPF restart, you must define the restart type as signaled or graceful. For Cisco devices, use type signaled. Use SecurePlatform s command line interface to configure each cluster member. Figure 6-2 is an example of the proper syntax for cluster member A. 148

149 Enabling Dynamic Routing Protocols in a Cluster Deployment Figure 6-2 Enabling OSPF on cluster member A Launch the Dynamic Routing Module vsx1:0]# router ER0 999 Unable to connect to host 'localhost'! ER0 999 Dynamic Routing is not supported on VSX gateway/cluster Use 'vrf-connect' to enter specific Virtual System (disconnected)>vrf-connect 1 localhost.localdomain- VRF-1>enable localhost.localdomain- VRF-1#configure terminal Enable OSPF and provide an OSPF router ID localhost.localdomain- VRF-1(config)#router ospf 1 localhost.localdomain- VRF-1(config-router-ospf)#router-id localhost.localdomain- VRF-1(config-router-ospf)#restart-type [ graceful signaled ] localhost.localdomain- VRF-1(config-router-ospf)#redistribute kernel Define interfaces/ip addresses on which OSPF runs (Use the cluster IP localhost.localdomain- VRF-1(config-router-ospf)#network area localhost.localdomain- VRF-1(config-router-ospf)#network area Exit the Dynamic Routing Module localhost.localdomain- VRF-1(config-router-ospf)#exit localhost.localdomain- VRF-1(config)#exit Write configuration to disk localhost.localdomain- VRF-1#write memory IU0 999 Configuration written to '/etc/gated1.ami' localhost.localdomain- VRF-1# The same configuration needs to be applied to each cluster member. As the FIB Manager uses TCP 2010 for routing information synchronization, the Security Policy must accept TCP 2010 to and from all cluster members. For detailed information regarding Dynamic Routing, see the Check Point Advanced Routing Suite guide. Chapter 6 VSX Clustering with ClusterXL 149

150 Virtual Switch in a Cluster Virtual Switch in a Cluster In a VSX cluster, Virtual Switches are also clustered for redundancy. Virtual Switches in the cluster are defined as active/active. By means of the ClusterXL Control Protocol (CCP), the physical interface connected to the Virtual Switch is monitored. In the event of a failover, all Virtual Systems on standby become active, and send gratuitous ARPs from the warp interface between the Virtual System and the Virtual Switch. Figure 6-3 Clustered Virtual Switches In Figure 6-3, a simplified VSX cluster contains two members, one active, the other standby. The Virtual Switches within each cluster are active/active. When the physical interface connected to either Virtual Switch fails to respond, a failover occurs. 150

151 Clustering Virtual Systems in Bridge Mode (for ClusterXL only) Clustering Virtual Systems in Bridge Mode (for ClusterXL only) A Virtual System in bridge mode transparently supports the Spanning Tree Protocol (STP), a link management protocol that provides path redundancy and prevents undesirable loops between switches. For a Virtual System in bridge mode to support STP, the Virtual System must be connected directly to a physical interface, as shown in Figure 6-4: Figure 6-4 STP support In Figure 6-4, the Virtual Systems in bridge mode move traffic at layer-2 between the switches on either side of the VSX machine, and transparently supports network linking decisions forwarded by STP. Even though the members of the VSX cluster in Figure 6-4 are in an active/standby configuration, the Virtual Systems (in bridge mode) on each cluster member are defined as active/active. Remember that: A Virtual System in bridge mode forwards all traffic received from the switch. STP decides which Virtual System receives packets. STP detects a failure when it stops receiving BPDUs (for example after a cable is disconnected), and immediately forwards traffic to the peer Virtual System in the cluster. A Virtual System in bridge mode is also capable of initiating a failover in the spanning tree by blocking BPDU packets. For example, if a critical firewall process fails in the Virtual System, the Virtual System initiates a failover to its peer in the VSX cluster by blocking BPDUs. Chapter 6 VSX Clustering with ClusterXL 151

152 Using PVST+ for Load Sharing Using PVST+ for Load Sharing To improve performance, Load Sharing can be implemented via the Per-VLAN Spanning Tree Plus (PVST+) protocol, a variation of STP. (The 802.1Q standard defines one unique Spanning Tree instance to be used by all VLANs in the network. PVST+ enables a separate spanning tree to be constructed for each VLAN.) While Virtual Systems in bridge mode are defined active/active, PVST+ can be configured so that a specific VLAN connected to a specific Virtual System receives higher priority than its peer in the cluster. In this way, Load Sharing per Virtual System is achieved. Note - It is the STP configuration that determines whether High Availability or Load Sharing takes place. As shown in Figure 6-5, VSX supports whatever decision is made by the STP protocol. Figure 6-5 Load sharing between Virtual Systems In Figure 6-5, PVST+ is configured so that VLAN 01 receives higher priority than its peer in the cluster. In this way the load is shared between them. Note - For Virtual Systems in bridge mode to support Load Sharing and High Availability decisions made by the STP protocol, the virtual systems must be connected directly to a physical or virtual (VLAN) interface. 152

153 Chapter 7 ClusterXL Virtual System Load Sharing In This Chapter Introduction to ClusterXL Load Sharing page 154 How it Works page 155 Configuration page 161 CLI Commands page

154 Introduction to ClusterXL Load Sharing Introduction to ClusterXL Load Sharing This chapter focuses on enhancements to the clustering capabilities of VPN-1 Power VSX NGX Scalability Pack (High Availability). VPN-1 Power VSX NGX Scalability Pack provides the ability to distribute Virtual Systems on different members of a cluster, effectively spreading the Virtual System traffic load within the cluster. This cluster mode is called ClusterXL Load Sharing, and it provides the following benefits: Capacity - ClusterXL Load Sharing leverages the cluster machines to handle greater network volume by efficiently distributing the load. Redundancy - A ClusterXL Load Sharing cluster with n machines offers full redundancy by maintaining connectivity for all the Virtual Systems even when n-1 machines fail. Cost efficiency - A ClusterXL Load Sharing cluster requires only a standard Layer 2 switch to achieve load sharing. Configuration simplicity - Virtual Systems are automatically distributed among all the cluster members - no special configuration is required. Priority designation - Mission-critical Virtual Systems can be separated from the other Virtual Systems, providing advantages in terms of bandwidth and resources. System scalability - Every cluster member added to the cluster increases the overall system capacity and redundancy. This document describes the system architecture and configuration, and includes a command line interface reference section. 154

155 How it Works How it Works In This Section Introduction to How it Works page 155 Backup State page 155 Standard Operation page 156 A Failure Scenario page 158 Another Failure Scenario page 159 Recovery page 160 Introduction to How it Works ClusterXL Load Sharing for VPN-1 Power VSX differs from load sharing in the traditional sense, in that it is not connection-based. Rather, its modus operandi is to distribute Virtual Systems to different cluster members, and then direct all of a specific Virtual System s traffic to a specific cluster member. This can be useful both in balanced configurations, where the desire is to simply spread the load equally, and in mission-critical deployments, where reserving bandwidth for a particular Virtual System is a priority. ClusterXL Load Sharing allows the administrator to either manually place specific Virtual Systems on specific cluster members, or allow the system to determine the dispersal configuration automatically. For configuration details, see the command vsx_util redistribute_vsls on page 167. Note - A VSX cluster cannot be configured with ClusterXL in Load Sharing mode if it contains Virtual Systems in bridge mode or Virtual Routers. Backup State ClusterXL Load Sharing adds a new Virtual System state called Backup to the existing states of Active and Standby. The Backup state contains the latest settings of the Virtual System, but does not receive state table synchronizations. The relationship between Virtual System states is illustrated in Figure 7-1. Chapter 7 ClusterXL Virtual System Load Sharing 155

156 How it Works Figure 7-1 Three states of a single Virtual System Each Virtual System in a ClusterXL Load Sharing cluster is replicated on the different cluster members, and each copy exists in a different state. The Active and Standby states of the Virtual System are synchronized so that the Standby copy can immediately become Active if the cluster member hosting an Active Virtual System experiences a failure. When this happens, the Backup Virtual System becomes a Standby Virtual System, and begins a full sync with the newly Active Virtual System. By not synchronizing the state tables with the Active Virtual System, the Backup state provides one of the key benefits of ClusterXL Load Sharing a reduction in the load on the sync network and consequently a more optimal use of system resources. Standard Operation Consider a deployment consisting of three cluster members and three Virtual Systems. In such a configuration, a typical load sharing deployment would be to set one Virtual System as Active on each cluster member. Figure 7-2 illustrates such a deployment. 156

157 How it Works Figure 7-2 Active Virtual Systems distributed among cluster members In Figure 7-2, three Virtual Systems have been created and a different cluster member hosts the Active state of each. This distribution of Virtual Systems spreads the load among the clustered machines. Once a Virtual System has been created, the system automatically creates Standby and Backup states for it and distributes them among the other cluster members, as illustrated in Figure 7-3. Chapter 7 ClusterXL Virtual System Load Sharing 157

158 How it Works Figure 7-3 Evenly dispersed ClusterXL Load Sharing deployment Note that in Figure 7-3, VS 1 is Active on Cluster Member 1, Standby on Cluster Member 3, and Backup on Cluster Member 2. The states of VS 2 and VS 3 are similarly distributed. A Failure Scenario In the event of a connectivity problem on one of the cluster members, ClusterXL Load Sharing detects the problem and directs traffic for the Virtual Systems affected by the failure to their respective Standby Virtual Systems. The Standby Virtual Systems, which are kept fully synchronized with their Active partners, switch immediately to the Active state and preserve active connections. At the same time, the Backup Virtual Systems switch to Standby, and begin a full sync operation with the newly Active Virtual Systems. Figure 7-4 illustrates the system s reaction to a connectivity failure. 158

159 How it Works Figure 7-4 Cluster member failure causes state change in Standby & Backup Virtual Systems In Figure 7-4, when the cluster detects a connectivity failure with Cluster Member 1, it performs a sub-second failover to the Standby Virtual System for VS 1 on Cluster Member 3, and directs all traffic for VS 1 to this cluster member. Concurrently, the system changes the state of the Backup Virtual Systems for VS 1 and VS 2 to Standby, and begins a full sync. Another Failure Scenario The previous scenario discussed the ramifications of a connectivity failure with a cluster member. However, a failure that affects individual Virtual Systems, but not others, will cause a failover for the affected systems only. Consider the following example: Chapter 7 ClusterXL Virtual System Load Sharing 159

160 How it Works Virtual Systems A and B are Active on a certain cluster member an interface belonging to Virtual System A fails In this case, only Virtual System A will fail over to another cluster member. Virtual System B will continue in the Active state on the original cluster member. Recovery When the affected cluster member or Virtual System comes back online, the system returns to its original load sharing configuration (Figure 7-3). 160

161 Configuration Configuration In This Section Introduction to Configuration page 161 Enable Per Virtual System State Mode page 161 Set Up ClusterXL Load Sharing page 161 Reviewing Virtual System Distribution page 162 Redistributing Virtual Systems Among Cluster Members page 162 Introduction to Configuration Setting up ClusterXL Load Sharing for VSX requires first enabling Per Virtual System State mode on each cluster member. A Load Sharing cluster can then be created, either by creating a new cluster object, or converting an existing ClusterXL High Availability cluster to Load Sharing mode. The distribution of the Virtual Systems can then be reviewed, and if necessary, modified. Enable Per Virtual System State Mode The Per Virtual System State mode allows Active Virtual Systems to be placed on different cluster members, and for Virtual System-specific failover. This setting is mandatory for ClusterXL Load Sharing. On each cluster member, do the following: 1. Run the command cpconfig. 2. Select Enable Check Point Per Virtual System State. 3. Answer y to the question: Would you like to enable Per Virtual System state? Set Up ClusterXL Load Sharing ClusterXL Load Sharing clusters can be created by two methods: as a new cluster, or by converting an existing ClusterXL High Availability cluster. Creating a New Cluster To create a new cluster using ClusterXL Load Sharing, do the following: Chapter 7 ClusterXL Virtual System Load Sharing 161

162 Configuration 1. From the Objects Tree in SmartDashboard, right click on Check Point and select New Check Point > VPN-1 Power VSX > Cluster. 2. Give the cluster object a name and select ClusterXL Load Sharing as the cluster type. 3. Continue configuring the cluster in the same manner as you would a ClusterXL High Availability cluster. 4. Use the VPN-1 Power VSX Create Virtual System wizard to create Virtual Systems. Converting an Existing Cluster To convert an existing ClusterXL High Availability cluster to ClusterXL Load Sharing, do the following: 1. Use the vsx_util convert_cluster command on the management server to change the cluster type, as described in vsx_util convert_cluster on page If desired, use the VPN-1 Power VSX Create Virtual System wizard to add Virtual Systems. Note - A VSX cluster cannot be converted to ClusterXL in Load Sharing mode if it contains Virtual Systems in bridge mode or Virtual Routers. Reviewing Virtual System Distribution To review the distribution of the Virtual Systems within the cluster, run the vsx_util vsls command on the management server, as described in vsx_util vsls on page 163. Redistributing Virtual Systems Among Cluster Members To modify the distribution of Virtual Systems, run the vsx_util redistribute_vsls command, as described in vsx_util redistribute_vsls on page

163 CLI Commands CLI Commands In This Section New Commands in this Release page 163 Commands Modified for VPN-1 Power VSX page 168 The following commands are to be run on the VPN-1 Power VSX management station. New Commands in this Release In This Section vsx_util vsls page 163 vsx_util convert_cluster page 165 vsx_util redistribute_vsls page 167 vsx_util vsls The vsx_util vsls command displays the following information: The name and ID of each Virtual System participating in the cluster Chapter 7 ClusterXL Virtual System Load Sharing 163

164 CLI Commands The preferred configuration for which cluster members should host the Virtual System s Active, Standby, and Backup states. This preference is expressed in terms of priority, where the cluster member preferred to host the Active state of the Virtual System is assigned a priority of 0. Priority levels are defined as following: Priority Definition 0 Highest priority, indicates the cluster member selected to host the Virtual System s Active state. 1 Second highest priority, indicates the cluster member selected to host the Virtual System s Standby state. > 1 Lower priority, indicates the cluster members selected to host a Virtual System s Backup state. The cluster member assigned priority 2 will be the first to switch the Virtual System to the Standby state in the event of a failure of either the Active or Standby Virtual System. A cluster member assigned priority 3 would be the next in line to come online in the event of another failure. The weight assigned to each Virtual System. As not all Virtual Systems are equal in terms of traffic and load, ClusterXL Load Sharing allows certain Virtual Systems to be weighted more than others. The weight of a Virtual System affects the dispersal pattern of other Virtual Systems across cluster members. Assigning a heavier weight to a Virtual System gives it increasingly exclusive use of a particular cluster member, and accordingly disperses the other Virtual Systems to other cluster members. For information about changing priorities or weights, see the section vsx_util redistribute_vsls on page

165 CLI Commands Example: vsx_util vsls Enter SmartCenter Server/main CMA IP address (Hit 'ENTER' for 'localhost'): Enter Administrator Name: Enter Administrator Password: Enter ClusterXL Load Sharing cluster object name: VSID VS name m5 m6 m7 Weight vs vs vs vs vs vs Total weight Legend: 0 - Highest priority 1 - Next priority 2 - Lowest priority vsx_util convert_cluster The vsx_util convert_cluster command changes the clustering type (choose either ClusterXL High Availability or ClusterXL Load Sharing). Chapter 7 ClusterXL Virtual System Load Sharing 165

166 CLI Commands Example: vsx_util convert_cluster ****************************************************************** Note: the operation you are about to perform changes the information in the management database. Back up the database before continuing. ****************************************************************** Enter SmartCenter Server/main CMA IP address (Hit 'ENTER' for 'localhost'): Enter Administrator Name: Enter Administrator Password: Enter VSX cluster object name: Enter desired ClusterXL mode: HA-High Availability, LS-Load Sharing (HA LS): LS All modules must be in the 'Per VS State' mode to conclude this operation successfully. Use the command cpconfig on each module to verify compliance before continuing with the operation. When converting a cluster, there are two options for distributing the existing Virtual System(s) among cluster members: 1. Distribute all Virtual Systems so that each cluster member is equally loaded. 2. Set all Virtual Systems as Active on the same cluster member. After converting the cluster, the command vsx_util redistribute_vsls may be used to modify Virtual System distribution. Enter distribution option (1-2) [1]: 1 Converting the cluster to ClusterXL Load Sharing mode... The cluster was successfully converted to ClusterXL Load Sharing mode Installing new policy Policy installation finished successfully. Converting Cluster Type from ClusterXL Load Sharing to ClusterXL High Availability To convert the cluster type from ClusterXL Load Sharing to ClusterXL High Availability, do the following: 1. Run the command vsx_util redistribute_vsls to set all Virtual Systems to be Active on the same member (see the section vsx_util redistribute_vsls on page 167). 2. Run the command vsx_util convert_cluster to change the cluster type to ClusterXL High Availability. 166

167 CLI Commands When the convert_cluster command completes, there should be one active cluster member on which all Virtual Devices are in Active mode, and one Standby cluster member on which all Virtual Devices are in standby mode. The rest of the cluster members should be in Standby mode and the Virtual Devices on them in the Down state. 3. Reinitialize the members in the Down state with the commands cpstop and cpstart. vsx_util redistribute_vsls The vsx_util redistribute_vsls command provides the ability to modify the distribution of the Virtual Systems on members of a ClusterXL Load Sharing cluster. This includes the following options: 1. Redistribute Virtual Systems between members, and configure weights (if desired). 2. Set all Virtual Systems to be Active on the same member (High Availability-like priority lists). 3. Redistribute a single Virtual System (change the weight and cluster member priorities for a Virtual System) Note - Do not use the command vsx_util redistribute_vsls with options 1 or 2 when the cluster is under heavy load, since the redistribute process is a resource consuming task for the cluster. Moreover, be aware that as in any case of failover, there is zero connectivity down-time, but existing connections may be lost. This last point is relevant for option 3 as well. Chapter 7 ClusterXL Virtual System Load Sharing 167

168 CLI Commands Example: vsx_util redistribute_vsls ****************************************************************** Note: the operation you are about to perform changes the information in the management database. Back up the database before continuing. *************************************************************** Enter SmartCenter Server/main CMA IP address (Hit 'ENTER' for 'localhost'): Enter Administrator Name: Enter Administrator Password: Enter VSX cluster object name: There are three options for distributing Virtual System(s) among cluster members: 1. Distribute all Virtual Systems so that each cluster member is equally loaded. 2. Set all Virtual Systems as Active on the same cluster member. 3. Configure the priority list and weight of a single Virtual System. Enter redistribution option (1-3) [1]: 1 Each virtual system is assigned a weight to reflect its relative load. The virtual systems will be distributed between the cluster members such that the total weight is balanced between the cluster members. Would you like to assign weights for the virtual systems? (y n) [n]: n Redistributing the virtual systems... The virtual system(s) were successfully redistributed Installing new policy Policy installation finished successfully. Commands Modified for VPN-1 Power VSX The following commands have been renamed or otherwise modified. vsx_util add_member The vsx_util add_member command adds cluster members. It is identical to what was formerly known as vsx_util add, and its functionality has not changed. After executing the vsx_util add command, run the command vsx_util add_member_reconf (instead of vsx_util reconfigure, as was done in the past). 168

169 vsx_util remove_member CLI Commands The vsx_util remove_member command removes cluster members. It is identical to what was formerly known as vsx_util remove, and its functionality has not changed other than requiring connectivity with the remaining cluster members to succeed. vsx_util add_member_reconf The vsx_util add_member_reconf command is run after executing the vsx_util add_member command to configure the new cluster member. Its functionality is similar to that of the vsx_util reconfigure command, differing only in requiring connectivity with all cluster members to succeed. Chapter 7 ClusterXL Virtual System Load Sharing 169

170 CLI Commands 170

171 Chapter 8 Resource Control In This Chapter Introduction to Resource Control page 172 Virtual System Resource Quotas page 173 Architecture page 174 CLI Commands for Resource Control page

172 Introduction to Resource Control Introduction to Resource Control Resource Control for VPN-1 Power VSX provides the ability to manage the processing power of a VSX machine. As different Virtual Systems have different levels of criticalness, resource consumption, and security needs, the ability to manage and allocate available system resources by Virtual System can be an important component of a VSX deployment. By assigning a weight for each Virtual System, you can apportion the system s free CPU resources according to your deployment s specific needs. Virtual Systems of lower priority (lighter weight) can be guaranteed less CPU time, while busy or mission critical Virtual Systems can be assigned more. Resource Control thus provides the following benefits: By guaranteeing that each Virtual System will receive its minimum CPU allocation, no Virtual System can deny another access to the CPU. Any CPU resources that are not consumed by the Virtual Systems to which they are allocated are made available for use by other Virtual Systems, until they are needed. Note - Resource Control draws upon only the CPU resources available, after allocating whatever is necessary for other processes on the system. In this chapter, the concept of weighting Virtual Systems is discussed, as well as the architecture and configuration of Resource Control. 172

173 Virtual System Resource Quotas Virtual System Resource Quotas When activating Resource Control, each Virtual System is by default weighted equally (the system assigns each a weight of 10). Regardless of how many Virtual Systems are added to the VSX machine, each Virtual System is guaranteed to receive an equal portion of the machine s available CPU (again, this is after allocating CPU resources to other processes). Take for example a VSX machine with five Virtual Systems - each is guaranteed at least 20% of the machine s available CPU resources. Adding five more Virtual Systems to this machine would by default guarantee a minimum of 10% of the machine s available CPU resources to each Virtual System. However, if you want to assign a specific Virtual System more CPU resources than the others, you can do so by modifying its resource weight. A weight s relative value is determined by adding all of the weights assigned to the Virtual Systems on a single VSX machine and dividing the total by that weight. For instance, if Virtual System A is assigned a weight of 10 and the total weight that is configured on the machine is 100, Virtual System A will be guaranteed 10% of the available CPU resources. Similarly, if Virtual System A is on a VSX machine with a total weight of 40, it will be guaranteed 25% of the system s available CPU resources. By weighting some Virtual Systems more than others, you can give certain Virtual Systems priority over the machine s available CPU relative to others. Note - As long as a system has CPU resources available, each Virtual System receives its resources independent of its weight. When a system is under stress, however, the Virtual Systems weighted the lightest will be the first to drop packets. Chapter 8 Resource Control 173

174 Architecture Architecture Resource Control has two major components: The Resource Control Monitor keeps track of the CPU consumption of each Virtual System. It also provides real-time information on the present and average CPU consumption by the Virtual Systems on the VSX machine. The Resource Control Enforcer implements the Resource Policy. The Resource Control Enforcer utilizes the data collected by the Resource Control Monitor to implement the Resource Policy. Configuration File Configuration information for Resource Control is stored in the file $FWDIR/conf/resctrl. This file contains the following information: The default setting of the Resource Control Monitor (enabled/disabled) The default setting of the Resource Control Enforcer (enabled/disabled) Any change to the default weight assigned to any Virtual System. Each Virtual System is automatically assigned a weight of 10. To alter this weight, enter the Virtual System ID and the desired weight. A sample file is depicted here: #file format: #first line must be "monitoring enabled" or "monitoring disabled" #second line must be "enforcement enabled" or "enforcement disabled" #rest of the lines should contain weights for the virtual systems #vsid[1-511] weight[1-100] monitoring disabled enforcement disabled

175 CLI Commands for Resource Control CLI Commands for Resource Control The following commands are to be run on the VPN-1 Power VSX gateways. In This Section fw vsx resctrl enforce page 175 fw vsx resctrl monitor page 176 fw vsx resctrl traffic_stat page 176 fw vsx resctrl reset page 177 fw vsx resctrl start page 177 fw vsx resctrl stat page 177 fw vsx resctrl enforce Description Configures the status of the Resource Control Enforcer, and shows its current status. This command overrides the setting in the Resource Control configuration file, but does not survive reboot. Usage fw vsx resctrl enforce {enable disable show} Syntax Argument enable disable show Description Enables Resource Enforcer Disables Resource Enforcer Display whether Resource Enforcer is enabled or disabled Chapter 8 Resource Control 175

176 CLI Commands for Resource Control fw vsx resctrl monitor Description Configures the status of the Resource Control Monitor, and shows its current status. This command overrides the setting in the Resource Control configuration file, but does not survive reboot. Usage fw vsx resctrl monitor {enable disable show] Syntax Argument enable disable show Description Enables Resource Monitor Disables Resource Monitor Display whether Resource Monitor is enabled or disabled fw vsx resctrl traffic_stat Description Displays the number of received and dropped packets for a Virtual System. The counter can be reset via the command fw vsx resctrl reset. Usage fw vsx resctrl -w {vsid} traffic_stat Syntax Argument Description -w {vsid} Displays the statistics for the Virtual System specified in {vsid}. The default vsid is 0. Output [Expert@rescon:0]# vsx resctrl -w 0 traffic_stat Packets processed by virtual system 0: 8582 Packets dropped by virtual system 0: 0 176

177 CLI Commands for Resource Control fw vsx resctrl reset Description Resets the monitoring statistics of Resource Control. Usage fw vsx resctrl reset fw vsx resctrl start Description Initializes Resource Control. Use this command after changing the weights of the Virtual Systems in the configuration file. Usage fw vsx resctrl [-v] start Syntax Argument Description -v Verbose mode displays the configuration of the Resource Control Monitor and the Resource Control Enforcer during initialization. fw vsx resctrl stat Description Displays the CPU consumption for packet processing per-virtual System, and serves as an accurate indicator of the total CPU consumption by the Virtual Systems. The consumption of each Virtual Device is expressed as a percentage of the total CPU resources available Usage fw vsx resctrl [-u -q] stat Chapter 8 Resource Control 177

178 CLI Commands for Resource Control Syntax Argument Description -u Display information per-cpu (SMP only) -q Do not display header row Output without Arguments fw vsx resctrl stat Virtual Systems CPU Usage Statistics ==================================== Number of CPUs/Hyper-threading: 4 Monitoring active time: 14s ID Name Weight 1sec 10sec 1min 1hr 24hr* ========================+======+================================== 0 VSX2 N/A VSX2_vs VSX2_vsw N/A VSX2_vs ========================+======+================================== Total VS CPU Usage ===============================+================================== System CPU Usage Notes: - Monitoring has been active for less than 24 hours. Statistics are calculated only for monitoring active time. - The displayed statistics are the average usage on all CPUs. Notes For systems with more than one CPU, the time displayed is an average among all CPUs. To see the usage for each Virtual System per CPU, run the command vsx resctrl -u stat. Context 0 and Virtual Switches / Routers are not weighted because they use a special queue. Total VS CPU Usage reports the total CPU consumption of all VSX devices and processes (including Virtual Routers, Virtual Switches & VSX) from the total CPU capacity. System CPU Usage reports the total CPU consumption of the machine. 178

179 CLI Commands for Resource Control Output with Argument -u fw vsx resctrl -u stat Virtual Systems CPU Usage Statistics ==================================== Number of CPUs/Hyper-threading: 2 Monitoring active time: 14s ID Name Weight CPU 1sec 10sec 1min 1hr 24hr =============+========+=======+==================================== 0 rescon N/A CPU CPU AVG VS1 10 CPU CPU AVG VS2 20 CPU CPU AVG ======================+=======+==================================== Total VS CPU Usage CPU CPU AVG ======================+=======+==================================== System CPU Usage CPU CPU AVG Notes: - Monitoring has been active for less than 24 hours. Statistics are calculated only for monitoring active time. - The displayed statistics are the average usage on all CPUs. Chapter 8 Resource Control 179

180 CLI Commands for Resource Control 180

181 Chapter 9 Lightweight QoS Enforcement In This Chapter Overview page 182 Architecture page 183 QoS Features page 185 QoS Management page 187 User Interface page

182 Overview Overview Lightweight QoS Enforcement for VPN-1 Power VSX provides the ability to control the network quality of service in the VSX network environment. Lightweight QoS supports the Differentiated Services architecture and allows assigning different transmission characteristics to different classes of service. The major characteristics which are controllable by Lightweight QoS are latency and bandwidth allocation. Lightweight QoS is designed to provide QoS functionality with minimal impact on performance. Lightweight QoS works seamlessly with Check Point Performance Pack. The VSX network usually includes various types of traffic such as: Real-time traffic (e.g. VoIP) which requires low bandwidth, and is sensitive to latency (delays) and drops Traffic which is sensitive to latency but not to occasional drops High-volume, low-priority traffic which has a low sensitivity to latency and drops Other traffic which requires its own share of the bandwidth Without Lightweight QoS Enforcement, all these different traffic types are given equal priority on the VSX gateway and are handled in a simple FIFO (first in-first out) manner. When the VSX gateway is congested, all traffic types suffer the same degree of latency and drops. Also, high-volume traffic may starve other types of low-volume traffic. With Lightweight QoS, the special requirements of each traffic type can be met. For example: Latency-sensitive traffic will be given preference over other types of traffic Traffic which is sensitive to drops will suffer fewer drops than other types of traffic. High-volume traffic that consumes bandwidth will be limited during times of congestion. Note - Lightweight QoS requires the use of DiffServ-enabled routers to mark preferred traffic types with a special tag. The tag is the DSCP (DiffServ Code Point), which represents the six most significant bits of the IP header's TOS field, as described in RFC The VSX gateway should then be configured to give traffic with this tag the required priority. 182

183 Architecture Architecture Three major aspects of the Lightweight QoS architecture are: Differentiated Services support Inbound prioritization Policy with a global scope Differentiated Services Support Lightweight QoS provides basic support for Differentiated Services, an architecture for specifying and controlling network traffic by class so that certain types of traffic receive priority over others. The DiffServ architecture PHB's (per-hop behaviors). When marked packets arrive to the VSX machine, they are classified and prioritized according to their DSCP (DiffServ code-point) values. To enhance performance, Lightweight QoS does not mark packets with DSCP and does not change their Type of Service (ToS) values. Lightweight QoS instead relies on peripheral devices (namely routers) to mark packets with the appropriate ToS value. Inbound Prioritization While Differentiated Services support in routers is usually performed on outbound traffic, Lightweight QoS for VSX prioritizes traffic on the inbound side because, in VSX deployments, QoS is primarily governed by system resources, namely the CPU, and not by network bandwidth. To prevent the VSX machine from becoming a bottleneck in the network, prioritization is enforced when packets arrive at the VSX machine, and before CPU processing is assigned. Inbound prioritization allows an earlier control on the loss and delay rate. Policy with Global Scope To minimize the impact of QoS functionality on performance, Lightweight QoS is not performed per network-interface, but for the entire system. This means that if a portion of the bandwidth is allocated to a certain class of service, it will be enforced on all traffic entering the VSX machine, regardless of the specific interface from which this traffic originates. Chapter 9 Lightweight QoS Enforcement 183

184 Architecture Note - On multiple-cpu machines, enforcement is not performed system-wide, but executed per-cpu. This means that global enforcement is done separately on traffic processed by each CPU. 184

185 QoS Features QoS Features Two main features of Lightweight QoS are: Bandwidth-allocation Latency control Bandwidth Allocation Bandwidth allocation is performed by assigning different weights to different classes of service. A weight is the relative portion of the available bandwidth that is allocated to a class. Allocating bandwidth according to weights ensures full utilization of the line even if a specific class is not using all of its bandwidth. In such a case, the remaining bandwidth is divided among the remaining classes in accordance with their relative weights. Latency For some types of traffic, such as voice and video, it is necessary to minimize the latency (delay) of packets. Latency is controlled by defining special LLQ's (low-latency queues) classes. These classes are handled in a strict priority manner. LLQ packets are handled immediately upon arrival, and before packets that do not belong to LLQ classes. Lightweight QoS allows configuring multiple LLQ classes. In some cases, it may be necessary to define more than one Low Latency class, for example when different types of traffic have a different sensitivity to delays. In such cases, the class with the higher-sensitivity to delay receives a higher priority than the class with the lower sensitivity. Note - When LLQ classes are used, it is recommended that the expected traffic will not exceed a relatively small amount of the bandwidth. Although Lightweight QoS does not allow LLQ traffic to starve non-llq traffic, having too much LLQ traffic reduces the overall network quality of service and prevents Lightweight QoS from efficiently managing weighted bandwidth allocation. WRED RED (Random Early Drop) is a congestion avoidance mechanism for detecting and preventing congestions. It takes advantage of TCP's congestion control mechanism by randomly dropping packets during periods of congestion. This causes TCP senders to slow down their transmission, thus preventing high congestion. Chapter 9 Lightweight QoS Enforcement 185

186 QoS Features Lightweight QoS implements WRED (Weighted RED) in which packets are dropped according to their priority. WRED mostly affects traffic which is of low priority and which exceeds its weight. 186

187 QoS Management QoS Management To manage the network quality of service it is necessary to create and install a QoS policy. The QoS policy consists of a list of up to 15 classes of service. Each class is assigned certain traffic characteristics and DSCP values. The QoS policy is managed with the cpqos command. For cpqos command usage, see: See User Interface on page 189. Class of Service Definitions The definition of a class of service includes the following: Name. The class name is a unique identifier which identifies the class during configuration and when presenting statistics. Type. There are two types of classes: i. LLQ ii. Regular Regular classes are non-llq classes which can be assigned a weight Priority. Each class is assigned a unique priority value between 1 and 15. The priority value is effective in prioritizing LLQ classes and during congestion, when drops occur. Weight value. One or more DSCP values. The Differentiated Services Code Point Priority and LLQs If there are multiple LLQ classes, packets are handled in a strict priority-based manner. Packets from a class with a higher priority are handled before packets with a lower priority class. Priority and Drop Precedence Priority also determines the probability of drops. A class with a lower priority has a higher drop precedence during times of congestion. Chapter 9 Lightweight QoS Enforcement 187

188 QoS Management The class priority is not the only factor that determines if drops occur. Other factors affect drops, for example if the class is LLQ or if the class exceeds its assigned bandwidth. LLQ's are not immune to drops. Although LLQ's are processed as soon as they arrive (and thus have a lower drop rate), drops may occur if there are many LLQ classes or if a large portion of the incoming traffic is LLQ. 188

189 User Interface User Interface All user interactions with the QoS module are performed with the cpqos command. cpqos Command Usage Usage: cpqos - Manage the network quality of service. cpqos install - Install the QoS policy. cpqos uninstall - Uninstall the QoS policy. cpqos status - Check if policy is installed. cpqos class show - Show the QoS policy. cpqos class add <name> prio <val> type <llq reg> [weight <val>] dscp <val[,val2[,val3...]]> - Adds new class with specified name, priority (1-15), type (low-latency or regular), DSCP values (0-63 or "default"), and weight for classes of type "reg". cpqos class del <name> - Deletes specified class name. cpqos stats [-c] - Show statistics. [-c] will show statistics per CPU. For cpqos: All commands return a zero value for success and a non-zero value for failure Options and argument are case-sensitive For examples of various cpqos commands, see: Sample Differentiated Services Implementation on page 192. Commands cpqos class add This command adds a class with the following arguments: Argument name priority Value Unique name for the class Value between 1 and 15. A low value indicates a higher priority Chapter 9 Lightweight QoS Enforcement 189

190 User Interface Argument type weight dscp Value llq for low-latency classes or reg for regular, weighted classes This value is used only for classes of type reg. It determines the relative portion of the bandwidth that the class will receive in relation to other weighted classes. Valid values are between 0 and The DiffServ code-points assigned to the class. Multiple DSCP's can be specified, separated by commas, with no spaces between values. Values are in decimal (not binary format) with values from 0 to 63 or default. There can be only one class with a default DSCP. The default class is used for traffic without DiffServ marking (e.g. tos=0) or traffic with DSCP values that are not assigned to any other class. If no class is used as default, all 64 DSCP values must be assigned to the classes. A DSCP value cannot be assigned to more than one class. Note - Changes to the policy with cpqos class add are enforced only after the policy is installed. cpqos class del This command deletes the class of the specified name. Changes to the policy with cpqos class del are enforced only after the policy is installed. cpqos class show This command shows the classes defined in the QoS policy. cpqos install This command installs the previously created QoS policy. It also validates the overall integrity of the policy. Once installed, the policy remains installed even if the machine reboots. cpqos uninstall This command un-installs the previously installed QoS policy. If un-installed, the policy will not be installed again when the machine boots. 190

191 User Interface cpqos stats This command shows QoS statistics. cpqos stats prints a line of statistics for each of the defined classes. Each line includes the following data columns: Column rx tx drops Value Number of bytes that arrived to this class since the last time statistics were presented Number of bytes that were transmitted from this class since the last time statistics were presented Number of bytes that were dropped from this class since the last time statistics were presented Note: [-c] option shows statistics separately for each CPU Statistics values are byte-counts, not packet counts Statistics values are reset after each query. Statistics should be presented periodically with intervals less than 1 minute. It is recommended to use the watch command to periodically present the statistics. QoS Policy File The QoS policy file is qos_policy.c, located in the $FWDIR/database directory. The QoS policy file is created when the cpqos command is run for the first time. The QoS policy file should not be edited manually. Use cpqos class add/del to create entries. To maintain multiple QoS policies, rename qos_policy.c or copy it to another directory, and copy it back to $FWDIR/database/qos_policy.C when the policy needs to be enforced. QoS Default Configuration Default QoS configuration is set to uninstall (e.g. not enforced). Calling cpqos install or cpqos uninstall sets the default configuration after boot Chapter 9 Lightweight QoS Enforcement 191

192 User Interface Sample Differentiated Services Implementation This section provides a sample DiffServ implementation. It includes examples for configuration, monitoring and statistics. Sample Traffic Types Traffic Type Diamond Platinum Gold Silver Bronze Copper Meaning... Real-time traffic (e.g. VOIP) which requires low bandwidth and is sensitive to latency and drops. This traffic is usually assigned to the EF (Expedited-Forwarding) PHB (Per Hop Behavior). Real-time traffic with low bandwidth which is less sensitive to latency and drops than Diamond. Traffic which is sensitive to drops Traffic which is less sensitive to drops than Gold. Various types of traffic which require bandwidth allocation. This traffic is usually assigned to the Best-Effort PHB. High-volume traffic with a tendency to hog the bandwidth Configuration Guidelines Your QoS policy should apply these guidelines: Diamond and Platinum classes should be defined as LLQ so they will have a lower latency than other classes Diamond should receive a higher priority then Platinum so it have even less latency and drops Gold should receive a higher priority than Silver so it will have fewer drops Copper bandwidth consumption should be limited to about 10% of the available bandwidth during periods of congestion Other traffic should receive about 45% of the bandwidth when the traffic load is high. 192

193 Configuration Examples User Interface 1. The following examples of the cpqos class add command creates classes for traffic of various types: cpqos class add Diamond type llq prio 1 dscp 46 cpqos class add Platinum type llq prio 2 dscp 32 cpqos class add Gold type reg prio 3 weight 100 dscp 26 cpqos class add Silver type reg prio 4 weight 100 dscp 28 cpqos class add Bronze type reg prio 5 weight 200 dscp default cpqos class add Copper type reg prio 15 weight 50 dscp 10,12,14 Chapter 9 Lightweight QoS Enforcement 193

194 User Interface 2. Monitoring example. The following command lists the previously defined classes: cpqos class show class: Diamond priority: 1 type: llq weight: 0 DSCPs: 46 class: Platinum priority: 2 type: llq weight: 0 DSCPs: 32 class: Gold priority: 3 type: reg weight: 100 DSCPs: 26 class: Silver priority: 4 type: llq weight: 100 DSCPs: 28 class: Bronze priority: 5 type: llq weight: 200 DSCPs: default class: Copper priority: 15 type: reg weight: 50 DSCPs: 10,12,14 194

195 User Interface 3. Statistics example. The following command lists statistics for the previously defined classes: cpqos stats class prio type weight rx tx drops Diamond 1 llq Platinum 2 llq Gold 3 reg Silver 4 reg Bronze 5 reg Copper 15 reg From this statistical output, it is apparent that: In the Diamond class there were no drops. In the Platinum class there were a few drops, even though less traffic arrived classed as Platinum than did as Diamond. In the Gold class there were fewer drops than from the Silver class. In the Bronze class there were twice as many bytes transmitted than in the Silver and Gold classes, and four times as many bytes than there were in the Copper class. Most packets in the Copper class were dropped. Chapter 9 Lightweight QoS Enforcement 195

196 User Interface 196

197 Chapter 10 VSX Diagnostics and Troubleshooting In This Chapter Introduction page 198 Troubleshooting VSX page

198 Introduction Introduction This chapter describes a basic diagnostic procedure that should be followed in the event of your encountering a problem on your VSX gateway/cluster. This diagnostic routine will assist you in determining the source of the problem. Thereafter, the chapter describes known problems and solutions. These problems are usually caused by misconfiguration of the VSX gateway/cluster, or by various networking problems affecting the VSX gateway/cluster s behavior. The problems are listed according to the order in which you may encounter them. Before reading and following a certain workaround, make sure you've read all the previous workarounds, and that those steps in the configuration were successful. In some of the cases, one initial problem can cause problems in later stages of the configuration. For that reason, it is important to find the root of the problem when you are trying to understand what went wrong. 198

199 Troubleshooting VSX Troubleshooting VSX What to do if you suspect there s a problem If you suspect that there is a problem with your VSX configuration there are certain diagnostic procedures that you can follow to determine the source. These procedures utilize various commands that are explained in Command Line Reference on page Perform a basic configuration check for each gateway/cluster member by running: fw vsx stat -v From this you will: a. account for all Virtual Systems (that none are missing from the configuration) b. see all Virtual Systems are active c. see all Virtual Systems have a correct security policy d. see if you have sufficient licenses. 2. Perform a check on the status for each gateway/cluster member by running: cphaprob state 3. If you suspect a Virtual System has connectivity problems: a. Run: fw vsx set to set the context to a specific Virtual System. b. Run fw [-vs vsname or vsid] getifs to get the interface list for the specific Virtual System. c. Examine connectivity status using standard Operating System commands and tools such as: ping, traceroute, tcpdump, telnet, ip route, ftp, etc. Some of these are run according to context (that is routing, source and destination IP addresses). In addition system-specific checks can be made on the network. For Linux/SecurePlatform, run: ip route and ip link If these tests indicate that all interfaces and routers have connectivity, and appear to be functioning correctly, you should monitor the passage of packets through the system. Chapter 10 VSX Diagnostics and Troubleshooting 199

200 Troubleshooting VSX 4. Run fw monitor -vs [vsname or vsid] to capture details of packets at multiple points. This may return multiple reports on the same packet as it passes various capture points. This will not report on Virtual Routers, except for packets destined to the External Virtual Router. Failed to establish Trust with VSX gateway during the VSX Creation Wizard Problem description When creating a VSX gateway/cluster for the first time, trust cannot be established with the gateway(s). The MDG/SmartDashboard gives an error message: 200

201 Troubleshooting VSX Certificate cannot be pushed. Connection error with wait agent. Table 10-1 Failed to Establish Trust with the VSX gateway during the VSX Creation Wizard Common Reasons for Failure Check that you have network connectivity between the gateway(s) and the CMA/SmartCenter by pinging from the VSX system to the IP of the CMA or the SmartCenter. (A ping from the CMA/SmartCenter to the VSX system will not work because of the default security policy installed on the VSX gateway/cluster.) Make sure the context is vrf 0 first. Check that all the Check Point processes on the VSX gateway(s) are up and running by running cpwd_admin list and making sure each line has a non-zero value in the PID field. Check that the CPD process is listening to the trust establishment port, by running netstat -an grep on the VSX gateway(s), and checking that output looks like this: tcp : :* LIST EN How to Resolve Each Problem On all relevant machines, re-check the cables, routes, IP addresses and any intermediate networking devices (routers, switches, hubs, and so on) between the management and the gateway(s). If the gateway(s) has just rebooted, the Check Point processes might still be coming up. If this is not the case, and you are using Crossbeam X40, make sure you have executed the application start command. (For more information refer to the Crossbeam documentation.) Make sure that you executed the cpconfig command on the gateway(s), and that it finished successfully. Chapter 10 VSX Diagnostics and Troubleshooting 201

202 Troubleshooting VSX After pressing Get Configuration button, Sync networks don t match Problem description After pressing the Get Configuration button during the VSX Cluster Creation wizard, the MDG/SmartDashboard gives an error message saying that the Sync network doesn't match. Table 10-2 After pressing the Get Configuration button the Sync networks do not match Common Reasons for Failure This message indicates that the IP addresses on the sync interface of the members are not valid. The Addresses must be unique for each member, must belong to the same network and must have the same Netmask. The interface that is used for Sync was defined during the initial configuration phase on the VSX gateway. How to Resolve Each Problem Change the IP address/netmask of the Sync interface, restart the VSX gateway(s), and press the Get Configuration button again. Failed to install policy on the VSX gateway during VSX Creation Wizard Problem description At the end of the VSX creation wizard, there is a failure installing the default policy on the VSX gateway. Error: Default policy installation failed on VSX. Install policy manually using SmartDashboard. 202

203 Troubleshooting VSX Table 10-3 Failed to Establish Trust with the VSX gateway during the VSX Creation Wizard Common Reasons for Failure Missing license for ClusterXL on the CMA/SmartCenter - If you are using a SecurePlatform Cluster, you must have a valid ClusterXL license on the CMA/SmartCenter for each VS defined (including the VSX gateway and the Virtual Router that leads to the external network). Run cplic check cluster-u or cplic check cluster-1 on the CMA/SmartCenter to make sure you have a ClusterXL license. If you are using Provider-1, refer to the Provider-1 documentation regarding the mdsenv command, which should be executed before running CMA-specific commands. Missing license for VSX gateway/cluster on the gateway(s). Run fw vsx stat on all gateways, and make sure that the output says Number of Virtual Systems allowed by license: is greater than 0. Time or time zone mismatch between the management and the gateway(s). For proper operation of the Secure Internal Communication, the time, date and time zone between the management and gateway must be set correctly. Execute the /bin/date -u command on all machines, to obtain the correct UTC/GMT time. The machines can be in different time zones, as long as their UTC/GMT times match. How to Resolve Each Problem Obtain a ClusterXL license, and attach it on the CMA/SmartCenter. You must have one valid ClusterXL license for each VS defined on the CMA/SmartCenter (including the VSX gateway and EVR). Obtain a VSX license for each VSX gateway and attach it to the gateway(s). Change the time, date and time zone on the management and/or the gateway(s) so that their UTC/GMT times match. Refer to the documentation of the Operating System vendor for the exact commands needed to accomplish this. Chapter 10 VSX Diagnostics and Troubleshooting 203

204 Troubleshooting VSX Failed to establish trust with newly created Virtual System/Virtual Router Problem description When creating a new Virtual System using the Provider-1/SmartDashboard, trust cannot be established with it. Table 10-4 Failed to establish trust with a newly created Virtual System/Virtual Router Common Reasons for Failure Time or time zone mismatch between the management and the gateway(s). For proper operation of the Secure Internal Communication, the time, date and time zone between the management and gateway must be set correctly. Execute the /bin/date -u command on all machines, to obtain the correct UTC/GMT time. The machines can be in different time zones, as long as their UTC/GMT times match. How to Resolve Each Problem Change the time, date and time zone on the management and/or the gateway(s) so that their UTC/GMT times match. Refer to the documentation of the Operating System vendor for the exact commands needed to accomplish this. 204

205 Troubleshooting VSX Internal host behind Virtual System cannot ping internal IP Address of Virtual System Problem description After defining a Virtual System with an internal VLAN interface, an internal host on that VLAN cannot ping the internal IP address of the Virtual System. Table 10-5 An internal host behind a Virtual System cannot ping the internal IP address of the Virtual System Common Reasons for Failure A policy allowing the communication was not installed on the Virtual System. Note that after creating a Virtual System, it has a default policy that blocks all traffic. There is the wrong VLAN configuration on the layer 2 switch, or there is a physical cable problem. There is incorrect routing on the surrounding routers or hosts. There is an incorrect IP address or Netmask defined on the VLAN interface of the Virtual System. How to Resolve Each Problem Install a policy on the Virtual System that enables the traffic. Check with the SmartView Tracker that the Virtual System is allowing the traffic. Recheck the configuration on the switch. Make sure that VLAN tag configured on the switch is the one used for the VLAN interface on the Virtual System. Recheck the cables, and make sure that you have plugged the cable from the switch to the correct port on the VSX machine(s). Recheck the routing tables on intermediate routers and hosts. You can use tcpdump on the relevant VLAN interface on the VSX gateway(s) to check that the traffic is arriving at and leaving the VSX machine. Recheck the IP address and the Netmask that you have assigned to the internal VLAN interface of the Virtual System. Chapter 10 VSX Diagnostics and Troubleshooting 205

206 Troubleshooting VSX Internal host behind Virtual System cannot ping external IP address of Virtual System Problem description An internal host cannot ping the internal and external IP address of its Virtual System, and cannot ping external hosts. Table 10-6 An internal host behind a Virtual System cannot ping the external address of the Virtual System Common Reasons for Failure A policy allowing the communication was not installed on the Virtual System. Note that after creating a Virtual System, it has a default policy that blocks all traffic. The routing table on the host or on intermediate routers doesn't have a route for the external IP of the Virtual System. How to Resolve Each Problem Install a policy on the Virtual System that enables the traffic. Check with the SmartView Tracker that the Virtual System is allowing the traffic. Re-check the routing tables on the host and intermediate routers and make sure the default gateway is properly defined. 206

207 Troubleshooting VSX Internal host behind Virtual System cannot ping an external host Problem description An internal host can ping the internal and external IP addresses of its Virtual System, but cannot ping external hosts connected. Table 10-7 An internal host behind a Virtual System cannot ping an external host Common Reasons for Failure Connectivity problems on the External Virtual Router (EVR). The EVR might have connectivity problems to the external hosts/routers due to bad network cables, or other link-level network problems. There are routing problems on the EVR. The EVR might not have correct routes for packets destined to the IP addresses of the external hosts. There are incorrect routes on external hosts and routers. The external hosts or routers do not have the correct routes telling them where to send packets destined for the IP address of the internal host via the IP address of the EVR. Routes not propagated from the Virtual System to the EVR. For the EVR to know how to route packets destined to the IP address of the internal hosts, the relevant route on the Virtual System must be propagated. How to Resolve Each Problem Check whether the EVR can ping the host. Recheck the configuration on the switch, recheck the cables, and make sure that you have plugged the cable from the switch to the correct port on the VSX machine(s). Review the routes defined on the EVR object in the MDG/SmartDashboard. Make sure that the EVR has the correct routes to reach the external hosts. Review the routes on the external hosts and intermediate routers. The adjacent external router should send all traffic destined to the internal IP addresses of the Virtual System via the IP address of the EVR. If you are using a VSX Cluster, the traffic should be sent via the shared cluster IP address of the EVR. Edit the relevant interface or route on the Virtual System, and select Propagate routes to adjacent Virtual Routers. Chapter 10 VSX Diagnostics and Troubleshooting 207

208 Troubleshooting VSX 208

209 Chapter 11 Command Line Reference fw getifs Description Usage Gets Firewall driver interface list for designated Virtual System. The default gives the VSX gateway. fw [-vs vsid vsname] getifs Syntax Argument [-vs vsid vsname] Description Gets Firewall driver interface list for a specific Virtual System. Using this option you can specify a Virtual System by name or by ID. The default gives the VSX gateway. Return Value Example Output 0 (zero) indicates successfully executed, any other response indicates failure. The fw getifs command shows all interfaces to which the Firewall is attached, their IP address, and network mask. fw getifs localhost vnd localhost eth localhost eth localhost sdp localhost int localhost mgmt localhost sync localhost wrpj localhost wrpj

210 fw monitor Description Usage Built-in tool for capturing network packets at multiple capture points within the VSX system. This Command Line Reference gives only the syntax specific to VSX gateway/cluster. fw monitor [-v vsid] Syntax Argument [-v vsid] Description Selects, by ID only, the specific Virtual System on which packets should be captured. The default gives the VSX gateway. Return Value Comments Example Output 0 (zero) indicates successfully executed, any other response indicates failure. Cannot show packets forwarded by a Virtual Router, but can show packets destined to the Virtual Router itself. The fw monitor -v 2 -e accept ip_p=6 command shows all TCP packets that pass through Virtual System 2. fw monitor monitor: getting filter (from command line) monitor: compiling monitorfilter: Compiled OK. monitor: loading monitor: monitoring (control-c to stop) ext:i[78]: > (UDP) len=78 id=0 UDP: 137 -> 137 ext:i[78]: > (UDP) len=78 id=0 UDP: 137 -> 137 ext:i[78]: > (UDP) len=78 id=0 UDP: 137 -> 137 ext:i[78]: > (UDP) len=78 id=0 UDP: 137 -> 137 ext:i[211]: > (UDP) len=211 id=0 UDP: 138 -> 138 monitor: caught sig 2 monitor: unloading 210

211 fw tab Description Shows state tables for a specific Virtual System. State tables are used to keep state information which the Virtual System needs in order to correctly inspect packets. Usage fw [-vs vsid vsname] tab [-t name] [...] Syntax Example Argument fw -vs 1 tab -t connections Description [-vs vsid vsname] Shows state tables for a specific Virtual System. Using this option you can specify a Virtual System by name or by ID. The default gives the VSX gateway. -t name Shows table for the specified Virtual System. [...] Arguments as defined for non-vsx machines. Chapter 11 fw tab 211

212 Output fw -vs 3 tab -t connections localhost: connections dynamic, id 8158, attributes: keep, sync, expires 25, refresh, limit 15000, hashsize 32768, kbuf , free function 90adc508 0 < , 0a125364, 00008a69, 0a12ae0a, , ; 0001c001, , , 00000e10, , 3f7c2df6, , , b6, ffffffff, ffffffff, ffffffff, ffffffff, , , , , , 3bcd7000, , , ; 3596/3600> < , 0a12ae0a, , 0a125364, 00008a69, > -> < , 0a125364, 00008a69, 0a12ae0a, , > ( ) < , 0a125364, 00008a6c, 0a12ab0a, , ; 0001c001, , , 00000e10, , 3f7c2e4b, , , b6, b, b, ffffffff, ffffffff, , , , , , 1fce4000, , , , , ; 3581/3600> < , 0a12ac0a, , 0a125364, 00008a6b, > -> < , 0a125364, 00008a6b, 0a12ac0a, , > ( ) < , 0a125364, 00008a6b, 0a12ac0a, , ; 0001c001, , , 00000e10, , 3f7c2e40, , , b6, ffffffff, ffffffff, ffffffff, ffffffff, , , , , , 15cdb000, , , , , ; 3581/3600> < , 0a12ad0a, , 0a125364, 00008a6a, > -> < , 0a125364, 00008a6a, 0a12ad0a, , > ( ) < , 0a12ab0a, , 0a125364, 00008a6c, > -> < , 0a125364, 00008a6c, 0a12ab0a, , > ( ) < , 0a125364, 00008a6a, 0a12ad0a, , ; 0001c001, , , 00000e10, , 3f7c2df0, , , b6, ffffffff, ffffffff, ffffffff, ffffffff, , , , , , 23cd9000, , , , , ; 3596/3600> fw vsx fetch Description Usage Usage Usage Fetches and executes configuration files. fw vsx fetch [-v -q -s] [-f conf_file] [local] fw vsx fetch [-v -q] -C command fw vsx fetch [-v -q -c -n -s] [management] [local] 212

213 Syntax Return Value Example Output Argument Description -c Cluster mode. -n Does not run local.vsall if VSX configuration, fetched from management, is up-to-date. -s Concurrent fetches for multi-processor environment. -q Quiet output. Nothing is displayed except the summary lines at the time of command startup and finish. -v Gives verbose (detailed) information. -f conf_file Fetches NCS commands configuration file instead of the default local.vsall. local Reads local.vsall configuration file from $FWDIR/state/local/vsx and executes the NCS script. management Fetches local.vsall from management, replace and run it. -C command Runs specific selected NCS command. 0 (zero) indicates successfully executed, any other response indicates failure. The fw vsx fetch command fetches the most current configuration files from the Main CMA, and applies it to the VSX gateway. fw vsx fetch Fetching VSX Configuration From: Local VSX Configuration is Up-To-Date. Cleaning un-used Virtual Systems entries (local.vskeep). Purge operation succeeded. Fetching Virtual Systems configuration file (local.vsall). SecureXL device has been enabled for vsid 1 SecureXL device has been enabled for vsid 2 SecureXL device has been enabled for vsid 3 Virtual Systems configuration file installed successfully Chapter 11 fw vsx fetch 213

214 fw vsx fetchvs Description Usage Syntax Comments Example Output Retrieves a specific Virtual System configuration file based on the information stored locally on the gateway. fw vsx fetchvs [-v -q] [VSname vsid] Argument Description -q Quiet output. Nothing is displayed except the summary lines at the time of command startup and finish. -v Gives verbose (detailed) information. VSname vsid Selects specific Virtual System by name or by ID. 0 (zero) indicates successfully executed, any other response indicates failure. The fw vsx fetchvs California command recreates Virtual System - California fw vsx fetchvs 2 SecureXL device has been enabled for vsid 2 fw vsx get Description Usage Output Gets current context of shell script. fw vsx get fw vsx get Current context is: Virtual System (fas_sucar_evr:1) vrf: 1. fw vsx set Description Usage Sets current context to selected Virtual System. fw vsx set [VSname vsid] Syntax Argument VSname vsid Description Selects specific Virtual System by name or by ID. The default gives the VSX gateway. The only exception is when changing context to the context of the VSX gateway. Use the vsid ID (0) instead of the name. 214

215 Return Value Comments 0 (zero) indicates successfully executed, any other response indicates failure. Can be used to check the connectivity of a specific Virtual System to other physical or Virtual Routers. The command line prompt also displays the current context. Example fw vsx set 2 Output fw vsx set 3 Context is set to Virtual System (fas_sucar_vs_620:3) vrf 3. fw vsx stat Description Usage Syntax Displays VSX status information. fw vsx stat [-v] [-l] Argument Description -v Gives verbose (detailed) information - shows the status table in full. -l Gives a detailed list of all the virtual systems. Chapter 11 fw vsx stat 215

216 Output VSX Gateway Status ================== Name: noor Management IP Address: Security Policy: Standard Installed at: 10Apr :31:25 SIC Status: Trust Number of Virtual Systems allowed by license: 0 Virtual Systems [active / configured]: 2 / 2 Virtual Routers and Switches [active / configured]: 1 / 1 Virtual Devices Status ====================== ID Type & Name Security Policy Installed at SIC Stat W noor_switch1 <Not Applicable> N/A Trust 2 S noor_vs1 Standard 10Apr :31 Trust 3 S noor_vs2 Standard 10Apr :31 Trust Type: S - Virtual System, B - Virtual System in Bridge mode, R - Virtual Router, W - Virtual Switch,? - Information unavailable. fw vsx start_dr Description Usage Output Starts dynamic routing on Virtual Systems / Routers previously configured fw vsx start_dr [Expert@test:0]# vsx start_dr Successfully activated dynamic routing on all Virtual Systems/Routers [Expert@test:0]# fw vsx sic reset Description Usage Resets the SIC for the Virtual System fw vsx sic reset {vsname vsid} 216

217 Output fw vsx sic reset 1 resetting SIC for VSID 1 [Expert@gateway:0]# NOTE: On the management server, use the cpca_client revoke_cert command to cancel the old certificate. In SmartDashboard, open the Virtual System object for editing. Click OK. This action creates a new certificate, and transfers the certificate to the gateway. Chapter 11 fw vsx sic reset 217

218 218

219 Appendix Aspects of VSX Networking A In This Appendix Overview page 220 Supporting Switched Networks page 221 IP Routing page 223 Dynamic Routing Scenarios page

220 Overview Overview Provider-1/SiteManager-1 provides tight integration within the existing network infrastructure. This is achieved via: Virtual Systems in bridge (layer-2) mode and routing (layer-3) mode Dynamic routing (BGP, OSPF, RIP) and multicast (IGMP, PIM-SM, PIM-DM) support per Virtual System/Virtual Router Interoperability with common switch environments and protocols, for example STP, PVST+ Layer-2 and Layer-3 Virtual Systems do not disrupt existing dynamic routing protocols, multicast protocols, or loop detection protocols associated with switches, such as STP and its variants (PVST+). By fully and transparently supporting a wide range of routing and switching protocols, VSX connects to the core network in a way that provides flexibility, granularity, and autonomy. 220

221 Supporting Switched Networks Supporting Switched Networks VPN-1 Power VSX fully supports STP control messages on the native VLAN, the default VLAN associated with a 802.1q trunk interface. For MSTP environments, where multiple instances of STP are run to discover the VLAN s active path, control information conveyed on the VLAN level (broadcast domain) is also fully supported. A simplified core network and protocols in use on the LAN are shown in Figure A-1: Figure A-1 Core network and protocols on the LAN In Figure A-1, 802.1q VLAN trunks connect the switches and the VSX cluster members. STP runs between the switches to determine the active VLAN path. A simplified core network and protocols in use are shown in Figure A-2: Appendix A Aspects of VSX Networking 221

222 Supporting Switched Networks Figure A-2 Core network protocols on the WAN In Figure A-2, OSPF is shown running between the routers and PVST+ running on the LAN. 222