NGX (R60) Route Based VPN Deployments

August 30, 2005

In This Document Introduction New VPN-1 Pro Concepts Configuration Scenarios Appendix A - Working with VPN Tunnel Interfaces page 1 page 1 page 8 page 20

Introduction
Check Point's next VPN-1 Pro release answers many of the challenges produced by increasingly complex large-scale VPN networks. This document focuses on dynamic routing and outlines scenarios a VPN administrator may be faced with, and how the latest Check Point VPN-1 Pro features address this scenario. The functionality described in this document is based on SecurePlatform. This functionality will also be available on IPSO, though there may be slight usability differences.

New VPN-1 Pro Concepts

Route Based VPN
To set up VPN in previous releases, VPN domains had to be configured. Traffic to the Gateway's VPN domain were directed via an IPSec tunnel to the domain's gateway. Exceptions to this were MEP (Multiple Entry Points) scenarios, and the use of vpn_route.conf . With MEP, a selection mechanism on a remote gateway, chose one of several possible VPN entry points to a VPN Domain, thus providing redundancy between the entry points. With the vpn_route.conf file, alterations were made to the VPN Domains configuration. This method is referred to as Domain Based VPN.

Copyright 2005 Check Point Software Technologies, Ltd. All rights reserved.

New VPN-1 Pro Concepts Route Based VPN

The use of VPN Tunnel Interfaces (VTI) introduces a new method of configuring VPNs called Route Based VPN. In Route Based VPN, VTIs are created on the local gateway. Each VTI is associated with a corresponding VTI on a remote VPN-1 Pro peer. Traffic routed from the local gateway via the VTI is transferred encrypted to the associated VPN-1 Pro peer gateway.
FIGURE 1 Route Based VPN

Route Based VPN is based on the notion that setting up a VPN between two peer gateways is much like connecting them directly with a dedicated wire. A VPN Tunnel Interface is an Operating System level virtual interface that provides a door into a VPN tunnel. Each VPN Tunnel Interface is associated with a single tunnel to a VPN peer gateway. It then behaves just like a point to point link between the two gateways. The tunnel itself with all its properties is defined, as before, by a VPN Community linking the two gateways. The peer gateway should also be configured with a VPN Tunnel Interface. The native IP routing mechanism on each gateway can then direct traffic into the tunnel just as it would for any other type of interface. With the introduction of VPN Tunnel Interfaces, it is now possible to have complete control of VPN routing by the native OS level IP routing. The same infrastructure allows dynamic routing protocols to control the VPN. A dynamic routing protocol daemon running on the VPN-1 gateway can establish connectivity with a neighbor routing daemon running on the other end of an IPsec tunnel, which appears to be a single hop away. The daemons can exchange routing information and dynamically change the IP routing, which naturally changes the traffic directed to the IPsec VPN tunnel.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

New VPN-1 Pro Concepts VPN Tunnel Interfaces

VPN Tunnel Interfaces

A VPN Tunnel Interface is a virtual interface on a VPN-1 module, which is associated with an existing VPN tunnel, and is used by IP routing as a point to point interface directly connected to a VPN peer gateway. The VPN routing process of an outbound packet can be described as follows: 1) An IP packet with destination address X is matched against the routing table. 2) The routing table indicates that IP address X should be routed through a point to point link, which is the VPN Tunnel Interface that is associated with peer gateway Y. 3) VPN-1 kernel intercepts the packet as it enters the virtual tunnel interface. 4) The packet is encrypted using the proper IPsec Security Association parameters with peer gateway Y (as defined in the VPN Community), and the new packet receives the peer gateway Y's IP address as the destination IP. 5) Based on the new destination IP, the packet is rerouted by VPN-1 into the physical interface, again, according to the appropriate routing table entry for Y's address. The opposite is done for inbound packets: 1) An IPsec packet enters the machine coming from gateway Y. 2) VPN-1 intercepts the packet on the physical interface. 3) VPN-1 identifies the originating VPN peer gateway. 4) VPN-1 decapsulates the packet, and extracts the original IP packet. 5) VPN-1 detects that a VPN Tunnel Interface exists for the peer VPN gateway, and reroutes the packet from the physical interface to the associated VPN Tunnel Interface. 6) The packet enters the IP stack through the VPN Tunnel Interface. A VPN Tunnel Interface is best defined symmetrically on both gateways, although it is possible to have one side work with Domain Based VPN. In such a case the gateway without the VPN Tunnel Interface configured on it would not accept just any IP address from its peer gateway, but only IP addresses that are specifically defined in the peer's VPN Domain (or any specific alteration of it configured in the vpn_route.conf file).

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

New VPN-1 Pro Concepts Numbered and unnumbered VPN Tunnel Interfaces

Numbered and unnumbered VPN Tunnel Interfaces

There is a difference between the VPN Tunnel Interface implementation on SecurePlatform, and on IPSO. VPN Tunnel Interfaces on SecurePlatform are numbered, while the IPSO ones are unnumbered. A numbered tunnel interface has a unique IP address assigned to it, while an unnumbered tunnel interface does not. Having no IP address of its own, the unnumbered VPN Tunnel Interface uses an IP address belonging to another interface IP address when needed, which is why a proxy interface needs to be specified for it upon creation. The proxy interface IP is used, for example, to set the source IP address for traffic initiated from the gateway itself through an unnumbered interface, or for applying hide NAT to such traffic. Another difference that currently exists between the two interface types is that when selecting "Get Topology" in SmartDashboard, numbered interfaces are displayed, while unnumbered interfaces are not. Therefore, no Anti-Spoofing can be defined for unnumbered interfaces. While the use of unnumbered interfaces is more economical in terms of the number of IP addresses required for the configuration on SecurePlatform, it is possible to define several VPN Tunnel Interfaces with the same assigned IP address. This address cannot belong to any other interface other than a VPN Tunnel Interface. At least one IP address is required for each SecurePlatform machine running Route Based VPN. VPN Tunnel Interfaces can be created using the vpn shell CLI (see Appendix A - Working with VPN Tunnel Interfaces page 20).

Directional VPN Rule Match

A new type of access control rule can be created using the Directional VPN Rule Match that matches VPN traffic more precisely, and allows expressing rules based on the direction of the traffic rather than the participating IP addresses. A Directional VPN Rule matches traffic based on the type of interface group through which traffic enters the gateway, and the type of interface group through which this traffic exits the gateway. The interfaces are divided into three main interface groups: internal interfaces, 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 in the VPN column of 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 matches traffic entering the gateway from interface group A, and leaving the gateway through interface group B. The following values can be used for A or B:

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

New VPN-1 Pro Concepts Directional VPN Rule Match

VPN Interface Groups: Community-X (for any existing VPN Community including the Remote Access Community) - represents all VPN tunnels defined by Community-X. All_GwToGw - represents the VPN tunnels of all site to site communities (for example, any community but the Remote Access Community). All_Communities - represents the VPN tunnels of all communities including the Remote Access Community. Internal interfaces: Internal_clear - represents all interfaces designated as "internal". External interfaces: External_clear - represents all interfaces designated as "external".

Any interfaces: Any Traffic - a wildcard that matches on any type of traffic. For example, consider the following rule:
FIGURE 2 Intercepting HTTP Traffic

The rule in Figure 2 on page 5 accepts HTTP traffic intercepted on any of the gateway's internal interfaces, which is about to enter a MyIntranet VPN Community tunnel. When using Route Based VPN you should try not to define the exact topology since the IP addresses encountered by the VPN-1 module are not 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 and this has two benefits: The first benefit is that a single rule can be installed on several gateways to signify different aspects of the same traffic. For example, the rule in Figure 3 on page 6 can be installed on two or more gateways that are members of MyIntranet, and for each HTTP connection routed on the tunnel between them, the same rule is matched to one gateway when it flows from an internal interface and into the VPN tunnel, and on the other gateway when it enters through the VPN tunnel and flows into the internal interface

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

New VPN-1 Pro Concepts Industry Standard Dynamic Routing Protocol Suite FIGURE 3 Single Rule Installed on Several Gateways.

The second benefit is that a connection may dynamically change its route without breaking. For example, the rule in Figure 4 on page 6 will allow HTTP traffic to be initiated from the internal interface side, and to be routed into a Community-A VPN tunnel or a Community-B VPN tunnel. The routing can change dynamically between these two communities without breaking the connection.
FIGURE 4 Dynamic Routing Changes

Note - The rule match is usually performed on traffic when it enters the VPN gateway. For the rule match to succeed before the actual IP routing is performed, the IP routing table is consulted prior to the rule match.

Industry Standard Dynamic Routing Protocol Suite

SecurePlatform Pro is now greatly enhanced with the integration of a dynamic routing protocol suite that is at an industry standard level. With this suite, SecurePlatform-Pro now natively supports the OSPF, BGP, RIPv1, and RIPv2 dynamic routing protocols. Support for these routing protocols is also uniquely integrated with ClusterXL, to provide unmatched support for a high availability and load balancing solution with dynamic routing. SecurePlatform additionally supports PIM-SM, PIM-DM, and IGMP for multicast traffic. Configuration of all these protocols is done through the SecurePlatform CLI.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

New VPN-1 Pro Concepts Combining Route Based VPN and Domain Based VPN

Combining Route Based VPN and Domain Based VPN

It is important to note that Route Based VPN has not replaced Domain Based VPN or made it obsolete, but rather it 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 is routed into a certain IPsec tunnel based on Domain Based VPN configuration is not changed by the definition of Route Based VPN. In other words, routing through VPN Tunnel Interfaces can only apply to traffic that is not covered by the definition of VPN Domains, and that would otherwise go in the clear. The order between the two VPN routing methods is simply set by the order of the VPN routing decisions. First, the Domain Based VPN routing tables are consulted, to determine the proper origin and/or target VPN gateway for the traffic. If no Domain Based VPN routing applies, the IP routing table is consulted, to determine whether the traffic is routed through a VPN Tunnel Interface. For example, if two gateways have their respective VPN Domains defined, the two gateways will always route traffic between those VPN Domains through the community tunnel that connects between them, regardless of whether VPN Tunnel Interfaces were defined or not. Adding VPN Tunnel Interfaces can be used at first to serve additional traffic that is not handled by Domain Based VPN. This way, an OSPF daemon can be set up to work over a VPN Tunnel Interface while Domain Based VPN is still active. Since OSPF uses multicast for communication, it can only work with VPN Tunnel Interfaces. Once OSPF adjacency is established between the two gateways, routing information can be exchanged. After verifying that the routing information is correct, one could gradually remove parts of the VPN Domains definition, to allow Route Based VPN to take affect.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

Configuration Scenarios Dynamic Routing Over VPN

Configuration Scenarios
Dynamic Routing Over VPN
For complicated networks, automatic updating is essential for the minimization of network configuration. Dynamic Routing protocols are especially designed to propagate information between routers automatically, whether the information regards newly connected networks, or whether it regards the best available path to some remote network. Establishing IPsec VPNs allows the usage of a relatively inexpensive media such as the Internet to connect geographically spaced networks. Combining these two (dynamic routing protocols and VPNs) is beneficial for several reasons: First, it allows dynamic routing information to propagate over the VPN, utilizing the VPN as just another point to point link in the network. Second, it allows the VPN device to be automatically updated regarding networks on any VPN peer's side of the network, without the need to update the VPN domain's configuration. Third, in case of tunnel failure, other tunnels may be used to route the traffic. Consider the following configuration:
FIGURE 5 Mesh of 3 VPN Gateways

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

Configuration Scenarios Dynamic Routing Over VPN

1) Dynamic Routing of VPN Topology The 3 gateways (A, B, and C) each have directly connected local networks (10.10.10.0/24, 10.10.20.0/24, and 10.10.30.0/24 respectively), and each gateway is connected to the Internet. 2) Purpose of Dynamic Routing of VPN To control VPN routing using OSPF instead of a VPN domains definition, in order to avoid the need for VPN configuration changes in case subnets are added or removed. To achieve network redundancy, so that if, for instance, gateway A loses connectivity with gateway B, traffic from A to B can be redirected through gateway C. 3) Dynamic Routing of VPN Configuration Checklist Define the gateway objects and VPN Community/Communities. Create an access control policy to accept OSPF. Create the VPN Tunnel interfaces manually. Install policy. Configure dynamic routing on each module. 4) Configure Dynamic Routing over VPN a. Use Check Point's SmartDashboard to configure the following objects: An empty group object to be used as a VPN Domain. A Check Point gateway object for each of the three gateways. - The OS should be set to SecurePlatform.

- The VPN Domain should be configured as an empty group. A Site to Site Meshed community that contains all three gateway objects.

b. Create an access control policy to accept the required traffic and create an accept rule for service OSPF, with the VPN Community in the VPN column. c. On each gateway two VPN Tunnel interfaces should be created (one for each VPN peer). This is done manually using the VPN shell CLI, as explained in the following command line. In order to add a VPN Tunnel Interface on gateway A, for the VPN Tunnel to gateway B, assign the point to point tunnel end point IP addresses on A and B to 10.10.1.2 and 10.10.2.1 respectively. The following is an example of a single command line that does this:
[Expert@A]# vpn shell interface add numbered 10.10.1.2 10.10.2.1 B to_B Interface 'to_B' was added successfully to the system [Expert@A]# vpn shell interface add numbered 10.10.1.3 10.10.3.1 C to_C Interface 'to_C' was added successfully to the system
NGX (R60) Route Based VPN Deployments. Last Update August 30, 2005

Configuration Scenarios Dynamic Routing Over VPN

[Expert@A]#

These command lines executed on the Expert shell of gateway A, add a virtual point to point interfaces called to_B, and to_C with local IP addresses 10.10.1.2 and 10.10.1.3 and remote IP addresses 10.10.2.1 and 10.10.3.1, associated with gateways B and C. For more information on VPN Tunnel Interfaces see VPN Tunnel Interfaces on page 3, or Appendix A - Working with VPN Tunnel Interfaces on page 20.
Note - For easier management (and less IP address involvement) it is recommended to configure all VTIs on each gateway with the same local IP address, thus having only 1 extra IP for each GW for VTIs. Currently, this is not supported on clusters. Therefore, each member of a cluster requires a different local IP for each VTI.

d. Configure OSPF on each of the VPN gateways to work with the VPN Tunnel Interfaces. The following is an example of how to do this on gateway A: During the SecurePlatform installation select the SecurePlatform-PRO option in addition to the "VPN-1 Pro". Run cpconfig and enable the advanced routing option to run the router. Run cligated, which enters the routers interactive mode, and use the following commands to manage OSPF: Use the command Use Use
enable

to enter privileged mode. to display configuration details.

show running-config configure terminal

to start configuring.

Use router ospf 1 to create an OSPF routing instance. This enters configuration mode for this specific router. Run the following commands (setting the required IP addresses):
"router-id <router id (e.g. 10.10.1.1)>" to set the router's id.

For each numbered interface on which OSPF is to be active, run the following:
"network <remote <remote ip>. ip (e.g. 10.10.2.1)> 0.0.0.0 area <area number (e.g. 0.0.0.0)>" - configures OSPF to work with the network represented by

This should be the same as the <remote ip> configured in the VPN shell above, as the IP address on the other side of the numbered VPN tunnel. The 0.0.0.0 that follows is the network wildcard (the binary NOT of the network mask), and is required since it is a point-to-point network. The OSPF area number is set to zero in this example.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

10

Configuration Scenarios Existing Dynamic Routing

Summary With the configuration of the VPN Tunnel Interfaces on top of the existing community tunnels, the VPN becomes an infrastructure, providing point to point links between VPN gateways. This infrastructure allows IP routing to control VPN traffic, and, in particular, it allows dynamic routing protocols to be deployed over the VPN. In this scenario, if a new network is connected to gateway A, gateways B and C will be automatically updated with this routing information. The routing tables are therefore updated accordingly, and traffic on B or C destined to the new network is automatically directed to the VPN Tunnel to A. If one of the VPN Tunnels fail, say from A to B, then the OSPF daemon on B detects this, and routes traffic to A through C. A replies to B through C as well, since A's routing has changed as well. This behavior assumes correct routing configuration, for example, assuming A, B, and C, are configured as all belonging to area zero of OSPF with equal costs associated to their links.
Note - OSPF network configuration is beyond the scope of this document.

Existing Dynamic Routing

Dynamic routing over VPN can be performed in environments where dynamic routing configurations are already deployed. The VPN may be a newly introduced type of link between sites, or it may have been previously unaware of dynamic routing information. In some cases routers are connected over the VPN using GRE. This has two main disadvantages: GRE overhead is added to all VPN traffic VPN device cannot filter or log the traffic within the GRE tunnel. Making the VPN routing aware can help build a healthier routing environment. Consider the following example: In the following Figure 6 on page 12, each of the 3 gateways (A, B, and C, as before) has directly connected local networks, that are connected to the Internet. In addition, on each gateway's internal network side there is a router with dynamic routing enabled (for example, OSPF.).

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

11

Configuration Scenarios Existing Dynamic Routing FIGURE 6 3 gateways with connected local networks

The purpose of Existing Dynamic Routing is summarized in the following list: Control VPN routing using OSPF instead of VPN domains definition, as in the previous example. Achieve network redundancy. Extend dynamic routing over the VPN. Avoid GRE tunneling. All configurations (refer to Configuration Scenarios on page 8) apply here as well. The only difference is in the dynamic routing configuration. Configure Existing Dynamic Routing 1) Follow the previous example (refer to Configuration Scenarios on page 8) to configure all but the dynamic routing part. 2) The following are some ideas about how to set up an environment with dynamic routing: a. Using BGP - Since VPN connected sites often make sense as separate routing domains, it is logical to link them using BGP. In this configuration each gateway can be assigned a separate private AS number, and can be configured to have an eBGP connection with its peers, or possibly only some of them. There is no need to have public AS numbers as there is no real connection to the Internet. In order to propagate the routing information to the adjacent local router, either iBGP can be used (for example, another BGP connection using the same AS number), or an OSPF link can be set up. For OSPF to work, the routing daemons need to be configured to redistribute the routes between OSPF and BGP.
NGX (R60) Route Based VPN Deployments. Last Update August 30, 2005

12

Configuration Scenarios Dynamic Routing and Stateful Inspection (Wire Mode)

b. A single OSPF area - With all gateways and routers configured to be part of the same OSPF area, the entire network information is known to all participants. This can be very simple to configure and is suitable for simple networks. As the network becomes larger, having all nodes across the VPN updated for every single change can be an undesirable overhead. c. VPN as the OSPF backbone area - In some cases it would make sense to have the VPN as the backbone area with each VPN site acting as an area connected to the backbone. This allows each VPN site to be an area of its own, without necessarily propagating unnecessary routing information from the VPN site to other VPN sites, and without receiving unnecessary routing information from other VPN sites, configured as separate areas. Summary: Configuring dynamic routing over the VPN, and over the adjacent LAN, makes it possible for routing information to propagate between geographically spaced networks. This can save a lot of configuration time, yield network redundancy, alleviate the burden of GRE, make better use of the VPN-1 Pro's firewall capabilities, and turn existing disjointed routing domains into connected ones. The existing router may run any routing protocol, and receive routing information over the VPN using OSPF or BGP sessions with the VPN-1 Pro device.

Dynamic Routing and Stateful Inspection (Wire Mode)

Stateful Inspection is based on the idea that a Firewall is able to intercept all packets of a given connection. While keeping track of the connections state, Stateful Inspection makes sure the traffic is compliant with certain security rules. When dynamic routing is used for redundancy purposes, traffic may change an ongoing connection's path. A Stateful Inspection Firewall, positioned along a dynamically changing path, will often start handling connections for the first time after they have already been established on another path. In TCP, for example, this would mean that the TCP handshake is not being monitored. By default, Check Point Firewall will drop such connections as being "out of state". The use of Wire Mode makes it possible to designate a certain portion of the traffic as traffic that should not be inspected. This can be useful when the traffic can be safely inspected at some other point in the flow, at a point which does not change dynamically, or when the traffic is considered harmless and no Inspection is required. The use of Wire Mode does not mean the Firewall is turned off on the gateway, but merely that it is bypassed for selected traffic. Wire Mode traffic selection is done in SmartDashboard by activating Wire Mode on a VPN Community and on some internal interface of a VPN Pro gateway object. Any connection, intercepted by the gateway, which is coming from a Wire Mode enabled VPN tunnel and going into a Wire Mode enabled internal interface, or vice versa, will not be inspected. In addition, Wire Mode can be separately turned-on in the VPN community for back to back

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

13

Configuration Scenarios Dynamic Routing and Stateful Inspection (Wire Mode)

tunnels. Traffic coming from a VPN Community tunnel and going into a VPN Community tunnel will also be passed un-inspected, if Wire Mode is enabled for back to back tunneling on both communities. This can also happen in the same community. The following pages present two examples of the use of Wire Mode. Wire Mode Topology Example #1 In this example (Figure 7 on page 14), we build on the previous scenario, where the three gateways, A, B, and C, are running some dynamic routing protocol among themselves, and are connected to routers in their protected networks. Additionally, there is a link between the networks behind gateways A and C. The added link between A's and C's networks makes it possible for B's network to access the same resources either through A or through C.
FIGURE 7 3 gateways running a dynamic routing protocol among themselves

Purpose

The following are the same as Configure Existing Dynamic Routing on page 12. To control VPN routing using OSPF instead of VPN domains definition. To achieve network redundancy. Extend dynamic routing over the VPN. Avoid GRE tunneling. To preserve existing connections in case either gateways A or C are lost.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

14

Configuration Scenarios Dynamic Routing and Stateful Inspection (Wire Mode)

Configuration Checklist

All configurations in Configure Existing Dynamic Routing on page 12 apply here as well. The added link is part of the dynamic routing configuration on the routers. To continue configure Wire Mode: 1) Turn on Wire Mode on the VPN community connecting gateway A with gateway B, and gateway C with gateway B. 2) Turn on Wire Mode on A's internal interface. 3) Turn on Wire Mode on C's internal interface.
Configuration

1) Open the VPN community defined to connect gateways A and C. This can be a mesh community as defined in the first example, which connects all three gateways. It can also be a star community that connects B to the two central gateways - A and B, or there can be different communities defined to connect each pair of gateways. a. Select the Wire Mode tab under the communitys Advanced Settings option. b. Check the checkbox for Allow uninspected encrypted traffic between Wire Mode interfaces of this community's members. 2) Open gateway A's network object, and select the VPN
Advanced

tab under the

VPN

tab.

a. Under Wire Mode check the Support Wire Mode checkbox. b. Click Add to select which of the gateway's internal interfaces should be Wire Mode enabled. Only traffic between these interfaces and some Wire Mode enabled VPN community tunnel will bypass firewall inspection. c. Select whether or not to log Wire Mode traffic using the Log Wire Mode traffic checkbox. 3) Follow the same steps as in Step #2 for gateway C.
Summary

Wire Mode allows VPN traffic to be fully trusted and enhances connectivity. Wire Mode is only active for traffic between designated internal interfaces and designated VPN communities. All other traffic is inspected as it always has been. Another use of Wire Mode can be seen in the following example, in which we look only at the tunnels that connect the three gateways. The point is to allow traffic passing between each pair of gateways to go through the third gateway in case direct connectivity is lost between the pair. For instance, if connectivity between A and B is lost, traffic should flow from A to C, and continue from C to B. Note, that for this to be accomplished there is no stateful inspection problem on A nor on B, since the traffic continues to flow through both of them. The problem is that gateway C may only see some of the traffic, and, therefore, needs to turn off its stateful inspection for this traffic.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

15

Configuration Scenarios Dynamic Routing and Stateful Inspection (Wire Mode)

Wire Mode Topology Example #2 The three gateways A, B, and C, with a single VPN Community connecting between them.
Purpose

Provide redundant paths between VPN gateways. Preserve existing connections when path fails over to include additional VPN gateways.
3 gateways connected by a single VPN community

FIGURE 8

Configuration Checklist

1) Turn on Wire Mode on the VPN community connecting all the gateways. 2) Turn on Wire Mode routing on the VPN community.
Configuration

1) As in the previous example, turn on Wire Mode on the community: a. Select the Wire Mode tab under the Advanced Settings option of the community. b. Check the checkbox for Allow uninspected encrypted traffic between Wire Mode interfaces of this community's members. 2) To turn on Wire Mode routing select the
Summary
Wire Mode routing - Allow members to route uninspected encrypted traffic in VPN routing configurations

checkbox.

By turning on Wire Mode on a VPN community for traffic between VPN tunnels (as opposed to traffic between VPN tunnels and internal gateway interfaces in the previous example), a VPN gateway may become a node along a VPN path, which can be dynamically included or excluded from the path without breaking connectivity.
16

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

Configuration Scenarios Dynamic Routing for IPsec VPN Backup

Dynamic Routing for IPsec VPN Backup

There are ways to establish VPN networks other than IPsec VPN over the Internet, using, for example, private or leased lines. With dynamic routing over the VPN it is possible to dynamically choose between using the IPsec VPN or its alternative. Consider the following example:
FIGURE 9 Dynamic Routing For IPsec VPN Backup

The 3 gateways - A, B, and C, (as in the first scenario) are each directly connected to local networks, and each gateway is connected to the Internet. In addition, gateways A and B are connected using some leased line. The purpose of Dynamic Routing for IPsec VPN Backup is as follows: Use OSPF to determine whether to use an unencrypted leased line or an Internet IPsec VPN link. To control VPN routing using OSPF instead of VPN domains definition, achieve network redundancy, and avoid unnecessary policy updates in case of network changes, as in previous examples. Avoid GRE tunneling. All configurations in the first scenario apply here as well. The dynamic routing configuration can be performed in several ways: 1) One way is to use dynamic routing on one of the links, either the IPsec VPN or the leased line, which acts as the primary link, and use static routes to the secondary link with a higher associated cost (metric), possibly even a default route. This way, as long as

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

17

Configuration Scenarios Dynamic Routing for IPsec VPN Backup

the primary link is up, dynamic routing information will be updated to use that link. Should that link go down, the dynamic routes will be removed, and the lower priority routes will apply. 2) The second option is to run OSPF on both links. Configure Dynamic Routing for IPsec VPN Backup 1) Follow the first scenario (that is, Dynamic Routing Over VPN on page 8) to configure all but the dynamic routing settings between gateways A and B. 2) Choose one of the following methods to configure dynamic routing to select between the encrypted IPsec VPN link or the unencrypted leased line link: a. To work with dynamic routing on only one of the links, as in #1 in the previous section: Type cligated to enter Router configuration CLI. Use the command enable to enter privileged mode. Type configure terminal to start configuring. Type router ospf 1 to edit OSPF instance number 1. This enters configuration mode for this specific router. Run the following commands (setting the required IP addresses)
router-id <router id (e.g. 10.10.1.1)> network <remote 0.0.0.0)>

to set the router's id.

ip (e.g. 10.10.2.1)> 0.0.0.0 area <area number (e.g.

- configures OSPF to work with the network represented by <remote

ip>. This should be the same as the <remote ip> configured in the VPN shell above, as the IP address on the other side of the numbered VPN tunnel. The 0.0.0.0 that follows is the network wildcard (the binary NOT of the network mask), and is required since it is a point-to-point network. The OSPF area number is set to zero in this example. If you are using OSPF on the leased line interface (which is a point to point interface), use the same command with the relevant parameters (for example, the remote IP of the peer gateway). See the Check Point Advanced Routing Suite Command Line Interface guide about the network command for setting OSPF on other types of networks. Set static routes with higher metrics for the alternate route. For example:
ip route add <network (e.g. 1.2.3.4/32)> via <next-hop router (e.g. 5.6.7.8)>

- or -

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

18

Configuration Scenarios Dynamic Routing for IPsec VPN Backup

ip route add default via <next-hop router (e.g. 5.6.7.8)>

b. To work with dynamic routing on both the IPsec VPN and the unencrypted line, follow the same steps as in #2a above, only instead of setting up a static route, configure OSPF to be active on the network of the interface leading to the leased line. Assuming there are different OSPF neighbors on both networks, a different metric can be used to have preference between the two links. Summary The choice of whether to use one VPN link over another is a decision that can be made via dynamic routing. The dynamic routing protocol needs to monitor the preferred link and possibly the secondary link as well, and change the routing accordingly. Again, the VPN Tunnel Interfaces infrastructure makes it possible for dynamic routing to monitor the IPsec VPN link, just like any other link.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

19

Appendix A - Working with VPN Tunnel Interfaces Dynamic Routing for IPsec VPN

Appendix A - Working with VPN Tunnel Interfaces

This section demonstrates the use of the VPN shell CLI for adding VPN Tunnel Interfaces, and showing their status. The following script is a possible listing of a VPN shell interaction, in which an administrator adds a tunnel interface on gateway A which corresponds to gateway B. In the listing below the administrator enters the shell prompt mode, and uses the ? sign to find out which options are available at each level (the prompt appears in bold face). The added interface is a VPN Tunnel Interface on gateway A, for the VPN Tunnel to gateway B. The IP addresses of the point to point tunnel end points on A and B are assigned as 10.10.1.2 and 10.10.2.1 respectively. First, an interface is added:
[Expert@A]# vpn shell VPN shell:[/] > ? ? .. quit [interface [show - This help - Go up one level - Quit ] - Manipulate tunnel interfaces ] - Show internal data

VPN shell:[/] > interface VPN shell:[/interface] > ? ? .. [add [modify [delete [show - This help - Go up one level ] - Add a VPN tunnel interface ] - Modify interface parameters ] - Delete a VPN tunnel interface ] - Show interface(s) and their status

VPN shell:[/interface] > add VPN shell:[/interface/add] > ? ? .. numbered - This help - Go up one level - Add a numbered interface

VPN shell:[/interface/add] > numbered Usage: /interface/add/numbered <LocalIP> <RemoteIP> <PeerName> [IfName] LocalIP - The local IP of the tunnel

RemoteIP - The remote IP of the tunnel PeerName - The peer to attach to this interface IfName - The name of the interface to be used

VPN shell:[/interface/add] > numbered 10.10.1.2 10.10.2.1 B to_B Interface 'to_B' was added successfully to the system

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

20

Appendix A - Working with VPN Tunnel Interfaces Dynamic Routing for IPsec VPN

The interface name is optional. If it is not given the default is to give a name based on the peer name.
Note - it is possible to use only the prefix of each option to select it (for example, i for interface). In addition, it is possible to run the VPN shell as a command line. Running: VPN shelli a n 10.10.1.2 10.10.2.1 B to_B will give the same result.

After successfully adding the interface, the

VPN shell:[/interface/add] > .. VPN shell:[/interface] > ? ? .. [add [modify [delete [show - This help

show

command can be used to view it.

- Go up one level ] - Add a VPN tunnel interface ] - Modify interface parameters ] - Delete a VPN tunnel interface ] - Show interface(s) and their status

VPN shell:[/interface] > show VPN shell:[/interface/show] > ? ? .. summary detailed - This help - Go up one level - Summary of interfaces - Detailed information about the interface

VPN shell:[/interface/show] > summary Usage: /interface/show/summary [IfName | all] IfName all - The name of the interface to display - Display all interfaces

VPN shell:[/interface/show] > summary all * - Indicate that the interface is unnumbered Interface Peer Name Peer ID Status

================================================================== to_B B 215.129.43.17 attached

VPN shell:[/interface/show] > detailed all to_B Type:numbered MTU:1500 P-t-P:10.10.2.1 Mask:255.255.255.255 Status:attached

inet addr:10.10.1.2 Peer:B

Peer ID: 215.129.43.17

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

21

Appendix B - Route Based VPN on Clusters Dynamic Routing for IPsec VPN Backup

An interface ID is designated as unknown as long as the Peer Name remains unresolved. Once a policy that contains the gateway object of the VPN peer is installed, the interface becomes attached to that peer object. Traffic routed through this interface will be encapsulated in an IPsec tunnel, and redirected to the proper physical interface to be sent to the VPN peer. The following depicts an interface when a matching object was not found for attachment:
VPN shell:[/interface/show] > summary all * - Indicate that the interface is unnumbered Interface Peer Name Peer ID Status

================================================================== to_B B unknown DETACHED

VPN shell:[/interface/show] > detailed all to_B Type:numbered MTU:1500 P-t-P:10.10.2.1 Mask:255.255.255.255

inet addr:10.10.1.2 Peer:B

Peer ID:unknown

Status:DETACHED

Reason:Peer object name not found

Appendix B - Route Based VPN on Clusters

When using Route Based VPN on clusters: 1) Define the VPN Tunnel Interfaces - for each VPN Tunnel Interface to be used on the cluster, a VPN Tunnel Interface should be defined on each cluster member, with its own unique local IP, and the same remote IP address (that is, the peer gateway's local IP). In addition, in case there are several VPN tunnel Interfaces on each members (several peers), each VPN tunnel interface local IP should be different (this limitation does not exist in non-cluster configuration). 2) Define a cluster interface - In SmartDashboard, the VPN Tunnel Interfaces created on the cluster members must be fetched (using the topology fetching), and a cluster interface must be defined for them (one per peer gateway). This cluster interface will also have a unique IP address. 3) Defining OSPF - when using the network command, instead of specifying the remote IP Address, the local cluster IP address should be used (for example, as in the previous bullet, the IP address defined as the cluster IP of the local VPN Tunnel Interfaces set). On the peer gateway this is also the IP address that should be used as the remote IP, if the peer is a non-cluster gateway. It is possible to define OSPF on the interface definition itself within a router, instead of using the network command.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

22

Appendix C - Route Based VPN and Implied rules Connections Dynamic Routing for

Appendix C - Route Based VPN and Implied rules Connections

Connections that pass through the rule base on implied rules are generally not encrypted, and are not considered part of the VPN, as such they are not conveyed through the VPN tunnels. Implied rules can be divided into two groups: control connections (SIC) - connections that are responsible for internal communication, which include the policy installation. In most cases such connections are between the SmartCenter Server and its managed modules, and between the modules and the log servers. Other implied rules (for example, connections from the modules to LDAP servers, radius server, etc.). With Route Based VPN, such connections may get routed into a VPN Tunnel Interface, which is problematic for the following reasons: VPN Breaks Control Connections If this happens it may not be possible to correct the situation, since such connections (for example, connectivity used for policy installation) are the foundation of configuration maintenance. For all implied rules, if a connection originates on a VPN-1 Pro gateway, and is routed on a VPN Tunnel Interface via a VPN Tunnel Interface, the source IP address of that connection is normally the interface's IP address. Such IP addresses used for VPN Tunnel Interfaces are often non-routable. Therefore, even if the connection is forwarded properly in the clear, it may not be routed back, or even reach its destination (due to anti-spoofing). To overcome such problems, there are several possible solutions to choose from (based on network context): 1) Use fully routable IP addresses for the VPN Tunnel Interfaces, so that the Control Connection will always be routable. 2) Add static routes that do not direct traffic to VPN Tunnel Interfaces. Static routes are generally stronger than dynamic routes. 3) Avoid routing implied rules on the VPN. This can be done using one of the following methods: a. Do not add the IP addresses of the servers that are accessed by implied rules (SmartCenter server, log server, LDAP server) to the dynamic routing definitions. In this case, such IPs will not be routed via any of the VPN Tunnel Interfaces, and therefore are not encrypted.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

23

Appendix C - Route Based VPN and Implied rules Connections Dynamic Routing for

b. In case the SmartCenter Server is also a module gateway, configure the router on the module not to advertise the external IPs of the module. By default, if no "redistribute" directive exists on the router, "redistribute direct" is assumed (which will advertise all connected networks and interfaces). To turn it off, other "redistribute" directive should be configured (for example, "redistribute ospf", or "redistribute static", etc.). c. Add a route-map entry on the gateway that publishes the servers that are accessed through implied rules (SmartCenter server, log server, ldap server), to prohibit the dynamic routing daemon from advertising those IPs. With all the above methods (described in #3), traffic will be unencrypted to the filtered IPs. If this poses a problem it may still be possible to overcome it by adding the IP addresses that need to communicate with those servers, including the servers themselves, to the appropriate VPN domains. This will enforce Domain Based VPN on this traffic, instead of Route Based VPN, and avoid the routing problems. Of course, care should be taken when adding IP addresses to VPN Domains, as for communications between such VPN Domains only Domain Based VPN will apply, and not Route Based VPN. 4) For customers that disable all implied rules (and added manual rules for all the connections they want to pass), VPN control connection breaks and non-routable IP address problems (as discussed above) do not exist, because in this case all those connections will be encrypted. If the encryption is performed by route based VPN (that is, routes that lead to a proper VPN tunnel Interface), and the route is learned by dynamic routing protocols, a problem with the VPN/dynamic routing may occur. Such a problem will cause you not to be able to access the module (install policy) until the dynamic routing timeout. The dynamic routing timeout will remove all routes to the VPN tunnel interface learned from the dynamic routing protocols. After this period all connections will work as before (that is, the connection will be routed through static / default route, and will not be encrypted).

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

24

Appendix C - Route Based VPN and Implied rules Connections Appendix D - Route

Appendix D - Route Based VPN - Security Considerations

With Route Based VPN, the VPN routing is not defined by the Security Policy, which means it could be modified without modifying the security policy. This primarily implies that modifying the routing has more impact on security, and therefore proper authorization should be enforced. Anti-spoofing is a greater problem. While it is possible to define anti-spoofing on VPN Tunnel Interfaces, this significantly impairs the advantage of using Route Based VPN. The Anti-Spoofing definition will be static, dependent on the Security Policy, and may be required on all VPN Tunnel Interfaces facing this gateway, meaning there will be more than one place to define what could have been done in one place in Domain Based VPN. In some cases it might make more sense to have several VPN Tunnel Interfaces defined with the same Anti-Spoofing information. This means, that a set of IP addresses may be expected to arrive via one of the VPN Tunnel Interfaces, while dynamic routing can still control which interface is really used. This is a static definition that allows some dynamic flexibility. With Directional VPN Rule Match it is possible to define what traffic arriving via a VPN Tunnel Interface is allowed access, instead of actually specifying the participating IP addresses. This is evidently more secure than trying to keep up with anti-spoofing definitions in a dynamic environment. In the above example (that is, Directional VPN Rule Match page 4), any rule allowing access via the VPN Tunnel Interface could be expressed as a directional rule with the proper community specified in the "from" side of the directional directive. Hence, it does not really matter which IP addresses are allowed access, as long as they arrive via the VPN Community.

NGX (R60)

Route Based VPN Deployments.

Last Update August 30, 2005

25