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.

1.1.1 Features of VPN

l 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.

l 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.

l 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.

1.1.2 Benefits of VPN

VPN allows you to:

l 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.

l 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.

l Add or delete users through software configuration rather than changing hardware facilities, thus delivering great flexibility.

l Support mobile access of VPN users at any time in any place, thus meeting growing mobile service demands.

1.1.3 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.

Figure 1-1 Composition of VPN

The above figure shows the relationship between five switches and three VPNs.

l VPN1—Switch2, Switch4

l VPN2—Switch1, Switch3, Switch4

l VPN3—Switch1, Switch5

1.2 Fundamental Technology of VPN

1.2.1 Basic Network Design of VPN

Take an enterprise as an example. Its intranet through a VPN is shown in the following figure.

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.

1.2.2 Mechanism of VPN

Figure 1-3 Diagram for accessing VPN

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:

l 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.

l 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.

l 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:

l Generic routing encapsulation (GRE), which is used to encapsulate a network layer protocol into another one.

l 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.

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

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.

Chapter 2 L2TP Configuration

2.1 Introduction to L2TP

2.1.1 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.

2.1.2 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 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:

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.

III. Technology details of L2TP

1) Architecture of L2TP

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 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:

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:

Figure 2-4 Network diagram for L2TP application

Call setup flow of L2TP Tunnel is shown in the following figure:

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;

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

l 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.

l Multi-protocol transmission

L2TP transmits PPP packets, so multiple protocols can be encapsulated in a PPP packet.

l Support authentication of RADIUS server

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.

l 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.

l 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.

l 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:

l Enable L2TP (required)

l Create an L2TP group (required)

l Set the condition of triggering L2TP Tunnel setup request and LNS addresses (required)

l Set local name (optional)

l Enable Tunnel authentication and set a password (optional)

l Set the transfer mode of AVP data (optional)

l Set Hello interval in the Tunnel (optional)

l Set user name and password and configure user authentication (required)

l Terminate a Tunnel by force (optional)

l Enable/disable the flow control function (optional)

l Set L2TP session idle-timeout timer (optional)

l Configure the Tunnel-hold function of L2TP (optional)

l Configure the LAC as a client (optional)

2.2.1 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

Operation	Command
Enable L2TP	l2tp enable
Disable L2TP	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:

l 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.

l Re-connect the remote user when the LAC does not serve as a client (that is, the remote user accesses the LAC through dialup).

2.2.2 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.

Table 2-2 Create/delete L2TP group

Operation	Command
Create an L2TP group	l2tp-group group-number
Delete an L2TP group	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.

2.2.3 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

Operation	Command
Configure to check whether the user is VPN user and set the IP address of an LNS	start l2tp { ip ip-addr [ ip ip-addr] [ ip ip-addr] ... } { domain domain-name \| fullusername user-name }
Cancel the Tunnel setup request configuration	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.

& Note:

l 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.

l 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.

2.2.4 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

Operation	Command
Set a local Tunnel name	Tunnel name name
Restore the default local Tunnel 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.

2.2.5 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 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

Operation	Command
Enable Tunnel authentication	Tunnel authentication
Disable Tunnel authentication	undo Tunnel authentication
Set the password of Tunnel authentication	Tunnel password { simple \| cipher } password
Restore the password of Tunnel authentication to the default	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.

2.2.6 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

Operation	Command
Configure to transfer AVP data in the hidden mode	Tunnel avp-hidden
Restore the default transfer mode of AVP data	undo Tunnel avp-hidden

By default, AVP data is transferred in plain text.

2.2.7 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 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

Operation	Command
Set Hello interval in a Tunnel	Tunnel timer hello hello-interval
Restore the default 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.

2.2.8 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

Operation	Command
Configure a user name and password (in system view)	local-user username
Delete the current setting (in system view)	undo local-user username
Configure local user password (in local user view)	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.

Table 2-9 Enable/Disable PPP user authentication mode

Operation	Command
Enable PPP user authentication	ppp authentication-mode { chap \| pap } [ call-in ] [ domain isp-name ]
Disable PPP user authentication	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

Operation	Command
Create an ISP domain and enter its view (in system view)	domain { isp-name \| default { disable \| enable isp-name } }
Delete the specified ISP domain (in system view	undo domain isp-name
Configure a local authentication scheme for the PPP domain user. (in ISP domain view)	scheme local

2.2.9 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

Operation	Command
Terminate a Tunnel	reset l2tp Tunnel {name remote-name \| id Tunnel-id }
Terminate a session	reset l2tp session session-id
Disconnect a user	reset l2tp user user-name user-name

2.2.10 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

Operation	Command
Enable flow control function of a Tunnel	Tunnel flow-control
Disable flow control function of a Tunnel	undo Tunnel flow-control

By default, the flow control function of Tunnels is disabled.

2.2.11 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

Operation	Command
Set the L2TP session idle-timeout timer	session idle-time time
Disable the L2TP session idle-timeout timer	undo session idle-time

By default, an L2TP session never expires.

2.2.12 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.

Table 2-14 Configure the Tunnel-hold function of L2TP

Operation	Command
Enable the Tunnel-hold function of L2TP	Tunnel keepstanding
Disable the Tunnel-hold function of L2TP	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

Operation	Command
Start an L2TP Tunnel connection	start l2tp Tunnel

2.2.13 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:

l Create a virtual template interface

l Configure the parameters of the virtual template interface, including IP address, PPP authentication mode, and username and password for PPP authentication

l Enable the virtual LAC client to set up an L2TP Tunnel

& 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

Operation	Command
Create a virtual template interface	interface virtual-template virtual-template-number
Delete a virtual template interface	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

Operation	Command
Assign an IP address to the virtual template interface	ip address { address mask \| ppp-negotiate \| unnumbered interface interface-type interface-number }
Configure a PPP authentication mode	ppp authentication-mode { pap \| chap }
Configure a username for CHAP authentication	ppp chap user user-name
Configure a password for CHAP authentication	ppp chap password { simple \| cipher } password
Configure a username and password for PAP authentication	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.

Table 2-18 Configure an L2TP Tunnel for the LAC client

Operation	Command
Enable the LAC client to set up L2TP Tunnel	l2tp-auto-client enable
Disable the LAC client from setting up L2TP Tunnel	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:

l Enable L2TP (required)

l Enable/disable the L2TP multi-domain function (optional)

l Create an L2TP group (required)

l Create a virtual template interface (required)

l Set the parameters for call receiving (required)

l Set a local name (optional)

l Set Tunnel authentication and password (optional)

l Set the transfer mode of AVP data (optional)

l Set Hello interval in the Tunnel (optional)

l Configure required local CHAP authentication (optional)

l Configure required LCP renegotiation (optional)

l Set local address and assigned address pool (optional)

l Set a user name and password and configure user authentication (optional)

l Terminate a Tunnel by force(optional)

l Enable/Disable the flow control function of Tunnel (optional)

l Set the L2TP session timeout timer (optional)

2.3.1 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.

Table 2-19 Enable/disable L2TP

Operation	Command
Enable L2TP	l2tp enable
Disable L2TP	undo l2tp enable

By default, L2TP is disabled.

2.3.2 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

Operation	Command
Enable the L2TP multi-domain function	l2tpmoreexam enable
Disable the L2TP multi-domain function	undo l2tpmoreexam enable

By default, the L2TP multi-domain function is disabled.

2.3.3 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

Operation	Command
Create L2TP group	l2tp-group group-number
Delete L2TP group	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, the local name and remote name of Tunnel.

By default, no L2TP group is created.

2.3.4 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

Operation	Command
Create a virtual template interface	interface virtual-template virtual-template-number
Delete the virtual template interface	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.

2.3.5 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.

Table 2-23 Set parameters for call receiving

Operation	Command
Set a name for the remote end of Tunnel (L2TP group not being 1)	allow l2tp virtual-template virtual-template-number remote remote-name [ domain domain-name ]
Set a name for the remote end of Tunnel (L2TP group being 1)	allow l2tp virtual-template virtual-template-number [ remote remote-name ] [ domain domain-name ]
Remove the name of the remote end of Tunnel	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:

l Only L2TP group 1 can be set to the default group.

l Any device can initiate a Tunnel setup request when the L2TP group number is 1, the default L2TP group number.

l The start command and the allow command are exclusive to each other. After one is configured, the other one goes invalid automatically.

l 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.

l 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.

2.3.6 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.

Table 2-24 Set local name

Operation	Command
Set a local name	Tunnel name name
Restore the default local name	undo Tunnel name

By default, the local name is the hostname of the SecBlade.

2.3.7 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

Operation	Command
Enable Tunnel authentication	Tunnel authentication
Disable Tunnel authentication	undo Tunnel authentication
Set a password for Tunnel authentication	Tunnel password { simple \| cipher } password
Remove the password for Tunnel authentication	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.

2.3.8 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.

Perform the following configuration in L2TP group view.

Table 2-26 Set the transfer mode of AVP data

Operation	Command
Configure to transfer AVP data in the hidden mode	Tunnel avp-hidden
Restore default transfer mode of AVP data	undo Tunnel avp-hidden

By default, AVP data is transferred in plain text.

2.3.9 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

Operation	Command
Set Hello interval	Tunnel timer hello hello-interval
Restore the default value of 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.

2.3.10 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 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

Operation	Command
Enable required local CHAP authentication	mandatory-chap
Disable local CHAP authentication	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.

2.3.11 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.

Table 2-29 Enable/disable required LCP re-negotiation

Operation	Command
Enable required LCP re-negotiation	mandatory-lcp
Disable required LCP re-negotiation	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.

2.3.12 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

Operation	Command
Set a local IP address	ip address X.X.X.X netmask
Remove the local IP address	undo ip address X.X.X.X netmask
Specify an address pool for remote address assignment	remote address { pool pool-number \| X.X.X.X }
Delete the address pool for remote address assignment	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.3.13 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.

2.3.14 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

Operation	Command
Terminate a Tunnel	reset l2tp Tunnel { name remote-name \| id Tunnel-id }
Terminate a session	reset l2tp session session-id
Disconnect a user	reset l2tp user user-name

2.3.15 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.

Table 2-32 Enable/disable flow control function of a Tunnel

Operation	Command
Enable flow control function of a Tunnel	Tunnel flow-control
Disable flow control function of a Tunnel	undo Tunnel flow-control

By default, the flow control function of Tunnels is disabled.

2.3.16 Setting the L2TP Session Timeout Timer

Perform the following configuration in L2TP group view.

Table 2-33 Set the L2TP session timeout timer

Operation	Command
Set the L2TP session timeout timer	session idle-time seconds
Disable the L2TP session timeout timer	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

Operation	Command
Display information about the current L2TP users	display l2tp user
Display information about the current L2TP Tunnels	display l2tp Tunnel
Display information about the current L2TP sessions	display l2tp session
Enable all types of L2TP debugging	debugging l2tp all
Disable all types of L2TP debugging	undo debugging l2tp all
Enable L2TP control packet debugging	debugging l2tp control
Disable L2TP control packet debugging	undo debugging l2tp control
Enable PPP packet debugging	debugging l2tp dump
Disable PPP packet debugging	undo debugging l2tp dump
Enable L2TP error debugging	debugging l2tp error
Disable L2TP error debugging	undo debugging l2tp error
Enable L2TP event debugging	debugging l2tp event
Disable L2TP event debugging	undo debugging l2tp event
Enable hidden AVP debugging	debugging l2tp hidden
Disable hidden AVP debugging	undo debugging l2tp hidden
Enable L2TP payload debugging	debugging l2tp payload
Disable L2TP payload debugging	undo debugging l2tp payload
Enable L2TP time stamp debugging	debugging l2tp time-stamp
Disable L2TP time stamp debugging	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:

l The L2TP user implements dial-up access.

l The NAS authenticates this user. The NAS sends a request to the LNS for establishing a Tunnel.

l 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.

l The LNS determines whether to accept this connection according to pre-negotiated content.

l The user and headquarters communicate through the Tunnel between the NAS and LNS.

II. Network diagram

Figure 2-6 Network diagram for L2TP

III. Configuration procedure

1) PC

IP address: 10.0.0.1/24

Gateway: 10.0.0.254

2) 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 50.0.0.1 24

[NAS-GigabitEthernet0/1] quit

# 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 50.0.0.254 fullusername l2tp

[NAS-l2tp1] quit

# Configure a static route.

[NAS] ip route-static 0.0.0.0 0 50.0.0.254

3) 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 10.0.0.254 24

[H3C-Vlan-interface10] quit

[H3C] interface vlan-interface 30

[H3C-Vlan-interface30] ip address 30.0.0.1 24

[H3C-Vlan-interface30] quit

# Configure a static route.

[H3C] ip route-static 0.0.0.0 0 30.0.0.254

# 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 50

# 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 30.0.0.254 24

[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 50.0.0.254 24

[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 100.0.0.254 24

[SecBlade-Virtual-Template0] remote address 100.0.0.1

[SecBlade-Virtual-Template0] ppp authentication-mode pap

[SecBlade-Virtual-Template0] quit

# Enable the L2TP service.

[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 0.0.0.0 0 50.0.0.1

[SecBlade] ip route-static 10.0.0.0 24 30.0.0.1

# 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:

l 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.

l 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.

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:

l 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.

l 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.

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:

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 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:

Figure 3-2 Format of encapsulated Tunnel packets

For instance, an IPX Delivery packet encapsulated in IP Tunnel is as follows:

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

Figure 3-4 Multi-protocol local network that makes transmission through a single-protocol backbone network

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)

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

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

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:

l Create a virtual Tunnel interface (required)

l Set encapsulation mode (optional)

l Specify source end of Tunnel (required)

l Specify destination end of Tunnel (required)

l Set the network address of Tunnel interface (required)

l Configure end-to-end verification on both ends of Tunnel (optional)

l Set identification key of Tunnel interface (optional)

l Configure routing through Tunnel (optional)

3.2.1 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.

Table 3-1 Create a virtual Tunnel interface

Operation	Command
Create a virtual Tunnel interface	interface Tunnel number
Delete a virtual Tunnel interface	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.

3.2.2 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

Operation	Command
Set an encapsulation mode on the Tunnel interface	Tunnel-protocol gre

By default, the encapsulation protocol is GRE.

3.2.3 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

Operation	Command
Specify the source address of the Tunnel	source { ip-addr \| interface-type interface-num }
Delete the source address of the Tunnel	undo source

& Note:

l The same source address and destination address cannot be configured on two or more Tunnel interfaces running the same protocol.

l 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.

3.2.4 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

Operation	Command
Set the destination address of the Tunnel	destination ip-addr
Delete the destination address of the Tunnel	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.

3.2.5 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.

Table 3-5 Assign network address to a Tunnel interface

Operation	Command
Assign an IP address to the Tunnel interface	ip address { ip-addr mask \| unnumbered interface interface-type interface-number }
Delete the IP address of the Tunnel interface	undo ip address

By default, the network address of the Tunnel interface is not configured.

3.2.6 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

Operation	Command
Enable end-to-end verification on both ends of the Tunnel	gre checksum
Disable end-to-end verification on both ends of the Tunnel	undo gre checksum

By default, end-to-end verification is disabled on both ends of a Tunnel.

3.2.7 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.

Table 3-7 Set identification key of the Tunnel interface

Operation	Command
Set the identification key of the Tunnel interface	gre key key-number
Cancel the identification key of Tunnel interface	undo gre key

The key-number argument is an integer in the range 0 to 4294967295.

By default, the Tunnel does not use a KEY.

3.2.8 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 Command 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 Command Manual accompanying this manual.

3.2.9 Configuring the Keepalive Function

Perform the following configuration in Tunnel interface view.

Table 3-8 Configure the keepalive function

Operation	Command
Enable the keepalive function of GRE	keepalive [ seconds ] [ times ]
Disable the keepalive function of GRE	undo keepalive [ seconds ] [ times ]

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

Operation	Command
Display operating state of Tunnel interfaces	display interface Tunnel number
Enable Tunnel information debugging	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.

II. Network diagram

Figure 3-8 Network diagram for GRE

III. Configuration procedure

1) PC-A

IP address: 10.0.0.1/24

Gateway: 10.0.0.254

2) PC-B

IP address: 20.0.0.1/24

Gateway: 20.0.0.254

3) Router

# Configure the interface address.

<Router> system-view

[Router] interface GigabitEthernet 0/0

[Router-GigabitEthernet0/0] ip address 50.0.0.1 24

[Router-GigabitEthernet0/0] quit

[Router] interface GigabitEthernet 0/1

[Router-GigabitEthernet0/1] ip address 60.0.0.1 24

[Router-GigabitEthernet0/1] quit

4) Switch A (SecBlade_A)

# Divide into VLANs.

<H3C_A> system-view

[H3C_A] vlan 10

[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 10.0.0.254 24

[H3C_A-Vlan-interface10] quit

[H3C_A] interface vlan-interface 30

[H3C_A-Vlan-interface30] ip address 30.0.0.1 24

[H3C_A-Vlan-interface30] quit

# Configure the static route.

[H3C_A] ip route-static 0.0.0.0 0 30.0.0.254

# 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 30.0.0.254 24

[SecBlade_A-GigabitEthernet0/0.1] quit

[SecBlade_A] interface GigabitEthernet 0/0.2

[SecBlade_A-GigabitEthernet0/0.2] vlan-type dot1q vid 50

[SecBlade_A-GigabitEthernet0/0.2] ip address 50.0.0.254 24

[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 100.0.0.1 24

# Configure Tunnel encapsulation mode.

[SecBlade_A-Tunnel0] Tunnel-protocol gre

# Configure the source address of the Tunnel.

[SecBlade_A-Tunnel0] source 50.0.0.254

# Configure the destination address of the Tunnel.

[SecBlade_A-Tunnel0] destination 60.0.0.254

[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 20.0.0.0 24 Tunnel 0

[SecBlade_A] ip route-static 10.0.0.0 24 30.0.0.1

[SecBlade_A] ip route-static 0.0.0.0 0 50.0.0.1

# 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 20.0.0.254 24

[H3C_B-Vlan-interface20] quit

[H3C_B] interface vlan-interface 40

[H3C_B-Vlan-interface40] ip address 40.0.0.1 24

[H3C_B-Vlan-interface40] quit

# Configure the static route.

[H3C_B] ip route-static 0.0.0.0 0 40.0.0.254

# 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 40.0.0.254 24

[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 60.0.0.1 24

[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 100.0.0.2 24

# Configure Tunnel encapsulation mode.

[SecBlade_B-Tunnel0] Tunnel-protocol gre

# Configure the source address of the Tunnel.

[SecBlade_B-Tunnel0] source 60.0.0.254

# Configure the destination address of the Tunnel.

[SecBlade_B-Tunnel0] destination 50.0.0.254

[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 10.0.0.0 24 Tunnel 0

[SecBlade_B] ip route-static 20.0.0.0 24 40.0.0.1

[SecBlade_A] ip route-static 0.0.0.0 0 60.0.0.1

# 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:

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:

l 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 10.2.0.0/16 on Switch A, and the route from interface Tunnel 2/0/0 to 10.1.0.0/16 on Switch B.

l 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 10.2.0.0 255.255.0.0 Tunnel 0

Chapter 4 IPSec Configuration

4.1 IPSec Overview

4.1.1 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.

l AH mainly provides data source authentication, data integrity authentication and anti-replay. However, it cannot encrypt the protected packets.

l 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.

l 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.

4.1.2 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.

4.1.3 Basic Concepts of IPSec

I. Security association

IPSec provides secure communication between two ends, which are called as IPSec peers.

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:

l Time-based duration is to update SA at a specific interval;

l 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:

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.

l MD5: Input a message with any length and generate a 128-bit message summary.

l SHA-1: Input a less than 2⁶⁴-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:

l Data encryption standard (DES): Encrypt a 64-bit plain text using a 56-bit key.

l Triple DES (3DES): Encrypt a plain text using three 56-bit keys (168 bits key).

l Advanced encryption standard (AES): 128-bit 192-bit and 256-bit AES algorithm, compliant with IETF standards, can be implemented on the VRP.

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 RFC2408.

1) Timers

IPSec DPD uses the following two timers to control sending and receipt of DPD packets:

l 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.

l Time_out: specifies the time waiting for a DPD acknowledgement.

2) Operating mechanism

The following describers how DPD operates after being enabled:

l At the sender side

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.

l 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.

4.1.4 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

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

l Create a security proposal (IPSec proposal or card SA proposal)

l Specify the encryption card used in the card SA proposal (only applies to encryption cards)

l Select security protocol

l Select security algorithm

l Select packet encapsulation mode

3) Create IPSec policy (manually or by using IKE)

For the manual mode:

l Create IPSec policy

l Import ACL into IPSec policy

l Configure starting and end points for Tunnel

l Configure SPI for SA

l Configure SA keys

For the IKE mode:

l Create IPSec policy using IKE

l Import card SA proposal into IPSec policy

l Import ACL into IPSec policy

l Import IKE peer into IPSec policy

l Configure SA duration (optional)

l 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

4.2.1 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.

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 173.1.1.0 0.0.0.255 destination 173.2.2.0 0.0.0.255

Peer end:

acl number 3101

rule 1 permit ip source 173.2.2.0 0.0.0.255 destination 173.1.1.0 0.0.0.255

& Note:

l 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.

l 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.

4.2.2 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.

l Create an IPSec or card SA proposal

l Specify the encryption card in the card SA proposal (only applied when an encryption card is involved)

l Select a security algorithm

l Set the mode adopted by the security protocol in IP datagram encapsulation

l Select a security protocol

l 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

Operation	Command
Create an IPSec proposal and access the IPSec proposal view (for IPSec module)	ipsec proposal proposal-name
Delete the IPSec proposal (for IPSec module)	undo ipsec proposal proposal-name
Create a card SA proposal and access its view (for encryption cards only )	ipsec card-proposal proposal-name
Delete the card SA proposal (for encryption card)	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

Operation	Command
Enter the encryption card SA proposal view	ipsec card-proposal proposal-name
Assign an encryption card to the card SA proposal	use encrypt-card slot-id
Remove the configuration	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

Operation	Command
Set the IP datagram encapsulation mode adopted by the security protocol	encapsulation-mode { transport \| Tunnel }
Restore the default encapsulation mode	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

Operation	Command
Configure a security protocol used by IPSec proposal	transform { ah \| ah-esp \| esp }
Restore default security protocol	undo transform

By default, use esp, i.e. RFC2406-specified ESP.

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

Operation	Command
Configure an encryption algorithm used by ESP	esp encryption-algorithm { 3des \| des \| aes \| nsa }
Configure ESP not to authenticate packets	undo esp encryption-algorithm
Configure an authentication algorithm used by ESP	esp authentication-algorithm { md5 \| sha1 \| hnsa }
Configure ESP not to authenticate packets	undo esp authentication-algorithm
Configure an authentication algorithm used by AH	ah authentication-algorithm { md5 \| sha1 }
Restore the default authentication algorithm used by AH	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 md5.

& 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.

4.2.3 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

Operation	Command
Manually create an IPSec policy for an SA	ipsec policy policy-name seq-number manual
Modify the IPSec policy of the SA	ipsec policy policy-name seq-number manual
Delete the IPSec policy	undo ipsec policy policy-name [ seq-number ]

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

Operation	Command
Configure IPSec proposal referenced by IPSec policy	proposal proposal-name1 [ proposal-name2... proposal-name6 ]
Remove IPSec proposal referenced by IPSec policy	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

Operation	Command
Configure an ACL referenced by IPSec policy	security acl acl-number
Remove an ACL referenced by IPSec policy	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.

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

Operation	Command
Configure a local address in the IPSec policy	Tunnel local ip-address
Delete the local address configured in the IPSec policy	undo Tunnel local
Configure a peer address in the IPSec policy	Tunnel remote ip-address
Delete the peer address configured in the IPSec policy	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

Operation	Command
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 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

Operation	Command
Configure an AH authentication key (in hexadecimal form)	sa authentication-hex { inbound \| outbound } { ah \| esp } hex-key
Configure an protocol key (in character string)	sa string-key { inbound \| outbound } { ah \| esp } string-key
Configure an ESP encryption key (in hexadecimal form)	sa encryption-hex { inbound \| outbound } esp hex-key
Delete the configured SA parameter	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.

l Create an IPSec policies by using IKE

l Reference an IPSec proposal in the IPSec policy

l Configure an ACL referenced by the IPSec policy

l Referencing an IKE peer in the IPSec policy

l Configure the lifetime of an SA (optional)

l Configure the PFS feature in negotiation (optional)

l 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

Operation	Command
Create an IPSec policy by using IKE and access IPSec policy view	ipsec policy policy-name seq-number isakmp
Dynamically create an IPSec policy by using IKE and an IPSec policy template	ipsec policy policy-name seq-number isakmp [ template template-name ]
Modify an IPSec policy that has been established by using IKE negotiation	ipsec policy policy-name seq-number isakmp
Delete the specified IPSec policy	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

Operation	Command
Reference an IPSec proposal in the IPSec policy	proposal proposal-name1 [ proposal-name2... proposal-name6 ]
Remove the IPSec proposal referenced by the IPSec policy	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 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

Operation	Command
Reference an ACL in the IPSec policy	security acl acl-number
Remove the ACL referenced by the IPSec policy	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

Operation	Command
Reference an IKE peer in the IPSec policy	ike peer peer-name
Remove the referenced IKE peer from the IPSec policy	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)

l 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.

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

Operation	Command
Configure a global SA lifetime	ipsec sa global-duration { traffic-based kilobytes \| time-based seconds }
Restore the default global SA lifetime	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.

l 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

Operation	Command
Configure an SA lifetime for the IPSec policy	sa duration { traffic-based kilobytes \| time-based seconds }
Adopt the configured global SA lifetime	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. 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

Operation	Command
Configure the PFS feature used in negotiation	pfs { dh-group1 \| dh-group2 \| dh-group5 \| dh-group14 }
Disable PFS in negotiation	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)

l Creating a DPD structure

Perform the following configuration in system view.

Table 4-19 Create a DPD structure and enter its view

Operation	Command
Create a DPD structure and enter its view	ike dpd dpd-name
Delete the specified DPD structure	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.

l Configuring timers

Perform the following configuration in DPD structure view.

Table 4-20 Configure timers

Operation	Command
Configure the interval for triggering a DPD query	interval time seconds
Restore the default interval for triggering a DPD query	undo interval time
Configure the time-out time waiting for a DPD acknowledgment	time out seconds
Restore the default time-out time waiting for a DPD acknowledgment	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.

l 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

Operation	Command
Specify a DPD structure for the IKE peer	dpd dpd-name
Remove the referenced DPD structure	undo dpd

4.2.4 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

Operation	Command
Create/Modify an IPSec policy template	ipsec policy-template policy-template-name seq-number
Delete an IPSec policy template	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.

& 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

Operation	Command
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.

4.2.5 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.

Table 4-24 Use IPSec policy group

Operation	Command
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.

4.2.6 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

Operation	Command
Disable the check of the next-payload field in the last payload of the IKE negotiation packet during IPSec negotiation	ike next-payload check disabled
Remove the default	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.2.7 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

Operation	Command
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

Operation	Command
Turn up the encryption card	undo shutdown
Shut down the encryption card	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.

Table 4-28 Configure IPSec module backup function

Operation	Command
Enable IPSec module backup function	encrypt-card backuped
Disable IPSec module backup function	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

Operation	Command
Enable the fast forwarding function of the encryption card	encrypt-card fast-switch
Disable the fast forwarding function of the encryption card	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.

Perform the following configuration in system view.

Table 4-30 Configure trap function on encryption card

Operation	Command
Enable the trap function on encryption card	snmp-agent trap enable encrypt-card
Disable the trap function on encryption 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

4.3.1 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

Operation	Command
Display SA related information	display ipsec sa [ brief \| remote ip-address \| policy policy-name [ seq-number ] \| duration ]
Display the information about IPSec Tunnel	display ipsec Tunnel
Display statistical information on IPSec processed packets	display ipsec statistics
Display an IPSec proposal	display ipsec proposal [ proposal-name ]
Display an IPSec policy	display ipsec policy [ brief \| name policy-name [ seq-number ] ]
Display an IPSec policy template	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 }
Disable the IPSec debugging function	undo debugging ipsec { all \| sa \| packet [ policy policy-name [ seq-number ] \| parameters ip-address protocol spi-number ] \| misc }
Enable the debugging for DPD	debugging ike dpd
Disable the debugging for 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

Operation	Command
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

Operation	Command
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.3.2 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

Operation	Command
Display interface information on the encryption card	display interface encrypt [ slot-id ]
Display information about the fast forwarding entry for the encryption cards	display encrypt-card fast-switch
Enable VRP test software debugging on the encryption card	debugging encrypt-card host { all \| packet \| sa \| command \| error \| misc }
Disable VRP test software debugging on the encryption card	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)

Operation	Command
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.

Table 4-36 Delete SA

Operation	Command
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

Operation	Command
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

Operation	Command
Clear system log information on encryption card	reset encrypt-card syslog [ slot-id ]

& 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

Operation	Command
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

Figure 4-2 Network diagram for IPSec

III. Configuration procedure

1) PC_A

IP address: 10.0.0.1/24

Gateway: 10.0.0.254

2) PC_B

IP address: 20.0.0.1/24

Gateway: 20.0.0.254

3) Router

# Configure an interface IP address.

<Router> system-view

[Router] interface GigabitEthernet 0/0

[Router-GigabitEthernet0/0] ip address 50.0.0.1 24

[Router-GigabitEthernet0/0] quit

[Router] interface GigabitEthernet 0/1

[Router-GigabitEthernet0/0] ip address 20.0.0.254 24

[Router-GigabitEthernet0/0] quit

# Configure ACL rules.

[Router] acl number 3000

[Router-acl-adv-3000] rule permit ip source 20.0.0.0 0.0.0.255 destination 10.0.0.0 0.0.0.255

[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 50.0.0.254

[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

# Configure a static route.

[Router] ip route-static 0.0.0.0 0 50.0.0.254

4) 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 10.0.0.254 24

[H3C-Vlan-interface10] quit

[H3C] interface vlan-interface 30

[H3C-Vlan-interface30] ip address 30.0.0.1 24

[H3C-Vlan-interface30] quit

# Configure a static route.

[H3C] ip route-static 0.0.0.0 0 30.0.0.254

# 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

# 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 30.0.0.254 24

[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 50.0.0.254 24

[SecBlade-GigabitEthernet0/0.2] quit

# Configure an ACL rule.

[SecBlade] acl number 3000

[SecBlade-acl-adv-3000] rule permit ip source 10.0.0.0 0.0.0.255 destination 20.0.0.0 0.0.0.255

[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 50.0.0.1

[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 0.0.0.0 0 50.0.0.1

[SecBlade] ip route-static 10.0.0.0 24 30.0.0.1

# Quit SecBlade configuration view.

[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.

Chapter 5 IKE Configuration

5.1 IKE Overview

5.1.1 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:

l 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.

l 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.

l 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.

l Identity protection

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.

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 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.

5.1.2 Preparation for IKE Configuration

Prior to IKE configuration, you need to specify following items, so as to smooth the configuration process:

l 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.

l Determine the identity authentication key of both sides in communication.

5.2 IKE Configuration

5.2.1 Introduction to IKE Configuration

IKE configuration includes:

1) Set a name for the local SecBlade

2) Define IKE proposal

l Establish IKE Proposal

l Select encryption algorithm

l Select authentication method

l Select authentication algorithm

l Select Diffie-Hellman group ID

l Set lifetime of ISAKMP SA (optional)

3) Configure IKE peer

l Create an IKE peer

l Configure IKE negotiation mode

l Configure identity authentication key (pre-shared key)

l Configure ID type in IKE negotiation

l Configure IP address in IKE negotiation

l Configure NAT traversal

l Configure subnet type of the IKE peer

4) Configure the parameters of Keepalive timer

l Configure interval for Keepalive transmission

l Configure timeout time for Keepalive

5.2.2 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

Operation	Command
Configure the name of the local SecBlade	ike local-name name
Restore the default name of the local SecBlade	undo ike local-name

5.2.3 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

Operation	Command
Create IKE proposal	ike proposal proposal-number
Delete IKE proposal	undo ike proposal proposal-number

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

Operation	Command
Select an encryption algorithm	encryption-algorithm { des-cbc \| 3des-cbc }
Set the encryption algorithm to the default value	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

Operation	Command
Specify authentication method	authentication-method { pre-share \| rsa-signature }
Restore the authentication method to the default value	undo authentication-method

By default, the pre-share key algorithm is adopted.

& Note:

l For details on PKI configuration, refer to PKI Configuration in this manual.

l 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

Operation	Command
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

Operation	Command
Select Diffie-Hellman group ID	dh { group1 \| group2 \| group5 \| group14 }
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

Operation	Command
Configure lifetime of IKE SA	sa duration seconds
Restore the default lifetime	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).

5.2.4 Configuring IKE Peer

I. Creating an IKE peer

Perform the following configuration in system view.

Table 5-8 Configure IKE peer

Operation	Command
Configure an IKE peer and access IKE peer view	ike peer peer-name
Delete the IKE peer	undo ike peer peer-name

II. Configuring IKE negotiation mode

Perform the following configuration in IKE-peer view.

Table 5-9 Configure negotiation mode

Operation	Command
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:

l If the IP address of one end of a security Tunnel is dynamic, you must adopt the aggressive mode for IKE negotiation.

l 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

Operation	Command
Configure a pre-shared key for IKE negotiation	pre-shared-key key
Remove the pre-shared key used in IKE negotiation	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

Operation	Command
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.

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

Operation	Command
Specify the name of a remote device	remote-name name
Remove the name of the remote device	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

Operation	Command
Configure IP address of the local SecBlade	local-address ip-address
Delete IP address of the local SecBlade	undo local-address
Configure IP address of the remote device	remote-address low-ip-address high-ip-address
Delete the IP address of the remote device	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).

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

Operation	Command
Enable the NAT traversal function of IPSec/IKE	nat-traversal
Disable the NAT traversal function of IPSec/IKE	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

Operation	Command
Configure subnet type of the local gateway	local { multi-subnet \| single-subnet }
Restore the default subnet type of the local gateway	undo local
Configure subnet type of the peer gateway	peer { multi-subnet \| single-subnet }
Restore the default subnet type of the peer gateway	undo peer

By default, the subnet type of both the local end and the remote end is single-subnet.

5.2.5 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.

Table 5-16 Configure the interval for Keepalive packet transmission

Operation	Command
Configure the interval at which an ISAKMP SA transmits a Keepalive packet to the peer	ike sa keepalive-timer interval seconds
Disable the above function	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:

l 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.

l 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

Operation	Command
Configure ISAKMP SA timeout time for waiting for Keepalive packet	ike sa keepalive-timer timeout seconds
Disable this function	undo ike sa keepalive-timer timeout

IKE maintains this ISAKMP SA link status through this packet.

When the configured timeout time expires:

l 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

Operation	Command
Define the interval at which the IKE peer sends NAT Keepalive packets	ike sa nat-keepalive-timer interval seconds
Restore the default NAT Keepalive interval	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

Operation	Command
Display the current established security tunnel	display ike sa [ verbose [ connection-id id \| remote-address ip-address ] ]
Display the parameters of each IKE proposal	display ike proposal
Display the configuration of IKE peers	display ike peer [ peer-name ]
Delete a security tunnel	reset ike sa [ connection-id ]
Enable information debugging of IKE	debugging ike { all \| error \| exchange \| message \| misc\| transport }
Disable information debugging of IKE	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

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.

Symptom 2: Proposal mismatch

Troubleshooting:

Following is the debugging information you may view on the screen:

got NOTIFY of type NO_PROPOSAL_CHOSEN

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:

l Use the command display ike sa to check whether both parties have established an SA of Phase 1.

l Use the command display ipsec sa to check whether the IPSec policy on an interface has established an IPSec SA.

l 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.

Chapter 6 PKI Configuration

6.1 PKI Overview

6.1.1 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.

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.2 Terminology

l 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.

l 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.

l 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.

l 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.

l 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.

6.1.3 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 Email 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.

6.1.4 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:

l PKI certificate request

l PKI certificate validation

l Display and debug

6.2 Certificate Request Configuration

6.2.1 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 Email, 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:

l Entering PKI domain view

l Specifying a trustworthy CA

l Configuring servers for certificate request

l Configuring entity name space

l Creating a local public/private key pair

l Setting request polling interval and count

l Configuring certificate request mode

l Making a certificate request manually

l Obtaining a certificate

6.2.2 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

Operation	Command
Specify a PKI domain and enter a designated PKI domain view	pki domain name
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.

6.2.3 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

Operation	Command
Specify a trustworthy CA	ca identifier name
Delete the trustworthy CA	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.2.4 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

Operation	Command
Configure the entity used to apply for a certificate	certificate request entity entity-name
Cancel the configured entity used to apply for a certificate	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

Operation	Command
Choose q registration organization	certificate request from { ca \| ra }
Delete the registration organization	undo certificate request from

By default, no registration organization is specified.

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

Operation	Command
Specify the location of a registration server	certificate request url string
Delete the location setting	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

Operation	Command
Specify the IP address of the LDAP server	ldap-server ip ip-address [ port port-num ] [ version version-number ]
Delete the IP address of the LDAP server	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, 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

Operation	Command
Configure the fingerprint for root certificate authentication	root-certificate fingerprint { md5 \| sha1 } string
Cancel the configured fingerprint for root certificate authentication	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.

6.2.5 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:

l PKI entity name

l Entity FQDN

l Country code

l State name

l Geographic locality

l Organization name

l General name of the entity

l IP address of the entity

& 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

Operation	Command
Specify an entity name and enter the entity view	pki entity name-str
Delete the entity name and relative parameters	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, Email 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

Operation	Command
Configure the entity FQDN	fqdn name-str
Delete the entity FQDN	undo fqdn

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

Operation	Command
Configure the country code for the entity	country country-code-str
Delete the country code for the entity	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

Operation	Command
Configure the state name for the entity	state state-str
Delete the state name for the entity	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

Operation	Command
Configure the geographic locality for the entity	locality locality-str
Delete the geographical locality for the entity	undo locality

By default, no geographic locality is specified for the entity.

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

Operation	Command
Configure the organization name for the entity	organization org-str
Delete the organization name for the entity	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

Operation	Command
Configure the organizational unit name for the entity	organization-unit org-unit-str
Delete the organizational unit name for the entity	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

Operation	Command
Configure the general name for the entity	common-name name-str
Delete the general name for the entity	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.

Table 6-16 Configure the IP address for the entity

Operation	Command
Configure the IP address for the entity	ip ip-address
Delete the IP address for the entity	undo ip

By default, no IP address is specified for the entity.

6.2.6 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

Operation	Command
Create a local RSA key pair	rsa local-key-pair create
Destroy a local RSA key pair	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.

Caution:

l 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.

l If a local RSA key pair exists, the newly-generated key pair will overwrite the existing one.

l 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.

6.2.7 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

Operation	Command
Configure polling interval and count	certificate request polling { interval minutes \| count count }
Restore the default values	undo certificate request polling { interval \| count }

By default, a request polling message is sent for 50 times at an interval of 20 minutes.

6.2.8 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.

Table 6-19 Configure certificate request mode

Operation	Command
Configure certificate request mode	certificate request mode { manual \| auto [ key-length key-length \| password { simple \| cipher } password ]* }
Restore the default request mode	undo certificate request mode

By default, the manual mode is selected.

6.2.9 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

Operation	Command
Make a certificate request	pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ]

Caution:

l 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.

l 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.

l 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.

l 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.

l This operation will not be saved in the configuration.

6.2.10 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

Operation	Command
Retrieve a certificate and download it locally	pki retrieval-certificate { local \| ca } domain domain-name

Caution:

l 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.

l This operation will not be saved in the configuration.

6.2.11 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

Operation	Command
Import a certificate	pki import-certificate { local \| ca } domain domain-name { der \| p12 \| pem } [ filename filename ]

6.2.12 Deleting Certificates

You can delete an existing local certificate or CA certificate using the command below.

Perform the following configuration in system view.

Table 6-23 Delete a certificate

Operation	Command
Delete a certificate	pki delete-certificate { local \| ca } domain domain-name

6.3 Certificate Authentication Configuration

6.3.1 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 Email, 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:

l Specify CRL distribution point location

l Configure CRL update interval

l Enable/Disable CRL check

l Retrieve CRL

l Verify certificate validity

6.3.2 Specifying CRL Distribution Point location

Perform the following configuration in PKI domain view.

Table 6-24 Configure CRL distribution point location

Operation	Command
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.

6.3.3 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.

Table 6-25 Configure CRL update period

Operation	Command
Specify CRL update interval	crl update-period hours
Restore the default interval	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.

6.3.4 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

Operation	Command
Disable CRL check	crl check disable
Enable CRL check	undo crl check disable

By default, CRL check is enabled.

6.3.5 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

Operation	Command
Retrieve a CRL and download it locally	pki retrieval-crl domain domain-name

& Note:

This operation will not be saved in configuration.

6.3.6 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

Operation	Command
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 email 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

Operation	Command
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 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

Operation	Command
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

Operation	Command
Enable PKI debugging	debugging pki { all \| verify \| request \| retrieval \| error }
Disable PKI debugging	undo debugging pki { all \| verify \| request \| retrieval \| error }

By default, all types of PKI debugging are disabled.

6.5 PKI Configuration Example

6.5.1 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.

II. Network diagram

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 10.0.0.254 24

[H3C-Vlan-interface10] quit

[H3C] interface vlan-interface 30

[H3C-Vlan-interface30] ip address 30.0.0.1 24

[H3C-Vlan-interface30] quit

# Configure the static route.

[H3C] ip route-static 0.0.0.0 0 30.0.0.254

# 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 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 30.0.0.254 24

[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 50.0.0.254 24

[SecBlade-GigabitEthernet0/0.2] quit

# Configure the static route.

[SecBlade] ip route-static 10.0.0.0 24 30.0.0.1

[SecBlade] ip route-static 0.0.0.0 0 50.0.0.1

# 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 http://201.1.1.1/certsrv/mscep/mscep.dll

[SecBlade_VPN-pki-domain-1] certificate request from ra entity en

[SecBlade_VPN-pki-domain-1] ldap-server ip 201.1.1.2

# Specify CRL distribution point location (you need not specify it if CRL check is disabled).

[SecBlade_VPN-pki-domain-1] crl url ldap://201.1.1.2

# Configure the entity DN.

[SecBlade_VPN] pki entity en

[SecBlade_VPN-pki-entity-en] ip 50.0.0.254

[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

6.6.1 Symptom 1: Failure to retrieve certificates

Solution: The following reasons may cause failure to make CA certificate requests manually;

1) Software

l No trustworthy CA name is set.

l The URL of the registration server is wrong or not configured. You can use the ping command to test the server’s connectivity.

l No RA is specified.

2) Hardware

l Check whether there is something wrong with the network connection, for example, the cable is broken or the connectors are loose.

6.6.2 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

l You do not have CA/RA certificates before certificate requests.

l No key pair is created or the current key pair has already had its certificate.

l No trustworthy CA name is specified.

l The URL of the registration server is wrong or not configured. You can use the ping command to test the server’s connectivity.

l No RA is specified.

l 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

l Check whether there is something wrong with the network connection, for example, the cable is broken or the connectors are loose.

6.6.3 Symptom 3: Failure to Retrieve CRL

Solution: The following reasons may cause failure to retrieve CRLs.

1) Software

l You do no have local certificates before retrieving CRL.

l The IP address of the LDAP server is not set.

l The CRL distribution point location is not specified.

l The version of LDAP server is wrong.

2) Hardware

l Check whether there is something wrong with the network connection, for example, the cable is broken or the connectors are loose.

Chapter 7 DVPN

7.1 Introduction to DVPN

7.1.1 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.

7.1.2 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.

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.

7.1.3 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.

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.

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.

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.

7.1.4 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.

Figure 7-2 Basic structure of DVPN

7.1.5 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:

l 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.

l 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.

l 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.)

l 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.

l Not secure. Layer 2 tunnel protocol (L2TP) and GRE do not encrypt packets. However, IPSec provides satisfactory security for packets forwarded across IPSec VPNs.

l 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:

l 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 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.

l 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.

l 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.

l 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.

l 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.

l 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.

l 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.

l 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.

l 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.

l 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:

l Enable/Disable DVPN

l Configure the client registration interval

l Configure the registering retries

l Configure the dumb interval

2) Tunnel interface configuration

Tunnel interface configuration includes the following:

l Configure the packet encapsulation format (UDP DVPN)

l Configure the Tunnel interface to client type

l Configure the source address or source interface of the Tunnel interface

l Configure the DVPN class to be applied to the Tunnel interface

l Configure the DVPN domain the Tunnel interface belongs to

l Configure register type (optional)

l Configure IPSec-encrypted data stream

3) DVPN class configuration

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:

l Create a DVPN class and enter its view

l Assign a public IP address to the DVPN server

l Assign a private IP address to the DVPN server (optional)

l Configure the register algorithm suite (optional. The default registering algorithm suite is DES-MD5-DH1.)

l Specify how the client authenticates the DVPN server (optional. NONE by default)

l Configure the pre-shared-key used when the client authenticates the DVPN server (optional)

l 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:

l Enable/Disable DVPN

l Configure the map aging interval

l Configure how to authenticate the clients

l Configure the pre-shared-key

2) Tunnel interface configuration

Tunnel interface configuration includes the following:

l Configure the packet encapsulation format (UDP DVPN)

l Configure the Tunnel interface to server

l Configure the DVPN domain the Tunnel interface belongs to

l Configure the source address or source interface of the Tunnel interface

l Configure the DVPN policy the Tunnel interface uses (optional)

l Configure IPSec-encrypted data stream

3) DVPN policy suite configuration

DVPN policy suite configuration includes the following:

l Create a DVPN policy and enter DVPN policy view

l Configure how the DVPN server authenticates the clients (optional and is NONE by default)

l Configure the algorithm suite for a specified session (optional and is des-md5-dh1 by default)

l Configure the idle timeout time for a specified session (optional and is 300 seconds by default)

l Configure the interval for sending keepalive packets (optional and is 10 seconds by default)

l Configure the interval for sending requests to establish a session (optional and is 10 seconds by default)

l Configure the IPSec algorithm suite (optional and is des-md5-dh1 by default)

l 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.

7.2.1 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

Operation	Command
Enable DVPN	dvpn service enable
Disable DVPN	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

Operation	Command
Configure a pre-shared-key	dvpn server pre-shared-key key
Remove a pre-shared-key	undo dvpn server pre-shared-key

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

Operation	Command
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

Operation	Command
Configure the map age interval	dvpn server map age-time time
Revert the map age interval to the default	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.

Table 7-5 Configure the interval for client registration

Operation	Command
Configure the interval for client registration	dvpn client register-interval time-interval
Restore the default registration interval for the client	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

Operation	Command
Configure the registration retries for the client	dvpn client register-retry times
Restore the default register retries for the client	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

Operation	Command
Configure the dumb interval for the client	dvpn client register-dumb time
Restore the default dumb interval for the client	undo dvpn client register-dumb

The default dumb interval for the client is 300 seconds.

7.2.2 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

Operation	Command
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

Operation	Command
Configure the type of the Tunnel interface	dvpn interface-type { client \| server }
Restore the default type of Tunnel interfaces	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.

Table 7-10 Configure registration type for a DVPN client

Operation	Command
Configure registration type for the DVPN client	dvpn register-type { forward \| undistributed } *
Remove the configuration	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

Operation	Command
Configure the DVPN domain the Tunnel interface belongs to	dvpn dvpn-id dvpn-id
Restore the Tunnel interface to the default	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

Operation	Command
Configure the source end address or source interface of the Tunnel interface	source { ip-address \| interface-type interface-number }
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

Operation	Command
Configure the DVPN class to be applied to the Tunnel interface	dvpn server dvpn-class-name
Remove the DVPN class applied to the Tunnel interface	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

Operation	Command
Configure the DVPN policy to be applied to the Tunnel interface	dvpn policy dvpn-policy-name
Remove the DVPN policy applied to the Tunnel interface	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.

Table 7-15 Configure IPSec-encrypted data stream

Operation	Command
Configure the IPSec-encrypted data stream	dvpn security acl acl-number
Remove the IPSec-encrypted data stream	undo dvpn security acl

No IPSec-encrypted data stream is configured on the Tunnel interface by default.

7.2.3 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

Operation	Command
Create a DVPN class and enter its view	dvpn class dvpn-class-name
Remove a DVPN class	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

Operation	Command
Assign a public IP address to the DVPN server	public-ip ip-address
Remove a public IP address	undo public-ip

A DVPN server is not assigned a public IP address by default.

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

Operation	Command
Assign a private IP address to a DVPN server	private-ip ip-address
Remove the private 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

Operation	Command
Configure the register algorithm suite	algorithm-suite suite-number
Restore the default register algorithm suite	undo algorithm-suite

By default, the suite-number parameter is 1, that is, DES-MD5-GROUP1. Refer to Command 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

Operation	Command
Specify to authenticate the DVPN server using the pre-shared-key	authentication-server method pre-share
Specify not to authenticate the DVPN server	authentication-server method none

A client does not authenticate a DVPN server by default.

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

Operation	Command
Configure a pre-shared-key for a authenticating DVPN server	pre-shared-key key
Remove the configured pre-shared-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

Operation	Command
Configure the user name and password for a client	local-user username password { simple \| cipher } password
Remove the user name and password of a client	undo local-user

A client is not configured with a user name and password by default.

7.2.4 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.

Table 7-23 Create a DVPN policy

Operation	Command
Create a DVPN policy and enter its view	dvpn policy dvpn-policy-name
Remove a DVPN policy	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

Operation	Command
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

Operation	Command
Configure the encryption algorithm suite for a session	session algorithm-suite suite-number
Restore the default encryption algorithm suite	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).

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

Operation	Command
Configure the idle timeout time for a session	session idle-time time-interval
Restore the default idle time out time	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

Operation	Command
Configure the interval for sending keepalive packets	session keepalive-interval time-interval
Restore the default interval for sending keepalive packets	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

Operation	Command
Configure the interval for sending requests to establish a session	session setup-interval time-interval
Restore the default interval for sending requests to establish a session	undo session setup-interval

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

Operation	Command
Configure the IPSec algorithm suite	data algorithm-suite suite-number
Restore the default IPSec algorithm suite	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

Operation	Command
Configure the timeout time to renegotiate a specified IPSec SA	data ipsec-sa duration time-based time-interval
Restore the default timeout time to renegotiate a specified IPSec SA	undo data ipsec-sa duration time-based

The default timeout time to renegotiate a specified IPSec SA is 3,600 seconds.

7.2.5 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.

Table 7-31 Display and debug DVPN

Operation	Command
Enable/Disable debugging for DVPN	[ undo ] debugging dvpn { all \| error \| event { all \| register \| session \| misc } \| hexadecimal \| packet { all \| control \| data \| ipsec } }
Display global information about DVPN in a system or information about a DVPN domain	display dvpn info { dvpn-id dvpn-id \| global }
Display information about maps in a DVPN domain	display dvpn map { all \| dvpn-id dvpn-id \| public-ip public-ip }
Display information about sessions in a DVPN domain	display dvpn session { all \| dvpn-id dvpn-id [ private-ip private-ip ] }
Display information about IPSec SAs in a DVPN domain	display dvpn ipsec-sa { all \| dvpn-id dvpn-id [ private-ip private-ip ] }
Display information about online DVPN users	display dvpn online-user
Initiate a DVPN domain	reset dvpn all dvpn-id
Clear a specified map	reset dvpn map public-ip port [ control-id ]
Clear a specified session	reset dvpn session dvpn-id private-ip
Clear DVPN statistics	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:

l 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.

l 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

Figure 7-3 Network diagram for DVPN

III. Configuration procedure

1) Configure a server

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 70.0.0.254 24

[H3C-Vlan-interface70] quit

[H3C] interface vlan-interface 80

[H3C-Vlan-interface80] ip address 80.0.0.1 24

[H3C-Vlan-interface80] quit

# Configure the static route.

[H3C] ip route-static 0.0.0.0 0 80.0.0.254

# 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/0.1

[SecBlade_Srv-GigabitEthernet0/0.1] vlan-type dot1q vid 80

[SecBlade_Srv-GigabitEthernet0/0.1] ip address 80.0.0.254 24

[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 90.0.0.254 24

[SecBlade_Srv-GigabitEthernet0/0.2] quit

# Configure a static route.

[SecBlade_Srv] ip route-static 70.0.0.0 24 80.0.0.1

# 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 192.168.0.254 255.255.255.0

[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 10.0.0.0 255.255.255.0 192.168.0.1

[SecBlade_Srv] ip route-static 20.0.0.0 255.255.255.0 192.168.0.2

2) 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 10.0.0.254 24

[H3C-Vlan-interface10] quit

[H3C] interface vlan-interface 30

[H3C-Vlan-interface30] ip address 30.0.0.1 24

[H3C-Vlan-interface30] quit

# Configure the static route.

[H3C] ip route-static 0.0.0.0 0 30.0.0.254

# 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 30.0.0.254 24

[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 50.0.0.254 24

[SecBlade_Clnt1-GigabitEthernet0/0.2] quit

# Configure a static route.

[SecBlade_Clnt1] ip route-static 10.0.0.0 24 30.0.0.1

# Enable the DVPN function.

[SecBlade_Clnt1] dvpn service enable

# Configure dvpn-class.

[SecBlade_Clnt1] dvpn class testserver

[SecBlade_Clnt1-dvpn-class-testserver] public-ip 90.0.0.254

[SecBlade_Clnt1-dvpn-class-testserver] quit

# Configure attributes for Tunnel 0 interface.

[SecBlade_Clnt1] interface Tunnel 0

[SecBlade_Clnt1-Tunnel0] ip address 192.168.0.1 255.255.255.0

[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 70.0.0.0 255.255.255.0 192.168.0.254

[SecBlade_Clnt1] ip route-static 20.0.0.0 255.255.255.0 192.168.0.2

3) 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 20.0.0.254 24

[H3C-Vlan-interface20] quit

[H3C] interface vlan-interface 40

[H3C-Vlan-interface40] ip address 40.0.0.1 24

[H3C-Vlan-interface40] quit

# Configure the static route.

[H3C] ip route-static 0.0.0.0 0 40.0.0.254

# 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 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 40.0.0.254 24

[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 60.0.0.254 24

[SecBlade_Clnt2-GigabitEthernet0/0.2] quit

# Configure a static route.

[SecBlade_Clnt2] ip route-static 20.0.0.0 24 40.0.0.1

# Enable DVPN function.

[SecBlade_Clnt2] dvpn service enable

# Configure the dvpn-class.

[SecBlade_Clnt2] dvpn class testserver

[SecBlade_Clnt2-dvpn-class-testserver] public-ip 90.0.0.254

[SecBlade_Clnt2-dvpn-class-testserver] quit

# Configure attributes for interface Tunnel 0.

[SecBlade_Clnt2] interface Tunnel 0

[SecBlade_Clnt2-Tunnel0] ip address 192.168.0.2 255.255.255.0

[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 1

[SecBlade_Clnt2-Tunnel0] quit

# Configure the static route.

[SecBlade_Clnt2] ip route-static 70.0.0.0 255.255.255.0 192.168.0.254

[SecBlade_Clnt2] ip route-static 10.0.0.0 255.255.255.0 192.168.0.1

H3C S9500 Series Routing Switches SecBlade FW VPN Cards Operation Manual(V1.03)

1.1 VPN Overview

I. Layer 2 Tunneling protocols

II. Layer 3 Tunneling protocols

III. Contrast between Layer 2 Tunneling protocols and Layer 3 Tunneling protocols

1.3 Classification of VPNs

I. Classified by operation mode

II. Classified by service application

III. Classified by networking model

IV. Classified by implementation level

I. Background

II. Typical L2TP network design

III. Technology details of L2TP

IV. Two typical L2TP Tunnel modes

V. Session setup flow of L2TP Tunnel

VI. L2TP features

2.2.3 Setting Condition of Triggering L2TP Tunnel Setup Request and LNS Address

2.2.8 Setting Username, Password and Local User Authentication

I. Configuring user name and password

II. Configuring PPP user authentication

III. Configuring a PPP domain user and an authentication scheme

2.2.9 Terminating an L2TP Connection

2.2.10 Enabling/Disabling Flow Control Function of Tunnel

I. Creating a virtual template interface

II. Configuring the parameters of the virtual template interface

III. Configuring an L2TP Tunnel for the LAC client

2.3.2 Enabling/Disabling the L2TP Multi-Domain Function

2.3.4 Creating Virtual Template Interface

2.3.14 Terminating an L2TP Connection

2.3.15 Enabling/Disabling Flow Control Function of Tunnel

2.4 Displaying and Debugging L2TP

I. Network requirements

II. Network diagram

III. Configuration procedure

2.6 L2TP Troubleshooting

Chapter 3 GRE Configuration

I. GRE overview

II. Application scope

3.2 GRE Configuration

I. Configuring static routing

II. Configuring dynamic routing

3.2.9 Configuring the Keepalive Function

I. Network requirements

II. Network diagram

III. Configuration procedure

4.1 IPSec Overview

4.1.3 Basic Concepts of IPSec

I. Security association

II. Working mode of IPSec protocol

III. Authentication algorithm and encryption algorithm

IV. Negotiation mode

V. IPSec DPD

I. Configuring IPSec

II. Configuring the encryption card (optional)

4.2.1 Defining an ACL

4.2.2 Defining an IPSec Proposal

II. Specifying the encryption card to be used by an IPSec proposal (only apply when an encryption card is involved)

III. Selecting packet encapsulation mode

IV. Selecting a security protocol

V. Selecting a security algorithm

4.2.3 Creating an IPSec Policy

I. Manually creating an IPSec policy

II. Creating IPSec Policies by using IKE

I. Entering encryption card interface view and enabling the card

II. Enabling IPSec module backup function

III. Configuring the fast forwarding function of the encryption card

IV. Performing simple network management configuration on encryption cards

4.3 Displaying and Debugging IPSec

I. Displaying and debugging IPSec configuration

II. Clearing IPSec packet statistical information

III. Deleting an SA

4.3.2 Displaying and Debugging Encryption Card Information

I. Displaying and debugging IPSec information on encryption cards

II. Clearing statistics on encryption card

III. Deleting an SA on encryption card

IV. Clearing packet statistics on encryption card

V. Clearing system log on encryption card

VI. Clearing the fast forwarding information on encryption card

I. Network requirements

II. Network diagram