NGX (R60) VPN-1 Networking Overview

August 30, 2005

IMPORTANT Before you begin installation, read the latest available version of these release notes at: http://www.checkpoint.com/support/technical/documents/docs_r60.html In This Document Introduction Domain Based VPN and Route Based VPN Industry Standard Dynamic Routing Protocol Suite Combining Route Based VPN and Domain Based VPN Directional VPN Rule Match Link Selection Route Injection Mechanism (RIM) page 1 page 2 page 4 page 4 page 5 page 6 page 7

Introduction
Virtual Private Networks are a growing necessity. In the recent past, geographically separated locations were connected by private or leased lines. With the Internet becoming more and more accessible, and with prices become more and more competitive, leased lines are making way for Internet VPNs. Two technologies are used to create a VPN that serves the Internet. One technology builds on cryptographic instruments to encrypt and authenticate traffic. This makes the traffic incomprehensible for an unauthorized eavesdropper, and makes it impossible for a man-in-the-middle to inject malicious data. The other technology is the firewall, which protects against Internet threats in general, and makes it possible to use the Internet securely. Check Points state of the art implementation of these technologies, combined with its powerful management tools, make its VPN capabilities unmatched. In NGX, Check Point has greatly enhanced VPN-1 Pros ability to integrate with network level functions. The introduction of Route Based VPN allows IP routing, and in particular dynamic routing protocols, to naturally use IPsec VPN tunnels as network resources, by
Copyright 2005 Check Point Software Technologies, Ltd. All rights reserved.

Domain Based VPN and Route Based VPN

representing IPsec tunnels as VPN Tunnel Interfaces (VTIs). SecurePlatform Pro, Check Points secure operating system, is empowered with an industry standard dynamic routing and multicast protocol suite. SecurePlatform Pros dynamic routing, when combined with ClusterXL, features unique dynamic routing high availability and load sharing capabilities thats also available for VPN. Link Selection mechanisms feature highly redundant, easy to configure, VPN links between gateways. This document explains the advantage of the new NGX features, and their potential usage.

Domain Based VPN and Route Based VPN

Configuring a VPN can be done in several ways. It is possible to specify all the IP addresses that participate in the VPN, along with their respective protecting gateways, and the possible VPN tunnels to be established. This is done by defining the VPN gateways, the VPN Domain of each gateway, and the VPN Community. The vpn_route.conf file can be used to add more flexibility in controlling the routing between the VPN gateways. This method is referred to as Domain Based VPN.
FIGURE 1 Domain Based VPN

In NGX, Check Point introduces a new method for setting up VPNs. This method is called Route Based VPN. In Route Based VPN, there is no need to define VPN Domains, instead only VPN Tunnels need to be defined. What controls the VPN routing is the native IP routing. VPN tunnels are represented using VTIs. These VTIs enable IP routing to control the VPN. VTIs are virtual interfaces defined on the VPN-1 Pro module. Each VTI is associated with a VPN peer gateway, and any traffic routed through such an interface is automatically encapsulated and sent to the associated peer gateway. Any traffic received from
NGX (R60) VPN-1 Networking Overview. Last Update August 30, 2005

Domain Based VPN and Route Based VPN

the associated peer gateway appears to be coming through the VTI. This configuration behaves exactly as if it were connected to the peer gateway over a point-to-point link, represented by the VPN Tunnel Interface.
FIGURE 2 Route Based VPN

It is very important to be able to control the VPN through IP routing. In some environments, network administrators have tools with IP routing capabilities. Large networks are often managed with dynamic routing protocols that allow automatic propagation of routing information, and make it possible to set up redundant links. Dynamic routing protocols reduce the overhead of configuring a large number of routers, and find the best available path when several paths exist to a given destination. With Route Based VPN, both static and dynamic IP routing can be used to control the VPN. Domain Based VPN and Route Based VPN are two ways of setting up a VPN. In more static environments the definition of the gateways and the VPN domains is very convenient. Route Based VPN should be used either when its easier to control IP routing than it is to change the VPN domains definitions, or when dynamic routing should be utilized. To summarize, following are the possible approaches to configuring VPNs: Domain Based VPN Configuring a VPN domain for each VPN gateway. Configuring static VPN routing through vpn_route.conf . Route Based VPN

NGX (R60) VPN-1 Networking Overview. Last Update August 30, 2005

Industry Standard Dynamic Routing Protocol Suite

Configuring VPN Tunnel Interfaces with either static routes or by controlling routes through network management tools. Configuring VPN Tunnel Interfaces and dynamic routing protocols, i.e. OSPF, BGP, and RIP, to run over the VPN.

Industry Standard Dynamic Routing Protocol Suite

The Check Point Operating System, SecurePlatform, is now greatly enhanced with the integration of a dynamic routing protocol suite that is industry standard level. SecurePlatform can be installed in two flavors: the regular flavor, and the SecurePlatform Pro flavor. SecurePlatform Pro is an enhanced version of SecurePlatform. With this suite, SecurePlatform Pro natively supports the OSPF, BGP, RIPv1, and RIPv2 dynamic routing protocols; therefore, making it unnecessary to acquire this functionality from external sources. Additionally, SecurePlatform Pro supports PIM-SM, PIM-DM, and IGMP for multicast traffic. Unique integration of the routing protocols with ClusterXL provides unmatched support for high availability and load balancing solutions with dynamic routing. This in essence allows a dynamic routing protocol, running on a cluster member of a load balancing cluster, to fail over to another cluster member, without losing connectivity, and without any network down time for dynamic routing synchronization. Configuration of all newly supported protocols is done through the SecurePlatform CLI. The new functionality is available as SecurePlatform Pro, which is priced per unit.

Combining Route Based VPN and Domain Based VPN

It is important to note that Route Based VPN does not replace or make Domain Based VPN obsolete, but rather expands the possibilities of configuring a VPN. In fact, the two methods can be used simultaneously. This is particularly useful during migration periods. The governing principal is that Domain Based VPN takes precedence over Route Based VPN. Consequently, whatever would have been routed into a certain IPSec tunnel based on Domain Based VPN configuration would not change by the definition of Route Based VPN. In other words, routing through VPN Tunnel Interfaces can only apply to traffic thats not covered by the definition of VPN Domains, and that would otherwise go in the clear. Combining the two methods is unique to Check Point, and provides great flexibility for configuration and transition.

NGX (R60) VPN-1 Networking Overview. Last Update August 30, 2005

Directional VPN Rule Match

Directional VPN Rule Match

A new type of access control rule can be created using the Directional VPN Rule Match feature that matches more precisely on VPN traffic, and allows expressing rules based on the direction of the traffic flow rather than the participating IP addresses. A Directional VPN Rule matches on traffic based on the type of interface group through which traffic enters the gateway, and the type of interface group this traffic goes out through. The interfaces are divided into three main interface groups: the internal interfaces, the external interfaces, and VPN interfaces. Traffic going into a VPN tunnel, or coming out of a VPN tunnel is considered to have passed through a VPN interface. VPN interfaces are referenced by their associated VPN community. The Directional VPN Rule Match is configured at the VPN column on the rule base, which can now contain values of the form A/B, where A and B each represent an interface group. Such a rule would match on traffic entering the gateway from interface group A, and leaving the gateway through interface group B. A and B can represent a VPN interface group, such as the interfaces belonging to some community or group of communities, an interface of the group of internal interfaces (called internal_clear), or an interface of the group of external interfaces (called external_clear). For example, consider the following rule:
FIGURE 3 Directional Rule

This rule would accept HTTP traffic intercepted on any of the gateways internal interfaces, which is about to enter a tunnel of MyIntranet VPN Community. When using Route Based VPN it is only natural to avoid defining the exact topology, and the IP addresses encountered by the VPN-1 module arent always known in advance. Route Based VPN makes it possible not to define VPN Domains, while Directional VPN Rule Match makes it possible not to specify IP addresses for a rule match. More than one Directional VPN Match condition can be specified in a single rule. For example:
FIGURE 4 Directional Rule with multiple direction matches

Note, that the directional rule match only works on VPN traffic, so at least one side of the arrow has to contain a VPN interface group.

NGX (R60) VPN-1 Networking Overview. Last Update August 30, 2005

Link Selection

Link Selection
Link Selection mechanisms were designed to help an administrator define how two peer VPN gateways find the path to establishing a tunnel between them. A gateway may have several IP addresses and more than one IP address can be viable for VPN establishment. Different peer gateways may need to choose a different IP address for connecting to the same gateway. When connecting to several ISPs, one would expect redundancy between them. To facilitate this, a gateway should be able to send traffic through the proper ISP based on availability of the ISP and of the peer gateways through each ISP. If a peer gateway has several IP addresses given by different ISPs, choosing the right IP isnt enough, but it is also required to failover to another IP in case the chosen IP isnt available anymore. There are several methods that can determine how remote peers resolve the IP address of the local gateway. Remote peers can connect to the local gateway using: A fixed IP address - one of the gateway's IP addresses, or even a NAT address that hides the gateway. The result of a DNS query. This is useful for gateways with a dynamically allocated address that can be dynamically updated on a DNS server. The result of actively probing to see which of the gateway's IP addresses responds. The subset of addresses to be probed can be selected. One of the addresses can be designated as primary. Probing can be done once, just to determine the proper IP to be used, or it can be ongoing, which allows failing over to another IP if the chosen IP stops responding to the probes. The result of a topological calculation, based on the information in the topology tab of both gateways - the local and the peer. For outbound traffic, the operating system configuration can be greatly enhanced. Route Based Probing is a Link Selection mechanism that can be used to look at all the possible routing entries in the routing table that are relevant for reaching some peer gateway. All of them are probed simultaneously, and the best available one is chosen based on the routing metric. Any change in the routing table will be immediately accounted for. Route Based Probing is most useful for multi-homed gateways, especially as an alternative to utilizing BGP against two or more ISPs. Another interesting aspect of this feature is that a different ISP link can be used as the path to different gateways, thus providing load sharing between ISPs. These mechanisms cover a wide range of connectivity scenarios, such as multi-homed gateways with redundant ISPs, dynamically assigned IP gateways with dynamically updated DNS, gateway behind NAT, and more.

NGX (R60) VPN-1 Networking Overview. Last Update August 30, 2005

Route Injection Mechanism (RIM)

Route Injection Mechanism (RIM)

RIM is a powerful tool that can be employed when there is a status change of a VPN tunnel. The Route Injection Mechanism (RIM) enables a VPN-1 gateway to easily detect when a VPN tunnel has been established and activated between itself and a VPN-1 Edge device (or another VPN-1 gateway), and automatically propagates the peers VPN domain, using a dynamic routing protocol, to its internal network. If the tunnel is deactivated, the peers VPN domain information is removed, and again, propagated internally via the routing protocol. Configuring RIM is an easy as checking a checkbox on the VPN Star Community. This makes it an attractive alternative for networks that are large scale, but not very complex, in particular, for large scale Hub and Spokes configurations.
FIGURE 5 Route Injection Mechanism (RIM) Example 1

RIM enables a VPN-1 Pro Gateway to use dynamic routing protocols to propagate the encryption domain of a VPN-1 Pro peer gateway to the internal network as well as initiate back connections. When a VPN tunnel is created, RIM updates the local routing table of the VPN-1 Pro Gateway to include the encryption domain of the VPN-1 Pro peer. The immediate solution to be examined is often some dynamic routing protocol with Route Based VPN, which can be a viable solution in some cases. However, for really large star networks a full blown dynamically routed network is a highly cumbersome solution. Configuring such a large dynamically routed network is far from simple. Additionally, dynamic routing protocols are overkill for such a problem, since they propagate the network topology over the VPN, while the network topology often doesnt really change. With RIM, a VPN gateway can use its ability to communicate using dynamic routing protocols towards the center side, while monitoring the VPN Tunnel state towards the remote sites. As long as the tunnel to a remote site is active, the networks defined as the VPN Domain of the remote site are injected into the dynamic routing network. By doing so, the center gateway reports to the center network that the remote site is connected to it and the center network routes traffic targeted to the remote site only through the right gateway. Should the remote site connect to a different center gateway, the newly connected gateway would inject the information to the center network, while the gateway no longer
7

NGX (R60) VPN-1 Networking Overview. Last Update August 30, 2005

Tunnel Monitoring

connected would remove the injected routes. Enhancements made to MEP configuration can also be advantageous, as they allow granular preference of primary gateway to be specified per satellite gateway.
FIGURE 6 Route Injection Mechanism (RIM) Example 2-

In this scenario: Gateways 1 and 2 are both RIM and have a dynamic routing protocol enabled. R1 and R4 are enabled routers. When a VPN tunnel is created, RIM updates the local routing tables of Gateway 1 and Gateway 2 to include the encryption domain of the other Gateway. Should the VPN tunnel become unavailable, traffic is redirected to the leased line.

Tunnel Monitoring
In NGX, it is possible to designate any VPN tunnel as a permanent tunnel. Permanent tunnels are constantly kept active, and their state can be easily monitored. This is very useful for troubleshooting, and for monitoring Internet connectivity, and gateway availability. In SmartView Monitor, tunnel status can be conveniently viewed as reported by its endpoint gateways. Logs and alerts are also available as well as SNMP information. The tunnel monitoring mechanism is also used by the Route Injection Mechanism to detect when tunnels are active or down. Configuring permanent tunnels can be done for an entire VPN Community, or for any subset of its tunnels, including singular tunnels.

NGX (R60) VPN-1 Networking Overview. Last Update August 30, 2005