H3C SecBlade FW/VPN Cards. Operation Manual. Hangzhou H3C Technologies Co., Ltd. Manual Version: T R C-1.

Transcription

1 Manual Hangzhou H3C Technologies Co., Ltd. Manual Version: T R C-1.03 Product Version: S9500-CMW310-R1628

2 Copyright , Hangzhou H3C Technologies Co., Ltd. and its licensors All Rights Reserved No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Hangzhou H3C Technologies Co., Ltd. Trademarks H3C,, Aolynk,, H 3 Care,, TOP G,, IRF, NetPilot, Neocean, NeoVTL, SecPro, SecPoint, SecEngine, SecPath, Comware, Secware, Storware, NQA, VVG, V 2 G, V n G, PSPT, XGbus, N-Bus, TiGem, InnoVision and HUASAN are trademarks of Hangzhou H3C Technologies Co., Ltd. All other trademarks that may be mentioned in this manual are the property of their respective owners. Notice Technical Support The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied. To obtain the latest information, please access: h3c.com customer_service@h3c.com h3c.com

3 About This Manual Related Documentation In addition to this manual, each documentation set of the H3C SecBlade FW/VPN Cards includes the following: Manual H3C SecBlade FW/VPN Card Manual Description It introduces all commands available in the configuration and operation on the SecBlade FW/VPN cards. The details include command name, complete command form, parameter, operation view, usage guide and operation example. Organization H3C Manual is organized as follows: Part 1 Overview 2 VPN 3 Security 4 Reliability Contents Profiles the characteristics and functions of the security gateway and firewall, and introduces SecBlade configuration. Focuses on technical principles and application categories of VPNs. The configuration details include L2TP and GRE configuration, dynamic VPN configuration, IPSec and IKE configuration. Describes the configuration on hierarchical command protection, RADIUS/HWTACACS-based AAA, firewall and NAT, SSL and PKI, transparent firewall, Web and filtering, attack prevention and packet statistics, log maintenance, as well as ACL. Introduces VRRP configuration. The VRRP provides backup for devices. 5 Appendix Offers the acronyms used in this manual

4 Conventions The manual uses the following conventions: I. conventions Convention Boldface italic [ ] { x y... } [ x y... ] { x y... } * [ x y... ] * &<1-n> Description The keywords of a command line are in Boldface. arguments are in italic. Items (keywords or arguments) in square brackets [ ] are optional. Alternative items are grouped in braces and separated by vertical bars. One is selected. Optional alternative items are grouped in square brackets and separated by vertical bars. One or none is selected. Alternative items are grouped in braces and separated by vertical bars. A minimum of one or a maximum of all can be selected. Optional alternative items are grouped in square brackets and separated by vertical bars. Many or none can be selected. The argument(s) before the ampersand (&) sign can be entered 1 to n times. # A line starting with the # sign is comments. II. GUI conventions Convention Boldface > Description Window names, button names, field names, and menu items are in Boldface. For example, the New User window appears; click OK. Multi-level menus are separated by angle brackets. For example, File > Create > Folder. < > [ ] Convention Description Button names are inside angle brackets. For example, click <OK>. Window names, menu items, data table and field names are inside square brackets. For example, pop up the [New User] window.

5 Convention Description / Multi-level menus are separated by forward slashes. For example, [File/Create/Folder]. III. Symbols Convention Warning Caution Note Description Means reader be extremely careful. Improper operation may cause bodily injury. Means reader be careful. Improper operation may cause data loss or damage to equipment. Means a complementary description.

6 Overview

7 Manual Overview Table of Contents Table of Contents Chapter 1 SecBlade Overview SecBlade Firewall Cards SecBlade VPN Cards Chapter 2 SecBlade Configuration SecBlade Configuration Configuring Interface Aggregation for the SecBlade Card Creating a SecBlade Module Specifying the Layer 3 Interface Connecting the Switch and the SecBlade Card Specifying the VLANs Protected by the SecBlade Card Mapping the SecBlade Module to the SecBlade Card Logging into the SecBlade Card Configuring Default Login User Function Displaying Information about the SecBlade Module i

8 Manual Overview Chapter 1 SecBlade Overview Chapter 1 SecBlade Overview 1.1 SecBlade Firewall Cards SecBlade firewall cards are designed to address the requirements on the security of enterprise or campus networks. By integrating the forwarding function of the switch and services processing, it enables the switch to handle security services as required for security defense and monitoring while forwarding data high efficiently. SecBlade firewall cards are security-specific cards that combine the VLAN switching technology of the switch and the network security technology. Furthermore, it inherits the feature of wire speed-based high capacity forwarding of the switch, and integrates the securevlan technology into the VLAN technology for security purpose. SecBlade firewall cards can protect network borders as well as multiple demilitarized zones (DMZs) and VLANs crossing areas in the Intranet. 1-1

9 Manual Overview Chapter 1 SecBlade Overview Table 1-1 SecBlade FW card functions Attribute Description Network security Authenticatio n, authorization and accounting (AAA) Firewall Mail/network page filtering RADIUS HWTACACS CHAP authentication PAP authentication Domain authentication Packet filtering Access control list on the basis of interface Access control list on the basis of time period ASPF status firewall Anti-attack features: Land, Smurf, Fraggle, WinNuke, Ping of Death, Tear Drop, IP Spoofing, SYN Flood, ICMP Flood, UDP Flood, ARP spoofing attack defending Initiative and reverse ARP query Illegal flag bit attack defending of TCP packets Super ICMP packet attack defending Address/port scanning defending DoS/DDoS attack defending ICMP redirection and unreachable packets controlling Tracert packets controlling IP packets with route record controlling Static and dynamic blacklist MAC and IP addresses binding Worm virus defending Transparent firewall Reverse path forwarding Mail filtering: SMTP mail addresses SMTP mail titles SMTP mail contents SMTP mail attachments Network page filtering: HTTP URLs HTTP contents 1-2

10 Manual Overview Attribute Description Chapter 1 SecBlade Overview VPN Network interconnection Network protocol Security management NAT L2TP VPN GRE VPN LAN protocol Data link layer protocol IP service Real time attack log Blacklist log Address binding log Traffic alarm log Session log Binary format log function Traffic statistics and analysis function Monitoring rate globally or on the basis of security domain Monitoring the percentage of protocol packets globally or on the basis of security domain Security event statistics Real time alarm Periodical transmission Address transmission in address pool mode Address transmission by ACL Easy IP NAT Server Valid time for address transmission Multiple ALGs, including FTP, H323, DNS, and SIP Initiating a connection to the specified LNS according to the full user name and domain name of the VPN user Assigning addresses for VPN users LCP re-negotiation and CHAP re-authentication L2TP multi-instance Using the tunnel technology to encapsulate and decapsulate data packets at both sides of the tunnel Ethernet_II Ethernet_SNAP VLAN PPP PPPoE ARP Static domain name resolution IP address borrowing DHCP relay DHCP server DHCP client 1-3

11 Manual Overview Attribute Description Chapter 1 SecBlade Overview IP routing Static route management RIP-1/RIP-2 OSPF BGP Routing policy Policy routing Network reliability Supporting virtual router redundancy protocol to implement backup Configuration management line interface Local configuration through the Console interface Remote configuration through the AUX interface Local or remote configuration through Telnet or SSH Configuration through switch Hierarchical protection for configuration commands to make sure illegal users cannot configure the device Prompts and help information in Chinese Detailed debugging information for diagnosing network failures Test tools such as Tracert and Ping commands for network diagnosis Telnet for directly logging into and managing other network devices FTP Server/Client TFTP Logging File system management User interface configuration to provide multiple authentication and authorization functions for login users SNMPv3 and SNMPv2C- and SNMPv1-compatible NTP synchronization 1.2 SecBlade VPN Cards SecBlade VPN cards support various VPN services such as L2TP VPN, IPSec VPN, GRE VPN and dynamic VPN. With SecBlade VPN cards, integrating access to LANs and WANs can implement flatted network aggregation for easing maintenance and reducing costs. In addition, integrating the Internet, Intranet and Extranet can provide for safe access. 1-4

12 Manual Overview Chapter 1 SecBlade Overview Table 1-2 SecBlade VPN card functions Attribute Network security VPN Network interconnection Authenticatio n, authorization and accounting (AAA) Firewall L2TP VPN IPSec/IKE GRE VPN DVPN LAN protocol Link layer protocol Description RADIUS HWTACACS CHAP authentication PAP authentication Domain authentication Packet filtering Access control list on the basis of interface Access control list on the basis of time period Initiating a connection to the specified LNS according to the full user name and domain name of the VPN user Assigning addresses for VPN users LCP re-negotiation and CHAP re-authentication AH and ESP protocols Establishing security association manually or through IKE negotiation automatically DES, 3DES and AES (only for ESP) MD5 and SHA-1 IKE main mode and aggressive mode NAT traversing Using the tunnel technology to encapsulate and decapsulate data packets at both sides of the tunnel Automatic tunnel establishment Tunnel establishment in UDP mode Client access authentication and inter-node encryption and authentication VPN building through dynamical IP addresses Supporting a node in multiple VPN areas Multiple VPN areas NAT traversing IPSec encryption. Server bandwidth saving through dynamic tunnel establishment Ethernet_II Ethernet_SNAP VLAN PPP PPPoE 1-5

13 Manual Overview Chapter 1 SecBlade Overview Attribute Network protocol IP service IP routing Description ARP Static domain name resolution IP address borrowing DHCP relay DHCP server DHCP client Static route management RIP-1/RIP-2 OSPF BGP Routing policy Policy routing Network reliability Supporting virtual router redundancy protocol to implement backup Configuration management line interface Local configuration through the Console interface Remote configuration through the AUX interface Local or remote configuration through Telnet or SSH Configuration through switch Hierarchical protection for configuration commands to make sure illegal users cannot configure the device Detailed debugging information for diagnosing network failures Test tools such as Tracert and Ping commands for network diagnosis Telnet for directly logging into and managing other network devices FTP Server/Client TFTP Logging File system management User interface configuration to provide multiple authentication and authorization functions for login users SNMPv3 and SNMPv2C- and SNMPv1-compatible NTP synchronization 1-6

14 Manual Overview Chapter 2 SecBlade Configuration Chapter 2 SecBlade Configuration 2.1 SecBlade Configuration To make switch and SecBlade work together, perform the following SecBlade configurations on the switch: Configuring Interface Aggregation for the SecBlade Card Creating a SecBlade Module Specifying the Layer 3 Interface Connecting the Switch and the SecBlade Card Specifying the VLANs Protected by the SecBlade Card Mapping the SecBlade Module to the SecBlade Card Logging into the SecBlade Card Configuring Default Login User Function (Optional) Configuring Interface Aggregation for the SecBlade Card Two internal GE interfaces are used to connect the SecBlade card to the switch. You can aggregate these two interfaces into a logical interface for higher bandwidth. Perform the following configuration in system view of the switch. Table 2-1 Configure interface aggregation for the SecBlade card Configure two GE interfaces for aggregation Remove the configuration secblade aggregation slot slot-number undo secblade aggregation slot slot-number By default, no interface aggregation is configured and only one GE interface is available. Caution: When you use the secblade aggregation slot command to configure interface aggregation for the SecBlade card, the SecBlade card will occupy the resources used by other aggregation groups if its resources for interface aggregation are not enough. 2-1

15 Manual Overview Chapter 2 SecBlade Configuration Creating a SecBlade Module To make the SecBlade card and the switch work together, you first need to create a SecBlade module to enter SecBlade module view. Perform the following configuration in system view of the switch. Table 2-2 Create the SecBlade module Create a SecBlade module Remove the SecBlade module secblade module sec-mod-name undo secblade module sec-mod-name By default, no SecBlade module is created Specifying the Layer 3 Interface Connecting the Switch and the SecBlade Card To make the SecBlade card and the switch communicate at Layer 3, you must specify the Layer 3 interface connecting the switch and the SecBlade card. Perform the following configuration in SecBlade module view of the switch. Table 2-3 Specify the Layer 3 interface connecting the switch and the SecBlade card Specify the Layer 3 interface connecting the switch and the SecBlade card Remove the configuration secblade-interface vlan-interface undo secblade-interface vlan-interface interface-number By default, the Layer 3 interface connecting the switch and the SecBlade card is not configured Specifying the VLANs Protected by the SecBlade Card To make the SecBlade card protect data streams of the specified VLANs, you need to specify the VLANs to be protected. Perform the following configuration in SecBlade module view of the switch. 2-2

16 Manual Overview Chapter 2 SecBlade Configuration Table 2-4 Specify the VLANs to be protected Specify the VLAN to be protected Cancel the VLAN protection security-vlan vlan-range undo security-vlan vlan-range By default, no VLAN is protected Mapping the SecBlade Module to the SecBlade Card After implementing the above configuration on the SecBlade module, you need to map this module to the SecBlade card to apply the configuration. Perform the following configuration in SecBlade module view of the switch. Table 2-5 Map the SecBlade module to the SecBlade card Map the SecBlade module to the SecBlade card Remove the configuration map to slot slot-number undo map to slot slot-number By default, the SecBlade module is not mapped to the SecBlade card Logging into the SecBlade Card You can directly log in to the SecBlade card through the switch for configuration and management. Perform the following configuration in user view of the switch. Table 2-6 Log in to the SecBlade card Log into the SecBlade secblade slot slot-number Configuring Default Login User Function For login convenience, a user whose name and password are both SecBlade is created in the SecBlade card. You can use this user name and password to log in to the SecBlade card. Perform the following configuration in system view of the SecBlade card. 2-3

17 Manual Overview Chapter 2 SecBlade Configuration Table 2-7 Configure default login user function Enable default login user function Disable default login user function default-login-user undo default-login-user By default, the default login user function is enabled. You are allowed to use the internally created user to log in to the SecBlade card. 2.2 Displaying Information about the SecBlade Module After the above configuration, you can execute the following command in any view to display information about the SecBlade module to verify the configuration. Table 2-8 Display information about the SecBlade module Display information about the SecBlade module display secblade module [sec-mod-name ] 2-4

18 VPN

19 Manual VPN Table of Contents Table of Contents Chapter 1 VPN Overview VPN Overview Features of VPN Benefits of VPN Structure of VPN Fundamental Technology of VPN Basic Network Design of VPN Mechanism of VPN Classification of VPNs Chapter 2 L2TP Configuration Introduction to L2TP VPDN Overview Introduction to L2TP LAC Configuration Enabling L2TP Creating an L2TP Group Setting Condition of Triggering L2TP Tunnel Setup Request and LNS Address Setting Tunnel Name Enabling Tunnel Authentication and Setting a Password Setting Transfer Mode of AVP Data Setting Hello Interval in Tunnel Setting Username, Password and Local User Authentication Terminating an L2TP Connection Enabling/Disabling Flow Control Function of Tunnel Setting the L2TP Session Idle-Timeout Timer Configuring the Tunnel-Hold Function of L2TP Configuring LAC as a Client LNS Configuration Enabling L2TP Enabling/Disabling the L2TP Multi-Domain Function Creating an L2TP Group Creating Virtual Template Interface Setting Parameters for Call Receiving Setting Local Name Setting Tunnel Authentication and Password Setting Transfer Mode of AVP Data Setting Hello Interval in Tunnel i

20 Manual VPN Table of Contents Enabling Required Local CHAP Authentication Forcing LCP to Re-negotiate Setting Local Address and Assigning Address Pool Setting Username, Password and User Authentication Terminating an L2TP Connection Enabling/Disabling Flow Control Function of Tunnel Setting the L2TP Session Timeout Timer Displaying and Debugging L2TP L2TP Configuration Example L2TP Troubleshooting Chapter 3 GRE Configuration Brief Introduction to GRE GRE Configuration Creating a Virtual Tunnel Interface Setting Encapsulation Mode Specifying Tunnel Source Specifying Tunnel Destination Assigning Network Address to Tunnel Interface Configuring End-to-End Verification on Both Ends of Tunnel Setting Identification Key of Tunnel Interface Configuring Routing Through Tunnel Configuring the Keepalive Function Displaying and Debugging GRE GRE Configuration Example GRE Troubleshooting Chapter 4 IPSec Configuration IPSec Overview IPSec Overview of Encryption Card Basic Concepts of IPSec IPSec on VRP IPSec Configuration Defining an ACL Defining an IPSec Proposal Creating an IPSec Policy Configuring IPSec Policy Template Applying IPSec Policy Group to Interface Disabling Next-Payload Field Check Configuring the Encryption Card (Optional) Displaying and Debugging IPSec Displaying and Debugging IPSec Module on VRP Displaying and Debugging Encryption Card Information ii

21 Manual VPN Table of Contents 4.4 IPSec Configuration Example IPSec Troubleshooting Chapter 5 IKE Configuration IKE Overview Brief Introduction to IKE Preparation for IKE Configuration IKE Configuration Introduction to IKE Configuration Setting a Name for the Local Security GW Defining IKE Proposal Configuring IKE Peer Configuring Keepalive Timer Displaying and Debugging IKE IKE Troubleshooting Chapter 6 PKI Configuration PKI Overview Introduction Terminology Applications Configuration Task List Certificate Request Configuration Certificate Request Overview Entering PKI Domain View Specifying a Trustworthy CA Configuring Servers for Certificate Request Configuring Entity Name Space Creating a Public and Private Key Pair Configuring Polling Interval and Count Configuring Certificate Request Mode Making a Certificate Request Manually Retrieving a Certificate Manually Importing Certificates Deleting Certificates Certificate Authentication Configuration Configuration Task List Specifying CRL Distribution Point location Configuring CRL Update Period Enabling/Disabling CRL Check Retrieving a CRL Verifying Certificate Validity Displaying and Debugging PKI Configuration Example iii

22 Manual VPN Table of Contents IKE Authentication Using PKI Certificate Troubleshooting Certificates Symptom 1: Failure to retrieve certificates Symptom 2: Failure to Apply for Local Certificates Symptom 3: Failure to Retrieve CRL Chapter 7 DVPN Introduction to DVPN Overview Basic DVPN Elements Implementation Basic Network Structure Traditional VPN Versus DVPN DVPN Configuration Basic DVPN Configuration Configuring the Tunnel Interface Configuring a DVPN class Configuring a DVPN policy Displaying and Debugging DVPN DVPN Configuration Example iv

23 Manual VPN Chapter 1 VPN Overview Chapter 1 VPN Overview 1.1 VPN Overview Along with the increasingly wide application of the Internet, virtual private network (VPN) has emerged to build private networks over public networks. Virtual indicates that a VPN is a kind of logical network Features of VPN Different from traditional networks, a VPN is a kind of logical network, a virtual network formed by employing the resources of the current public network. Each VPN is only dedicated to a particular enterprise or group of users. For VPN users, a VPN is just like any traditional private network. As a kind of private network, a VPN keeps resources independent of the underlying network, meaning that resources of each VPN are normally inaccessible to other VPNs over the underlying network and users outside this VPN. It also delivers adequate security, safeguarding the internal information of a VPN against external intrusion. VPN is a kind of upper layer service but not simple. It establishes network interconnection between private network users, including network topology inside a VPN, route calculation, joining and seceding of members. Thus, the VPN technology is much more complicated than various common point-to-point application mechanisms Benefits of VPN VPN allows you to: Establish reliable and secure connections between remote users, oversea agencies, partners, suppliers and company headquarters, ensuring security of data transmission. This advantage is of special significance to the integration of E-business or financial networks with communication networks. Provide information communication over public networks, thus allowing enterprises to connect with remote offices, staff traveling on business and business partners at a low cost, while improving utilization of network resources. This will help Internet service providers (ISPs) increase profits. Add or delete users through software configuration rather than changing hardware facilities, thus delivering great flexibility. Support mobile access of VPN users at any time in any place, thus meeting growing mobile service demands. 1-1

24 Manual VPN Chapter 1 VPN Overview Structure of VPN A VPN comprises a group of switches. A switch may join one or more VPNs, but any two switches are reachable to each other only if they belong to the same VPN at a time. According to its standard definition, a VPN with all its switches coming from a single enterprise is called an Intranet, and a cross-enterprise VPN is called an Extranet. Switch 2 VPN1 VPN3 Switch 5 Switch 4 VPN2 Switch 1 Switch 3 Figure 1-1 Composition of VPN The above figure shows the relationship between five switches and three VPNs. VPN1 Switch2, Switch4 VPN2 Switch1, Switch3, Switch4 VPN3 Switch1, Switch5 1.2 Fundamental Technology of VPN Basic Network Design of VPN Take an enterprise as an example. Its intranet through a VPN is shown in the following figure. 1-2

25 Manual VPN Chapter 1 VPN Overview Remote subscriber PSTN/ISDN Corporate headquarter POP POP Internet Internal server POP Cooperator Figure 1-2 Diagram for VPN application The figure above shows that users of enterprise internal resource can access a local ISP at its POP (Point of Presence) server through the PSTN/ISDN or LAN and access the internal resources of the company. With the traditional WAN networking technology, however, they need to be connected using dedicated lines to achieve the same purpose. A VPN allows remote subscribers and nonlocal clients to access enterprises internal resources without being authorized by their local ISPs, which is of great significance for staffs on business trip and geographically scattered clients. An enterprise can deploy VPN services simply by setting up a VPN-supporting server (a Windows NT server or a VPN-supporting router) for resource sharing. The resource sharers connect to a local POP server through the PSTN/ISDN or LAN before they directly call the remote server (VPN server) of the enterprise. The call process is completed by the ISP network access server (NAS) and VPN server together Mechanism of VPN VPN subscriber PSTN/ISDN NAS ISP GRE Tunnel Figure 1-3 Diagram for accessing VPN 1-3

26 Manual VPN Chapter 1 VPN Overview As shown in the above figure, a subscriber accesses the NAS of the ISP through the PSTN/ISDN. After the NAS recognizes that this is a VPN user by checking the user name or access number, it establishes a connection, which is called Tunnel, to the user s destination VPN server. Then the NAS encapsulates the user data into an IP packet and transmits it to the VPN server through this Tunnel. Upon receipt of this IP packet, the VPN server decapsulates the packet to get the original data. In the opposite direction, the packet is handled likewise. On both sides of the Tunnel, packets can be encrypted to make other users on the Internet unable to access them, so they are safe and reliable. For users, Tunnels are only the logical extension of their PSTN/ISDN links and thus can be operated like physical links. Tunnels are implemented using Tunneling protocols. Tunneling protocols are classified as Layer 2 Tunneling protocols and Layer 3 Tunneling protocols. I. Layer 2 Tunneling protocols Layer 2 Tunneling protocols encapsulate PPP frames entirely into internal Tunnels. The existing Layer 2 Tunneling protocols include: Point to point tunneling protocol (PPTP): Supported by companies like Microsoft, Ascend, and 3COM and in Windows NT 4.0 and its later versions. This protocol supports Tunneling encapsulation of PPP in IP networks. As a call control and management protocol, PPTP uses an enhanced generic routing encapsulation (GRE) technology to provide the encapsulation service (flow control and congestion control for transmitted PPP packets. Layer 2 forwarding (L2F): Supported by Nortel and some other companies. It supports Tunnel encapsulation for higher-level link layers and physically separates the dial-up server and dial-up connection. Layer 2 tunneling protocol (L2TP): Drafted by the IETF, and prepared by Microsoft and other companies. Absorbing the advantages of two protocols above, it is accepted by many companies and has become a standard RFC. L2TP provides both dial-up VPN service and leased line VPN service. II. Layer 3 Tunneling protocols Both the start point and end point of Layer 3 Tunneling protocols are in an ISP. PPP sessions terminate at an NAS. Only Layer 3 packets are carried in Tunnels. The existing Layer 3 Tunneling protocols include: Generic routing encapsulation (GRE), which is used to encapsulate a network layer protocol into another one. IP security (IPSec), which provides a complete architecture of data security on IP networks by using several protocols rather than a single one, such as authentication header (AH), encapsulating security payload (ESP), and Internet Key exchange (IKE). GRE and IPSec mainly apply in leased line VPN services. 1-4

27 Manual VPN Chapter 1 VPN Overview III. Contrast between Layer 2 Tunneling protocols and Layer 3 Tunneling protocols Compared with Layer 2 Tunneling protocols, the advantages of Layer 3 Tunneling protocols are their security, scalability and reliability. In terms of security, Layer 2 Tunnels imposes severe challenges to security of user networks and firewall technologies while Layer 3 Tunnels do not, because Layer 2 Tunnels generally terminate at customer premise equipment and Layer 3 Tunnels at an ISP gateway. As for scalability, a Layer 2 Tunnel is not as efficient as a Layer 3 Tunnel in transmission due to the encapsulation of entire PPP frames. Besides, its PPP session runs through the entire Tunnel and terminates at customer premise equipment, and thus requires the user-side gateway to store a large amount of PPP session status and information, which may not only overload the system but also decrease the scalability. The introduction of Tunneling latency may cause such problems as PPP session timeout in time-sensitive LCP and NCP negotiations of PPP. On the contrary, a Layer 3 Tunnel terminates within the ISP gateway, and a PPP session terminates at an NAS; thus the user gateway need not manage and maintain status of each PPP session, thereby reducing system load. Normally, Layer 2 Tunneling protocols and Layer 3 Tunneling protocols are used separately from each other. The reasonable combination of the two types of protocols, however, may bring about better security and performance (using L2TP and IPSec together). 1.3 Classification of VPNs IP VPN means emulating private line services of WAN (remote dial-up, and DDN) over IP networks (including the Internet or dedicated IP backbone networks). IP VPNs are classified as follows: I. Classified by operation mode 1) Customer premises equipment based VPN (CPE-based VPN) Users not only have to install expensive devices and special authentication tools, but also maintain complex VPNs (tunnel maintenance and bandwidth management). Networking in this way features high complexity and low service scalability. 2) Network-based VPN (NBIP-VPN) The maintenance of VPNs (permitting users to conduct service management and control to some extent) is conducted by ISPs, and all functions are implemented at network-side devices, so as to reduce users investment, enhance flexibility and scalability of services, and bring new incomes to ISPs. II. Classified by service application 1) Intranet VPN 1-5

28 Manual VPN Chapter 1 VPN Overview An Intranet VPN interconnects points distributed inside an enterprise through a public network. It is an extended or substitute form of traditional private networks or other enterprise networks. 2) Access VPN An access VPN allows staff on business trip and remote small offices to establish private network connections with the intranet and extranet of their enterprise over a public network. Access VPNs provide two types of connections: client-initiated VPN connection and NAS-initiated VPN connection. 3) Extranet VPN An extranet VPN extends an enterprise network to suppliers, cooperators and clients by using a VPN, allowing different enterprises to build a VPN over public networks. III. Classified by networking model 1) VLL Virtual leased line (VLL) is an emulation to traditional leased line services. By emulating a leased line over IP networks, it provides asymmetric and low-cost DDN service. From the point of view of end users of a VLL, it is similar to traditional leased lines. 2) VPDN Virtual private dial network (VPDN) means implementing a VPN by employing the dial-up function of public networks (ISDN and PSTN) and access networks, to provide access service for enterprises, small ISPs, and mobile office clerks. 3) VPLS service Virtual private LAN segment (VPLS) interconnects LANs through VPN segments using IP public networks. It is an extension of LANs on IP public networks. 4) VPRN Virtual private routing network (VPRN) interconnects headquarters, branches and remote offices through a network management virtual router using IP public networks. There are two kinds of VPRN services: VPRN implemented using traditional VPN protocols (IPSec, and GRE) and VPRN by means of MPLS. IV. Classified by implementation level 1) L3VPN: including BGP/MPLS VPN, IPSec VPN, and GRE VPN. 2) L2VPN: including MPLS L2VPN in Martini mode, MPLS L2VPN in Kompalla mode, MPLS L2VPN in SVC mode, VPLS and static CCC configuration. 3) VPDN: including L2TP and PPTP. 1-6

29 Manual VPN Chapter 2 L2TP Configuration Chapter 2 L2TP Configuration 2.1 Introduction to L2TP VPDN Overview Virtual private dial network (VPDN) means implementing a VPN by employing the dial-up function of public networks (ISDN and PSDN) and access networks, thus providing access service for enterprises, small ISPs and mobile office clerks. VPDN sets up secure VPNs in public networks for enterprises using special network encryption protocols. In this way, overseas agencies and traveling staff of an enterprise can access the headquarters' network using encrypted virtual Tunnels over public networks, while other users in public networks have no access to internal resources of the enterprise network through virtual Tunnels. There are two VPDN implementation approaches: 1) An NAS sets up a channel with a VPDN gateway through a Tunneling protocol. In this way, users PPP is directly connected to an enterprise s gateway. Protocols available now are L2F and L2TP. This approach has great advantages: transparent Tunnel setup process from the perspective of users, network access with one login, user authentication and address assignment by enterprise network without occupying public addresses, and supports a wide range of platforms for network access. It requires however: a) NAS supporting the VPDN protocol, and b) authentication system supporting VPDN attributes, and c) router or special VPN server serving as a gateway. 2) A client sets up a Tunnel with a VPDN gateway. In this way, the client first sets up a connection with the Internet, and then sets up a Tunnel with the gateway using special client software (L2TP client supported by Win2000). This approach allows users to access networks by whatever means available anywhere without the intervention of an ISP. The disadvantage is the limitation in the platform, meaning users need to install special software (usually Win2000 platform). There are three types of VPDN Tunneling protocols: PPTP, L2F, and L2TP, with L2TP being most popular Introduction to L2TP I. Background PPP defines a kind of encapsulation technology that allows transmission of various kinds of data packets on Layer 2 point-to-point links. Meanwhile, PPP is performed 2-1

30 Manual VPN Chapter 2 L2TP Configuration between users and an NAS, with endpoints of Layer 2 links and PPP session residing on the same hardware. L2TP provides Tunnel transmission for PPP link layer packets. It extends the PPP model because it allows the link endpoint of Layer 2 and PPP session point to stay at different devices and allows information exchange by using packet switching network technologies. It combines the advantages of PPTP and L2F. Therefore, it becomes the industrial standard of the IETF in Layer 2 Tunneling. II. Typical L2TP network design Figure 2-1 shows a typical network where a VPDN is built using L2TP: Remote users PC PSTN/ISDN LAC Internet backbone network L2TP tunnel LNS NAS Remote users Internal server Figure 2-1 Network diagram for typical VPDN application created by L2TP In this figure, the L2TP access concentrator (LAC) is a switching network device with the capability to process PPP and L2TP requests. Usually, the LAC functions as an NAS to provide access service for users through the PSTN/ISDN. The L2TP network server (LNS) is a device functioning in the PPP system as an L2TP server. The LAC lies between the LNS and a remote system (remote users and remote branches) to transmit packets between them, encapsulate packets from a remote system in compliance with L2TP and send the encapsulated packets to the LNS, and decapsulate packets from the LNS and send the packets to a remote system. A local connection or PPP link can be adopted between the LAC and remote system, but a PPP link is always involved in VPDN applications. As one end of the L2TP Tunnel, the LNS is the peer device of the LAC, and also is the logic terminating point of PPP session transmitted in Tunnel by the LAC. 2-2

31 Manual VPN Chapter 2 L2TP Configuration III. Technology details of L2TP 1) Architecture of L2TP PPP frame L2TP data message L2TP data channel L2TP control message L2TP control channel Packet transmission network Figure 2-2 Architecture of L2TP The architecture of L2TP shown above describes the relationship between the PPP frame, control Tunnel and data Tunnel. The PPP frame is transmitted in an unreliable L2TP data channel. The control message is transmitted in a reliable L2TP control channel. Usually L2TP data is carried in UDP packets for transmission. L2TP registers the UDP 1701 port, but this port is only used for the Tunnel setup at the initial stage. The L2TP Tunnel initiator selects any port from available ones (unnecessarily being 1701) and forwards packets to the 1701 port of the receiver. After receiving the packets, the receiver also selects any idle port (unnecessarily being 1701) and forwards packets again to the specified port of the initiator. Thus, ports of the two sides are determined. They will remain unchanged until the Tunnel connection is terminated. 2) Definitions of Tunnel and session There are two kinds of connections between an LNS and an LAC: Tunnel connection and Session connection. A Tunnel connection defines an LNS-LAC pair, and a Session connection is multiplexed over a Tunnel connection to present PPP sessions in it. Several L2TP Tunnels can be created between an LNS and an LAC. An L2TP tunnel consist of one control connection, and one or several Sessions. Session connections can be set up only after Tunnels are created successfully (including such information exchange as ID protection, L2TP version, frame type, and hardware transmission type). Each session connection corresponds to a PPP data stream between an LAC and LNS. Both control messages and PPP data packets are transmitted in the Tunnels. L2TP uses Hello packets to check the connectivity of a Tunnel. The LAC and LNS send Hello packets to each other at regular intervals. If no response to the Hello packet is received in a certain period, the session will be terminated. 3) Definitions of control message and data message There are two kinds of messages in L2TP: control messages and data messages. Control messages are used for the setup, maintenance and transmission control of Tunnel and session connections, and data messages are for PPP frame encapsulation and transmission in Tunnels. The transmission of control messages is 2-3

32 Manual VPN Chapter 2 L2TP Configuration reliable, delivering flow and congestion control. On the contrary, the transmission of data messages is unreliable, meaning it lacks mechanisms of retransmission, flow control, and congestion control. Control messages and data messages share the same type of packet headers. A Tunnel ID and Session ID are included in L2TP packet header, to identify different Tunnels and sessions. The packets with the same Tunnel ID but different Session IDs will be multiplexed in the same Tunnel. The Tunnel ID and Session ID in the packet header are assigned by peers. IV. Two typical L2TP Tunnel modes The following figure shows the Tunnel modes available between a remote system or LAC clients (hosts running L2TP) and an LNS: LAC client LAC PSDN/ISDN LAC Remote system Internet Frame relay or ATM LNS LNS Inner server Inner server Figure 2-3 Two typical L2TP Tunnel modes 1) Initiated by remote dial-up user. A remote system dials in the LAC through the PSTN/ISDN. The LAC sends a Tunnel setup request to the LNS through the Internet. Dial-up users addresses are assigned by the LNS. The authentication and accounting of remote dial-up users can be accomplished either by an agent at the LAC side or at the LNS side directly. 2) Initiated directly by LAC users (local users who support L2TP). Once assigned a public network address, an LAC user can send a Tunnel setup request directly to the LNS, without requiring an additional LAC device. In this case, the private network address of an LAC user is assigned by the LNS. V. Session setup flow of L2TP Tunnel A typical L2TP application network is as follows: 2-4

33 Manual VPN Chapter 2 L2TP Configuration RADIUS server RADIUS server IP network IP network PSTN/ISDN WAN Host B Host A Switch A LAC Switch B LNS Host C Figure 2-4 Network diagram for L2TP application Call setup flow of L2TP Tunnel is shown in the following figure: Client LAC Switch A LAC RADIUS server LNS Switch B LNS RADIUS server (1) Call setup (2) PPP LCP setup (3) PPP or CHAP authenticaion (4) Access request (5) Access accept (6) Tunnel establishment (7) PPP or CHAP authentication (challenge/response) (8) Authentication passes (9) User CHAP response, PPP negotiation parameter (12) CHAP authentication twice (challenge/response) (10) Access request (11) Acesss accept (13) Access request (14) Acesss accept (15) Authentication passes Figure 2-5 Call setup flow of L2TP channel The following is the call setup process using an L2TP Tunnel: 1) The Client at user side initiates a setup request; 2) The Client and LAC negotiate PPP LCP parameters; 2-5

34 Manual VPN Chapter 2 L2TP Configuration 3) The LAC performs PAP or CHAP authentication against the information provided by the Client; 4) The LAC sends an access request containing the VPN user's name and password to the RADIUS server for authentication; 5) The RADIUS server authenticates this user and returns related information such as LNS address, after authentication is passed successfully; the LAC is ready for initiating a new Tunnel request; 6) The LAC initiates a Tunnel request to the LNS specified by the RADIUS server; 7) The LAC informs the specified LNS of CHAP challenge information, the LNS sends back CHAP response and its own CHAP challenge, and the LAC sends back CHAP response; 8) Authentication is passed successfully; 9) The LAC transmits the information of CHAP response, response identifier and PPP negotiation parameters to the LNS; 10) The LNS sends the access request to the RADIUS server for authentication; 11) The RADIUS server authenticates this access request and sends back a response if authentication is successful; 12) If local required CHAP authentication is configured at the LNS, the LNS will authenticate the VPN user by sending CHAP challenge and the VPN user at the PC sends back a CHAP response; 13) The LNS resends this access request to RADIUS for authentication; 14) The RADIUS server re-authenticates this access request and sends back a response if authentication is successful; 15) The authentication is passed and the VPN user can access the internal resources of the enterprise. VI. L2TP features Flexible ID authentication mechanism and high security L2TP relies on authentication (CHAP and PAP authentication) provided by PPP because it does not ensure security of connections itself. Therefore, L2TP has all the security characteristics of PPP. Together with IPSec, L2TP can ensure data security, thereby protecting the data transmitted through L2TP from attacks. Furthermore, L2TP can satisfy specific requirements for network security through various technologies: tunnel encryption, end-to-end data encryption, and encryption of application layer data. Multi-protocol transmission L2TP transmits PPP packets, so multiple protocols can be encapsulated in a PPP packet. Support authentication of RADIUS server 2-6

35 Manual VPN Chapter 2 L2TP Configuration The LAC sends a username and password to the RADIUS server for authentication. The RADIUS server receives authentication requests from users and implements ID authentication. Support internal address allocation The LNS can be placed behind the firewall of an enterprise network. It can dynamically allocate and manage addresses for remote users, and supports private address applications (RFC1918). The addresses allocated to remote users are internal private addresses of enterprises rather than Internet addresses, thus facilitating address management and enhancing security. Flexible network accounting Accounting can be implemented on an LAC and LNS at the same time, that is, an ISP (for generating bills) and enterprise gateway (for payment and auditing). L2TP can provide various accounting data like the number of outgoing/incoming packets, number of bytes, and start/end connection time. Reliability L2TP supports LNS backup. If an active LNS is not reachable, an LAC can set up a connection with the backup LNS, thereby enhancing reliability and fault tolerance of VPN services. The section below describes the configuration of L2TP at the LAC side and LNS side. 2.2 LAC Configuration Concerning L2TP configuration, configuration of LAC side differs from that of LNS side. This section covers the configuration of LAC side. In the configuration task list, L2TP must be enabled and an L2TP group must be created before any other function can be configured. For details on PPP configuration commands, refer to the related chapters and sections. Configuration tasks at LAC side include: Enable L2TP (required) Create an L2TP group (required) Set the condition of triggering L2TP Tunnel setup request and LNS addresses (required) Set local name (optional) Enable Tunnel authentication and set a password (optional) Set the transfer mode of AVP data (optional) Set Hello interval in the Tunnel (optional) Set user name and password and configure user authentication (required) Terminate a Tunnel by force (optional) Enable/disable the flow control function (optional) Set L2TP session idle-timeout timer (optional) Configure the Tunnel-hold function of L2TP (optional) Configure the LAC as a client (optional) 2-7

36 Manual VPN Chapter 2 L2TP Configuration Enabling L2TP Only after L2TP is enabled, can the L2TP functions on the SecBlade work normally. If L2TP is disabled, the SecBlade cannot provide related functions even if parameters of L2TP have been configured. These configurations are required at LAC side. Perform the following configuration in system view. Table 2-1 Enable/disable L2TP Enable L2TP Disable L2TP l2tp enable undo l2tp enable By default, L2TP is disabled. Note: If a tunnel is set up successfully or no tunnel is set up because of authentication failure, disable L2TP first and then enable L2TP on the LAC. If no tunnel can be set up: Execute the undo l2tp-auto-client enable command and then the l2tp-auto-client enable command in virtual template interface of the LAC when the LAC serves as a client. Re-connect the remote user when the LAC does not serve as a client (that is, the remote user accesses the LAC through dialup) Creating an L2TP Group An L2TP group needs to be created in order to configure related parameters of L2TP. It allows you not only to configure L2TP functions as needed but also to implement one-to-one and one-to-many networking applications between LACs and LNSs. L2TP groups are numbered separately on LACs and LNSs, so LACs and LNSs only need to keep consistent in the configurations of the involved L2TP groups (peer name of Tunnel, start L2TP and LNS address). These configurations are required at LAC side. Perform the following configuration in system view. 2-8

37 Manual VPN Chapter 2 L2TP Configuration Table 2-2 Create/delete L2TP group Create an L2TP group Delete an L2TP group l2tp-group group-number undo l2tp-group group-number After an L2TP group is created, other configurations related to the L2TP group can be performed in L2TP group view, for example, name of local device, condition of triggering L2TP Tunnel setup request and LNS address. By default, no L2TP group is created Setting Condition of Triggering L2TP Tunnel Setup Request and LNS Address A SecBlade will not send an L2TP Tunnel setup request to some other devices like other SecBlades, routers and LNSs unless certain conditions are met. By configuring on the criteria for user information and specifying the IP address of an LNS, the SecBlade can determine whether a user is a VPN user and whether to initiate a connection with the LNS. Up to five LNSs can be configured, meaning LNS backup is allowed. During normal operation, the local SecBlade (LAC) sends a Tunnel setup request to the peer LNSs in the same order as they are configured until an LNS accepts the request. This LNS becomes the peer end of L2TP Tunnel. An L2TP Tunnel setup request can be triggered by a full user name and domain name. Perform the following configuration in L2TP group view. Table 2-3 Set condition of triggering L2TP Tunnel setup request and LNS address Configure to check whether the user is VPN user and set the IP address of an LNS Cancel the Tunnel setup request configuration start l2tp { ip ip-addr [ ip ip-addr] [ ip ip-addr]... } { domain domain-name fullusername user-name } undo start The parameters above have no default values and they can be configured as needed. However, at least one triggering condition must be configured for initiating an L2TP Tunnel setup request. When the L2TP LAC initiates an L2TP Tunnel connection, the system checks whether the L2TP group specified by the complete user name exists. If the system does not find the required L2TP group, the system continues to search for the required L2TP group according to the domain name. 2-9

38 Manual VPN Chapter 2 L2TP Configuration Note: When multiple LNSs are configured, subsequent IP addresses (backup LNSs) may not be connected because the timeout time of PPP varies with the client. Therefore, you are recommended to configure a maximum of two LNSs. The SecBlade can serve as both LAC and LNS simultaneously. In this case, you must use different usernames for the SecBlade. Otherwise, L2TP may function abnormally Setting Tunnel Name You can configure a local Tunnel name at LAC side. The Tunnel name at LAC side must keep in line with the peer name of Tunnel configured at LNS side. These configurations are optional at LAC side. Perform the following configuration in L2TP group view. Table 2-4 Set local Tunnel name Set a local Tunnel name Restore the default local Tunnel name Tunnel name name undo Tunnel name By default, the local Tunnel name is the hostname of the SecBlade. Note: An LNS selects a local L2TP group according to the tunnel name of an LAC. If tunnel names are the same as one another, the LNS will set up a tunnel using the first eligible group. To set up multiple tunnels, you must configure different tunnel names Enabling Tunnel Authentication and Setting a Password As needed, a user can decide whether to enable Tunnel authentication before creating a Tunnel connection. A Tunnel authentication request can be sent by either the LAC side or LNS side. If one end of a Tunnel enables Tunnel authentication, the other end must also enable Tunnel authentication in order to set up a Tunnel connection. In addition, both ends must use the same password, which cannot be void. Otherwise, the local end will terminate the Tunnel automatically. If Tunnel 2-10

39 Manual VPN Chapter 2 L2TP Configuration authentication is disabled on both ends, it does not matter whether both ends use the same password. These configurations are optional at LAC side. Perform the following configuration in L2TP group view. Table 2-5 Set Tunnel authentication and authentication password Enable Tunnel authentication Disable Tunnel authentication Set the password of Tunnel authentication Restore the password of Tunnel authentication to the default Tunnel authentication undo Tunnel authentication Tunnel password { simple cipher } password undo Tunnel password By default, Tunnel authentication is enabled, with the password of Tunnel authentication being null. For the sake of Tunnel security, it is not suggested to disable Tunnel authentication Setting Transfer Mode of AVP Data An attribute value pair (AVP) is adopted in L2TP to transfer and negotiate some attribute parameters of L2TP. By default, an AVP is transferred in plain text. For the purpose of security, users can hide AVP data in transmission by using the following configuration. The function of hiding AVP data only works when both of the two ends use Tunnel authentication. These configurations are optional at LAC side. Perform the following configuration in L2TP group view. Table 2-6 Set transfer mode of AVP data Configure to transfer AVP data in the hidden mode Restore the default transfer mode of AVP data Tunnel avp-hidden undo Tunnel avp-hidden By default, AVP data is transferred in plain text Setting Hello Interval in Tunnel In order to check the connectivity of the Tunnel between an LAC and an LNS, they send Hello packets to each other periodically and the receiver will respond upon receipt of the packets. If the LAC or the LNS does not receive response from the peer 2-11

40 Manual VPN Chapter 2 L2TP Configuration end within a specified interval, it will resend a Hello packet and will regard the L2TP Tunnel connection has failed if receiving no response after making three transmission attempts. In this case, the LAC and the LNS need to set up a new Tunnel connection. This configuration is optional at LAC side. Perform the following configuration in L2TP group view. Table 2-7 Set Hello interval in a Tunnel Set Hello interval in a Tunnel Restore the default Hello interval Tunnel timer hello hello-interval undo Tunnel timer hello By default, the Hello interval is 60 seconds. If this configuration is not performed at LAC side, the LAC will send a Hello packet to the peer end at an interval of this default value Setting Username, Password and Local User Authentication If you have configured local authentication when configuring AAA authentication at LAC side, you also need to configure a local username and password at this side. The LAC performs user authentication to determine whether a user is a valid VPN user by comparing the remote dial-in username and password with the usernames and passwords registered at the local end. It originates a Tunnel setup request only upon successful authentication. Otherwise, the user will be diverted to other kinds of services. These configurations are required at LAC side. I. Configuring user name and password Table 2-8 Configure a username and password Configure a user name and password (in system view) Delete the current setting (in system view) Configure local user password (in local user view) local-user username undo local-user username password { simple cipher } password By default, no local username and password are configured at the LAC side. II. Configuring PPP user authentication Perform the following configuration in virtual template interface view. 2-12

41 Manual VPN Chapter 2 L2TP Configuration Table 2-9 Enable/Disable PPP user authentication mode Enable PPP user authentication Disable PPP user authentication ppp authentication-mode { chap pap } [ call-in ] [ domain isp-name ] undo ppp authentication-mode User authentication is not configured by default. The interface where you configure local authentication must be an interface connected to users. III. Configuring a PPP domain user and an authentication scheme Table 2-10 Configure a PPP domain user and an authentication scheme Create an ISP domain and enter its view (in system view) Delete the specified ISP domain (in system view Configure a local authentication scheme for the PPP domain user. (in ISP domain view) domain { isp-name default { disable enable isp-name } } undo domain isp-name scheme local Terminating an L2TP Connection A connection can be terminated for one of these reasons: no user is present, a fault occurs on the network, or the administrator requests to do so. Both the LAC side and LNS side can request to terminate the Tunnel. After a Tunnel is terminated, the control connections and sessions on it are cleared. This Tunnel can be set up when a new user dials in. These configurations are optional at LAC side. Perform the following configurations in user view. Table 2-11 Terminate a connection Terminate a Tunnel reset l2tp Tunnel {name remote-name id Tunnel-id } Terminate a session Disconnect a user reset l2tp session session-id reset l2tp user user-name user-name 2-13

42 Manual VPN Chapter 2 L2TP Configuration Enabling/Disabling Flow Control Function of Tunnel This configuration can enable/disable the flow control function on a Tunnel. These configurations are optional at LAC side. Perform the following configuration in L2TP group view. Table 2-12 Set flow control function of a Tunnel Enable flow control function of a Tunnel Disable flow control function of a Tunnel Tunnel flow-control undo Tunnel flow-control By default, the flow control function of Tunnels is disabled Setting the L2TP Session Idle-Timeout Timer An L2TP session is terminated automatically if the session is idle or no data is transmitted or received on it for a specified period. You may set a session idle-timeout timer to specify this idle period. You can even configure L2TP sessions to never time out, that is, the L2TP sessions will not be terminated automatically. Perform the following configuration in L2TP group view. Table 2-13 Set the L2TP session idle-timeout timer Set the L2TP session idle-timeout timer Disable the L2TP session idle-timeout timer session idle-time time undo session idle-time By default, an L2TP session never expires Configuring the Tunnel-Hold Function of L2TP Normally, the LAC sets up a Tunnel with the LNS only when receiving an L2TP session request from a PPP user. This Tunnel is automatically removed after all PPP sessions are terminated. For some applications that require fast connection setup, however, a Tunnel must be available beforehand so that the system can set up a session immediately after receiving a PPP session request. To this end, the LAC and the LNS must always maintain a Tunnel connection even when no session is present on it. Perform the following configuration in L2TP group view. 2-14

43 Manual VPN Chapter 2 L2TP Configuration Table 2-14 Configure the Tunnel-hold function of L2TP Enable the Tunnel-hold function of L2TP Disable the Tunnel-hold function of L2TP Tunnel keepstanding undo Tunnel keepstanding By default, the Tunnel-hold function of L2TP is disabled. Note: To have the Tunnel-hold function take effect, you must configure it on both an LAC and an LNS. After you configure the Tunnel-hold function of L2TP, you can execute the start l2tp Tunnel command to send a Tunnel setup request. Perform the following configuration in L2TP group view. Table 2-15 Start an L2TP Tunnel connection Start an L2TP Tunnel connection start l2tp Tunnel Configuring LAC as a Client Normally, an L2TP client is a host that gains access to the LAC through dialup. Then, the connection between the user and the LAC is always a PPP connection. If the LAC is functioning as a client, the connection between the host and the LAC can be an IP connection, thereby allowing the LAC to forward the IP packets from the host to the LNS. This is equivalent to creating a virtual PPP user associated with multiple actual users on the LAC and maintaining a permanent connection for it. The IP packets of all these actual users are forwarded to the LNS through this virtual user. To use the LAC as a client, you must add the following configurations in addition to other LAC configurations: Create a virtual template interface Configure the parameters of the virtual template interface, including IP address, PPP authentication mode, and username and password for PPP authentication Enable the virtual LAC client to set up an L2TP Tunnel 2-15

44 Manual VPN Chapter 2 L2TP Configuration Note: When the LAC is functioning as an L2TP client, you must configure L2TP sessions to never time out. Otherwise, the session of the virtual user will be terminated when no data is transmitted or received. I. Creating a virtual template interface Perform the following configuration in system view. Table 2-16 Create/delete a virtual template interface Create a virtual template interface Delete a virtual template interface interface virtual-template virtual-template-number undo interface virtual-template virtual-template-number II. Configuring the parameters of the virtual template interface Perform the following configuration in virtual template interface view. Table 2-17 Configure the parameters of the virtual template interface Assign an IP address to the virtual template interface Configure a PPP authentication mode Configure a username for CHAP authentication Configure a password for CHAP authentication Configure a username and password for PAP authentication ip address { address mask ppp-negotiate unnumbered interface interface-type interface-number } ppp authentication-mode { pap chap } ppp chap user user-name ppp chap password { simple cipher } password ppp pap local-user user-name password { simple cipher } password III. Configuring an L2TP Tunnel for the LAC client Perform the following configuration in virtual template interface view. 2-16

45 Manual VPN Chapter 2 L2TP Configuration Table 2-18 Configure an L2TP Tunnel for the LAC client Enable the LAC client to set up L2TP Tunnel Disable the LAC client from setting up L2TP Tunnel l2tp-auto-client enable undo l2tp-auto-client enable By default, the LAC client is disabled from setting up an L2TP Tunnel. 2.3 LNS Configuration In the LNS configuration task list, L2TP must be enabled and an L2TP group must be created before any other functions can be configured. When L2TP supports multi-domain configurations, no configurations can become valid unless the L2TP multi-domain function is enabled. For detailed introduction to related commands of PPP and Virtual-Template interfaces, refer to corresponding chapters and sections. The major configuration tasks at LNS side include: Enable L2TP (required) Enable/disable the L2TP multi-domain function (optional) Create an L2TP group (required) Create a virtual template interface (required) Set the parameters for call receiving (required) Set a local name (optional) Set Tunnel authentication and password (optional) Set the transfer mode of AVP data (optional) Set Hello interval in the Tunnel (optional) Configure required local CHAP authentication (optional) Configure required LCP renegotiation (optional) Set local address and assigned address pool (optional) Set a user name and password and configure user authentication (optional) Terminate a Tunnel by force(optional) Enable/Disable the flow control function of Tunnel (optional) Set the L2TP session timeout timer (optional) Enabling L2TP Only after L2TP is enabled, can the L2TP functions on the SecBlade work normally. If L2TP is disabled, the SecBlade cannot provide related functions even if parameters of L2TP have been configured. These configurations are required at LNS side. Perform the following configuration in system view. 2-17

46 Manual VPN Chapter 2 L2TP Configuration Table 2-19 Enable/disable L2TP Enable L2TP Disable L2TP l2tp enable undo l2tp enable By default, L2TP is disabled Enabling/Disabling the L2TP Multi-Domain Function A SecBlade can function as an LNS for multiple enterprises only when the L2TP multi-domain function is enabled. The L2TP multi-domain function can be implemented to diversify VPN networking modes. In L2TP multi-domain applications, these configurations are required at LNS side. Perform the following configuration in system view. Table 2-20 Enable/disable the L2TP multi-domain function Enable the L2TP multi-domain function Disable the L2TP multi-domain function l2tpmoreexam enable undo l2tpmoreexam enable By default, the L2TP multi-domain function is disabled Creating an L2TP Group An L2TP group needs to be created in order to configure related parameter of L2TP. It allows you not only to configure L2TP functions on the SecBlade as needed but also to implement one-to-one and one-to-many networking applications between LACs and LNSs easily. L2TP groups are numbered separately on LACs and LNSs, so LACs and LNSs only need to keep consistent in the configurations of the involved L2TP groups such as the remote name of Tunnel, start L2TP and LNS address. These configurations are required at LNS side. Perform the following configuration in system view. Table 2-21 Create/delete L2TP group Create L2TP group Delete L2TP group l2tp-group group-number undo l2tp-group group-number 2-18

47 Manual VPN Chapter 2 L2TP Configuration After an L2TP group is created, other configurations related to the L2TP group can be performed in L2TP group view, for example, the local name and remote name of Tunnel. By default, no L2TP group is created Creating Virtual Template Interface A virtual template interface is used to configure parameters of virtual interface created dynamically by the SecBlade during operation, e.g. MP logical interface and L2TP logical interface. These configurations are required at LNS side. Perform the following configuration in system view. Table 2-22 Create/delete virtual template interface Create a virtual template interface Delete the virtual template interface interface virtual-template virtual-template-number undo interface virtual-template virtual-template-number By default, no virtual template interface is created. Note: If the virtual template interface is configured with address borrowing and if the borrowed interface is occupied by a service, L2TP on this interface will function abnormally Setting Parameters for Call Receiving An LNS can adopt different virtual template interfaces for receiving Tunnel setup request from different LACs. When receiving a Tunnel setup request from an LAC, the LNS needs to check whether the name of the LAC is a valid remote name of Tunnel before allowing it to create the Tunnel. These configurations are required at LNS side. Perform the following configuration in L2TP group view. 2-19

48 Manual VPN Chapter 2 L2TP Configuration Table 2-23 Set parameters for call receiving Set a name for the remote end of Tunnel (L2TP group not being 1) Set a name for the remote end of Tunnel (L2TP group being 1) Remove the name of the remote end of Tunnel allow l2tp virtual-template virtual-template-number remote remote-name [ domain domain-name ] allow l2tp virtual-template virtual-template-number [ remote remote-name ] [ domain domain-name ] undo allow When the L2TP group is numbered 1 (the default L2TP group number), you do not need to specify remote-name. If remote-name is specified in L2TP group view 1, L2TP group 1 will not be regarded as the default L2TP group. Note: Only L2TP group 1 can be set to the default group. Any device can initiate a Tunnel setup request when the L2TP group number is 1, the default L2TP group number. The start command and the allow command are exclusive to each other. After one is configured, the other one goes invalid automatically. When the PPPoE client is used to trigger the Tunnel connection from an LAC to an LNS, you are recommended to decrease the MTU value of the virtual template interface on the side of LNS to 1,480 bytes. The SecBlade can function as both LAC and LNS simultaneously. In this case, you must assign different usernames to the SecBlade. Otherwise, L2TP may function abnormally Setting Local Name A user can configure a local Tunnel name at LNS side. These configurations are optional at LNS side. Perform the following configuration in L2TP group view. 2-20

49 Manual VPN Chapter 2 L2TP Configuration Table 2-24 Set local name Set a local name Restore the default local name Tunnel name name undo Tunnel name By default, the local name is the hostname of the SecBlade Setting Tunnel Authentication and Password As needed, a user can decide whether to enable Tunnel authentication before creating a Tunnel connection. Tunnel authentication requests can be sent by either the LAC side or LNS side. If one end of a Tunnel enables Tunnel authentication, the other end must also enable Tunnel authentication in order to set up the Tunnel connection. In addition, both ends must use the same password, which cannot be void. Otherwise, the local end will terminate the Tunnel automatically. If Tunnel authentication is disabled on both ends, it does not matter whether both ends use the same password. These configurations are optional at LNS side. Perform the following configuration in L2TP group view. Table 2-25 Set Tunnel authentication and authentication password Enable Tunnel authentication Disable Tunnel authentication Set a password for Tunnel authentication Remove the password for Tunnel authentication Tunnel authentication undo Tunnel authentication Tunnel password { simple cipher } password undo Tunnel password By default, Tunnel authentication is enabled, with the password being null. For the sake of Tunnel security, you are not recommended to disable Tunnel authentication Setting Transfer Mode of AVP Data An AVP is adopted in L2TP to transfer and negotiated some attribute parameters of L2TP. By default, AVP data is transferred in plain text. For the purpose of security, users can hide these AVPs in transmission by using the following configuration. The function of hiding AVP data only works when both of the two ends use Tunnel authentication. These configurations are optional at LNS side. 2-21

50 Manual VPN Chapter 2 L2TP Configuration Perform the following configuration in L2TP group view. Table 2-26 Set the transfer mode of AVP data Configure to transfer AVP data in the hidden mode Restore default transfer mode of AVP data Tunnel avp-hidden undo Tunnel avp-hidden By default, AVP data is transferred in plain text Setting Hello Interval in Tunnel In order to check the connectivity of the Tunnel between an LAC and an LNS, they send Hello packets to each other periodically and the receiver will respond upon receipt of the packets. If the LAC or the LNS does not receive response from the peer end in a specified interval, it will resend a Hello packet and will regard the L2TP Tunnel connection has failed if receiving no response after making three transmission attempts. In this case, the LAC and the LNS need to set up a new Tunnel connection. This configuration is optional at LNS side. Perform the following configuration in L2TP group view. Table 2-27 Set Hello interval Set Hello interval Restore the default value of Hello interval Tunnel timer hello hello-interval undo Tunnel timer hello By default, the Hello interval is 60 seconds. If this configuration is not performed at LNS side, the LAC will send a Hello packet to the peer end at intervals of this default value Enabling Required Local CHAP Authentication After an LAC performs agent authentication on a user, an LNS can authenticate the user again. The user therefore undergoes authentication twice: once at LAC side and once at LNS side. Only after both the two authentications succeed, can an L2TP Tunnel be created. In an L2TP network, the LNS side authenticates users in three ways: agent authentication, required CHAP authentication, and LCP re-negotiation. Among these three authentication approaches, LCP re-negotiation is of the first priority. If both LCP re-negotiation and required CHAP authentication are configured 2-22

51 Manual VPN Chapter 2 L2TP Configuration at LNS side, L2TP will choose the former, adopting the authentication mode configured in the associated virtual template interface. If only CHAP authentication is configured, the LNS will perform CHAP authentication on users. To perform required CHAP authentication at LNS side, you must configure username, password and user authentication and enable AAA on this side. Required local CHAP authentication is optional at LNS side. Perform the following configuration in L2TP group view. Table 2-28 Enable required local CHAP authentication Enable required local CHAP authentication Disable local CHAP authentication mandatory-chap undo mandatory-chap If neither LCP re-negotiation nor required CHAP authentication is configured, the LNS will perform agent authentication on the user. In this case, the LAC sends the LNS all authentication information received from the user as well as authentication mode configured at LAC side. If you do not configured authentication mode for the virtual template interface, the LNS side will accept the authentication result at LAC side. When the LNS adopts agent authentication, a session is allowed to be created if the authentication mode configured on virtual template interface is PAP and the authentication succeeds. If the authentication mode configured in virtual template interface is CHAP and that configured at LAC side is PAP, authentication fails and a session cannot be correctly created as the CHAP authentication level demanded by the LNS is higher than PAP authentication supplied by the LAC. The local end does not perform CHAP authentication by default Forcing LCP to Re-negotiate For NAS-Initialized VPN, the user first performs PPP negotiation with the NAS when a PPP session starts. If the negotiation passes, the NAS initializes an L2TP Tunnel connection, and transmits user information to the LNS so that the LNS can judge whether the user is legal or not according to the received agent authentication information. In some cases (e.g. authentication and accounting are made at LNS side simultaneously), re-negotiation needs to be made between the LNS and the user, and agent authentication information at NAS side will be ignored. The configuration of required LCP re-negotiation is optional at LNS side. Perform the following configuration in L2TP group view. 2-23

52 Manual VPN Chapter 2 L2TP Configuration Table 2-29 Enable/disable required LCP re-negotiation Enable required LCP re-negotiation Disable required LCP re-negotiation mandatory-lcp undo mandatory-lcp By default, LCP re-negotiation is not performed. After LCP re-negotiation is enabled, the LNS will not perform authentication on the user if authentication is not configured on the associated virtual template interface. In this case, the user is only authenticated once at LAC side, and the address from the global address pool is assigned to the client directly Setting Local Address and Assigning Address Pool After the L2TP Tunnel connection between an LAC and an LNS is created, the LNS should assign IP addresses for VPN users from the address pool. Before an address pool is specified, you must use the ip pool command in system view or domain view to define an address pool. For detailed description about the ip pool command, refer to the Security part of this manual. If the LNS adopts agent authentication or required CHAP authentication, the system uses the address pool configured in domain view for address assignment; if the LNS adopts required LCP re-negotiation, the system uses the global address pool for address assignment. These configurations are required at LNS side. Perform the following configuration in virtual template interface view. Table 2-30 Set local address and assigned address pool Set a local IP address Remove the local IP address Specify an address pool for remote address assignment Delete the address pool for remote address assignment ip address X.X.X.X netmask undo ip address X.X.X.X netmask remote address { pool pool-number X.X.X.X } undo remote address If you do not assign a value to the pool-number parameter behind the keyword pool when specifying an address pool, the system will use the default address pool for assignment. By default, addresses will be assigned to the peer end from address pool 0 (default address pool). 2-24

53 Manual VPN Chapter 2 L2TP Configuration Setting Username, Password and User Authentication At LNS side, if required CHAP authentication has been configured, you need to configure a local registered username and password at LNS side. The LNS performs user authentication to determine whether a user is a valid VPN user by comparing remote dial-in username and password with usernames and passwords registered at the local end. If the authentication passes, the VPN user is allowed to communicate with the LNS; if it fails, L2TP will be notified to clear the L2TP connection. These configurations are optional at LNS side. For more information on how to configure them, refer to the Setting Username, Password and Local User Authentication Terminating an L2TP Connection A connection can be terminated for one of these reasons: no user is present, a fault occurs on the network, or the administrator requests to do so. Both the LAC side and LNS side can request to terminate the connection. After a Tunnel is terminated, the control connections and sessions on it are cleared. This Tunnel can be set up when a new user dials in. These configurations are optional at LNS side. Perform the following configurations in user view. Table 2-31 Terminate a connection by force Terminate a Tunnel reset l2tp Tunnel { name remote-name id Tunnel-id } Terminate a session Disconnect a user reset l2tp session session-id reset l2tp user user-name Enabling/Disabling Flow Control Function of Tunnel This configuration can enable/disable the simple flow control function on a Tunnel. These configurations are optional at LNS side. Perform the following configuration in L2TP group view. 2-25

54 Manual VPN Chapter 2 L2TP Configuration Table 2-32 Enable/disable flow control function of a Tunnel Enable flow control function of a Tunnel Disable flow control function of a Tunnel Tunnel flow-control undo Tunnel flow-control By default, the flow control function of Tunnels is disabled Setting the L2TP Session Timeout Timer An L2TP session is terminated automatically if the session is idle or no data is transmitted or received on it for a specified period. You may set a session idle-timeout timer to specify this idle period. You can even configure L2TP sessions to never time out, that is, the L2TP sessions will not be terminated automatically. Perform the following configuration in L2TP group view. Table 2-33 Set the L2TP session timeout timer Set the L2TP session timeout timer Disable the L2TP session timeout timer session idle-time seconds undo session idle-time By default, an L2TP session never expires. 2.4 Displaying and Debugging L2TP After performing the above configuration tasks, execute display commands in any view to view the running status of L2TP configurations, and to verify the configuration effect. The debugging commands can be used in user view. Table 2-34 Display and debug L2TP Display information about the current L2TP users Display information about the current L2TP Tunnels Display information about the current L2TP sessions Enable all types of L2TP debugging Disable all types of L2TP debugging Enable L2TP control packet debugging display l2tp user display l2tp Tunnel display l2tp session debugging l2tp all undo debugging l2tp all debugging l2tp control 2-26

55 Manual VPN Chapter 2 L2TP Configuration Disable L2TP control packet debugging Enable PPP packet debugging Disable PPP packet debugging Enable L2TP error debugging Disable L2TP error debugging Enable L2TP event debugging Disable L2TP event debugging Enable hidden AVP debugging Disable hidden AVP debugging Enable L2TP payload debugging Disable L2TP payload debugging Enable L2TP time stamp debugging Disable L2TP time stamp debugging undo debugging l2tp control debugging l2tp dump undo debugging l2tp dump debugging l2tp error undo debugging l2tp error debugging l2tp event undo debugging l2tp event debugging l2tp hidden undo debugging l2tp hidden debugging l2tp payload undo debugging l2tp payload debugging l2tp time-stamp undo debugging l2tp timestamp 2.5 L2TP Configuration Example I. Network requirements As shown in Figure 2-6, a VPN user accesses the headquarters as follows: The L2TP user implements dial-up access. The NAS authenticates this user. The NAS sends a request to the LNS for establishing a Tunnel. After the Tunnel between the NAS and LNS is established, the NAS sends back the packet about the negotiation with the VPN user to the LNS. The LNS determines whether to accept this connection according to pre-negotiated content. The user and headquarters communicate through the Tunnel between the NAS and LNS. 2-27

56 Manual VPN Chapter 2 L2TP Configuration II. Network diagram /24 VLAN 30 VLAN /24 SecBlade /24 VLAN / /24 Switch(LNS) VLAN 10 Internet NAS(LAC) Trust Zone L2TP User / /24 Figure 2-6 Network diagram for L2TP III. Configuration procedure 1) PC IP address: /24 Gateway: ) NAS # Set a system user. <NAS> system-view [NAS] local-user vpdnuser [NAS-luser-vpdnuser] password simple Hello [NAS-luser-vpdnuser] service-type ppp [NAS-luser-vpdnuser] quit # Configure a virtual template interface. [NAS] interface Virtual-Template 0 [NAS-Virtual-Template0] ppp authentication-mode pap [NAS-Virtual-Template0] quit # Bind the virtual template interface to the Ethernet interface. [NAS] interface GigabitEthernet 0/0 [NAS-GigabitEthernet0/0] pppoe-server bind virtual-template 0 [NAS-GigabitEthernet0/0] quit # Configure the Ethernet interface connected to the LNS. [NAS] interface GigabitEthernet 0/1 [NAS-GigabitEthernet0/1] ip address [NAS-GigabitEthernet0/1] quit 2-28

57 Manual VPN Chapter 2 L2TP Configuration # Enable L2TP service. [NAS] l2tp enable # Set an L2TP group. [NAS] l2tp-group 1 [NAS-l2tp1] Tunnel authentication [NAS-l2tp1] Tunnel password simple secblade [NAS-l2tp1] Tunnel name LAC [NAS-l2tp1] start l2tp ip fullusername l2tp [NAS-l2tp1] quit # Configure a static route. [NAS] ip route-static ) Switch (SecBlade) # Divide into VLANs. <H3C> system-view [H3C] vlan 10 [H3C-vlan10] quit [H3C] vlan 30 [H3C-vlan30] quit [H3C] vlan 50 [H3C-vlan50] quit # Configure an IP address. [H3C] interface vlan-interface 10 [H3C-Vlan-interface10] ip address [H3C-Vlan-interface10] quit [H3C] interface vlan-interface 30 [H3C-Vlan-interface30] ip address [H3C-Vlan-interface30] quit # Configure a static route. [H3C] ip route-static # Configure aggregation of SecBlade interfaces (the SecBlade card resides in slot 2). [H3C] secblade aggregation slot 2 # Create SecBlade module test. [H3C] secblade module test # Specify a SecBlade interface VLAN. [H3C-secblade-test] secblade-interface vlan-interface 30 # Set the VLAN to be protected. [H3C-secblade-test] security-vlan

58 Manual VPN Chapter 2 L2TP Configuration # Map the SecBlade module to the SecBlade card in the specified slot. [H3C-secblade-test] map to slot 2 [H3C-secblade-test] quit [H3C] quit # Log into the SecBlade card in the specified slot. <H3C> secblade slot 2 (Both the default user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade> system-view # Create a sub-interface. [SecBlade] interface GigabitEthernet 0/0.1 [SecBlade-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade-GigabitEthernet0/0.1] ip address [SecBlade-GigabitEthernet0/0.1] quit [SecBlade] interface GigabitEthernet 0/0.2 [SecBlade-GigabitEthernet0/0.2] vlan-type dot1q vid 50 [SecBlade-GigabitEthernet0/0.2] ip address [SecBlade-GigabitEthernet0/0.2] quit # Add the sub-interface to the corresponding zone (applicable to firewall cards only). [SecBlade] firewall zone trust [SecBlade-zone-trust] add interface GigabitEthernet 0/0.1 [SecBlade -zone-trust]quit [SecBlade]firewall zone untrust [SecBlade-zone-untrust] add interface GigabitEthernet 0/0.2 [SecBlade-zone-untrust] quit # Configure the firewall to permit packets to pass (applicable to firewall cards only). [SecBlade] firewall packet-filter default permit # Set a system user. [SecBlade] local-user vpdnuser [SecBlade-luser-vpdnuser] password simple Hello [SecBlade-luser-vpdnuser] service-type ppp [SecBlade-luser-vpdnuser] quit # Configure a virtual template interface. [SecBlade] interface Virtual-Template 0 [SecBlade-Virtual-Template0] ip address [SecBlade-Virtual-Template0] remote address [SecBlade-Virtual-Template0] ppp authentication-mode pap [SecBlade-Virtual-Template0] quit # Enable the L2TP service. 2-30

59 Manual VPN Chapter 2 L2TP Configuration [SecBlade] l2tp enable # Set an L2TP group. [SecBlade-l2tp1] Tunnel authentication [SecBlade-l2tp1] Tunnel password simple secblade [SecBlade-l2tp1] Tunnel name LNS [SecBlade-l2tp1] allow l2tp virtual-template 0 remote LAC [SecBlade-l2tp1] quit # Configure a static route. [SecBlade] ip route-static [SecBlade] ip route-static # Quit the SecBlade configuration view. [SecBlade] quit <SecBlade> quit 2.6 L2TP Troubleshooting The VPN Tunnel setup process is quite complicated; only several common cases are analyzed here. Before debugging the VPN, confirm that both the LAC and LNS are connected to a public network, and are connected correctly. Symptom 1: User s login fails. Troubleshooting: Failure causes are as follows: Fail to establish a Tunnel because: 1) At LAC side, LNS addresses are improperly set. 2) At LNS side, no L2TP group that can receive the remote end of the Tunnel is configured. For details, refer to the description of the allow command. 3) Tunnel authentication fails. If authentication is configured, make sure that the same Tunnel authentication password is configured at both sides. 4) If the local end terminates the connection by force but the peer end fails to receive the Disconnect packet due to some network transmission problems, the Tunnel will fail after a Tunnel setup request is initiated immediately. The reason is that both sides cannot detect the disconnection within a certain period. PPP negotiation fails because : 1) An error occurs to the username or password set at LAC side, or the corresponding users are not set at LNS side. 2) The LNS cannot assign addresses, e.g. because the address pool is too small or no address pool is set at all. 3) The types of Tunnel password authentication are inconsistent. The default authentication type of VPN connection created by Windows 2000 is MSCHAP. If the peer end does not support MSCHAP, CHAP is recommended instead. 2-31

60 Manual VPN Chapter 2 L2TP Configuration Symptom 2: Data transmission fails. After the connection is established, no data can be transmitted, e.g. the peer end cannot be pinged through. Troubleshooting: Possible causes are as follows: The address set by the user is wrong: Generally, it is up to the LNS to assign addresses, but a user can also designate his own address. If the designated address and the address assigned by the LNS are not in the same network segment, this problem occurs. It is recommended that the LNS assign addresses completely. Network congestion: Congestion occurs to the Internet backbone and packet loss is serious. L2TP uses user datagram protocol (UDP) for transmission. Because UDP lacks error control mechanism, applying L2TP on an unstable line will result in ping failures. 2-32

61 Manual VPN Chapter 3 GRE Configuration Chapter 3 GRE Configuration 3.1 Brief Introduction to GRE I. GRE overview Generic routing encapsulation protocol (GRE) can encapsulate datagrams of some network layer protocols (e.g. IP and IPX) and allow these encapsulated datagrams to be transferred in another network layer protocol (e.g. IP). GRE is a Layer 3 Tunnel protocol of a VPN, adopting a technique called Tunnel between protocol layers. Each Tunnel is a virtual point-to-point connection and can be regarded as a virtual interface only supporting a point-to-point connection. The interface provides a Tunnel whereby encapsulated datagrams can be transmitted. And it can also encapsulate and decapsulate datagrams at both ends of the Tunnel. To move in a Tunnel, a packet must undergo the processes of encapsulation and decapsulation, which is illustrated in Figure 3-1: Novell IPX Protocol Group1 Switch A Internet GRE Tunnel Switch B Novell IPX Protocol Group2 Figure 3-1 IPX network interconnection through GRE Tunnel 1) Process of encapsulation After receiving an IPX packet, the interface connected to Novell group1 first sends it to IPX for processing. IPX decides how to route it by examining the destination address field in its IPX header. If IPX finds that the packet should pass by the network 1f (virtual network number of the Tunnel) in order to reach the destination, it delivers the packet to the Tunnel interface with the network number of 1f. After receiving the packet, the Tunnel interface performs GRE encapsulation before forwarding it to the IP module for processing. After the IP header is encapsulated, the packet will be forwarded to the appropriate network interface according to its destination address and the routing table. 2) Process of decapsulation The process of decapsulation is contrary to that of encapsulation. The system examines the destination address of each IP packet received from the Tunnel interface; if the destination is the tunnel interface, the system removes the IP header of the packet and sends it to the GRE module for processing (verifying key, checksum, and serial number of the packet). After completing all the actions, the GRE module 3-1

62 Manual VPN Chapter 3 GRE Configuration removes the GRE header of the packet and sends it to the IPX module where it is handled just as a common one. When receiving a datagram to be encapsulated and routed, called payload, the system first add a GRE header to the datagram to form a GRE packet. This GRE packet is then encapsulated into an IP packet, thus allowing the IP layer to forward the packet. The IP in this particular case is called Delivery Protocol or Transport Protocol. The format of an encapsulated Tunnel packet is shown as follows: Delivery Header (Transport Protocol) GRE Header (Encapsulation Protocol) Payload Packet (Passenger Protocol) Figure 3-2 Format of encapsulated Tunnel packets For instance, an IPX Delivery packet encapsulated in IP Tunnel is as follows: IP header GRE header IPX payload Passenger protocol Encapsulation protocol Figure 3-3 Format of Delivery packets in Tunnel II. Application scope GRE provides services below: 1) Allowing a multi-protocol local network to make transmission through a single-protocol backbone network Novell IPX Protocol Group1 Switch A Switch B Novell IPX Protocol Group2 Internet GRE Tunnel IP Protocol Term 1 IP Protocol Term 2 Figure 3-4 Multi-protocol local network that makes transmission through a single-protocol backbone network 3-2

63 Manual VPN Chapter 3 GRE Configuration In the above figure, Group1 and Group2 are the local networks employing the Novell IPX protocol; Term1 and Term2 are the local networks running IP. By setting up a GRE Tunnel between Switch A and Switch B, you can allow Group1 to communicate with Group2 and Term1 with Term2 without interfering with each other. 2) Expanding the operating scope of networks running hop-limited protocols (e.g. IPX) Switch A Switch B IP network GRE tunnel IP network Host A Router A IP network Router B Host B Figure 3-5 Expanding network operating scope If the hop count between two terminals in the above figure is more than 15, the two terminals cannot communicate with each other. By setting up a Tunnel across the network, some hops can be hidden, thus expanding the operating scope of the network. 3) Connecting some discontinuous sub-networks to establish a VPN Novell IPX protocol Group 1 GRE tunnel Novell IPX protocol Group 2 Switch A IP network Switch B Figure 3-6 Tunnel connecting discontinuous sub-networks Sub-networks group1 and group2 running Novell IPX are in different cities but they can form a VPN over WAN by using a Tunnel. 4) Use in conjunction with IPSec 3-3

64 Manual VPN Chapter 3 GRE Configuration Switch A Internet GRE tunnel IPSec tunnel Switch B Corporate intranet Remote office network Figure 3-7 GRE-IPSec Tunnel application Routing protocol data, voice data and video data can be encapsulated by GRE first, and then be encrypted through IPSec. In addition, GRE also supports users to select and record identification key of the Tunnel interface, and supports end-to-end check of encapsulated packets. Due to such factors as encapsulation and decapsulation between the GRE sender and receiver and data increase caused by encapsulation, the use of GRE may somewhat decrease the data forwarding efficiency of SecBlade. 3.2 GRE Configuration Among all the configuration tasks, a virtual Tunnel interface must be created first before other function features can be configured on it. Deleting a virtual Tunnel interface deletes all configurations on it. GRE configuration tasks include: Create a virtual Tunnel interface (required) Set encapsulation mode (optional) Specify source end of Tunnel (required) Specify destination end of Tunnel (required) Set the network address of Tunnel interface (required) Configure end-to-end verification on both ends of Tunnel (optional) Set identification key of Tunnel interface (optional) Configure routing through Tunnel (optional) Creating a Virtual Tunnel Interface A virtual Tunnel interface should be created so that other parameters of GRE can be configured on it. These configurations are required on both ends of the Tunnel. Perform the following configuration in system view. 3-4

65 Manual VPN Chapter 3 GRE Configuration Table 3-1 Create a virtual Tunnel interface Create a virtual Tunnel interface Delete a virtual Tunnel interface interface Tunnel number undo interface Tunnel number By default, no virtual Tunnel interface is created. number specifies an interface number, ranging from 0 to 1023, but the actual number of created Tunnels depends on the total number of interfaces and available memory Setting Encapsulation Mode An encapsulation protocol and transmission protocol are to be configured on the Tunnel interface. The configurations are optional on both ends of a Tunnel. If you do configure them, make sure to use the same encapsulation mode on both ends. Perform the following configuration in Tunnel interface view. Table 3-2 Set encapsulation mode Set an encapsulation mode on the Tunnel interface Tunnel-protocol gre By default, the encapsulation protocol is GRE Specifying Tunnel Source After the creation of a Tunnel interface, the source address of the Tunnel, that is, the actual interface address where GRE packets are forwarded, also needs to be specified. A Tunnel is uniquely identified by one source address and one destination address. These configurations are required on both ends of the Tunnel, with the source address at one end being the destination address at the other end and vice versa. Perform the following configuration in Tunnel interface view. Table 3-3 Specify source address of the Tunnel Specify the source address of the Tunnel Delete the source address of the Tunnel source { ip-addr interface-type interface-num } undo source 3-5

66 Manual VPN Chapter 3 GRE Configuration Note: The same source address and destination address cannot be configured on two or more Tunnel interfaces running the same protocol. The source command configures an actual physical interface address or actual physical interface. The network address of the Tunnel interface also needs to be configured using the ip address command in Tunnel interface view Specifying Tunnel Destination After the creation of a Tunnel interface, the destination address of the Tunnel, that is, IP address of the actual physical interface receiving GRE packets, also needs to be specified. A Tunnel is uniquely identified by one source address and one destination address. These configurations are required on both ends of the Tunnel, with the source address at one end being the destination address at the other end and vice versa. Perform the following configuration in Tunnel interface view. Table 3-4 Specify destination address of the Tunnel Set the destination address of the Tunnel Delete the destination address of the Tunnel destination ip-addr undo destination Note: The destination command sets the IP address of an actual physical interface. In order to support dynamic routing protocols, the network address of the Tunnel interface also needs to be configured Assigning Network Address to Tunnel Interface You must assign addresses to the interfaces at both ends of a Tunnel. The assigned addresses can be private ones but they must belong to the same network segment. Perform the following configuration in Tunnel interface view. 3-6

67 Manual VPN Chapter 3 GRE Configuration Table 3-5 Assign network address to a Tunnel interface Assign an IP address to the Tunnel interface Delete the IP address of the Tunnel interface ip address { ip-addr mask unnumbered interface interface-type interface-number } undo ip address By default, the network address of the Tunnel interface is not configured Configuring End-to-End Verification on Both Ends of Tunnel As stipulated by RFC1701, if the Checksum Present bit in a GRE header is set to 1, the checksum field is present and contains valid information. The sender calculates the checksum according to GRE header and payload information and sends the packet containing the checksum information to the peer end. The receiver calculates the checksum of the received packet and compares it with the one in the packet. If they are consistent, the packet that may be discarded otherwise will be further processed. The checksum can be enabled or disabled on the two ends of a Tunnel as needed. If the checksum is enabled only at the local end, the local end will calculate the checksum of each transmitted packet but will ignore the checksum of received packets; on the contrary, if the checksum is enabled only at the peer end, the local end will verify the checksum of each received packet but will ignore the checksum of transmitted packets. Perform the following configuration in Tunnel interface view. Table 3-6 Enable/disable end-to-end verification on both ends of a Tunnel Enable end-to-end verification on both ends of the Tunnel Disable end-to-end verification on both ends of the Tunnel gre checksum undo gre checksum By default, end-to-end verification is disabled on both ends of a Tunnel Setting Identification Key of Tunnel Interface RFC1701 provides that if the Key Present bit in the GRE header of a packet is set to 1, the Tunnel identification key carried by the packet will be verified between the sender and the receiver. The verification will fail if different identification keys are used at both ends, and the packet will be discarded. Perform the following configuration in Tunnel interface view. 3-7

68 Manual VPN Chapter 3 GRE Configuration Table 3-7 Set identification key of the Tunnel interface Set the identification key of the Tunnel interface Cancel the identification key of Tunnel interface gre key key-number undo gre key The key-number argument is an integer in the range 0 to By default, the Tunnel does not use a KEY Configuring Routing Through Tunnel A Tunnel route must exist on both the source and destination ends, so that GRE packets can be forwarded properly. I. Configuring static routing You may manually configure a route to the destination address, which is the destination address of the unencapsulated packet rather than the destination address of the Tunnel, with the next hop being the address of the peer Tunnel interface address. This configuration is required at both ends of the Tunnel. For details about this configuration, refer to the Routing Protocol module of this manual. For detailed descriptions on the configuration commands, refer to the Manual accompanying this manual. II. Configuring dynamic routing If a dynamic routing protocol is running on the SecBlade, you may simply enable this protocol on both the Tunnel interface and the interface of the SecBlade directly connected to the private network. This configuration is required on both ends of the Tunnel. For details about this configuration, refer to the Routing Protocol module of this manual. For detailed descriptions on the configuration commands, refer to the Manual accompanying this manual Configuring the Keepalive Function Perform the following configuration in Tunnel interface view. Table 3-8 Configure the keepalive function Enable the keepalive function of GRE keepalive [ seconds ] [ times ] Disable the keepalive function of GRE undo keepalive [ seconds ] [ times ] 3-8

69 Manual VPN Chapter 3 GRE Configuration By default, the keepalive function of GRE is disabled; the seconds argument is set to 10 and times to 3. After the GRE keepalive function is enabled, the SecBlade will send GRE keepalive packets to the Tunnel interface periodically. If the remote end does not respond at the expiry of the timeout time, the local end SecBlade will send keepalive packets again. If the remote end still does not respond after the maximum number of retries, the protocol state of the local Tunnel interface will become down. 3.3 Displaying and Debugging GRE Upon completion of the above configurations, execute the display command in any view to view their running state and to verify the effect of the configurations. The debugging command can be used in user view. Table 3-9 Display and debug GRE Display operating state of Tunnel interfaces Enable Tunnel information debugging display interface Tunnel number debugging Tunnel 3.4 GRE Configuration Example I. Network requirements A GRE Tunnel is established between SecBlade_A and SecBlade_B so that PC_A and PC_B can be connected with each other. 3-9

70 Manual VPN Chapter 3 GRE Configuration II. Network diagram / /24 Router VLAN 50 VLAN /24 VLAN /24 Switch A /24 Switch B /24 VLAN 40 VLAN /24 SecBlade A / /24 VLAN /24 SecBlade B VLAN 10 VLAN 20 Trust Zone Trust Zone PC-A /24 PC-B /24 Figure 3-8 Network diagram for GRE III. Configuration procedure 1) PC-A IP address: /24 Gateway: ) PC-B IP address: /24 Gateway: ) Router # Configure the interface address. <Router> system-view [Router] interface GigabitEthernet 0/0 [Router-GigabitEthernet0/0] ip address [Router-GigabitEthernet0/0] quit [Router] interface GigabitEthernet 0/1 [Router-GigabitEthernet0/1] ip address [Router-GigabitEthernet0/1] quit 4) Switch A (SecBlade_A) # Divide into VLANs. <H3C_A> system-view [H3C_A] vlan

71 Manual VPN Chapter 3 GRE Configuration [H3C_A-vlan10] quit [H3C_A] vlan 30 [H3C_A-vlan30] quit [H3C_A] vlan 50 [H3C_A-vlan50] quit # Configure the IP address. [H3C_A] interface vlan-interface 10 [H3C_A-Vlan-interface10] ip address [H3C_A-Vlan-interface10] quit [H3C_A] interface vlan-interface 30 [H3C_A-Vlan-interface30] ip address [H3C_A-Vlan-interface30] quit # Configure the static route. [H3C_A] ip route-static # Configure aggregation of SecBlade interfaces (the SecBlade card resides in slot 2). [H3C_A] secblade aggregation slot 2 # Establish SecBlade configuration module test. [H3C_A] secblade module test # Specify the SecBlade interface VLAN. [H3C_A-secblade-test] secblade-interface vlan-interface 30 # Set the protected VLAN. [H3C_A-secblade-test] security-vlan 50 # Map the SecBlade module to the SecBlade card in the specified slot. [H3C_A-secblade-test] map to slot 2 [H3C_A-secblade-test] quit [H3C_A] quit # Log into the SecBlade card in the specified slot. <H3C_A> secblade slot 2 (Both the default user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade_A> system-view # Create the sub-interface. [SecBlade_A] interface g0/0.1gigabitethernet 0/0.1 [SecBlade_A-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade_A-GigabitEthernet0/0.1] ip address [SecBlade_A-GigabitEthernet0/0.1] quit [SecBlade_A] interface GigabitEthernet 0/0.2 [SecBlade_A-GigabitEthernet0/0.2] vlan-type dot1q vid

72 Manual VPN Chapter 3 GRE Configuration [SecBlade_A-GigabitEthernet0/0.2] ip address [SecBlade_A-GigabitEthernet0/0.2] quit # Create the Tunnel interface. [SecBlade_A] interface Tunnel 0 # Assign an IP address to the tunnel. [SecBlade_A-Tunnel0] ip address # Configure Tunnel encapsulation mode. [SecBlade_A-Tunnel0] Tunnel-protocol gre # Configure the source address of the Tunnel. [SecBlade_A-Tunnel0] source # Configure the destination address of the Tunnel. [SecBlade_A-Tunnel0] destination [SecBlade_A-Tunnel0] quit # Add the virtual interface to the Trust zone (applicable to only firewall cards). [SecBlade_A] firewall zone untrust [SecBlade_A-zone-untrust] add interface Tunnel 0 [SecBlade_A-zone-untrust] quit # Configure the static route passing by the Tunnel. [SecBlade_A] ip route-static Tunnel 0 [SecBlade_A] ip route-static [SecBlade_A] ip route-static # Quit SecBlade configuration view. [SecBlade_A] quit <SecBlade_A> quit [H3C_A] 5) Switch B(SecBlade_B) # Divide into VLANs. <H3C_B> system-view [H3C_B] vlan 20 [H3C_B-vlan20] quit [H3C_B] vlan 40 [H3C_B-vlan40] quit [H3C_B] vlan 60 [H3C_B-vlan60] quit # Configure the IP addresses. [H3C_B] interface vlan-interface 20 [H3C_B-Vlan-interface20] ip address

73 Manual VPN Chapter 3 GRE Configuration [H3C_B-Vlan-interface20] quit [H3C_B] interface vlan-interface 40 [H3C_B-Vlan-interface40] ip address [H3C_B-Vlan-interface40] quit # Configure the static route. [H3C_B] ip route-static # Configure aggregation of SecBlade interfaces (the SecBlade card resides in slot 2). [H3C_B] secblade aggregation slot 2 # Create SecBlade module test. [H3C_B] secblade module test # Specify the SecBlade interface VLAN. [H3C_B-secblade-test] secblade-interface vlan-interface 40 # Set the protected VLAN. [H3C_B-secblade-test] security-vlan 40 # Map the SecBlade module to the SecBlade card in the specified slot. [H3C_B-secblade-test] map to slot 2 [H3C_B-secblade-test] quit [H3C_B] quit # Log into the SecBlade card in the specified slot. <H3C_B> secblade slot 2 (Both user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade_B> system-view # Create the sub-interface. [SecBlade_B] interface GigabitEthernet 0/0.1 [SecBlade_B-GigabitEthernet0/0.1] vlan-type dot1q vid 40 [SecBlade_B-GigabitEthernet0/0.1] ip address [SecBlade_B-GigabitEthernet0/0.1] quit [SecBlade_B] interface GigabitEthernet 0/0.2 [SecBlade_B-GigabitEthernet0/0.2] vlan-type dot1q vid 60 [SecBlade_B-GigabitEthernet0/0.2] ip address [SecBlade_B-GigabitEthernet0/0.2] quit # Create the Tunnel interface. [SecBlade_B] interface Tunnel 0 # Configure the Tunnel IP address. [SecBlade_B-Tunnel0] ip address # Configure Tunnel encapsulation mode. 3-13

74 Manual VPN Chapter 3 GRE Configuration [SecBlade_B-Tunnel0] Tunnel-protocol gre # Configure the source address of the Tunnel. [SecBlade_B-Tunnel0] source # Configure the destination address of the Tunnel. [SecBlade_B-Tunnel0] destination [SecBlade_B-Tunnel0] quit # Add the virtual interface to the Trust zone (applicable to only firewall cards). [SecBlade_A] firewall zone untrust [SecBlade_A-zone-untrust] add interface Tunnel 0 [SecBlade_A-zone-untrust] quit # Configure the static route passing by the Tunnel. [SecBlade_B] ip route-static Tunnel 0 [SecBlade_B] ip route-static [SecBlade_A] ip route-static # Quit SecBlade configuration view. [SecBlade_B] quit <SecBlade_B> quit [H3C_B] 3.5 GRE Troubleshooting GRE configuration is relatively simple, except that you should pay more attention to the consistency. Most errors can be located by executing the debugging Tunnel command. Here, only one type of error is analyzed, as shown in the following figure: Tunnel0 Tunnel0 GRE Tunnel Host A /16 Switch A Switch C Switch B Figure 3-9 Troubleshooting example of GRE Symptom 1: The interfaces at both ends of the Tunnel are correctly configured and both ends of the Tunnel can ping through each other successfully, but PC A and PC B fail to do so. Troubleshooting: Perform the following steps: In any view, perform the display ip route command on Switch A and Switch B respectively, making sure there is the route from interface Tunnel1/0/0 to 3-14

75 Manual VPN Chapter 3 GRE Configuration /16 on Switch A, and the route from interface Tunnel 2/0/0 to /16 on Switch B. If the needed static route does not exist in the output information of the above step, perform the ip route command in system view to add it. Taking Switch A for example, make the following configuration: <H3C> system-view [H3C] ip route-static Tunnel

76 Manual VPN Chapter 4 IPSec Configuration Chapter 4 IPSec Configuration 4.1 IPSec Overview IPSec The IP security (IPSec) protocol suite is a series of protocols prepared by the IETF. It provides high quality, interoperable and cryptology-based security for IP data packets. The two sides of communication perform encryption and data source authentication on the IP layer to assure confidentiality, data integrity, data origin authentication and anti-replay for packets when they are transmitted on networks. Note: Confidentiality is to encrypt a client data and then transmit it in cipher text. Data integrity is to authenticate the received data so as to determine whether the packet has been modified. Data origin authentication is to authenticate the data source to make sure that the data is sent from a real sender. Anti-replay is to prevent some malicious clients from repeatedly sending a data packet. In other words, the receiver will deny old or repeated data packets. IPSec attains the above aims through authentication header (AH) and encapsulating security payload (ESP) security protocols. Moreover, Internet key exchange (IKE) provides auto-negotiation key exchange and security association (SA) setup and maintenance services for IPSec so as to simplify the use and management of IPSec. AH mainly provides data source authentication, data integrity authentication and anti-replay. However, it cannot encrypt the protected packets. ESP provides an encryption function besides the above functions that AH provides. However, its data integrity authentication does not include IP header check. Note: AH and ESP can be used either independently or together. There are two types of working modes for AH and ESP: transport mode and Tunnel mode, which will be introduced later. 4-1

77 Manual VPN Chapter 4 IPSec Configuration IKE is to negotiate the cryptographic algorithm applied in AH and ESP and to put the necessary key in the algorithm to the proper place. Note: IPSec policy and algorithm can also be negotiated manually. So IKE negotiation is not required. The comparison of these two negotiation modes will be introduced later Overview of Encryption Card IPSec may use ESP or AH protocol to process packets. For a security purpose, complicated encryption/decryption/authentication algorithms are often used. The IPSec on a SecBlade uses many CPU resources for encryption/decryption algorithms, so the overall performance may be degraded. To solve this problem, you can insert an encryption card for a modularized SecBlade, on which IPSec operations are processed by hardware. This can improve IPSec processing efficiency, as well as overall performance of a SecBlade. 1) Encryption/decryption process on the encryption card: The SecBlade sends data to be encrypted or decrypted to the encryption card. The card runs encryption/decryption operations, adds/deletes encryption headers to/from data, and then sends the processed data back to the SecBlade for forwarding. 2) For the IPSec SA implemented by the encryption card, if the card is faulty, the backup function is enabled on the card and the selected encryption/authentication algorithms for the SA are supported by the IPSec module on VRP, IPSec shall be implemented by the IPSec module on the VRP. However, you cannot use one encryption card as the backup to another card. Note: The encryption card processes data using the same mechanism as the IPSec module on the VRP. The only difference is that the card uses hardware, while the IPSec module uses software Basic Concepts of IPSec I. Security association IPSec provides secure communication between two ends, which are called as IPSec peers. 4-2

78 Manual VPN Chapter 4 IPSec Configuration IPSec allows systems, network subscribers or administrators to control granularity of security services between peers. For instance, IPSec policies of an organization prescribe that data flow from a specific subnet should be protected using AH and ESP and be encrypted using triple data encryption standard (3DES) simultaneously. Moreover, the policies prescribe that data flow from another site should be protected using ESP only and be encrypted using DES only. IPSec can provide security protection at various levels for different data flows based on an SA. An SA is essential to IPSec. It is the standard for some elements of communication peers. For example, it determines which protocol should be applied (AH, ESP or both) as well as the working mode (transport mode or Tunnel mode), encryption algorithm (DES and 3DES), shared protecting key in some streams and SA duration. An SA is unidirectional, so at least two SAs are needed to protect data flow in two directions in bi-directional communication. Moreover, if both AH and ESP are applied to protect data flow between peers, still two SAs are needed for AH and ESP respectively. An SA is identified by a triplet uniquely, including security parameter index (SPI), destination IP address and security protocol ID (AH or ESP). The SPI is a 32-bit number generated for uniquely identifying an SA. It is transmitted in an AH/ESP header. An SA has duration. It is calculated as follows: Time-based duration is to update SA at a specific interval; Traffic-based duration is to update SA every time specific traffic (bytes) is transmitted. II. Working mode of IPSec protocol IPSec works in two modes: transport mode and Tunnel mode. They are specified in an SA. In the transport mode, AH/ESP is inserted after the IP header but before all transmission layer protocols or all other IPSec protocols. In the Tunnel mode, AH/ESP is inserted before the original IP header but after the new header. The data encapsulation format for various protocols (taking the transmission protocol TCP as an example) in the transmission/tunnel mode is shown in the following figure: 4-3

79 Manual VPN Chapter 4 IPSec Configuration Mode Protocol transport tunnel AH IP Header AH TCP Header data new IP Header AH raw IP Header TCP Header data ESP IP Header ESP TCP Header data ESP Tail ESP Auth data new IP Header ESP raw IP TCP Header Header data ESP Tail ESP Auth data AH-ESP IP Header AH ESP TCP Header ESP data Tail ESP Auth data new IP Header raw IP TCP AH ESP data Head er Header ESP Tail ESP Auth data Figure 4-1 Data encapsulation format for security protocols The Tunnel mode is safer than the transport mode. It can authenticate and encrypt original IP data packets completely. Moreover, it can hide the client IP address using the IPSec peer IP address. On the other hand, the Tunnel mode occupies more bandwidth than the transport mode because it has an extra IP header. Therefore, you can select a proper mode according to the practical need of security or performance. III. Authentication algorithm and encryption algorithm 1) Authentication algorithm Both AH and ESP can check integrity for an IP packet so as to determine whether the packet is modified. The authentication algorithm is implemented through a hybrid function. The hybrid function is a kind of algorithm that does not limit the length of inputting messages and outputs messages with a fixed length. The output message is called a message summary. IPSec peers calculate the packet summary through the hybrid function respectively. If they get identical summaries, the packet is integrated and not modified. Generally speaking, there are two types of IPSec authentication algorithms. MD5: Input a message with any length and generate a 128-bit message summary. SHA-1: Input a less than bit message and generate a 160-bit message summary. Because the SHA-1 summary is longer than that of MD5, SHA-1 is safer than MD5. 2) Encryption algorithm ESP can encrypt IP packets so that the content of the packets will not let out during transmission. The encryption algorithm is implemented by encrypting or decrypting data with identical key through a symmetric key system. IPSec in the VRP implements three types of encryption algorithms: Data encryption standard (DES): Encrypt a 64-bit plain text using a 56-bit key. Triple DES (3DES): Encrypt a plain text using three 56-bit keys (168 bits key). Advanced encryption standard (AES): 128-bit 192-bit and 256-bit AES algorithm, compliant with IETF standards, can be implemented on the VRP. 4-4

80 Manual VPN Chapter 4 IPSec Configuration IV. Negotiation mode There are two negotiation modes to establish an SA: manual mode (manual) and IKE auto-negotiation mode (isakmp). The former is a bit complex because all information about an SA has to be configured manually. Moreover, it does not support some advanced features of IPSec, such as key update timer. However, its advantage is that it can implement IPSec independent of IKE. The latter one is much easier because an SA can be established and maintained by IKE auto-negotiation as long as security policies of IKE negotiation are configured. The manual mode is feasible in the case of a small number of peer devices or in a small-sized static environment. For middle/large-sized dynamic environment, IKE auto-negotiation mode is recommended. V. IPSec DPD IPSec dead peer detection on-demand (IPSec DPD) is a function that allows on-demand IKE peer existence detection on IPSec/IKE Tunnels. The idea of DPD is that when an IKE end receives no packets from its peer within a specified period, a DPD query is triggered. The IKE end sends a query to its peer, thus detecting the existence of the IKE Peer. Compared with other keepalive mechanisms available on IPSec, DPD generates less traffic, but allows more prompt detection and quicker Tunnel recovery. In the scheme using Internet security association and key management protocol security association (ISAKMP SA) established between a router address and a virtual address of a virtual router redundancy protocol (VRRP) backup group, DPD can recover rapidly and automatically security Tunnels in case of active/standby switchover in a virtual router redundancy protocol (VRRP) backup group. DPD avoids security Tunnels from interrupting in case of active/standby switchover, expands the IPSec application scope, and makes the IPSec protocol more robust. DPD is implemented in compliance with RFC3706 and RFC ) Timers IPSec DPD uses the following two timers to control sending and receipt of DPD packets: Interval-time: specifies the interval for triggering a DPD query. If an IKE peer receives no IPSec packet from its peer when this timer times out, DPD query is triggered. Time_out: specifies the time waiting for a DPD acknowledgement. 2) Operating mechanism The following describers how DPD operates after being enabled: At the sender side 4-5

81 Manual VPN Chapter 4 IPSec Configuration A local IKE end does not receive IPSec packets from its peer when the interval-time timer expires and now, it wants to send IPSec packets to its peer. Then, the local IKE end sends a DPD query to its peer. At the same time, a timeout timer is started. If no acknowledgement is received upon expiration of this timer, DPD records one failure event. When the number of failure events reaches three, the involved ISAKMP SAs and IPSec SAs are deleted. The same mechanism applies to the IPSec SAs set up between a router and the virtual address of a VRRP standby group: when the failure count reaches three, the security Tunnel between them is deleted. The setup of this security Tunnel is triggered only when a packet matching the IPSec policy is present. The switchover duration depends on the setting of timeout timer. A shorter timer means a shorter downtime but increased overheads. You are recommended to use the default setting in normal cases. At the receiving end The peer of the sender sends an acknowledgement after receiving the query. Caution: If the IKE SA corresponding to an IPSec SA is updated, the DPD query function will fail and the IPSec SA will be removed when DPD query is triggered. The DPD function will take effect if a subsequent packet triggers IKE negotiation again and establishes an IPSec SA corresponding to the updated IKE SA IPSec on VRP The VRP implements the said aspects of IPSec. Through IPSec, peers (here refer to the SecBlade where the VRP locates as well as its peer) can perform various security protection (authentication, encryption or both) on different data flows, which are differentiated on the basis of an ACL. Security protection elements, such as security protocol, authentication algorithm, encryption algorithm and operation mode, are defined in IPSec proposal. The association between data flows and IPSec proposal (namely, apply a certain protection on a certain data flow), SA negotiation mode, peer IP address configuration (start/end of protection path), the required key as well as the duration of SA are defined in IPSec policies. Finally, IPSec policies are applied on interfaces of the SecBlade. This is the process of IPSec configuration. The following is the detailed description: 1) Defining data flows to be protected 4-6

82 Manual VPN Chapter 4 IPSec Configuration A data flow is an aggregation of a series of traffic, defined by the source address/mask, destination address/mask, number of protocol over IP, source port number and destination port number. An ACL defines a data flow, that is, traffic that matches an ACL is a data flow logically. A data flow can be a single TCP connection between two hosts or all traffic between two subnets. IPSec can apply different security protection on different data flows. So the first step of IPSec configuration is to define data flows. 2) Defining IPSec proposal An IPSec proposal prescribes the security protocol, authentication algorithm and encryption algorithm as well as operation mode (namely, the packet encapsulation mode) for data flows to be protected. AH and ESP supported by the VRP can be used either independently or together. AH supports MD5 and SHA-1 authentication algorithms. ESP supports MD5 and SHA-1 authentication algorithms as well as DES and 3DES encryption algorithms. Working mode supported by the VRP includes transport mode and Tunnel mode. For a data flow, peers at two ends should be configured with the identical protocol, algorithm and working mode. Moreover, if IPSec is applied on two SecBlades, filewalls or routers, the Tunnel mode is recommended so as to hide the real source and destination addresses. Therefore, you should define an IPSec proposal as needed so that you can associate it with data flows. 3) Defining IPSec policy or IPSec policy group An IPSec policy specifies a certain IPSec proposal for a certain data flow. An IPSec policy is defined by name and sequence number uniquely. IPSec policies fall into two types, manual IPSec policy and IKE negotiation IPSec policy. The former one is to configure parameters such as key, SPI as well as IP addresses of two ends in the Tunnel mode manually. For the latter one, these parameters are automatically generated by IKE negotiation. An IPSec policy group is an aggregation of IPSec policies with the identical name but different sequence numbers. In an IPSec policy group, the smaller the sequence number is, the higher the priority is. 4) Applying IPSec policies on an interface Apply all IPSec policies in a group on an interface so as to perform different security protection on different data flows forwarded through the interface. 4.2 IPSec Configuration I. Configuring IPSec 1) Configure an ACL 2) Configure a security proposal Create a security proposal (IPSec proposal or card SA proposal) 4-7

83 Manual VPN Chapter 4 IPSec Configuration Specify the encryption card used in the card SA proposal (only applies to encryption cards) Select security protocol Select security algorithm Select packet encapsulation mode 3) Create IPSec policy (manually or by using IKE) For the manual mode: Create IPSec policy Import ACL into IPSec policy Configure starting and end points for Tunnel Configure SPI for SA Configure SA keys For the IKE mode: Create IPSec policy using IKE Import card SA proposal into IPSec policy Import ACL into IPSec policy Import IKE peer into IPSec policy Configure SA duration (optional) Configure PFS feature for negotiation (optional) An IPSec policy can reference an IPSec proposal or card SA proposal as needed. 4) Configure IPSec policy template (optional) 5) Apply IPSec policy on the interface 6) Disable next-payload field checking (optional) II. Configuring the encryption card (optional) 1) Enable the encryption card 2) Enable VRP main software backup 3) Configure the fast forwarding function of the encryption card 4) Configure the simple network management operations for the encryption card Defining an ACL IPSec uses advanced ACLs to determine the packets needing to be protected. The role of advanced ACLs in IPSec is different from that of those introduced in firewalls. Normally, advanced ACLs are used for determining which data are permitted and which are denied on an interface. Advanced ACLs in IPSec, however, are used by IPSec to determine which packet needs security protection and which does not. For this reason, an advanced ACL applied in IPSec is in fact an encryption ACL. Packets permitted by an Encryption ACL will be under protection, while packets denied by the ACL will not be protected. An encryption ACL can apply on both input interfaces and output interfaces. 4-8

84 Manual VPN Chapter 4 IPSec Configuration For more information about the detailed configuration of ACL, see the Security part in this manual. Encryption ACLs defined at the local and peer devices should correspond to each other (i.e., they can mirror each other), thus allowing either side to decrypt the data encrypted at the other side. Otherwise, one end cannot decrypt data sending from the other end. For example, Local end: acl number 3101 rule 1 permit ip source destination Peer end: acl number 3101 rule 1 permit ip source destination Note: IPSec protects the data flow permitted in an ACL, therefore, the users are recommended to configure the ACL accurately, that is, configure permit only to the data flow needing IPSec protection so as to avoid the excessive use of the key word any. The users are recommended to configure the ACLs of local and peer ends as the mirror of each other. Otherwise, one end cannot decrypt data sending from the other end. Executing the display acl all command will display all the ACLs, including all the advanced IP ACLs regardless of whether they are for communications filtering or for encryption Defining an IPSec Proposal An IPSec proposal saves the particular security protocol and the encryption/authentication algorithms applied in IPSec, and provides security parameters for IPSec to make SA negotiation. To ensure the success of a negotiation, the two ends involved in the negotiation must use the same IPSec proposal. Perform the following tasks to configure a security proposal. Create an IPSec or card SA proposal Specify the encryption card in the card SA proposal (only applied when an encryption card is involved) Select a security algorithm Set the mode adopted by the security protocol in IP datagram encapsulation Select a security protocol 4-9

85 Manual VPN Chapter 4 IPSec Configuration Select a security algorithm I. Creating an IPSec or card SA proposal An IPSec proposal is a set of security protocols, algorithms and packet encapsulation format used to implement IPSec protection. An IPSec policy can determine the adopted security protocol, algorithms, and encapsulation mode by referencing one or more IPSec proposals. Before an IPSec proposal is referenced by an IPSec policy, this IPSec proposal must be established. You are allowed to modify an IPSec proposal, but such modifications cannot take effect at all if the modified proposal is applied to an SA that has been set up between the two sides after negotiation unless you execute the reset ipsec sa or reset encrypt-card sa command to reset the SA. New security proposals can only apply to new SAs. Perform the following configuration in system view. Table 4-1 Configure an IPSec proposal Create an IPSec proposal and access the IPSec proposal view (for IPSec module) Delete the IPSec proposal (for IPSec module) Create a card SA proposal and access its view (for encryption cards only ) Delete the card SA proposal (for encryption card) ipsec proposal proposal-name undo ipsec proposal proposal-name ipsec card-proposal proposal-name undo ipsec card-proposal proposal-name By default, no IPSec proposal is configured. II. Specifying the encryption card to be used by an IPSec proposal (only apply when an encryption card is involved) When an encryption card is used, you must specify its slot number in card SA proposal view. Each encryption card can be assigned to multiple encryption card security proposals. In system view, use the ipsec card-proposal proposal-name command to enter encryption card SA proposal view, and then specify the encryption card to be used by a security proposal in this view. Table 4-2 Assign an encryption card to the card SA proposal Enter the encryption card SA proposal view ipsec card-proposal proposal-name 4-10

86 Manual VPN Chapter 4 IPSec Configuration Assign an encryption card to the card SA proposal Remove the configuration use encrypt-card slot-id undo use encrypt-card By default, no encryption card is used in the card SA proposal. III. Selecting packet encapsulation mode You must specify an encapsulation mode in a security proposal. In addition, the same encapsulation mode must be adopted at the two ends of a security Tunnel. Perform the following configurations in IPSec proposal or card SA proposal view. Table 4-3 Select a packet encapsulation mode Set the IP datagram encapsulation mode adopted by the security protocol Restore the default encapsulation mode encapsulation-mode { transport Tunnel } undo encapsulation-mode Normally, the Tunnel mode is always adopted between two SecBlades, firewalls or routers. The transport mode is always preferred, however, with respect to the communication between two hosts or between a host and a SecBlade, firewall or router. By default, the Tunnel mode is adopted. IV. Selecting a security protocol The security protocol needs specifying in the IPSec proposal and by far AH and ESP are the only two options. You are allowed to use AH, ESP, or both, but the choice must be the same as that at the peer end of the security Tunnel. Perform the following configuration in the IPSec proposal or card SA proposal view. Table 4-4 Select security protocol Configure a security protocol used by IPSec proposal Restore default security protocol transform { ah ah-esp esp } undo transform By default, use esp, i.e. RFC2406-specified ESP. 4-11

87 Manual VPN Chapter 4 IPSec Configuration V. Selecting a security algorithm Different security protocols may use different authentication and encryption algorithms. Currently AH supports the MD5 and SHA-1 authentication algorithms, and ESP supports the MD5 and SHA-1 authentication algorithms and the DES, 3DES and AES encryption algorithms. Perform the following configuration in the IPSec proposal or card SA proposal view. Table 4-5 Select security algorithm Configure an encryption algorithm used by ESP Configure ESP not to authenticate packets Configure an authentication algorithm used by ESP Configure ESP not to authenticate packets Configure an authentication algorithm used by AH Restore the default authentication algorithm used by AH esp encryption-algorithm { 3des des aes nsa } undo esp encryption-algorithm esp authentication-algorithm { md5 sha1 hnsa } undo esp authentication-algorithm ah authentication-algorithm { md5 sha1 } undo ah authentication-algorithm ESP will allow packet encryption and authentication at the same time, or encryption only or authentication only. Note that the undo esp authentication-algorithm command will not restore the authentication algorithm to the default, but configure authentication method as null, i.e., undo authentication-method. When the encryption algorithm is null, the undo esp authentication-algorithm command is invalid. AH has no encrypting function and can only perform authentication for packets. The undo ah authentication-algorithm command is used to restore the AH protocol default authentication algorithm as md5. On both ends of a security Tunnel, the IPSec proposals referenced by an IPSec policy must be configured with the same authentication algorithm and encryption algorithm. ESP supports three types of encryption algorithms: des, 3des and aes, and two authentication algorithms: hmac-md5 and hmac-sha1. AH supports two types of authentication algorithms: hmac-md5 and hmac-sha1. By default, the encryption algorithm used by ESP is des and authentication algorithm used is md5. The authentication method used by AH is md

88 Manual VPN Chapter 4 IPSec Configuration Note: Only when the desired security protocol is selected using the transform command, can you configure the security algorithm. For example, if you can select ESP, you can only configure those security algorithms for ESP, excluding those for AH Creating an IPSec Policy An IPSec policy specifies a certain IPSec proposal for a certain data flow. IPSec policies fall into two types, manual IPSec policies and IKE negotiation IPSec policies. The former ones are to configure parameters such as the key, SPI and SA duration as well as IP addresses of two ends in the Tunnel mode manually. For the latter ones, these parameters are automatically generated by IKE negotiation. Note: This section describes configurations about an IPSec policy in detail, including manual configuration and IKE negotiation configuration. Configuration only for one mode will be followed by a special note. Otherwise, the configuration should be performed in both manual mode and IKE negotiation mode. I. Manually creating an IPSec policy 1) Manually creating an IPSec policy You are not allowed to modify the negotiation mode of an IPSec policy that has been created. For example: If the manual IPSec policy is established, it cannot be revised into isakmp mode, and you have to delete this IPSec policy before establishing a new one. Perform the following configuration in system view. Table 4-6 Establish IPSec policy Manually create an IPSec policy for an SA Modify the IPSec policy of the SA Delete the IPSec policy ipsec policy policy-name seq-number manual ipsec policy policy-name seq-number manual undo ipsec policy policy-name [ seq-number ] 4-13

89 Manual VPN Chapter 4 IPSec Configuration IPSec policies with the same name and different sequence numbers can compose an IPSec policy group. In one IPSec policy group, up to 500 IPSec policies can be configured. However, the maximum number of all IPSec policies in all IPSec policy groups is 500. In an IPSec policy group, the smaller the sequence number is, the higher the priority will be. By default, there is no IPSec policy. 2) Referencing IPSec proposal in IPSec policy An IPSec policy will specify its security protocol, algorithm and packet encapsulation format by referencing an IPSec proposal. Before an IPSec proposal is referenced, this IPSec proposal must be configured. Perform the following configuration in IPSec policy view. Table 4-7 Use IPSec proposal in IPSec policy Configure IPSec proposal referenced by IPSec policy Remove IPSec proposal referenced by IPSec policy proposal proposal-name1 [ proposal-name2... proposal-name6 ] undo proposal [ proposal-name ] An SA can be established through manual mode. One IPSec policy can reference only one IPSec proposal. If an IPSec proposal has been configured, the former IPSec proposal must be removed so as to configure a new IPSec proposal. On both ends of a security Tunnel, IPSec proposals referenced by the IPSec policy must be configured to use the same security protocol, algorithm and packet encapsulation mode. 3) Configuring an ACL referenced in IPSec policy An IPSec policy will reference an ACL. IPSec will specify which packet needs security protection and which does not according to the rules in this ACL. Packets permitted by ACL will be under protection, while packets denied by ACL will not be protected. Perform the following configuration in IPSec policy view. Table 4-8 Configure ACL referenced by IPSec policy Configure an ACL referenced by IPSec policy Remove an ACL referenced by IPSec policy security acl acl-number undo security acl One IPSec policy can reference only one ACL. If the IPSec policy has referenced more than one ACL, only the last configured list is valid. 4-14

90 Manual VPN Chapter 4 IPSec Configuration A manually created IPSec policy only protects one rule in an ACL, that is, protect only the first packet matching the ACL rather than subsequent packets matching other rules in the ACL. 4) Configuring Tunnel start/end point Generally, Tunnels applying IPSec policies are called security Tunnels. A security Tunnel is set up between the local and the peer gateways. To ensure the success in security Tunnel setup, you must configure correct local and peer addresses. Perform the following configuration in IPSec policy view. Table 4-9 Configure Tunnel start/end point Configure a local address in the IPSec policy Delete the local address configured in the IPSec policy Configure a peer address in the IPSec policy Delete the peer address configured in the IPSec policy Tunnel local ip-address undo Tunnel local Tunnel remote ip-address undo Tunnel remote [ ip-address ] With respect to an IPSec policy set up manually, only if both local and peer addresses are correctly configured, can a security Tunnel be set up. (As ISAKMP SA can automatically obtain local and peer addresses, it does not require the configuration of local or peer addresses. 5) Configuring SA SPI This configuration task only applies to a manually created IPSec policy. Use the following command to configure an SA SPI for manually creating an SA. An isakmp-mode IPSec policy does not need manual configuration and IKE will automatically negotiate an SPI and create an SA. Perform the following configuration in IPSec policy view. Table 4-10 Configure an SA SPI Configure an SA SPI sa spi { inbound outbound } { ah esp } spi-number Delete the SA SPI undo sa spi { inbound outbound } { ah esp } When configuring an SA for the system, you must set the parameters in the inbound and outbound directions separately. The SA parameters set at both ends of the security Tunnel must be fully matched. The SPI in the inbound SA at the local must be the same as that in the outbound SA at the 4-15

91 Manual VPN Chapter 4 IPSec Configuration peer. Likewise, the SA SPI in the outbound SA at the local must be the same as that in the inbound SA at the peer. 6) Configuring a key for SA This configuration is used only for a manual mode IPSec policy. An SA key can be input manually by using the following commands. (For an isakmp negotiation IPSec policy, manual configuration for key is not required. IKE will automatically negotiate security association key.) Perform the following configuration in IPSec policy view. Table 4-11 Configure a key used by security association Configure an AH authentication key (in hexadecimal form) Configure an protocol key (in character string) Configure an ESP encryption key (in hexadecimal form) Delete the configured SA parameter sa authentication-hex { inbound outbound } { ah esp } hex-key sa string-key { inbound outbound } { ah esp } string-key sa encryption-hex { inbound outbound } esp hex-key undo sa string-key { inbound outbound } { ah esp } undo sa authentication-hex { inbound outbound } { ah esp } undo encryption-hex { inbound outbound } esp At both ends of a security Tunnel, configured SA parameters must be consistent. The SA SPI and key input on local end must be the same as those output at peer end. The SA SPI and key output at local end must the same as those input at peer end. For the character string key and hex string key, the last configured one will be adopted. At both ends of a security Tunnel, the keys should be input in the same form. If a key is input in character string at one end and in hexadecimal form at the other end, the security Tunnel cannot be correctly established. II. Creating IPSec Policies by using IKE The configuration tasks for creating an IPSec policy by using IKE are as follows. Create an IPSec policies by using IKE Reference an IPSec proposal in the IPSec policy Configure an ACL referenced by the IPSec policy Referencing an IKE peer in the IPSec policy Configure the lifetime of an SA (optional) Configure the PFS feature in negotiation (optional) 4-16

92 Manual VPN Chapter 4 IPSec Configuration Configure IPSec DPD (optional) 1) Creating an IPSec policy by using IKE Perform the following configurations in system view. Table 4-12 Create an IPSec policy Create an IPSec policy by using IKE and access IPSec policy view Dynamically create an IPSec policy by using IKE and an IPSec policy template Modify an IPSec policy that has been established by using IKE negotiation Delete the specified IPSec policy ipsec policy policy-name seq-number isakmp ipsec policy policy-name seq-number isakmp [ template template-name ] ipsec policy policy-name seq-number isakmp undo ipsec policy policy-name [ seq-number ] To create a dynamic IPSec policy by making use of an IPSec policy template, you must first define the policy template. For more information about defining a policy template, see Configuring IPSec Policy Template. 2) Referencing an IPSec proposal in the IPSec policy An IPSec proposal is referenced in an IPSec policy to specify the IPSec protocol, algorithms, and packet encapsulation mode. Before an IPSec proposal can be referenced, it must have been created. Perform the following configurations in IPSec policy view. Table 4-13 Reference an IPSec proposal in the IPSec policy Reference an IPSec proposal in the IPSec policy Remove the IPSec proposal referenced by the IPSec policy proposal proposal-name1 [ proposal-name2... proposal-name6 ] undo proposal [ proposal-name ] If an SA is established through IKE (isakmp) negotiation, one security policy references a maximum of six IPSec proposals. IKE negotiation searches both ends of a security tunnel for the completely matched security proposals. If IKE cannot find a completely matched security proposal at both ends, no SA can be established and the packets to be protected will be discarded. 3) Referencing an ACL in the IPSec policy An IPSec policy will reference an ACL to specify which packet needs security protection and which does not according to the rules in this ACL. Packets permitted by 4-17

93 Manual VPN Chapter 4 IPSec Configuration the ACL will be under protection, while packets denied by the ACL will not be protected. Perform the following configuration in IPSec policy view. Table 4-14 Reference an ACL in the IPSec policy Reference an ACL in the IPSec policy Remove the ACL referenced by the IPSec policy security acl acl-number undo security acl One IPSec policy can reference only one ACL. If the IPSec policy has referenced more than one ACL, only the one configured last is valid. 4) Referencing an IKE peer in the IPSec policy In IKE negotiation mode, these parameters such as the peer, SPI and key can be obtained through negotiation, so you only need to associate an IPSec policy with an IKE peer. The IKE peer must be established before being referenced. Perform the following configurations in IPSec policy view. Table 4-15 Reference an ACL in the IPSec policy Reference an IKE peer in the IPSec policy Remove the referenced IKE peer from the IPSec policy ike peer peer-name undo ike peer [ peer-name ] Note: This section only discusses referencing an IKE peer for IPSec, but in practice other parameters also need to be configured in IKE Peer view, including IKE negotiation mode, ID type, NAT traversal, shared key, peer IP address, peer name etc. Refer to the next chapter for such details. 5) Configuring SA duration (lifetime) (optional) Configuring global SA lifetime All the SAs that have not been configured separately with a lifetime in IPSec policy view adopt the global lifetime. In the SA negotiation through IKE, the lifetime configured at the local or that proposed by the peer will be adopted, whichever is smaller. 4-18

94 Manual VPN Chapter 4 IPSec Configuration There are two types of lifetime: time-based" lifetime and traffic-based lifetime. The expiration of either type of lifetime will invalidate an SA. Before it goes invalid, IKE will set up a new SA for IPSec negotiation. Thus, when the old SA becomes fully invalid, a new one is available. Perform the following configurations in system view. Table 4-16 Configure a global SA lifetime Configure a global SA lifetime Restore the default global SA lifetime ipsec sa global-duration { traffic-based kilobytes time-based seconds } undo ipsec sa global-duration { traffic-based time-based } Changing the configured global lifetime does not affect the IPSec policies that have separate lifetimes or the SAs that have been set up. The changed global lifetime will apply to the IKE negotiation initiated later. Lifetime is not applicable to manually established SAs but isakmp mode SAs. In other words, a manually established SA will never fail. Configuring SA lifetime in IPSec policy view You can configure a separate SA lifetime for an IPSec policy. If such a lifetime is not available, the global SA lifetime will apply. In the SA negotiation through IKE, the lifetime configured at the local or at the peer will be adopted, whichever is smaller. Perform the following configurations in IPSec policy view. Table 4-17 Configure an SA lifetime Configure an SA lifetime for the IPSec policy Adopt the configured global SA lifetime sa duration { traffic-based kilobytes time-based seconds } undo sa duration { traffic-based time-based } Changing the configured global lifetime does not affect the SAs that have been set up. The changed global lifetime will apply to the IKE negotiation initiated later. 6) Configuring the PFS feature in negotiation Perfect forward secrecy (PFS) is a security feature. With it, keys are not derivative of one another, so the deciphering of a key will not threaten the security of other keys. 4-19

95 Manual VPN Chapter 4 IPSec Configuration This feature is implemented by adding the process of key exchange in the stage-2 negotiation of IKE. Perform the following configuration in IPSec policy view. Table 4-18 Set the PFS feature used in negotiation Configure the PFS feature used in negotiation Disable PFS in negotiation pfs { dh-group1 dh-group2 dh-group5 dh-group14 } undo pfs When IKE initiates a negotiation by using an IPSec policy configured with the PFS feature, it will make a key exchange operation. In the event that the local adopts PFS, the peer must also adopt PFS. The local and the peer must specify the same Diffie-Hellman (DH) group; otherwise, the negotiation between them will fail. The group2 provides a security level higher than group1 (the group5 provides a security level higher than group2, and the rest may be deduced by analogy), but it needs longer time for calculation. By default, the PFS feature is not used. 7) Configuring IPSec DPD (optional) Creating a DPD structure Perform the following configuration in system view. Table 4-19 Create a DPD structure and enter its view Create a DPD structure and enter its view Delete the specified DPD structure ike dpd dpd-name undo ike dpd dpd-name A DPD data structure, or a DPD structure, contains DPD query parameters, such as interval-time timer and timeout timer. A DPD structure can be referenced by multiple IKE peers. Thus, you need not configure one DPD structure for each interface. If a DPD structure has been referenced by an IKE peer, it cannot be deleted. Configuring timers Perform the following configuration in DPD structure view. Table 4-20 Configure timers Configure the interval for triggering a DPD query Restore the default interval for triggering a DPD query interval time seconds undo interval time 4-20

96 Manual VPN Chapter 4 IPSec Configuration Configure the time-out time waiting for a DPD acknowledgment Restore the default time-out time waiting for a DPD acknowledgment time out seconds undo time out By default, the interval for triggering a DPD query is 10 seconds, and the time-out time waiting for a DPD acknowledgment is five seconds. Specifying a DPD structure for an IKE peer Perform the following configuration in IKE peer view. Table 4-21 Specify a DPD structure for an IKE peer Specify a DPD structure for the IKE peer Remove the referenced DPD structure dpd dpd-name undo dpd Configuring IPSec Policy Template When creating an IPSec policy through IKE, you can configure the IPSec policy not only directly in IPSec policy view, but also by referencing an IPSec policy template. In the second mode, you must configure all IPSec policies in the IPSec policy template. The configuration of an IPSec policy template is similar to that of a common IPSec policy: first create a policy template and then configure template parameters. Perform the following configuration in system view. Table 4-22 Configure IPSec policy template Create/Modify an IPSec policy template Delete an IPSec policy template ipsec policy-template policy-template-name seq-number undo ipsec policy-template policy-template-name [ seq-number ] Using IPSec policy-template command, you will enter IPSec policy template view, in which you can configure the policy template related parameters. 4-21

97 Manual VPN Chapter 4 IPSec Configuration Note: The parameters configurable in an IPSec policy template are the same as those of IPSec policy in isakmp mode, except that many parameters are optional. Only IPSec proposal and IKE peer (for an IKE peer, there is no need to configure the IP address for its peer) are required, while the configuration of the data stream to be protected and the PFS feature are optional. Note that, if the IPSec policy template is used for policy matching, the configured parameters must be matched in IKE negotiation. After the configuration of policy template, the following command must be executed to reference the policy template just defined. Table 4-23 Reference IPSec policy template Reference an IPSec policy template ipsec policy policy-name seq-number isakmp template template-name After an IPSec policy references an IPSec policy template, you cannot enter its IPSec policy view for configuring or modifying the IPSec policy. Instead, you can enter its IPSec policy template view. Caution: The policy of an IPSec policy template cannot initiate SA negotiation, but can respond to a negotiation Applying IPSec Policy Group to Interface In order to validate a defined SA, you must apply an IPSec policy group on the interface (logical or physical) where the outgoing data needs encryption or incoming data needs decryption. In conjunction with the peer encryption device, data encryption on the interface will be made on the basis of the IPSec policy group. Deleting the IPSec policy group from the interface will disable the protection function of IPSec on the interface. Perform the following configuration in interface view. 4-22

98 Manual VPN Chapter 4 IPSec Configuration Table 4-24 Use IPSec policy group Apply IPSec policy group ipsec policy policy-name Remove the applied IPSec policy group undo ipsec policy [ policy-name ] An interface can only use one IPSec policy group. An IPSec policy group can be applied on more than one interface. A manually configured IPSec policy group can only be applied on one interface. When packets are transmitted from an interface, each IPSec policy in an IPSec policy group will be searched for according to sequence numbers in ascending order. If an ACL referenced by an IPSec policy permits a packet, the packet will be processed by this IPSec policy. If the packet is not permitted, the next IPSec policy will be searched for. If the packet is not permitted by any ACL referenced by the IPSec policy, it will be directly transmitted (IPSec does not protect the packet). H3C s IPSec policy can not only be applied on practical physical ports such as serial ports and Ethernet ports, but also on virtual interfaces such as Tunnel and Virtual Template. In this way, IPSec can be applied on Tunnels like GRE and L2TP according to the practical networking requirement. All IKE SAs will be removed only when IPSec policies are removed from all interfaces. Otherwise, you must manually remove the IKE SAs or wait till the IKE SAs time out Disabling Next-Payload Field Check An IKE negotiation packet comprises multiple payloads; the next-payload field is in the generic header of the last payload. According to the protocol, this field should be set to 0. It, however, may vary with vendors. For the interoperability sake, you can use the following commands to disable the check of this field during IPSec negotiation. Table 4-25 Disable the check of the next-payload field Disable the check of the next-payload field in the last payload of the IKE negotiation packet during IPSec negotiation Remove the default ike next-payload check disabled undo ike next-payload check disabled By default, the system checks the next-payload field in the last payload of the IKE negotiation packet during IPSec negotiation. 4-23

99 Manual VPN Chapter 4 IPSec Configuration Configuring the Encryption Card (Optional) The basic configurations of an encryption card are the same as those of IPSec; refer to the previous sections. The optional configurations for the encryption card are as follows. I. Entering encryption card interface view and enabling the card When a SecBlade has multiple encryption cards running at the same time, you may use the undo shutdown and shutdown commands to enable or disable them. The undo shutdown command can reset and initialize an encryption card that is disabled. Before you can shut down/enable the encryption card in a specified slot, you must use the interface encrypt command to enter the encryption card in a slot. Perform the following configuration in system view. Table 4-26 Enter encryption card interface view Enter encryption card interface view interface encrypt slot-id Perform the following configuration in encryption card interface view. Table 4-27 Enable or shut down the encryption card Turn up the encryption card Shut down the encryption card undo shutdown shutdown By default, all the fitted encryption cards are enabled. II. Enabling IPSec module backup function For the IPSec SA implemented by an encryption card, if the card is normal, IPSec is processed by the card. If the card fails, the backup function is enabled on the card, and the selected encryption/authentication algorithms for the SA are supported by the IPSec module on the VRP, IPSec will be implemented by the IPSec module on the VRP. In the event that the selected algorithms are not supported by the IPSec module, the system drops packets. Perform the following configuration in system view. 4-24

100 Manual VPN Chapter 4 IPSec Configuration Table 4-28 Configure IPSec module backup function Enable IPSec module backup function Disable IPSec module backup function encrypt-card backuped undo encrypt-card backuped By default, the IPSec module backup function is disabled. III. Configuring the fast forwarding function of the encryption card For the packets that have the same [SourIP, SourPort, DestIP, DestPort, Prot] quintuple, the SecBlade creates a fast forwarding entry when it receives/transmits the first packet. Then, the subsequent packets, rather than processed one by one, are sent directly to the encryption card, where they are sent to the destination after being encrypted or decrypted. This is how the fast forwarding function of the encryption card expedites packet processing. Perform the following configuration in system view. Table 4-29 Configure the fast forwarding function of the encryption card Enable the fast forwarding function of the encryption card Disable the fast forwarding function of the encryption card encrypt-card fast-switch undo encrypt-card fast-switch By default, the fast forwarding function of the encryption card is disabled. Caution: After the fast forwarding function is enabled on the encryption card, no ACL measurement will be performed on the packets fast-forwarded by the encryption card. IV. Performing simple network management configuration on encryption cards You can manage encryption cards on the SecBlade remotely through SNMP. With the NM function on the SecBlade, you can query the card status and monitor trap information, which includes information about card reset, status transition and packet loss. 4-25

101 Manual VPN Chapter 4 IPSec Configuration Perform the following configuration in system view. Table 4-30 Configure trap function on encryption card Enable the trap function on encryption card Disable the trap function on encryption card snmp-agent trap enable encrypt-card undo snmp-agent trap enable encrypt-card By default, the trap function is enabled on the encryption card. 4.3 Displaying and Debugging IPSec Displaying and Debugging IPSec Module on VRP I. Displaying and debugging IPSec configuration After the above configuration, execute the display command in any view to display the running of the IPSec configuration, and to verify the effect of the configuration. Execute debugging command in user view for the debugging of IPSec configuration. Table 4-31 Display and debug IPSec Display SA related information Display the information about IPSec Tunnel Display statistical information on IPSec processed packets Display an IPSec proposal Display an IPSec policy Display an IPSec policy template display ipsec sa [ brief remote ip-address policy policy-name [ seq-number ] duration ] display ipsec Tunnel display ipsec statistics display ipsec proposal [ proposal-name ] display ipsec policy [ brief name policy-name [ seq-number ] ] display ipsec policy-template [ brief name policy-name [ seq-number ] ] Display DPD configuration display ike dpd [ dpd-name ] Enable the IPSec debugging function debugging ipsec { all sa packet [ policy policy-name [ seq-number ] parameters ip-address protocol spi-number ] misc } 4-26

102 Manual VPN Chapter 4 IPSec Configuration Disable the IPSec debugging function Enable the debugging for DPD Disable the debugging for DPD undo debugging ipsec { all sa packet [ policy policy-name [ seq-number ] parameters ip-address protocol spi-number ] misc } debugging ike dpd undo debugging ike dpd II. Clearing IPSec packet statistical information This command clears IPSec packet statistical information. All statistical information is set to zero. Perform the following configuration in user view. Table 4-32 Clear IPSec packet statistics Clear IPSec packet statistical information reset ipsec statistics III. Deleting an SA The configuration is used to delete the established SA (either manually or through IKE negotiation). If no parameter is specified, all SAs will be deleted. Perform the following configuration in user view. Table 4-33 Delete SA Delete an SA reset ipsec sa [ remote ip-address policy policy-name [ seq-number ] parameters ip-address protocol spi-number ] If a packet re-triggers IKE negotiation after an SA set up through IKE negotiation is deleted, IKE will reestablish an SA through negotiation. If an SA set up manually is deleted, the system will automatically set up a new SA according to the parameter manually configured. If the parameters keyword is specified, SAs appear in pairs. The inbound SA will also be deleted after the outbound SA is deleted. 4-27

103 Manual VPN Chapter 4 IPSec Configuration Displaying and Debugging Encryption Card Information I. Displaying and debugging IPSec information on encryption cards You can view the IPSec configurations, including SA information, statistics, log, interface information and IPSec module backup function, on the encryption card using display commands in all views. Execute the debugging command in user view for the debugging of IPSec configuration. Table 4-34 Display and debug encryption card configuration Display interface information on the encryption card Display information about the fast forwarding entry for the encryption cards Enable VRP test software debugging on the encryption card Disable VRP test software debugging on the encryption card display interface encrypt [ slot-id ] display encrypt-card fast-switch debugging encrypt-card host { all packet sa command error misc } undo debugging encrypt-card host { all packet sa command error misc } II. Clearing statistics on encryption card Use this command to clear statistics of encryption cards. Perform the following configuration in user view. Table 4-35 Clear statistics on encryption card(s) Clear statistics on encryption card reset counters interface encrypt [ slot-id ] III. Deleting an SA on encryption card Use this command to clear the established SAs (either manually or through IKE negotiation) of the encryption cards on the SecBlade. Perform the following configuration in user view. 4-28

104 Manual VPN Chapter 4 IPSec Configuration Table 4-36 Delete SA Delete SAs on the encryption cared reset encrypt-card sa [ slot-id ] Note: Currently this command is not supported on encryption cards. IV. Clearing packet statistics on encryption card You can reset all counters on the encryption card, including for the statistics on data packets, bytes, lost packets, failed authentication, faulty SAs, invalid SA proposals, and invalid protocols. Perform the following configuration in user view. Table 4-37 Clear packet statistics on encryption card Clear packet statistics on encryption card reset encrypt-card statistics [ slot-id ] Note: Currently this command is not supported on encryption cards. V. Clearing system log on encryption card You can clear the system log information, which records all key operations to it, on the encryption card. Perform the following configuration in user view. Table 4-38 Clear system log information on encryption card Clear system log information on encryption card reset encrypt-card syslog [ slot-id ] 4-29

105 Manual VPN Chapter 4 IPSec Configuration Note: Currently this command is not supported on encryption cards. VI. Clearing the fast forwarding information on encryption card Perform the following configuration in user view. Table 4-39 Clear the fast forwarding information on encryption card Clear the fast forwarding information on the encryption card reset encrypt-card fast-switch 4.4 IPSec Configuration Example I. Network requirements An IPSec Tunnel is established between the SecBlade and Router. Therefore the data stream between PC_A and PC_B is protected when it is transferred through an insecure network. II. Network diagram /24 VLAN 30 VLAN /24 SecBlade /24 VLAN / /24 Switch VLAN 10 Unstrust Zone Router /24 Trust Zone PC-A /24 Trust Zone PC-B /24 Figure 4-2 Network diagram for IPSec III. Configuration procedure 1) PC_A IP address: /24 Gateway:

106 Manual VPN Chapter 4 IPSec Configuration 2) PC_B IP address: /24 Gateway: ) Router # Configure an interface IP address. <Router> system-view [Router] interface GigabitEthernet 0/0 [Router-GigabitEthernet0/0] ip address [Router-GigabitEthernet0/0] quit [Router] interface GigabitEthernet 0/1 [Router-GigabitEthernet0/0] ip address [Router-GigabitEthernet0/0] quit # Configure ACL rules. [Router] acl number 3000 [Router-acl-adv-3000] rule permit ip source destination [Router-acl-adv-3000] quit # Configure IPSec IKE. [Router] ike peer same [Router-ike-peer-same] pre-shared-key test [Router-ike-peer-same] remote-address [Router] quit # Configure an IPSec proposal. [Router] ipsec proposal tran [Router-ipsec-proposal-tran] encapsulation-mode Tunnel [Router-ipsec-proposal-tran] transform esp [Router-ipsec-proposal-tran] esp encryption-algorithm des [Router-ipsec-proposal-tran] esp authentication-algorithm sha1 [Router-ipsec-proposal-tran] quit # Configure an IPSec policy. [Router] ipsec policy auto 1 isakmp [Router-ipsec-policy-isakmp-auto-1] ike-peer same [Router-ipsec-policy-isakmp-auto-1] proposal tran [Router-ipsec-policy-isakmp-auto-1] security acl 3000 [Router-ipsec-policy-isakmp-auto-1] quit # Apply the IPSec policy to the sub-interface of the external network. [Route] interface GigabitEthernet 0/0 [Router-GigabitEthernet0/0] ipsec policy auto [Router-GigabitEthernet0/0] quit 4-31

107 Manual VPN Chapter 4 IPSec Configuration # Configure a static route. [Router] ip route-static ) Switch (SecBlade) # Divide into VLANs. <H3C> system-view [H3C] vlan 10 [H3C-vlan10] quit [H3C] vlan 30 [H3C-vlan30] quit [H3C] vlan 50 [H3C-vlan50] quit # Configure an IP address. [H3C] interface vlan-interface 10 [H3C-Vlan-interface10] ip address [H3C-Vlan-interface10] quit [H3C] interface vlan-interface 30 [H3C-Vlan-interface30] ip address [H3C-Vlan-interface30] quit # Configure a static route. [H3C] ip route-static # Configure aggregation of SecBlade interfaces (the SecBlade card resides in slot 2). [H3C] secblade aggregation slot 2 # Create SecBlade module test. [H3C] secblade module test # Specify the SecBlade interface VLAN. [H3C-secblade-test] secblade-interface vlan-interface 30 # Set the protected VLAN. [H3C-secblade-test] security-vlan 50 # Map the SecBlade module to the SecBlade card of the specified slot. [H3C-secblade-test] map to slot 2 [H3C-secblade-test] quit [H3C] quit # Log into the SecBlade card of the specified slot (Both user name and password are SecBlade by default). <H3C> secblade slot 2 user: SecBlade password: SecBlade <SecBlade> system-view 4-32

108 Manual VPN Chapter 4 IPSec Configuration # Create a sub-interface. [SecBlade] interface GigabitEthernet 0/0.1 [SecBlade-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade-GigabitEthernet0/0.1] ip address [SecBlade-GigabitEthernet0/0.1] quit [SecBlade] interface GigabitEthernet 0/0.2 [SecBlade-GigabitEthernet0/0.2] vlan-type dot1q vid 50 [SecBlade-GigabitEthernet0/0.2] ip address [SecBlade-GigabitEthernet0/0.2] quit # Configure an ACL rule. [SecBlade] acl number 3000 [SecBlade-acl-adv-3000] rule permit ip source destination [SecBlade-acl-adv-3000] quit # Configure IPSEC IKE. [SecBlade] ike peer same [SecBlade-ike-peer-same] pre-shared-key test [SecBlade-ike-peer-same] remote-address [SecBlade-ike-peer-same] quit # Configure an IPsec proposal. [SecBlade] ipsec proposal tran [SecBlade-ipsec-proposal-tran] encapsulation-mode Tunnel [SecBlade-ipsec-proposal-tran] transform esp [SecBlade-ipsec-proposal-tran] esp encryption-algorithm des [SecBlade-ipsec-proposal-tran] esp authentication-algorithm sha1 # Configure an IPsec policy. [SecBlade] ipsec policy auto 1 isakmp [SecBlade-ipsec-policy-isakmp-auto-1] ike-peer same [SecBlade-ipsec-policy-isakmp-auto-1] proposal tran [SecBlade-ipsec-policy-isakmp-auto-1] security acl 3000 [SecBlade-ipsec-policy-isakmp-auto-1] quit # Apply the IPSec policy to the sub-interface of the external network. [SecBlade] interface GigabitEthernet 0/0.2 [SecBlade-GigabitEthernet0/0.2] ipsec policy auto [SecBlade-GigabitEthernet0/0.2] quit # Configure a static route. [SecBlade] ip route-static [SecBlade] ip route-static # Quit SecBlade configuration view. 4-33

109 Manual VPN Chapter 4 IPSec Configuration [SecBlade] quit <SecBlade> quit [H3C] 4.5 IPSec Troubleshooting Symptom: When you apply an IPSec policy on an interface for the first time, the receiving/sending end can encrypt and decrypt the data flow normally; after you disable the IPSec function, the receiving/sending end can communicate normally; when you apply an IPSec policy for the second time, packets cannot be processed by IPSec, and the peer end cannot be pinged through. Troubleshooting: This problem usually occurs when the originator configures an IPSec policy directly in IPSec policy view, and the connected end creates an IPSec policy by referencing an IPSec policy template. When you apply the IPSec policy for the first time, the communication is normal. However, when you disable the function, a fast forwarding entry is established at the connected end. So when you enable the IPSec policy for the second time, the presence of the fast forwarding entry causes IPSec processing of packets to fail. If you use the reset ip fast-forwarding cache command to clear the fast forwarding buffer before enabling the IPSec policy for the third time, the problem will be solved. 4-34

110 Manual VPN Chapter 5 IKE Configuration Chapter 5 IKE Configuration 5.1 IKE Overview Brief Introduction to IKE Internet key exchange (IKE) is used to set up an SA. It is a mixed protocol, configured in a framework specified by Internet security association and key management protocol (ISAKMP). IKE will provide automatic negotiation key exchange and SA establishment for IPSec, thus simplifying IPSec application and management. Network security has two meanings: one is internal network security, and the other is security of data exchange in public networks. The former is implemented by means of Firewall, and network address translation (NAT). Emerging IPSec implements the latter. IPSec provides a means of packet encryption in the IP layer. An IPSec SA can be established by manual configuration. When the number of nodes increases in the network, manual configuration will be very difficult, and hard to ensure security. In this case, the IKE automatic negotiation can be used to establish SAs and exchange keys. IKE has a series of self-protection mechanisms to safely distribute shared keys, authenticate identity, and establish IPSec SAs in insecure networks. The IKE security mechanism includes: Diffie-Hellman (DH) exchange and shared key distribution The Diffie-Hellman algorithm is a shared key algorithm. The both parties in communication can exchange some data without transmitting the shared key and find the shared key by calculation. The pre-condition for encryption is that the both parties must have a shared key. The merit of IKE is that it never transmits a shared key directly in an insecure network, but calculates the shared key by exchanging a series of data. Even if the third party (e.g. hackers) captures all exchange data used to calculate the shared key for both parties, he/she cannot figure out the real shared key. Perfect Forward Secrecy (PFS) PFS is a security feature. When a shared key is decrypted, there will be no impact on the security of other shared keys, because these secrets have no derivative relations. IPSec is implemented by adding key exchange during IKE negotiation phase II. Identity authentication Identity authentication will authenticate identity for both parties in communication. An authenticator can be input to generate a shared key. It is impossible for different authentication keys to generate the same shared key between the two parties. An authenticator is the key in identity authentication for both parties. Identity protection 5-1

111 Manual VPN Chapter 5 IKE Configuration After a shared key is generated, identity data will be encrypted and transmitted, thus protecting identity data. IKE uses 2 stages to implement shared key negotiation for IPSec and creating SAs. In the first stage, parties involved in the communication will establish a channel for identity authentication and security protection. An ISAKMP SA is established by the exchange in this stage. In the second stage, the security tunnel established in phase 1 will be used to negotiate specific SAs for IPSec and establish IPSec SAs. IPSec SAs will be used for final IP data security transmission. The relation between IKE and IPSec is shown in the following figure. IKE SA negotication IKE Switch A Switch B TCP/UDP SA SA TCP/UDP IPSec IPSec Encrypted packet Figure 5-1 Relation between IKE and IPSec I. IKE aggressive mode ADSL and dial-up are two solutions widely adopted for building a VPN. In these two solutions, there is an exceptional case where IP addresses of the devices at operator end are static and the IP addresses of the devices at subscriber end are dynamic. In order to support the application in this special case, the aggressive mode is introduced in IKE negotiation. This mode allows IKE to search for the pre-shared key of the negotiation initiator by the IP address or ID of the negotiation initiator to accomplish the negotiation. Compared to the main mode, the IKE aggressive mode delivers more flexibility and supports IKE negotiation even when the IP address of the initiator is dynamic. II. NAT traversal If there is a NAT gateway on the VPN Tunnel set up through IPSec/IKE and if this gateway performs NAT on the VPN service data, you must configure the NAT traversal function for IPSec/IKE. With this function, the IKE negotiation will not authenticate the UDP port number. At the same time, traversal enables NAT gateway discovery on the VPN Tunnel. If a NAT gateway is discovered, UDP encapsulation will be used in the subsequent IPSec data transmission, (i.e., encapsulating IPSec 5-2

112 Manual VPN Chapter 5 IKE Configuration packets in the UDP connection Tunnel for IKE negotiation), to prevent the NAT GW from modifying the IPSec packets. That is, the NAT GW can only change the outermost IP and UDP headers but leave the IPSec packets encapsulated in the UDP packets intact, thus ensuring integrity of the IPSec packets. The encryption/decryption/authentication process of IPSec data requires the IPSec packets reaching the destination to remain intact. Currently only the aggressive mode supports NAT traversal (the main mode does not support NAT traversal). Usually the two features described above are used together in the ADSL + IPSec networking to solve the problems resulting from dynamic IP addresses on broadband-access enterprise networks and NAT traversal on a public network. The combination of these two features provides a secure solution to access to enterprise networks through ADSL instead of in leased line mode Preparation for IKE Configuration Prior to IKE configuration, you need to specify following items, so as to smooth the configuration process: Determine algorithm strength for IKE exchange, i.e., security protection strength (including identity authentication method, encryption algorithm, and authentication algorithm, DH algorithm). The algorithm strength is different. The higher strength the algorithm has, the harder it is to decrypt the protected data, but more calculation resources will be consumed. Generally, the longer the shared key is, the higher the algorithm strength is. Determine the identity authentication key of both sides in communication. 5.2 IKE Configuration Introduction to IKE Configuration IKE configuration includes: 1) Set a name for the local SecBlade 2) Define IKE proposal Establish IKE Proposal Select encryption algorithm Select authentication method Select authentication algorithm Select Diffie-Hellman group ID Set lifetime of ISAKMP SA (optional) 3) Configure IKE peer Create an IKE peer Configure IKE negotiation mode Configure identity authentication key (pre-shared key) Configure ID type in IKE negotiation 5-3

113 Manual VPN Chapter 5 IKE Configuration Configure IP address in IKE negotiation Configure NAT traversal Configure subnet type of the IKE peer 4) Configure the parameters of Keepalive timer Configure interval for Keepalive transmission Configure timeout time for Keepalive Setting a Name for the Local Security GW If the initiator uses the gateway name in IKE negotiation (that is, id-type name is used), you must configure the ike local-name command on the local device. Perform the following configuration in system view. Table 5-1 Configure name of the local security GW Configure the name of the local SecBlade Restore the default name of the local SecBlade ike local-name name undo ike local-name Defining IKE Proposal I. Establishing IKE proposal An IKE proposal defines a set of attributes describing how IKE negotiation conducts secure communications. Configuring an IKE proposal includes the tasks of IKE proposal creation, selection in encryption algorithm, authentication mode, authentication algorithm, and Diffie-Hellman group ID, and SA lifetime setting. The user may create multiple IKE proposals on the basis of precedence, but the negotiation parties should have at least one matched IKE proposal in order to reach an agreement. This configuration is used to define an IKE proposal. The IKE proposal configured is used to establish a security tunnel. Perform the following configuration in system view. Table 5-2 Establish IKE proposal Create IKE proposal Delete IKE proposal ike proposal proposal-number undo ike proposal proposal-number 5-4

114 Manual VPN Chapter 5 IKE Configuration Execute the ike proposal command to enter IKE proposal view, where you can configure an encryption algorithm, authentication algorithm, Diffie-Hellman group ID, SA lifetime, and authentication method. The proposal-number argument is the IKE proposal number, ranging from 1 to 100. This parameter also stands for the priority. A smaller number stands for a higher priority. You can create multiple IKE proposals for each end of the negotiation. A same proposal between both ends in the negotiation will be matched from the one with the highest priority. Successful matching complies with the principle below: Both ends must have the same encryption and authentication algorithm, some authentication method and Diffie-Hellman group ID. The system provides a default IKE proposal, which has the lowest priority and has the default encryption algorithm, authentication algorithm, Diffie-Hellman group ID, SA lifetime, and authentication method. The parameters needed by an IKE proposal are as follows. II. Selecting encryption algorithm This configuration is used to specify an encryption algorithm used by an IKE proposal. Perform the following configuration in IKE proposal view. Table 5-3 Select encryption algorithm Select an encryption algorithm Set the encryption algorithm to the default value encryption-algorithm { des-cbc 3des-cbc } undo encryption-algorithm By default, the 56-bit DES algorithm in CBC mode is adopted. III. Selecting authentication method This configuration is used to specify an authentication method used by an IKE proposal. IKE authentication has two algorithms: pre-share-key and PKI (rsa-signature). Perform the following configuration in IKE proposal view. Table 5-4 Specify authentication method Specify authentication method authentication-method { pre-share rsa-signature } 5-5

115 Manual VPN Chapter 5 IKE Configuration Restore the authentication method to the default value undo authentication-method By default, the pre-share key algorithm is adopted. Note: For details on PKI configuration, refer to PKI Configuration in this manual. During IKE negotiation, id-type and remote-name configured in an IKE Peer do not take effect if the initiator uses the rsa-signature mode for authentication. Instead, the responder only selects an IKE peer according to remote-address contained in the IKE peer. Therefore, both the initiator and the responder must specify remote-address if the rsa-signature mode is used for authentication. Otherwise, all addresses will be matched by default. IV. Selecting authentication algorithm This configuration is used to specify the authentication algorithm used by an IKE proposal. Perform the following configuration in IKE proposal view. Table 5-5 Select authentication algorithm Select an authentication algorithm authentication-algorithm { md5 sha } Set the authentication algorithm to the default value undo authentication-algorithm By default, the SHA-1 authentication algorithm is adopted. V. Selecting Diffie-Hellman group ID This configuration is used to specify the Diffie-Hellman group ID used by an IKE proposal. Perform the following configuration in IKE proposal view. Table 5-6 Select Diffie-Hellman group ID Select Diffie-Hellman group ID dh { group1 group2 group5 group14 } 5-6

116 Manual VPN Chapter 5 IKE Configuration Restore the default value of Diffie-Hellman group ID undo dh By default, the 768-bit Diffie-Hellman group (group 1) is selected. VI. Configuring lifetime of ISAKMP SA (optional) This configuration is used to specify the lifetime of ISAKMP SA used by an IKE proposal. Perform the following configuration in IKE proposal view. Table 5-7 Set lifetime of IKE SA Configure lifetime of IKE SA Restore the default lifetime sa duration seconds undo sa duration If sa duration expires, the ISAKMP SA will automatically be updated. The SA lifetime can be set as one number between 60 and 604,800 seconds. Because IKE negotiation needs DH calculation, which will take a long period. In order that the update of ISAKMP SAs does not affect secure communication, it is recommended to set the sa duration to a value greater than 10 minutes. An SA will negotiate another one to replace the old SA before the set SA lifetime expires. The old SA will be cleared automatically when the SA lifetime expires. By default, the ISAKMP SA duration is 86,400 seconds (one day) Configuring IKE Peer I. Creating an IKE peer Perform the following configuration in system view. Table 5-8 Configure IKE peer Configure an IKE peer and access IKE peer view Delete the IKE peer ike peer peer-name undo ike peer peer-name II. Configuring IKE negotiation mode Perform the following configuration in IKE-peer view. 5-7

117 Manual VPN Chapter 5 IKE Configuration Table 5-9 Configure negotiation mode Configure an IKE negotiation mode exchange-mode { aggressive main } Restore the default IKE negotiation mode undo exchange-mode By default, the main mode is adopted. Note: If the IP address of one end of a security Tunnel is dynamic, you must adopt the aggressive mode for IKE negotiation. After accepting a negotiation request from the initiator by using a policy template, the responder end selects the negotiation mode according to the negotiation mode of the initiator. III. Configuring pre-shared key Perform the following configuration in IKE-peer view. Table 5-10 Configure pre-shared key Configure a pre-shared key for IKE negotiation Remove the pre-shared key used in IKE negotiation pre-shared-key key undo pre-shared-key IV. Configuring ID type in IKE negotiation Perform the following configuration in IKE-peer view. Table 5-11 Configure ID type in IKE negotiation Select an ID type in the IKE negotiation id-type { ip name } Restore the default ID type in the IKE negotiation undo id-type By default, the IP address is taken as the ID in IKE negotiation. In main mode, only the IP address can be taken as the ID in IKE negotiation. In aggressive mode, however, you may use either the IP address or name as the ID in IKE negotiation. 5-8

118 Manual VPN Chapter 5 IKE Configuration V. Specifying name of the remote device If the initiator uses its gateway name in IKE negotiation (that is, id-type name is used), it sends the name to the peer as its identity, whereas the peer uses the username configured using the remote-name name command to authenticate the initiator. To pass authentication, this remote name must be the same as one configured using the ike local-name command on the gateway at the initiator end. Perform the following configuration in IKE-peer view. Table 5-12 Specify name of the remote device Specify the name of a remote device Remove the name of the remote device remote-name name undo remote-name VI. Configuring IP addresses of the local SecBlade and remote device If the initiator uses its IP address in IKE negotiation (that is, id-type ip is used), it sends its IP address to the peer as its identity, whereas the peer uses the remote-address ip-address command to authenticate the initiator. If the responder is only configured with low-ip-address, low-ip-address must be consistent with the IP address in the initiator configured using the local-address command. If the responder is configured with both low-ip-address and high-ip-address, that is, configured with an address range, the address range must include the IP address in the initiator configured using the local-address command. The initiator of IKE negotiation cannot configure remote-address as an address range. Table 5-13 Configure IP addresses of the local SecBlade and remote device Configure IP address of the local SecBlade Delete IP address of the local SecBlade Configure IP address of the remote device Delete the IP address of the remote device local-address ip-address undo local-address remote-address low-ip-address high-ip-address undo remote-address Generally speaking, you do not need to configure the local-address command unless you want to specify a special address for the local gateway (such as the address of a loopback interface). 5-9

119 Manual VPN Chapter 5 IKE Configuration VII. Configuring NAT traversal The NAT traversal function must be configured so long as there is a NAT IPSec device on a VPN Tunnel built using IPSec/IKE. Perform the following configuration in IKE-peer view. Table 5-14 Configure the NAT traversal function of IPSec/IKE Enable the NAT traversal function of IPSec/IKE Disable the NAT traversal function of IPSec/IKE nat-traversal undo nat-traversal To save IP address space, ISPs often add NAT gateways to public networks, so as to allocate private IP addresses to users. This may lead to an IPSec/IKE Tunnel having a public network address and a private network address at both ends respectively. Hence you must enable NAT traversal at both ends of the Tunnel, so as to ensure normal negotiation and establishment for the Tunnel. VIII. Configuring subnet type of the IKE peer You can use these two commands only when your SecBlade is interoperable with a NETSCREEN device. Perform the following configuration in IKE-peer view: Table 5-15 Configure subnet type of the IKE peer Configure subnet type of the local gateway Restore the default subnet type of the local gateway Configure subnet type of the peer gateway Restore the default subnet type of the peer gateway local { multi-subnet single-subnet } undo local peer { multi-subnet single-subnet } undo peer By default, the subnet type of both the local end and the remote end is single-subnet Configuring Keepalive Timer I. Configuring keepalive interval Configure the interval at which an ISAKMP SA transmits a Keepalive packet to the peer. Perform the following configuration in system view. 5-10

120 Manual VPN Chapter 5 IKE Configuration Table 5-16 Configure the interval for Keepalive packet transmission Configure the interval at which an ISAKMP SA transmits a Keepalive packet to the peer Disable the above function ike sa keepalive-timer interval seconds undo ike sa keepalive-timer interval IKE will maintain the link state of the ISAKMP SA through this packet. Generally, if the peer has used the ike sa keepalive-timer timeout command to configure a timeout time, this Keepalive interval must be configured at local end. When the configured timeout time expires: The ISAKMP SA of the peer will be marked with TIMEOUT (if not available in the ISAKMP SA of the peer), and the TIMEOUT mark will be removed if the peer receives a keepalive packet from the local end at the expiry of the keepalive-timer time. The ISAKMP SA and corresponding IPSec SA will be removed if the ISAKMP SA of the peer is marked with TIMEOUT (indicating that the peer does not receive a keepalive packet at the expiry of the timeout time). Therefore, the configured timeout time should be longer than the Keepalive packet transmission interval. By default, this function is disabled. II. Configuring keepalive timeout time Configure a timeout time for ISAKMP SA waiting for Keepalive packets. Perform the following configuration in system view. Table 5-17 Configure timeout time for waiting for Keepalive packets Configure ISAKMP SA timeout time for waiting for Keepalive packet Disable this function ike sa keepalive-timer timeout seconds undo ike sa keepalive-timer timeout IKE maintains this ISAKMP SA link status through this packet. When the configured timeout time expires: The ISAKMP SA of the peer will be marked with TIMEOUT (if not available in the ISAKMP SA of the peer), and the TIMEOUT mark will be removed if the peer receives a keepalive packet from the local end at the expiry of the keepalive-timer time. 5-11

121 Manual VPN Chapter 5 IKE Configuration The ISAKMP SA and corresponding IPSec SA will be removed if the ISAKMP SA is marked with TIMEOUT (indicating that the peer does not receive a keepalive packet at the expiry of the timeout time). Therefore, the configured timeout time should be longer than the Keepalive packet transmission interval. On a network, packet loss will rarely occur more than 3 times, so the timeout time can be configured to be 3 times as long as the Keepalive packet transmission interval of the peer. By default, this function is disabled. III. Configuring NAT Keepalive sending interval Perform the following configuration in system view. Table 5-18 Configure Keepalive sending interval Define the interval at which the IKE peer sends NAT Keepalive packets Restore the default NAT Keepalive interval ike sa nat-keepalive-timer interval seconds undo ike sa nat-keepalive-timer interval The default NAT Keepalive interval is 20 seconds. A NAT Keepalive packet is an unencrypted packet that is encapsulated using UDP. The NAT gateway sends NAT Keepalive packets to maintain dynamic mapping between IKE peers, but not to check the status of the peers. When defining the time interval, ensure that the interval is less than the timeout time for NAT. 5.3 Displaying and Debugging IKE After the above configuration, execute display commands in all views to display the running of the IKE configuration, and to verify the effect of the configuration. Execute the debugging and reset commands in user view. Table 5-19 Display and debug IKE Display the current established security tunnel Display the parameters of each IKE proposal display ike sa [ verbose [ connection-id id remote-address ip-address ] ] display ike proposal Display the configuration of IKE peers display ike peer [ peer-name ] 5-12

122 Manual VPN Chapter 5 IKE Configuration Delete a security tunnel reset ike sa [ connection-id ] Enable information debugging of IKE Disable information debugging of IKE debugging ike { all error exchange message misc transport } undo debugging ike { all error exchange message misc transport } You can delete a specified security tunnel by specifying SA connection-id, which can be displayed by executing the display ike sa command. So far as the same security tunnel (that is, the same remote end) is concerned, the connection-id information includes the information at stage 1 and the information at stage 2. If the ISAKMP SA at stage 1 still exists when you delete the local SA, the system will send the DELETE message under the protection of the ISAKMP SA to notify the peer to clear the SA database. If no connection-id is specified, all the SAs at stage 1 will be removed. A security tunnel and SA are totally different concepts. A security tunnel is a channel through which its two endpoints can make bidirectional communications, but an IPSec SA is just a unidirectional connection. In other words, a security tunnel comprises a pair or several pairs of SAs. 5.4 IKE Troubleshooting When configuring parameters to establish an IPSec security tunnel, you can enable Error debugging of IKE to find configuration problems. The command is as follows: <H3C> debugging ike error Symptom 1: Invalid user ID information Troubleshooting: User ID is the data that the user initiating the IPSec communication uses to identify itself. In practice, you can make use of user ID to set up different security tunnels for various types of data traffic for the sake of protection. In the implementation of h3c, a user is identified by its IP address. Following is the debugging information you may view on the screen: got NOTIFY of type INVALID_ID_INFORMATION Or drop message from A.B.C.D due to notification type INVALID_ID_INFORMATION Check whether the ACLs of the IPSec policies configured on the interfaces at both ends of the negotiation are compatible. You are recommended to configure the ACLs to mirror each other. For more information about ACL mirror, refer to the section Configure ACL in IPSec Configuration. 5-13

123 Manual VPN Chapter 5 IKE Configuration Symptom 2: Proposal mismatch Troubleshooting: Following is the debugging information you may view on the screen: got NOTIFY of type NO_PROPOSAL_CHOSEN Or drop message from A.B.C.D due to notification type NO_PROPOSAL_CHOSEN The two parties of the negotiation have no matched proposal. For the negotiation at stage 1, you can look up the IKE proposals for a match. For the negotiation at stage 2, you can check whether the parameters of the IPSec polices applied on the interfaces are matched, and whether the referenced IPSec proposals have a match in the protocol, encryption and authentication algorithms. Symptom 3: Unable to establish a security tunnel Troubleshooting: Check whether the network is stable and the security tunnel is established correctly. Sometimes there is a security tunnel but there is no way to communicate, and ACLs of both parties are correctly configured, and there is also a matched policy. In this case, the problem is usually cased by the restart of one tunnel end after a security tunnel is established. Solution: Use the command display ike sa to check whether both parties have established an SA of Phase 1. Use the command display ipsec sa to check whether the IPSec policy on an interface has established an IPSec SA. If the above two results show that one party has an SA but the other does not, then use the reset ike sa command to clear the SA with errors and re-originate negotiation. 5-14

124 Manual VPN Chapter 6 PKI Configuration Chapter 6 PKI Configuration 6.1 PKI Overview Introduction Public key infrastructure (PKI) is a system that uses the public key technology and digital certificates to protect system security and authenticates digital certificate holders. It provides a whole set of security mechanisms by combining software/hardware systems and security policies together. PKI uses certificates to manage public keys: It binds user public keys with other identifying information through a trustworthy institution, so that online authentication is possible. PKI provides a secure network environment and enables easy use of encryption and digital signature technologies in many application environments, to assure confidentiality, integrity and validity of online data. Confidentiality of data means that data cannot be snooped about by unauthorized users during transmission; integrity of data means that data cannot be altered illegally during transmission; the validity of data means that data cannot be denied. A PKI system consists of a public key algorithm, certificate authority, registration authority, digital certificate, and PKI repository. PKI application Digital certificate CA RA PKI repository Figure 6-1 PKI components block diagram The certificate authority issues and manages certificates. The registration authority authenticates user identity and manages certificate revocation list. PKI repository stores and manages such information as certificates and logs, and provides query function. The digital certificate, also called Public Key Certificate (PKC), underlies the security of PKI system and the trust in application. Adopting an authentication technology based on public key technology, it is a file duly signed by the certificate authority that contains public key and owner information. It can be used as an identity proof for online information exchange and commercial activities. A certificate has its lifetime, which is specified at the time of issuing. Of course, the certificate authority can revoke a certificate before its expiration date. 6-1

125 Manual VPN Chapter 6 PKI Configuration Terminology Public key algorithm: Key algorithm that involves different encryption key and decryption key. A pair of keys is generated for each user: One is publicized as a public key; the other is reserved as a private key. The information encrypted by one key has to be decrypted by the other; the key pair therefore is generally used in signature and encryption. In communication, if the sender signs information using its private key, the receiver needs to authenticate this signature using the sender s public key. If the sender encrypts the information using the receiver s public key, then only the receiver s private is capable of decryption. Certificate authority (CA): Trustworthy entity issuing certificates to individuals, PCs or any other entities. The CA deals with certificate requests, and checks applicant information according to the certificate management policy. Then it signs the certificate using its private key and issues the certificate. Registration authority (RA): Extension of CA. It forwards the entities' certificate requests to the CA, and digital certificates and certificate revocation list to the directory server, for directory browsing and query. Light-weight directory access protocol (LDAP) server: LDAP provides a means to access the PKI repository, for the purpose of accessing and managing PKI information. LDAP server supports directory browsing and enlists the user information and digital certificates from an RA server. Then the user can get his or others certificates when accessing the LDAP server. Certificate revocation list (CRL): A certificate has its lifetime, but the CA can revoke a certificate before its expiration date if the private key leaks or if the service ends. Once a certificate is revoked, a CRL is released to announce its invalidity, and lists a set of serial numbers of invalid certificates. A CRL, stored in LDAP server, provides an effective way to check the validity of certificates, and offers centralized management of user notification and other applications Applications PKI includes a set of security services provided using the technologies of public key and X.509 certification in distributed computing systems. It can issue certificates for various purposes, such as Web user identity authentication, Web server identity authentication, secure using secure/multipurpose Internet mail extensions (S/MIME), VPN, IP Security, IKE, and secure sockets layer/transport layer security (SSL/TLS). One CA can issue certificates to another CA, to establish a certificate hierarchy Configuration Task List PKI configuration includes applying to a CA for a local certificate for a designated device and checking validity of the certificate. The configuration involves: 6-2

126 Manual VPN Chapter 6 PKI Configuration PKI certificate request PKI certificate validation Display and debug 6.2 Certificate Request Configuration Certificate Request Overview Certificate request is a process when an entity introduces itself to a CA. The identity information the entity provides will be contained in the certificate issued subsequently. A CA uses a set of criteria to review the applicant s credit standing, request purpose and identity authenticity, to ensure that certificates are bound to correct identities. Offline and non-auto out-of-band (phone, storage disk and , for example) identity authentication may be required in this process. If this process goes smooth, the CA issues a certificate to the user and displays it along with some public information on the LDAP server for directory browsing. The user can then download its own public-key digital certificate from the notified position, and obtain those of others through the LDAP server. The request process proceeds as follows: Entering PKI domain view Specifying a trustworthy CA Configuring servers for certificate request Configuring entity name space Creating a local public/private key pair Setting request polling interval and count Configuring certificate request mode Making a certificate request manually Obtaining a certificate Entering PKI Domain View A PKI domain manages in a unified way a group of PKI users who trust the same third trustworthy organization. That is, it suffices with the trust each member lays on a CA; no trust between group members is required. It serves a lot in relieving system load and extending the PKI certificate system. For the configuration of domain parameters, you should enter PKI domain view. Perform the following configuration in system view. Table 6-1 Enter PKI domain view Specify a PKI domain and enter a designated PKI domain view pki domain name 6-3

127 Manual VPN Chapter 6 PKI Configuration Delete a designated PKI domain and its relative information undo pki domain name By default, no PKI domain is specified. Note: Currently, one device supports only one PKI domain; therefore, if two PKI domains exist and you wan to add a new one, you need to use the corresponding undo command to delete an existing one first Specifying a Trustworthy CA When an entity applies for a certificate, a trustworthy CA which provides guarantee for the entity registers and issues the certificate. A trustworthy CA is the base for PKI. Only when a CA trusted by everyone is available, can users enjoy the security services provided by the public key technology. Perform the following configuration in PKI domain view. Table 6-2 Specify trustworthy CA Specify a trustworthy CA Delete the trustworthy CA ca identifier name undo ca identifier By default, no trustworthy CA is specified. Note: A suit of standards that a CA uses in request processing, certificate issuing and revoking, and CRL releasing are called a CA policy. In general, a CA uses files, called certification practice statements (CPS), to advertise its policy. A CA policy can be obtained in out-of-band or other mode. You are recommended to understand CA policies before choosing a CA, for different CAs may use different methods to authenticate the binding between a public key and entity. 6-4

128 Manual VPN Chapter 6 PKI Configuration Configuring Servers for Certificate Request I. Configuring the entity used to apply for a certificate When you send a certificate request to the CA, an entity name must be specified to indicate you identity. Perform the following configurations in PKI domain view. Table 6-3 Configure the entity used to apply for a certificate Configure the entity used to apply for a certificate Cancel the configured entity used to apply for a certificate certificate request entity entity-name undo certificate request entity By default, no entity is specified to apply for a certificate. Note: For more information about entities (entity-name), see Configuring Entity Name Space. II. Specifying a registration organization Registration management is often implemented by an independent registration authority (RA), which is responsible for coping with certificate request, examining entity qualification and allowing a CA whether or not to issue the digital certificate. It does not issue the certificate, as is performed by a CA. Instead, it just exams the qualification of the users. Sometimes no independent RA is set. It does not mean that the registration function of PKI is disabled, because the CA takes over the registration management function. Perform the following configuration in PKI domain view. Table 6-4 Specify a registration organization Choose q registration organization certificate request from { ca ra } Delete the registration organization undo certificate request from By default, no registration organization is specified. 6-5

129 Manual VPN Chapter 6 PKI Configuration The PKI IPSec policy recommends using an RA as the registration organization. Note: For details about the entity-name argument, refer to Configuring Entity Name Space. III. Configuring registration server location The registration server location (i.e., URL) needs to be specified. Then entities can apply to this server for a certificate using simple certification enrollment protocol (SCEP), a protocol used to communicate with a CA. Perform the following configuration in PKI domain view. Table 6-5 Specify registration server location Specify the location of a registration server Delete the location setting certificate request url string undo certificate request url By default, no registration server location is specified. IV. Configuring the IP address of the LDAP server In the PKI system, it is a core problem to store the user certificates and CRLs. Generally, an LDAP directory server is used to distribute certificates and CRLs. Perform the following configuration in PKI domain view. Table 6-6 Specify the IP address of the LDAP server Specify the IP address of the LDAP server Delete the IP address of the LDAP server ldap-server ip ip-address [ port port-num ] [ version version-number ] undo ldap-server By default, no IP address or port is specified for the LDAP server. Currently it is LDAP version 2. V. Configuring fingerprint for root certificate authentication When the SecBlade obtains an identity certificate from the CA, it will need the CA root certificate to make sure that the identity certificate is true and legal. In addition, when the SecBlade obtains the CA root certificate, it needs to verify its fingerprint, that is, 6-6

130 Manual VPN Chapter 6 PKI Configuration the hash value of the root certificate content, which is unique to each certificate. If the fingerprint is different from that configured using the command below, the SecBlade denies the root certificate. The fingerprint can be an MD5 or SHA1 footprint. Perform the following configurations in PKI domain view. Table 6-7 Configure the fingerprint for root certificate authentication Configure the fingerprint for root certificate authentication Cancel the configured fingerprint for root certificate authentication root-certificate fingerprint { md5 sha1 } string undo root-certificate fingerprint By default, no fingerprint is configured for root certificate authentication. When an MD5 fingerprint is adopted, the string argument must contain 32 hexadecimal characters. When an SHA1 fingerprint is adopted, the string argument must contain 40 hexadecimal characters Configuring Entity Name Space I. Name space overview Entity name space should be taken into account when PKI is set up. In a certificate, the public key and owner name must be consistent. Each CA details an entity using the information it considers important. A unique identifier (also called DN-distinguished name) can be used to identify an entity. It consists of several parts, such as user general name, organization, country and owner name. It must be unique in the network. Perform the following configurations in PLI entity view: PKI entity name Entity FQDN Country code State name Geographic locality Organization name Organization name General name of the entity IP address of the entity 6-7

131 Manual VPN Chapter 6 PKI Configuration Note: Entity configuration information must comply with the CA certificate issue policy to determine the DN configuration tasks, for example, in determining required and optional parameters. Otherwise, the certificate request may be rejected. II. Specifying a PKI entity name In PKI entity view, you can configure the attributes of an entity DN. Perform the following configuration in system view. Table 6-8 Specify an entity name Specify an entity name and enter the entity view Delete the entity name and relative parameters pki entity name-str undo pki entity name-str By default, no entity name is given. Note: The entity name must be consistent with the entity-name argument specified by the registration organization in the certificate request entity-name command. Otherwise, the certificate request fails. The name-str argument is just for the convenience of referencing, and is not used as a certificate field. III. Configuring the entity FQDN Fully qualified domain name (FQDN) is the unique identifier of an entity in the network, for example, address. It is often in the format of user.domain and can be resolved to an IP address. Functionally, an FQDN is equivalent to an IP address. This configuration is optional. Perform the following configuration in PKI entity view. Table 6-9 Configure the entity FQDN Configure the entity FQDN Delete the entity FQDN fqdn name-str undo fqdn 6-8

132 Manual VPN Chapter 6 PKI Configuration By default, no FQDN is configured for the entity. IV. Configuring the country code for the entity Perform the following configuration in PKI entity view. Table 6-10 Configure the country code for the entity Configure the country code for the entity Delete the country code for the entity country country-code-str undo country By default, no country code is specified for the entity. Note: The country code uses two standard characters, for example, CN for China and US for the United States. V. Configuring the state name for the entity Perform the following configuration in PKI entity view. Table 6-11 Configure the state name for the entity Configure the state name for the entity Delete the state name for the entity state state-str undo state By default, no state name is specified for the entity. VI. Configuring the geographic locality for the entity Perform the following configuration in PKI entity view. Table 6-12 Configure the geographic locality for the entity Configure the geographic locality for the entity Delete the geographical locality for the entity locality locality-str undo locality By default, no geographic locality is specified for the entity. 6-9

133 Manual VPN Chapter 6 PKI Configuration VII. Configuring the organization name for the entity Perform the following configuration in PKI entity view. Table 6-13 Configure the organization name for the entity Configure the organization name for the entity Delete the organization name for the entity organization org-str undo organization By default, no organization name is specified for the entity. VIII. Configuring the organizational unit name for the entity This optional field specifies to which units of an organization this entity belongs. Perform the following configuration in PKI entity view. Table 6-14 Configure the organizational unit name for the entity Configure the organizational unit name for the entity Delete the organizational unit name for the entity organization-unit org-unit-str undo organization-unit By default, no organizational unit name is specified for the entity. IX. Configuring the general name for the entity Perform the following configuration in PKI entity view. Table 6-15 Configure the common name for the entity Configure the general name for the entity Delete the general name for the entity common-name name-str undo common-name By default, no general name is specified for the entity. X. Configuring the IP address for the entity Like the function of specifying the entity FQDN, this function is optional. Perform the following configuration in PKI entity view. 6-10

134 Manual VPN Chapter 6 PKI Configuration Table 6-16 Configure the IP address for the entity Configure the IP address for the entity Delete the IP address for the entity ip ip-address undo ip By default, no IP address is specified for the entity Creating a Public and Private Key Pair A pair of keys are generated during a certificate request: one public and the other private. The private key is held by the user, and the public key and other information are transferred to the CA center for signature and then the generation of the certificate. Each CA certificate has a lifetime that is determined by the CA issuing certificates. When the private key leaks or the current certificate is about to expire, you have to delete the old key pair. Another key pair can be generated for a new certificate. This configuration is used to generate local key pairs. If an RSA key pair already exists, the system prompts you whether to replace it. The naming mode of key pairs: SecBlade name + host. The minimum length of a host key is 512 digits and the maximum length is 2,048 digits. Perform the following configuration in system view. Table 6-17 Create and destroy an RSA key pair Create a local RSA key pair Destroy a local RSA key pair rsa local-key-pair create rsa local-key-pair destroy By default, there is no existing local RSA key pair. You have to create an RSA key pair by yourself. 6-11

135 Manual VPN Chapter 6 PKI Configuration Caution: If a local certificate already exists, you are not recommended to create another key pair in order to keep the key consistent with the existing certificate. You should first delete the existing certificate and then create a new key pair. If a local RSA key pair exists, the newly-generated key pair will overwrite the existing one. The key pairs are originally for the use in SSH. The local server regularly updates the local server key pair. However, the host key pair used in a certificate request remains unchanged Configuring Polling Interval and Count If a CA examines a certificate request in manual mode, then a long time may be required before the certificate is issued. In this period, you need to query the request status periodically, so that you may obtain the certificate right after it is issued. Perform the following configuration in PKI domain view. Table 6-18 Configure polling interval and count Configure polling interval and count Restore the default values certificate request polling { interval minutes count count } undo certificate request polling { interval count } By default, a request polling message is sent for 50 times at an interval of 20 minutes Configuring Certificate Request Mode The request mode can be manual or auto. Auto mode enables the automatic request for a certificate through SCEP when there is none and for a new one when the old one is about to expire. For manual mode, all the related operations need to be carried out manually. Perform the following configuration in PKI domain view. 6-12

136 Manual VPN Chapter 6 PKI Configuration Table 6-19 Configure certificate request mode Configure certificate request mode Restore the default request mode certificate request mode { manual auto [ key-length key-length password { simple cipher } password ]* } undo certificate request mode By default, the manual mode is selected Making a Certificate Request Manually A complete certificate request comprises a user public key and other registered information. When all the configuration above is completed, you can deliver the certificate request to a PKI RA. Perform the following configuration in system view. Table 6-20 Deliver a certificate request Make a certificate request pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ] Caution: If a local certificate already exists, you should delete it and all the CA certificates locally stored using the pki delete certificate command first before applying for another one. Otherwise, inconsistency between the certificate and registered information may occur. If you cannot send a certificate request to CA using SCEP, you can select the pem keyword to print out the request information, copy it and send one to CA in out-of-band mode. Before you deliver a certificate request, make sure the clocks of the entity and CA are synchronous. Otherwise, a fault occurs to the certificate validation period. If you use a Windows CA server to obtain a certificate, the RA identifier (also known as DN-distinguished name) and the CA identifier must be different from each other when you install the Windows CA server; otherwise, no CA certificate or local certificate will be obtained. This operation will not be saved in the configuration. 6-13

137 Manual VPN Chapter 6 PKI Configuration Retrieving a Certificate Manually Certificate retrieval has two purposes: store locally the certificates related to the local security domain to improve the query efficiency and reduce the times of query request for PKI repository; prepare for the certificate authentication. When downloading a digital certificate, select the local keyword for a local certificate and ca keyword for a CA certificate. Perform the following configuration in system view. Table 6-21 Retrieve a certificate Retrieve a certificate and download it locally pki retrieval-certificate { local ca } domain domain-name Caution: If a CA certificate already exists, you should delete it and all the local certificates using the pki delete certificate command before retrieving another one. Otherwise, inconsistency between the certificate and the registered information may occur. This operation will not be saved in the configuration Importing Certificates You can import existing a local certificate or CA certificate using the commands below. Perform the following configuration in system view. Table 6-22 Import a certificate Import a certificate pki import-certificate { local ca } domain domain-name { der p12 pem } [ filename filename ] Deleting Certificates You can delete an existing local certificate or CA certificate using the command below. Perform the following configuration in system view. 6-14

138 Manual VPN Chapter 6 PKI Configuration Table 6-23 Delete a certificate Delete a certificate pki delete-certificate { local ca } domain domain-name 6.3 Certificate Authentication Configuration Configuration Task List At every stage of data communication, parties should verify the validity of corresponding certificates, including issue time, issuer and certificate validity. The core is to verify the signature of a CA and to make sure the certificate is still valid. It is believed that a CA never issues fake certificates, so every certificate with an authentic CA signature will pass the verification. For example, if you receive an , which contains a certificate with a public key and is encrypted with a private key, then you should verify the validity of this certificate, to determine whether it is valid and trustworthy. For certificate validation, you need to: Specify CRL distribution point location Configure CRL update interval Enable/Disable CRL check Retrieve CRL Verify certificate validity Specifying CRL Distribution Point location Perform the following configuration in PKI domain view. Table 6-24 Configure CRL distribution point location Specify CRL distribution point location crl url { url-string scep } Delete the location setting undo crl url By default, no CRL distribution point location is specified Configuring CRL Update Period The CRL update interval refers to the interval at which the CRL is downloaded from the CRL storage server. Perform the following configuration in PKI domain view. 6-15

139 Manual VPN Chapter 6 PKI Configuration Table 6-25 Configure CRL update period Specify CRL update interval Restore the default interval crl update-period hours undo crl update-period By default, CRLs are updated according to their validity period. Note: The CRL update interval configured here takes priority of that specified in CRLs Enabling/Disabling CRL Check CRL check is optional for certificate authentication. If it is enabled, you must check CRLs to decide on the certificate validity. The authentication can be carried out directly in CA center or locally with CRLs downloaded. Perform the following configuration in PKI domain view Table 6-26 Enable/disable CRL check Disable CRL check Enable CRL check crl check disable undo crl check disable By default, CRL check is enabled Retrieving a CRL Having finished the above configuration tasks, you can retrieve a CRL in any view. The purpose of downloading CRL is to verify the validity of the certificates on a local device. Perform the following configuration in system view. Table 6-27 Retrieve a CRL Retrieve a CRL and download it locally pki retrieval-crl domain domain-name 6-16

140 Manual VPN Chapter 6 PKI Configuration Note: This operation will not be saved in configuration Verifying Certificate Validity You can verify the validity of a local certificate using the local keyword; or a CA certificate using the ca keyword. Perform the following configuration in system view. Table 6-28 Verify certificate validity Verify the validity of a local certificate pki validate certificate { local ca } domain domain-name Note: This operation will not be saved in configuration. 6.4 Displaying and Debugging I. Displaying certificates If certificate retrieval succeeds, you can display the fields of the certificates locally downloaded. Certificate format and fields comply with X.509 standard. All kinds of identifying information about a user and CA are included, such as user address; public key of the certificate holder; issuer, serial number, and validity (period) of the certificate. Perform the following configuration in any view. Table 6-29 Display certificates Displaying certificates display pki certificate { { local ca } domain domain-name request-status } II. Displaying CRL The fields of a CRL that is retrieved and locally downloaded can be displayed by the following operation. The CRL complies with X.509 standard, and contains the 6-17

141 Manual VPN Chapter 6 PKI Configuration following information: version, signature (algorithm), issuer name, this update, next update, user public key, signature value, serial number, and revocation date. Perform the following configuration in any view. Table 6-30 Display CRLs Displaying CRLs display pki crl domain domain-name III. Displaying and debugging configuration Using the display current-configuration command, you can view current PKI configuration. You can enable PKI debugging to monitor and diagnose relevant certificate implementation. Perform the following configuration in user view. Table 6-31 Display and debug PKI information Enable PKI debugging Disable PKI debugging debugging pki { all verify request retrieval error } undo debugging pki { all verify request retrieval error } By default, all types of PKI debugging are disabled. 6.5 PKI Configuration Example IKE Authentication Using PKI Certificate I. Network requirements The IKE automatic negotiation mode is used to create a security association on the SecBlade. The IKE authentication policy uses the PKI certificate system to authenticate identities. 6-18

142 Manual VPN Chapter 6 PKI Configuration II. Network diagram /24 VLAN 30 VLAN /24 SecBlade /24 VLAN / /24 Switch VLAN 10 Internet Router Trust Zone /24 RA LDAP CA Figure 6-2 Network diagram for IKE authentication using PKI certificate III. Configuration procedure H3C (SecBlade) # Divide into VLANs. <H3C> system-view [H3C] vlan 10 [H3C-vlan10] quit [H3C] vlan 30 [H3C-vlan30] quit [H3C] vlan 50 [H3C-vlan50] quit # Configure the IP address. [H3C] interface vlan-interface 10 [H3C-Vlan-interface10] ip address [H3C-Vlan-interface10] quit [H3C] interface vlan-interface 30 [H3C-Vlan-interface30] ip address [H3C-Vlan-interface30] quit # Configure the static route. [H3C] ip route-static # Configure aggregation of SecBlade interfaces (the SecBlade card resides in slot 2). [H3C] secblade aggregation slot

143 Manual VPN Chapter 6 PKI Configuration # Create SecBlade module test. [H3C] secblade module test # Specify a SecBlade interface VLAN. [H3C-secblade-test] secblade-interface vlan-interface 30 # Set the protected VLAN. [H3C-secblade-test] security-vlan 50 # Map the SecBlade module to the SecBlade card of the specified slot. [H3C-secblade-test] map to slot 2 [H3C-secblade-test] quit [H3C] quit # Log into the SecBlade card of the specified slot. <H3C> secblade slot 2 (Both the default user name and password are SecBlade) Username:SecBlade Password:SecBlade <SecBlade> system-view # Create the sub-interface. [SecBlade] interface GigabitEthernet 0/0.1 [SecBlade-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade-GigabitEthernet0/0.1] ip address [SecBlade-GigabitEthernet0/0.1] quit [SecBlade] interface GigabitEthernet 0/0.2 [SecBlade-GigabitEthernet0/0.2] vlan-type dot1q vid 50 [SecBlade-GigabitEthernet0/0.2] ip address [SecBlade-GigabitEthernet0/0.2] quit # Configure the static route. [SecBlade] ip route-static [SecBlade] ip route-static # Use the default IKE policy on the SecBlade and configure PKI (rsa-signature) algorithm for identity authentication. [SecBlade_VPN] ike proposal 1 [SecBlade_VPN-ike-proposal-1] authentication-method rsa-signature [SecBlade_VPN-ike-proposal-1] quit # Configure parameters for the PKI domain. [SecBlade_VPN] pki domain 1 [SecBlade_VPN-pki-domain-1] ca identifier CA [SecBlade_VPN-pki-domain-1] certificate request url [SecBlade_VPN-pki-domain-1] certificate request from ra entity en 6-20

144 Manual VPN Chapter 6 PKI Configuration [SecBlade_VPN-pki-domain-1] ldap-server ip # Specify CRL distribution point location (you need not specify it if CRL check is disabled). [SecBlade_VPN-pki-domain-1] crl url ldap:// # Configure the entity DN. [SecBlade_VPN] pki entity en [SecBlade_VPN-pki-entity-en] ip [SecBlade_VPN-pki-entity-en] common-name SecBlade # Use the RSA algorithm to generate the local key pair. [SecBlade_VPN-pki-entity-en] rsa local-key-pair create # Apply for a certificate. [SecBlade_VPN-pki-entity-en] pki retrieval certificate ca domain 1 [SecBlade_VPN-pki-entity-en] pki request certificate 1 Note: The above section describes IKE negotiation configuration with a PKI certificate. To establish an IPSec security tunnel for secure communication, you need to configure IPSec. For details, refer to IPSec Configuration. 6.6 Troubleshooting Certificates Symptom 1: Failure to retrieve certificates Solution: The following reasons may cause failure to make CA certificate requests manually; 1) Software No trustworthy CA name is set. The URL of the registration server is wrong or not configured. You can use the ping command to test the server s connectivity. No RA is specified. 2) Hardware Check whether there is something wrong with the network connection, for example, the cable is broken or the connectors are loose. 6-21

145 Manual VPN Chapter 6 PKI Configuration Symptom 2: Failure to Apply for Local Certificates Solution: The following reasons may cause the failure to send manual certificate requests after you configure PKI domain parameters and entity DN for the SecBlade and create new RSA key pairs. 1) Software You do not have CA/RA certificates before certificate requests. No key pair is created or the current key pair has already had its certificate. No trustworthy CA name is specified. The URL of the registration server is wrong or not configured. You can use the ping command to test the server s connectivity. No RA is specified. The required attributes for the entity DN are not configured. You can select the related attributes through checking the CA/RA registration policy and then configure them. 2) Hardware Check whether there is something wrong with the network connection, for example, the cable is broken or the connectors are loose Symptom 3: Failure to Retrieve CRL Solution: The following reasons may cause failure to retrieve CRLs. 1) Software You do no have local certificates before retrieving CRL. The IP address of the LDAP server is not set. The CRL distribution point location is not specified. The version of LDAP server is wrong. 2) Hardware Check whether there is something wrong with the network connection, for example, the cable is broken or the connectors are loose. 6-22

146 Manual VPN Chapter 7 DVPN Chapter 7 DVPN 7.1 Introduction to DVPN Overview The dynamic virtual private network (DVPN) technology is a kind of technology that establishes VPNs by dynamically acquiring the information about the peers. DVPN adopts an NBMA-type Tunnel mechanism, which enables devices to encapsulate and transmit packets with Tunnel interfaces as the end points of DPVN Tunnels and enables devices to learn routes of private networks through Tunnel interfaces dynamically. (NBMA: non-broadcast multiple access) The DVPN technology also adopts a client-server model to overcome the drawbacks that the traditional VPN technology suffers from. By registering with a server, clients store their information on the server. So a registered client can then acquire information about other registered clients through the redirecting function the server provides to establish separate sessions with corresponding clients. By registering with the same server, multiple DVPN-enabled access devices can form a DVPN domain to have VPNs connected to these access devices interconnected Basic DVPN Elements I. DVPN domain A set of private networks and the devices in them that are interconnected using DVPN. II. DVPN access device Routers or SecBlades in a network that are used to form a DVPN. Any router or SecBlade that supports the DVPN technology can be a DVPN access device. III. DVPN Server The DVPN access device that operates as the server in a DVPN domain. DVPN access devices must register with the DVPN server before they can access a DVPN domain. IV. DVPN Client The DVPN access device that operates as a client in a DVPN domain. A device must successfully register with the DVPN server to access a DVPN domain. 7-1

147 Manual VPN Chapter 7 DVPN V. DVPN ID Identifier of a DVPN domain. For a DVPN access device, different DVPN domains have different DVPN IDs. VI. Map Channel established between a DVPN client and a DVPN server when the DVPN client attempts to register with the DVPN server. A map remains after the client successfully registers with the DVPN server until the DVPN client exits the DVPN domain or the network. VII. Session DVPN Tunnel for data transmission. In a DVPN domain, sessions are established between pairs of DVPN access devices and are used to connect private networks. Packets in a DVPN domain are transmitted through sessions. VIII. Redirect Redirecting mechanism. For two clients with no session established, data between them is forwarded by the DVPN server. When forwarding packets between these two clients, the DVPN server sends redirecting packets to the source client if the DVPN server determines a separate session can be established between the two clients. Redirecting packets contain information about the destination clients. IX. Active side and passive side The two sides of a session determine an active side and a passive side through negotiation. For a session established between a client and a server, the client operates as the active side and the server operates as the passive side. If a session is established between two clients, the one that initiates the session is the active side and the other is the passive side Implementation The DVPN protocol runs between DVPN access devices. The DVPN server holds information about all successfully registered clients, and the clients hold information about all sessions they establish, such as the private IP addresses of destination devices (the IP addresses of Tunnel interfaces), the public IP addresses of destination devices (the IP addresses of WAN interfaces), the UDP port numbers of the destination devices (when employing UDP), and the identifiers of session state. The following section briefly describes the interaction between servers and clients. 7-2

148 Manual VPN Chapter 7 DVPN I. Register After a client is configured with proper interface properties and the server address, and its interfaces are up, the client negotiates with the DVPN server about the algorithm, key, authentication (optional), information registering, and policy issuing. Register negotiations are carried out through maps established between the clients and the servers. A map remains after the client registers and accesses the DVPN domain. It is removed only when the client exits the DVPN domain. If you remove a map through which a client registers, the client releases all resources it occupies (including all sessions it establishes) and resumes the initial state. Figure 7-1 demonstrates the registering workflow. Any error during the workflow results in abort of the registering and causes the client to resume the initial state. Client Server (1) (2) (3) (4) (5) (6) (7) (8) Figure 7-1 DVPN registering workflow 1) The client sends an algorithm negotiation request to the server. 2) The server sends an algorithm negotiation response to the client. 3) The client sends a key negotiation request and server authentication request to the server. 4) The server sends key negotiation response, client authentication, and server authentication response to the client. 5) The client sends authentication messages to the server. 6) The server sends the authentication result to the client. 7) The client sends register request messages to the server, where all information about the client is included. 8) The server sends a register response to the client. The response contains the following information: data encrypting policies, key, and the ID of the DVPN. II. Establishing session Upon successfully registered, a client establishes a session with the DVPN server immediately to transmit its packets using DVPN. 7-3

149 Manual VPN Chapter 7 DVPN If the packets the server receives are destined for another node in the VPN instead of the local private network, the server forwards the packets and sends next hop redirecting messages to the source client to inform it of the information about the next hop. The client then sends session Setup requests to the peer client to negotiate with it about establishing a separate session and about the IPSec SA. After the session is established, the two clients can communicate with each other without the server. When removing a session, the server checks whether it is created by a registered map. If the map does not exist, the session is removed directly. Otherwise, you need to remove the corresponding map first Basic Network Structure DVPN works in Client/Server mode. Among all the access devices in a DVPN domain, only one can be the server and uses a fixed public IP address, whereas others operate as clients. You need to configure information about the server manually on each client to enable the clients to register with the server. A session is automatically established between a client and the server after the client successfully registers with the server. By sending redirecting packets, the server can provide information about other clients for a client to enable sessions being established between clients, through which the DVPN domain can be fully connected. When transmitted in a DVPN domain, DVPN packets are encapsulated using UDP, that is, DVPN control packets and other DVPN packets to be forwarded are encapsulated using UDP. As UDP packets are capable of traversing NAT gateways, sessions can be established between DVPN clients even though they use private IP addresses. Server Session Session Internet Client Session Client Figure 7-2 Basic structure of DVPN 7-4

150 Manual VPN Chapter 7 DVPN Traditional VPN Versus DVPN I. Drawbacks of traditional VPN Current network solutions commonly use generic routing encapsulation (GRE) or multi-protocol label switching/border gateway protocol (MPLS/BGP) to form Layer 3 VPNs. Both of the two kinds of VPNs encounter the following drawbacks: Complicated in networking and configuration. Layer 3 VPNs communicate through point-to-point Tunnels. So, to form a fully connected VPN with the number of access points of N, the number of point-to-point VPN Tunnels to be manually configured is N (N-1) / 2. Poor in maintenance and scalability. For an established VPN, you must reconfigure all other nodes if you add a node to the VPN or reconfigure an existing node in the VPN, which results in high maintaining cost. Unable to traverse NAT gateways. For VPN Tunnels that are established using GRE and with network address port translation (NAPT) gateways deployed at the egresses, you must map each private IP address to a unique public IP address to transmit packets along the VPN Tunnel. So a large number of public IP addresses are needed for this kind of VPNs. So GRE is not applicable in NAT gateways. (VPNs that are established using early versions of IPSec cannot traverse NAT gateways either. This problem is resolved by encapsulating IPSec packets in UDP packets.) Not applicable for dynamic IP addresses. VPN Tunnels that are established using GRE are based on fixed IP addresses. So you cannot establish VPNs for dial-up subscribers using GRE. Not secure. Layer 2 tunnel protocol (L2TP) and GRE do not encrypt packets. However, IPSec provides satisfactory security for packets forwarded across IPSec VPNs. IPSec does not support dynamical routes. VPN Tunnels that are established using GRE and L2TP are interface-based, whereas those that are established using IPSec are data stream-oriented. Therefore, route learning is not possible between these two kinds of private networks interconnected through IPSec VPN Tunnels, thereby causing some troubles to dynamic network planning. II. Advantages of DVPN DVPN has all advantages of traditional VPN. It also overcomes lot of problems that traditional VPN faces. It provides an easy way to configure and plan networks and is more powerful. It is more suitable for modern and future networks. It features the following: Ease of configuration. Instead of configuring logic interfaces as the Tunnel ends for each Tunnel, only one logic Tunnel interface is needed for a DVPN access device to establish sessions with multiple other DVPN access devices, which simplifies DVPN configuration remarkably and improves maintainability and 7-5

151 Manual VPN Chapter 7 DVPN scalability. To add a private network to an existing DVPN domain, you need only to configure information about the DVPN server of the DVPN domain on the DVPN access device of the private network. Capable of NAT traversal. UDP-encapsulated DVPN packets are capable of traversing NAT gateways. This enables VPN connections to be established between internal network DVPN access devices and public network DVPN access devices and enables VPNs that contain both internal private networks and external private networks to be established. Capable of establishing dynamic IP address-based VPN. You need only to provide the IP address of the DVPN server to establish a Tunnel in a DVPN domain. So DVPN is suitable for subscribers that use dynamic IP addresses, such as dial-up and xdsl. Capable of establishing Tunnels automatically. A DVPN server maintains information about all DVPN access devices in the DVPN domain. The redirecting function enables the DVPN clients to acquire information about any other DVPN clients in the DVPN domain from the DVPN server to establish sessions. A DVPN client is only needed to be configured with information about itself and the DVPN server, so the work load of network administration can be remarkably eased. Encrypted registration. When registering with a DVPN server, a client first negotiates with the server about the algorithm suite and keys, and then encrypts the key registering information (such as user name and password) using the negotiated algorithm. They can also check the validity of the registering packets to secure the key registering information. Authentication. When registering with a DVPN server, a client can authenticate the server using a pre-shared-key to make sure the DVPN server is valid. The DVPN server, in turn, can authenticate the clients that want to access the DVPN domain using AAA to ensure DVPN clients are authenticated. Centralized policy management. Policies applied to sessions in a DVPN domain are the same. A DVPN server issues the policy of the DVPN domain to each registered client, including the algorithm suite used in session negotiations, the keepalive time of sessions, the idle timeout time of sessions, the IPSec encryption algorithm, and the renegotiation time of IPSec SA. Encryption during session negotiation. In the course of session negotiation, all the control packets are IPSec-encrypted using the algorithm suite the DVPN server issues. The client negotiates with the DVPN server about the IPSec SA of the session using the encryption and authentication algorithm issued by the DVPN server. DH (Diffie-Hellman) is used for negotiating the key of the IPSec SA. The data to be encrypted and transmitted through this session is encrypted using the IPSec SA negotiated in the course of the session establishment and then is transmitted through the DVPN domain. The IPSec SA of a session can be renegotiated. You can specify an IPSec SA renegotiation interval to improve security. 7-6

152 Manual VPN Chapter 7 DVPN Support for multiple DVPN domains. A single DVPN device can support multiple DVPN domains. That is, a device can belong to both DVPN domain A and DVPN domain B simultaneously, and a DVPN device can be a client in DVPN domain A and the DVPN server in DVPN domain B at the same time. A DVPN device can support up to 200 DVPN domains and can be the DVPN server of up to 200 DVPN domains. This improves network flexibility remarkably and protects user investment efficiently, and enables you to make full use of network device resources. When multiple DVPN domains are configured on one DVPN device, you can isolate these DVPN domains using private network routes. Support for dynamic routes. In a DVPN domain, route packets that need to be transmitted through Tunnel interfaces can be broadcast over all sessions to enable route learning in DVPN domains. In conjunction with dynamic routing protocols, DVPN can simplify planning of private networks that are to access a DVPN domain and the configuration of the entire network, improve network maintainability and automaticity. 7.2 DVPN Configuration DVPN configuration comprises client configuration and server configuration. I. Client configuration For DVPN clients, you need to perform basic configuration, Tunnel interface configuration, and DVPN class configuration. 1) Basic configuration Basic configuration includes the following: Enable/Disable DVPN Configure the client registration interval Configure the registering retries Configure the dumb interval 2) Tunnel interface configuration Tunnel interface configuration includes the following: Configure the packet encapsulation format (UDP DVPN) Configure the Tunnel interface to client type Configure the source address or source interface of the Tunnel interface Configure the DVPN class to be applied to the Tunnel interface Configure the DVPN domain the Tunnel interface belongs to Configure register type (optional) Configure IPSec-encrypted data stream 3) DVPN class configuration 7-7

153 Manual VPN Chapter 7 DVPN DVPN class configuration refers to configuring parameters that are necessary for a client to register with a DVPN server and providing information used in negotiation in a DVPN class view. It includes the following: Create a DVPN class and enter its view Assign a public IP address to the DVPN server Assign a private IP address to the DVPN server (optional) Configure the register algorithm suite (optional. The default registering algorithm suite is DES-MD5-DH1.) Specify how the client authenticates the DVPN server (optional. NONE by default) Configure the pre-shared-key used when the client authenticates the DVPN server (optional) Configure user information used when the client registers with the DVPN server (optional) II. DVPN server configuration For a DVPN server, you need to perform basic configuration, Tunnel interface configuration, and DVPN policy suite configuration (DVPN policies are configured in DVPN policy views), which are described as follows. 1) Basic configuration Basic configuration includes the following: Enable/Disable DVPN Configure the map aging interval Configure how to authenticate the clients Configure the pre-shared-key 2) Tunnel interface configuration Tunnel interface configuration includes the following: Configure the packet encapsulation format (UDP DVPN) Configure the Tunnel interface to server Configure the DVPN domain the Tunnel interface belongs to Configure the source address or source interface of the Tunnel interface Configure the DVPN policy the Tunnel interface uses (optional) Configure IPSec-encrypted data stream 3) DVPN policy suite configuration DVPN policy suite configuration includes the following: Create a DVPN policy and enter DVPN policy view Configure how the DVPN server authenticates the clients (optional and is NONE by default) Configure the algorithm suite for a specified session (optional and is des-md5-dh1 by default) 7-8

154 Manual VPN Chapter 7 DVPN Configure the idle timeout time for a specified session (optional and is 300 seconds by default) Configure the interval for sending keepalive packets (optional and is 10 seconds by default) Configure the interval for sending requests to establish a session (optional and is 10 seconds by default) Configure the IPSec algorithm suite (optional and is des-md5-dh1 by default) Configure the timeout time for renegotiating a specified IPSec SA (optional and is 3,600 seconds by default) To correspond to the configurations mentioned above, following sections describe how to configure DVPN in terms of basic configuration, Tunnel interface configuration, DVPN class configuration, and DVPN policy configuration Basic DVPN Configuration I. Enabling/Disabling DVPN Perform these operations to enable/disable DVPN. If you disable DVPN on a DVPN server, the existing DVPN sessions are removed after they time out. Perform the following configuration in system view on a client or a DVPN server. Table 7-1 Enable/Disable DVPN Enable DVPN Disable DVPN dvpn service enable dvpn service disable DVPN is disabled by default. II. Configuring the pre-shared-key Perform these operations to configure/remove authentication information (pre-shared-key) on a DVPN server. If a client authenticates the server using a pre-shared-key, it specifies the pre-shared-key of the DVPN server. The specified pre-shared-key must be identical with the one the DVPN server owns. Perform the following configuration in system view on a DVPN server. Table 7-2 Configure the pre-shared-key for a DVPN server Configure a pre-shared-key Remove a pre-shared-key dvpn server pre-shared-key key undo dvpn server pre-shared-key 7-9

155 Manual VPN Chapter 7 DVPN Pre-shared-keys are not configured by default. III. Configuring how to authenticate a client At present, password authentication protocol (PAP), challenge authentication protocol (CHAP) and NONE are available for a DVPN server to authenticate a clients that attempt to access the DVPN domain. After you perform this operation to specify how a DVPN server authenticates a client, a DVPN server authenticates clients in the specified way if no DVPN policy is configured. Perform the following configuration in system view on a DVPN server. Table 7-3 Configure how to authenticate a client Configure how to authenticate a client dvpn server authentication-client method { none { chap pap } [ domain isp-name ] } A DVPN server does not authenticate clients by default. IV. Configuring the map aging interval If a map is not registered successfully, you can remove the map by configuring a map aging interval on the server. If a client is registered successfully, a map can coexist with the created session. Perform the following configuration in system view. Table 7-4 Configure the map age time Configure the map age interval Revert the map age interval to the default dvpn server map age-time time undo dvpn server map age-time The default map age interval is 30 seconds. V. Configuring the interval for client registration If a client fails to register with a DVPN server, it registers with the DVPN server again after a specified interval. You can configure the register interval on a client. Perform the following configuration in system view on a client. 7-10

156 Manual VPN Chapter 7 DVPN Table 7-5 Configure the interval for client registration Configure the interval for client registration Restore the default registration interval for the client dvpn client register-interval time-interval undo dvpn client register-interval The default registration interval is 10 seconds. VI. Configuring the register retries for a client A client enters a dumb state if it fails to register with a DVPN server for specified times. You can configure the maximum retries during a register round by performing this operation. Perform the following configuration in system view on a client. Table 7-6 Configure the registering retries for a client Configure the registration retries for the client Restore the default register retries for the client dvpn client register-retry times undo dvpn client register-retry The default number of registration retries for the client is 3. VII. Configuring the dumb interval for a client A client in dumb state registers with the DVPN server again after a specified interval. You can specify the interval by performing this operation. Perform the following configuration in system view on a client. Table 7-7 Configure the dumb interval for a client Configure the dumb interval for the client Restore the default dumb interval for the client dvpn client register-dumb time undo dvpn client register-dumb The default dumb interval for the client is 300 seconds. 7-11

157 Manual VPN Chapter 7 DVPN Configuring the Tunnel Interface I. Configuring the encapsulation format Before configuring other DVPN parameters, be sure to encapsulate UDP DVPN on the Tunnel interface. Perform the following configuration in Tunnel interface view on a client or a DVPN server. Table 7-8 Configure the encapsulation format Configure the encapsulation format on the Tunnel interface Tunnel-protocol udp dvpn By default, the encapsulation format is GRE. II. Configuring the type of the Tunnel interface Configure the Tunnel interface as server or client type according to its location (server side or client side). Perform the following configuration in Tunnel interface view on a client or a DVPN server. Table 7-9 Configure the type of the Tunnel interface Configure the type of the Tunnel interface Restore the default type of Tunnel interfaces dvpn interface-type { client server } undo dvpn interface-type A Tunnel interface is of client type by default. III. Configuring registration type for a DVPN client You can only use the dvpn register-type command on a client. When registering with the server, the client can ask the server to forward the data packet from this client and notify the server not to advertise the registering information about this client to other clients. Perform the following configuration in Tunnel interface view on the client. 7-12

158 Manual VPN Chapter 7 DVPN Table 7-10 Configure registration type for a DVPN client Configure registration type for the DVPN client Remove the configuration dvpn register-type { forward undistributed } * undo dvpn register-type { forward undistributed } * By default, the register type for the DVPN client is not configured. IV. Configuring the DVPN domain the Tunnel interface belongs to You can configure the ID of the DVPN domain the Tunnel interface belongs to by performing this operation. (Tunnel interfaces that belong to the same DVPN domain have the same DVPN ID.) Perform the following configuration in Tunnel interface view on a client or a DVPN server. Table 7-11 Configure the DVPN domain the Tunnel interface belongs to Configure the DVPN domain the Tunnel interface belongs to Restore the Tunnel interface to the default dvpn dvpn-id dvpn-id undo dvpn dvpn-id By default, a Tunnel interface is not configured with a DVPN ID. V. Configuring the source end address of the Tunnel interface The source address or source interface refers to address of the interface DVPN packets source from. The source end address along with the destination address, which must be configured on both the server end and the client end respectively, uniquely identifies a Tunnel. The two addresses are source and destination addresses mutually. Perform the following configuration in Tunnel interface view on a client or a DVPN server. Table 7-12 Configure the source end address of the Tunnel interface Configure the source end address or source interface of the Tunnel interface source { ip-address interface-type interface-number } 7-13

159 Manual VPN Chapter 7 DVPN Remove the source end address or the source interface of the Tunnel interface undo source VI. Configuring the DVPN class to be applied to the Tunnel interface (client side only) After configuring the DVPN server in DVPN class view on the client side, perform the following operations to apply the DVPN class. Perform the following configuration in Tunnel interface view on the client side. Table 7-13 Configure/Remove the DVPN class to be applied to the Tunnel interface Configure the DVPN class to be applied to the Tunnel interface Remove the DVPN class applied to the Tunnel interface dvpn server dvpn-class-name undo dvpn server dvpn-class-name A Tunnel interface does not have a DVPN class applied by default. VII. Configuring the DVPN policy to be applied to the Tunnel interface After configuring the policy in DVPN policy view on the server side, perform the following operations to apply it to the DVPN domain. Perform the following configuration in Tunnel interface view on the server side. Table 7-14 Configure/Remove the DVPN policy to be applied to the Tunnel interface Configure the DVPN policy to be applied to the Tunnel interface Remove the DVPN policy applied to the Tunnel interface dvpn policy dvpn-policy-name undo dvpn policy dvpn-policy-name A Tunnel interface does not have a DVPN policy applied by default. VIII. Configuring IPSec-encrypted data stream Packets forwarded in a DVPN domain are processed by using the corresponding ACL. The packets matching an ACL will be encrypted by IPSec, while others will not. Perform the following configuration in Tunnel interface view. 7-14

160 Manual VPN Chapter 7 DVPN Table 7-15 Configure IPSec-encrypted data stream Configure the IPSec-encrypted data stream Remove the IPSec-encrypted data stream dvpn security acl acl-number undo dvpn security acl No IPSec-encrypted data stream is configured on the Tunnel interface by default Configuring a DVPN class After configuring parameters of a specified DVPN server used for clients to register with the DVPN server in DVPN class view (such as private IP address, public IP address, and user name), you need to perform corresponding configuration on the client side. The configuration must be consistent with that on the sever side. I. Creating a DVPN class and enter its view You can create a DVPN class and enter its view, or remove an existing DVPN class by performing the following operations. A DVPN class that is in use cannot be removed. Perform the following configuration in system view. Table 7-16 Create/Remove a DVPN class Create a DVPN class and enter its view Remove a DVPN class dvpn class dvpn-class-name undo dvpn class dvpn-class-name No DVPN class is configured by default. II. Assigning a public IP address to a DVPN server The IP address here refers to the fixed public IP address assigned to the DVPN server. Perform the following configuration in DVPN class view. Table 7-17 Assign a public IP address to the DVPN server Assign a public IP address to the DVPN server Remove a public IP address public-ip ip-address undo public-ip A DVPN server is not assigned a public IP address by default. 7-15

161 Manual VPN Chapter 7 DVPN III. Assigning a private IP address to a DVPN server The IP address here refers to the IP address of the Tunnel interface through which the DVPN server accesses a DVPN domain. Perform the following configuration in DVPN class view. Table 7-18 Assign a private IP address to a DVPN server Assign a private IP address to a DVPN server Remove the private IP address private-ip ip-address undo private-ip A DVPN server is not assigned a private IP address by default. IV. Configuring a register algorithm suite DVPN registration control packets must be encrypted for security. The encryption algorithm, authentication algorithm, and key negotiation algorithm are determined by the registration algorithm suite. Perform the following configuration in DVPN class view. Table 7-19 Configure the register algorithm suite Configure the register algorithm suite Restore the default register algorithm suite algorithm-suite suite-number undo algorithm-suite By default, the suite-number parameter is 1, that is, DES-MD5-GROUP1. Refer to Manual for the meanings of other values. V. Specifying how the client authenticates the DVPN server A client can authenticate the DVPN server to be accessed using a pre-shared-key. Perform the following configuration in DVPN class view. Table 7-20 Specify how the client authenticates the DVPN server Specify to authenticate the DVPN server using the pre-shared-key Specify not to authenticate the DVPN server authentication-server method pre-share authentication-server method none A client does not authenticate a DVPN server by default. 7-16

162 Manual VPN Chapter 7 DVPN VI. Configuring a pre-shared-key for authenticating a DVPN server Configure a pre-shared-key on a client for authenticating the server to be accessed. The configured pre-shared-key must be consistent with that of the server to be accessed. Perform the following configuration in DVPN class view. Table 7-21 Configure a pre-shared-key for authenticating a DVPN server Configure a pre-shared-key for a authenticating DVPN server Remove the configured pre-shared-key pre-shared-key key undo pre-shared-key A DVPN server is not configured with a pre-shared-key by default. VII. Configuring the user name and password for a client User names and passwords are used when clients register with DVPN servers. You must configure the user name and password in DVPN class view for a client if it is to register with a DVPN server that authenticates registering clients. Perform the following configuration in DVPN class view. Table 7-22 Configure the user name and password for a client Configure the user name and password for a client Remove the user name and password of a client local-user username password { simple cipher } password undo local-user A client is not configured with a user name and password by default Configuring a DVPN policy Parameters about a DVPN policy, such as session algorithm, IPSec algorithm for data, time parameters, are configured in DVPN policy view. A DVPN server sends DVPN policies applied in the DVPN domain to clients that successfully register with it. I. Creating a DVPN policy view You can create a DVPN policy and enter DVPN policy view, or remove an existing DVPN policy by performing the following operations. To remove a DVPN policy that is applied in a DVPN domain, you must disable it first. Perform the following configuration in system view. 7-17

163 Manual VPN Chapter 7 DVPN Table 7-23 Create a DVPN policy Create a DVPN policy and enter its view Remove a DVPN policy dvpn policy dvpn-policy-name undo dvpn policy dvpn-policy-name No DVPN policy is configured by default. II. Configuring how a DVPN server authenticates clients You can configure a DVPN server to authenticate clients that are to access the DVPN domain. At present, the supported authentication modes include PAP, CHAP, and None. Perform the following configuration in DVPN policy view. Table 7-24 Configure how a DVPN server authenticates clients Configure how a DVPN server authenticates clients authentication-client method { none { chap pap } [ domain isp-name ] } A DVPN server does not authenticate clients by default. III. Configuring the encryption algorithm suite for a session You can apply DES, 3DES, and AES encryption algorithms, MD5 and SHA1 authentication algorithms, and DH-GROUP1 and DH-GROUP2 key negotiation algorithms to control packets transmitted during DVPN session negotiation by performing the following operations. Perform the following configuration in DVPN policy view. Table 7-25 Configure the encryption algorithm suite for a session Configure the encryption algorithm suite for a session Restore the default encryption algorithm suite session algorithm-suite suite-number undo session algorithm-suite The suite-number parameter is 1 by default, which stands for DES (for encryption), MD5 (for authentication) and DH-GROUP1 (for key negotiation). 7-18

164 Manual VPN Chapter 7 DVPN IV. Configuring the idle timeout time for a session A session is torn down if receiving no packet during a specified interval known as the idle timeout time. Perform the following configuration in DVPN policy view. Table 7-26 Configure the idle time out time for a session Configure the idle timeout time for a session Restore the default idle time out time session idle-time time-interval undo session idle-time The default idle timeout time is 300 seconds. V. Configuring the interval for sending keepalive packets After a session is established, the active side sends keepalive packets regularly to check the connection state of the session if no packet passes through the session. Perform the following configuration in DVPN policy view. Table 7-27 Configure the interval for sending keepalive packets Configure the interval for sending keepalive packets Restore the default interval for sending keepalive packets session keepalive-interval time-interval undo session keepalive-interval The default interval for sending keepalive packets is 10 seconds. VI. Configuring the interval for sending requests to establish a session If a session is not successfully established, the initiator sends a request again to try to establish the session after a specific interval. The initiator fails to establish a session if the session is not established after the initiator sends three successive requests. Perform the following configuration in DVPN policy view. Table 7-28 Configure the interval for sending requests to establish a session Configure the interval for sending requests to establish a session Restore the default interval for sending requests to establish a session session setup-interval time-interval undo session setup-interval 7-19

165 Manual VPN Chapter 7 DVPN The default interval for sending requests to establish a session is 10 seconds. VII. Configuring the IPSec algorithm suite Packets transmitted in a DVPN domain are encrypted by IPSec. At present, DES, 3DES, and AES encryption algorithms and MD5, SHA1 authentication algorithms are available. You can specify the algorithm suite used when an IPSec SA forwards packets by performing the following operations. Perform the following configuration in DVPN policy view. Table 7-29 Configure the IPSec algorithm suite Configure the IPSec algorithm suite Restore the default IPSec algorithm suite data algorithm-suite suite-number undo data algorithm-suite The suite-number parameter is 1 by default, which stands for DES (for encryption) and MD5 (for authentication). VIII. Configuring the timeout time to renegotiate a specified IPSec SA Perform the following configuration in DVPN policy view. Table 7-30 Configure the time out time to renegotiate a specified IPSec SA Configure the timeout time to renegotiate a specified IPSec SA Restore the default timeout time to renegotiate a specified IPSec SA data ipsec-sa duration time-based time-interval undo data ipsec-sa duration time-based The default timeout time to renegotiate a specified IPSec SA is 3,600 seconds Displaying and Debugging DVPN Execute the display command in any view to display how DVPN operates. Execute the reset command in user view to clear sessions, maps, statistics information, or initiate a DVPN domain. Execute the debugging command in user view to debug DVPN. 7-20

166 Manual VPN Chapter 7 DVPN Table 7-31 Display and debug DVPN Enable/Disable debugging for DVPN Display global information about DVPN in a system or information about a DVPN domain Display information about maps in a DVPN domain Display information about sessions in a DVPN domain Display information about IPSec SAs in a DVPN domain Display information about online DVPN users Initiate a DVPN domain Clear a specified map Clear a specified session Clear DVPN statistics [ undo ] debugging dvpn { all error event { all register session misc } hexadecimal packet { all control data ipsec } } display dvpn info { dvpn-id dvpn-id global } display dvpn map { all dvpn-id dvpn-id public-ip public-ip } display dvpn session { all dvpn-id dvpn-id [ private-ip private-ip ] } display dvpn ipsec-sa { all dvpn-id dvpn-id [ private-ip private-ip ] } display dvpn online-user reset dvpn all dvpn-id reset dvpn map public-ip port [ control-id ] reset dvpn session dvpn-id private-ip reset dvpn statistics Note: If you wan to use a new policy after changing the dvpn policy, you must reboot the SecBlade or the shutdown/undo shutdown Tunnel interface. The new policy cannot be used by using the reset command. 7.3 DVPN Configuration Example I. Network requirements As Figure 7-3 shows, Branch A and Branch B establish DVPN connections with the headquarters respectively. Detailed requirements are as follows: Use the default algorithm suite (algorithm suite 1) for registration and sessions, that is, use DES for encryption, MD5 for authentication, and DH-GROUP1 for key negotiation. 7-21

167 Manual VPN Chapter 7 DVPN Data is IPSec-encrypted for security using algorithm suite 6. That is, use 3DES for encryption, MD5 for authentication, and DH-GROUP2 for key negotiation. Note: After a session is established between a server and client 1 and client 2, transmitted data is IPSec-encrypted using algorithm suite 1 by default. That is, use DES for encryption, MD5 for authentication, and DH-GROUP1 for key negotiation. II. Network diagram VLAN 70: /24 Server Headquarter /24 VLAN /24 VLAN /24 SecBlade A Tunnel0: / /24 Switch A g0/0.2: /24 Internet Tunnel0: /24 Tunnel0: /24 Client 1 g0/0.2: /24 g0/0.2: /24 Client /24 VLAN / /24 VLAN /24 VLAN / /24 SecBlade A Switch A VLAN 10: /24 VLAN / /24 Switch B SecBlade B VLAN 20: /24 Branch A Branch B VLAN 10: /24 VLAN 20: /24 Figure 7-3 Network diagram for DVPN III. Configuration procedure 1) Configure a server 7-22

168 Manual VPN Chapter 7 DVPN Switch (SecBlade) # Divide into VLANs. <H3C> system-view [H3C] vlan 70 [H3C-vlan70] quit [H3C] vlan 80 [H3C-vlan80] quit [H3C] vlan 90 [H3C-vlan90] quit # Configure the IP address. [H3C] interface vlan-interface 70 [H3C-Vlan-interface70] ip address [H3C-Vlan-interface70] quit [H3C] interface vlan-interface 80 [H3C-Vlan-interface80] ip address [H3C-Vlan-interface80] quit # Configure the static route. [H3C] ip route-static # Configure aggregation of SecBlade interfaces (SecBlade slot number is 2). [H3C] secblade aggregation slot 2 # Create SecBlade module test. [H3C] secblade module test # Specify the SecBlade interface VLAN. [H3C-secblade-test] secblade-interface vlan-interface 80 # Set the protected VLAN. [H3C-secblade-test] security-vlan 90 # Map the SecBlade module to the SecBlade card of the specified slot. [H3C-secblade-test] map to slot 2 [H3C-secblade-test] quit [H3C] quit # Log into the SecBlade card of the specified slot. <H3C> secblade slot 2 (Both user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade_Srv> system-view # Create the sub-interface. [SecBlade_Srv] interface GigabitEthernet 0/

169 Manual VPN Chapter 7 DVPN [SecBlade_Srv-GigabitEthernet0/0.1] vlan-type dot1q vid 80 [SecBlade_Srv-GigabitEthernet0/0.1] ip address [SecBlade_Srv-GigabitEthernet0/0.1] quit [SecBlade_Srv] interface GigabitEthernet 0/0.2 [SecBlade_Srv-GigabitEthernet0/0.2] vlan-type dot1q vid 90 [SecBlade_Srv-GigabitEthernet0/0.2] ip address [SecBlade_Srv-GigabitEthernet0/0.2] quit # Configure a static route. [SecBlade_Srv] ip route-static # Enable the DVPN function. [SecBlade_Srv] dvpn service enable # Create a DVPN policy and configure IPSec algorithm-suite as 5. [SecBlade_Srv] dvpn policy 1 [SecBlade_Srv-dvpn-policy-1] data algorithm-suite 5 # Configure Tunnel 0 interface. [SecBlade_Srv] interface Tunnel 0 [SecBlade_Srv-Tunnel0] Tunnel-protocol udp dvpn [SecBlade_Srv-Tunnel0] dvpn interface-type server [SecBlade_Srv-Tunnel0] ip address [SecBlade_Srv-Tunnel0] source GigabitEthernet0/0.2 [SecBlade_Srv-Tunnel0] dvpn dvpn-id 1 [SecBlade_Srv-Tunnel0] dvpn policy 1 [SecBlade_Srv-Tunnel0] quit # Configure route information. [SecBlade_Srv] ip route-static [SecBlade_Srv] ip route-static ) Configure client 1 Switch (SecBlade) # Divide into VLANs. <H3C> system-view [H3C] vlan 10 [H3C-vlan10] quit [H3C] vlan 30 [H3C-vlan30] quit [H3C] vlan 50 [H3C-vlan50] quit # Configure the IP address. [H3C] interface vlan-interface 10 [H3C-Vlan-interface10] ip address

170 Manual VPN Chapter 7 DVPN [H3C-Vlan-interface10] quit [H3C] interface vlan-interface 30 [H3C-Vlan-interface30] ip address [H3C-Vlan-interface30] quit # Configure the static route. [H3C] ip route-static # Configure aggregation of SecBlade interfaces (SecBlade slot number is 2). [H3C] secblade aggregation slot 2 # Create SecBlade module test. [H3C] secblade module test # Specify the SecBlade interface VLAN. [H3C-secblade-test] secblade-interface vlan-interface 30 # Set the protected VLAN. [H3C-secblade-test] security-vlan 50 # Map the SecBlade module to the SecBlade card of the specified slot. [H3C-secblade-test] map to slot 2 [H3C-secblade-test] quit [H3C] quit # Log into the SecBlade card of the specified slot. <H3C> secblade slot 2 (Both user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade_Clnt1> system-view # Create a sub-interface. [SecBlade_Clnt1] interface GigabitEthernet 0/0.1 [SecBlade_Clnt1-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade_Clnt1-GigabitEthernet0/0.1] ip address [SecBlade_Clnt1-GigabitEthernet0/0.1] quit [SecBlade_Clnt1] interface GigabitEthernet 0/0.2 [SecBlade_Clnt1-GigabitEthernet0/0.2] vlan-type dot1q vid 50 [SecBlade_Clnt1-GigabitEthernet0/0.2] ip address [SecBlade_Clnt1-GigabitEthernet0/0.2] quit # Configure a static route. [SecBlade_Clnt1] ip route-static # Enable the DVPN function. [SecBlade_Clnt1] dvpn service enable # Configure dvpn-class. 7-25

171 Manual VPN Chapter 7 DVPN [SecBlade_Clnt1] dvpn class testserver [SecBlade_Clnt1-dvpn-class-testserver] public-ip [SecBlade_Clnt1-dvpn-class-testserver] quit # Configure attributes for Tunnel 0 interface. [SecBlade_Clnt1] interface Tunnel 0 [SecBlade_Clnt1-Tunnel0] ip address [SecBlade_Clnt1-Tunnel0] Tunnel-protocol udp dvpn [SecBlade_Clnt1-Tunnel0] source GigabitEthernet0/0.2 [SecBlade_Clnt1-Tunnel0] dvpn interface-type client [SecBlade_Clnt1-Tunnel0] dvpn server testserver [SecBlade_Clnt1-Tunnel0] dvpn vpn-id 1 [SecBlade_Clnt1-Tunnel0] quit # Configure the static route. [SecBlade_Clnt1] ip route-static [SecBlade_Clnt1] ip route-static ) Configure client 2 Switch (SecBlade) # Divide into VLANs. <H3C> system-view [H3C] vlan 20 [H3C-vlan20] quit [H3C] vlan 40 [H3C-vlan40] quit [H3C] vlan 60 [H3C-vlan60] quit # Configure the IP address. [H3C] interface vlan-interface 20 [H3C-Vlan-interface20] ip address [H3C-Vlan-interface20] quit [H3C] interface vlan-interface 40 [H3C-Vlan-interface40] ip address [H3C-Vlan-interface40] quit # Configure the static route. [H3C] ip route-static # Configure aggregation of SecBlade interfaces (SecBlade slot number is 2). [H3C] secblade aggregation slot 2 # Create SecBlade module test. [H3C] secblade module test 7-26

172 Manual VPN Chapter 7 DVPN # Specify the SecBlade interface VLAN. [H3C-secblade-test] secblade-interface vlan-interface 40 # Set the protected VLAN. [H3C-secblade-test] security-vlan 60 # Map the SecBlade module to the SecBlade card of the specified slot. [H3C-secblade-test] map to slot 2 [H3C-secblade-test] quit [H3C] quit # Log into the SecBlade card of the specified slot. <H3C> secblade slot 2 (Both user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade_Clnt2> system-view # Create a sub-interface. [SecBlade_Clnt2] interface GigabitEthernet 0/0.1 [SecBlade_Clnt2-GigabitEthernet0/0.1] vlan-type dot1q vid 40 [SecBlade_Clnt2-GigabitEthernet0/0.1] ip address [SecBlade_Clnt2-GigabitEthernet0/0.1] quit [SecBlade_Clnt2] interface GigabitEthernet 0/0.2 [SecBlade_Clnt2-GigabitEthernet0/0.2] vlan-type dot1q vid 60 [SecBlade_Clnt2-GigabitEthernet0/0.2] ip address [SecBlade_Clnt2-GigabitEthernet0/0.2] quit # Configure a static route. [SecBlade_Clnt2] ip route-static # Enable DVPN function. [SecBlade_Clnt2] dvpn service enable # Configure the dvpn-class. [SecBlade_Clnt2] dvpn class testserver [SecBlade_Clnt2-dvpn-class-testserver] public-ip [SecBlade_Clnt2-dvpn-class-testserver] quit # Configure attributes for interface Tunnel 0. [SecBlade_Clnt2] interface Tunnel 0 [SecBlade_Clnt2-Tunnel0] ip address [SecBlade_Clnt2-Tunnel0] Tunnel-protocol udp dvpn [SecBlade_Clnt2-Tunnel0] source GigabitEthernet0/0.2 [SecBlade_Clnt2-Tunnel0] dvpn interface-type client [SecBlade_Clnt2-Tunnel0] dvpn server testserver [SecBlade_Clnt2-Tunnel0] dvpn vpn-id

173 Manual VPN Chapter 7 DVPN [SecBlade_Clnt2-Tunnel0] quit # Configure the static route. [SecBlade_Clnt2] ip route-static [SecBlade_Clnt2] ip route-static

174 Security

175 Manual Security Table of Contents Table of Contents Chapter 1 Network Security Overview Introduction to the Network Security Features Provided by CMW Hierarchical Line Protection RADIUS-Based AAA Packet Filter and Firewall Firewall Concept Firewall Classification Packet Filter Security Authentication for Route Information Exchange Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Overview Introduction to AAA Introduction to the RADIUS Protocol Introduction to the HWTACACS Protocol Configuring AAA Creating an ISP Domain and Setting the Related Attributes Creating a Local User and Setting the Related Attributes Configuring the RADIUS Protocol Creating a RADIUS Scheme Configuring RADIUS Authentication/Authorization Servers Configuring RADIUS Accounting Servers and Related Attributes Setting the Shared Key for RADIUS Packet Encryption Setting the Maximum Number of RADIUS Request Attempts Setting the Supported RADIUS Server Type Setting the State of RADIUS Servers Setting the Username Format Acceptable to RADIUS Servers Setting the Unit of Data Flows Destined for RADIUS Servers Configuring an IP Address for the NAS to Use as the Source IP Address of RADIUS Packets Setting RADIUS Server Timers Configuring to Send a Trap Packet When the RADIUS Server Goes Down Configuring Local RADIUS Authentication Server Configuring HWTACACS Protocol Creating a HWTACACS Scheme Configuring TACACS Authentication Servers Configuring TACACS Authorization Servers Configuring TACACS Accounting Servers and Related Attributes i

176 Manual Security Table of Contents Configuring an IP Address for the NAS to Use as the Source IP Address of HWTACACS Packets Setting a Key for TACACS servers Setting the Username Format Acceptable to TACACS Servers Setting the Unit of Data Flows Destined for TACACS Servers Setting TACACS Server Timers Configuring TACACS to Support Super Authentication Right Switching in Super Authentication Setting Super Authentication Mode Setting Super Authentication Scheme Displaying and Debugging AAA and RADIUS and HWTACACS Protocols AAA, RADIUS and HWTACACS Protocol Configuration Example Authentication and Accounting for Telnet/SSH Users Using a RADIUS Server Local Authentication for FTP/Telnet Users Authentication (One Time Authentication) and Accounting for Telnet Users through a TACACS Server Troubleshooting AAA, RADIUS and HWTACACS Protocols Troubleshooting the RADIUS Protocol Troubleshooting the HWTACACS Protocol Chapter 3 ACL Configuration Introduction to ACL ACL Overview Classification of ACL Match Order of ACL ACL Creation Basic ACL Advanced ACL Interface-Based ACL MAC-Based ACL ACL Supporting Fragment Configuring an ACL Configuring a Basic ACL Configuring an Advanced ACL Configuring an Interface-Based ACL Configuring a MAC-Based ACL Adding a Description to an ACL Adding a Comment to an ACL Rule Removing an ACL Configuring a Time Range Creating/Removing a Time Range Displaying and Debugging ACL Typical Configuration Examples of ACL ii

177 Manual Security Table of Contents Chapter 4 NAT Configuration NAT Overview Introduction to NAT Functions Provided by NAT Many-to-Many Address Translation and Address Translation Control NAPT Static Network Segment Address Translation Bidirectional Network Address Translation Internal Server Easy IP NAT Application Level Gateway Limiting the Maximum Number of TCP Connections through NAT NAT Configuration Configuring Address Pool Configuring NAT Configure Bidirectional NAT Table Configuring Internal Server Enabling NAT ALG Configuring Domain Name Mapping Configuring Address Translation Lifetimes Configuring NAT to Limit the Maximum Number of TCP Connections Displaying and Debugging NAT NAT Configuration Example Troubleshooting NAT Configuration Chapter 5 Firewall Configuration Introduction to Firewall ACL/Packet Filter Application Specific Packet Filter Virtual Firewall Configuring Packet Filter Enabling or Disabling Firewall Setting the Default Filtering Mode of Firewall Enabling Packet Filter Fragment Detection Configuring Upper/Lower Threshold of Fragment Detection Applying ACL on the Interface Displaying and Debugging Packet Filter Packet Filter Configuration Example Configuration Example of Fragment Filtering Through Packet Filter Configuring ASPF Enabling Firewall Configuring ACL Defining an ASPF Policy iii

178 Manual Security Table of Contents Applying ASPF Policy to Specified Interface Setting the Session Timeout Values Configuring ASPF with Session Logging Configuring Port Mapping Displaying and Debugging ASPF Cautions about ASPF Configuration ASPF Configuration Example Configuring Virtual Firewall Defining a VPN Instance Binding an Interface to a VPN Instance Configuring the Limitation of Virtual Firewall Resources Displaying and Debugging Virtual Firewall Virtual Firewall Configuration Example Black List Introduction to Black List Configuring Black List Displaying and Debugging Black List Black List Configuration Example MAC and IP Address Binding Introduction to MAC and IP Address Binding Configuring MAC and IP Address Binding Displaying and Debugging MAC and IP Address Binding MAC and IP Address Binding Configuration Example Security Zone Configuration Introduction to Security Zone Configuring Security Zone Chapter 6 Transparent Firewall Transparent Firewall Overview Obtaining a MAC Address Table Forwarding and Filtering Configuring Transparent Firewall Configuring Firewall Mode Configuring System IP Address Enabling/Disabling Dynamic ARP Learning Configuring Handling Approach for the Packets with Unknown MAC Address Configuring MAC Address-Based ACLs Applying MAC Address-Based ACL to the Interface Configuring Aging Time of the MAC Forwarding Table Defining Allowed Packet Types Configuring VLAN ID Transparent Transmission Displaying and Debugging Transparent Firewall Transparent Firewall Configuration Example iv

179 Manual Security Table of Contents Chapter 7 Web and Filtering Introduction to Web and Filtering Configuring Web Filtering Configuring Web Address Filtering Configuring Web Content Filtering Configuring SQL Attack Prevention Configuring Filtering Configuring Address Filtering Configuring Subject Filtering Configuring Content Filtering Configuring Attachment Filtering Displaying and Debugging Filtering Chapter 8 Attack Prevention and Packet Statistics Overview of Attack Prevention and Packet Statistics Introduction to Attack Prevention Classes of Network Attacks Typical Examples of Network Attacks Introduction to Packet Statistics Analysis Configuring Attack Prevention Enabling/Disabling ARP Flood Attack Prevention Configuring ARP Spoofing Attack Prevention Enabling/Disabling the IP Spoofing Attack Prevention Function Enabling/Disabling the Land Attack Prevention Function Enabling/Disabling the Smurf Attack Prevention Function Enabling/Disabling the WinNuke Attack Prevention Function Enabling/Disabling the Fraggle Attack Prevention Function Enabling/Disabling Frag Flood Attack Prevention Enabling/Disabling the SYN Flood Attack Prevention Function Enabling/Disabling the ICMP Flood Attack Prevention Function Enabling/Disabling the UDP Flood Attack Prevention Function Enabling/Disabling the ICMP Redirect Packet Control Function Enabling/Disabling the ICMP Unreachable Packet Control Function Enabling/Disabling the IP Sweep Attack Prevention Function Enabling/Disabling the Port Scan Attack Prevention Function Enabling/Disabling the Attack Prevention Function of the IP Packet Carrying Source Route Enabling/Disabling Attack Prevention for Route Record Options Enabling/Disabling the Tracert Packet Control Function Enabling/Disabling Ping of Death Prevention Function Enabling/Disabling the Teardrop Attack Prevention Function Enabling/Disabling the TCP Flag Validity Detection Function Enabling/Disabling the IP Fragment Packet Detection Function v

180 Manual Security Table of Contents 8.3 Setting the Warning Level in Monitoring the Number and Rate of Connections Enabling/Disabling the Oversized ICMP Packet Control Function Configuring System-Based Statistics Enabling/Disabling the System-Based Statistics Function Configuring the System-Based Connection Count Monitoring Configuring Alarm Detection for Abnormal System Packet Rate Configuring Zone-Based Statistics Enabling/Disabling the Zone-Based Statistics Function Configuring the Zone-Based Connection Count Monitoring Configuring the Zone-Based Connection Rate Monitoring Configuring IP-Based Statistics Enabling/Disabling the IP-Based Statistics Function Configure the IP-Based Connection Count Monitoring Function Configuring the IP-Based Connection Rate Monitoring Function Displaying and Debugging Attack Prevention and Packet Statistics Displaying and Debugging Attack Prevention Displaying and Debugging Packet Statistics Configuring SMTP Client Configuring Mail Triggering Time Configuring Mail Addresses Displaying and Debugging SMTP Client Configuration Configuring DNS Client Configuring a DNS Server Configuring DNS Cache Displaying and Debugging DNS Client Configuration Attack Prevention and Packet Statistics Configuration Examples Enabling the Land Attack Prevention Function Enabling the SYN Flood Attack Prevention Function Enabling the Address Scanning Attack Prevention Function Enabling the Zone-Based Connection Count Monitoring Function Displaying Statistics Information of Specified IP Address Attack Prevention Troubleshooting Chapter 9 IDS Cooperation Introduction to IDS Cooperation Configuring IDS Cooperation Issuing IDS-Cooperation ACL Rules to Interfaces Displaying and Debugging IDS Cooperation IDS Configuration Examples Chapter 10 Log Maintenance Introduction to Log Configuring Syslog Log Configuring Syslog Log Output Format vi

181 Manual Security Table of Contents Configuring the Sweep Time for the Syslog Log Buffer Configuring the Log Redirection for the Information Center Binary-Flow Log Configuration Enabling/Disabling Binary-Flow Log Output in Interzone Configuring Host Address and Port of Receiving Binary-Flow Log Clearing Log Log Configuration Example Outputting Attack Prevention Log to Host Outputting Binary-Flow Log to Host vii

182 Manual Security Chapter 1 Network Security Overview Chapter 1 Network Security Overview Note: All the contents below are about SecBlade cards, so the commands in this manual are executed in views corresponding to SecBlade cards instead of the other series switches. 1.1 Introduction to the Network Security Features Provided by CMW SecBlade must be able to withstand malicious attacks from the public network. On the other hand, the accidental but destructive access may also result in significant performance decrease and even the operation failure. CMW provides the following network security characteristics: Authentication, authorization and accounting (AAA) services based on Remote Authentication Dial-In User Service (RADIUS). AAA can provide authentication, authorization, and accounting services on users for preventing illegal access. Authentication protocol that supports CHAP and PAP authentication on PPP line. Packet filter implemented through access control list (ACL) which specifies the type of packets that the SecBlade will permit or deny. Application specific packet filter (ASPF), or status firewall. ASPF is an advanced communication filtering approach that checks the application layer information and monitors the status of connection-oriented application layer protocols, maintains the status information of each connection, and dynamically makes decision on whether to permit or deny a packet. IP security (IPSec), which guarantees the privacy, integrity and validity of packets while being transmitted on the Internet through encryption and data source authentication on the IP layer. Internet key exchange (IKE) that provides the services of key exchange through auto-negotiation and establishment of the security association (SA) to simplify the use and management of IPSec. Event log, which is used to record system security events and trace illegal access in real time. Address translation provided by NAT Gateway (GW), which separates the public network from the intranet, makes the IP addresses of the internal devices 1-1

183 Manual Security Chapter 1 Network Security Overview unknown to the public network, and hence prevents the attacks from the public network. Dynamic routing protocol authentication that ensures reliable route information to be exchanged. Hierarchical view protection, which classifies users into four levels that are assigned with different configuration rights. A low-level user cannot enter the view of a higher level. The following chapters describe how to configure AAA and RADIUS, user password, firewall and packet filtering. Refer to the VPN part of this manual for IPSec/IKE configuration; refer to NAT Configuration for address translation configuration; refer to the Routing Protocol part of this manual for dynamic routing protocol authentication. 1.2 Hierarchical Line Protection The system command lines are protected in a hierarchical way. In this approach, the command lines are divided into four levels: visit, monitor, system, and manage. You are unable to use the corresponding levels of commands unless you have provided the correct login password. 1.3 RADIUS-Based AAA AAA is used for user access management. It can be implemented via multiple protocols but the AAA discussed here is based on RADIUS. AAA provides: Hierarchical user management. Generally, users are allowed to perform the operations like managing and maintaining the system configuration data, and monitoring and maintaining the device. These operations are crucial to the normal operation of the system. Therefore, it is necessary to classify the users into different levels and grants each with specific rights. In this case, a low-level user can only perform some viewing operations, while only a high-level user can modify data, maintain devices, and perform some other sensitive operations. PPP authentication. With it, username/password authentication will be performed before the setup of a PPP connection. PPP address management and allocation. When setting up a PPP connection, the system may assign the pre-specified IP address to the PPP user. The next chapter will cover the details of RADIUS protocol and its configurations, user password configuration, and PPP user address configuration. For PPP authentication protocols, refer to the User Access part of this manual. 1-2

184 Manual Security Chapter 1 Network Security Overview 1.4 Packet Filter and Firewall Firewall Concept The firewall can prevent unauthorized or unauthenticated users on the Internet from accessing a protected network while allowing the users on the internal network to access web sites on the Internet and send/receive s. It can also work as an Internet access control GW by permitting only some particular users in an organization to access the Internet. Figure 1-1 A firewall separating the intranet from the Internet Apart from connecting the Internet, the firewall can also protect the mainframe and crucial resources (like data) on the intranet of the organization. Access to the protected data should be permitted by the firewall first, even if the access is initiated from the organization. An external network user must pass through the firewall before it can access the protected network resources. Likewise, an intranet user must pass through the firewall before it can access the external network resources. Thus, the firewall plays the role as a guard and discards the denied packets Firewall Classification Normally, firewalls are classified into two categories: network layer firewalls and application layer firewalls. Network layer firewalls mainly obtain the information of the packet header, such as protocol, source address, destination address, and destination port. Alternatively, they can directly obtain a segment from the packet header. The application layer firewalls, however, analyze the whole information traffic. Firewalls are generally divided into the following categories: 1-3

185 Manual Security Chapter 1 Network Security Overview Application gateway: It verifies the application layer of all packets. Take a File Transfer Protocol (FTP) application GW as an example. From the perspective of the Client, the FTP GW is an FTP server; however, from the perspective of the Server, it is an FTP client. All the FTP packets must pass through this FTP GW. Circuit-Level Gateway: The term "circuit refers to Virtual Circuit (VC). Before a TCP or UDP connection or a VC is opened, the session reliability must be verified. Packet transmission is allowed only after a valid handshake procedure is accomplished. After the setup of a session, the session information is stored in a table of valid connections maintained by the firewall. A packet can be permitted only if its session information matches an entry in the table. After the session is terminated, the session entry will be deleted from the table. The circuit-level GW authenticates a connection at the session layer. If the authentication is passed, any application can apply through the connection. Take FTP as an example. A circuit-level GW only authenticates an FTP session at the TCP layer at the beginning of the session. If the authentication is passed, all the data can be transmitted through this connection until the session is terminated. Packet filter: The firewall filters each packet based on the items that specified by the user. For example, the firewall compares the source and destination address of packets with the defined rules for a match. A packet filter neither considers the session status, nor analyzes the data. If the user specifies that the packets carrying port number 21 or a port number no less than 1024 are permitted, all the packets matching the rule can pass through the firewall. If the rules are specified based on actual applications, large numbers of malicious packets can be filtered out. Network Address Translation (NAT), also called address proxy, which makes it possible for a private network to access the external network. The NAT mechanism is to substitute the external network address and port number of SecBlade for that of a host on the private network and vice versa. In other words, it is the translation between <Private address + Port number> and <Public address + Port number>. The private address discussed here refers to the internal network or host address, and the public address refers to a globally unique IP address on the Internet. Internet Assigned Number Authority (IANA) provisioned that that the following IP address ranges are reserved for private addresses: to to to In other words, the addresses in these three ranges will be used inside organizations or companies rather than being assigned as Internet addresses. A company can select a proper network address range by taking the future expansion of internal hosts and networks into consideration. The internal network addresses of different companies can be the same. However, it may cause chaos if a company uses network addresses 1-4

186 Manual Security Chapter 1 Network Security Overview from a network segment range other than the three ranges given above. NAT allows internal hosts to access the Internet resources while keeping their privacy Packet Filter I. Function Generally, a packet filter filters IP packets. For the packets that the SecBlade will forward, the packet filter will first obtain the header information of each packet, including upper protocol carried by the IP layer, source and destination addresses, and source and destination port numbers of the packet. Then, the packet filter compares the above elements with the preset rules to determine whether the packet should be forwarded or discarded. Figure 1-2 illustrates the elements that a packet filter uses for decision making (on IP packets), given the upper layer carried by IP is TCP/UDP. Source/destination IP addresses IP header Packet filtering elements Source/destination ports TCP/UDP header Application layer header Application layer traffic Data Figure 1-2 Packet filtering elements Most packet filter systems do not take any operation on data itself or make content-based filtering. II. ACL Before the system can filter the packets, you should configure ACL rules to specify which type of packets should be allowed or denied. A user should configure an ACL according to the security policy and apply it to a specified interface or all the interfaces on the device. Then, the SecBlade checks all the packets received by the specified interface or all the interfaces based on the ACL, and then forwards or discards the packets matching the rules. In this way, the SecBlade functions as a firewall. 1.5 Security Authentication for Route Information Exchange The SecBlade card operates based on the maintenance of the route forwarding table, which is implemented by dynamic route information exchange among neighboring routers. 1-5

187 Manual Security Chapter 1 Network Security Overview I. Necessity of implementing security authentication for route information exchange As the neighboring routers on a network need to exchange enormous route information, some unreliable routers may attack other network devices. Enabled with the route authentication function, the SecBlade card will be able to authenticate the route updates received from neighboring routers, and hence will receive only the reliable route information. II. Authentication Implementation The routers exchanging route information share the same key that is sent along with the route information packets. Upon receiving the route information, the routers will authenticate the packets, and verify the key carried by the packets. If the key carried by the packets is the same as the shared key, the packets will be accepted; otherwise, they will be discarded. Authentication can be implemented through simple text authentication and MD5 authentication. The former sends keys in plain text providing lower security, whereas the latter sends encrypted keys providing higher security. 1-6

188 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration 2.1 Overview Introduction to AAA Authentication, Authorization and Accounting (AAA) provides a framework designed to configure a set of three security functions in a consistent manner. The network security mentioned here refers to access control and it includes: Which users can access the network server? Which services can the authorized users enjoy? How to keep accounts for the users who are using network resources? Accordingly, AAA provides the following services: I. Authentication For authentication, the following methods are supported: None authentication: All users are trusted and are not verified. Generally, this method is not recommended. Local authentication: User profiles (including username, password, and attributes) are stored on the broadband access server (BAS). Local authentication features high speed but low cost; the information that can be stored in this approach is however limited depending on hardware. Remote authentication: RADIUS and HWTACACS protocols are supported for remote authentication. In this approach, the BAS acts as the client to communicate with the RADIUS or TACACS authentication server. For RADIUS, you can use standards-based RADIUS protocol or H3C extended RADIUS protocol to complete authentication in conjunction with devices like itellin/cams. II. Authorization For authorization, the following methods are supported: Direct authorization: All users are trusted and directly authorized. Local authorization: Users are authorized according to the relevant attributes of the local user accounts configured on the BAS. HWTACACS authorization: Users are authorized by the TACACS server. If-authenticated authorization: Users are authorized after they are authenticated in any method other than none authentication. 2-1

189 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration RADIUS authorization following successful authentication: With RADIUS, users are authorized only after they pass authentication. In other words, you cannot perform RADIUS authorization without authentication. III. Accounting For accounting, the following methods are supported: None accounting: Users are not accounted. Remote accounting: Users are accounted remotely through the RADIUS server or TACACS account server. Note: Currently, the SecBlade supports accounting for PPP users and Telnet users only, but it does not provide real time accounting for Telnet users. AAA usually utilizes a client/server model, where the client controls user access and the server stores user information. The framework of AAA thus has a high scalability and centralized management. Being a management framework, AAA can be implemented using multiple protocols. In CMW, for example, AAA is implemented based on the RADIUS protocol or HWTACACS protocol Introduction to the RADIUS Protocol I. What is RADIUS Remote authentication dial-in user service (RADIUS) is an information exchange protocol in a distributed client/server model designed for preventing a network from being accessed illegally. It is often used in network environments where both high security and remote access are required, for example, to manage a large number of dispersed dial-in users that use serial ports and modems. The RADIUS system is an important auxiliary part of the Network Access Server (NAS). The RADIUS service involves three components: Protocol: Based on the UDP/IP layer, RFC2865 and 2866 define the RADIUS frame format and the message transfer mechanism, and use UDP port 1812 as the authentication port and UDP port 1813 as the accounting port. Server: RADIUS server runs on the computer or workstation at the center, and maintains authentication and network access information. Client: RADIUS client is located at the Network Access Server (NAS) side anywhere in the network. As the RADIUS client, the NAS (a switch or a router) is responsible for transferring user information to a designated RADIUS server and taking actions based on the response 2-2

190 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration from the server (such as connecting or disconnecting users). The RADIUS server receives user connection requests, authenticates users, and returns the required information to the NAS. In general, the RADIUS server maintains three databases, namely, users, clients and dictionary, as shown in the following figure. The users database stores user information such as username, password, applied protocols, and IP address; the clients database stores information about RADIUS clients such as shared key; and the dictionary database stores the information for interpreting RADIUS protocol attributes and their values. RADIUS Server Users Clients Dictionary Figure 2-1 RADIUS server components In addition, the RADIUS server can act as the client of other AAA servers to provide proxy authentication or accounting service. The RADIUS server supports authentication in many ways, such as PPP-based PAP, CHAP and UNIX-based login. II. Basic message exchange procedure in RADIUS In most cases, user authentication using a RADIUS server involves the proxy function of devices like NAS. Transactions between the RADIUS client and the RADIUS server are authenticated through a shared key, and user passwords are transferred in cipher text across the network for enhanced security. The RADIUS protocol combines the authentication and authorization processes together by sending authorization information in the authentication response message. See the following figure. 2-3

191 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Host RADIUS Client RADIUS Server (1)the user enter username and password (2)Authentication request (3)Authentication accept (4)Accounting-Request (start) (5)Accounting-Response (6)The user accesses resources (7)Accounting-Request (stop) (8)Accounting-Response (9)Notify termination of the access Figure 2-2 Basic message exchange procedure in RADIUS Following is how RADIUS operates: 1) The user enters the username and password. 2) Having received the username and password, the RADIUS client sends an authentication request (Access-Request) to the RADIUS server. 3) The RADIUS server compares the received user information against that in the Users database. If the authentication succeeds, it sends back an authentication response (Access-Accept) with user right. If the authentication fails, it returns an Access-Reject message. 4) The RADIUS client determines to permit the user based on the received authentication results. If so, the RADIUS client sends a start accounting request (Accounting-Request) to the RADIUS server, with the value of Status-Type being start. 5) The RADIUS server returns a start-accounting response (Accounting-Response). 6) The RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server, with the value of Status-Type being stop. 7) The RADIUS server returns a stop-accounting response (Accounting-Response). III. RADIUS packet format RADIUS transfers messages in UDP packets, and leverages timer, retransmission and primary/secondary mechanisms to ensure smooth message exchange between the RADIUS server and the RADIUS client. The following figure shows the RADIUS packet format. 2-4

192 Manual Security Code Identifier Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration 7 Length Authenticator Attribute Figure 2-3 RADIUS packet format The identifier field is used for matching request packets against response packets. It varies with the attribute field and is up on the receiving of valid response packets. However, it keeps unchanged during retransmission. The 16-byte authenticator field is used to authenticate the requests transmitted back from the RADIUS server. It also applies to the password hidden algorithm. There are two kinds of authenticators: request authenticator and response authenticator. Request authenticator is the random code of 16 bytes in length. Response authenticator is the operation result of applying the MD5 algorithm to code, identifier, request authenticator, length, attribute and shared-key. 1) The code field determines the type of a RADIUS packet, as shown in the following table. Table 2-1 Code values Code Packet type Description 1 Access-Request 2 Access-Accept 3 Access-Reject The packet carries user information and flows from the client to the server to help the client determine whether the user can access the network. In this packet, User-Name is required; NAS-IP-Address, User-Password, and NAS-Port are optional. The packet flows from the server to the client. If all the attribute values carried in the Access-Request packet are acceptable, the server allows the user to pass authentication and sends back an Access-Accept response. The packet flows from the server to the client. If any attribute value carried in the Access-Request packet is unacceptable, the server denies the user and sends back an Access-Reject response. 2-5

193 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Code Packet type Description 4 Accounting-Request 5 Accounting-Response The packet carries user information and flows from the client to the server. The server can determine whether to start accounting according to the Acct-Status-Type attribute. The attributes carried in this type of packet are basically the same as those carried by an Access-Request packet. The packet flows from the server to the client, notifying the client that the server has received the Accounting-Request packet and has recorded accounting information. The packet carries such information as number of input/output bytes, number of input/output packets, and session duration. 2) The attribute field contains authentication, authorization, and accounting information, and provides detailed configuration of a request or response packet. This field is represented by the triplet of type, length and value. The following table lists the standard attribute values defined by RFC: Table 2-2 Attribute values Type Attribute type Type Attribute type 1 User-Name 23 Framed-IPX-Network 2 User-Password 24 State 3 CHAP-Password 25 Class 4 NAS-IP-Address 26 Vendor-Specific 5 NAS-Port 27 Session-Timeout 6 Service-Type 28 Idle-Timeout 7 Framed-Protocol 29 Termination-Action 8 Framed-IP-Address 30 Called-Station-Id 9 Framed-IP-Netmask 31 Calling-Station-Id 10 Framed-Routing 32 NAS-Identifier 11 Filter-ID 33 Proxy-State 12 Framed-MTU 34 Login-LAT-Service 13 Framed-Compression 35 Login-LAT-Node 14 Login-IP-Host 36 Login-LAT-Group 15 Login-Service 37 Framed-AppleTalk-Link 16 Login-TCP-Port 38 Framed-AppleTalk-Network 2-6

194 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Type Attribute type Type Attribute type 17 (unassigned) 39 Framed-AppleTalk-Zone 18 Reply_Message (reserved for accounting) 19 Callback-Number 60 CHAP-Challenge 20 Callback-ID 61 NAS-Port-Type 21 (unassigned) 62 Port-Limit 22 Framed-Route 63 Login-LAT-Port The RADIUS protocol is extensible. The No. 26 attribute (Vender-Specific) defined in the protocol allows you to define an extended attribute, as shown in the following figure. Type Length 7 Vendor-ID Vendor-ID Type (specified) Length (specified) Specified attribute value Figure 2-4 A RADIUS packet segment containing the extended attribute IV. RADIUS features The RADIUS protocol is widely used. RADIUS uses UDP as transfer protocol for real time applications and retransmission and primary/secondary mechanisms for higher reliability. Being easy to implement, RADIUS is applicable for multithreading structures on the server side where there are a lot number of users Introduction to the HWTACACS Protocol I. What is HWTACACS Huawei terminal access controller access control system (HWTACACS) is a security protocol enhanced based on TACACS (RFC1492). Similar to the RADIUS protocol, it implements AAA for all users (such as PPP/VPDN/login users) through communications with TACACS servers in the client/server model. Compared with RADIUS, HWTACACS provides more reliable transmission and encryption features, and therefore is more suitable for security control. The following table lists the primary differences between HWTACACS and RADIUS protocols. 2-7

195 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-3 Comparison between HWTACACS and RADIUS HWTACACS Adopts TCP, providing more reliable network transmission Encrypts the entire packet, including the HWTACACS header Separates authentication from authorization (for example, you can implement authentication and authorization on different TACACS servers) Applies to security control Supports the use of configuration commands through authorization Adopts UDP RADIUS Encrypts only the password field in the authentication packet Brings authentication and authorization together Applies to accounting Not supporting In a typical HWTACACS application, a dial-up or terminal user needs to log in to the SecBlade. Working as the client of HWTACACS in this case, the SecBlade sends the username and password to the TACACS server for authentication. After passing authentication and being authorized, the user can log in to the SecBlade, as shown in Figure 2-5. Terminal user ISDN/PSTN TACACS Server Dial user Switch HWTACACS Client TACACS Server Figure 2-5 Network diagram for a typical HWTACACS application II. Basic message exchange procedure for HWTACACS For example, HWTACACS is used to implement authentication, authorization, and accounting for a telnet user. The basic message exchange procedure is as follows: 1) The user requests access to the SecBlade; the TACACS client sends a start-authentication packet to the TACACS server upon receipt of the request. 2) The TACACS server sends back an authentication response requesting the username; the TACACS client asks the user for the username upon receipt of the response. 2-8

196 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration 3) The TACACS client sends an authentication continuance packet carrying the username after receiving the username from the user. 4) The TACACS server sends back an authentication response requesting the login password. Upon receipt of the response, the TACACS client requests the user for the login password. 5) After receiving the login password, the TACACS client sends an authentication continuance packet carrying the login password to the TACACS server. 6) The TACACS server sends back an authentication response, indicating that the user has passed the authentication. 7) The TACACS client sends the user authorization packet to the TACACS server. 8) The TACACS server sends back an authorization response, indicating that the user has passed the authorization. 9) Upon receipt of the response indicating an authorization success, the TACACS client pushes the configuration interface of the SecBlade to the user. 10) The TACACS client sends a start-accounting request to the TACACS server. 11) The TACACS server sends back an accounting response, indicating that it has received the start-accounting request. 12) The user logs off; the TACACS client sends a stop-accounting request to the TACACS server. 13) The TACACS server sends back a stop-accounting packet, indicating that the stop-accounting request has been received. The following figure illustrates the basic message exchange procedure: 2-9

197 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration User HWTACACS Client HWTACACS Server User logs in Authentication start request packet Request User for the user name Authentication response packet,requesting for the user name User enters the user name Authentication continuance packet carrying the user name Authentication response packet,requesting for the password Request User for password User enters the password Authentication continuance packet carrying the password Authentication success packet Authorization request packet Authorization success packet User is permitted Accounting start request packet Accounting start response packet User quits Accounting stop packet Accounting stop response packet Figure 2-6 AAA procedure for a telnet user 2.2 Configuring AAA AAA configuration tasks include: I. Creating an ISP domain and setting the related attributes Creating an ISP domain Configuring an AAA scheme Configuring the ISP domain state Setting an access limit Enabling accounting optional Defining an address pool and allocating IP addresses to PPP users 2-10

198 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration II. Creating a local user and set the related attributes (for local authentication only) Creating an ISP Domain and Setting the Related Attributes I. Creating an ISP domain An Internet service provider (ISP) domain is a group of users that belong to the same ISP. For a username in the userid@isp-name format, gw @test163.net for example, the isp-name (test163.net) following sign is the ISP domain name. When receiving a connection request from a user named userid@isp-name, the SecBlade considers the userid part as the username for authentication and the isp-name part as the domain name. The purpose of introducing ISP domain settings is to support the multi-isp application environment, where users of different ISPs may access the same access device. Because the attributes of ISP users, such as username and password formats, type of service and right may be different, you must differentiate them by setting ISP domains. In ISP domain view, you can configure a complete set of exclusive ISP domain attributes on a per-isp domain basis, including an AAA scheme. For the SecBlade, each supplicant belongs to an ISP domain. Up to 16 domains can be configured in the system. If a user has not reported its ISP domain name, the system puts it into the default domain. Perform the following configurations in system view. Table 2-4 Create/delete an ISP domain Create an ISP domain or enter the specified domain view Remove the specified ISP domain domain { isp-name default { disable enable isp-name } } undo domain isp-name By default, the default ISP domain in the system is system. II. Configuring an AAA scheme You can configure an AAA scheme in two ways. 1) AAA binding mode In this mode, you can use the scheme command to specify a scheme. If you choose the RADIUS or HWTACACS scheme, the corresponding RADIUS or HWTACACS server will perform the authentication, authorization and accounting tasks in a consistent manner. That is, you cannot specify different schemes for authentication, authorization and accounting. If you use the local scheme, only authentication and authorization are implemented. 2-11

199 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration When the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local command is configured, the local scheme applies as an alternative scheme in case the RADIUS or TACACS server is not available. If the local scheme applies as the first scheme, only local authentication is performed and the RADIUS, HWTACACS or none scheme cannot be adopted. If the none scheme applies as the first scheme, neither RADIUS nor HWTACACS scheme can be adopted. Perform the following configuration in ISP domain view. Table 2-5 Configure the related attributes of the ISP domain Configure an AAA scheme for the domain Restore the default AAA scheme scheme { radius-scheme radius-scheme-name [ local ] hwtacacs-scheme hwtacacs-scheme-name [ local ] local none } undo scheme [ radius-scheme hwtacacs-scheme none ] The default AAA scheme is local. Caution: The none scheme cannot be used for authenticating an FTP user, because an FTP server implemented with CMW does not support anonymous login. If the scheme none command is used, the privilege level of a user logged into the system is 0. 2) AAA separate mode In this mode, you can use the authentication, authorization or accounting command to select schemes respectively. For example, you can specify the RADIUS scheme for authentication and authorization, and the HWTACACS scheme for optional accounting. This provides users with flexibility in scheme combination. Implementations of AAA services in this mode are listed below. For terminal users Authentication: RADIUS, HWTACACS, local, RADIUS-local, HWTACACS-local or none; Authorization: HWTACACS or none; Accounting: RADIUS, HWTACACS or none. You can custom an AAA scheme according to the above implementations. 2-12

200 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration For FTP users Only authentication applies to FTP users. Authentication: RADIUS, HWTACACS, local, RADIUS-local or HWTACACS-local. For PPP and L2TP users Authentication: RADIUS, HWTACACS, local, RADIUS-local, HWTACACS-local or none; Authorization: HWTACACS or none; Accounting: RADIUS, HWTACACS or none. You can custom an AAA scheme according to the above implementations. For DVPN services At present, for authentication and authorization, only RADIUS, local and RADIUS-local are supported; for accounting, only RADIUS is supported. Perform the following configuration in ISP domain view. Table 2-6 Configure the related ISP domain attributes Configure an authentication scheme for the domain Restore the default authentication scheme Configure an authorization scheme for the domain Restore the default authorization scheme Configure an accounting scheme for the domain Restore the default accounting scheme authentication { radius-scheme radius-scheme-name [ local ] hwtacacs-scheme hwtacacs-scheme-name [ local ] local none } undo authentication authorization { hwtacacs-scheme hwtacacs-scheme-name none } undo authorization accounting { radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name none } undo accounting Note: 3) If AAA separate and AAA binding modes are configured at the same time, the former applies. 4) The RADIUS and local schemes do not support separated authentication and authorization. Therefore, the following should be noted: When the scheme radius-scheme or scheme local command is configured, but the authentication command is not configured, there are two cases: If the 2-13

201 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration authorization none command is configured, the authorization data returned by the RADIUS or local scheme is still valid; if the authorization hwtacacs-scheme command is configured, the HWTACACS scheme is used for authorization. If the scheme radius-scheme or scheme local command is configured as well as the authentication hwtacacs-scheme command is configured at the same time, the HWTACACS scheme is used for authentication and no authorization is performed. III. Configuring the ISP domain state Every ISP domain has two states: active or block. If an ISP domain is in active state, users in the domain can request network services; while in block state, users in the domain cannot request network services, except for those already online users. Perform the following configuration in ISP domain view. Table 2-7 Configure the ISP domain state Configure the ISP domain state state { active block } By default, an ISP domain is in active state upon its creation. IV. Setting an access limit You can specify the maximum number of users that an ISP domain can accommodate by setting an access limit. Perform the following configuration in ISP domain view. Table 2-8 Configure an access limit Set an access limit to limit the number of users that the domain can accommodate Restore the default value access-limit { disable enable max-user-number } undo access-limit By default, no limit is imposed on the number of users that an ISP domain can accommodate upon its creation. V. Enabling accounting optional With the accounting optional command configured, the device does not disconnect the connection to users during accounting even when it finds no active accounting server or fails to communicate with the accounting server. 2-14

202 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration With the accounting optional command, the system always sends accounting information to the accounting server and does not terminate the connection, no matter whether the accounting server responds or performs the accounting service. On contrary, if the none keyword in the scheme command is specified, the system neither sends accounting information to the accounting server nor certainly terminates the connection. If you have specified the RADIUS-scheme or HWTACACS-scheme keyword in the scheme command but have not configured the accounting optional command, the system sends accounting information to the accounting server and, if the server does not respond or perform accounting service, terminates the connection. Perform the following configuration in ISP domain view. Table 2-9 Enable accounting optional Enable accounting optional Disable accounting optional accounting optional undo accounting optional By default, when an ISP domain is created, accounting optional is disabled. VI. Defining an address pool and allocating IP addresses to PPP users Users can obtain IP addresses through PPP negotiation in three ways: Directly allocating IP addresses on the interface without configuring an address pool. Defining address pools in system view and specifying an address pool for the interface (only one is allowed) in interface view to allocate addresses to peers. Defining address pools in domain view and directly allocating addresses from the pools to PPP users orderly. Perform the following configuration in ISP domain view. Table 2-10 Define an IP address pool for PPP users Define an IP address pool used for allocating addresses to PPP users Remove the specified address pool ip pool pool-number low-ip-address [ high-ip-address ] undo ip pool pool-number By default, no address pool is configured. The following are the principles of how to allocating IP addresses to PPP users in AAA: 1) For a domain user with a name either in the form of userid or userid@isp-name, an IP address is allocated as follows: 2-15

203 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration If RADIUS or TACACS authentication/authorization applies, the address that the server has issued to the user is allocated, if there is any. If the server issues an address pool instead of an address, the device searches the address pool in domain view for an address. In case no address is allocated with the above two methods or local authentication is used, the user will be allocated an IP address based on the configuration on the interface. If the remote address ip-address command is configured on the interface and the specified address is not in use, the device assigns the address to the user. If the remote address pool command is configured on the interface, the device searches the specified address pool for an IP address in domain view and assigns the address to the user. If the remote address command is not configured on the interface, the device searches all the address pools for an IP address in domain view and assigns the address to the user. 2) For a user not to be authenticated, the device allocates an IP address from the specified address pool (defined in system view) on the interface. Note: For a user that is to be authenticated and is not assigned any address with the remote address ip-address command, you can change the way of address allocation after the PPP connection is set up Creating a Local User and Setting the Related Attributes Create a local user and configure the related attributes on the security gateway if you select the local authentication scheme in AAA. Note: If you use a RADIUS scheme or HWTACACS scheme to authenticate users, you must configure the RADIUS or TACACS server appropriately. The local configuration in this case does not take effect. I. Creating a local user A local user is a group of users set on the NAS (i.e. the SecBlade). The username is the unique identifier of users in the group. A user requesting network services can pass 2-16

204 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration local authentication as long as its information has been added to the local user database of the NAS. Perform the following configuration in system view. Table 2-11 Create/delete a local user Add a local user Delete a local user and its related attributes Delete all local users or users with the specified service type local-user user-name undo local-user user-name [ service-type level ] undo local-user all [ service-type { ftp ppp ssh telnet terminal } ] By default, there is no local user in the system. II. Setting attributes of a local user The attributes of a local user include password display mode, password, state, and type of service granted. Perform the following configuration in system view. Table 2-12 Set the password display mode for local users Set the password display mode for local users Cancel the password display mode for local users local-user password-display-mode { cipher-force auto } undo local-user password-display-mode Where, auto means that the password will be displayed in the specified display mode (refer to the password command in the following table for reference), and cipher-force means that the password will be displayed in cipher text. Perform the following configurations in local user view. Table 2-13 Set/remove the attributes for the specified user Configure a password for the user Remove the password setting password { simple cipher } password undo password Configure the state for the user state { active block } Remove the state setting undo state { active block } Configure a service type for the user service-type { telnet ssh terminal pad } 2-17

205 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Remove the service type setting Configure a privilege level for the user Restore the default Authorize the user to use DVPN service Cancel the authorization Authorize the user to use FTP service and specify a directory the user can access Cancel the authorization and restore the directory that the user can access to the default Authorize the user to use the PPP service Cancel the authorized PPP service undo service-type { telnet ssh terminal pad } level level undo level service-type dvpn undo service-type dvpn service-type ftp [ ftp-directory directory] undo service-type ftp [ ftp-directory ] service-type ppp undo service-type ppp By default, no service is authorized to users. The default privilege level of a user is 0. Note: If you specify an authentication method that requires the username and password, including local authentication, RADIUS authentication and HWTACACS authentication, the level of the commands that a user can use after login depends on the privilege level of the user, or the priority of user interface as with other authentication methods. For an SSH user using RSA public key authentication, the commands that he can use depend on the priority level configured for the user interface. 2.3 Configuring the RADIUS Protocol The RADIUS protocol is configured on a per-radius scheme basis. In a real networking environment, a RADIUS scheme may comprise an independent RADIUS server or a pair of primary and secondary RADIUS servers with the same configuration but different IP addresses. Accordingly, every RADIUS scheme has the following attributes: IP addresses of primary and secondary servers, shared key, and type of RADIUS server. Actually, configuration of the RADIUS protocol only involves the parameters necessary for information exchange between the NAS and the RADIUS server. To bring these parameters into effect, you need to configure a domain to reference the RADIUS 2-18

206 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration scheme with these parameters in ISP domain view. For more information about configuration commands, refer to the Configuring AAA. RADIUS protocol configuration includes: Creating a RADIUS Scheme Configuring RADIUS Authentication/Authorization Servers Configuring RADIUS Accounting Servers and Related Attributes Configuring optional accounting Enabling stop-accounting buffer and Retransmission Setting the Maximum Number of RADIUS Request Attempts Setting the Shared Key for RADIUS Packet Encryption Setting the Maximum Number of RADIUS Request Attempts Setting the Supported RADIUS Server Type Setting the State of RADIUS Servers Setting the Username Format Acceptable to RADIUS Servers Setting the Unit of Data Flows Destined for RADIUS Servers Configuring an IP Address for the NAS to Use as the Source IP Address of RADIUS Packets Setting RADIUS Server Timers Configuring to Send a Trap Packet When the RADIUS Server Goes Down Configuring Local RADIUS Authentication Server Among these tasks, creating a RADIUS scheme and configuring RADIUS authentication/authorization server are required, while other tasks are optional Creating a RADIUS Scheme As mentioned earlier, the RADIUS protocol is configured on a per-radius scheme basis. To configure the RADIUS protocol, you must create a RADIUS scheme and enter its view. You can use the following commands to create or delete a RADIUS scheme. Perform the following configurations in system view. Table 2-14 Create a RADIUS scheme Create a RADIUS scheme and enter its view Delete a RADIUS scheme radius scheme radius-scheme-name undo radius scheme radius-scheme-name A RADIUS scheme can be referenced by several ISP domains at the same time. 2-19

207 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration By default, the system has a RADIUS scheme named system whose attributes are all default values. Caution: FTP, terminal, and SSH are not standard attribute values of the RADIUS protocol, so you need to define them in the attribute login-service (the standard attribute 15): Login-service(50) = SSH Login-service(51) = FTP Login-service(52) = Terminal After that, reboot the RADIUS server is required Configuring RADIUS Authentication/Authorization Servers You can use the following commands to configure IP addresses and port numbers of RADIUS authentication/authorization servers. Perform the following configuration in RADIUS view. Table 2-15 Configure RADIUS authentication/authorization servers Configure IP address and port number of the primary RADIUS authentication/authorization server Restore IP address and port number of the primary RADIUS authentication/authorization server to the default values Configure IP address and port number of the secondary RADIUS authentication/authorization server Restore IP address and port number of the secondary RADIUS authentication/authorization server to the default values primary authentication ip-address [ port-number ] undo primary authentication secondary authentication ip-address [ port-number ] undo secondary authentication As authorization information from the RADIUS server is sent to the RADIUS clients in authentication response packets, so you do not need to specify a separate authorization server. 2-20

208 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration In real networking environments, you may specify two RADIUS servers as the primary and secondary authentication/authorization servers respectively, or specify one server to function as both Configuring RADIUS Accounting Servers and Related Attributes I. Configuring RADIUS accounting servers You can use the following commands to configure IP addresses and port numbers of RADIUS accounting servers. Perform the following configuration in RADIUS view. Table 2-16 Configure RADIUS accounting servers Configure IP address and port number of the primary RADIUS accounting server Restore IP address and port number of the primary RADIUS accounting server to the default value Configure IP address and port number of the secondary RADIUS accounting server Restore IP address and port number of the secondary RADIUS accounting server to the default value primary accounting ip-address [ port-number ] undo primary accounting secondary accounting ip-address [ port-number ] undo secondary accounting In practice, you can specify two RADIUS servers as the primary and the secondary accounting servers respectively; or specify one server to function as both. To configure IP address and port number of the RADIUS server, you must ensure an active route between it and the NAS for normal interaction. In addition, since RADIUS uses different UDP ports to receive and send authentication/authorization and accounting packets, you must assign different numbers to the authentication/authorization port and the accounting port, which are 1812 and 1813 respectively as recommended by RFC2138/2139. You can assign port numbers different from the two recommended values in the RFC, however. (For example, in the early stage of RADIUS server implementation, 1645 and 1646 were often assigned to the authentication/authorization port and accounting port). In practice, make sure that the port settings on the SecBlade and the RADIUS server are consistent. You can use the display radius scheme command to view the IP addresses and port numbers of the primary and secondary accounting servers in the RADIUS scheme. 2-21

209 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Note: After accounting is completed successfully, both update accounting and stop accounting packets will be sent to the accounting server used when accounting. No primary-secondary switching will occur even if this server is not available. The switching occurs only in the initial stage of authentication, authorization and accounting process. II. Configuring optional accounting With the accounting optional command configured, the device does not disconnect the connection to the user during the accounting, even when it finds no available accounting server or fails to communicate with the accounting server. Perform the following configuration in RADIUS domain view. Table 2-17 Enable optional accounting Enable optional accounting. Disable optional accounting. accounting optional undo accounting optional By default, when an RADIUS scheme is created, optional accounting is disabled. III. Enabling stop-accounting buffer and Retransmission Given the influence of a stop accounting packet on billing and eventually charging, it has importance for both users and ISPs. Therefore, the NAS should make its best effort to send the stop accounting packet to the RADIUS accounting server. If the SecBlade receives no response from the RADIUS accounting server, it buffers the packet locally and sends repeatedly until the RADIUS accounting server responds, or it discards the packet when the predefined attempt times is reached. You can use the following commands to enable stop-accounting buffer. Perform the following configuration in RADIUS view. Table 2-18 Enable stop-accounting buffer and retransmission Enable stop-accounting buffer Disable stop-accounting buffer Enable stop-accounting retransmission and specify the maximum number of retries stop-accounting-buffer enable undo stop-accounting-buffer enable retry stop-accounting retry-times 2-22

210 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Disable stop-accounting retransmission and restore the default undo retry stop-accounting By default, the stop-accounting buffer function is enabled and the maximum number of transmission attempts is set to 500. IV. Configuring the maximum number of real-time accounting request attempts A RADIUS server usually determines the online state of a user using the connection timeout timer. If the RADIUS sever receives no real time accounting packets from the NAS for a long time, it considers that the line or device fails and stops user accounting. To work with this feature of the RADIUS server, the NAS is required to terminate user connections simultaneously with the RADIUS server when unpredictable faults occur. The SecBlade allows you to set the maximum number of real time accounting request attempts. The NAS terminates a user connection if it has received no response after the maximum number of real time accounting request attempts is reached. You can use the following command to set the maximum number of real time accounting request attempts. Perform the following configuration in RADIUS view. Table 2-19 Set the maximum number of real time accounting request attempts Set the maximum number of real time accounting request attempts Restore the default retry realtime-accounting retry-times undo retry realtime-accounting By default, the maximum number of real time accounting request attempts is Setting the Shared Key for RADIUS Packet Encryption The RADIUS client (the SecBlade) and the RADIUS server use the MD5 algorithm to encrypt the packets exchanged between them. Both verify the validity of packets through a shared key. Only when the same key is used can they properly receive the packets and make responses. Perform the following configurations in RADIUS view. 2-23

211 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-20 Set the shared key for RADIUS packet encryption Set the shared key for RADIUS authentication/authorization packet encryption Restore the default Set the shared key for RADIUS accounting packet encryption Restore the default key authentication string undo key authentication key accounting string undo key accounting By default, the shared key none is used for RADIUS authentication/authorization and accounting packet encryption Setting the Maximum Number of RADIUS Request Attempts Since RADIUS uses UDP packets to carry data, the communication process is not reliable. If the RADIUS server does not respond to the NAS when the response timer times out, the NAS should retransmit the RADIUS request to the RADIUS server. If the RADIUS server does not respond when the retry-times is reached, the NAS considers the communication with the current RADIUS server has been disconnected and turns to another RADIUS server. You can use the following command to set the maximum number of RADIUS request attempts. Perform the following configurations in RADIUS view. Table 2-21 Set the maximum number of RADIUS request attempts Set the maximum number of RADIUS request attempts. Restore the default retry retry-times undo retry By default, a RADIUS request can be sent up to three times Setting the Supported RADIUS Server Type You can use the following command to set the supported RADIUS server type. Perform the following configurations in RADIUS view. 2-24

212 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-22 Set the supported RADIUS server type Set the supported RADIUS server type server-type { extended standard } Restore the default undo server-type By default, in system scheme, the RADIUS server type is extended; in the newly created RADIUS scheme, the RADIUS server type is standard. Note: If a H3C CAMS server is used, some parameters, such as service type, EXEC priority level, and FTP directory, take effect only after service-type is configured as extended Setting the State of RADIUS Servers For primary and secondary servers (no matter they are authentication/authorization servers or accounting servers) in a RADIUS scheme, if the primary server is disconnected from the NAS due to some fault, the NAS automatically turns to the secondary server. However, after the primary one recovers, the NAS does not resume the communication with it at once; instead, the NAS continues communicating with the secondary one and turns to the primary one again only after the secondary one fails. To have the NAS communicate with the primary server right after its recovery, you can manually set the primary server state to active. When the primary and secondary servers are active or block, the NAS sends packets to the primary one only. Perform the following configurations in RADIUS view. Table 2-23 Set RADIUS server state Set the state of the primary RADIUS authentication/authorization server Set the state of the primary RADIUS accounting server Set the state of the secondary RADIUS authentication/authorization server Set the state of the secondary RADIUS accounting server state primary authentication { block active } state primary accounting { block active } state secondary authentication { block active } state secondary accounting { block active } 2-25

213 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration You can use the display radius scheme command to view the server state in the RADIUS scheme Setting the Username Format Acceptable to RADIUS Servers As mentioned above, the supplicants are generally named in userid@isp-name format. The part is the ISP domain name. The SecBlade will put the users into different ISP domains according to domain names. However, some earlier RADIUS servers reject the username with ISP domain name. In this case, you have to remove the domain name before sending the username to these RADIUS servers. The SecBlade provides the following command to specify whether the username to be sent to the RADIUS server carries ISP domain name or not. Table 2-24 Set username format acceptable to the RADIUS server Set the username format transmitted to the RADIUS server user-name-format { with-domain without-domain } Note: If a RADIUS scheme is configured not to allow usernames to include ISP domain names, the RADIUS scheme shall not be simultaneously used in more than one ISP domain. Otherwise, the RADIUS server will regard two users in different ISP domains as the same user by mistake if they have the same username (excluding their respective domain names.) By default, in system scheme, the NAS server sends user names without ISP domain names to the RADIUS server; in the newly created RADIUS scheme, the NAS server sends user names with ISP domain names to the RADIUS server Setting the Unit of Data Flows Destined for RADIUS Servers The SecBlade provides you with the following command to define the unit of data flows sent to RADIUS servers. 2-26

214 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-25 Set the unit of data flows destined for RADIUS servers Set the unit of data flows transmitted to RADIUS servers Restore the default data-flow-format data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega- packet one-packet } undo data-flow-format In a RADIUS scheme, the default data flow unit is byte and the default data packet unit is one packet Configuring an IP Address for the NAS to Use as the Source IP Address of RADIUS Packets Perform the following configuration in the specified views. Table 2-26 Configure an IP address for the NAS Configure an IP address for the NAS to use as the source IP address of RADIUS packets (RADIUS view) Remove the configuration (RADIUS view) Configure an IP address for the NAS to use as the source IP address of RADIUS packets (System view) Remove the configuration (System view) nas-ip ip-address undo nas-ip radius nas-ip ip-address undo radius nas-ip You can use either command to bind a source address with the NAS. By default, no source address is specified and the source address of a packet is the IP address of the interface where it is sent Setting RADIUS Server Timers I. Setting the response timeout timer If the NAS receives no response from the RADIUS server after sending a RADIUS request (authentication/authorization or accounting request) for a period, the NAS has to resend the request, thus ensuring the user can obtain the RADIUS service. You can use the following commands to set the response timeout timer. Perform the following configuration in RADIUS view. 2-27

215 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-27 Set the response timeout timer Set the response timeout timer Restore the default timer response-timeout seconds undo timer response-timeout By default, the response timeout timer for the RADIUS server is set to three seconds. II. Setting the quiet timer for the primary RADIUS server Perform the following configuration in RADIUS view. Table 2-28 Configure the quiet timer for the primary RADIUS server Configure the quiet timer for the primary RADIUS server Restore the default timer quiet minutes undo timer quiet By default, the primary RADIUS server must wait five minutes before it resumes the active state. III. Setting the real time accounting timer The setting of real time accounting timer is indispensable to real time accounting. After an interval value is set, the NAS transmits the accounting information of online users to the RADIUS accounting server at intervals of this value. Perform the following configuration in RADIUS view. Table 2-29 Set the real time accounting timer Set the real time accounting timer Restore the default timer realtime-accounting minutes undo timer realtime-accounting Where minutes represents the interval for real time accounting and it must be a multiple of three. The setting of real time accounting timer somewhat depends on the performance of the NAS and the RADIUS server: a shorter interval means higher device performance. You are therefore recommended to adopt a longer interval when there are a large number of users (more than 1000, inclusive). The following table recommends the ratio of minutes to the number of users. 2-28

216 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-30 Recommended ratio of real time accounting interval to user number User number Realtime accounting interval (minute) ú1000 ú15 The real time accounting interval defaults to 12 minutes Configuring to Send a Trap Packet When the RADIUS Server Goes Down Perform the following configuration in system view. Table 2-31 Configure the RADIUS server to send a trap packet Configure to send a trap packet when the RADIUS server goes down Configure not to send a trap packet when the RADIUS server goes down radius trap { authentication-server-down accounting-server-down } undo radius trap { authentication-server-down accounting-server-down } By default, the RADIUS server does not send a trap packet when it goes down Configuring Local RADIUS Authentication Server The SecBlade provides simple local RADIUS server function, including authentication and authorization, called RADIUS authentication server function. Table 2-32 Configure local RADIUS authentication server Configure local RADIUS authentication server remove the configuration local-server nas-ip ip-address key password undo local-server nas-ip ip-address 2-29

217 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration By default, a local RADIUS authentication server with the NAS-IP as and key as none is created. Note: When the local RADIUS authentication server function is enabled, the UDP port number for the authentication/authorization services must be 1645 and that for the accounting service must be The key password configured here must be the same with the key password configured by the key authentication command in RADIUS view. The device supports 16 local RADIUS authentication servers at most, including the default one created by the system. 2.4 Configuring HWTACACS Protocol The configuration tasks of HWTACACS include: Creating a HWTACACS Scheme Configuring TACACS Authentication Servers Configuring TACACS Authorization Servers Configuring TACACS Accounting Servers and Related Attributes Configuring an IP Address for the NAS to Use as the Source IP Address of HWTACACS Packets Setting a Key for TACACS servers Setting the Username Format Acceptable to TACACS Servers Setting the Unit of Data Flows Destined for TACACS Servers Setting TACACS Server Timers Note: Compared with RADIUS configuration, note that: The system only checks users are using the current HWTACACS scheme when you delete the scheme. By default, the TACACS server has no key. Among these configuration tasks, creating a HWTACACS scheme and configuring TACACS authentication/authorization servers are mandatory, while others are optional at your discretion. 2-30

218 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Creating a HWTACACS Scheme As aforementioned, the HWTACACS protocol is configured on a per-scheme basis. Therefore, you must create a HWTACACS scheme and enter HWTACACS view before you perform other configuration tasks. Perform the following configuration in system view. Table 2-33 Create a HWTACACS scheme Create a HWTACACS scheme and enter HWTACACS view Delete a HWTACACS scheme hwtacacs scheme hwtacacs-scheme-name undo hwtacacs scheme hwtacacs-scheme-name In HWTACACS view, you can configure the HWTACACS scheme. Up to 128 HWTACACS schemes can be supported and only the inactive schemes can be deleted. By default, no HWTACACS scheme exists Configuring TACACS Authentication Servers Perform the following configuration in HWTACACS view. Table 2-34 Configure TACACS authentication servers Configure the primary TACACS authentication server Delete the primary TACACS authentication server Configure the secondary TACACS authentication server Delete the secondary TACACS authentication server primary authentication ip-address [ port ] undo primary authentication secondary authentication ip-address [ port ] undo secondary authentication The primary and secondary authentication servers cannot use the same IP address. Otherwise, the system will prompt unsuccessful configuration. The default port number is 49. If you execute this command repeatedly, the new settings will overwrite the old settings. A server can be deleted only when it is not used by any active TCP connection for sending authentication packets. 2-31

219 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Configuring TACACS Authorization Servers Perform the following configuration in HWTACACS view. Table 2-35 Configure TACACS authorization servers Configure the primary TACACS authorization server Delete the primary TACACS authorization server Configure the secondary TACACS authorization server Delete the secondary TACACS authorization server primary authorization ip-address [ port ] undo primary authorization secondary authorization ip-address [ port ] undo secondary authorization Note: If HWTACACS authentication is configured for a user which has not deployed a TACACS authorization server, the user cannot log in regardless of its user type. The primary and secondary authorization servers cannot use the same IP address. Otherwise, the system will prompt unsuccessful configuration. The default port number is 49. If you execute this command repeatedly, the new settings will overwrite the old settings. A server can be deleted only when it is not used by any active TCP connection for sending authorization packets Configuring TACACS Accounting Servers and Related Attributes I. Configuring TACACS accounting servers Perform the following configuration in HWTACACS view. Table 2-36 Configure TACACS accounting servers Configure the primary TACACS accounting server Delete the primary TACACS accounting server Configure the secondary TACACS accounting server primary accounting ip-address [ port ] undo primary accounting secondary accounting ip-address [ port ] 2-32

220 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Delete the secondary TACACS accounting server undo secondary accounting The primary and secondary accounting servers cannot use the same IP address. Otherwise, the system will prompt unsuccessful configuration. The default port number is 49. The default IP address of TACACS accounting server is If you execute this command repeatedly, the new settings will overwrite the old settings. A server can be deleted only when it is not used by any active TCP connection for sending accounting packets. Note: After accounting is completed successfully, both update accounting and stop accounting packets will be sent to the server used when accounting. No primary-secondary switching will occur even if this server is not available. The switching occurs only in the initial authentication, authorization and accounting process. II. Enabling stop-accounting packet retransmission Perform the following configuration in HWTACACS view. Table 2-37 Configure stop-accounting packet retransmission Enable stop-accounting packet retransmission and set the maximum number of transmission attempts. Disable stop-accounting packet retransmission and restore the default retry stop-accounting retry-times undo retry stop-accounting By default, stop-accounting packet retransmission is enabled, and the maximum number of transmission attempts is Configuring an IP Address for the NAS to Use as the Source IP Address of HWTACACS Packets Perform the following configuration. 2-33

221 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-38 Configure an IP address for the NAS Configure an IP address for the NAS to use as the source IP address of HWTACACS packets (HWTACACS view) Remove the configuration (HWTACACS view) nas-ip ip-address undo nas-ip Configure an IP address for the NAS to use as the source IP address of HWTACACS packets (System view) hwtacacs ip-address nas-ip Remove the configuration (System view) undo hwtacacs nas-ip By default, no source address is specified and the source address of a packet is the address of the interface where the packet is sent Setting a Key for TACACS servers When using a TACACS server as an AAA server, you can set a key to improve the security of communications between the SecBlade and the TACACS server. Perform the following configuration in HWTACACS view. Table 2-39 Set a key for TACACS servers Configure a key for TACACS accounting, authorization or authentication server Remove the configuration key { accounting authorization authentication } string undo key { accounting authorization authentication } No key is configured by default Setting the Username Format Acceptable to TACACS Servers A username is usually in the userid@isp-name format, with the domain name If a TACACS server does not accept a username with domain name, you can remove the domain name and resend it to the TACACS server. Perform the following configuration in HWTACACS view. 2-34

222 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-40 Set the username format acceptable to the TACACS server Send a username with domain name Send a username without domain name user-name-format with-domain user-name-format without-domain By default, each username sent to a TACACS server contains a domain name Setting the Unit of Data Flows Destined for TACACS Servers Perform the following configuration in HWTACACS view. Table 2-41 Set the unit of data flows destined for TACACS servers Set the unit of data flows destined for TACACS servers data-flow-format data { byte giga-byte kilo-byte mega-byte } data-flow-format packet { giga-packet kilo-packet mega-packet one-packet } Restore the default undo data-flow-format { data packet } By default, data is sent in bytes. The packets are measured in the unit of one packet Setting TACACS Server Timers I. Setting the response timeout timer Since HWTACACS is implemented based on TCP, response timeout or TCP timeout may terminate the connection to TACACS servers. Perform the following configuration in HWTACACS view. Table 2-42 Set the response timeout timer Set the response timeout time Restore the default timer response-timeout seconds undo timer response-timeout The default response timeout timer is set to five seconds. II. Setting the quiet timer for the primary TACACS server Perform the following configuration in HWTACACS view. 2-35

223 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Table 2-43 Set the quiet timer for the primary TACACS server Set the quiet timer for the primary TACACS server Restore the default timer quiet minutes undo timer quiet By default, the primary TACACS server must wait five minutes before it resumes the active state. III. Setting the real time accounting timer The setting of real time accounting timer is indispensable to real time accounting. After an interval value is set, the NAS transmits the accounting information of online users to the RADIUS accounting server at intervals of this value. Perform the following configuration in HWTACACS view. Table 2-44 Set the real time accounting timer Set a real time accounting interval Restore the default timer realtime-accounting minutes undo timer realtime-accounting The interval is in minutes and must be a multiple of 3. The setting of real time accounting timer somewhat depends on the performance of the NAS and the TACACS server: a shorter interval means higher device performance. You are therefore recommended to adopt a longer interval when there are a large number of users (more than 1000, inclusive). The following table recommends the ratio of minutes to the number of users. Table 2-45 Recommended ratio of minute to the number of users User number Real time accounting interval (in minutes) ú 1000 ú 15 The real time accounting timer defaults to 12 minutes. 2-36

224 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration 2.5 Configuring TACACS to Support Super Authentication With the super level command, a user can gain a higher right level when he or she logs in to the firewall. In the process, a super password can be used for authentication. All users at one level use the same password, which is not flexible and is of low security. The TACACS supports super authentication, that is, a user name and super password are configured on the TACACS server. Consequently, it enhances flexibility and security of setting management significantly Right Switching in Super Authentication The system allows you to configure super authentication in each user interface view. The system supports four authentication modes: super-password scheme super-password + scheme scheme + super-password After logging into the device, a user can execute the super level command to change the current right to a desired level. There are the following cases: I. The requested right is not higher than the current right In this case, the user directly obtains the requested right without being authenticated. II. The requested right is higher than the current right In this case, the system handles the command according to the super authentication mode configured in the current user interface view. 1) super password You can set a super password for each level of right. If a password is set for the requested level of right, the system asks the user to enter a password. If the password is correct, the user can obtain the requested right. Otherwise, the system prompts that the user fails the authentication. If no password is set for the requested level of right, the user cannot obtain the right. 2-37

225 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Caution: If no super password is set for the requested level of right, the processing is somewhat different from the previous procedure. Previously, only users connecting the console port can obtain the right. Now, no one can obtain the right. 2) scheme In the AAA authentication mode (in this mode, a user needs to enter a username and password at the time of login), the system asks the user to enter a password after the user executes the super level command. Then, the username and entered super password are sent to the TACACS server for authentication. If authentication succeeds, the user can obtain the requested right. Otherwise, the system prompts that the user fails the authentication. In the none or password authentication mode (in this mode, a user needs not to enter a username at the time of login), the system asks the user to enter a username and super password after the user executes the super level command. Then, the entered username and password are sent to the TACACS server for authentication. If authentication succeeds, the user can obtain the requested right. Otherwise, the system prompts that the user fails the authentication. 3) scheme + super password In this case, the system uses the scheme authentication in preference to the super password authentication mode. If the TACACS server configured in the scheme is not available or no authentication scheme is configured in the domain, the system will turn to the super password authentication mode. 4) super password + scheme In this case, the system uses the super password authentication in preference to the scheme authentication mode. If no super password is configured, the system will turn to the scheme authentication mode Setting Super Authentication Mode Perform the following configurations in user interface view. Table 2-46 Setting super authentication mode Set super authentication mode Restore the default super authentication-mode { super-password scheme } * undo super authentication-mode 2-38

226 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration By default, the super authentication mode is super password Setting Super Authentication Scheme The system allows you to configure each domain with a super authentication scheme. The scheme can only be a HWTACACS scheme, rather than RADIUS or local scheme. When a HWTACACS scheme is referenced by the super authentication scheme of a domain, the scheme cannot be removed. If no scheme is specified or the specified scheme does not exist, TACACS authentication will fail. Perform the following configurations in ISP domain view. Table 2-47 Setting super authentication scheme Set super authentication scheme Remove the configured super authentication scheme authentication super hwtacacs-scheme hwtacacs-scheme-name undo authentication super By default, no super authentication scheme is configured. 2.6 Displaying and Debugging AAA and RADIUS and HWTACACS Protocols After the above configuration, you can: Execute the display commands in any view to view the running of the AAA and RADIUS/HWTACACS configurations and to check the configuration effect. Execute the reset commands in user view to reset the configurations. Execute the debugging commands in user view for debugging. Table 2-48 Display and debug the AAA protocol Display the configuration information of the specified ISP domain or all the ISP domains Display connection information associated with the specified or all users display domain [ isp-name ] display connection [ domain isp-name ip ip-address mac mac-address radius-scheme radius-scheme-name ucibindex ucib-index user-name user-name ] 2-39

227 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Display information about the specified or all local users display local-user [ domain isp-name service-type { dvpn telnet ssh terminal ftp ppp } state { active block } user-name user-name ] Table 2-49 Display and debug the RADIUS protocol Display information about the specified or all the RADIUS schemes Display statistics of RADIUS packets Display information on the stop-accounting packets in the buffer Display statistics of the local RADIUS authentication server Enable RADIUS packet debugging Disable RADIUS packet debugging Enable local RADIUS authentication server debugging Disable local RADIUS authentication server debugging Clear stop-accounting packets from the buffer Clear statistics of RADIUS servers display radius scheme [ radius-scheme-name ] display radius statistics display stop-accounting-buffer { radius-scheme radius-scheme-name session-id session-id time-range start-time stop-time user-name user-name } display local-server statistics debugging radius packet undo debugging radius packet debugging local-server { all error event packet } undo debugging local-server { all error event packet } reset stop-accounting-buffer { radius-scheme radius-scheme-name session-id session-id time-range start-time stop-time user-name user-name } reset radius statistics Table 2-50 Display and debug the HWTACACS protocol Display information about the specified or all the HWTACACS schemes Display information on the stop-accounting packets in the buffer Enable HWTACACS debugging display hwtacacs scheme [ hwtacacs-scheme-name [ statistics ] ] display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name debugging hwtacacs { all error event message receive-packet send-packet } 2-40

228 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Disable HWTACACS debugging Clear stop-accounting packets in the buffer Clear statistics of TACACS servers undo debugging hwtacacs { all error event message receive-packet send-packet } reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name reset hwtacacs statistics {accounting authentication authorization all } 2.7 AAA, RADIUS and HWTACACS Protocol Configuration Example Authentication and Accounting for Telnet/SSH Users Using a RADIUS Server Note: Authentication configuration on the RADIUS server for SSH users is similar to that for Telnet users. The following uses the configuration for Telnet users as an example. I. Network requirements As shown in the following figure, configure the SecBlade to use the RADIUS server to provide authentication and accounting services for Telnet users. Connect the SecBlade to the RADIUS server (functions as both authentication and accounting servers) whose IP address is /24. On the SecBlade, set the shared keys both for packet exchange with the authentication server and with the accounting server as expert. Use a H3C CAMS server as the RADIUS server. Set server type in the RADIUS scheme to standard or extended if a third-party RADIUS server is used and to extended if a H3C CAMS server is used. On the RADIUS server, set the shared key for packet exchange with the SecBlade as expert; set the authentication and accounting port numbers; add the usernames and login passwords of the Telnet users. If the SecBlade is configured in the RADIUS scheme not to remove the domain name from the user name but send the full username to the RADIUS server, the Telnet usernames added onto the RADIUS server must be in the userid@isp-name format. 2-41

229 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration II. Network diagram /24 VLAN 30 VLAN /24 SecBlade /24 VLAN / /24 Switch VLAN 10 Telent User Radius Server /24 Figure 2-7 Network diagram for remote RADIUS authentication on Telnet users III. Configuration procedure 1) Radius Server IP address: /24. Gateway: ) Telnet User IP address: /24. 3) Switch (SecBlade) # Configure VLANs. <Switch> system-view [Switch] vlan 10 [Switch-vlan10] quit [Switch] vlan 30 [Switch-vlan30] quit [Switch] vlan 50 [Switch-vlan50] quit # Configure IP addresses for VLAN interfaces. [Switch] interface vlan-interface 10 [Switch-Vlan-interface10] ip address [Switch-Vlan-interface10] quit [Switch] interface vlan-interface 30 [Switch-Vlan-interface30] ip address [Switch-Vlan-interface30] quit # Configure a static route. 2-42

230 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration [Switch] ip route-static # Configure interface aggregation for the SecBlade (the SecBlade card resides in slot 2). [Switch] secblade aggregation slot 2 # Create a SecBlade module named test. [Switch] secblade module test # Specify the SecBlade interface as VLAN interface. [Switch-secblade-test] secblade-interface vlan-interface 30 # Configure the VLAN to be protected. [Switch-secblade-test] security-vlan 50 # Map the SecBlade module to the SecBlade card in the specified slot. [Switch-secblade-test] map to slot 2 [Switch-secblade-test] quit [Switch] quit # Log into the SecBlade card in the specified slot. <Switch> secblade slot 2 (Both the default user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade> system-view # Create sub interfaces. [SecBlade] interface GigabitEthernet 0/0.1 [SecBlade-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade-GigabitEthernet0/0.1] ip address [SecBlade-GigabitEthernet0/0.1] quit [SecBlade] interface GigabitEthernet 0/0.2 [SecBlade-GigabitEthernet0/0.2] vlan-type dot1q vid 50 [SecBlade-GigabitEthernet0/0.2] ip address [SecBlade-GigabitEthernet0/0.2] quit # Add the sub interface of the internal network to the trust zone. [SecBlade] firewall zone trust [SecBlade-zone-trust] add interface GigabitEthernet 0/0.1 [SecBlade-zone-trust] quit # Add the sub interface of the external network to the untrust zone. [SecBlade] firewall zone untrust [SecBlade-zone-untrust] add interface GigabitEthernet 0/0.2 [SecBlade-zone-untrust] quit # Configure a static route. 2-43

231 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration [SecBlade] ip route-static # Configure the Telnet user to use AAA authentication mode. [SecBlade] user-interface vty 0 4 [SecBlade-ui-vty0-4] authentication-mode scheme # Configure the domain. [SecBlade] domain cams [SecBlade-isp-cams] access-limit enable 10 [SecBlade-isp-cams] accounting optional [SecBlade-isp-cams] quit # Configure a RADIUS scheme. [SecBlade] radius scheme cams [SecBlade-radius-cams] primary authentication [SecBlade-radius-cams] primary accounting [SecBlade-radius-cams] key authentication expert [SecBlade-radius-cams] key accounting expert [SecBlade-radius-cams] server-type extended [SecBlade-radius-cams] user-name-format with-domain [SecBlade-radius-cams] quit # Configure to associate the domain with the RADIUS. [SecBlade] domain cams [SecBlade-isp-cams] scheme radius-scheme cams [SecBlade-isp-cams] quit Telnet users use usernames in the userid@cams format to log onto the network and are to be authenticated as cams domain users. # Quit SecBlade configuration view. [SecBlade] quit <SecBlade> quit [Switch] Local Authentication for FTP/Telnet Users Note: Configuring local authentication for FTP users is similar to that for Telnet users. The following example is based on Telnet users. 2-44

232 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration I. Network requirements Configure the SecBlade to authenticate the login Telnet users locally (see the following figure). II. Network diagram /24 VLAN 30 VLAN /24 SecBlade /24 VLAN / /24 Switch VLAN 10 Internet Telent User /24 Figure 2-8 Network diagram for local authentication for Telnet user III. Configuration procedure 1) Telnet User IP address: /24. Gateway: ) Switch (SecBlade) # Configure VLANs. <Switch> system-view [Switch] vlan 10 [Switch-vlan10] quit [Switch] vlan 30 [Switch-vlan30] quit [Switch] vlan 50 [Switch-vlan50] quit # Configure IP addresses for VLAN interfaces. [Switch] interface vlan-interface 10 [Switch-Vlan-interface10] ip address [Switch-Vlan-interface10] quit [Switch] interface vlan-interface 30 [Switch-Vlan-interface30] ip address [Switch-Vlan-interface30] quit 2-45

233 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration # Configure a static route. [Switch] ip route-static # Configure interface aggregation of SecBlade (the SecBlade card resides in slot 2). [Switch] secblade aggregation slot 2 # Create a SecBlade module named test. [Switch] secblade module test # Specify the SecBlade interface as VLAN interface. [Switch-secblade-test] secblade-interface vlan-interface 30 # Set the VLAN to be protected. [Switch-secblade-test] security-vlan 50 # Map the SecBlade module to the SecBlade card in the specified slot. [Switch-secblade-test] map to slot 2 [Switch-secblade-test] quit [Switch] quit # Log into the SecBlade card in the specified slot. <Switch> secblade slot 2 (Both the default user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade> system-view # Create sub interfaces. [SecBlade] interface GigabitEthernet 0/0.1 [SecBlade-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade-GigabitEthernet0/0.1] ip address [SecBlade-GigabitEthernet0/0.1] quit [SecBlade] interface GigabitEthernet 0/0.2 [SecBlade-GigabitEthernet0/0.2] vlan-type dot1q vid 50 [SecBlade-GigabitEthernet0/0.2] ip address [SecBlade-GigabitEthernet0/0.2] quit # Add the sub interface of the internal network to the trust zone. [SecBlade] firewall zone trust [SecBlade-zone-trust] add interface GigabitEthernet 0/0.1 [SecBlade-zone-trust] quit # Add the sub interface of the external network to the untrust zone. [SecBlade] firewall zone untrust [SecBlade-zone-untrust] add interface GigabitEthernet 0/0.2 [SecBlade-zone-untrust] quit # Configure a static route. 2-46

234 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration [SecBlade] ip route-static [SecBlade] ip route-static # Configure the Telnet user to use AAA authentication. [SecBlade] user-interface vty 0 4 [SecBlade-ui-vty0-4] authentication-mode scheme # Create a local user named telnet. [SecBlade] local-user telnet@system [SecBlade-luser-telnet@system] service-type telnet [SecBlade-luser-telnet@system] password simple extended [SecBlade-luser-telnet@system] quit [SecBlade] domain system [SecBlade-isp-system] scheme local [SecBlade-isp-system] quit Telnet users use usernames in the userid@system format to log onto the network and are to be authenticated as system domain users. # Quit SecBlade configuration view. [SecBlade] quit <SecBlade> quit Authentication (One Time Authentication) and Accounting for Telnet Users through a TACACS Server I. Network requirements As shown in the following figure, configure the SecBlade to use the TACACS server to provide one time password authentication and accounting services for Telnet users. Connect the SecBlade to the TACACS server (functions as both authentication and accounting servers) whose IP address is /24. On the SecBlade, set the shared keys both for packet exchange with the authentication server and with the accounting server as expert. The TACACS server uses one time password authentication. The SecBlade sends the full username to the TACACS server without removing the domain name. The Telnet usernames sent to the TACACS server must be in the test@tacacs format. 2-47

235 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration II. Network diagram /24 VLAN 30 VLAN /24 SecBlade /24 VLAN / /24 Switch VLAN 10 Telent User TACACS Server /24 Figure 2-9 Network diagram for remote TACACS authentication on Telnet user III. Configuration procedure 1) TACACS Server IP address: /24. Gateway: ) Telnet User IP address: /24. 3) Switch (SecBlade) # Configure VLANs. <Switch> system-view [Switch] vlan 10 [Switch-vlan10] quit [Switch] vlan 30 [Switch-vlan30] quit [Switch] vlan 50 [Switch-vlan50] quit # Configure IP addresses for VLAN interfaces. [Switch] interface vlan-interface 10 [Switch-Vlan-interface10] ip address [Switch-Vlan-interface10] quit [Switch] interface vlan-interface 30 [Switch-Vlan-interface30] ip address [Switch-Vlan-interface30] quit # Configure a static route. 2-48

236 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration [Switch] ip route-static # Configure interface aggregation for the SecBlade (the SecBlade card resides in slot 2). [Switch] secblade aggregation slot 2 # Create a SecBlade module named test. [Switch] secblade module test # Specify the SecBlade interface as VLAN interface. [Switch-secblade-test] secblade-interface vlan-interface 30 # Set the VLAN to be protected. [Switch-secblade-test] security-vlan 50 # Map the SecBlade module to the SecBlade card in the specified slot. [Switch-secblade-test] map to slot 2 [Switch-secblade-test] quit [Switch] quit # Log into the SecBlade card in the specified slot. <Switch> secblade slot 2 (Both the default user name and password are SecBlade) user: SecBlade password: SecBlade <SecBlade> system-view # Create sub interfaces. [SecBlade] interface GigabitEthernet 0/0.1 [SecBlade-GigabitEthernet0/0.1] vlan-type dot1q vid 30 [SecBlade-GigabitEthernet0/0.1] ip address [SecBlade-GigabitEthernet0/0.1] quit [SecBlade] interface GigabitEthernet 0/0.2 [SecBlade-GigabitEthernet0/0.2] vlan-type dot1q vid 50 [SecBlade-GigabitEthernet0/0.2] ip address [SecBlade-GigabitEthernet0/0.2] quit # Add the sub interface of the internal network to the trust zone. [SecBlade] firewall zone trust [SecBlade-zone-trust] add interface GigabitEthernet 0/0.1 [SecBlade-zone-trust] quit # Add the sub interface of the external network to the untrust zone. [SecBlade] firewall zone untrust [SecBlade-zone-untrust] add interface GigabitEthernet 0/0.2 [SecBlade-zone-untrust] quit # Configure a static route. 2-49

237 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration [SecBlade] ip route-static # Configure the Telnet user to use AAA authentication. [SecBlade] user-interface vty 0 4 [SecBlade-ui-vty0-4] authentication-mode scheme # Configure the domain. [SecBlade] domain cams [SecBlade-isp-cams] access-limit enable 10 [SecBlade-isp-cams] accounting optional [SecBlade-isp-cams] quit # Configure the RADIUS scheme. [SecBlade] hwtacacs scheme system [SecBlade-hwtacacs-system] primary authentication [SecBlade-hwtacacs-system] primary accounting [SecBlade-hwtacacs-system] key authentication expert [SecBlade-hwtacacs-system] key accounting expert [SecBlade-hwtacacs-system] server-type extended [SecBlade-hwtacacs-system] user-name-format with-domain [SecBlade-hwtacacs-system] quit # Configure to associate the domain with the TACACS. [SecBlade] domain tacacs [SecBlade-isp-tacacs] scheme tacacs-scheme system 4) Configure the TACACS server Configure the IP address Configure the shared key Add username test@ tacacs Enable one-time authentication 5) Login procedure Configure one-time password authentication for Telnet users as follows: Figure 2-10 Telnet user login interface 2-50

238 Manual Security Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration Step 1: Type username test@tacacs. Step 2: Choose to use the winkey.exe calculator to get the login password at the prompt s/key 89 gf Figure 2-11 Calculate login password In the above figure: Type the prompt 89 gf55236 in the Challenge field. Type the private password (test for example) in the Password field. The Response field outputs the calculation result, that is, the password you need to type in the login interface. Step 3: Type the calculated password in the login interface and you are authorized to access. 2.8 Troubleshooting AAA, RADIUS and HWTACACS Protocols Troubleshooting the RADIUS Protocol The RADIUS protocol of the TCP/IP protocol suite is located at the application layer. It mainly defines how to exchange user information between a NAS and a RADIUS server of an ISP. So it is very likely to get invalid. Symptom 1: User authentication/authorization always fails Troubleshooting: Check that: 1) The username is in the userid@isp-name format or a default ISP domain is specified on the NAS. 2) The user exists in the database on the RADIUS server. 3) The password input by the user is correct. 4) The same shared key is configured on both the RADIUS server and the NAS. 5) The NAS can communicate with the RADIUS server (by pinging the RADIUS server). Symptom 2: RADIUS packets cannot reach the RADIUS server. 2-51