Print Download PDF Send Feedback

Previous

Next

Deploying VSX

In This Section:

Introduction

Internal Network Deployment Strategies

Organizational Deployment Strategies

Migrating between Servers with Different Interface Names

This chapter presents deployment concepts and strategies for exploiting VSX virtualization and its unique feature set. This presentation is divided into two sections as follows:

Introduction

This chapter presents deployment concepts and strategies for exploiting VSX virtualization and its unique feature set. This presentation is divided into two sections as follows:

Internal Network Deployment Strategies

Security Gateway Deployment on a Physical Network

In large physical network deployments, multiple Check Point security products, such as Security Gateways or UTM-1 Edge appliances, are deployed to protect various network segments.

Each Security Gateway physically connects to its own internal protected network as well as to a router for access to other internal networks and the Internet.

VSX Virtual System Deployment Strategies

In a VSX environment, Virtual Systems protect internal networks, much in the same manner as Security Gateways and other Check Point products in a physical network. This section presents several sample VSX deployments using Virtual Systems to protect internal networks.

Each example highlights certain VSX features. In a real-world deployment, you can combine several of the concepts presented in these examples to create a powerful network security solution for complex enterprise environments.

Physical Internal Interface for Each Virtual System

The figure below shows a basic VSX configuration where Virtual Systems connect directly to protected internal networks using physical interfaces on the VSX Gateway. A Virtual Switch provides connectivity between internal networks, as well as to the Internet. This deployment is simple to provision and is suitable for protecting a small, fixed quantity of internal networks.

The main disadvantage of this deployment is that each protected network requires its own dedicated physical interface on the VSX Gateway. Obviously, this deployment is not suitable for networks that require many Virtual Systems.

Virtual Systems with Internal VLAN Interfaces

In this deployment example, Virtual Systems connect to internal protected networks using VLAN interfaces. The VSX Gateway connects to a VLAN switch via an 802.1q VLAN trunk, which is an aggregate of all VLANs passing through it.

This deployment option is appropriate for environments where many Virtual Systems protect many internal networks with a single VSX Gateway or cluster. The use of VLANs provides scalability as well as granularity, allowing administrators to provision additional Virtual Systems and protected networks quickly and without impacting the existing IP address structure.

Internal Virtual Router with Source-Based Routing

This deployment scenario enables Virtual Systems to connect to protected networks using a single physical interface without VLAN technology. The Virtual Router uses source-based routing rules to forward traffic to the appropriate Virtual System based on its source IP address.

In a VSX deployment with each Virtual System connected to a single Virtual Router: You can configure the Virtual Router to use source-based routing rules, to forward traffic to the appropriate Virtual System, based on the source IP address.

Notes to this scenario:

The Routing Concept section provides a detailed discussion of routing options in VSX environments.

Virtual Systems in the Bridge Mode

A Virtual System in the bridge mode implements native layer-2 bridging instead of IP routing. This allows network administrators to easily and transparently deploy a Virtual System in an existing network topology without reconfiguring the existing IP routing scheme. The figure below, shows a scenario where each Virtual System in the Bridge Mode protects a VLAN switched network.

Bridge Mode deployments are particularly suitable for large-scale clustered environments.

Cluster Deployments

This section presents several examples of cluster deployments that highlight important VSX features. The discussion is intended to introduce these features as they relate to deployment strategy. Refer to the conceptual discussion of cluster deployments section for more information.

Active/Standby Bridge Mode

The Active/Standby Bridge Mode provides path redundancy and loop prevention, while offering seamless support for Virtual System Load Sharing and overcoming many Spanning Tree Protocol (STP) Bridge mode limitations.

VLAN Shared Interface Deployment - Active/Standby Bridge Mode

In this scenario, each individual member connects to pair of redundant switches via a VLAN trunk. All Virtual Systems in a given member share the same VLAN trunk.

When using the Active/Standby Bridge Mode in a High Availability deployment, VSX directs traffic to members according to predefined priorities and member status. In VSLS deployments, VSX distributes the traffic load amongst members according to a set of predefined preferences.

This deployment scenario is appropriate for very large enterprises.

Virtual Systems in Bridge Mode

A three layer hierarchical model is appropriate for large, high-traffic network environments. It contains a mixture of components as described below:

  1. A core network, comprised of high-speed backbone switches directs traffic to and from the Internet and other external networks.
  2. A distribution layer, comprised of routers, provides connectivity between the core and the access layer.
  3. An access layer, comprised of redundant LAN switches, forwards traffic to and from internal networks.

Use Active/Standby Bridge Mode with VSX to enforce the security policy over the distribution layer.

The routers direct external, "dirty" traffic (typically from the Internet) to the appropriate Virtual System via a segregated VLAN. Filtered, "clean" traffic exits the Virtual System through a separate segregated VLAN back to the routers and on to internal destinations.

This deployment scenario is appropriate for very large enterprises.

Virtual System Load Sharing (VSLS)

VSX clusters can efficiently balance network traffic load by distributing active Virtual Systems amongst cluster members. This capability is known as Virtual System Load Sharing (VSLS).

In a deployment scenario with three cluster members, each with three Virtual Systems: an equalized Load Sharing deployment might have one active Virtual System on each cluster member.

A different member hosts the active peer for each Virtual System. This distribution spreads the load equally amongst the members. When you create a Virtual System, VSX automatically assigns standby and backup states to the appropriate peers and distributes them among the other cluster members.

In the event that a cluster member fails, VSLS directs traffic destined to affected Virtual Systems to their fully synchronized standby peers, which then become active. At the same time, a backup Virtual Systems switches to standby, and synchronizes with the newly active Virtual System.

In the event that an individual active Virtual System fails, it immediately fails over to its standby peer and one of its backup peers becomes the standby, synchronizing with the newly active peer.

Organizational Deployment Strategies

This section presents deployment scenarios for different types of large organizations and illustrates how VSX provides security both internally and at the perimeter. The discussion covers the following types of organizations:

Enterprise Deployments

Large enterprise network environments typically contain a wide variety of diverse networks, distributed over multiple locations around the world. These networks often have differing security and access requirements for various departments and branches. The ability to centrally manage network security while maintaining throughput is a critical requirement.

Core Network Security

Many Enterprise environments are based on core networks. Situated adjacent to core network backbone switches, VSX protects the internal network by providing security at layer-2, layer-3 or both. VSX communicates with the core network using the existing infrastructure. With Virtual Systems in the Bridge Mode, VSX can protect departmental networks, while simultaneously preventing network segmentation. In this case, switches are located at the entrance to each department's network.

VSX ensures connectivity between the core network and the Internet or external networks, while providing perimeter security. Security can be configured on a per VLAN basis.

Dynamic Routing

In an enterprise network with dynamic routing protocols (OSPF/BGP), VSX secures the DMZ services, VPN peers, Domains and partner networks.

In this example, BGP neighbor updates in the routed core network are selectively redistributed to application networks. OSPF provides connectivity between Virtual Routers, Virtual Systems, the core network and application networks.

Perimeter Security

For example, security is enforced on each VLAN. The OSPF and BGP Dynamic routing protocols provide connectivity to multiple security zones along the perimeter.

Notes to this scenario:

Managed Service Providers Using Multi-Domain Security Management

Managed service providers give connectivity and security services for Domain networks. Some of these Domains require remote access capabilities. In this service oriented environment, VSX and Multi-Domain Security Management provide central management and make connectivity and security easier, without affecting the existing IP topology.

In this scenario, a VSX cluster is in a Point of Presence (POP) deployment for a service provider. VSX consolidates hardware for the service provider and ensures privacy and secure connectivity solutions (VPN) for users. This scenario is appropriate for High Availability and Virtual System Load Sharing cluster modes.

VSX and Multi-Domain Security Management provide a centralized, granular provisioning system for a number of Domains. Applications and services are separated by discrete Virtual Systems. Access to these services and applications is based on need.

Scenario:

Item

Description

1

Internet. Routers are between the VSX cluster members and the Internet.

2

VSX cluster. One member handles the Local Exchange and another handles server traffic of different Domains.

3

Core IP VPN Network.

4

Multi-Domain Security Management at the Network Operation Center monitors POP and connects to VSX Gateway. The Multi-Domain Log Server in the NOC collects data for each Domain and stores the logs in separate private databases.

5

Multi-Domain Security Management at the NOC and the VSX Gateway make the Local Exchange.

6

Domain A web servers.

7

Domain B DMZ.

8

Domain C mail servers.

9

PE Router.

10, 11, 12

Domain A, B, and C. Each Domain manages its own security and cannot define Virtual Systems or other network components. Domains have secure VPN connectivity.

Data Centers

Data center providers supply external hosting services for Domain servers and databases. The service typically includes infrastructure, connectivity, and security for multiple Domains.

For example, you can have a scenario such as:

To provide network security and management, the data center provider deploys a VSX Gateway with one Virtual System for each Domain.

This scenario offers a cost effective scalability solution for network expansion by means of remote connectivity. In this example, a VPN connection between a Domain Virtual System and a UTM-1 Edge device protecting a remote network, integrates that network into the MPLS core. Similarly, a Virtual System can provide access for individual remote users who connect intermittently.

Data Centers in an Enterprise

This example scenario illustrates how VSX provides security management for enterprise data centers. By assigning layer-2 connections to Virtual Systems, VSX reduces the number of physically managed devices within a data center while providing the same high level of security.

For example, a VSX Gateway allows authorized users to access data center resources. The objective here is to protect shared resources with differing access permissions and security requirements, while implementing network granularity.

For example, one Virtual System protects databases against SQL vulnerabilities. Another Virtual System protects Web Servers using IPS. When new applications and services are added to the enterprise data center, new Virtual Systems are easily created to secure them according to their specific requirements.

Migrating between Servers with Different Interface Names

Check Point VSX-1 appliances use different interface names than Open Server platforms (Gaia, Linux). When migrating an Open Server VSX Gateway or cluster to a VSX-1 appliance, you must use the vsx_util change_interfaces command to change the appliance interface names.

The vsx_util change_interfaces command command contains a Management Only option that allows you to change the interface names on the management server (Security Management Server or Multi-Domain Security Management Domain Management Server) only. You then use the vsx_util reconfigure command to push the updated configuration to VSX Gateways or cluster members.

To migrate a VSX Gateway or cluster to a VSX-1 appliance:

  1. Close SmartDashboard for the Security Management Server and/or Multi-Domain Security Management Domain Management Servers.
  2. On the management server, enter the Expert Mode and run the vsx_util change_interfaces command.
  3. When prompted, enter the Security Management Server, or Multi-Domain Security Management Main Domain Management Server IP address.
  4. When prompted, enter the administrator name and password as prompted.
  5. When prompted, enter the VSX cluster object name.
  6. When prompted, select the Management Only option.
  7. When prompted, select the interface to be replaced.
  8. When prompted, enter 1 and then enter the new interface name.
  9. When prompted to change another interface, enter "y" when prompted and repeat steps 7and 8 as required.
  10. To complete the process, enter "n".
  11. When prompted to remove the old interfaces from the database enter "y".
  12. On the VSX Gateway or cluster members, run the vsx_util reconfigure command.
  13. Reboot the VSX Gateway or cluster members.