migration from domain to route based vpn - check point software · summary of contents preface 9...

68
Migration From Domain to Route Based VPN Version NGX R65 January 2007

Upload: others

Post on 06-Feb-2021

2 views

Category:

Documents


0 download

TRANSCRIPT

  • Migration From Domain to RouteBased VPN

    Version NGX R65

    January 2007

    Migration_from_domain_to_Route_Based_VPN.book Page 1 Thursday, February 15, 2007 3:11 PM

  • Migration_from_domain_to_Route_Based_VPN.book Page 2 Thursday, February 15, 2007 3:11 PM

  • © 2003-2007 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 252.227-7013 and FAR 52.227-19.

    TRADEMARKS:

    ©2003-2007 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, Confidence Indexing, ConnectControl, Connectra, Connectra Accelerator Card, Cooperative Enforcement, Cooperative Security Alliance, CoSa, DefenseNet, Dynamic Shielding Architecture, Eventia, Eventia Analyzer, Eventia Reporter, Eventia Suite, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, Hybrid Detection Engine, IMsecure, INSPECT, INSPECT XL, Integrity, Integrity Clientless Security, Integrity SecureClient, InterSpect, IPS-1, IQ Engine, MailSafe, NG, NGX, Open Security Extension, OPSEC, OSFirewall, Policy Lifecycle Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureClient Mobile, SecureKnowledge, SecurePlatform, SecurePlatform Pro, SecuRemote, SecureServer, SecureUpdate, SecureXL, SecureXL Turbocard, Sentivist, 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 Pro, 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. ZoneAlarm is a Check Point Software Technologies, Inc. Company. 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.

    Migration_from_domain_to_Route_Based_VPN.book Page 3 Thursday, February 15, 2007 3:11 PM

  • Migration_from_domain_to_Route_Based_VPN.book Page 4 Thursday, February 15, 2007 3:11 PM

  • Table of Contents 5

    Contents

    Preface Who Should Use This Guide................................................................................ 8Summary of Contents ......................................................................................... 9Related Documentation .................................................................................... 10More Information ............................................................................................. 13

    Chapter 1 Preparing for Migration Overview ......................................................................................................... 16Enable Advanced Routing................................................................................. 17Allow OSPF Traffic........................................................................................... 18Adjust the Rule Base........................................................................................ 19

    Chapter 2 Migration Step-by-Step Migrating Gateways with a Common Management Module.................................... 26Migrating Gateways with a Different Management Module.................................... 27

    Chapter 3 Migration Examples Example 1: Mesh Topology Migration................................................................. 30

    Pre-Migration Configuration ......................................................................... 31Migrating Gateway A and Gateway B ............................................................. 32Migrating Gateway A and Gateway C ............................................................. 38Additional Migration Steps........................................................................... 44Migrating Gateway A and Gateway D ............................................................. 45

    Example 2: Star Topology Migration................................................................... 50Pre-Migration Configuration ......................................................................... 51Migrating Gateway A and Gateway B ............................................................. 51Additional Migration Steps........................................................................... 58

    Example 3: Hybrid Topology Migration ............................................................... 59

    Index...........................................................................................................67

    Migration_from_domain_to_Route_Based_VPN.book Page 5 Thursday, February 15, 2007 3:11 PM

  • 6

    Migration_from_domain_to_Route_Based_VPN.book Page 6 Thursday, February 15, 2007 3:11 PM

  • 7

    Preface PPreface

    In This Chapter

    Who Should Use This Guide page 8

    Summary of Contents page 9

    Related Documentation page 10

    More Information page 13

    Migration_from_domain_to_Route_Based_VPN.book Page 7 Thursday, February 15, 2007 3:11 PM

  • Who Should Use This Guide

    8

    Who Should Use This GuideThis 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.).

    Migration_from_domain_to_Route_Based_VPN.book Page 8 Thursday, February 15, 2007 3:11 PM

  • Summary of Contents

    Preface 9

    Summary of ContentsThis guide contains the following sections and chapters:

    Chapter Description

    Chapter 1, “Preparing for Migration”

    Describes how to prepare the SmartDashboard rule base for migration.

    Chapter 2, “Migration Step-by-Step”

    Describes the process of migrating from Domain to Route Based VPN.

    Chapter 3, “Migration Examples”

    Provides examples of a migration process.

    Migration_from_domain_to_Route_Based_VPN.book Page 9 Thursday, February 15, 2007 3:11 PM

  • Related Documentation

    10

    Related DocumentationThis release includes the following documentation

    TABLE P-1 Check Point suite documentation

    Title Description

    Getting Started Guide The Getting Started guide contains an overview of NGX R65 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.

    Upgrade Guide The Upgrade guide 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 R65.

    SmartCenter Guide The SmartCenter Guide 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.

    Firewall and SmartDefense Guide

    The Firewall and SmartDefense guide is divided into the following topics:

    • Controlling and securing network access.

    • Establishing network connectivity.

    • Using SmartDefense to protect against network and application level attacks.

    • Using Web Intelligence to protect web servers and applications, and integrated web security capabilities.

    • Using Content Vectoring Protocol (CVP) applications for anti-virus protection, and URL Filtering (UFP) applications for limiting access to web sites

    • Securing VoIP traffic

    Migration_from_domain_to_Route_Based_VPN.book Page 10 Thursday, February 15, 2007 3:11 PM

  • Related Documentation

    Preface 11

    Eventia Reporter The Eventia Reporter guide 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 Pro, SecureClient and SmartDefense.

    SmartView Tracker Guide

    The SmartView chapter provides information about how to collect comprehensive information on your network activity in the form of logs. In this chapter you learn how to use SmartView Tracker to audit these logs at any given time, analyze traffic patterns and troubleshoot networking and security issues.

    SecurePlatform Guide The SecurePlatform guide 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.

    Provider-1 Guide The Provider-1 guide 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-1 Check Point suite documentation (continued)

    Title Description

    Migration_from_domain_to_Route_Based_VPN.book Page 11 Thursday, February 15, 2007 3:11 PM

  • Related Documentation

    12

    TABLE P-2 Integrity Server documentation

    Title Description

    Integrity Advanced Server Installation Guide

    Integrity Advanced Server Installation Guide explains how to install, configure, and maintain the Integrity Advanced Server.

    Integrity Advanced Server Administrator Console Reference

    The Integrity Advanced Server Administrator Console Reference guide 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.

    Integrity Advanced Server Administrator Guide

    The Integrity Advanced Server Administrator Guide explains how to managing administrators and endpoint security with Integrity Advanced Server.

    Integrity Advanced Server Gateway Integration Guide

    Integrity Advanced Server Gateway Integration Guide provides information about how to integrating your Virtual Private Network gateway device with Integrity Advanced Server. This guide also contains information regarding deploying the unified SecureClient/Integrity client package.

    Integrity Advanced Server System Requirements

    The Integrity Advanced Server System Requirements provides information about client and server requirements.

    Integrity Agent for Linux Installation and Configuration Guide

    The Integrity Agent for Linux Installation and Configuration Guide explains how to install and configure Integrity Agent for Linux.

    Integrity XML Policy Reference Guide

    The Integrity XML Policy Reference Guide provides the contents of Integrity client XML policy files.

    Integrity Client Management Guide

    The Integrity Client Management Guide explains how to use of command line parameters to control Integrity client installer behavior and post-installation behavior.

    Migration_from_domain_to_Route_Based_VPN.book Page 12 Thursday, February 15, 2007 3:11 PM

  • More Information

    Preface 13

    More Information• For additional technical information about Check Point products, consult Check

    Point’s SecureKnowledge at https://secureknowledge.checkpoint.com/.

    • See the latest version of this document in the User Center at http://www.checkpoint.com/support/technical/documents.

    Migration_from_domain_to_Route_Based_VPN.book Page 13 Thursday, February 15, 2007 3:11 PM

    https://secureknowledge.checkpoint.com/https://secureknowledge.checkpoint.com/http://www.checkpoint.com/support/technical/documentshttp://www.checkpoint.com/support/technical/documents

  • More Information

    14

    Migration_from_domain_to_Route_Based_VPN.book Page 14 Thursday, February 15, 2007 3:11 PM

  • 15

    Chapter 1Preparing for Migration

    In This Chapter

    Overview page 16

    Enable Advanced Routing page 17

    Allow OSPF Traffic page 18

    Adjust the Rule Base page 19

    Migration_from_domain_to_Route_Based_VPN.book Page 15 Thursday, February 15, 2007 3:11 PM

  • Overview

    16

    OverviewRoute Based VPN with an integrated support of dynamic routing protocols is only available on a SecurePlatform Pro operating system.

    Domain Based VPN takes precedence over Route Based VPN during the migration process to ease migration. For this reason, it is important to lay the foundations for Route Based VPN first. Domain Based VPN settings will be deleted at a later time since they are no longer needed.

    It is highly recommended that the migration be performed gradually, preferably two gateways at a time (as shown in the Chapter 3, “Migration Examples”) on the less significant gateways. If all the gateways are migrated together the slightest failure in configuration could cause a major downfall to large portions of the network, or worst, the entire network.

    Local and remote IP addresses for VTIs should be selected from one of three private IP addresses pools as described in RFC 1918:

    Class A private addresses: 10.0.0.0 - 10.255.255.255

    Class B private addresses: 172.16.0.0 - 172.31.255.255

    Class C private addresses: 192.168.0.0 - 192.168.255.255

    To ensure that a proper environment is set for Route Based VPN, the following three global configurations steps must be performed prior to the migration process.

    1. “Enable Advanced Routing” on page 17

    2. “Allow OSPF Traffic” on page 18

    3. “Adjust the Rule Base” on page 19

    Migration_from_domain_to_Route_Based_VPN.book Page 16 Thursday, February 15, 2007 3:11 PM

  • Enable Advanced Routing

    Chapter 1 Preparing for Migration 17

    Enable Advanced RoutingTo use Dynamic Routing, Advanced Routing must be enabled on all gateways designated to work as Route Based VPNs.

    Use the Check Point Configuration tool to enable Advanced Routing as follows:

    1. Type cpconfig and press Enter.

    2. Type 10 to select Advanced Routing.

    3. Type y to enable Advanced Routing.

    4. Type y to restart the Check Point services.

    The following figure demonstrates the process you should follow: Figure 1-1 cpconfig Configuration Tool

    Note - Enabling or disabling Advanced Routing requires restarting all Check Point products.

    Migration_from_domain_to_Route_Based_VPN.book Page 17 Thursday, February 15, 2007 3:11 PM

  • Allow OSPF Traffic

    18

    Allow OSPF TrafficTo enable the OSPF daemon to publish (that is, distribute) its routing information to other gateways within a specific community a rule must be created. By design a firewall will not anything to pass unless it is explicitly allowed.

    For example, the following image depicts a rule that permits OSPF traffic to pass through a community called MyIntranet.

    Migration_from_domain_to_Route_Based_VPN.book Page 18 Thursday, February 15, 2007 3:11 PM

  • Adjust the Rule Base

    Chapter 1 Preparing for Migration 19

    Adjust the Rule BaseThe process of migration requires that encryption domains be removed for some of the gateways because Route Based VPN will not work when gateways contain objects that are a part of the encryption domains. For this reason, the Rule Base must be adjusted to work with this change.

    To get a better understanding of this concept refer to “Example 1” and “Example 2”.

    Example 1

    Consider the possibility that there are two gateways meshed in a community called MyIntranet and each has defined its internal network as its encryption domain. Refer to Figure 1-2 on page 19. To migrate these two gateways their encryption domains must be empty, as shown in Figure 1-3 on page 20. Figure 1-2 Internal Network Defined as an Encryption Domain

    Migration_from_domain_to_Route_Based_VPN.book Page 19 Thursday, February 15, 2007 3:11 PM

  • Adjust the Rule Base

    20

    Figure 1-3 Empty Encryption Domains

    Once the encryption domains for Gateway A and Gateway B are empty, any connection initiated by hosts from Gateway A’s internal network and destined to hosts from Gateway B’s internal network (or to Gateway B itself and vica versa), will not match any rule in which the VPN column contains the MyIntranet community.

    Rules that contain MyIntranet in the VPN column only apply to connections between encryption domains and MyIntranet gateways.

    Example 2

    Consider the possibility that prior to migration there is a rule that allows any Telnet connection within the MyIntranet community, as shown in the following image:

    For this rule to be applicable after the migration is complete, another corresponding directional match rule must be added to the rule base above the original rule.

    The new rule should be identical to the original rule except for the VPN column. The VPN column should contain the following three directional match conditions:

    • MyIntranet > MyIntranet

    • MyIntranet > Internal_clear

    • Internal_clear > MyIntranet

    To add these three directional match conditions to the VPN column perform the following steps:

    1. Select SmartDashboard > Policy > Global Properties.

    Migration_from_domain_to_Route_Based_VPN.book Page 20 Thursday, February 15, 2007 3:11 PM

  • Adjust the Rule Base

    Chapter 1 Preparing for Migration 21

    2. Select VPN > Advanced.

    The following window appears:Figure 1-4 Advanced VPN Properties

    3. Select the Enable VPN Directional Match in VPN Column check box and click OK.

    4. In the rule base duplicate the original rule.

    5. Right-click the VPN column in the new rule and select Edit Cell....

    The following window appears:

    Migration_from_domain_to_Route_Based_VPN.book Page 21 Thursday, February 15, 2007 3:11 PM

  • Adjust the Rule Base

    22

    Figure 1-5 VPN Match Conditions

    6. Select Match traffic in this direction only and click Add.

    The following window appears:Figure 1-6 Directional VPN Match Condition

    7. Select MyIntranet from within the Match on traffic reaching the Gateway from drop-down list.

    Migration_from_domain_to_Route_Based_VPN.book Page 22 Thursday, February 15, 2007 3:11 PM

  • Adjust the Rule Base

    Chapter 1 Preparing for Migration 23

    8. Select MyIntranet from within the Match on traffic reaching the Gateway To drop-down list.

    9. Click OK.

    10. In the VPN Match Conditions window click Add again.

    11. Select MyIntranet from within the Match on traffic reaching the Gateway from drop-down list.

    12. Select Internal_clear from within the Match on traffic reaching the Gateway To drop-down list.

    13. Click OK.

    14. In the VPN Match Conditions window click Add again.

    15. Select Internal_clear from within the Match on traffic reaching the Gateway from drop-down list.

    16. Select MyIntranet from within the Match on traffic reaching the Gateway To drop-down list.

    17. Click OK to close the Directional VPN Match Conditions window.

    18. Click OK to close the VPN Match Conditions window.

    The result of the latter configuration should look as follows:

    19. Select Policy > Install to install the new policy.

    Migration_from_domain_to_Route_Based_VPN.book Page 23 Thursday, February 15, 2007 3:11 PM

  • Adjust the Rule Base

    24

    Migration_from_domain_to_Route_Based_VPN.book Page 24 Thursday, February 15, 2007 3:11 PM

  • 25

    Chapter 2Migration Step-by-Step

    In This Chapter

    Migrating Gateways with a Common Management Module page 26

    Migrating Gateways with a Different Management Module page 27

    Migration_from_domain_to_Route_Based_VPN.book Page 25 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateways with a Common Management Module

    26

    Migrating Gateways with a Common Management Module

    The following list represents the phases that should be performed to convert two gateways within a specific network to work in a Route Based VPN environment, while additional gateways within the same network continue to work in the current environment.

    Phase 1: Select the two gateways that should be migrated to a Route Based VPN environment.

    Phase 2: Create a VTI and connect the two gateways.

    Phase 3: Enable a Dynamic Routing protocol on VTI.

    Phase 4: Verify Dynamic Routing functionality.

    Phase 5: Adjust the VPN routing information with the vpn_route.conf file.

    Phase 6: Terminate Domain Based.

    Phase 7: Set the encryption domains of the two gateways to an empty group.

    For an additional migration repeat phases 1 through 7.

    Migration_from_domain_to_Route_Based_VPN.book Page 26 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateways with a Different Management Module

    Chapter 2 Migration Step-by-Step 27

    Migrating Gateways with a Different Management Module

    The following process performs a Domain Based termination of two gateways with different management modules.

    As shown in the following image, Gateway A and Gateway B are managed by A_manage and B_manage respectively. Gateway A and Gateway B work as a Domain Based VPN environment and should be converted to a Route Based VPN environment.

    1. Select the two gateways that should be migrated to a Route Based VPN environment.

    2. Create a VTI and connect the two gateways.

    3. Enable a Dynamic Routing protocol on VTI. For additional information refer to Migrating Gateway A and Gateway B page 32 step #3.

    4. Verify Dynamic Routing functionality. For additional information refer to Migrating Gateway A and Gateway B page 32 step #4.

    Migration_from_domain_to_Route_Based_VPN.book Page 27 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateways with a Different Management Module

    28

    5. Open the SmartDashboard associated with A_manage (Gateway A's management module).

    6. Set the encryption domain of Gateway B to an empty encryption domain.

    7. Select Policy > Install to install the policy.

    8. Open the SmartDashboard associated with B_manage (Gateway B's management module).

    9. Set the encryption domain of A to an empty encryption domain.

    10. Select Policy > Install to install the policy.

    Migration_from_domain_to_Route_Based_VPN.book Page 28 Thursday, February 15, 2007 3:11 PM

  • 29

    Chapter 3Migration Examples

    In This Chapter

    Example 1: Mesh Topology Migration page 30

    Example 2: Star Topology Migration page 50

    Example 3: Hybrid Topology Migration page 59

    Migration_from_domain_to_Route_Based_VPN.book Page 29 Thursday, February 15, 2007 3:11 PM

  • Example 1: Mesh Topology Migration

    30

    Example 1: Mesh Topology MigrationIn This Section

    To completely migrate this topology the sections above must be performed in the order they appear.

    In this example (refer to Figure 3-1) there are four gateways in a single Mesh community named MyNet. All four gateways work together as Domain Based VPN.

    The result of this migration process should be as follows:

    • Gateway A and Gateway B will work as a Route Based VPN with one another.

    • Gateway A and Gateway B will work as a Domain Based VPN with other gateways (for example, Gateway C and Gateway D).

    • Gateway C and Gateway D will work as a Domain Based VPN with one another.

    Pre-Migration Configuration page 31

    Migrating Gateway A and Gateway B page 32

    Migrating Gateway A and Gateway C page 38

    Additional Migration Steps page 44

    Migrating Gateway A and Gateway D page 45

    Migration_from_domain_to_Route_Based_VPN.book Page 30 Thursday, February 15, 2007 3:11 PM

  • Pre-Migration Configuration

    Chapter 3 Migration Examples 31

    Figure 3-1 Meshed Topology

    Pre-Migration ConfigurationApply the following pre-migration configurations:

    1. “Enable Advanced Routing” on page 17

    2. “Allow OSPF Traffic” on page 18

    3. “Adjust the Rule Base” on page 19

    Migration_from_domain_to_Route_Based_VPN.book Page 31 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    32

    Migrating Gateway A and Gateway BThe end of this migration process should yield the following:

    • Gateway A and Gateway B work as a Route Based VPN with each other.

    • Gateway A and Gateway B remain a Domain Based VPN with other gateways, (for example, Gateway C and Gateway D).

    • Gateway C and Gateway D work as a Domain Based VPN with each other.

    1. Select Gateway A and Gateway B

    2. Create VTIs that connect Gateway A and Gateway B to one another. Refer to Figure 3-2 for a graphical representation of this configuration.

    a. On Gateway A create a numbered VTI named to_gwB whose peer gateway is Gateway B.

    Local Address: 10.10.1.1

    Remote IP Address: 10.10.2.2

    b. On Gateway B create a numbered VTI named to_gwA whose peer gateway is Gateway A.

    Local Address: 10.10.2.2

    Remote IP Address: 10.10.1.1

    Migration_from_domain_to_Route_Based_VPN.book Page 32 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    Chapter 3 Migration Examples 33

    Figure 3-2 VTIs connecting Gateway A and Gateway B

    3. Enable Dynamic Routing (OSPF) on the VTIs created in step 2 to:

    • to_gwB on Gateway A. For example:

    Note - For additional information about VPN Shell CLI commands refer to the Check Point Command Line Interface Guide.

    Migration_from_domain_to_Route_Based_VPN.book Page 33 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    34

    • to_gwA on Gateway B. For example:

    4. Verify proper OSPF functionality through the following series of commands:

    a. Enter GateD’s CLI on Gateway A and Gateway B.

    b. Type the show ip ospf neighbor command, as demonstrated in the following images:

    • On Gateway A

    • On Gateway B

    Note - The redistribute command shown in the above images is only an example. Please refer to the Check Point Advanced Routing Suite - Command Line Interface Guide for more information on advanced routing commands.

    Migration_from_domain_to_Route_Based_VPN.book Page 34 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    Chapter 3 Migration Examples 35

    The show ip ospf neighbor command displays the OSPF daemon’s neighbors. The latter images demonstrate how both gateways recognize the other as a neighbor.

    c. In the GateD’s CLI type the show ip route ospf command, as demonstrated in the following images. This command displays the OSPF’s routing table:

    • On Gateway A the designated interface for Gateway B’s external and internal networks is to_gwB.

    • On Gateway B the designated interface for Gateway A’s external and internal networks is to_gwA.

    d. Type the ip route get command to display the designated interface for outbound connection to the host whose address is .

    • On Gateway A, 172.20.30.200 is an arbitrary IP address of Gateways B's internal network. The designated interface for this address is to_gwB.

    Warning - Verify that the state of each neighbor is Full.

    Migration_from_domain_to_Route_Based_VPN.book Page 35 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    36

    • On Gateway B, 172.17.10.200 is an arbitrary IP address of Gateway A's internal network. The designated interface for this address is to_gwA.

    5. Perform the following VPN routing adjustments so that both Gateway A and Gateway B function as a Domain Based VPN with other gateways after the migration process is complete:

    • In the vpn_route.conf file Gateway A and Gateway B should “know” their own encryption domains.

    • In the vpn_route.conf file Gateway C and Gateway D should “know” Gateway A and Gateway B’s encryption domains.

    a. Open /opt/CPsuite-R60/fw1/conf/vpn_route.conf on the management gateway (that is, Gateway A) and add the following six lines:

    gwA_Internal gwA gwA

    gwB_Internal gwB gwB

    gwA_Internal gwA gwC

    gwA_Internal gwA gwD

    gwB_Internal gwB gwC

    gwB_Internal gwB gwD

    The first two lines notify Gateway A and Gateway B about their own encryption domains. The next four lines notify Gateway C and Gateway D about Gateway A and Gateway B’s encryptions domains.

    6. Apply Domain Based termination. This can only be done once the foundations for Route Based VPN are established for Gateway A and Gateway B.

    a. Open SmartDashboard.

    b. Create an empty group.

    c. Set the encryption domains of Gateway A and Gateway B so that they constitute an empty group.

    The migration of Gateway A and Gateway B is now complete and the results are:

    • Gateway A and Gateway B work as a Route Based VPN with each other.

    • Gateway A and Gateway B remain a Domain Based VPN with other gateways, (for example, Gateway C and Gateway D).

    • Gateway C and Gateway D work as a Domain Based VPN with each other.

    Figure 3-3 is an image of the resulting topology.

    Migration_from_domain_to_Route_Based_VPN.book Page 36 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    Chapter 3 Migration Examples 37

    Figure 3-3 Result of Migrating Gateway A and Gateway B

    Migration_from_domain_to_Route_Based_VPN.book Page 37 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway C

    38

    Migrating Gateway A and Gateway CThe end of this migration process should yield the following:

    • Gateway A will work as a Route Based VPN with Gateway B and Gateway C.

    • Gateway A will remain a Domain Based VPN with Gateway D.

    • Gateway B will remain a Domain Based VPN with Gateway C and Gateway D.

    • Gateway C and Gateway D will work as a Domain Based VPN with each other.

    1. Select Gateway A and Gateway C.

    2. Create VTIs that connect Gateway A and Gateway C to one another. Refer to Figure 3-2 for a graphical representation of this configuration.

    a. On Gateway A create a numbered VTI named to_gwC whose peer gateway is Gateway C.

    Local Address: 10.10.1.1

    Remote IP Address: 10.10.3.3

    b. On Gateway C create a numbered VTI named to_gwA whose peer gateway is Gateway A.

    Local Address: 10.10.3.3

    Remote IP Address: 10.10.1.1

    Migration_from_domain_to_Route_Based_VPN.book Page 38 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway C

    Chapter 3 Migration Examples 39

    Figure 3-4 Virtual Tunnel Connecting Gateway A and Gateway C

    3. Enable Dynamic Routing (OSPF) on the VTIs created in step 2 to:

    • to_gwC on Gateway A. For example

    Migration_from_domain_to_Route_Based_VPN.book Page 39 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway C

    40

    • to_gwA on Gateway C. For example

    4. Verify proper OSPF functionality through the following series of commands:

    a. Enter GateD’s CLI on Gateway A and Gateway C.

    b. Type the show ip ospf neighbor command, as demonstrated in the following images:

    • On Gateway A

    • On Gateway C

    Note - The router-id and redistribute commands should only be issued once per router. These two commands are not issued again on Gateway A’s router in the latter example. Refer to the Check Point Advanced Routing Suite - Command Line Interface Guide for additional information.

    Migration_from_domain_to_Route_Based_VPN.book Page 40 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway C

    Chapter 3 Migration Examples 41

    The show ip ospf neighbor command displays the OSPF daemon’s neighbors. The latter images demonstrate how both gateways recognize the other as a neighbor.

    c. In the GateD’s CLI type the show ip route ospf command, as demonstrated in the following images. This command displays the OSPF’s routing table:

    • On Gateway A the designated interface for Gateway C’s external and internal networks is to_gwC

    • On Gateway C the designated interface for Gateway A’s external and internal networks is to_gwA

    5. Perform the following VPN routing adjustments so that Gateway C works as a Domain Based VPN with Gateway B and Gateway D.

    • In the vpn_route.conf file Gateway C should “know” its own encryption domain.

    • In the vpn_route.conf file Gateway C and Gateway D should “know” Gateway B and Gateway D must know Gateway C’s encryption domain.

    Warning - Verify that the state of each neighbor is Full.

    Note - At this point Gateway A should recognize two neighbors (that is, both Gateway B and Gateway C).

    Migration_from_domain_to_Route_Based_VPN.book Page 41 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway C

    42

    a. Open /opt/CPsuite-R60/fw1/conf/vpn_route.conf on the management gateway (that is, Gateway A) and verify that the file now contains the following six lines:

    gwA_Internal gwA gwA

    gwB_Internal gwB gwB

    gwA_Internal gwA gwC

    gwA_Internal gwA gwD

    gwB_Internal gwB gwC

    gwB_Internal gwB gwD

    b. Since Gateway A now works as a Rout Based VPN with Gateway C, the third line in the vpn_route.conf file should be deleted.

    c. Add the following three lines to the file:

    gwC_Internal gwC gwC

    gwC_Internal gwC gwB

    gwC_Internal gwC gwD

    The resulting file content should now appear as follows:

    gwA_Internal gwA gwA

    gwB_Internal gwB gwB

    gwA_Internal gwA gwD

    gwB_Internal gwB gwC

    gwB_Internal gwB gwD

    gwC_Internal gwC gwC

    gwC_Internal gwC gwB

    gwC_Internal gwC gwD

    6. Apply Domain Based termination. This can only be done once the foundations for Route Based VPN are established for Gateway A and Gateway B.

    a. Open SmartDashboard.

    b. Set the encryption domains of Gateway C so that they constitute an empty group.

    c. Install Policy.

    Migration_from_domain_to_Route_Based_VPN.book Page 42 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway C

    Chapter 3 Migration Examples 43

    The migration of Gateway A and Gateway C is now complete and the results are:

    • Gateway A works as a Route Based VPN with Gateway B and Gateway C.

    • Gateway A works as a Domain Based VPN with Gateway D.

    • Gateway B works as a Domain Based VPN with Gateway C and Gateway D.

    • Gateway C and Gateway D work as a Domain Based VPN with each other.

    Figure 3-5 is an image of the resulting topology.Figure 3-5 Result of Migrating Gateway A and Gateway C

    Migration_from_domain_to_Route_Based_VPN.book Page 43 Thursday, February 15, 2007 3:11 PM

  • Additional Migration Steps

    44

    Additional Migration StepsTo further migrate the topology refer to Migrating Gateways with a Different Management Module page 27.

    Once a pair of gateways is converted to work as Route Based VPN, neither one of the two gateways should know the encryption domain of the other. If there are entries in the vpn_route.conf file (possibly from a previous migration processes) that expose an encryption domain they should be deleted (as demonstrated in “Migrating Gateway A and Gateway C” on page 38).

    When the migration of an entire Mesh topology is performed properly the vpn_route.conf file will not contain encryption domains (as demonstrated in “Migrating Gateway A and Gateway D” on page 45).

    Migration_from_domain_to_Route_Based_VPN.book Page 44 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway D

    Chapter 3 Migration Examples 45

    Migrating Gateway A and Gateway DAt the end of this migration process the entire community should work as Route Based VPN, as shown in Figure 3-6.Figure 3-6 Result of Completed Migration Process

    1. Select Gateway A and Gateway D.

    2. Create VTIs that connect Gateway A and Gateway D to one another. Refer to Figure 3-7 for a graphical representation of this configuration.

    a. On Gateway A create a numbered VTI named to_gwD whose peer gateway is Gateway D.

    Local Address: 10.10.1.1

    Remote IP Address: 10.10.4.4

    b. On Gateway D create a numbered VTI named to_gwA whose peer gateway is Gateway A.

    Local Address: 10.10.4.4

    Migration_from_domain_to_Route_Based_VPN.book Page 45 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway D

    46

    Remote IP Address: 10.10.1.1

    Figure 3-7 Virtual Tunnel Connecting Gateway A and Gateway D

    3. Enable Dynamic Routing (OSPF) on the VTIs created in step 2 to:

    • to_gwD on Gateway A. For example

    Migration_from_domain_to_Route_Based_VPN.book Page 46 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway D

    Chapter 3 Migration Examples 47

    • to_gwA on Gateway D. For example

    4. Verify proper OSPF functionality through the following series of commands:

    a. Enter GateD’s CLI on Gateway A and Gateway D.

    b. Type the show ip ospf neighbor command, as demonstrated in the following images:

    • On Gateway A

    • On Gateway D

    Note - The router-id and redistribute commands should only be issued once per router. These two commands are not issued again on Gateway A and Gateway D’s router in the latter example. Refer to the Check Point Advanced Routing Suite - Command Line Interface Guide for additional information.

    Migration_from_domain_to_Route_Based_VPN.book Page 47 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway D

    48

    The show ip ospf neighbor command displays the OSPF daemon’s neighbors. The latter images demonstrate how both gateways recognize the other as a neighbor.

    c. In the GateD’s CLI type the show ip route ospf command, as demonstrated in the following images. This command displays the OSPF’s routing table:

    • On Gateway A the designated interface for Gateway D’s external and internal networks is to_gwD

    • On Gateway D the designated interface for Gateway A’s external and internal networks is to_gwA

    Warning - Verify that the state of each neighbor is Full.

    Note - At this point all four gateways should recognize one another.

    Migration_from_domain_to_Route_Based_VPN.book Page 48 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway D

    Chapter 3 Migration Examples 49

    5. Perform the following VPN routing adjustments:

    a. Open /opt/CPsuite-R60/fw1/conf/vpn_route.conf on the management gateway (that is, Gateway A) and verify that the file now contains the following six lines:

    gwA_Internal gwA gwA

    gwA_Internal gwA gwD

    gwD_Internal gwD gwD

    gwD_Internal gwD gwA

    gwB_Internal gwB gwB

    gwC_Internal gwC gwC

    b. Since Gateway A now works as a Route Based VPN with Gateway D, the second and fourth lines must be deleted. In addition, since there are no additional gateways that still work as Domain Based VPN with Gateways A, B, C and D, lines one, three, five and six should be deleted as well.

    The vpn_route.conf file should now be empty of all entries.

    6. Apply Domain Based termination. This can only be done once the foundations for Route Based VPN are established for Gateway A and Gateway B.

    a. Open SmartDashboard and install Policy in order to apply the changes made to the vpn_route.conf file.

    The migration of Gateway A and Gateway D is now complete.

    Migration_from_domain_to_Route_Based_VPN.book Page 49 Thursday, February 15, 2007 3:11 PM

  • Example 2: Star Topology Migration

    50

    Example 2: Star Topology MigrationIn This Section

    To completely migrate this topology the sections above must be performed in the order they appear.

    In this example (refer to Figure 3-8) there are four gateways in a single Star community named MyStar. All four gateways work together as Domain Based VPN.

    • Gateway B is the center gateway (hub).

    • Gateway A, Gateway C and Gateway D are satellites (spokes).Figure 3-8 Star Topology

    Pre-Migration Configuration page 51

    Migrating Gateway A and Gateway B page 51

    Additional Migration Steps page 58

    Migration_from_domain_to_Route_Based_VPN.book Page 50 Thursday, February 15, 2007 3:11 PM

  • Pre-Migration Configuration

    Chapter 3 Migration Examples 51

    Pre-Migration ConfigurationApply the following pre-migration configurations:

    1. “Enable Advanced Routing” on page 17

    2. “Allow OSPF Traffic” on page 18

    3. “Adjust the Rule Base” on page 19

    Migrating Gateway A and Gateway BThe end of this migration process should yield the following:

    • Gateway A and Gateway B will work as a Route Based VPN with one another.

    • Gateway C and Gateway D will each work as a Domain Based VPN with Gateway B.

    1. Select Gateway A and Gateway B

    2. Create VTIs that connect Gateway A and Gateway B to one another. Refer to Figure 3-2 for a graphical representation of this configuration.

    a. On Gateway A create a numbered VTI named to_gwB whose peer gateway is Gateway B.

    Local Address: 10.10.1.1

    Remote IP Address: 10.10.2.2

    b. On Gateway B create a numbered VTI named to_gwA whose peer gateway is Gateway A.

    Local Address: 10.10.2.2

    Remote IP Address: 10.10.1.1

    Migration_from_domain_to_Route_Based_VPN.book Page 51 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    52

    Figure 3-9 VTIs connecting Gateway A and Gateway B

    3. With GateD’s CLI enable Dynamic Routing (OSPF) on the VTIs created in step 2 to:

    • to_gwB on Gateway A.

    • to_gwA on Gateway B.

    When configuring OSPF on gateways in a Star community it is recommended that you place center gateways in the backbone area (Area 0). Each satellite gateways should be placed as a ABR (Area Border Routers), between the backbone area and a different non-zero area.

    In our example (as shown in Figure 3-10) Gateway B will reside in the backbone area (Area 0) and Gateway A, Gateway C and Gateway D will each act as an ABR.

    Note - For additional information about VPN Shell CLI commands refer to the Check Point Command Line Interface Guide.

    Migration_from_domain_to_Route_Based_VPN.book Page 52 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    Chapter 3 Migration Examples 53

    Figure 3-10 Dynamic Routing (OSPF)

    4. Verify proper OSPF functionality through the following series of commands:

    a. Enter GateD’s CLI on Gateway A and Gateway B.

    b. Type the show ip ospf neighbor command, as demonstrated in the following images:

    • On Gateway A

    Note - The redistribute command shown in the above images is only an example. Please refer to the Check Point Advanced Routing Suite - Command Line Interface Guide for more information on advanced routing commands.

    Migration_from_domain_to_Route_Based_VPN.book Page 53 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    54

    • On Gateway B

    The show ip ospf neighbor command displays the OSPF daemon’s neighbors. The latter images demonstrate how both gateways recognize the other as a neighbor.

    c. In the GateD’s CLI type the show ip route ospf command, as demonstrated in the following images. This command displays the OSPF’s routing table:

    • On Gateway A the designated interface for Gateway B’s external and internal networks is to_gwB.

    • On Gateway B the designated interface for Gateway A’s external and internal networks is to_gwA.

    Warning - Verify that the state of each neighbor is Full.

    Migration_from_domain_to_Route_Based_VPN.book Page 54 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    Chapter 3 Migration Examples 55

    d. Type the ip route get command to display the designated interface for outbound connection to the host whose address is .

    • On Gateway A, 172.20.30.200 is an arbitrary IP address of Gateways B's internal network. The designated interface for this address is to_gwB.

    • On Gateway B, 172.17.10.200 is an arbitrary IP address of Gateway A's internal network. The designated interface for this address is to_gwA.

    5. Perform the following VPN routing adjustments so that both Gateway A and Gateway B function as a Domain Based VPN with other gateways after the migration process is complete.

    Gateway C and Gateway D must each know Gateway A’s encryption domains.

    If one of the two “through center” VPN routing options is selected (as shown in Figure 3-11), then several VPN routing adjustments must be performed in the $FWDIR/conf/vpn_route.conf file.

    Migration_from_domain_to_Route_Based_VPN.book Page 55 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    56

    Figure 3-11 Star Community Properties

    a. Open /opt/CPsuite-R60/fw1/conf/vpn_route.conf on the management gateway (that is, Gateway A) and add the following two lines:

    gwB_Internal gwB gwC

    gwB_Internal gwB gwD

    Migration_from_domain_to_Route_Based_VPN.book Page 56 Thursday, February 15, 2007 3:11 PM

  • Migrating Gateway A and Gateway B

    Chapter 3 Migration Examples 57

    6. Apply Domain Based termination.

    a. Open SmartDashboard.

    b. Create an empty group.

    c. Set the encryption domain of Gateway A so that it is an empty group.

    d. Install Policy.

    The migration of Gateway A and Gateway B is now complete and the results are:

    • Gateway A and Gateway B work as a Route Based VPN with each other.

    • Gateway C and Gateway D remain a Domain Based VPN with Gateway B and Gateway A as long as routing through the center is enabled.

    • Gateway C and Gateway D work as a Domain Based VPN with each other.

    Figure 3-12 is an image of the resulting topology.Figure 3-12 Result of Migrating Gateway A and Gateway B

    Migration_from_domain_to_Route_Based_VPN.book Page 57 Thursday, February 15, 2007 3:11 PM

  • Additional Migration Steps

    58

    Additional Migration StepsTo further migrate the topology refer to Migrating Gateways with a Different Management Module page 27.

    After migration of the last Center-Satellite pair is complete, encryption domains of the center gateways can be emptied through SmartDashboard.

    Warning - In a Star topology encryption domains belonging to the center gateways should be emptied last.

    Migration_from_domain_to_Route_Based_VPN.book Page 58 Thursday, February 15, 2007 3:11 PM

  • Example 3: Hybrid Topology Migration

    Chapter 3 Migration Examples 59

    Example 3: Hybrid Topology Migration

    In this example (refer to Figure 3-13) there are six gateways in a Hybrid:

    • Gateway A, Gateway B and Gateway C reside in a Star community named MyStar.

    • Gateway B is in the center (hub).

    • Gateway A and Gateway C are satellites (spokes)

    • Gateway B, Gateway D, Gateway E and Gateway F reside in a Mesh community name MyMesh.

    Figure 3-13 Hybrid Migration

    Migration of a hybrid network is no different form the migration of a Mesh or a Star network.

    When selecting a pair of gateways for migration identify their common community and apply the migration process according to the common community's type (Mesh or Star) as demonstrated in the first two examples in this chapter

    Migration_from_domain_to_Route_Based_VPN.book Page 59 Thursday, February 15, 2007 3:11 PM

  • Example 3: Hybrid Topology Migration

    60

    Migration_from_domain_to_Route_Based_VPN.book Page 60 Thursday, February 15, 2007 3:11 PM

  • 61

    THIRD PARTY TRADEMARKS AND COPYRIGHTS

    Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrust’s logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust.

    Verisign is a trademark of Verisign Inc.

    The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided “as is” without express or implied warranty. Copyright © Sax Software (terminal emulation only).

    The following statements refer to those portions of the software copyrighted by Carnegie Mellon University.

    Copyright 1997 by Carnegie Mellon University. All Rights Reserved.

    Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

    The following statements refer to those portions of the software copyrighted by The Open Group.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).

    THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright © 1998 The Open Group.

    Migration_from_domain_to_Route_Based_VPN.book Page 61 Thursday, February 15, 2007 3:11 PM

  • 62

    The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

    1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

    2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

    3. This notice may not be removed or altered from any source distribution.

    The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

    The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.GDChart is free for use in your applications and for chart generation. YOU MAY NOT re-distribute or represent the code as your own. Any re-distributions of the code MUST reference the author, and include any and all original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41-RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999, 2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson ([email protected]). Portions relating to gdft.c copyright 2001, 2002 John Ellson ([email protected]). Portions relating to JPEG and to color quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more information. Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande. Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application, provided that this notice is present in user-accessible supporting documentation. This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all programs that utilize the library. Credit must be given in user-accessible documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying documentation. Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software Corporation for their prior contributions.

    Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

    The curl license

    COPYRIGHT AND PERMISSION NOTICE

    Copyright (c) 1996 - 2004, Daniel Stenberg, .All rights reserved.

    Permission to use, copy, modify, and distribute this software for any purpose

    with or without fee is hereby granted, provided that the above copyright

    notice and this permission notice appear in all copies.

    Migration_from_domain_to_Route_Based_VPN.book Page 62 Thursday, February 15, 2007 3:11 PM

  • 63

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.

    The PHP License, version 3.0

    Copyright (c) 1999 - 2004 The PHP Group. All rights reserved.

    Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met:

    1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

    2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

    3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].

    4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from [email protected]. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

    5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.

    6. Redistributions of any form whatsoever must retain the following acknowledgment:

    "This product includes PHP, freely available from ".

    THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via Email at [email protected].

    For more information on the PHP Group and the PHP project, please see . This product includes the Zend Engine, freely available at .

    This product includes software written by Tim Hudson ([email protected]).

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS

    INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd

    Migration_from_domain_to_Route_Based_VPN.book Page 63 Thursday, February 15, 2007 3:11 PM

  • 64

    Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved.

    Confidential Copyright Notice

    Except as stated herein, none of the material provided as a part of this document may be copied, reproduced, distrib-uted, republished, downloaded, displayed, posted or transmitted in any form or by any means, including, but not lim-ited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of NextHop Technologies, Inc. Permission is granted to display, copy, distribute and download the materials in this doc-ument for personal, non-commercial use only, provided you do not modify the materials and that you retain all copy-right and other proprietary notices contained in the materials unless otherwise stated. No material contained in this document may be "mirrored" on any server without written permission of NextHop. Any unauthorized use of any material contained in this document may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes. Permission terminates automatically if any of these terms or condi-tions are breached. Upon termination, any downloaded and printed materials must be immediately destroyed.

    Trademark Notice

    The trademarks, service marks, and logos (the "Trademarks") used and displayed in this document are registered and unregistered Trademarks of NextHop in the US and/or other countries. The names of actual companies and products mentioned herein may be Trademarks of their respective owners. Nothing in this document should be construed as granting, by implication, estoppel, or otherwise, any license or right to use any Trademark displayed in the document. The owners aggressively enforce their intellectual property rights to the fullest extent of the law. The Trademarks may not be used in any way, including in advertising or publicity pertaining to distribution of, or access to, materials in

    this document, including use, without prior, written permission. Use of Trademarks as a "hot" link to any website is prohibited unless establishment of such a link is approved in advance in writing. Any questions concerning the use of these Trademarks should be referred to NextHop at U.S. +1 734 222 1600.

    U.S. Government Restricted Rights

    The material in document is provided with "RESTRICTED RIGHTS." Software and accompanying documentation are provided to the U.S. government ("Government") in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. The Government's rights to use, modify, reproduce, release, perform, display or disclose are

    restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and Noncommercial Computer Soft-ware Documentation clause at DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in Data-General clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial

    Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987).

    Use of the material in this document by the Government constitutes acknowledgment of NextHop's proprietary rights in them, or that of the original creator. The Contractor/Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in applicable laws and regulations.

    Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty

    THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRANTIES,

    EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR ANY OTHER PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHERWISE RESPECTING, THE MATERIAL IN THIS DOCUMENT.

    Limitation of Liability

    Migration_from_domain_to_Route_Based_VPN.book Page 64 Thursday, February 15, 2007 3:11 PM

  • 65

    UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR THE INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS IN THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT FULLY APPLY TO YOU.

    Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved.

    BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC"))

    Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release

    PCRE LICENCE

    PCRE is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. Release 5 of PCRE is distributed under the terms of the "BSD" licence, as specified below. The documentation for PCRE, supplied in the "doc" directory, is distributed under the same terms as the software itself.

    Written by: Philip Hazel

    University of Cambridge Computing Service, Cambridge, England. Phone:

    +44 1223 334714.

    Copyright (c) 1997-2004 University of Cambridge All rights reserved.

    Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

    * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

    * Neither the name of the University of Cambridge nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    Eventia Reporter includes software whose copyright is owned by, or licensed from, MySQL AB.

    Migration_from_domain_to_Route_Based_VPN.book Page 65 Thursday, February 15, 2007 3:11 PM

  • 66

    Migration_from_domain_to_Route_Based_VPN.book Page 66 Thursday, February 15, 2007 3:11 PM

  • February 2007 67

    Index

    Migration_from_domain_to_Route_Based_VPN.book Page 67 Thursday, February 15, 2007 3:11 PM

  • 68

    Migration_from_domain_to_Route_Based_VPN.book Page 68 Thursday, February 15, 2007 3:11 PM

    ContentsPrefaceWho Should Use This GuideSummary of ContentsRelated DocumentationMore InformationPreparing for MigrationOverviewEnable Advanced RoutingAllow OSPF TrafficAdjust the Rule Base

    Migration Step-by-StepMigrating Gateways with a Common Management ModuleMigrating Gateways with a Different Management Module

    Migration ExamplesExample 1: Mesh Topology MigrationPre-Migration ConfigurationMigrating Gateway A and Gateway BMigrating Gateway A and Gateway CAdditional Migration StepsMigrating Gateway A and Gateway D

    Example 2: Star Topology MigrationPre-Migration ConfigurationMigrating Gateway A and Gateway BAdditional Migration Steps

    Example 3: Hybrid Topology Migration

    Index