Professional Documents
Culture Documents
VSX5000-InstlGuide N450000590r001
VSX5000-InstlGuide N450000590r001
Supplement to the Check Point VPN-1 Power VSX NGX R65 Guide
COPYRIGHT 2008 Nokia. All rights reserved. Rights reserved under the copyright laws of the United States. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the United States 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. Notwithstanding any other license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the United States Government regarding its use, reproduction, and disclosure are as set forth in the Commercial Computer Software-Restricted Rights clause at FAR 52.227-19. IMPORTANT NOTE TO USERS This software and hardware is provided by Nokia Inc. as is and any express or implied warranties, including, but not limited to, implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall Nokia, or its affiliates, subsidiaries or suppliers 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. Nokia reserves the right to make changes without further notice to any products herein. TRADEMARKS Nokia is a registered trademark of Nokia Corporation. Other products mentioned in this document are trademarks or registered trademarks of their respective holders.
070101
Nokia Virtual Firewall for Check Point NGX Installation and Configuration Guide
Nokia Contact Information Corporate Headquarters Web Site Telephone Fax Mail Address http://www.nokia.com 1-888-477-4566 or 1-650-625-2000 1-650-691-2170 Nokia Inc. 313 Fairchild Drive Mountain View, California 94043-2215 USA
Regional Contact Information Americas Nokia Inc. Tel: 1-877-997-9199 313 Fairchild Drive Outside USA and Canada: +1 512-437-7089 Mountain View, CA 94043-2215 email: info.ipnetworking_americas@nokia.com USA Tel: UK: +44 161 601 8908 Tel: France: +33 170 708 166 email: info.ipnetworking_emea@nokia.com Tel: +65 6588 3364 email: info.ipnetworking_apac@nokia.com
Europe, Nokia House, Summit Avenue Middle East, Southwood, Farnborough and Africa Hampshire GU14 ONG UK Asia-Pacific 438B Alexandra Road #07-00 Alexandra Technopark Singapore 119968 Nokia Customer Support Web Site: Email: Americas Voice: Fax: Asia-Pacific Voice: Fax: +65-67232999 +65-67232897 1-888-361-5030 or 1-613-271-6721 1-613-271-8782
https://support.nokia.com/ tac.support@nokia.com Europe Voice: Fax: +44 (0) 125-286-8900 +44 (0) 125-286-5666
050602
Nokia Virtual Firewall for Check Point NGX Installation and Configuration Guide
Nokia Virtual Firewall for Check Point NGX Installation and Configuration Guide
Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 In This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conventions This Guide Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 13 14 14 14 15
Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Basic Nokia Virtual Firewall for Check Point VSX NGX R65 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Obtaining Check Point Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18 18 19
Configuring Virtual Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Creating a Virtual Switch Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Virtual Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Virtual Ethernet Interfaces to a Virtual Switch . . . . . . . . . . . . . . . . . . . . . . . Deleting a Virtual Switch Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Virtual Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 23 23 23 24
Planning a VRRP HA Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Hardware Platform Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firewall Synchronization Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topology and IP Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of Supported VSX Cluster Configurations . . . . . . . . . . . . . . . . . . . . . . . . Example 1: DMI and EVR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 2: DMI and VSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 3: DMI, EVR, and IVR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 4: DMI and No Virtual Router Configuration . . . . . . . . . . . . . . . . . . . . . . Example 5: DMI, EVR, IVR, and DMZ Configuration . . . . . . . . . . . . . . . . . . . . . . Example 6: DMI with Internet Access to VSX Gateway . . . . . . . . . . . . . . . . . . . . Example 7: Non-DMI with EVR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Configuring the VSX Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26 26 26 27 29 31 33 35 37 39 42
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
4 Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Using the VSX Configuration Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Using the cpconfig Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Managing the VSX Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 Installing the Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Installing Management Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6 Installing the VSX Management Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Testing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Next Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7 Configuring the VSX VRRP Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Adding a Customer and a Customer Management Add-On . . . . . . . . . . . . . . . . . . Adding and Configuring the VRRP Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Virtual System for the VRRP Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring VRRP Active-Active Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing Up Your VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 56 67 73 75
Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway . . . . . 77 Adding Interfaces to VRRP Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring Routing and Routing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Multiple Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Routing Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Gateway to Ignore Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CLI Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual IP Address Support for VRRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OSPF Virtual Link and VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternate Area Border Router Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of OSPF Configuration in a VRRP Setup . . . . . . . . . . . . . . . . . . . . . . Example 1: OSPF with an EVR and a VS in a VRRP Setup. . . . . . . . . . . . . . . Example 2: OSPF with an EVR, IVR, and a VS in a VRRP Setup . . . . . . . . . . 84 84 85 85 86 86 86 87 88 88 88 89 89 90 93 93 96
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Example 3: OSPF with a VS and no EVR in a VRRP Setup . . . . . . . . . . . . . . . 98 Example of OSPF Configuration on a Nokia Virtual Firewall for Check Point VSX Standalone Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Configuring OSPF on Nokia Virtual Firewall for Check Point VSX Standalone Gateway Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Configuring OSPF on Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Configuring OSPF on Nokia Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Enabling RIP for Nokia Virtual Firewall for Check Point VSX . . . . . . . . . . . . . . . 102 RIP 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Network Mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 RIP 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Network Mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Auto Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Voyager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 CLI Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Virtual IP Address Support for VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Configuring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Configuring RIP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Configuring Auto-Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Example of RIP Configuration in a VRRP Setup with an EVR and a VS . . . . . . 107 Configuring RIP on the EVR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Configuring RIP on a VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 CLI Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Configuring Virtual IP Support for VRRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Configuring Dense-Mode PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Disabling PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Setting Advanced Options for Dense-Mode PIM (Optional) . . . . . . . . . . . . . . . . 113 Configuring Sparse-Mode PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Configuring High-Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Configuring this Router as a Candidate Bootstrap and Candidate Rendezvous Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Configuring a PIM-SM Static Rendezvous Point. . . . . . . . . . . . . . . . . . . . . . . . . 119 Setting Advanced Options for Sparse-Mode PIM (Optional). . . . . . . . . . . . . . . . 120 Debugging PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Example of PIM Configuration in a VRRP Setup . . . . . . . . . . . . . . . . . . . . . . . . 124 Configuring PIM-SM on the EVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Configuring PIM-SM on the VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Voyager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Configuring IGMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling BGP on Nokia Virtual Firewall for Check Point VSX . . . . . . . . . . . . . . CLI Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Sessions (Internal and External) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Path Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Multi-Exit Discriminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Interactions with IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inbound BGP Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Redistribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Reflection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EBGP Multihop Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Support for Virtual IP for VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Memory Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Memory Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of BGP Configuration in a VRRP Setup . . . . . . . . . . . . . . . . . . . . . Example 1: BGP Configuration in a VRRP Setup with an EVR and a VS. . . . Example 2: BGP Configuration in a VRRP Setup with a VS Only. . . . . . . . . . Examples of BGP Configuration on a Standalone Gateway . . . . . . . . . . . . . . . Example 1: BGP Configuration in Standalone Setup With an EVR and a VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 2: BGP Configuration in a Standalone Setup with a VR and No EVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Neighbors Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IBGP on Nokia Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IBGP on Nokia Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IBGP on Nokia Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Nokia Platform C as an IBGP Peer to Nokia Platform A . . . . . . . Configuring Nokia Platform A as an IBGP Peer to Nokia Platform C . . . . . . . Configuring EBGP on Nokia Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring EBGP on Nokia Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring EBGP on Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring EBGP on Nokia Platform E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Path Filtering Based on Communities Example . . . . . . . . . . . . . . . . . . . . . . . . . BGP Multi Exit Discriminator Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Default MED for Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . .
128 130 130 131 131 132 133 133 134 134 135 135 136 137 138 139 139 140 140 140 141 141 142 149 150 151 151 152 152 153 153 154 154 154 154 155 155 156 156 157 157
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Configuring MED Values for all Peers of AS200 . . . . . . . . . . . . . . . . . . . . . . . Configuring MED Values for each External BGP Peer for Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring MED Values and a Route Redistribution Policy on Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Local Preference Value Example . . . . . . . . . . . . . . . . . . . . . . . . . BGP Confederation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Reflector Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform B as Route Reflector . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform C as IBGP Peer of Platform B . . . . . . . . . . . . . . . . . . . . Configuring Platform D as IBGP Peer of Platform B . . . . . . . . . . . . . . . . . . . . Configuring BGP Route Inbound Policy on Platform B . . . . . . . . . . . . . . . . . . Configuring Redistribution of BGP Routes on Platform B . . . . . . . . . . . . . . . . BGP Community Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EBGP Load Balancing Example: Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform A . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform B . . . . . . . . . . . . . . . . . . . . . . . Configuring a Static Route on Platform A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Static Route on Platform B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . EBGP Load Balancing Example: Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform A . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform B . . . . . . . . . . . . . . . . . . . . . . . Configuring OSPF on Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adjusting BGP Timers Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP MD5 Authentication Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring TCP MD5 Authentication on Nokia Platform A . . . . . . . . . . . . . . . Configuring BGP Route Redistribution on Nokia Platform B . . . . . . . . . . . . . . BGP Route Dampening Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Path Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static Routes on Nokia Virtual Firewall for Check Point VSX Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
158 158 159 159 160 161 161 163 165 165 167 167 168 168 168 170 170 170 170 171 171 171 172 172 172 172 172 173 173 173 174 174 175 175 176 176 177 177 178 179
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Setting the Rank for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Multiple Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding and Managing Static Routes Example . . . . . . . . . . . . . . . . . . . . . . . . . . Creating and Removing Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Backup Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a Backup Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Aggregation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rank Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Route Rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Protocol Rank Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Rank for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Route Redistribution Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BGP Route Redistribution on Nokia Platform D. . . . . . . . . . . . . . Redistributing a Single Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing All Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing RIP to OSPF Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing Routes from RIP to OSPF External. . . . . . . . . . . . . . . . . . . . . . . Redistributing Routes from OSPF to RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing OSPF to BGP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nokia Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inbound Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IGP Inbound Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Route Inbound Policy Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Route Inbound Policy on Nokia Platform D Based on ASPATH Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP AS Path Filtering Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASPATH Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BOOTP/DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BOOTP/DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
179 180 181 181 182 182 183 183 184 184 185 186 186 187 187 188 188 189 189 190 190 190 191 192 193 193 194 194 195 196 197 197 198 198
10 Configuring Security and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Role-Based Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Roles and Access Mechanisms to Users . . . . . . . . . . . . . . . . . . . . . Authentication, Authorization, and Accounting (AAA) . . . . . . . . . . . . . . . . . . . . . . Configuring AAA Service Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 201 203 203 204 209
10
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Configuring Nonlocal RADIUS Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Configuring TACACS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Configuring Nonlocal TACACS+ Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 11 Policy-Based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 12 Configuring Automatic Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Enabling and Configuring Automatic Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Creating SSH Certificates for Automatic Backup . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Restoring System Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 A Helpful Commands and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Entering Commands from the Nokia Virtual Firewall for Check Point VSX Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firewall Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SecureXL Commands: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup and Restore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EVR Default Policy Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Customers from Provider-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Authentication Is Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an Extreme Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Re-establishing Trust on Provider-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 226 226 226 226 228 229 229 229 229
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
11
12
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
This guide describes the installation and configuration of Nokia Virtual Firewall for Check Point VSX NGX R65on a Nokia IP security platform. Nokia Virtual Firewall for Check Point VSX NGX R65consists of Check Point VPN-1 Power VSX NGX R65running on Nokia IPSO 5.0. This guide describes how to configure features that are unique to Nokia Virtual Firewall for Check Point VSX, such as dynamic routing on a per virtual system basis.The guide also describe various configurations of Nokia Virtual Firewall for Check Point VSX gateways, including single gateway and VRRP pairs. This guide supplements the Check Point VPN-1 Power VSX NGX R65 guide, which contains important information, including VPN-1 VSX architecture and concepts, how to plan a VSX environment, and how to configure and manage objects in the VSX environment. You can download the Check Point VPN-1 Power VSX NGX R65 guide from the Check Point Web site at http://www.checkpoint.com. This preface provides the following information: In This Guide Conventions This Guide Uses Related Documentation
In This Guide
This guide is organized into the following chapters: Chapter 1, Installation Overview contains an overview of the installation process. Chapter 2, Configuring Virtual Switches, Chapter 3, Planning a VRRP HA Environment describes how to plan a Nokia Virtual Firewall for Check Point VSX environment in which two VSX gateways form a VRRP cluster. Chapter 4, Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway describes how to perform the initial configuration of the VSX gateway. Chapter 5, Installing the Management Server describes how to install the management server. Chapter 6, Installing the VSX Management Clientdescribes how to install the management client applications on your Microsoft Windows platform and contains
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
13
information on the next steps to take to configure your Nokia Virtual Firewall for Check Point VSX environment. Chapter 7, Configuring the VSX VRRP Cluster describes how to create and configure two VSX gateways in a VRRP cluster. Chapter 8, Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway, describes how to reconfigure certain aspects of the Nokia IP security platform after the initial setup. Chapter 9, Configuring Routing and Routing Services describes how to configure dynamic and static routing on a virtual system. Chapter 10, Configuring Security and Access describes how to configure non-local users and role-based administration. Chapter 11, Policy-Based Routing describes how to configure policy-based routing on a virtual system. Chapter 12, Configuring Automatic Backup and Restore describes how to configure automatic backups of a VRRP pair. Appendix A, Helpful Commands and Tips contains information about useful commands, back up and restore of a gateway, and tips on configuration and troubleshooting.
Notices
Note Notes provide information of special interest or recommendations.
Caution Cautions indicate potential equipment damage, equipment malfunction, loss of performance, loss of data, or interruption of service.
Text Conventions
The following table describes the text conventions this guide uses.
14
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Related Documentation
Convention
Description Indicates command syntax, or represents computer or screen output, for example:
monospace font
# cpconfig
Menu commands Menu commands are separated by a greater than sign (>): Choose File > Open. Enter indicates you type something and then press the Return or Enter key. Do not press the Return or Enter key when an instruction says type. Emphasizes a point or denotes new terms at the place where they are defined in the text. Indicates an external book title reference. Indicates a variable in a command:
Italics
newpkg file_name.tgz
Related Documentation
For more information about Check Point VPN-1 Power VSX NGX R65 see the following documents: The Check Point VPN-1 Power VSX NGX R65 guide The Check Point Provider-1/SiteManager-1 User Guide for the version of Provider-1 you are using. The preceding guides are available at the Check Point Product Documentation Web site: http://www.checkpoint.com. For more information about how to configure and manage a Nokia IP security platform, see: The IPxxx Series Installation Guide for your platform. The Nokia Network Voyager Reference Guide for IPSO 4.2 The CLI Reference Guide for IPSO 4.2 The preceding documents are available at the Nokia Support Site: http://support.nokia.com. The Nokia Network Voyager Reference Guide and CLI Reference Guide are available both as PDF documents for printing and as a package which can be installed on your platform, allowing the documents to be accessed from Nokia Network Voyager.
Note The Nokia Network Voyager Reference Guide and the CLI Reference Guide are based on Nokia IPSO 4.2, which does not support routing instances. For information about configuring
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
15
routing instances for features such as VRRP, transparent mode, and routing, please consult the appropriate chapters in this manual.
16
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Installation Overview
This chapter describes the basic components in the Nokia Virtual Firewall for Check Point VSX NGX R65environment and what you need to do to prepare for installation of Nokia Virtual Firewall for Check Point VSX NGX R65. The topics covered are: Basic Nokia Virtual Firewall for Check Point VSX NGX R65 Components Installation Overview Preparing the Network Obtaining Check Point Licensing
Basic Nokia Virtual Firewall for Check Point VSX NGX R65 Components
Nokia Virtual Firewall for Check Point VSX NGX R65 consists of a Nokia IP security platform that is running the Nokia IPSO operating system and the Check Point VPN-1 Power VSX NGX R65 NGX R65 packages. The Nokia Virtual Firewall for Check Point VSX NGX R65 components include management products, gateway products, and client software. Table 1 lists the components you need to build a Nokia Virtual Firewall for Check Point VSX NGX R65 environment. For information on supported platforms, see the Nokia Virtual Firewall for Check Point VSX NGX R65 Release Notes.
Table 1 Nokia Virtual Firewall for Check Point VSX NGX R65 Components
Component Gateway Enforcement Module Name VPN-1 Power VSX NGX R65 Description Consists of the Check Point VPN-1 Power VSX NGX R65 software.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
17
Installation Overview
Table 1 Nokia Virtual Firewall for Check Point VSX NGX R65 Components
Component Management Server Name Provider-1/SiteManager-1 NGX R65 or SmartCenter NGX R65 Description Maintains the databases of network object definitions, user definitions, policies, and log files for any number of enforcement Modules. Provides the GUI interface you use to define network objects, customers, and policies.
Management Client Provider-1/SiteManager-1 GUI VSX NGX R65 SmartConsole NGX R65)
You can use Provider-1 or SmartCenter to manage Nokia Virtual Firewall for Check Point VSX NGX R65 gateways. The management model you choose depends on the deployment size, administration requirements, and your existing Check Point product deployment.
Installation Overview
You must install and configure the Nokia Virtual Firewall for Check Point VSX modules in the correct order: 1. Install and configure the VSX gateway. See the Release Notes for Nokia Virtual Firewall for Check Point VSX NGX R65 for more information on how to install the VSX software on your gateway. 2. Install and configure the Provider-1Server or SmartCenter. For more information see the Release Notes for Nokia Virtual Firewall for Check Point VSX NGX R65 and Chapter 5, Installing the Management Server. 3. Install the GUI applications (Provider-1 GUI and SmartConsole for the Provider-1 management model, or SmartConsole alone for the SmartCenter management model). For more information see Chapter 6, Installing the VSX Management Client.
18
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
19
Installation Overview
20
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Virtual switches give you the ability to connect virtual systems without using a virtual router. Since virtual switches operate at layer 2, you will not have to segment your network or manually configure routing on routers adjacent to shared interfaces. Simplifying your typology from layer 3 to layer 2 reduces overall configuration complexity and overhead. As with a physical switch, virtual switches maintain forwarding tables with a list of MAC addresses and their associated ports. The following is the configuration process: 1. Create a virtual switch. 2. Add a physical interface to the switch. 3. Create virtual ethernets for each virtual system. 4. Add the virtual ethernets to the virtual switch.
Note Virtual switches cannot be created on a link-aggregated interface. Virtual Ethernet interfaces cannot be link aggregated.
The following diagram shows a virtual switch connecting three virtual systems. The virtual systems all reside on the same subnet using virtual Ethernet connections. When you view this configuration in the Provider-1 GUI, you will see the Ethernet interfaces and not the physical interface connected to the virtual switch.You configure virtual switches through either Network Voyager or Provider-1 or SmartCenter GUIs. Once you have created a virtual switch in either the Voyager GUI or the Check Point GUIs, all other virtual switches must be configured with the same GUI interface.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
21
22
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
23
4. Click the delete box next to the virtual switch group you want to delete. 5. Click Apply.
Note The interface must be removed from a virtual switch group before deleting the interface.
1. Click Interface Configuration. 2. Click Virtual Switch. 3. Click the delete box next to the interface you want to delete. 4. Click Apply.
24
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
This chapter describes how to plan a Nokia Virtual Firewall for Check Point VSX environment with VRRP High Availability (HA). It assumes you are familiar with the basic VSX architecture and concepts, as described in the Check Point VPN-1 Power VSX NGX R65. Nokia Virtual Firewall for Check Point VSX supports two modes of VRRP HA: Active-passive modein active-passive mode, one member of a VRRP HA cluster acts as the master member. If any interface fails in the master, the entire gateway fails over to the backup member. Active-active modein active-active mode, an individual virtual system (VS) can failover if one of its interfaces fails. Traffic for that VS fails over to the VS on the second member, but traffic for the other VSs is still handled by the cluster member on which the interface failed. Active-active mode also allows static load sharing to be implemented.
Note You cannot implement VRRP HA active-active mode on a VS where the VS is connected to any virtual router (either EVR or IVR). The external and internal interfaces of a VS should be connected to the physical interfaces. However, VSs in the same VSX gateway that are not configured in VRRP HA active-active mode can be connected to an EVR or IVR.
This chapter includes the following sections: Hardware Platform Planning Topology and IP Planning Examples of Supported VSX Cluster Configurations Overview of Configuring the VSX Cluster
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
25
26
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
The following configurations are not supported: A non-DMI configuration with an IVR A non-DMI configuration without an EVR A VS configured for VRRP HA active-active mode that is connected to an EVR or IVR
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
27
VS1
VS1 VIP 192.168.1.75 eth-s1p2
VSX
VS2
VS2 EXT VRRP IP 10.10.20.75
EVR
eth-s1p1
VS3
eth4
eth-s1p3 VS2 VIP 192.168.2.75 eth2 eth-s1p3 VS3 VIP 192.168.3.75 eth3 VS1 EXT VRRP IP 10.10.10.75 Sync VSX VIP 172.16.1.75
Gateway 10.50.50.25
VS1
VSX
VS2
VS2 EXT VRRP IP 10.10.20.75
EVR
eth-s1p1
VS3
VSX2
none
10.10.20.75
eth4
10.10.30.75
eth-s1p2
192.168.1.75
28
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
eth3
192.168.3.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25, the IP address of the management interface on the Management Server is 172.16.1.50, and the IP address of the gateway internal communication network is 10.88.88.0/24.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
29
VS1
VS1 VIP 192.168.1.75 eth-s1p2
VSX
VS2
VS2 EXT VRRP IP 10.50.50.50
VSW
eth-s1p1
VS3
eth4
eth-s1p3 VS2 VIP 192.168.2.75 eth2 eth-s1p3 VS3 VIP 192.168.3.75 eth3 VS1 EXT VRRP IP 10.50.50.75 Sync VSX VIP 172.16.1.75 Gateway 10.50.50.25
VS1
VSX
VS2
VS2 EXT VRRP IP 10.50.50.50
VSW
eth-s1p1
VS3
VSX2
none
10.50.50.50
eth4
10.10.30.75
eth-s1p2
192.168.1.75
30
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
eth3
192.168.3.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25, the IP address of the management interface on the management server is 172.16.1.50, and the IP address of the gateway internal communication network is 10.88.88.0/24.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
31
VS1
eth-s1p4
IVR
VS2 Internal VRRP IP 192.168.150.100
eth-s1p1
VS3
eth-s1p3 Sync eth-s1p3 VS2 Internal VRRP IP 192.168.100.100 eth2 VS3 Internal VIP 192.168.200.100 VS1 EXT VRRP IP 10.10.10.75 172.16.1.50 Provider-1 MDS VSX VIP 172.16.1.75
Gateway 10.50.50.25
VS1
eth-s1p4
IVR
VS2 Internal VRRP IP 192.168.150.100
VS3
VSX2
32
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
none
10.10.30.75
eth-s1p2 none
192.168.50.100 192.168.100.100
none
192.168.150.100
eth2
192.168.200.100
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25, the IP address of the management interface on the management server is 172.16.1.50, and the IP address of the gateway internal communication network is 10.88.88.0/24.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
33
VS1
VS1 Internal VIP 192.168.1.75 eth-s1p2
VSX
VS2
eth-s3p3
VS3
eth-s1p3 VS2 Internal VIP 192.168.2.75 eth2 VSX VIP 172.16.1.75 Gateway 10.50.50.25
Sync
eth-s1p3 eth-s3p1
VS1
eth-s1p4 eth-s3p2
VSX
VS2
eth-s3p3
VS3
Virtual Links Physical Links Private Internal Network 10.88.88.0/24 00064
VSX2
eth-s3p2
10.10.20.75
eth-s3p3
10.10.30.75
eth-s1p2
192.168.1.75
34
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
eth3
192.168.3.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25, the IP address of the management interface on the management server is 172.16.1.50, and the IP address of the gateway internal communication network is 10.88.88.0/24.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
35
VSX1
VS1 Internal WRP IP 192.168.100.100 eth-s4p1 eth-s4p2 eth-s4p3 IVR VIP 192.168.50.100 VS1 EXT VRRP IP 10.10.10.75
VS1
eths1p4
IVR
VS2 Internal WRP IP 192.168.150.100
eth-s1p1
IVR-1 DMZ
VS3 Internal WRP IP 192.168.200.100 eth-s1p3 Sync eth-s1p3 VS1 Internal WRP IP 192.168.100.100 VS1 EXT VRRP IP 10.10.10.75 172.16.1.50 Provider-1 MDS VSX VIP 172.16.1.75
VS3
VS1
eth-s4p3 eth-s4p2 eth-s4p1 IVR-1 VIP 192.168.200.75 eth-s1p2 eths1p4
IVR
VS2 Internal WRP IP 192.168.150.100
VSX EVR
eth-s1p1
VS2
VS2 EXT VRRP IP 10.10.10.75
IVR-1 DMZ
VS3 Internal WRP IP 192.168.200.100 Virtual Links Physical Links
VS3
VSX2
36
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
none
10.10.30.75
192.168.50.100
IVR-1 (DMZ)
192.168.200.75
VS1 to internal network VS2 to internal network VS3 to internal network Synchronization
none
192.168.100.100
none
192.168.150.100
none
192.168.200.100
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25, the IP address of the management interface on the management server is 172.16.1.50, and the IP address of the gateway internal communication network is 10.88.88.0/24.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
37
VSX1
VS1 EXT VRRP IP 10.10.10.75 Provider-1 MDS
VSX VS1
VS1 VIP 192.168.1.75 eth-s1p2
eth-s1p4
eth-s1p1
EVR
VSX VIP 172.16.1.75
VS2
VS2 EXT VRRP IP 10.10.20.75 eth-s1p3 EVR VIP 10.50.50.75 Sync VS2 VIP 192.168.2.75 eth3 Gateway 10.50.50.25 VS1 EXT VRRP IP 10.10.10.75
eth-s1p3
VSX VS1
eth-s1p4
EVR
eth-s1p1
VS2
VSX2
none
10.10.20.75
eth-s1p2
192.168.1.75
38
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25 and the IP address of the gateway internal communication network is 10.88.88.0/24.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
39
VSX1
VS1 EXT VRRP IP 10.10.10.75 Provider-1 MDS VSX VRRP IP 172.16.1.75
VSX VS1
VS1 VIP 192.168.1.75 eth-s1p2
VS2
VS2 EXT VRRP IP 10.10.20.75
EVR
eth-s1p1
Internet
VS3
eth-s1p3 VS2 VIP 192.168.2.75 eth2 Sync eth-s1p3 VS1 EXT VRRP IP 10.10.10.75 VS3 VIP 192.168.3.75 eth3 EVR VIP 10.10.50.75 Gateway 10.50.50.25
VSX VS1
VSX VRRP IP 172.16.1.75
VS2
VS2 EXT VRRP IP 10.10.20.75
EVR
eth-s1p1
VS3
VSX2
40
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
none
10.10.30.75
eth-s1p2
192.168.1.75
eth2
192.168.2.75
eth3
192.168.3.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25 and the IP address of the gateway internal communication network is 10.88.88.0/24.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
41
3. Configure static routes on the management server. For VSX gateways, the VSX gateway, EVR, and IVR interfaces, and the main IP addresses of the external VS interfaces, must be routable from the management server through the VSX gateway interface for DMI configuration and through the EVR interface for non-DMI configuration. For VSX gateways in a VRRP cluster, the management server must be able to reach the appropriate interfaces for both cluster members. 4. Add a customer and a customer management add-on by using the management client. For more information, see Adding a Customer and a Customer Management Add-On on page 55. 5. Create the VSX gateway and optional EVR by using the management client. For more information, see Adding and Configuring the VRRP Cluster on page 56. 6. Add one or more virtual systems by using the management client. For more information, see Creating a Virtual System for the VRRP Cluster on page 67.
Note In a non-DMI configuration, if you want to add a VS from which traffic does not go through the EVR, you must use the Check Point GUI to manually create a wrp link between the VS and the EVR before you push the VS configuration to the gateway.
7. Configure routing, policy-based routing, or transparent mode on the routing instances that are created in IPSO when you create a VS. For more information about routing instances, see Multiple Routing Instances on page 84. 8. Back up your configuration on both the master and backup member as described in Backup and Restore on page 226. You must have a backup file to restore a VRRP gateway.
42
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway
This chapter describes how to perform the initial configuration of the Nokia Virtual Firewall for Check Point VSX NGX R65 gateway. The procedures in this chapter assume that you have already installed the Check Point VPN-1 Pro/Express package on the IP security platform as described in Chapter 3, Preparing the Nokia IP Security Platform. It also assumes that your IP security platform is running IPSO 5.0. After you install the Check Point packages, you must create the management interface and perform the initial configuration of the Nokia Virtual Firewall for Check Point VSX NGX R65 gateway. The procedures for the initial configuration of the gateway are as follows: 1. Run the vsx_config utility. 2. Run the cpconfig utility (automatically called at the end of vsx_config). 3. Reboot the system.
Note Do not use Nokia Network Voyager to configure VRRP and your interfaces. Use the vsx_config utility instead.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
43
Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway
No changes are made to the configuration until the end of the script, when you are asked to confirm your selections. If you confirm them, then the configuration changes are made. The final prompt on the vsx_config utility asks if you would like to execute the cpconfig utility. The cpconfig utility guides you through the steps of licensing and configuring the software. Before You Begin Make sure you know the following information for direct management interface (DMI) configurations: The physical interface to use for the management interface The IP address of the management interface and its default gateway Make sure you know the following information for VRRP cluster configurations: The IP address of the synchronization interface for each cluster member The names of each physical interface that you would like VRRP to monitor Router VRRP ID You can aggregate up to three interfaces. To perform the initial VSX gateway network configuration 1. Log in to the host from a console connection. 2. At the command prompt, enter vsx_config to start the configuration utility. 3. Enter y to continue. 4. If you wish to create a link-aggregated synchronization interface, type y. Otherwise, type n and skip to step 9. 5. Type y to create a link-aggregation group (LAG). 6. From the list of interfaces, select the interfaces that will make up the link aggregation group. Enter the interface you want to be the primary interface first. You can enter up to three interfaces. 7. You will now be given the opportunity to change the speed and duplex configuration of the intefaces in the link aggregation group. Make sure that the settings for each interface is identical. These settings must match the settings for the switch ports that the interfaces are connected to. When you are finished configuring the interface settings, vsx_config creates the link aggregation group. The link aggregation group is given an interface name in the form of aexxxc0: for example, ae1c0 for the first link aggregation group configured.
Note If you make a mistake while setting up link aggregation, exit vsx_config. Using Network Voyager, select Interface Configuration > Link Aggregation and correct your mistake by adding or deleting interfaces in the Link Aggregation group. If you are adding an interface, make sure you set the correct speed and duplicity first. If
44
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
you need to correct the speed/duplicity of an interface that is a member of the Link Aggregation group, you will have to delete it from the group first, correct the speed/ duplicity, and the re-add it to the group. When you are finished reconfiguring link aggregation, rerun vsx_config, but skip the link aggregation configuration by typing n when asked if you want to create Link Aggregated interfaces.
8. Type n when you are asked if you want to create a new link aggregation group. 9. At the prompt, select the logical interface to use as your management interface. 10. At the prompt, select the speed of the interface. 11. At the prompt, select half or full duplex. 12. To accept the IP address associated with the management interface, enter 1. To configure a new IP address for the management interface, enter 2, and then enter the address, network mask, and gateway address at the subsequent prompts.
Note If you change the IP address for the management interface, you must make sure a host name is assigned to that address before running cpconfig. Use the Host Address Assignment page in Network Voyager to assign a host name to the IP address. You must also manually remove the previous IP address using Network Voyager.
.Accept the current default gateway for the management interface or configure a new default gateway. 13. For non-DMI configurations, configure the IP address for the VSX gateway interface. 14. At the next prompt, enter:
n if the VSX gateway is not part of a VRRP cluster. Skip to step 24. y if the VSX gateway is part of an VRRP cluster. Continue with the rest of this procedure.
15. After confirming that you want to configure clustering on this system, select the interface to use for synchronization traffic. If you created an aggregated interface, select it (ae1c0).
Note Do not use ports on IP2250 or IP2255 ADP I/O cards for firewall synchronization traffic. The ADP I/O ports should be used for production traffic.
16. Configure the IP address for the synchronization interfacefor example, 10.10.10.10and enter the mask length.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
45
Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway
Note With the exception of a link-aggregated sync interface, the sync interface is configured for 10 Mb half-duplex. If you want to change the speed or duplex mode for this interface, you must use Nokia Network Voyager or the CLI to do so on both members of the VRRP cluster.
17. At the next prompt, Do you wish to setup VRRP now (y/n) [y]?, enter y. 18. If this machine will be master, enter y. 19. From the list, select the interfaces that will be used by virtual systems and virtual routers. In DMI configurations, the VSX gateway interface is automatically configured for VRRP; in non-DMI configurations, the EVR interface is automatically configured for VRRP. The interfaces to be monitored must be identical on both VSX gateways in a VRRP cluster. You must enter the numbers in the same order on both platforms.
Note If you deselect a VLAN interface in the management GUI, you must configure it as a monitored interface again using vsx_config before you reselect it.
20. Enter the first number of the VRRP ID range. 21. If you wish to enable the auto-backup feature, type y. Otherwise type n and go to step 33. 22. At the prompt, enter the IP address of the other node of the VRRP pair. 23. At the prompt, enter the time to schedule the daily backup. 24. Review the configuration displayed on the screen. If the configuration is correct, select y and the configuration wizard applies the configuration to your current system. If you enter n, the configuration wizard gives you the option of restarting vsx_config to correct the configuration or of exiting completely without saving the configuration.
Note If you type n to discard the configuration and start again, all configuration is discarded except the link aggregation configuration. When you rerun vsx_config, skip the link aggregation configuration portion of vsx_config since link aggregation is already configured. If you make an error when initially configuring link aggregation, you can correct the error before you rerun vsx_config by using Network Voyager. Select Interface Configuration > Link Aggregation and correct your mistake by adding or deleting interfaces in the Link Aggregation group. If you are adding an interface, make sure you set the correct speed and duplicity first.
46
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
To complete the configuration by using the cpconfig utility 1. After you finish the initial network configuration, the following prompt appears:
Do you wish to execute cpconfig now?
Enter y to configure the VSX software and finish the gateway configuration process. If you exit the configuration process, you can enter cpconfig at the command prompt any time to finish the initial configuration. 2. Read the license agreement, and then enter y to accept it. 3. If you plan to use two VSX gateways in a VRRP cluster, enter y in response to the following prompt:
Would you like to install a Check Point clustering product (CPHA, CPLS or State Synchronization)? (y/n) [n]?
Otherwise, accept the default value of n. 4. Enter y to add a license and fill in the license information, or enter n to complete the license information later. 5. As part of configuring the certificate authority, type random text at a random pace until you hear a beep. The timing latency between your keystrokes is used to generate cryptographic data. VPN-1 VSX uses certificates for secure internal communication (SIC) between the MDS and the VSX gateway.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
47
Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway
6. Enter an activation key to authenticate secure communication between VSX components. Enter and re-enter the activation key. You need to enter this key later from the Provider-1 Client to initialize trust between the MDS and the VSX gateway. 7. You will be asked to reboot the system. If you answer No or n, you will be asked if you wish to open HTTPS access for Nokia Network Voyager. You will then have to reboot manually from the command prompt. If you enter Yes or y, your system will be rebooted.
Note If you do not activate HTTPS access to Network Voyager, you will have no Network Voyager access after the reboot until you install a policy on the gateway that accepts Network Voyager access.
48
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
You can use either Provider-1/SiteManager-1 or SmartCenter to manage your Nokia gateways. Provider-1 allows you to centrally configure, manage and monitor VSX gateways and other Check Point enforcement modules from a single console. The following versions of management software are supported: Provider-1/SiteManager-1 VSX NGX R65 SmartCenter VSX NGX R65 The standard NGX R65 version of Provider-1 or SmartCenter can manage both standard VPN-1 and VPN-1 Power VSX NGX R65 gateways.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
49
Provider-1/SiteManager-1 VPN-1 Power VSX NGX R65 SmartCenter VSX NGX R65
Provider-1/SiteManager-1 Getting Started Guide for VPN-1 Power VSX NGX R65
IPSO SecurePlatform Solaris 8, 9, 10 Linux Red Hat Enterprise 3.0 Windows server
Check Point for Nokia IPSO Getting Started Guide VSX NGX R65. Available from Nokia. Enterprise Security Product Suite for VSX NGX R65
SecurePlatform
50
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
This chapter describes how to install the Provider-1 Client and the SmartConsole and lists the next steps you take to set up your Nokia Virtual Firewall for Check Point VSX NGX R65 environment. The VSX management clients provide the interfaces to manage the VSX gateway. If you are using Provider-1, you must install both the Provider-1 and SmartConsole GUIs on the management client. If you are using SmartCenter, you install only SmartConsole. You can install the management client applications on as many Microsoft Windows desktops as you desire. The procedures in this chapter assume that you downloaded the Check Point management client software to an FTP server. Depending on the version of your management server and platform, you might also install the management client from CD. See the Check Point documentation for information on how to do so. To install the management client applications on a Windows platform 1. Close any Check Point applications running on the Windows platform. 2. Copy the installation files for Provider-1 GUI and SmartConsole from the FTP server to a temporary folder on the Windows computer. 3. Unzip the SmartConsole installation file and double-click setup.exe. The Installation Wizard opens. Accept the default values by clicking Next. 4. After the SmartConsole software installation completes, unzip the Provider-1 installation file and double-click setup.exe. The Installation Wizard opens. Accept the default values by clicking Next.
Testing Connectivity
The management client connects to the Provider-1 Server (MDS). The MDS must contain the IP addresses of all management clients allowed to connect to it. During the MDS configuration, you specified the IP address of the management clients that you use to connect to the MDS.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
51
To test connectivity 1. Double-click the appropriate icon to launch the Provider-1 client. The login screen appears. 2. Enter the administrative username and password you specified when you configured the management server. 3. In the Server field, enter the IP address of the Server. Select the Read Only option to allow others access to the SmartCenter Server while you view information. 4. Click OK. A successful connection indicates that you installed the Client and Server correctly.
Next Steps
When you successfully install the VSX gateway, the Provider-1 MDS, and the management clients, you can configure the objects in the Nokia Virtual Firewall for Check Point VSX environment. The next steps to take are as follows: 1. Create a customer for VSX gateway interface and EVR management. 2. Define a customer management add-on (CMA) for the customer. 3. Add the VSX gateway.
Note When you add the VSX gateway, you must establish trust between the MDS and the VSX gateway. You configured the activation key in step 6 on page 48. Check the connectivity and routing from the management server to the VSX gateway interface and EVR interfaces.
5. Configure the management virtual system. 6. Create a customer and CMA (or create a new CMA in the original customer) for each VS that is independently managed. The Check Point VPN-1 Power VSX NGX R65 guide contains detailed instructions about how to complete each of the required steps. The Check Point guide also contains instructions about how to: Add and edit customers Define and edit virtual systems and virtual routers
52
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Next Steps
Define policies Install policies Obtain status information about the VSX deployment
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
53
54
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
This chapter describes how to configure the Check Point VPN-1 Power VSX NGX R65 gateways in a VRRP cluster. This chapter assumes that you already successfully performed the initial configuration on both Check Point VPN-1 Power VSX NGX R65 gateways, and that you completed the installation for the Provider-1 MDS and the management clients. This chapter covers: Adding a Customer and a Customer Management Add-On Adding and Configuring the VRRP Cluster Creating a Virtual System for the VRRP Cluster
Note The procedures and examples in the above subsections assume that you are using NGX R65 management.
To add a customer and a CMA 1. Log on to the client on the Windows system. 2. From the Manage menu, click New Customer to run the New Customer Wizard.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
55
3. Complete the required information to add a new customer. For information about customers and CMAs, see the Provider-1 documentation available on the Check Point Web site. 4. Choose to define the CMA and click Next.
If you do not enter any license information, you can still complete the configuration. Check Point software comes with a 15-day evaluation license. 6. Start the CMA.
56
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Note You must first launch SmartDashBoard from the Provider-1 client and then follow the procedures below.
To add the VRRP cluster 1. From the main Provider-1 Client window, right-click the customer you created and select New Check Point > VPN-1 VSX > Cluster.
2. From the Set the VSX Cluster Version drop-down list, select VPN-1 Power VSX NGX R65.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
57
3. From the Select the VSX Cluster Platform drop-down list, select Nokia VRRP.
58
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
59
60
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
61
62
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
63
Note You cannot implement VRRP-HA active-active mode on a VS which is connected to a virtual router (either EVR or IVR). The external and internal interfaces of a VS should be connected to the physical interfaces. However, VSs in the same VSX gateway that are not configured in VRRP-HA active-active mode can be connected to an EVR or IVR.
64
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Note If you are configuring a non-dmi typology, you must select the management interface. This is important since you cannot configure the non-dmi typology with a management interface afterwards.
.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
65
10. Click Finish on the VSX Cluster Definition Completed screen to create the VSX cluster. The Creating VSX Cluster window opens.
66
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
2. Enter a name for the VS. 3. From the VSX Gateway/Cluster drop-down list, select the VSX cluster you configured.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
67
4. Add the main interface and a wrp link to the EVR, if you have configured one.
68
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
69
70
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
6. (Optional) Configure the default gateway, which can be an IP address or a virtual router.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
71
7. Shows compete configuration of a virtual system with two interfaces and a default route.
72
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
8. After the VS is successfully completed, return to the main Provider-1 Client screen to add other virtual systems, if necessary.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
73
When you configure a VRRP cluster, all interfaces on which VRRP is configured in the master member are given a priority of 100 and all interfaces in the backup member are given a priority of 95. To make a VS active in the backup member rather than the master member, you must give the interfaces for VS instance in the master member a lower priority than the interfaces for VS instance in backup. You must also ensure that the VS interfaces are monitoring only each other, and not other interfaces.
74
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
To achieve the configuration shown in Figure 8, you would: 1. Specify that eth1, eth2, eth3, and eth4 are to be configured for VRRP when you run vsx_config on the member gateways. 2. Create the VRRP cluster and VSs using the management GUI as described in the preceding sections of this chapter. Although Figure 8 does not show this, you can configure VLAN on the VRRP interfaces. Do not create an EVR for the VSs. In active-active mode, the VSs must be connected directly to the physical interface and not to virtual routers. You can, however, configure an EVR for use by other interfaces. 3. Install the configuration and policy on both VRRP members. 4. Connect to the master gateway using Network Voyager. Using the VRRP Configuration page (Virtual Systems tab> Configuration for Default (VSX gateway) instance > VRRP), change the VRRP priority for interfaces eth3 and eth4 to 90. 5. For each interface, including the VSX gateway interface, in the master and backup gateways, correct the list of interfaces to be monitored by setting the interfaces that should not be monitored to off. For example: For eth1, only eth2 should be monitored (and vice versa). Remove all other monitored interfaces by setting them to off. For eth3, only eth4 should be monitored (and vice versa). Remove all other monitored interfaces by setting them to off. For eth1sp1 (the VSX gateway interface), no other interfaces should be monitored, so remove all monitored interfaces by setting them to off.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
75
76
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway
This chapter describes how to use the vsx_config command to add interfaces to a VRRP configurations.
Note Re-run the vsx_config script for the instances specified in this chapter only. Complete all other configuration through the Check Point GUI.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
77
Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway
Note For a VS to use an interface, it must be allocated in the system interfaces list. This list is created during initial configuration of the VSX object. Any addition or removal of interfaces must be reflected manually in that list.
Add the interfaces to an existing or new VS. If you are using active-active mode, configure the interfaces as described in Configuring VRRP Active-Active Mode on page 73. To add interfaces to the platform 1. Plug in the network interface card. 2. Use Network Voyager to set the speed and duplex mode for the interfaces: To configure VRRP on an interface 1. Log on to the host from a console connection 2. At the prompt, enter vsx_config to start the configuration utility. The console displays the following message:
Welcome to the VSX reconfiguration utility. This utility will
permit you to reconfigure parts of the system. Choose a configuration item: ---------------------------------------------------------------------1. Configure VRRP on Additional Interface 2. Show VSX Summary 3. Modify Speed/Duplexity on interfaces 4. Change starting VRID for new Virtual Ethernets. 5. Exit ---------------------------------------------------------------------Note: Configuration changes are automatically saved
78
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
5. Enter the new interfaces to configure for VRRP when you see the following message:
From the list below select the additional interfaces to be used for Virtual Systems and Virtual Routers: ----------------------------------------------------------------------1) 2) 3) 4) eth1c0 eth2c0 eth4c0 Configure all available interfaces
For example, enter 1 2 6. If you are installing a new network card into an IP1220 or IP1260, you need to change the logical interface names so that they follow the naming convention of the existing interfaces. For example, change eth-s1/s1p1c0 to: e-s1s1p1c0 Using Network Voyager, select the logical interface on the Interfaces Configuration page (Default > Interfaces) and then change the logical name in the Logical name field. You can now use either Provider-1 or SmartCenter to add the interfaces to the system interfaces list. Complete one of the following procedures. To change the virtual router identification of an interface 1. Choose option 4. 2. Follow the onscreen instructions. To add interfaces using SmartCenter 1. Edit the VSX cluster properties. 2. Go to the System Interfaces tab and click the name of each interface you configured VRRP on.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
79
Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway
3. Click OK to commit the changes. 4. If the interface does not appear on the list, this means the interface was added after initial setup. To add the interface, click Add. The following dialogue box appears.
80
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
5. Enter the name of the interface you are adding and click OK to commit the changes. 6. Install the configuration on the gateways and reboot. To Add Interfaces Using Provider-1 1. Edit VSX Cluster properties
2. Go to the System Interfaces tab and check the box for each interface you configured VRRP on. 3. Click OK to commit the changes. 4. If the interface does not appear on the list, this means the interface was added after initial setup. To add the interface, click Add. The following dialogue box appears.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
81
Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway
5. Enter the name of the interface and click OK to commit the changes. 6. Install the configuration on the gateways and reboot.
82
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
This chapter describes in detail how to configure the following routing protocols: Multiple Routing Instances OSPF RIP PIM IGMP BGP Static Routes Route Aggregation Route Rank Route Redistribution Inbound Route Filters Nokia Virtual Firewall for Check Point VSX NGX R65 also supports an option to configure the gateway to ignore the default route. For more information about this option, see Configuring Gateway to Ignore Default Route on page 86. For more information about policy routes, which you can also configure using Nokia Network Voyager, see Policy-Based Routing on page 217.
Note The Nokia Virtual Firewall for Check Point VSX NGX R65 Feature Pack provides optional advanced routing functionality. For more information, contact your Nokia sales representative.
Note You must install the license key supplied by Nokia to use individual dynamic routing protocols, including OSPF, RIP, PIM, and BGP, as well as transparent mode. For more information on how to install a license key, see Installing Nokia License Keys on page 45.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
83
84
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Note You must also enable RIP and BGP through the Provider-1 MDS. For more information, see Enabling RIP for Nokia Virtual Firewall for Check Point VSX on page 102 and Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
4. You can also use the main page for the specific routing instance to configure all other features, including Static Routes, Transparent Mode, route aggregation, Inbound Route Filters, and Routing Options. You can also use the Show Configuration Summary page to configure specific routing protocols for an instance. From the main configuration page for a specific multiple routing instance, click the Show Configuration Summary link. That page displays a summary of configured routing protocols and options and lets you make configuration changes.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
85
OSPF
OSPF is a link-state routing protocol based on the Dijkstra (or shortest path first) algorithm. OSPF is an interior gateway protocol (IGP) that distributes routing information between routers in a single autonomous system. OSPF chooses the least-cost path as the best path. Suitable for complex networks with a large number of routers, OSPF provides equal-cost multipath routing where packets to a single destination can be sent using more than one interface. OSPF groups networks into areas. Routing information passed between areas is summarized and allows significant potential reduction in routing traffic. OSPF uses four different types of routes: Intra-area Interarea Type 1 external Type 2 external Intra-area paths have destinations within the same area; interarea paths have destinations in other OSPF areas; and autonomous system external (ASE) routes are routes to destinations external to the autonomous system (AS). Routes imported into OSPF as Type 1 routes are supposed to be from IGPs whose metrics are directly comparable to OSPF metrics. When a routing decision is being made, OSPF adds the internal cost to the AS border router to the external metric. Type 2 ASEs are used for routes whose metrics are not comparable to OSPF internal metrics. In this
86
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
OSPF
case, only the external OSPF cost is used. In the event of ties, the least cost to an AS border router is used. OSPF areas are connected by the backbone area, the area with identifier 0.0.0.0. All areas must be logically contiguous, with the backbone being no exception. To permit maximum flexibility, OSPF allows the configuration of virtual links, enabling the backbone area to appear contiguous despite the physical reality. All routers on a link must agree on the configuration parameters of the link. All routers in an area must agree on the configuration parameters of the area. A separate copy of the SPF algorithm is run for each area. Misconfigurations prevent adjacencies from forming between neighbors, and routing black holes or loops can form.
Types of Areas
Routers using OSPF send packets called Link State Advertisements (LSA) to all routers in an area. Areas are smaller groups within the AS that you can design to limit the flooding of an LSA to all routers. LSAs do not leave the area from which they originated, thus increasing efficiency and saving network bandwidth. You must specify at least one area in your OSPF networkthe backbone area, which has the responsibility to propagate information between areas. The backbone area has the identifier 0.0.0.0. You can designate other areas, depending on your network design, of the following types: Normal AreaAllows all LSAs to pass through. The backbone is always a normal area. Stub AreaStub areas do not allow Type-5 LSAs to be propagated into or throughout the area and instead depends on default routing to external destinations. You can configure an area as a stub to reduce the number of entries in the routing table (routes external to the OSPF domain are not added to the routing table). NSSA (Not So Stubby Area)Allows the import of external routes in a limited fashion using Type-7 LSAs. NSSA border routers translate selected Type-7 LSAs into Type-5 LSAs which can then be flooded to all Type-5 capable areas. Configure an area as an NSSA if you want to reduce the size of the routing table, but still want to allow routes that are redistributed to OSPF. It is generally recommended that you limit OSPF areas to about 50 routers based on the limitations of OSPF (traffic overhead, table size, convergence, and so on). All OSPF areas must be connected to the backbone area. If you have an area that is not connected to the backbone area, you can connect it by configuring a virtual link, enabling the backbone area to appear contiguous despite the physical reality.
Note If you need to connect two networks that both already have backbone areas and you do not want to reconfigure one to something other than 0.0.0.0, you can connect the two backbone areas using a virtual link.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
87
Each router records information about its interfaces when it initializes and builds an LSA packet. The LSA contains a list of all recently seen routers and their costs. The LSA is forwarded only within the area it originated in and is flooded to all other routers in the area. The information is stored in the link-state database, which is identical on all routers in the AS.
Authentication
The OSPF protocol exchanges can be authenticated. Authentication guarantees that routing information is accepted only from trusted routers. A variety of authentication schemes can be used, but a single scheme must be configured for each interface. This enables some links to use much stricter authentication than others. The currently supported authentication schemes are: null, simple password, and MD5. Null authentication does not authenticate packets. Simple password authentication uses a key of up to eight characters. MD5 algorithm uses a key of up to 16 characters. The simple password scheme provides little protection because the key is sent in the clear, and it is possible to capture packets from the network and learn the authentication key. The MD5 algorithm provides much stronger protection, as it does not include the authentication key in the packet. Instead, it provides a cryptographic hash based on the configured key. The MD5 algorithm creates a crypto checksum of an OSPF packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead it contains a crypto-checksum called the digest. The receiving router performs a calculation using the correct authentication key and discards the packet if the digest does not match. In addition, a sequence number is maintained to prevent the replay of older packets. This method provides stronger assurance that routing data originated from a router with a valid authentication key.
CLI Support
IPSO 5.0 supports CLI commands for configuring and monitoring OSPF for a routing instance, that is, virtual system. To configure OSPF, use the following syntax before any specific command:
set instance <instance_name>
To use the show commands for OSPF, use the following syntax:
show instance <instance_name>
For more information about how to use CLI, see the Nokia IPSO CLI Reference Guide.
88
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
OSPF
the new master. A traffic break might occur during the time it takes both the VRRP and OSPF protocols to learn the routes again. The larger the network, the more time it would take OSPF to synchronize its database and install routes again. You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address. For more information on enabling the advertising of a virtual IP address when running OSPF, see Configuring OSPF on page 90, step 15.
Note Nokia also provides support for BGP and PIM, both sparse mode and dense mode, and RIP to advertise the virtual IP address of the VRRP virtual router, beginning with IPSO 3.7.90.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
89
Autonomous system external (ASE)Have destinations external to the autonomous system (AS). These are the routes calculated from Type-5 LSAs. NSSA ASE RouterHave destinations external to AS. These are the routes calculated from Type-7 LSAs. All routers on a link must agree on the configuration parameters of the link. All routers in an area must agree on the configuration parameters of the area. A separate copy of the SPF algorithm is run for each area. Misconfigurations prevent adjacencies from forming between neighbors, and routing black holes or loops can form.
Configuring OSPF
1. Use the Provider-1 GUI to configure the Ethernet interface. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure OSPF. 4. Click the OSPF link in the Routing section. 5. (Optional) This step is encouraged so that the ID is not tied to an address. Enter the router ID in the Router ID text box. 6. (Optional) If you have new OSPF areas to enter, enter the new OSPF area name in the Add New OSPF Area text box; then click Apply. Repeat this step for each new area. Area 0.0.0.0 is already defined as the backbone area. 7. (Optional) If some of the defined areas are stub areas: a. Click yes for the Stub Area for each area, then click Apply. b. Enter the cost for the default route to originate into the stub area in the Cost for default stub area route text box. c. Click Apply. This is not an option for the backbone area. 8. (Optional) If some of the stub areas are totally stubby areas: a. Click yes in the Totally Stubby Area field for each stub area. b. Click Apply. This disallows the stub area entry point from advertising interarea routes and summaries. 9. (Optional) If some of the defined areas are not so stubby areas (NSSA): a. Select NSSA in the area type drop-down box. b. Click Apply. c. Configure additional parameters that appear as described in Table 25.
90
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
OSPF
10. (Optional) For each summary to define: a. Enter the network prefix summary in the Add new address range: prefix text box, and enter the length of the subnet mask (in bits) in the Mask Length text box. b. Click Apply. This procedure is useful for decreasing the number of prefixes advertised into the backbone. 11. (Optional) For each summary you do not want to define, click off in the Restrict section where the network prefix summary is defined 12. Click Apply. 13. (Optional) To add a new stub network: a. Enter the prefix in the Add new stub network: Prefix text box. b. Enter the mask length in the Mask length text box. c. Click Apply. 14. Assign the appropriate area to each interface: a. Click the appropriate area in the drop-down list for each interface; then click Apply. This completes configuring an interface with the default parameters. 15. If VRRP is enabled on a physical interface, click On next to the Virtual Address field to enable OSPF on the virtual IP address associated with this interface; then click Apply.
Note Do not enable the option to advertise the virtual IP address on a wrp interface. If VRRP is not configured on an interface, do not enable the option to advertise the virtual IP address for that interface.
16. (Optional) For the configuration parameters for each interface to change: a. Enter a new hello interval (in seconds) in the Hello Interval text box; then click Apply. The hello interval must be the same for all routers on the link for them to become adjacent. b. Enter a new dead interval (in seconds) in the Dead Interval edit box; then click Apply. The router dead interval must be the same for all routers on the link for them to become adjacent. c. Enter a new cost metric in the OSPF Cost text box for each interface; then click Apply. d. Enter a new designated router priority (0-255) in the Election Priority text box; then click Apply e. Click On to make the interface operate in Passive mode; then click Apply. f. For simple authentication, select Simple from the AuthType drop-down list; then click Apply. Enter the password in the Password text box; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
91
g. For MD5 authentication, select MD5 from the AuthType drop-down list; then click Apply. In the add MD5 key field, enter the new MD5 key ID (in the Key Id text box) and MD5 password (in the MD5 Secret text box); then click Apply. 17. To make your changes permanent, click Save. Table 10 describes the configuration parameters for NSSA areas. These fields appear if you define the area as an NSSA (Not So Stubby Area). For more information on NSSA, see RFC 3101.
Table 10 NSSA (Not So Stubby Area) Parameters
Parameter Translator Role Description Specifies whether this NSSA border router will unconditionally translate Type-7 LSAs into Type-5 LSAs. When role is Always, Type-7 LSAs are translated into Type-5 LSAs regardless of the translator state of other NSSA border routers. When role is Candidate, this router participates in the translator election to determine if it will perform the translations duties. If this NSSA router is not a border router, then this option has no effect. Default: Candidate. Specifies how long in seconds this elected Type-7 translator will continue to perform its translator duties once it has determined that its translator status has been assumed by another NSSA border router. This field appears only if an area is defined as an NSSA with translator role as Candidate. Default: 40 seconds. Specifies if summary routes (summary link advertisements) are imported into the stub area or NSSA. Each summary link advertisement describes a route to a destination outside the area, yet still inside the AS (i.e. an interarea route). These include routes to networks and routes to AS boundary routers. Default: On. Enter a cost associated with the default route to the NSSA. Specifies the route type associated with the Type-7 default route for an NSSA when routes from other protocols are redistributed into OSPF as ASEs. If a redistributed route already has a route type, this type is maintained. If summary routes are imported into an NSSA, only then a Type7 default route is generated (otherwise a Type-3 default route is generated). This field appears only if an area is defined as an NSSA into which summary routes are imported. The route type can be either 1 or 2. A type 1 route is internal and its metric can be used directly by OSPF for comparison. A type 2 route is external and its metric cannot be used for comparison directly. Default: 1
92
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
OSPF
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
93
Area 1
24.46/30
Nokia Platform C
24.50/30 e1
Nokia Platform A
In Figure 9 above: Nokia platforms A and E are gateways Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, VRRP pair. Each member of the pair is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A and B are in the backbone area. Nokia Platform E is in Area 1.
Configuring OSPF on the Nokia Virtual Firewall for Check Point VSX VRRP Pair
1. Use the Provider-1 GUI to configure an EVR and a VS on each member of the VRRP pair, that is, on Nokia platforms C and D. 2. Log on to Nokia Network Voyager sessions and complete the following steps on each member of the VRRP pair, Nokia platforms C and D. 3. Click the Virtual Systems tab. 4. Click Configuration next to the instance name for the EVR. 5. Click the OSPF link in the Routing section. 6. In the Area drop-down list for the e1 interface, select BACKBONE; then click Apply. 7. Click on next to the Virtual Address field to advertise the VRRP virtual IP address for this interface; then click Apply. 8. In the Router ID text box, enter the virtual IP address of the EVR; then click Apply. 9. For the wrpj interface that connects the EVR to the VS in Area 0, select BACKBONE in the Area drop-down list for that interface.
94
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
OSPF
Caution Do not enable the virtual address option for the wrpj interface. This option is not supported on wrp interfaces.
10. Return to Nokia Voyager, and click the Virtual Systems tab. 11. Click Configuration next to the instance name for the VS. 12. Click the OSPF link in the Routing section. 13. In the Add New OSPF Area text box, enter 0.0.0.1 Click Apply. 14. In the Area drop-down list for interface e2, select AREA 1;then click Apply. 15. Click on next to the Virtual Address field to advertise the VRRP virtual IP address on this interface. then click Apply. 16. In the Router ID text box, enter the virtual IP address of the VS; then click Apply. 17. In the area drop-down list for the wrp interlace that connects to the VS to the EVR, select BACKBONE; then click Apply.
Caution Do not enable the virtual address option for the wrp interface. This option is not supported on wrp interfaces.
1. Initiate a Nokia Network Voyager session to Platform E. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 5. In the Area drop-down list for interface e3, select AREA 0.0.0.1; then click Apply. 6. Click Save to make your changes permanent.
Configuring OSPF on Nokia Platform B
1. Initiate a Nokia Network Voyager session to Platform B. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Area drop-down list for interface e4, select BACKBONE; then click Apply. 5. Click Save to make your changes permanent.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
95
Nokia Platform D
24.58/30 24.57/30 Nokia Platform B 24.45/30
Nokia Platform A
24.46/30
Nokia Platform C
24.50/30 e1 24.53/30 e2 24.54/30 e3 Nokia Platform E
00340
24.49/30 e4
In Figure 10 above: Nokia platforms A and E are gateways Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, VRRP pair. Each member of the cluster is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A and B are in the backbone area. Nokia platform E is in Area 1.
Configuring OSPF on the Nokia Virtual Firewall for Check Point VSX VRRP Pair
1. Use the Provider-1 GUI to configure an EVR, an IVR, and a VS on each member of the VRRP pair, that is, on Nokia platforms C and D. 2. Initiate Network Voyager sessions and complete the following steps on each member of the VRRP pair, Nokia platforms C and D. 3. Click Configuration next to the instance name for the EVR. 4. Click the OSPF link in the Routing section. 5. In the Area drop-down list for interface e1, select BACKBONE; then click Apply.
96
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
OSPF
6. Click on in the Virtual Address field to advertise the VRRP virtual IP address on this interface; then click Apply. 7. In the Router ID text box, enter the virtual IP address of the EVR; then click Apply. 8. In the Area drop-down list for the wrpj interface that connects the EVR to the VS, select BACKBONE.
Caution Do not enable the virtual address option for the wrpj interface. This option is not supported on wrp interfaces.
9. Click Apply, and then click Save to make your changes permanent. 10. Click Configuration next to the instance name for the IVR. 11. Click the OSPF link in the Routing section. 12. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 13. In the Area drop-down list for interface e2, select AREA 1; then click Apply. 14. Click on in the Virtual Address field to advertise the VRRP virtual IP address on the interface.; then click Apply. 15. In the Router ID text box, enter the virtual IP address of the IVR; then click Apply. 16. In the Area drop-down list for the wrp interface that connects the IVR to the VS, select backbone.
Caution Do not enable the virtual address option for the wrp interface. This option is not supported on wrp interfaces.
17. Click Apply, and then click Save to make your changes permanent. 18. Click Configuration next to the name of the VS. 19. In the Area drop-down list for the wrp interface that connects the VS to the EVR, select BACKBONE.
Caution Do not enable the virtual address option for the wrp interface. This option is not supported on wrp interfaces.
20. Click Apply, and then click Save to make your changes permanent.
Configuring OSPF on Nokia Platform E
1. Initiate a Nokia Network Voyager session to Platform E. 2. Click Configuration in the tree view.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
97
3. Click the OSPF link in the Routing section. 4. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 5. In the Area drop-down list for interface e3, select AREA 0.0.0.1; then click Apply. 6. Click Save to make your changes permanent.
Configuring OSPF on Nokia Platform B
1. Initiate a Nokia Network Voyager session to Platform B. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Area drop-down list for interface e4, select BACKBONE; then click Apply. 5. Click Save to make your changes permanent.
Area 1
24.46/30
Nokia Platform C
24.50/30 e1
Nokia Platform A
In Figure 11 above: Nokia platforms A and E are gateways Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, a VRRP pair. Each member of the cluster is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A nd B are in the backbone area. Nokia Platform E is in Area 1.
98
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
OSPF
Configuring OSPF on the Nokia Virtual Firewall for Check Point VSX VRRP Pair
1. Use the Provider-1 GUI to configure an EVR and a VS on each member of the VRRP pair, that is, on Nokia platforms C and D 2. Initiate Network Voyager sessions and complete the following steps on each member of the VRRP pair, Nokia platforms C and D. 3. Click the Virtual Systems tab. 4. Click the OSPF link in the Routing section. 5. In the Area drop-down list for interface e1, select BACKBONE; then click Apply. 6. Click on next to the Virtual Address field to advertise the VRRP virtual IP address on this interface; then click Apply. 7. In the Router ID text box, enter the virtual IP address of the VS; then click Apply. 8. In the Add New OSPF Area text box, enter 0.0.0.1 Click Apply. 9. In the Area drop-down list for interface e2, select AREA 1; then click Apply. 10. Click on next to the Virtual Address field to advertise the VRRP virtual IP address for this interface; then click Apply. 11. Click Save to make your changes permanent.
Configuring OSPF on Nokia Platform E
1. Initiate a Network Voyager session to Nokia platform E. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Add New OSPF Area text box, enter 0.0.0.1 Click Apply. 5. In the Area drop-down list for interface e3, select AREA 0.0.0.1; then click Apply. 6. Click Save to make your changes permanent.
Configuring OSPF on Nokia Platform B
1. Initiate a Network Voyager session to Nokia platform E. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Area drop-down list for interface e4 select BACKBONE; then click Apply. 5. Click Save to make your changes permanent.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
99
Example of OSPF Configuration on a Nokia Virtual Firewall for Check Point VSX Standalone Gateway
In the following example, Nokia platform C is a Nokia Virtual Firewall for Check Point VSX standalone gateway, which means VRRP is not configured. You configure the gateway as follows: Enable OSPF on VS physical interface in Area 0 Enable OSPF on VS physical interface in Area 1
Figure 12 OSPF Configuration of Nokia Virtual Firewall for Check Point VSX Standalone Gateway
Area 0
Area 1
24.46/30
Nokia Platform A
In Figure 12: Nokia platforms A and D are gateways. Nokia platform C is a standalone Nokia Virtual Firewall for Check Point VSX gateway. Platform C is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A and B are in the backbone area. Nokia Platform D in is Area 1.
Configuring OSPF on Nokia Virtual Firewall for Check Point VSX Standalone Gateway Platform C
1. Use Check Point Provider-1 GUI to configure platform C as a VSX gateway. This means that platform C is not part of a VSX cluster, that is VRRP is not configured on the platform. 2. Initiate a Nokia Network Voyager session to platform C. 3. Click Configuration in the tree view.
100
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
RIP
4. Click the OSPF link in the Routing section. 5. In the Area drop-down list for interface e1, select BACKBONE; then click Apply.
Caution Do not enable the virtual address option for this interface.
6. (Optional) Enter a value in the Router ID text box for platform C.; then click Apply. 7. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 8. In the Area drop-down list for interface e2, select AREA 1; then click Apply.
Caution Do not enable the virtual address option for this interface.
RIP
The Routing Information Protocol (RIP) is one of the most widely used interior gateway protocols (IGP). RIP is an implementation of a distance-vector, or Bellman-Ford, routing protocol for local networks. Routers advertise their routes (reachability information) to other neighboring routers.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
101
When it has information to send, a router running RIP sends updates on each configured interface at set intervals. Each update contains paired values, where each pair consists of an IP network address and a distance (expressed as an integer) to that network. RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a router advertises directly connected networks as a metric of 1. Networks that are reachable through one other router are two hops, and so on. Thus, the number of hops, or hop count, along a path from a given source to a given destination refers to the number of gateways that a datagram would encounter along that path. The maximum number of hops in a RIP network is 15 as the protocol treats anything equal to or greater than 16 as unreachable.
Enabling RIP for Nokia Virtual Firewall for Check Point VSX
For RIP to function with Nokia Virtual Firewall for Check Point VSX, you must complete the following procedure to add manually an entry to the table.def file in the Provider-1. Complete this procedure for each customer you want to enable RIP. 1. Open a console connection to the Provider-1 MDS. 2. Change directories (cd) to the directory for customers, which includes a subdirectory for each customer: /var/opt/CPmds-V25/customers. 3. Locate the name of the CMA you want to enable RIP and change to that directory. 4. Change directories (cd) to the private lib directory for that customer: CPfw1-V25/lib 5. Open the table.def file 6. Locate the table called nokia_no_fold_ports and add the following entry: <0, 520> 7. Log on to the Provider-1 GUI and push the policy for this entry change to take effect. 8. You can now continue to configure RIP for the specific CMA using Network Voyager. Repeat steps 2 through 6 for each CMA you want to enable RIP.
Note For more information about how to operate the Provider-1 MDS, see the Check Point Provider-1 User Guide.
Note If you want to implement BGP, you also need to modify the table.def file in the Provider-1 MDS. For more information, see Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
RIP 2
The RIP version 2 protocol adds capabilities to RIP. Some of the most notable RIP 2 enhancements follow.
102
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
RIP
Network Mask
The RIP 1 protocol assumes that all subnetworks of a given network have the same network mask. It uses this assumption to calculate the network masks for all routes received. This assumption prevents subnets with different network masks from being included in RIP packets. RIP 2 adds the ability to explicitly specify the network mask for each network in a packet.
Authentication
RIP 2 packets also can contain one of two types of authentication methods that can be used to verify the validity of the supplied routing data. The first method is a simple password in which an authentication key of up to 16 characters is included in the packet. If this password does not match what is expected, the packet is discarded. This method provides very little security, as it is possible to learn the authentication key by watching RIP packets. The second method uses the MD5 algorithm to create a crypto checksum of a RIP packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead, it contains a crypto-checksum called the digest. The receiving router performs a calculation using the correct authentication key and discards the packet if the digest does not match. In addition, a sequence number is maintained to prevent the replay of older packets. This method provides stronger assurance that routing data originated from a router with a valid authentication key.
RIP 1
Network Mask
RIP 1 derives the network mask of received networks and hosts from the network mask of the interface from which the packet was received. If a received network or host is on the same natural network as the interface over which it was received, and that network is subnetted (the specified mask is more specific than the natural network mask), then the subnet mask is applied to the destination. If bits outside the mask are set, it is assumed to be a host; otherwise, it is assumed to be a subnet.
Auto Summarization
The Nokia implementation of RIP 1 supports auto summarization; this allows the router to aggregate and redistribute nonclassful routes in RIP 1.
Note Nokia recommends that you run version 2 only on a Nokia Virtual Firewall for Check Point VSX gateway. For warp interfaces, only version 2 multicast mode is supported.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
103
Voyager Interface
Using Voyager, you can configure the following options: Version: You an use either RIP 1or RIP 2. RIP interfaces: You can specify the interfaces on which to run RIP. Metric: You can set the cost to use a given interface. Accept updates. You can configure whether or not to accept updates from other routers speaking RIP. Accepting updates specifies whether RIP packets received from a specified interface is accepted or ignored. Ignoring an update can result in suboptimal routing. Therefore, Nokia recommends that you retain the default setting for accepting updates. Transport: You can set this option only for RIP 2. You can set either broadcast or multicast. The RIP 2 option should always be set to multicast unless RIP 1 neighbors exist on the same link and it is desired that they hear the routing updates. Auto summarization: You should set auto summarization to aggregate and redistribute nonclassful routes in RIP 1.
104
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
RIP
You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable the option to advertise the virtual IP address on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address. For more information on enabling the advertising of a virtual IP address when running RIP, see Configuring RIP on page 105, step 14.
Note Nokia also provides support for BGP, OSPF, and PIM, both Sparse-Mode and Dense-Mode, to advertise the virtual IP address of the VRRP virtual router, beginning with IPSO 3.7.90.
Configuring RIP
1. Use Check Point Provider-1 to configure an Ethernet interface. 2. You must enable RIP on the management station using Provider-1. For more information on how to do so, see Enabling RIP for Nokia Virtual Firewall for Check Point VSX on page 102. 3. Click the Virtual Systems tab. 4. Click Configuration in the tree view next to the name of the routing instance you want to configure RIP. 5. Click the RIP link in the Routing section. 6. Click on for each interface to configure; then click Apply. 7. Click either 1 or 2 in the Version field to select RIP 1 or RIP 2, respectively, for each interface; then click Apply.
Note Nokia recommends that you run version 2 on a Nokia Virtual Firewall for Check Point VSX gateway. On wrp interfaces, only version 2 multicast mode is supported.
8. (Optional) Enter a new cost in the Metric text box for each interface; then click Apply. 9. (Optional) To configure the interface to not accept updates, click on the on radio button in the Accept updates field; then click Apply. 10. (Optional) If you want to configure the interface to not send updates, click on in the Send updates field; then click Apply. 11. (Optional) If you selected RIP 2 for an interface, make sure that Multicast is turned on for that interface; then click Apply.
Note When you use RIP 2, always select the multicast option. Nokia recommends that you not operate RIP 1 and RIP 2 together.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
105
12. (Optional) If you selected RIP 2 for an interface, select the type of authentication scheme to use from the AuthType drop-down list; then click Apply. For simple authentication, select SIMPLE from the AuthType drop-down window. Enter the password in the Password edit box; then click Apply. The password must be from 1 to 16 characters long. For MD5 authentication, select MD5 from the AuthType drop-down list. Enter the password in the MD5 key text box; then click Apply. 13. (Optional) If you selected MD5 as your authentication type and want to ensure interoperability with Cisco routers running RIP MD5 authentication, click yes in the Cisco Interoperability field. The default is no, which means that RIP MD5 is set to conform to Nokia platforms. Click Apply. 14. If VRRP is enabled on a physical interface, click On next to the Virtual Address field to enable RIP on the virtual IP address associated with this interface; then click Apply.
Note Do not enable the option to advertise the virtual IP address on a wrp interface. If VRRP is not configured on an interface, do not enable the option to advertise the virtual IP address for that interface.
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure RIP. 3. Click the RIP link in the Routing section. 4. To modify the update interval, enter the new update interval in the Update Interval text box; then click Apply. 5. To modify the expire interval enter the new expire interval in the Expire Interval text box; then click Apply. 6. To make your changes permanent, click Save.
106
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
RIP
Configuring Auto-Summarization
Auto-summarization allows you to aggregate and redistribute non-classful routes in RIP 1.
Note Auto-summarization applies only to RIP 1.
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure RIP. 3. Click the RIP link in the Routing section. 4. To enable auto-summarization, click on in the Auto-Summarization field; then click Apply. 5. To disable auto-summarization click off in the Auto-Summarization field; then click Apply. 6. To make your changes permanent, click Save.
Note By default, auto-summarization is enabled.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
107
3. Click Configuration in the tree view next to the name of the EVR., which in this example, as the Example screen shot of Network Voyager below shows, is referred to as vs1. 4. Click on next to the external and internal interfaces of the EVR to enable RIP. The screen shot below of Network Voyager configuration for the EVR shows that interface eth4 is configured as an external interface with an IP address of 172.168.231.1/24. The screen shot also shows that the internal interface is an unnumbered link called wrpj129. 5. Click either 1 or 2 to select the version of RIP for each interface. Nokia recommends that you select version 2. 6. Click on next to the Virtual Address field for the eth4 interface to advertise the VRRP virtual IP address on this interface.
Caution Do not enable the virtual address option for the wrpj129 interface. This option is not supported on wrp interfaces.
7. Click Apply, and then click Save to make your changes permanent. 8. (Optional) You can remove the default route for the EVR. To do so, click Configuration in the tree view next to the name of the EVR, which in this example, is vs1. Click the Routing Options link. Click on next to Ignore IPv4 Default Route. The default is off, which means that the default route is automatically installed.
Note Make sure that you are not removing the route from the EVR to the Provider-1 or SmartCenter management station. The EVR must always have a route to the management station.
9. Click Apply, and then click Save to make your changes permanent.
108
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
RIP
Configuring RIP on a VS
This example shows you how to configure RIP on a VS in a VRRP setup. You do not have to have an EVR configured. If you want to configure an IVR, configure it the same way you configure a VS. Perform the following procedure on each member of the VRRP pair, starting with the master.The example assumes that you configured interfaces and created the VS using the Provider-1 GUI. 1. Initiate a Nokia Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the VS, which in this example, as the Example Nokia Network Voyager screen shot below shows, is vs2. 4. Click on next to the internal and external interfaces for the VS. In this example, the internal interface is eth-s1p1c0.339 with an IP address of 173.168.39.0/24 The external interface is an unnumbered interface, which in this example is wrp129. 5. Click either 1 or 2 to select the version of RIP for each interface. Nokia recommends that you select version 2. 6. Click on in the Virtual Address field to advertise the VRRP virtual IP address for the eths1p1c0.330 interface only.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
109
Caution Do not enable the virtual address option for the wrp129 interface. This option is not supported on wrp interfaces.
7. Click Apply, and then click Save to make your changes permanent. 8. Make sure that the wrp129 interface, the interface that connects the VS to the EVR, is also enabled on the configuration page for the EVR, which in this example is vs1. That is, both the wrpj129, which connects the EVR to the VS, and wrp129 interfaces must be enabled on the configuration page for the EVR.
Network Voyager Configuration of VS
PIM
Protocol-Independent Multicast (PIM) gets its name from the fact that it can work with any existing unicast protocol to perform multicast forwarding. It supports two different types of multipoint traffic distribution patterns: dense and sparse. Dense mode is most useful when: Senders and receivers are in close proximity.
110
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
There are few senders and many receivers. The volume of multicast traffic is high. The stream of multicast traffic is constant. Dense-mode PIM resembles Distance Vector Multicast Routing Protocol (DVMRP). Like DVMRP, dense-mode PIM uses Reverse Path Forwarding and the flood-and-prune model. Sparse mode is most useful when: A group has few receivers. Senders and receivers are separated by WAN links. The type of traffic is intermittent. Sparse-mode PIM is based on the explicit join model; the protocol sets up the forwarding state for traffic by sending join messages. This model represents a substantial departure from floodand-prune protocols, such as dense-mode PIM, which set up the forwarding state through he arrival of multicast data. You can configure different modes of PIM, either sparse or dense, for different routing instances. You cannot, however, enable both modes of PIM on the same routing instance, that is, virtual system. For more information about PIM, read the following Internet Engineering Task Force (IETF) drafts. For Dense-Mode PIM, see Protocol-Independent MulticastDense Mode (PIM-DM): Protocol Specification (Revised). For Sparse-Mode PIM, see Protocol-Independent MulticastSparse Mode (PIM-SM): Protocol Specification (Revised).
CLI Support
IPSO 3.9.92 supports CLI commands to configure and to monitor PIM for a virtual system. To configure PIM, use the following syntax before any specific command:
set instance <instance name>
To use the show commands for PIM, use the following syntax:
show instance <instance name>
For more information about how to use CLI, see the Nokia IPSO CLI Reference Guide.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
111
You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable, the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address. For more information on how to configure this option through Voyager, see either Configuring Dense-Mode PIM or Configuring Sparse-Mode PIM.
Note Nokia also provides support for BGP, OSPF, and RIP to advertise the virtual IP address of the VRRP virtual router, beginning with IPSO 3.7.90.
4. Click Apply, and then click Save to make your changes permanent. 5. (Optional) To configure this interface to use the VRRP virtual IP address, in the Virtual address field, click On.
Note You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address.
6. Click Apply. 7. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address text box. PIM uses this address to send advertisements on the interface.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, all messages from the neighbor are rejected. A PIM router on a shared LAN must have at least one interface address with a subnet prefix that all neighboring PIM routers share.
112
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
8. (Optional) For each interface that is running PIM, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designated router. The default is 1, and the range is 0 to 4294967295 (2^32 - 1).
Note Although you can configure this option, PIM-DM does not use DR Election Priority. On a LAN with more than one router, data forwarding is implemented on the basis of PIM Assert messages. The router with the lowest cost (based on unicast routing) to reach the source of data traffic is elected as the router that forwards traffic. In the case of a tie, the router with the highest IP address is elected to forward traffic.
9. Click Apply, and then click Save to make your change permanent.
Disabling PIM
You can disable PIM on one or more interfaces you configured on each Nokia platform. 1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the Interfaces section, click Off for each interface on which to disable PIM. To disable PIM entirely, click Off next to each interface that is currently running PIM. 4. Click Apply; then click Save to make your change permanent.
4. Click Apply, and then click Save to make your changes permanent. 5. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address text box. PIM uses this address to send advertisements on the interface.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, all messages from the neighbor are rejected. A PIM router on a shared LAN must
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
113
have at least one interface address with a subnet prefix that all neighboring PIM routers share.
6. (Optional) For each interface that is running PIM, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designated router. The default is 1, and the range is 0 to 4294967295 (2^32 - 1). 7. Click Apply, and then click Save to make your changes permanent. 8. Click the Advanced PIM Options link. In the General Timers section, enter a value for the hello interval (in seconds) in the Hello Interval text box. The router uses this interval to send periodic Hello messages on the LAN. 9. In the General Timers section, enter a value for the data interval (in seconds) in the Data Interval text box. This value represents the interval after which the multicast (S, G) state for a silent source is deleted. 10. In the General Timers section, enter a value for the assert interval (in seconds) in the Assert Interval text box. This value represents the interval between the last time an assert is received and when the assert is timed out. 11. In the General Timers section, enter a value for the assert rate limit in the Assert Rate Limit text box. The value represents the number of times per second at which the designated router sends assert messages. The upper limit is 10,000 assert messages per second. 12. In the General Timers section, enter a value (in seconds) for the interval between sending join or prune messages in the Join/Prune Interval text box. 13. In the General Timers section, enter a value for the random delay join or prune interval (in seconds) in the Random Delay Join/Prune Interval text box. This value represents the maximum interval between the time when the Reverse Path Forwarding neighbor changes and when a join/prune message is sent. 14. In the General Timers section, enter a value for the join/prune suppression interval (in seconds) in the Join/Prune Suppression Interval text box. This value represents the mean interval between receiving a join/prune message with a higher hold time and allowing duplicate join/prune messages to be sent again.
Note The join/prune suppression interval should be set at 1.25 times the join/prune interval.
15. In the Assert Ranks section, in the appropriate text box, enter a value for the routing protocol(s) you are using.Assert Rank values are used to compare protocols and determine which router forwards multicast packets on a multiaccess LAN. Assert messages include these values when more than one router can forwarding the multicast packets.
114
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
Note Assert rank values must be the same for all routers on a multiaccess LAN that are running the same protocol.
16. Click Apply. 17. To make your changes permanent, click Save.
6. Click Apply. 7. (Optional) To configure this interface to use the VRRP virtual IP address, in the Virtual address field, click On.
Note You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable, the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address.
8. Click Apply. 9. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address text box. PIM uses this address to send advertisements on the interface. This option is useful only when multiple addresses are configured on the interface.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, then all messages from the neighbor are rejected. A PIM router on a shared LAN must have at least one interface address with a subnet prefix that all neighboring PIM routers share.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
115
10. (Optional) For each interface that is running PIM, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designated router. To break a tie, the designated router with the highest IP address is chosen. If even one router does not advertise a DR election priority value in its hello messages, DR election is based on the IP addresses. The default is 1, and the range is 0 to 4294967295 (232 - 1).
Note To verify whether a PIM neighbor supports DR Election Priority, use the following CLI command: show instance <instance name> pim neighbor <ip_address> For neighbors that advertise a DR election priority value, the following message appears in the summary: DRPriorityCapable Yes.
11. Click Apply. 12. To make your changes permanent, click Save.
1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the PIM Instance Mode field, click On for sparse. 4. Click Apply.
116
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
5. In the HA Mode field, click On to enable the high-availability mode. 6. Click Apply. 7. In the Interfaces section, click On for each interface to run PIM.
Note The number of interfaces on which you can run PIM is unlimited
8. Click Apply. 9. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address edit box. PIM uses this address to send advertisements on the interface. This option is useful only when multiple addresses are configured on the interface.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, then all messages from the neighbor are rejected. A PIM router on a shared LAN must have at least one interface address with a subnet prefix that all neighboring PIM routers share.
10. (Optional) For each interface that is running PIM, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designated router. To break a tie, the designated router with the highest IP address is chosen. If even one router does not advertise a DR election priority value in its hello messages, DR election is based on the IP addresses. The default is 1, and the range is 0 to 4294967295 (2^32 - 1).
Note To verify whether a PIM neighbor supports DR Election Priority, use the following CLI command: show instance <instance name> pim neighbor <ip_address> For neighbors that advertise a DR election priority value, the following message appears in the summary: DRPriorityCapable Yes.
11. Click Apply. 12. To make your changes permanent, click Save.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
117
6. Click Apply. 7. In the Sparse Mode Rendezvous Point (RP) Configuration section, to enable this router as a candidate bootstrap router: a. Click On in the Bootstrap Router field. b. (Optional) Enter the address of the bootstrap router in the Local Address text box. Configure an address for the candidate bootstrap router to help specify the local address used as the identifier in the bootstrap messages. By default, the router chooses an address from one of the interfaces on which PIM is enabled. c. (Optional) Enter the bootstrap router priority (0 to 255) in the Priority text box. Use the priority option to help specify the priority to advertise in bootstrap messages. The default priority value is 0.
Note The domain automatically elects a bootstrap router, based on the assert rank preference values configured. The candidate bootstrap router with the highest preference value is elected the bootstrap router. To break a tie, the bootstrap candidate router with the highest IP address is elected the bootstrap router.
8. In the Sparse Mode Rendezvous Point (RP) Configuration section, to enable this router as a Candidate Rendezvous Point: a. Click On in the Candidate RP Router field. b. (Optional) Enter the local address of the Candidate Rendezvous Point router in the Local Address field. This router sends Candidate Rendezvous Point messages. Configure an address for the Candidate Rendezvous Point to select the local address used in candidate-RP-advertisements sent to the elected bootstrap router. By default, the router chooses an address from one of the interfaces on which PIM is enabled. c. (Optional) Enter the Candidate Rendezvous Point priority (0 to 255) in the Priority text box.
118
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
Use the priority option to set the priority for this rendezvous point. The lower this value, the higher the priority. The default priority value is 0. 9. (Optional) To configure a multicast address for which this router is designated as the rendezvous point, in the Local RPSET field, enter an IP address in the Multicast address group text box and the address mask length in the Mask length text box.
Note If you do not configure a multicast address for the router, it advertises as able to function as the rendezvous point for all multicast groups (224/4)
10. Click Apply. 11. To make your changes permanent, click Save.
6. Click Apply. 7. In the Sparse Mode Rendezvous Point (RP) Configuration section, to enable a Static Rendezvous Point router, click On in the Static RP Router field.
Note Static Rendezvous Point configuration overrides rendezvous point (RP) information received from other RP-dissemination mechanisms, such as bootstrap routers.
8. Enter the IP address of the router to configure as the static rendezvous point in the RP Address text box. Click Apply. 9. (Optional) Enter the multicast group address and prefix length in the Multicast group address and Mask length text boxes. Click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
119
Note If you do not configure a multicast group address and prefix length for this Static Rendezvous Point, it functions by default as the rendezvous point for all multicast groups (224.0.0.0/4).
6. Click Apply. 7. Click the Advanced PIM Options link. In the Sparse Mode Timers section, enter a value for the register suppression interval (in seconds) in the Register-Suppression Interval text box. This value represents the mean interval between receiving a Register-Stop message and allowing Register messages to be sent again. 8. In the Sparse Mode Timers section, enter a value for the bootstrap interval for candidate bootstrap routers (in seconds) in the Bootstrap Interval text box. This value represents the interval between which bootstrap advertisement messages are sent. 9. In the Sparse Mode Timers section, enter a value for the candidate rendezvous point advertisement interval (in seconds) in the Candidate RP-Advertisement Interval text box. This value represents the interval between which Candidate Rendezvous Point routers send Candidate-RP-Advertisement messages. 10. In the Sparse Mode Timers section, enter a value for the shortest path tree threshold (in kilobits per second) in the Threshold (kbps) text box. Enter an IP address for the multicast group to which the SPT threshold applies in the Multicast Group ID text box. Enter the mask length for the group multicast address in the Mask Length edit box. When the data rate for a sparse-mode group exceeds the shortestpath-tree threshold at the last-hop router, an (S,G) entry is created and a join/prune message is sent toward the source. Setting this option builds a shortest-path tree from the source S to the last-hop router.
120
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
11. Click Apply, and then click Save to make your changes permanent. 12. (Optional) In the General Timers section, enter a value for the hello interval (in seconds) in the Hello Interval edit box. The router uses this interval to send periodic Hello messages on the LAN. 13. (Optional) In the General Timers section, enter a value for the data interval (in seconds) in the Data Interval text box. This value represents the interval after which the multicast (S, G) state for a silent source is deleted. 14. (Optional) In the General Timers section, enter a value for the assert interval (in seconds) in the Assert Interval text box. This value represents the interval between the last time an assert is received and when the assert is timed out. 15. (Optional) In the General Timers section, enter a value for the assert rate limit in the Assert Rate Limit text box. The value represents the number of times per second at which the designated router sends assert messages. The upper limit is 10,000 assert messages per second. 16. (Optional) In the General Timers section, enter a value (in seconds) for the interval between sending join/prune messages in the Join/Prune Interval text box. 17. (Optional) In the General Timers section, enter a value for the random delay join/prune interval (in seconds) in the Random Delay Join/Prune Interval text box. This value represents the maximum interval between the time when the reverse path forwarding neighbor changes and when a join/prune message is sent. 18. (Optional) In the General Timers section, enter a value for the join/prune suppression interval (in seconds) in the Join/Prune Suppression Interval text box. This value represents the mean interval between receiving a join/prune message with a higher Holdtime and allowing duplicate join/prune messages to be sent again.
Note The join/prune suppression interval should be set at 1.25 times the join/prune interval.
19. (Optional) In the Assert Ranks section, enter a value for the routing protocol(s) you are using in the appropriate text box. Assert Rank values are used to compare protocols and determine which router forwards multicast packets on a multiaccess LAN. Assert messages include these values when more than one router can forward the multicast packets.
Note Assert rank values must be the same for all routers on a multiaccess LAN that are running the same protocol.
20. Click Apply, and then click Save to make your change permanent. 21. (Optional) The checksum of the PIM register messages is calculated without including the multicast payload. Earlier releases of the Cisco IOS calculate the checksum by including the
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
121
multicast payload. If you experience difficulties having PIM register messages sent by the Nokia appliance being accepted by a Cisco router that is the elected rendezvous point (RP), configure this option. A Nokia appliance that is the elected RP accepts register messages that calculate the checksum with or without the multicast payload, that is, it accepts all register messages. a. To enable Cisco compatibility for register checksums, click On in the Cisco Compatibility Register Checksums field. b. Click Apply, and then click Save to make your change permanent.
Debugging PIM
The following IPSO CLI commands can assist you in debugging PIM:
Command show instance <instance name> pim interface show instance <instance name> pim neighbors Shows Which interfaces are running PIM, their status, and the mode they are running. This command also displays the interface and its DR priority and the number of PIM neighbors on the interface. The IP address of each PIM neighbor and the interface on which the neighbor is present. This command also displays the neighbors DR priority, generation ID, holdtime and the time the neighbor is set to expire based on the holdtime received in the most recent hello message. The number of different types of PIM packets received and transmitted and any associated errors.
show instance <instance name> pim statistics show instance <instance name> mfc cache show instance <instance name> mfc interfaces
The following CLI commands can assist you in debugging sparse-mode PIM (PIM-SM):
Command show instance <instance name> pim bootstrap show instance <instance name> pim candidate-rp Shows The IP address and state of the Bootstrap router.
122
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
Shows PIMs view of the join-prune (*, G and S, G) state, including RP for the group, incoming, and outgoing interface(s), interaction with the multicast forwarding cache and the presence of local members. To view the equivalent information for dense-mode PIM, use the show mfc cache command. The active RP-set, including the RP addresses, their type (or source of information about them) and the groups for which they are configured to act as RP. The RP selected for a particular group based on information from the active RP-set.
show instance <instance name> pim group-rpmapping <groupaddress> show instance <instance name> pim sparse-mode statistics
Error statistics for multicast forwarding cache (MFC); Bootstrap Router (BSR) messages; Candidate Rendezvous Point (CRP) advertisements; and the Internet Group Management Protocol (IGMP).
Use the Trace Options feature to log information about errors and events. 1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the Trace Options section, click on the Add Option drop-down window in the PIM field. Select each option for which you want to log information. You must select each option one at a time and click Apply after you select each option. For each option you select, its name and on and off radio buttons appear just above the drop-down window. To disable any of the options you have selected, click the off radio button, and then click Apply. 4. Click Save to make your changes permanent. The following trace options apply both to dense-mode and sparse-mode implementations: Assert: traces PIM assert messages. Hello: traces PIM router hello messages. Join: traces PIM join/prune messages MFC: traces calls to or from the multicast forwarding cache MRT: traces PIM multicast routing table events. Packets: traces all PIM packets. Trap: Trace PIM trap messages. All: traces all PIM events and packets. The following trace options apply to sparse-mode implementations only: Bootstrap: traces bootstrap messages. CRP: traces candidate-RP-advertisements.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
123
RP: traces RP-specific events, including both RP set-specific and bootstrap-specific events. Register: traces register and register-stop packets. The following trace option applies to dense-mode implementations only: Graft: traces graft and graft acknowledgment packets
5. Click on next to the internal and external interfaces for the EVR to enable PIM-SM on those interfaces. In this example, the external interface is eth4 with an IP address 172.168.1.231, and the internal interface is an unnumbered interface, wrpj129. Click Apply. 6. Click on next to Virtual Address for the eth4 interface to advertise the VRRP virtual IP address on this interface.
Caution Do not enable the virtual address option for the wrpj129 interface. This option is not supported on wrp interfaces.
7. Click Apply, and then click Save to make your changes permanent.
124
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
PIM
Caution Do not enable the virtual address option for the wrpj129 interface. This option is not supported on wrp interfaces.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
125
4. Click sparse in the Protocol Type field. As the example screen shot shows, do not enable the HA mode for the VS. The default is off.
Note To configure PIM-DM, click dense in the Protocol type field and continue with the procedure below.
5. Click on next to the internal and external interfaces for the EVR to enable PIM-SM on those interfaces. In this example, the internal interface is eth-21p1c0.330 with an IP addresses 20.20.20.1/28 and 173.168.39.0, and the external interface is an unnumbered interface, wrp129. Click Apply. 6. Click on in the Virtual Address field for the eth4 interface only to advertise the VRRP virtual IP address on this interface.
Caution Do not enable the virtual address option for the wrp129 interface. This option is not supported on wrp interfaces.
7. Click Apply, and then click Save to make your changes permanent. 8. Make sure that the wrp129 interface, the interface that connects the VS to the EVR, is also enabled on the Nokia Network configuration page for the EVR. That is, both the wrpj129 interface, which connects the EVR to the VS, and the wrp129 interface, must be enabled on the configuration page for the EVR, which in this example is vs1.
Note Nokia recommends that you not configure the VS as either a rendezvous point for a bootstrap candidate router, as the screen shot of the VS configuration shows.
126
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
IGMP
IGMP
Internet Group Management Protocol (IGMP) allows hosts on multiaccess networks to inform locally attached routers of their group membership information. Hosts share their group membership information by multicasting IGMP host membership reports. Multicast routers listen for these host membership reports, and then exchange this information with other multicast routers. The group membership reporting protocol includes two types of messages: host membership query and host membership report. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. Protocol operation requires that a designated querier router be elected on each subnet and that it periodically multicast a host membership query to the all-hosts group. Hosts respond to a query by generating host membership reports for each multicast group to which they belong. These reports are sent to the group being reported, which allows other active members on the subnet to cancel their reports. This behavior limits the number of reports generated to one for each active group on the subnet. This exchange allows the multicast routers to maintain a database of all active host groups on each of their attached subnets. A group is declared inactive (expired) when no report is received for several query intervals.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
127
The IGMPv.2 protocol adds a leave group message and uses an unused field in the IGMPv.1 host membership query message to specify a maximum response time. The leave group message allows a host to report when its membership in a multicast group terminates. Then, the IGMP querier router can send a group-directed query with a very small maximum response time to probe for any remaining active group members. This accelerated leave extension can reduce the time required to expire a group and prune the multicast distribution tree from minutes, down to several seconds The unicast traceroute program allows the tracing of a path from one device to another, using mechanisms that already exist in IP. Unfortunately, you cannot apply such mechanisms to IP multicast packets. The key mechanism for unicast traceroute is the ICMP TTL exceeded message that is specifically precluded as a response to multicast packets. The traceroute facility implemented within IPSRD conforms to the traceroute facility for IP multicast draft specification.
Features
Complete IGMPv.2 functionality Multicast traceroute Complete configurability of protocol timers Administratively-blocked groups Support for interfaces with secondary addresses Monitoring template
Voyager Interface
Using Voyager, you can configure the following options: Version number Loss robustness Query interval Query response interval Last-member query interval Additionally, you can enable and disable router alert.
Configuring IGMP
1. Configure a multicast routing protocol, such as PIM-DM or PIM-SM. The IGMP feature supports IP multicast groups on a network and functions only in
128
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
IGMP
conjunction with a multicast routing protocol to calculate a multicast distribution tree. For more information on multicast routing protocols supported by IPSO 5.0, see PIM.
Note After you enable a mulitcasting protocol, either PIM-DM or PIM-SM, you do not typically need to perform any additional configuration for IGMP because the multicasting protocol automatically enables version 2 of IGMP and set the default values.
2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure IGMP. 4. Click the IGMP link in the Routing section. 5. Complete the following steps for each interface on which you enabled a multicast routing protocol. 6. Click the appropriate Version button to enable either version 1 or 2; then click Apply. The default is version 2
Note A router configured for IGMP version 2 can interoperate with hosts running either IGMP version 1 or version 2. Nokia recommends that you use version 1 only on networks that include multicast routers that are not upgraded to IGMP version 2.
7. (Optional) Enter the loss robustness value in the Loss robustness text box; then click Apply. The range is 1 to 255, and the default is 2. 8. (Optional) Enter the query interval in the Query interval text box; then click Apply. This value specifies the interval, in seconds, that the querier router sends IGMP general queries. The default is 125, and the range is 1 to 3600. 9. (Optional) Enter the query response interval in the Query response interval text box; then click Apply. This value specifies the maximum response time, in seconds, inserted into the periodic IGMP general queries. The higher the value the longer the interval between host IGMP reports, which reduces burstiness. This value must be lower than that of the query interval. The default is 10, and the range is 1 to 25. 10. (Optional) Enter the last member query interval in the Last member query interval text box,; then click Apply. This value specifies the maximum response time, in seconds, inserted into IGMP groupspecific queries. A lower value results in less time to detect the loss of the last member of a multicast group. This value must be lower than that of the query interval. The default is 1, and the range is 1 to 25. 11. (Optional) Click On in the Disable router alert field to actively disable the insertion of the IP router alert typically included in IGMP messages. Disabling this option is useful when interoperating with broken IP implementations that
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
129
might otherwise discard packets from the specified interface. The default is Off, meaning that the IGMP messages include the IP router alert. Click Apply. 12. To make your changes permanent, click Save.
BGP
Border Gateway Protocol (BGP) is an inter-AS protocol, meaning that it can be deployed within and between autonomous systems (ASes). An autonomous system is a set of routers under a single technical administration. An AS uses an interior gateway protocol and common metrics to route packets within an AS; it uses an exterior routing protocol to route packets to other ASes.
Note This implementation supports only BGP version 4.
BGP sends update messages that consist of network number-AS path pairs. The AS path contains the string of ASes through which the specified network can be reached. An AS path has some structure in order to represent the results of aggregating dissimilar routes. These update messages are sent over TCP transport mechanism to ensure reliable delivery. BGP contrasts with IGPs, which build their own reliability on top of a datagram service. As a path-vector routing protocol, BGP limits the distribution of router reachability information to its peer or neighbor routers.
130
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Note For more information about how to operate the Provider-1 MDS, see the Check Point Provider-1 User Guide.
Note To implement RIP, you also need to modify the table.def file in the Provider-1 MDS. For more information, see Enabling RIP for Nokia Virtual Firewall for Check Point VSX on page 102.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
131
Where possible, for internal BGP group types, a single outgoing message is built for all group peers based on the common policy. A copy of the message is sent to every peer in the group, with appropriate adjustments to the next hop field to each peer. This minimizes the computational load of running large numbers of peers in these types of groups.
The following table displays the path attributes and their definitions
Path Attribute AS_PATH Definition Identifies the autonomous systems through which routing information carried in an UPDATE message passed. Components of this list can be AS_SETs or AS_SEQUENCES. Defines the IP address of the border router that should be used as the next hop to the destinations listed in the UPDATE message. Discriminates among multiple exit or entry points to the same neighboring autonomous system. Used only on external links. Determines which external route should be taken and is included in all IBGP UPDATE messages. The assigned BGP speaker sends this message to BGP speakers within its own autonomous system but not to neighboring autonomous systems. Higher values of a LOCAL_PREF are preferred.
NEXT_HOP
MULTI_EXIT_DISC
LOCAL_PREF
132
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Definition Specifies to a BGP speaker that a less specific route was chosen over a more specific route. The BGP speaker attaches the ATOMIC_AGGREGATE attribute to the route when it reproduces it to other BGP speakers. The BGP speaker that receives this route cannot remove the ATOMIC_AGGREGATE attribute or make any Network Layer Reachability Information (NLRI) of the route more specific. This attribute is used only for debugging purposes.
All unreachable messages are collected into a single message and are sent before reachable routes during a flash update. For these unreachable announcements, the next hop is set to the local address on the connection, no metric is sent, and the path origin is set to incomplete. On external connections, the AS path in unreachable announcements is set to the local AS. On internal connections, the AS path length is set to zero. Routing information shared between peers in BGP has two formats: announcements and withdrawals. A route announcement indicates that a router either learned of a new network attachment or made a policy decision to prefer another route to a network destination. Route withdrawals are sent when a router makes a new local decision that a network is no longer reachable.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
133
propagate at different rates across the AS. A time window might occur between the moment when some border gateway (A) receives new BGP routing information (which was originated from another border gateway (B) within the same AS) and the moment the IGP within this AS can route transit traffic to the border gateway (B). During that time window, either incorrect routing or black holes can occur. To minimize such routing problems, border gateway (A) should not advertise to any of its external peers a route to some set of exterior destinations associated with a given address prefix using border gateway (B) until all the interior gateways within the AS are ready to route traffic destined to these destinations by using the correct exit border gateway (B). Interior routing should converge on the proper exit gateway before advertising routes that use the exit gateway to external peers. If all routers in an AS are BGP speakers, no interaction is necessary between BGP and an IGP. In such cases, all routers in the AS already have full knowledge of all BGP routes. The IGP is then only used for routing within the AS, and no BGP routes are imported into the IGP. The user can perform a recursive lookup in the routing table. The first lookup uses a BGP route to establish the exit router, while the second lookup determines the IGP path to the exit router.
BGP Redistribution
When redistributing routes to BGP, you can modify the community, local preference, and MED attributes. Redistribution to BGP is controlled on an AS or AS path basis. BGP 4 metrics (MED) are 32-bit unsigned quantities; they range from 0 to 4294967295 inclusive, with 0 being the most desirable. If the metric is specified as IGP, any existing metric on the route is sent as the MED. For example, this allows OSPF costs to be redistributed as BGP MEDs. If this capability is used, any change in the metric causes the route to be redistributed with the new MED, or to flap, so use it with care. The BGP local preference is significant only when used with internal BGP. It is a 32-bit unsigned quantity and larger values are preferred. The local preference should normally be specified within the redistribution list unless no BGP sources are present in the redistribution list.
134
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Note If BGP routes are being redistributed into IBGP, the local preference cannot be overridden, and this parameter is ignored for IBGP sources. The same is true for confederation peers (CBGP).
Communities
BGP communities allow you to group a set of IP addresses and apply routing decisions based on the identity of the group or community. To implement this feature, map a set of communities to certain BGP local preference values. Then you can apply a uniform BGP configuration to the community as a whole as opposed to each router within the community. The routers in the community can capture routes that match their community values. Use community attributes to can configure your BGP speaker to set, append, or modify the community of a route that controls which routing information is accepted, preferred, or distributed to other neighbors. The following table displays some special community attributes that a BGP speaker can apply.
Community attribute NO_EXPORT (0xFFFFFF01) Description Not advertised outside a BGP confederation boundary. A standalone autonomous system that is not part of a confederation should be considered a confederation itself. Not advertised to other BGP peers. Not advertised to external BGP peers. This includes peers in other members autonomous systems inside a BGP confederation.
For further details, refer to the communities documents, RFCs 1997 and 1998.
Route Reflection
Generally, all border routers in a single AS need to be internal peers of each other; all nonborder routers frequently need to be internal peers of all border routers. While this configuration is usually acceptable in small networks, it can lead to unacceptably large internal peer groups in large networks. To help address this problem, BGP supports route reflection for internal and routing peer groups (BGP version 4). When using route reflection, the rule that specifies that a router can not readvertise routes from internal peers to other internal peers is relaxed for some routers called route reflectors. A typical
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
135
use of route reflection might involve a core backbone of fully meshed routers. This means that all the routers in the fully meshed group peer directly with all other routers in the group. Some of these routers act as route reflectors for routers that are not part of the core group. Two types of route reflection are supported. By default, all routes received by the route reflector that originate from a client are sent to all internal peers (including the client group but not the client). If the no-client reflect option is enabled, routes received from a route reflection client are sent only to internal peers that are not members of the client group. In this case, the client group must be fully meshed. In either case, all routes received from a non-client internal peer are sent to all route reflection clients. Typically, a single router acts as the reflector for a set, or cluster, of clients; for redundancy, two or more routers can also be configured to be reflectors for the same cluster. In this case, a cluster ID should be selected to identify all reflectors serving the cluster, using the cluster ID keyword.
Note Nokia recommends that you not use multiple redundant reflectors unnecessarily as it increases the memory required to store routes on the peers of redundant reflectors.
No special configuration is required on the route reflection clients. From a client perspective, a route reflector is a normal IBGP peer. Any BGP version 4 speaker should be able to be a reflector client. For further details, refer to the route reflection specification document (RFC 2796 as of this writing).
Non-client IBGP Nokia Platform B route reflector Nokia Platform C Nokia Platform E Non-client IBGP Cluster EBGP AS1 Nokia Platform D
Nokia Platform A
IBGP
Client
Client
AS1 has five BGP-speaking routers. With Router B working as a route reflector, there is no need to have all the routers connected in a full mesh.
Confederations
An alternative to route reflection is BGP confederations. As with route reflectors, you can partition BGP speakers into clusters where each cluster is typically a topologically close set of routers. With confederations, this is accomplished by subdividing the autonomous system into multiple, smaller ASes that communicate among themselves. The internal topology is hidden from the outside world, which perceives the confederation to be one large AS.
136
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Each distinct sub-AS within a confederation is referred to as a routing domain (RD). Routing domains are identified by using a routing domain identifier (RDI). The RDI has the same syntax as an AS number, but as it is not visible outside of the confederation, it does not need to be globally unique, although it does need to be unique within the confederation. Many confederations find it convenient to select their RDIs from the reserved AS space (ASes 64512 through 65535 (see RFC 1930)). RDIs are used as the ASes in BGP sessions between peers within the confederation. The confederation as a whole, is referred to by a confederation identifier. This identifier is used as the AS in external BGP sessions. As far as the outside world is concerned, the confederation ID is the AS number of the single, large AS. For this reason, the confederation ID must be a globally unique, normally assigned AS number.
Note Do not nest confederations.
For further details, refer to the confederations specification document (RFC 1965 as of this writing).
AS1
RDI A IBGP
AS2
EBGP
RDI B
IBGP RDI C
00329
AS1 has seven BGP-speaking routers grouped under different routing domains: RDI A, RDI B, and RDI C. Instead of having a full-mesh connection among all seven routers, you can have a full-meshed connection within just one routing domain.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
137
EBGP multihop support can provide redundancy so that an EBGP peer session persists even in the event of an interface failure. Using an address assigned to the loopback interface for the EBGP peering session ensures that the TCP connection stays up even if one of the links between them is down, provided the peer loopback address is reachable. In addition, you can use EBGP multihop support to balance the traffic among all links.
Caution Enabling multihop BGP connections is dangerous because BGP speakers might establish a BGP connection through a third-party AS. This can violate policy considerations and introduce forwarding loops.
AS2
Loopback Address
Loopback Address
00330
Router A and Router B are connected by two parallel serial links. To provide fault tolerance and enable load-balance, enable EBGP multihop and using addresses on the loopback interface for the EBGP peering sessions.
Route Dampening
Route dampening lessens the propagation of flapping routes. A flapping route is a route that repeatedly becomes available then unavailable. Without route dampening, autonomous systems continually send advertisement and withdrawal messages each time the flapping route becomes available or unavailable. As the Internet has grown, the number of announcements per second has grown as well and caused performance problems within the routers. Route dampening enables routers to keep a history of the routes that are flapping and prevent them from consuming significant network bandwidth. This is achieved by measuring how often a given route becomes available and then unavailable. When a set threshold is reached, that route is no longer considered valid, and is no longer propagated for a given period of time, usually about 30 minutes. If a route continues to flap even after the threshold is reached, the time out period for that route grows in proportion to each additional flap. Once the threshold is reached, the route is dampened or suppressed. Suppressed routes are added back into the routing table once the penalty value is decreased and falls below the reuse threshold. Route dampening can cause connectivity to appear to be lost to the outside world but maintained on your own network because route dampening is only applied to BGP routes. Because of increasing load on the backbone network routers, most NSPs (MCI, Sprint, UUNet etc.) have set up route suppression.
138
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Perform the following procedure to configure an a peer autonomous system, corresponding local address, and to enable support for virtual IP for VRRP. 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Enter a value between 1 and 65535 in the Peer autonomous system number edit box. 5. Click the Select the peer group type drop-down list and click either INTERNAL or EXTERNAL. If the peer autonomous system number is different from the local autonomous system of this router, click EXTERNAL. If the peer autonomous system number is the same as that of the local autonomous system of this router, click INTERNAL. You must also select Internal if the local autonomous system is part of a confederation. For more information on confederations, see Confederations. 6. Click Apply. 7. Click the Advanced BGP Options link on the BGP page. 8. Click on in the Virtual Address field to enable virtual IP for VRRP support.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
139
Note You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable, the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address.
9. Click Apply, and then click Save to make your changes permanent.
Memory Size
Base IPSRD is approximately 2 MB Route entry in the local route table is 76 bytes Inbound route entry in the BGP table is 20 bytes Outbound route entry in the BGP table is 24 bytes To calculate the amount of memory overhead on the routing daemon because of BGP peers, calculate the memory required for all of the RIBs according to the following procedures. Add the result to the base IPSRD size. Inbound RIB: Multiply the number of peers by the number of routes accepted. Multiply the result by the size of each inbound route entry. Local RIB: Multiply the number of routes accepted by a local policy by the size of each local route entry. Outbound RIB: Multiply the number of peers by the number of routes advertised. Multiply the result by the size of each BGP outbound route entry.
Example
Assume that a customer is peering with two ISPs that are dual homed and is accepting full routing tables from these two ISPs. Each routing table contains 50,000 routes. The customer is only advertising its local routes (2,000) to each ISP. With these figures, you can compute the total memory requirements:
140
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
The base IPSRD memory is 2 MB. Add this value to the following values to calculate the total memory requirements. 1. To calculate the inbound memory requirements, multiply the number of peers (two ISPs) by the number of routes accepted (50,000). Multiply the resulting value by the size of each inbound route entry in the BGP table (20 bytes). The answer is 2,000,000 or 2 MB. 2. To calculate the local memory requirements, multiply the number of routes accepted (50,000) by the size of each route entry in the local route table (76 bytes). The answer is 4,000,000 or 4MB. 3. To calculate the outbound memory requirements, multiply the number of peers (only one customer) by the number routes advertised (2,000). Multiply the result by the size of each outbound route entry in the BGP table (24 bytes). The answer is 48,000 or 50 K. 4. Add all of the results together (2MB + 2MB + 4MB + 50K). The answer is 8.05MB, which means that IPSRD requires 8.05MB of memory for this example.
Note Make sure that IPSRD is not swapping memory. Look at the memory sizes occupied by user-level daemons like Check Point, ifm , xpand, etc.
To find out how much memory IPSRD occupies, run the following command:
ps -auxww | grep ipsrd
The fourth column labeled, %MEM, displays the percentage of memory that IPSRD occupies.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
141
In these examples, you use Check Point Provider-1 GUI to configure interfaces and IP addresses as well as an EVR and a VS before you configure BGP using Network Voyager. You must also modify the Provider-1 MDS to enable BGP. For more information, see Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
Perform the following procedure on each member of the VSX cluster, that is, the VRRP pair. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the EVR, which in this example as the Example screen shot of Network Voyager below shows, is vs1. 4. Click the BGP link in the Routing section. 5. As the screen shot shows, in the AS number text box for the EVR, enter 100. Click Apply. 6. In the Firewall Address for Nexthop Attribute text box, enter the IP address of the external interface of the EVR, which in a VSX cluster is the VRRP address. In this example, as the screen shot shows, the IP address is 10.1.10.100 Click Apply. 7. In the Peer autonomous system number text box, enter the AS number of the peer, which in this example is 200. In the Peer group type drop-down list, select EXTERNAL. Click Apply. An entry for the AS200 external peer group appears on the Network Voyager configuration page for the EVR, as the Example screen shot shows. 8. In the Add remote peer IP address text box, enter the IP address of the peer, which in this example, is 1.2.3.4. Click Apply. An entry for the peer IP address appears on the Network Voyager configuration page. 9. If the EVR is connecting to the peer through a VRRP interface, as in this example, click on in the Virtual Address field to advertise the VRRP virtual IP address on this interface. Click Apply. 10. Click Save to make your changes permanent.
142
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Perform the following procedure on each member of the VSX cluster, that is, the VRRP pair. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the VS, which in this example, as Example the screen shot of Network Voyager below shows, is vs2. 4. Click the BGP link in the Routing section. 5. As the screen shot shows, in the AS number text box for the VS, enter 100. Click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
143
6. In the Firewall Address for Nexthop Attribute text box, enter the IP address of the external interface of the VS, which is the IP address of the wrp interface that connects the VS to the EVR. In this example, that IP address is 20.20.20.100, as the Example screen shot shows. Click Apply. 7. In the Peer autonomous system number text box, enter the AS number of the external peer, which in this example is 200. In the Peer group type drop-down list, select EXTERNAL. Click Apply. An entry for the AS external peer group appears on the Network Voyager configuration page for the VS, as the screen shot shows. 8. In the Add remote peer IP address text box, enter the IP address of the external peer, which in this example is 192.168.40.10. Click Apply. An entry for the peer address appears on the Network Voyager configuration page. 9. If the VS is connecting to a peer through a VRRP interface, click on in the Virtual Address field to advertise the VRRP virtual IP address on this interface. Click Apply. 10. Click Save to make your changes permanent.
144
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
BGP Configuration of VS
Perform the following procedure on each member of the VSX cluster, that is, the VRRP pair. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the VS, which in this example, as Example Network Voyager screen below shows is v2. 4. Click the BGP link in the Routing section. 5. As the screen shot shows, in AS number text box for the VS, enter 100. Click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
145
6. In the Firewall Address for the Nexthop Attribute text box, enter the IP address of the external interface of the VS, which in this example is the IP address of the wrp interface that connects the VS to the EVR. In this example, that IP address is 20.20.20.100, as the screen shot shows. Click Apply. 7. In the Peer autonomous system number text box, enter the AS number of the EVR, which in this example is 100. In the Peer group type drop-down list, select INTERNAL. Click Apply. An entry for the AS internal peer group appears on the Network Voyager configuration page. 8. In the Add remote peer IP address text box, enter the VRRP IP address of the external interface of the EVR, which in this example is 10.1.0.100. Click Apply, and the click Save to make your changes permanent.
146
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
9. Click Configuration in the tree view next to the name of the EVR, which in this example, as the Example Network Voyager screen shot below shows, is vs1. 10. Click the BGP configuration link in the Routing section. 11. As the screen shot shows, in the AS number text box for the EVR, enter 100. Click Apply. 12. In the Firewall Address for Nexthop Attribute text box, enter the IP address of the external interface of the EVR, which in a VSX cluster, is the VRRP address. In this example, as the Example screen shot shows, the IP address is 10.1.10.100 Click Apply. 13. In the Peer Autonomous system number text box enter the AS number of the VS, which in this example is 100.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
147
In the Peer group type drop-down list, select INTERNAL. Click Apply. An entry for the AS internal peer group appears on the Network Voyager configuration page. 14. In the Add remote peer IP address text box, enter the IP address of the external interface of the VS, which is the IP address of the wrp interface that connects the VS to the EVR. In this example that IP address is 20.20.20.100. Click Apply, and then click Save to make your changes permanent.
BGP Configuration of EVR as internal Peer of VS
148
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Configuring an External Router as BGP Peer of a VS, which sits behind the EVR
You can configure an external router, that is a router in the external network, as a BGP peer of a VS that sits behind the EVR. However that external router must use as the peer IP address the main IP address of the VS. This IP address, which the address of the external interface that points to the EVR is the same IP address you configure as the Firewall Address for Nexthop Attribute. The nexthop address must always be the IP address assigned to the external interface of the VS. This address is used in BGP updates. In the example for how to configure a BGP peer on a VS, that IP address is 20.20.20.100. For more information, see Configuring a BGP External Peer on the VS on page 143.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
149
150
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
In these examples, you use Check Point Provider-1 GUI to configure interfaces and IP address as well as an EVR and a VS before you configure BGP using Network Voyager. You must also modify the Provider-1 MDS to enable BGP. For more information, see Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
Complete the same procedure to configure the BGP external peer on the EVR for a VRRP setup. However, for a standalone setup, you only need to configure the EVR on a single gateway. For more information, see Configuring a BGP External Peer on the EVR on page 142.
Configuring a BGP peer on the VS
Complete the same procedure to configure the BGP external peer on the VS for a VRRP setup. However, for a standalone setup, you only need to configure each VS on a single gateway. For more information, see Configuring a BGP External Peer on the VS on page 143.
Configuring the EVR and VS as Internal BGP Peers
Complete the same procedure to configure the EVR and VS as internal BGP peers for a VRRP setup. However, for a standalone setup, you only need to configure the EVR and each VS as internal BGP peers on a single gateway. For more information, see Configuring the EVR and the VS as Internal BGP Peers on page 145.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
151
Complete the same procedure to configure the BGP external peer on the VS for a VRRP setup. However, for a standalone setup, you only need to configure each VS on a single gateway. For more information, see Configuring a BGP External Peer on the VS on page 143.
152
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
11. Configure an inbound route filter for AS 100 according to BGP Route Inbound Policy Example.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
153
11. Configure an inbound route policy for AS100 according in BGP Route Inbound Policy Example.
154
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
5. Click EXTERNAL in the Peer group type drop-down list; then click Apply. 6. Enter 172.17.10.2 in the Add remote peer IP address text box; then click Apply. 7. Configure route redistribution policy according to BGP Route Redistribution Example. 8. Configure an inbound route filter according to BGP Route Inbound Policy Example to allow Nokia Platform C to accept routes from its EBGP peer.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
155
Verification
To verify that you configured BGP neighbors correctly, log on to Network Voyager and click the Monitor link next to the instance name you configured, click the BGP link in the Routing Protocols section, and then click the neighbor link. For more information about monitoring BGP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
To filter BGP updates based on community ID or special community, specify an AS number along with the community ID or the name of one of the following possible special community attributes: no export, no advertise, no subconfed, or none. 1. Click the Advanced BGP options link. 2. Click on in the Enable Communities field, then click Apply. 3. Follow the steps described in the Configuring Route Inbound Policy on Nokia Platform D Based on an Autonomous System Number example. 4. Enter the community ID or the name of one of the special attributes in the Community ID/ Special community text box, then click Apply. 5. Click on button in the Redistribute All Routes field or enter specific IP prefixes to redistribute as described in the Configuring Route Inbound Policy on Nokia Platform D Based on an Autonomous System Number example, then click Apply.
156
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
In the above diagram, MED values are being propagated with BGP updates. This diagram shows four different configurations. Configuring Default MED for Nokia Platform D Configuring MED Values for all Peers of AS200 Configuring MED Values for each External BGP Peer for Nokia Platform D Configuring MED Values and a Route Redistribution Policy on Nokia Platform D
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
157
Configuring MED Values for each External BGP Peer for Nokia Platform D
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Configure EBGP peers in AS100 and AS200 according to the BGP Neighbors Example. 5. Click the link for the peer IP address for Nokia Platform A under AS100. 6. Enter 100 in the MED sent out text box. 7. Click on in the Accept MED from external peer field; then click Apply. 8. Click the link for the peer IP address for Nokia Platform B under AS100. 9. Enter 200 in the MED sent out text box. 10. Click on in the Accept MED from external peer field; then click Apply. 11. Click the link for the peer IP address for Nokia Platform C under AS200. 12. Enter 50 in the MED sent out text box. 13. Click on in the Accept MED from external peer field; then click Apply. 14. Click Save to make your changes permanent. This configuration allows Nokia Platform D to prefer Nokia Platform A (with the lower MED value of 100) over Nokia Platform B (with the higher MED value of 200) as the entry
158
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
point to AS100 while it propagates routes to AS100. Similarly, this configuration propagates routes with an MED value of 50 to AS200, although no multiple entry points exist to AS200.
Verification
To verify that you configured BGP MED values correctly, run the following command in CLI.
show instance <instance name> route
For more information about this command, see the Nokia IPSO CLI Reference Guide. Note that IPSO 5.0 does not support BGP CLI commands to configure or monitor the routing protocol for a routing instance, that is, virtual system. You must use Network Voyager to configure and monitor BGP for a virtual system. For more information about monitoring BGP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
159
IBGP AS342
Local preference is used in IBGP sessions to indicate the preference for an external route. The route with the highest local preference value is preferred. This example shows how to configure routes learned using Nokia Platform A to have a higher local preference value over Nokia Platform B, which has a default local preference value of 100. First, configure an IBGP link between Nokia platforms A and B as in Configuring IBGP on Nokia Platform A on page 152. Then complete the procedure below to set the local preference value of IBGP Peer Platform A. Setting the Local Preference Value for IBGP Peer Platform B 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Based on Autonomous System Number link. 5. Enter 512 (or any unique number in the range of 512 to 1024) in the Import ID text box. 6. Enter 100 in the AS text box. 7. Enter 200 in the LocalPref text box. 8. Click Apply. 9. Click Accept in the all routes from BGP AS 100 field; then click Apply. 10. Click Save to make your changes permanent.
160
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
192.168.30
Nokia Platform E
.1
.1
To external AS
00333
In the above diagram, all the routers belong to the same Confederation 65525. Nokia platform A and Nokia platform B belong to routing domain ID 65527, Nokia platform C and Nokia platform D belong to routing domain ID 65528, and Nokia Platform E belongs to routing domain ID 65524. In this example, you configure Nokia platform B and Nokia platform C as members of Confederation 65525 and as members of separate routing domains within the confederation. You also configure each platform as confederation peers to Nokia platform E, which has a direct route to the external AS.
Configuring Platform C
1. Set up the confederation and the routing domain identifier. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65525 in the Confederation text box. f. Enter 65528 in the Routing domain identifier text box; then click Apply. 2. Create confederation group 65524. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
161
c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65524 in the Peer autonomous system number text box. f. Click CONFEDERATION in the Peer group type drop-down list; then click Apply. Define properties for the above group. g. Click on in the all field. h. Click on in the All Interfaces field; then click Apply. i. Enter 192.168.40.1 in the Add a new peer text box; then click Apply. 3. Create confederation group 65528. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Enter 65528 in the Peer autonomous system number text box. e. Click CONFEDERATION in the Peer group type drop-down list; then click Apply. Define properties for the above group. f. Click on in the all field. g. Click on in the All Interface field; then click Apply. h. Enter 192.168.45.1 in the Add a new peer text box; then click Apply. 4. Define BGP route inbound policy by using regular expressions for any AS path and from any origin. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Based on ASPath Regular Expressions link. e. Enter 1 in the Import ID text box and enter .* in the ASPATH Regular Expression text box; then click Apply. f. Click on in the Import all routes from AS path field; then click Apply. 5. Define route redistribution. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the Route Redistribution link in the Routing section. d. Click the BGP link in the Redistribute to BGP section.
162
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
e. Click 65528 in the Redistribute to Peer AS drop-down list. f. Click 65524 in the From AS drop-down list; then click Apply. g. Click on in the Enable redistribution of routes from AS 65524 into AS 65528 field; then click Apply. h. Click on in the all BGP AS 65524 routes into AS 65528; then click Apply. i. Click Save to make your changes permanent.
Configuring Platform B
1. Set up the confederation and the routing domain identifier. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65525 in the Confederation text box. f. Enter 65527 in the Routing domain identifier text box; then click Apply. 2. Create confederation group 65524. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65524 in the Peer autonomous system number text box. f. Click CONFEDERATION in the Peer group type drop-down list; then click Apply. Define properties for the above group. g. Click on in the all field. h. Click on in the All Interfaces field; then click Apply. i. Enter 192.168.30.1 in the Add a new peer text box; then click Apply. 3. Create confederation group 65527. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Enter 65528 in the Peer autonomous system number text box. e. Click CONFEDERATION in the Peer group type drop-down list; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
163
Define properties for the above group. f. Click on in the all field. g. Click on in the All Interface field; then click Apply. h. Enter 192.168.35.1 in the Add a new peer text box; then click Apply. 4. Define BGP route inbound policy by using regular expressions for any AS path and from any origin. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Based on ASPath Regular Expressions link. e. Enter 1 in the Import ID text box and enter .* in the ASPATH Regular Expression text box; then click Apply. f. Click on in the Import all routes from AS path field; then click Apply. 5. Define route redistribution. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the Route Redistribution link in the Routing section. d. Click the BGP link in the Redistribute to BGP section. e. Click 65528 in the Redistribute to Peer AS drop-down list. f. Click 65524 in the From AS drop-down list; then click Apply. g. Click on in the Enable redistribution of routes from AS 65524 into AS 65527 field; then click Apply. h. Click on in the all BGP AS 65524 routes into AS 65528; then click Apply. i. Click Save to make your changes permanent.
164
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
AS65526
Nokia Platform B .1 .1 192.168.20
IBGP Route reflector
.2
192.168.10 EBGP
.1 192.168.30
Client .2 Nokia Platform D
00334
.2 Client
Nokia Platform C
In the above diagram, router Nokia Platform A is on AS 65525, and routers Nokia Platform B, Nokia Platform C, and Nokia Platform D are in AS 65526. This example shows how to configure Nokia Platform B to act as a route reflector for clients Nokia Platform C and Nokia Platform D. You then configure platforms C and D as IBGP peers to platform D, as the example shows. Finally, you configure inbound route and redistribution policies for AS 65526.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
165
3. Enter the peer information. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 192.168.10.2 in the Add remote peer ip address text box under the AS65525 external group; then click Apply. 4. Create an internal group. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65526 in the Peer auto autonomous system number text box. f. Select INTERNAL in the Peer group type drop-down list; then click Apply. 5. Configure parameters for the group. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Click on in the all field. This option covers all IGP and static routes. f. Click on in the All Interfaces field; then click Apply. 6. Enter the peer information. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 192.168.20.2 in the Add remote peer ip address text box under the AS65526 routing group. f. Select REFLECTOR CLIENT from the Peer type drop-down list; then click Apply. g. Click the Virtual Systems tab. h. Click the BGP link in the Routing section.
166
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
i. Click the Advanced BGP Options link. j. Enter 192.168.30.2 in the Add remote peer ip address text box under the AS65526 routing group. k. Select REFLECTOR CLIENT from the Peer type drop-down list; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
167
168
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Communities are used to simplify the BGP inbound and route redistribution policies. Each community is identified by either an ID or one of the following special community names: no export, no advertise, no subconfed, or none.
Note Specify the community ID and the AS number in order to generate a unique AS numbercommunity ID combination.
To restrict incoming routes based on their community values, see Path Filtering Based on Communities Example. To redistribute routes that match a specified community attribute, append a community attribute value to an existing community attribute value, or both.
Note The examples that follows is valid only for redistributing routes from any of the specified routing protocols to BGP. For example, configuring community-based route redistribution policy from OSPF to BGP automatically enables the same community-based redistribution policies for all of the other configured policies. In such an example, if you configure a route redistribution policy for OSPF to BGP, these changes also propagate to the redistribution policy for the interface routes into BGP.
1. Follow the steps in the Redistributing OSPF to BGP Example. 2. Match the following ASes with the following community IDsAS 4 with community ID 1 (4:1), AS 5 with community ID 2 (5:2), AS with no exportby entering the AS values in the AS text box and the community IDs in the Community ID/Special community text box; then click Apply.
Note Matching an AS with the no export option only matches those routes that have all of the preceding AS number and community ID values.
3. To append an AS number and community ID combination to the matched routes, click on in the community field; then click Apply. 4. Match AS 6 with community ID 23 (6:23) by entering 6 in the AS edit box and 23 in the Community ID/Special community text box; then click Apply. 5. Match AS with no advertise; then click Apply.
Note Matching an AS with the no advertise option appends the community attribute with the values described in step 2. Thus, all of the routes with the community attributes set to 4:1, 5:2, and no export are redistributed with the appended community attributes 4:1, 5:2, no export, 6:23, and no advertise.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
169
129.10.2.1
00335
170
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
3. Enter 32 in the Mask length edit box; then click Apply. 4. Enter 129.10.2.2 in the Additional gateway edit box; then click Apply. 5. Enter 129.10.1.2 in the Additional gateway edit box; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
171
1. Click the OSPF link in the Routing section. 2. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.1.2; then click Apply. 3. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.2.2; then click Apply 4. Enter 5.6.7.8 in the Add a new stub host column and then click Apply.
172
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
5. In the Nexthop field, click on next to EBGP Multihop to enable the multihop option; then click Apply. 6. (Optional) Enter a value in the TTL text box to set the number of hops over which the EBGP multihop session is established. The default value is 64 and the range is 1 to 255. Click Apply.
Verification
To verify that you have configured load balancing correctly, run the following command in CLI:
show instance <vsid> route
For more information about this command, see the Nokia IPSO CLI Reference Guide. Note that IPSO 5.0 does not support BGP CLI commands to configure or monitor the routing protocol for a routing instance, that is, virtual system. You must use Network Voyager to configure or monitor BGP for a virtual system. For additional verification, log onto Network Voyager, click the Monitor link next to the instance name you configured, click the BGP link in the Routing Protocols section, and then click the neighbor link. For more information about monitoring BGP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
173
Holdtime indicates the maximum number of seconds that can elapse between the receipt of successive keepalive or update messages by the sender before the peer is declared dead. It must be either zero (0) or at least 3 seconds. The default value is 180 seconds. 4. Enter a value in seconds in the Keepalive text box; then click Apply. BGP does not use any transport-protocol-based keepalive mechanism to determine whether peers are reachable. Instead, keepalive messages are exchanged between peers to determine whether the peer is still reachable. The default value is 60 seconds. 5. To make your changes permanent, click Save.
00336
174
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BGP
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
175
Default value 3
Units of measurement Number of route flaps or approximate value of the instability metric Same as above Same as above Seconds Seconds Seconds
2 16 300
6. Enter any changes in the text boxes that correspond to the appropriate fields, then click Apply.
Verification
To verify that you have configured route dampening correctly, run the following command in CLI.: show instance <vsid> route For more information about this command, see the Nokia IPSO CLI Reference Guide. Note that IPSO 5.0 does not support CLI commands for configuring or monitoring BGP for a routing instance, that is, virtual system. You must use Nokia Network Voyager to configure and to monitor BGP for a virtual system. For more information about how to monitor BGP using Network Voyager, see the Displaying Routing Protocol Information section in the Nokia Network Voyager documentation.
If the weights are the same, prefer the path with the largest local preference. If the local preferences are the same, prefer the route that has the shortest AS_path. If all paths have the same AS_path length, prefer the path with the lowest origin type (Origin IGP < EGP < Incomplete).
176
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Static Routes
If the origin codes are the same, prefer the path with the lowest MED attribute (if MED is not ignored). If the paths have the same MED, prefer the external path over the internal path. If the paths are still the same, prefer the path through the closest IGP neighbor. Prefer the path with the lowest IP address, as specified by the BGP router ID.
Static Routes
Static routes (also known as statics) are routes that you manually configure in the routing table. Static routes do not change and are not dynamic (hence the name). Static routes cause packets addresses to the destination to take a specified next hop. Static routes allow you to add routes to destinations that are not known by dynamic routing protocols. Static routes can also be used in providing a default route. Static routes consist of the following: Destination Type Next-hop gateway Static routes can be one of the following types: Normal A normal static route is one used to forward packets for a given destination in the direction indicated by the configured router. Black hole A black hole static route is a route that uses the loopback address as the next hop. This route discards packets that match the route for a given destination. Reject A reject static route is a route that uses the loopback address as the next hop. This route discards packets that match the route for a given destination and sends an ICMP unreachable message back to the sender of the packet.
Static Routes on Nokia Virtual Firewall for Check Point VSX Gateway
The Check Point GUI sets static routes on a Nokia Virtual Firewall for Check Point VSX gateway. If you configure a static route using either Network Voyager or the CLI, it is not persistent across all policy installations or when you reboot the appliance. If you check the Propagate Route to EVR option in the Check Point Provider-1 GUI when configuring a VS, the GUI installs a static route for that IP address or subnet in the EVR. For an IP address, the static route points to the main IP address of the VS. For a subnet, the static route points to the VLAN subnet of the VS.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
177
The Check Point GUI installs a default route in each VS that points to the EVR. You can use Network Voyager to override that default route. For more information, see Configuring Gateway to Ignore Default Route on page 86.
Note If you are configuring a default route between a virtual system and a virtual router, you must specify the Gateway Type as LOGICAL NAME and then select the wrp interface between the virtual system and virtual router as the logical gateway. Use a logical gateway only if the next hop is reachable by a point-to-point interface and the IP address of the gateway is unknown.
7. Click Apply. 8. If you specified: Gateway Type as ADDRESS, enter the IP address of the default router in the Gateway text box Gateway Type as LOGICAL NAME, select the logical interface from the selection box. Click Apply. 9. To disable a default route, click off in the Default field; then click Apply. 10. To make your changes permanent, click Save.
178
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Static Routes
Note If you are configuring a default route between a virtual system and a virtual router, you must specify the Gateway Type as LOGICAL NAME and then select the wrp interface between the virtual system and virtual router as the logical gateway. Use a logical gateway only if the next hop is reachable by a point-to-point interface and the IP address of the gateway is unknown.
8. Click Apply. 9. If you specified: Gateway Type as ADDRESS, enter the IP address of the default router in the Gateway text box Gateway Type as LOGICAL NAME, select the logical interface from the selection box. Click Apply. 10. To make your changes permanent, click Save.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
179
The system uses the rank value to determine which route to use when routes are present from different protocols to the same destination. For each route, the system uses the route from the protocol with the lowest rank number. The default for static routes is 60. The range you can enter is 0 to 255. 5. Click Apply, and then click Save to make your changes permanent.
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. In the Quick-add static routes field, click the Quick-add next hop type drop-down list, and select NORMAL, REJECT, or BLACK HOLE. The default is normal. For more information on static route types, see BGP. 5. In the Quick-add static routes edit box, enter an IP address, its mask length, and add one or more next-hop IP addresses for each static route you want to add. Use the following format: IP address/mask length next hop IP address The IP addresses must be specified in a dotted-quad format ([0 to 255]).[0 to 255].[0 to 255].[0 to 255]) The range for the mask length is 1 to 32. For example, to add a static route to 205.226. 10.0 with a mask length of 24 and next hops of 10.1.1.1 and 10.1.1.2, enter: 205.226.10.0/24 10.1.1.1 10.1.1.2 6. Press ENTER after each entry you make for a static route. 7. Click Apply. The newly configured additional static routes appear in the Static Route field at the top of the Static Routes page.
Note The text box displays any entries that contain errors. Error messages appear at the top of the page.
180
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Static Routes
26.70/30
OSPF
26.73/30
26.74/30
Nokia Platform D
24.0/24
22.1/22
Internet
Remote PCs
00345
In this example, Nokia Platform A is connected to the Internet, with no routing occurring on the interface connected to the Internet (no OSPF or BGP). A corporate WAN is between Nokia platform B and Nokia platform C, and no routing occurs on this link. Use static routes so that the remote PC LAN can have Internet access. Static routes apply in many areas, such as connections to the Internet, across corporate WANs, and creating routing boundaries between two routing domains.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
181
Creating a static route (non-default) 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. In the New Static Route text box enter: 192.168.24.0. 5. In the Mask Length text box enter: 24. 6. In the Gateway text box enter: 192.168.26.70; then click Apply. If you have configured OSPF or RIP on your remote office network, you now have connectivity to the Internet. Disabling a static route 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. Click off for the route you want to disable; then click Apply.
182
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Route Aggregation
4. Enter the IP address of the gateway in the Additional gateway text box. 5. Enter the priority value in the Priority text box; then click Apply. The IP address of the additional gateway that you entered appears in the Gateway column, and new Additional gateway and Priority edit boxes are displayed. To add more backup static routes, repeat steps 3 and 4. 6. To make your changes permanent, click Save.
Route Aggregation
Route aggregation allows you to take numerous specific routes and aggregate them into one encompassing route. Route aggregation can reduce the number of routes that a given protocol advertises. The aggregates are activated by contributing routes. For example, if a router has many interface routes subnetted from a class C and is running RIP 2 on another interface, the interface routes can be used to create an aggregate route (of the class C) that can then be redistributed into RIP. Creating an aggregate route reduces the number of routes advertised using RIP. You must take care must be taken when aggregating if the route that is aggregated contains holes. An aggregate route is created by first specifying the network address and mask length. Second, a set of contributing routes must be provided. A contributing route is defined when a source (for example, a routing protocol, a static route, an interface route) and a route filter (a prefix) are specified. An aggregate route can have many contributing routes, but at least one of the routes must be present to generate an aggregate. Aggregate routes are not used for packet forwarding by the originator of the aggregate route, only by the receiver. A router receiving a packet that does not match one of the component routes that led to the generation of an aggregate route responds with an ICMP network unreachable message. This message prevents packets for unknown component routes from following a default route into another network where they would be continually forwarded back to the border router until their TTL expires.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
183
184
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Route Aggregation
24.46/30
24.49/30
24.50/30
24.53/30 24.54/30
Nokia Platform D
Advertise 192.168.24.0
Backbone running RIPv1
00344
26.1/24
In the preceding figure Nokia Platform B, Nokia Platform C, and Nokia Platform D are running OSPF with the backbone area. Nokia Platform A is running OSPF on one interface and RIP 1 on the backbone side interface. Assume that all the interfaces are configured with the addresses and the routing protocol as shown in the figure. Configure route aggregation of 192.168.24.0/24 from the OSPF side to the RIP side. 1. Initiate a Network Voyager session to Nokia Platform A. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure. 4. Click the Route Aggregation link in the Routing section. 5. Enter 192.168.24.0 in the Prefix for new aggregate text box. 6. Enter 24 in the Mask Length edit box; then click Apply. 7. Click OSPF2 in the New Contributing Protocol drop-down list; then click Apply. 8. Click on in the Contribute all matching routes from OSPF2 field; then click Apply. 9. Click DIRECT in the New Contributing Protocol drop-down list; then click Apply. 10. Click on in the Contribute All Matching Routes from direct field; then click Apply. 11. Click TOP. 12. Click the Route Redistribution link in the Routing section. 13. Click the Aggregates Routes link in the Redistribute to RIP section. 14. Click on radio button in the Export all aggregates into RIP field; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
185
Note If the backbone is running OSPF as well, you can enable aggregation only by configuring the 192.168.24.0 network in a different OSPF Area.
Route Rank
The route rank is the value that the routing subsystem uses to order routes from different protocols to the same destination. You cannot use rank to control the selection of routes within a dynamic interior gateway protocol (IGP); this is accomplished automatically by the protocol and is based on the protocol metric. You can use rank to select routes from the same external gateway protocol (EGP) learned from different peers or autonomous systems. The rank value is an arbitrarily assigned value used to determine the order of routes to the same destination in a single routing database. Each route has only one rank associated with it, even though rank can be set at many places in the configuration. The route derives its rank from the most specific route match among all configurations. The active route is the route installed into the kernel forwarding table by the routing subsystem. In the case where the same route is contributed by more than one protocol, the one with the lowest rank becomes the active route. Some protocolsBGP and aggregatesallow for routes with the same rank. To choose the active route in these cases, a separate tie breaker is used. This tie breaker is called LocalPref for BGP and weight for aggregates.
Rank Assignments
A default rank is assigned to each protocol. Rank values range from 0 to 255, with the lowest number indicating the most preferred route. The table below summarizes the default rank values.
Preference of Interface routes OSPF routes Static routes IGRP routes RIP routes Aggregate routes Default 0 10 60 80 100 130
186
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Route Rank
26.66/30
26.65/30
Nokia Platform B
26.69/30
26.70/30
Nokia Platform C
26.73/30 26.74/30
Nokia Platform A
26.61/24
Nokia Platform D
26.77/28
Hub
RIP Network
Corporate Net
26.79/28
26.80/28
00337
In the preceding figure, the top part of the network is running OSPF and the bottom part of the network is running RIP. Nokia Platform D learns network 192.168.22.0 from two routing protocols: RIP from the bottom of the network, and OSPF from the top of the network. When
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
187
other hosts want to go to 192.168.22.0 through Nokia Platform D, Nokia Platform D can select one protocol route, such as an OSPF route first, to reach the destination. If that route is broken, then Nokia Platform D uses another available route to reach the destination. To configure the routing preferences: 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Routing Options link in the Routing section. 4. Enter 10 in the OSPF edit box. 5. Enter 40 in the RIP edit box; then click Apply. This configuration makes the OSPF route the preferred route. To make the RIP route be the preferred route, enter 40 for OSPF and 10 for RIP.
Route Redistribution
Route redistribution allows routes learned from one routing protocol to be propagated to another routing protocol. This is necessary when routes from one protocol such as RIP, IGRP, OSPF, or BGP need to be advertised into another protocol (when two or more routing protocols are configured on the same router). Route redistribution is also useful for advertising static routes (for example, the default route) or aggregates into a protocol.
Note Route metrics are not translated between different routing protocols.
When you leak routes between protocols, specify routes that are to be injected and routes that are to be excluded. In the case where the prefix is redistributed, you can the metric to advertise.
188
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Route Redistribution
For each prefix that is to be redistributed or excluded, the prefix is matched against a filter. The filter is composed of a single IP prefix and one of the following modifiers: normal, exact, refines, and range. The default modifier is normal. Normal matches any route that is equal to or more specific than the given prefix. Exact matches a route only if it equals the IP address and mask length of the given prefix. Refines matches a route only if it is more specific than the given prefix. Range matches any route whose IP address equals the given prefixs IP address and whose mask length falls within the specified mask length range. A sample route redistribution examples follow.
Note The Route Redistribution link contains over thirty possible route redistribution options.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
189
This procedure enables route redistribution from AS 4 to AS 100. By default, all routes that are excluded from being redistributed from AS 4 are redistributed to AS 100.
190
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Route Redistribution
Note routed is a utility that runs by default on most Unix workstations. This utility listens to RIP network updates and chooses a default route based on what is advertised. This process eliminates the need for static routes and provides route redundancy. Because routed does not send route updates, it is called a passive RIP listener. This subnet (192.168.26.64/28) is categorized as a stub network, meaning that a particular subnet does not send RIP routing updates.
Nokia Platform B
26.69/30
26.70/30
Nokia Platform C
26.73/30 26.74/30
Hub
RIP Network
1. Connect to Nokia Platform A using Voyager. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
191
4. Click the Route Redistribution link under the Routing section. 5. Click the RIP link under the Redistribute to OSPF External section. 6. To redistribute all routes, click Accept in the All RIP routes into OSPF External field. (Optional) To change the cost metric for RIP Routes into OSPF Externals, enter the new cost metric in the Metric text box, then click Apply. 7. To prevent 192.168.22.0/24 and other more specific routes from being redistributed into OSPF External, define a route filter to restrict only this route as follows: a. To configure this filter, enter 192.168.22.0 in the New IP prefix to redistribute text box, and 24 in Mask length text box. Click Apply. b. Select normal in the Match type drop-down list. This specifies to prefer routes that are equal to or more specific than 192.168.22.0/24. c. Click Apply. The filter is fully configured.
192
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Route Redistribution
c. Finally, click restrict in the Action field. This specifies that we want to discard the routes that match this prefix. d. Click Apply. The filter is fully configured.
Nokia Platform B
26.69/30
26.70/30
Nokia Platform C
26.73/30 26.74/30
Nokia Platform A is running OSPF and BGP and its local AS is 4. Nokia Platform E of AS 100 and Nokia Platform A of AS 4 are participating in an EBGP session. Nokia Platform F of AS 200 and Nokia Platform D of AS 4 are also participating in an EBGP session.
Nokia Platform A
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Route Redistribution link in the Routing section. 4. Click the OSPF link in the Redistribute to BGP section. 5. To redistribute OSPF routes into peer AS 100, select 100 from the Redistribute to peer AS drop-down list, then click Apply. 6. (Optional) Enter the MED in the MED text box; then click Apply. 7. (Optional) Enter the local preference in the LocalPref text box, then click Apply. 8. To redistribute OSPF routes, enter the IP prefix in the New IP prefix to redistribute text box and the mask length in Mask length text box; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
193
5. In the All Routes Action field, click either accept or restrict. If you select accept, routes can be rejected individually by entering their IP address and mask length in the appropriate fields. Similarly, if you select RESTRICT, routes can be accepted individually by entering their IP address and mask length in the appropriate fields. 6. If you set All Routes to accept and click Apply, the Rank field is displayed. In the Rank field you can specify the rank to a value that all routes should have. The range of values is 1 to 255.
194
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
7. Enter the appropriate IP address and mask length in the New Route to Filter and Mask Length fields; then click Apply. A new set of fields is displayed adjacent to the newly entered IP address and mask length. 8. Click on or off to enable or disable filtering of this route. 9. From the Match Type field drop-down list, select NORMAL, EXACT, REFINES, or RANGE. 10. In the Action field, click Accept or Restrict to determine what to do with the routes that match the given filter. 11. In the Rank field, enter the appropriate value, and then click Apply. 12. If this completes your actions for this route filtering option, click Save. 13. If this does not complete your actions for this route filtering option, begin again at step 6.
Configuring Route Inbound Policy on Nokia Platform D Based on an Autonomous System Number
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Based on Autonomous System Number link. 5. Enter 512 in the Import ID edit box. Import ID specifies the order in which the import lists are applied to each route. The range for filters based on AS numbers is from 512 to 1024. 6. Enter 100 in the AS text box; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
195
This is the AS number from which routes are to be filtered. 7. (Optional) Enter more values in the Import ID and AS text boxes to configure more inbound policies based on autonomous system numbers; then click Apply.
Note By default, all routes originating from the configures ASes are accepted.
You can accept or reject all routes from a particular AS by enabling the accept or restrict option next to the All BGP routes from AS field. 1. You also can accept or reject particular routes from AS 100 by specifying a route filter. Route filters are specified as shown in the Route Redistribution section. Assume that you want to filter all routes that are strictly more specific than 10.0.0.0/8. In other words, allow all routes whose prefix is not 10.0.0.0/8 except for 10.0.0.0/8 itself, but exclude all routes that are more specific, such as 10.0.0.0/9 and 10.128.0.0/9. 2. To configure this filter, enter 10.0.0.0 in New IP prefix to import text box, and 8 in Mask length text box; click Apply. 3. Select refines in the Match type drop-down list. This specifies routes that are strictly more specific than 10.0.0.0/8. 4. Finally, click restrict in the Action field. This specifies discard the routes that match this prefix. 5. Click Apply. The filter is fully configured.
Configuring Route Inbound Policy on Nokia Platform D Based on ASPATH Regular Expressions
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Based on ASPATH Regular Expressions link. 5. Enter 500 in the Import ID edit box. The import ID specifies the order in which the import lists are applied to each route. For route filters based on AS path regular expressions, the range of values is from 1 to 511. 6. Enter a regular expression that identifies a set of ASes that should be matched with the SPATH sequence of the route:
100|200
This sequence accepts all routes whose ASPATH sequence contains 100 or 200 or both. 7. Select one of the origin options from the Origin drop-down list; then click Apply.
196
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
These options detail the completeness of AS path information. An origin of IGP indicates that an interior routing protocol-learned route was learned from an interior routing protocol and is most likely complete. An origin of EGP indicates the route was learned from an exterior routing protocol that does not support AS paths, and the path is most likely incomplete. When the path information is incomplete, an origin of incomplete is used. 8. Enter a new route filter. In this example assume that you want to filter all routes that are strictly more specific than 10.0.0.0/8. In other words, allow all routes whose prefix is not 10.0.0.0/8 except for 10.0.0.0/8 itself, but exclude all routes that are more specific, such as 10.0.0.0/9 and 10.128.0.0/9. 9. To configure this filter, enter 10.0.0.0 in New IP prefix to import edit box, and 8 in Mask length edit box; then click Apply. 10. Select refines in the Match type drop-down list. This specifies routes that are strictly more specific than 10.0.0.0/8. 11. Finally, click restrict in the Action field. This specifies to discard the routes that match this prefix. 12. Click Apply. The filter is fully configured.
Select ANY from the Origin drop-down list; then click Apply. 2. To accept routes whose last autonomous system is 3662, enter this ASPATH regular expression in the ASPATH Regular Expression text box:
(.* 3662)
Select ANY from the Origin drop-down list; then click Apply. 3. To accept routes that originated from 2041 and whose last autonomous system is 701, enter the following ASPATH regular expression in the ASPATH Regular Expression text box:
2041 701
Select ANY from the Origin drop-down list; then click Apply.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
197
4. To accept SPRINT (AS number 1239) routes that transit through AT&T (AS number 7018) or InternetMCI (AS number 3561), enter the following ASPATH regular expression in the ASPATH Regular Expression text box:
(1239 .* 7018 .*) | (1239 .* 3561 .*)
Select ANY from the Origin drop-down window; then click Apply. 5. Click Save to make your changes permanent.
BOOTP/DHCP Relay
BOOTP/DHCP Relay extends Bootstrap Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) operation across multiple hops in a routed network. In standard BOOTP, all interfaces on a LAN are loaded from a single configuration server on the LAN. BOOTP Relay allows configuration requests to be forwarded to and serviced from configuration servers located outside the single LAN. BOOTP/DHCP Relay offers the following advantages over standard BOOTP/DHCP: You can provide redundancy by configuring an interface on the Nokia system to relay client configuration requests to multiple servers. With this setup, configuration requests are relayed to all the listed servers simultaneously. You can provide load balancing by configuring multiple interfaces on the Nokia system to relay client configuration requests to different servers. It allows you to centrally manage client configuration across multiple LANs. This is particularly useful in large enterprise environments. The IPSO implementation of BOOTP Relay is compliant with RFC 951, RFC 1542, and RFC 2131. BOOTP Relay supports Ethernet and IEEE 802 LANs by using canonical MAC byte ordering, that is, clients that specify Bootp htype=1: 802.3 and FDDI. When an interface configured for BOOTP Relay receives a boot request, it forwards the request to all the servers in its server list. It does this after waiting a specified length of time to see if a local server answers the boot request. If a primary IP is specified, it stamps the request with that address, otherwise it stamps the request with the lowest numeric IP address specified for the interface.
198
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
BOOTP/DHCP Relay
Wait Time
New Server
To enable BOOTP/DHCP relay on an Interface 1. Click BOOTP/DHCP Relay under Configuration > Router Services in the tree view. 2. Select On for the interface on which you want to enable BOOTP/DHCP. 3. Click Apply. Additional fields appear. 4. (Optional) Enter values for one or more of the following parameters, described in Table 11, above. Primary IPEnter the IP address to use as the BOOTP/DHCP router address. Wait TimeEnter the minimum client-elapsed time (in seconds) before forwarding a BOOTP/DHCP request. New ServerEnter the IP address of the BOOTP/DHCP configuration server to which to relay BOOTP/DHCP requests. 5. Click Apply. 6. Repeat to relay BOOTP/DHCP requests to more than one server. 7. Click Save to make your changes permanent. To disable BOOTP/DHCP relay on an interface 1. Click BOOTP/DHCP Relay under Configuration > Router Services in the tree view. 2. Select Off for the interface on which you want to disable BOOTP/DHCP. 3. Click Apply to disable the interface.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
199
When you click Off, then Apply, the BOOTP/DHCP relay parameters (primary IP, wait time, and new server) disappear, however the parameters are still stored in the system. If you select On, then Apply, these parameters reappear. 4. Click Save to make your changes permanent.
200
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
10
Role-Based Administration
When you add a new user, you must assign roles to the user to provide access privileges. Role-based administration (RBA) allows IPSO administrators to create and use separate roles. With RBA, an administrator can allow users to access specific features by including the features in a role and assigning the role to users. Each role can include a combination of administrative (read/write) access to some features, monitoring (read-only) access to other features, and no access to still other features. This feature also provides improved auditing capabilities. To assign a set of access permissions to a user, create a role that specifies levels of access to features you want to include, then assign this role to the relevant user. You can also specify which access mechanisms (Network Voyager or the CLI) are available to the user when you assign a role to the user.
Managing Roles
To view a list of existing roles on your system, click Manage Roles under Configuration > Security and Access >Role Based Administration in the tree view. The following roles are predefined on the system: adminRoleGives the user read/write access to every feature on the system. monitorRoleGives the user read-only access to every feature on the system.
Note When you assign a role containing access to a feature to a user, the user gets access to the configuration pages for that feature but not to the monitor pages for that feature. To provide access to the monitor pages, you must include the monitor privilege for that feature in the role definition.
To add or edit a role 1. Select one of the following: To add a role, click Add Role under Configuration > Security and Access > Role Based Administration in the tree view.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
201
10
To edit a role, click Manage Roles under Configuration > Security and Access > Role Based Administration in the tree view, then click the name of the role.
Caution Because a user with read/write permission to the Users feature can change the password of any user, including the admin user, you should be cautious in assigning roles that contain this permission.
2. If applicable, select a role type from the Role Type drop-down list. You might see only one selection, System, meaning that this role will apply to this machine only. 3. If you are adding a role, enter a name in the Role Name text box. The role name can be any combination of letters and numbers, but it must start with a letter. You cannot edit the name of an existing role. 4. Add features by moving them to the RW (Read/Write) or RO (Read Only) columns, depending on the permission level you want to give to this role. Remove the features by moving them back to the Available column. Press Shift-Click to select a range of features, or Ctrl-click to select multiple features one at a time.
Note If you assign the Clustering feature to a user with the role type System, that user can configure clustering on individual nodes but cannot use Cluster Voyager or the CLI.
5. Click Apply. 6. Click Save to make your changes permanent. To delete a role 1. Click Manage Roles under Configuration > Security and Access > Role Based Administration in the tree view. 2. Check the Delete check box for the role. 3. Click Apply. 4. Click Save to make your changes permanent.
Note You cannot delete the adminRole, clusterAdminRole, or monitorRole default roles.
202
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
4. If you assign a cluster role to a user, you must also assign them the domain value that matches the appropriate cluster ID. 5. Click Apply. 6. Click Save to make your changes permanent.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
203
10
session management. In particular, note that accounting is not the same as account management.
The following service modules are included by default and cannot be deleted: httpd login other snmpd sshd However, you can modify any of these service modules by modifying the service profiles it uses, or by modifying the authentication, account management, or session profiles that are likewise used by a service profile. You cannot delete services or profiles if they are referenced by other definitions. For example, if the service my_service uses the profile my_profile, you cannot delete my_profile until you delete my_service. You can delete both a service and any or all of its profiles at the same time. To configure a service module 1. Click AAA under Configuration > Security and Access in the tree view. 2. You can use an existing session profile, modify an existing session profile, or create a new one. The session profile contains information about how to assign IP addresses to sessions. a. If you are creating a new session profile, scroll down to the Session Profile table and enter a name profile in the New Sess. Profile text box. The name must not match the name of any existing session profiles. b. Select the profile type from the drop-down list for the new session profile, or for an existing session profile.
204
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Select from the following types: PERMITDoes nothing, always returns success. (pam_permit.so.1.0 module) UNIXLogs a message to indicate that a session has started or stopped. Checks whether the password is still valid. (pam_unix_sess.so.1.0 module)
Note These modules reside in the /usr/lib directory.
c. Select a value from the Control drop-down list. For information on control types, see Table 12 on page 207. d. Click Apply. 3. You can use or modify existing account management or authentication profiles or create new ones: a. Scroll to the Account Management Profile Configuration section or the Authentication Profile Section. b. Modify the existing profile by using the associated drop-down lists, or, if you are creating a new profile, enter a name in the New Profile text box that does not match any existing profile names. c. Select the profile type from the drop-down list. For Account Management profiles, the choices are PERMIT and UNIX, described in step 2, above. For Authentication profiles, the choices are described in Table 13 on page 208. d. Select control type from the drop-down list. For information on the control types, see Table 12 on page 207. e. Click Apply. 4. You can use or modify an existing service profile or define a new one. Service profiles describe the characteristics of the PAM service module, by referencing specific Authentication, Accounting and Session profiles. a. Scroll to the Service Profile Configuration Section. b. If you are creating a new service profile, enter a name in the Service Profile text box that does not match any existing service profile names. If you are modifying an existing service profile, enter the name of the profile you want to modify. c. Enter names of existing authorization, account, and session profiles which you want this service profile to use. Leave any of these text boxes blank if the service requirements do not include them. You can include multiple services of any type (authentication, account management, or session).
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
205
10
Note Profiles are invoked in the order that they appear in the relevant list (top to bottom). When you add profiles, they are added to the end of the list. To change the order, delete the profiles that are out of order and add them back in the desired order.
d. Click Apply. 5. Modify an existing service module: a. Enter the name of the service profile that you want the service module to reference in the Profile text box. b. Click Apply. 6. Click Save to make your changes permanent.
Note If multiple authentication servers are configured for the same user, the roles for the user should be identical on all the servers. If the roles are different, the role assigned in the last server (the one lowest in the list) will be used.
To delete a service module or service profile 1. Click the Delete check box for the module or profile you want to delete. 2. Click Apply. 3. Click Save to make your changes permanent.
Note You cannot delete a profile that is used by a service module or another profile. You also cannot delete any of the default service modules or profiles.
To remove a profile from a service profile To remove a profile (authentication, accounting, or session) from a service profile, perform this procedure: 1. Select the authentication, accounting, or session profile in the appropriate service profile. 2. Click the Delete check box for the service profile. 3. Click Apply. 4. Click Save to make your changes permanent.
206
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Note The authentication and accounting profiles that begin with tally and nonuse are used by certain Password and Account Management features and are required for the features to work.
Table 12 describes the profile control types used to determine how the results of multiple authentication, accounting, or session algorithms are handled and when multiple items are defined in the auth. profile, acct. profile or session profile lists for a given Service Profile, a feature known as stacking. (You specify lists of algorithms by defining multiple entries under the Auth. Profile, Acct. Profile, and Session Profile columns of a Service Profile). Values other than required are effective only when the service requires more than one profile.
Table 12 Profile Control Types
Type Required Description The result is retained and the next algorithm is invoked. If the algorithm is at the end of the list, the result is combined with the results of previous algorithms such that any failure result causes failure to be reported. A result of failure is reported immediately and no further algorithms are invoked. If the algorithm is at the end of the list, the result is reported immediately. If no previous algorithm reported failure, a result of success is reported immediately and no further algorithms are invoked. A result of failure for this algorithm is discarded. If a previous algorithm has reported failure or the result of this algorithm is failure, the next algorithm is invoked. If the algorithm is at the end of the list, the result is reported immediately. A result of failure is ignored and a result of success is retained. The next algorithm is always invoked. If the algorithm is at the end of the list, a result of success is reported. Used in Auth. Profiles only. It is the same as sufficient, except that a result of 'authentication error' for this algorithm is reported immediately and no further algorithms are invoked. This type is intended for use with algorithms that access remote servers and where the modules have different result codes for 'authentication error' and 'server not reachable'.
Requisite
Sufficient
Optional
nokia-serverauth-sufficient
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
207
10
Table 13 describes the authentication algorithms that are available in the drop-down list when you create a new authentication profile.
Table 13 Authentication Profile Types
Type HTTP Description Logs a message to indicate that a session has started or stopped. Authenticates the user and verifies the user name and password. Module: pam_httpd_auth.so.1.0 Does not do any authentication. Is considered to succeed when invoked. Module: pam_permit.so.1.0 A client/server authentication system which offloads authentication processing and some other management functions from the IPSO system to a RADIUS server. Defined in RFC2865. Requires additional configuration, as described in Configuring RADIUS on page 209." Module: pam_radius_auth.so.1 Performs one task: if the user ID is 0, it returns success. It can be used to allow password-free access to some services for root. Caution: This module can bypass password checking, which in some cases might be undesirable. Module: pam_rootok_auth.so.1.0 Allows root logins only if the user is logging in on a secure TTY. Module: pam_securetty_auth.so.1 Implements the S/Key algorithm. The user provides the one-time pass phrase, which is used to authenticate the user by using the password database. Module: pam_skey_auth.so.1.0 Authenticates the SNMP packets from a user (Management Station). When an SNMP user is added in the system through Network Voyager, a corresponding authentication and privacy key is created and kept in the usmUser database, /var/ucd-snmp/ snmpd.conf. When an SNMP packet is received, the user name in the packet is used to retrieve the user information from the database and imported to the SNMP agent local store by this module. This information is then used to authenticate the packets. Module: pam_snmpd_auth.so.1.0 A client/server authentication system, which offloads authentication processing and some other management functions from the IPSO system to a RADIUS server. Requires additional configuration, as described in Configuring TACACS+ on page 212. Module: pam_tacplus_auth.so.1.0 Maintains a count of attempted accesses and resets count on success. Module: pam_tally_auth.so.1.0 Uses the local password database to authenticate the user. When the user enters user name and password, this module is called to authenticate the user. Module: pam_unix_auth.so.1.0
PERMIT
RADIUS
ROOTOK
SECURETTY
SKEY
SNMPD
TACPLUS
TALLY
UNIX
208
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Configuring RADIUS
RADIUS (Remote Authentication Dial-In User Service) is a client/server authentication software system that supports remote-access applications. This service allows an organization to maintain user profiles in a centralized database that resides on an authentication server. A host contacts a RADIUS server, which determines who has access to that service. IPSO will accept users configured on a RADIUS server even if there is no corresponding local account on the Nokia system (assuming that you configure the RADIUS server and IPSO appropriately). See Configuring Nonlocal RADIUS Users on page 211 for more information. You can configure RADIUS as an AAA module so that your appliance functions as a RADIUS client. Nokia systems do not include RADIUS server functionality. You can configure your appliance to contact more than one RADIUS server. If the first server in the list is unreachable, the next RADIUS server in the priority ranking is contacted to provide the functionality. You can remove a server at any time by checking the Delete check box next to the row for the server you want to remove. In the following procedure, these names are used for purposes of example: Auth Profile is called RADIUS_http_authprofile. Service profile is called RADIUS_prof_httpd. Username is nokiaadmin. To configure RADIUS client on your appliance 1. Click AAA under Configuration > Security and Access in the tree view. 2. Create an authorization profile called RADIUS_httpd_authprofile: a. Scroll to the Auth. Profile section. b. Enter RADIUS_httpd_authprofile in the New Auth. Profile text box. c. Click the Type drop-down list and select RADIUS. d. Select a control type from the drop-down list. For descriptions of profile control types, see Table 12 on page 207. e. Click Apply and click Save to make your changes permanent. The name of the RADIUS authentication profile appears in the Auth. Profile table. A link labeled Servers also appears in the same row. 3. Specify the RADIUS servers this client will use: a. Scroll to the Service Profile section and click the Servers link for the profile you just created. The AAA RADIUS Authorization Servers Configuration page appears.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
209
10
b. Enter values in the following fields: PriorityEnter a unique integer to indicate the priority of the server in the Priority text box. There is no default. You must enter a value in the Priority text box. You can configure multiple servers for a profile, and the priority value determines which server to try first. A smaller number indicates a higher priority. Host addressEnter the IP address of your RADIUS server. RADIUS supports only IPv4 addresses. Port numberEnter the port number of the UDP port to contact on the server host. The default is 1812, which is specified by the RADIUS standard. The range is 1 to 65535.
Caution Firewall software often blocks traffic on port 1812. To ensure that RADIUS packets are not dropped, make sure that any firewalls between the RADIUS server and IPSO devices are configured to allow traffic on UDP port 1812.
SecretEnter the shared secret used to authenticate the authorization profile between the RADIUS server and the local client. Enter a text string without a backslash. You must also configure this same value on your RADIUS server. For more information see RFC 2865. The RFC recommends that the shared secret be at least 16 characters long. Some RADIUS servers limit the shared secret to 15 or 16 characters. Consult the documentation for your RADIUS server. Timeout (optional)Enter the number of seconds the system waits for a response after contacting the server. The default value is 3. Depending on your client configuration, if the client does not receive a response, it retries the same server or attempts to contact another server. Max Tries (optional)Enter the maximum number attempts to contact the server. The default is 3. If all of the attempts do not make a reliable connection within the timeout period, the client stops trying to contact the RADIUS server.
Note The maximum tries value includes the first attempt. For example, a value of 3 means the client makes two additional attempts to contact the RADIUS server after the first attempt.
c. Click Apply. d. Click Save to make your changes permanent. e. To configure additional RADIUS authentication profiles, repeat this procedure to configure additional RADIUS authentication profiles. You must configure a RADIUS authentication server for each profile even if you associate the new profile with a server that you previously configured for an existing RADIUS authentication profile.
210
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
4. Create a service profile: a. Scroll to the Service Profile section. b. Enter the following values in the appropriate text boxes: Service profileEnter RADIUS_prof_httpd. This is the name of the authorization profile you created in step 2. Acct. ProfileEnter base_httpd_acctprofile. Session ProfileEnter base_httpd_sessprofile. c. Click Apply, then click Save to make your changes permanent. 5. Associate the service module httpd with the RADIUS_prof_httpd profile. 6. Click Users under Configuration > Security and Access, and create a user called nokiaadmin with UID=0 and home directory of /var/emhome/nokiaadmin. This user is shown for purposes of example; you can also use any other locally-configured user. 7. Configure the nokiaadmin user and password on your RADIUS server. 8. Test Network Voyager access by using the RADIUS login ID nokiaadmin.
For example:
Nokia-IPSO-User-Role = "foorole, barrole" Nokia-IPSO-User-Role = "foorole:foodomain, barrole" Nokia-IPSO-User-Role = "foorole:foodomain;bardomain, barrole:foodomain;bardomain" Note Make sure the role names match existing roles in the IPSO system.
3. Specify whether the Nokia users should have superuser access to the IPSO shell by adding the following VSA:
Nokia-IPSO-SuperUser-Access = <0|1>
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
211
10
in which 0 provides nonsuperuser access 1 provides superuser access To configure a Nokia system for nonlocal users 1. On your Nokia system, create the roles that are to be assigned to the nonlocal users. 2. Create an authentication profile of type RADIUS and set the control level to sufficient. 3. Add the new authentication profile to each appropriate service profile. 4. Make the RADIUS authentication profile the first authentication mechanism for each appropriate service by deleting the other authentication profiles for each service and then adding them back again. The other profiles are then added after the RADIUS authentication profile. See step 4 on page 205 for information about adding an authentication profile to a service. See To remove a profile from a service profile on page 206 for more information about deleting an authentication profile from a service. 5. For critical users, you should configure the Nokia system to allow access even if the RADIUS server is unavailable: a. Create local accounts for these users. b. If necessary, add a local authentication profile after the RADIUS profile for all the service profiles. To log in as a superuser If the Nokia Superuser VSA is set to 1 for a nonlocal user, they can log into the IPSO shell with superuser privileges if they perform the following procedure: 1. Log into the system using command line. 2. The default shell is the IPSO CLI., enter
shell -
Configuring TACACS+
The TACACS+ (Terminal Access Controller Access Control System) authentication protocol allows a remote server that is not part of IPSO to authenticate users on behalf of the IPSO system. IPSO will accept users configured on a TACACS+ server even if there is no corresponding local account on the Nokia system (assuming that you configure the TACACS+ server and IPSO appropriately). See Configuring Nonlocal TACACS+ Users on page 214 for more information.
212
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
All data sent to the TACACS+ server are encrypted. IPSO supports TACACS+ for authentication only, and not for accounting. Challenge-response authentication, such as S/Key, over TACACS+ is not supported. You can configure TACACS+ support separately for various services. The Network Voyager service is one of those for which TACACS+ is supported and is configured as the httpd service. When TACACS+ is configured for use with a service, IPSO contacts the TACACS+ server each time it needs to check a user password. If the server fails or is unreachable, the password is not recognized and the user is not allowed access. Before you change the Network Voyager configuration, confirm any new configuration. To configure TACACS+ servers for a single authentication profile 1. Click AAA under Configuration > Security and Access in the tree view. 2. Create a TACACS+ authorization profile: a. Scroll to the Auth. Profile Section. b. Enter a name in the New Profile text box which does not match any existing profile names. c. From the profile type drop-down list, select TACPLUS. See Table 13 on page 208 for descriptions of the profile types. d. Select a control type from the drop-down list. For descriptions of control types, see Table 12 on page 207. e. Click Apply, and then click Save to make your changes permanent. The name of the TACACS+ authentication profile appears in the Auth. Profile table. A link labeled Servers also appears in the new row. 3. Configure one or more TACACS+ servers for the authentication profile you created: a. In the Auth. Profile table, click the Servers link in the row for the TACACS+ authorization profile you configured in step 2. The AAA TACACS+ Authorization Servers Configuration page appears. b. Enter values in the following text boxes: PriorityEnter a unique integer to indicate the priority of the server in the Priority text box. There is no default. You must enter a value in the Priority text box. You can configure multiple servers for a profile, and the priority value determines which server to try first. A smaller number indicates a higher priority. Host addressEnter the IP address of the TACACS+ Server. TACACS+ supports only IPv4 addresses. Port numberEnter the port number of the TCP port to contact on the server host. The default is 49, which is specified by the TACACS+ standard. The range is 1 to 65535. SecretEnter the shared secret used to authenticate the authorization profile between the TACACS+ server and the local client. You must also configure this same value on your TACACS+ server. Enter a text string without a backslash.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
213
10
Timeout (optional)Enter the number of seconds to wait for a response after contacting the server. Depending on your client configuration, if the client does not receive a response, it retries the same server or attempts to contact another server. The default value is 3. c. Click Apply, and then click Save to make your changes permanent. 4. Repeat step 2 to configure additional TACACS+ authentication profiles. You must configure a TACACS+ authentication server for each profile even if you associate the new profile with a server that you previously configured for an existing TACACS+ authentication profile. 5. Repeat step 3 of this procedure to configure additional AAA TACACS+ authentication servers for existing TACACS authentication profiles. 6. Associate the service module httpd with the name of the TACACS+ authorization profile that you created in step 2.
In
Nokia-IPSO-SuperUser-Access = <0|1>
0 provides nonsuperuser access 1 provides superuser access 2. Configure the appropriate user accounts in the TACACS+ server. The following is an example:
#key = password group = ipso-admin { service = nokia-ipso { Nokia-IPSO-User-Role = "adminRole" Nokia-IPSO-SuperUser-Access = 1 } }
214
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
#IPSO admin users user = admin { member = ipso-admin login = cleartext changeme } user = Landon { member = ipso-admin login = cleartext changeme } #Cluster administrator role for cluster ID 100 group = cluster-admin { service = nokia-ipso { Nokia-IPSO-User-Role = "ClusterRole:100" Nokia-IPSO-SuperUser-Access = 1 } } #Cluster administrator users user = cadmin { member = cluster-admin login = cleartext changeme } user = Mia{ member = cluster-admin login = cleartext changeme }
To configure a Nokia system for nonlocal users 1. On your Nokia system, create the roles that are to be assigned to the nonlocal users. 2. Create an authentication profile of type TACACS+ and set the control level to sufficient. 3. Add the new authentication profile to each appropriate service profile. 4. Make the TACACS+ authentication profile the first authentication mechanism for each appropriate service by deleting the other authentication profiles for each service and then adding them back again. The other profiles are then added after the TACACS+ authentication profile. See step 4 on page 205 for information about adding an authentication profile to a service. See To remove a profile from a service profile on page 206 for more information about deleting an authentication profile from a service.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
215
10
5. For critical users, you should configure the Nokia system to allow access even if the TACACS+ server is unavailable: a. Create local accounts for these users. b. If necessary, add a local authentication profile after the TACACS+ profile for all the service profiles. To log in as a superuser If TACACS+ allows a nonlocal user superuser access, the user must also perform the following procedure to obtain superuser privileges in the IPSO shell: 1. Log into the system using command line. The default shell is the IPSO CLI. 2. Enter
shell
216
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
11
Policy-Based Routing
Policy-based routing (or Advanced Routing in Check Point terminology) allows classification of traffic beyond regular destination-based routing policies. Policy-based routing entries provide an extended set of selectors to classify traffic: Ingress interface Source network Destination network The following graphic shows a configuration where Policy Based Routing is required:
vsx1
VS1
IVR MVS
EVR
VS2
In this configuration, single or multiple interfaces can be used to connect multiple customer networks without VLANs. Network traffic is routed by the internal virtual router (IVR) to the appropriate customer virtual system according to the destination IP address. Additionally, the IVR can forward traffic to VS1 or VS2 based on IP source and destination as well as incoming interface information. For this example, an entry is configured on an IVR. Policy-based routes are configured through Nokia Network Voyager.
Note Policy-based routing is not supported on the IP2250 or IP2255.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
217
11
Policy-Based Routing
Note When you add routes for Policy Based Routing, use either the Nokia Network Voyager GUI or the Check Point GUI for all configuration changes, not both. If you configure routes with both GUIs, the Nokia Network Voyager routes may be deleted after reboot.
Define the source network including the mask length. By default it is 0.0.0.0/0. Define the destination network including the mask length. By default it is 0.0.0.0/0. At least a source or destination must be defined.
218
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
If the ingress interface is relevant to the entry, select it from the pull-down list. Otherwise, use the default: Any. The next hop can be the address or the logical point-to-point interface between virtual system instances. Several next hops can be defined with different priorities.
Note For a route between a VS and a VR (IVR or EVR), you must specify the next hop type to be logical and then select the wrp link between the VS and VR.
For multiple next hops, each one must have a unique priority value. The next hop with a smaller priority value, and which is reachable or active, is selected. In the case of next-hop IP address, if the IP is not directly reachable, next hop is considered unreachable. In the case of next-hop interface, if the interface is turned off or an IP address is not configured on it, it is considered to be inactive. If none of the next hops are reachable or active, all of the packets that match the policy route are rejected. Regular static route is not applied.
Note Policy-based route entries take precedence over regular routing entries.
Note In virtual routing instances, a change of priority is reflected only for new connections if SecureXL acceleration is enabled.
A limited version of policy-based routing configuration is available through the Check Point GUI. If you choose to use Check Point configuration, be aware of the following limitations: Ingress interface information cannot be defined. Multiple next-hop entries for the same subnet are not supported. Only logical interfaces are supported as next hop, not IP addresses. Policy-based routes can only be defined for virtual router instances. Policy-based routes cannot be modified once created and applied to the gateway.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
219
11
Policy-Based Routing
220
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
12
Automatic Backup and Restore gives you the ability to create backups of your VSX VRRP pair so that you can rebuild the gateway pair quickly after the loss of either member. You can also enable automatic backup using vsx_config. See Using the VSX Configuration Utility. Complete the configuration of Automatic Backup in the following order: 1. Create SSH certificates for both VRRP pairs. See Creating SSH Certificates for Automatic Backup 2. Configure Automatic Backup.See Enabling and Configuring Automatic Backup
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
221
12
SSH Certificate
8. Click Apply. This will generate the public keys. 9. Follow steps 1 through 8 for VRRP 2. 10. Navigate to Home page. 11. Click SSH (Secure Shell). 12. Click Goto the authorized keys page link.
222
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
13. In VRRP 1, copy the public key generated in Step 8 and paste it into the authorized keys page of VRRP 2. While performing the above actions, be aware of the following: Paste the DSA public key in the DSA section only. Paste the RSA v2 key in the RSA v2 section only. The keys are displayed in two different formats (OpenSSH and SSH2). Make sure you are pasting them in the correct sections. 14. Click Apply. 15. Click Save to make your changes permanent. 16. Follow Steps 10 through 15 for VRRP 2. 17. To check that the key exchange is working, do the following: From the command line type: ssh <user>@<host> <vrrp-host> If the key exchange is successful, you will not be prompted for a password. If you are prompted for a password, you must reconfigure the SSH certificates.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
223
12
224
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
This appendix describes Commands that you might find useful How to use Nokia Network Voyager to back up and restore the Nokia Virtual Firewall for Check Point VSX gateway Configuration and troubleshooting tips For information about known limitations and workarounds, see the Release Notes for Nokia Virtual Firewall for Check Point VSX NGX R65.
Entering Commands from the Nokia Virtual Firewall for Check Point VSX Gateway
You can enter the commands in this section from the command prompt on the VSX gateway. To ping the interfaces on a virtual system (VS), use the following command:
# ping -z vs<number> <destination IP>
For example:
ping -z vs1 10.10.10.1
If you do not know the VS number, use the fw vsx stat -v command to display information about the VSs configured on your gateway. To view the flow table configured on the gateway, use the following command:
# netstat -F
To erase the existing Nokia IPSO configuration without removing the Check Point modules, use the following command:
newsystem -r
After you enter newsystem -r, reboot the system with the following command:
reboot
Reactivate the Check Point packages after the reboot by using Nokia Network Voyager or the CLI.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
225
To set the environment to a new virtual system, enter the following command:
vsx set -vs <vs number>
To get a policy file from the $FWDIR\conf directory and replace the current running policy with it, use the following command:
fw fetch -f Note You need to be in the appropriate VS instance.
Firewall Commands
Use the following commands to find out information about the VSX gateway and virtual systems:
fw vsx stat -v
Display packets that pass through the given VS. For more information about these commands and other firewall commands, see Command Line Reference section of the Check Point VPN-1 Power VSX NGX R65 guide.
SecureXL Commands:
Use the following commands to view or configure SecureXL:
fwaccel -vs <vsid> stat
226
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
By default, the backup contains all of the configuration (/config), cron (/var/cron), etc (/var/etc), and IPSec files (/var/etc/IPSec). Export versions of Nokia IPSO do not include IPSec files. You can choose to back up the home directories, which are stored in the /var/admin and /var/monitor directories and the log files, which are stored in the /var/logs directory. You can also choose to back up the Check Point VPN-1 Power VSX NGX R65 package. To perform a restore: The gateway must have the same versions of the Check Point packages and Nokia IPSO that are in the backup file. The configuration for the gateway in the management server must be intact and unchanged. To create a backup file manually 1. Click Virtual Systems tab. 2. Click Configuration for the Default instance. 3. Click the Configuration Backup and Restore link in the System Configuration section. 4. In the Manual Backup section, enter a file name in the Backup File Name text box.
Note If you do not enter a name, the backup file is not created.
5. Select whether you want to back up the admin and monitor home directories and the log file directory. 6. Select the Check Point VPN-1 Power (fw) package for back up. 7. Click Apply. 8. Wait for the backup to complete. (The browser status line will report that the page is done.) 9. Click Save to save your backup configuration choices. The backup file is in /var/backup. You can upload this file to any FTP server. You can also schedule regular backups. For more information, see the Nokia Network Voyager Reference Manual. To restore backup file from a remote server
Warning Restoring from a backup file overwrites your existing files.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
227
Warning Make sure that you have enough disk space available on your Nokia appliance before restoring files. If you try to restore files and you do not have enough disk space, you risk damaging the operating system.
1. Perform a fresh installation of the IPSO image and Check Point packages. Do not configure anything. See Performing a Fresh Installation on page 45 for how to perform a fresh install.
Note The system must be running the same version of the operating system and the same packages as those of the backup file.
2. From the Nokia Network Voyager home page, click the System Configuration link and then the Backup and Restore link. 3. Find the Restore from Remote section on the page and enter the required FTP information. 4. Click Apply. 5. A list of available files in the directory you specify appears. Select the backup files you want to restore. 6. Click Apply. 7. Wait for the restore to complete, which may take some time. (The browser status line will report that the page is done.) 8. Do not click Save. Ignore any Unsaved changes will be lost messages. 9. Click the Reboot link at the bottom of the page and wait for the system to reboot.
Note You must reboot your system after restoring from backup files.
10. Verify that the previous configuration has been restored with the fw vsx stat -v command.
228
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
Packets that are destined to other network entities, for example VSs, are passed as is to the IP stack and forwarded uninspected. With SecureXL the packets after the first are wrp-jumps or cut-through over the VR directly to the VS. The inspection and policy enforcement is done on the VSs for the forwarded packets, assuming they are forwarded to a VS and no internal network is directly connected to the EVR.
For example:
fwm load MDS_Default.W HILO_VSX gateway
This procedure does not work for EVRs and VSs. If you need to re-establish trust, you must delete and recreate the EVRs and VSs. Note that the MDS_Default.W file is in /opt/CPfw1-V26/ conf directory: either change directories (cd) into that directory and run the fwm load command, or specify the path in the command.
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
229
Also, after you establish trust with the SIC, instead of pushing the default policy, you can push an ANY, ANY, ANY Accept policy and reload the VSX gateway.
Note For backup and restore options, please see the Check Point documentation.
230
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide