Configuration Guide - VPN Huawei

Huawei AR150&200 Series Enterprise Routers
V200R002C00
Configuration Guide - VPN
Issue 02
Date 2012-03-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2012-03-30) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Configuration Guide - VPN About This Document
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the VPN supported by the AR150/200 device.
This document describes how to configure the VPN.
This document is intended for:
l Data configuration engineers

l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.
DANGER
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
WARNING
Indicates a potentially hazardous situation, which if not

avoided, could result in equipment damage, data loss,
CAUTION
performance degradation, or unexpected results.
TIP Indicates a tip that may help you solve a problem or save
time.
NOTE Provides additional information to emphasize or supplement

important points of the main text.
Issue 02 (2012-03-30) Huawei Proprietary and Confidential ii

Configuration Guide - VPN About This Document
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by vertical

bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by vertical

bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by vertical

bars. A minimum of one item or a maximum of all items can be
selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by vertical

bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.
Interface Numbering Conventions

Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 02 (2012-03-30)

Based on issue 01 (2011-12-30), the document is updated as follows:
The following information is modified:
l 5.4 Managing SSL VPN Users
l Example for Configuring the SSL VPN Gateway
Changes in Issue 01 (2011-12-30)

Initial commercial release.
Issue 02 (2012-03-30) Huawei Proprietary and Confidential iii

Configuration Guide - VPN Contents
Contents
About This Document.....................................................................................................................ii

1 GRE Configuration.......................................................................................................................1
1.1 Introduction to GRE...........................................................................................................................................2
1.2 GRE Features Supported by the AR150/200......................................................................................................2
1.3 Configuring GRE................................................................................................................................................3
1.3.1 Establishing the Configuration Task.........................................................................................................3
1.3.2 Configuring a Tunnel Interface.................................................................................................................4
1.3.3 Configuring Routes for the Tunnel............................................................................................................5
1.3.4 (Optional) Configuring GRE Security Options.........................................................................................6
1.3.5 Checking the Configuration.......................................................................................................................7
1.4 Configuring the Keepalive Function..................................................................................................................8
1.4.1 Establishing the Configuration Task.........................................................................................................8
1.4.2 Enabling the Keepalive Function..............................................................................................................9
1.4.3 Checking the Configuration.....................................................................................................................10
1.5 Maintaining GRE..............................................................................................................................................11
1.5.1 Resetting the Statistics of a Tunnel Interface..........................................................................................11
1.5.2 Monitoring the Running Status of GRE..................................................................................................11
1.5.3 Debugging GRE......................................................................................................................................12
1.6 Configuration Examples...................................................................................................................................12
1.6.1 Example for Configuring a Static Route for GRE...................................................................................12
1.6.2 Example for Configuring a Dynamic Routing Protocol for GRE...........................................................17
1.6.3 Example for Configuring a GRE Tunnel to Transmit VPN Multicast Data Encrypted with IPSec........20
1.6.4 Example for Configuring the CE to Access a VPN Through a GRE Tunnel of the Public Network
..........................................................................................................................................................................27
1.6.5 Example for Configuring the Keepalive Function for GRE....................................................................34
2 L2TP Configuration.....................................................................................................................38
2.1 L2TP Overview................................................................................................................................................39
2.1.1 Introduction to L2TP...............................................................................................................................39
2.1.2 L2TP Features Supported by the AR150/200..........................................................................................39
2.2 Configuring Basic L2TP Functions..................................................................................................................40
2.2.1 Establishing the Configuration Task.......................................................................................................40
2.2.2 Configuring Basic L2TP Capability........................................................................................................41
2.3 Configuring LAC..............................................................................................................................................42
Issue 02 (2012-03-30) Huawei Proprietary and Confidential iv


2.3.2 Configuring an L2TP Connection on LAC Side.....................................................................................43
2.3.3 (Optional) Configuring LAC Auto-Dial..................................................................................................43
2.3.4 (Optional) Configuring Local Authentication on LAC Side...................................................................45
2.3.5 (Optional) Configuring RADIUS Authentication on LAC Side.............................................................45
2.4 Configuring LNS..............................................................................................................................................48
2.4.2 Configuring an L2TP Connection on LNS..............................................................................................50
2.4.3 (Optional) Configuring User Authentication on LNS.............................................................................51
2.4.4 Allocating Addresses to Access Users....................................................................................................52
2.5 Adjusting L2TP Connection.............................................................................................................................53
2.5.2 Configuring Security Options for L2TP Connection..............................................................................54
2.5.3 Configuring L2TP Connection Parameters.............................................................................................55
2.6 Maintaining L2TP.............................................................................................................................................56
2.6.1 Disconnecting a Tunnel Forcibly............................................................................................................56
2.6.2 Monitoring the Running Status of L2TP.................................................................................................56
2.6.3 Debugging L2TP Information.................................................................................................................57
2.7 Configuration Examples...................................................................................................................................57
2.7.1 Example for Configuring NAS-Initialized VPNs (Domain Name Access)............................................57
2.7.2 Example for Configuring NAS-Initialized VPNs (Dialup Access).........................................................62
2.7.3 Example for Configuring Client-Initialized VPNs..................................................................................65
2.7.4 Example for Configuring LAC-Auto-Initiated VPN...............................................................................68
3 IPSec Configuration....................................................................................................................72
3.1 IPSec Overview................................................................................................................................................74
3.2 IPSec Features Supported by the AR150/200..................................................................................................75
3.3 Establishing an IPSec Tunnel Manually...........................................................................................................76
3.3.2 Defining Protected Data Flows................................................................................................................77
3.3.3 Configuring an IPSec Proposal................................................................................................................78
3.3.4 Configuring an IPSec Policy...................................................................................................................78
3.3.5 Applying an IPSec Policy to an Interface................................................................................................80
3.4 Establishing an IPSec Tunnel Through IKE Negotiation.................................................................................81
3.4.2 Defining Protected Data Flows................................................................................................................82
3.4.3 (Optional) Configuring an IKE Proposal.................................................................................................83
3.4.4 Configuring an IKE Peer.........................................................................................................................84
3.4.5 Configuring an IPSec Proposal................................................................................................................86
3.4.6 Configuring an IPSec Policy...................................................................................................................87
Issue 02 (2012-03-30) Huawei Proprietary and Confidential v

3.4.7 Configuring an IPSec Policy Template...................................................................................................88

3.4.8 (Optional) Setting Optional Parameters..................................................................................................89
3.4.9 (Optional) Configuring Route Injection..................................................................................................91
3.4.10 Applying an IPSec policy to an interface..............................................................................................91
3.4.11 Checking the Configuration...................................................................................................................92
3.5 Establishing an IPSec Tunnel Using an IPSec Tunnel Interface......................................................................92
3.5.2 Configuring an IPSec Profile...................................................................................................................93
3.5.3 Configuring an IPSec Tunnel Interface...................................................................................................94
3.6 Establishing an IPSec Tunnel Using the Efficient VPN Policy.......................................................................96
3.6.2 Configuring Client Mode.........................................................................................................................97
3.6.3 Configuring Network Mode..................................................................................................................100
3.6.4 Verifying the Configuration..................................................................................................................103
3.7 Maintaining IPSec..........................................................................................................................................103
3.7.1 Displaying the IPSec Configuration......................................................................................................103
3.7.2 Clearing IPSec Information...................................................................................................................104
3.8 Configuration Examples.................................................................................................................................104
3.8.1 Example for Establishing an SA Manually...........................................................................................105
3.8.2 Example for Configuring IKE Negotiation Using Default Settings......................................................109
3.8.3 Example for Configuring IKE Negotiation...........................................................................................114
3.8.4 Example for Establishing an IPSec Tunnel Using an IPSec Tunnel Interface......................................121
3.8.5 Example for Establishing an SA Using Efficient VPN in Client Mode................................................125
3.8.6 Example for Establishing an SA Using Efficient VPN in Network Mode............................................130
4 DSVPN Configuration.............................................................................................................134
4.1 DSVPN Overview..........................................................................................................................................135
4.2 DSVPN Features Supported by the AR150/200.............................................................................................135
4.3 Configuring DSVPN.......................................................................................................................................136
4.3.1 Establishing the Configuration Task.....................................................................................................136
4.3.2 Configuring MGRE...............................................................................................................................137
4.3.3 Configuring Tunnel Routes...................................................................................................................137
4.3.4 Configuring NHRP on a Branch............................................................................................................138
4.3.5 Configuring NHRP on the Central Office.............................................................................................139
4.3.6 (Optional) Configuring an IPSec Profile...............................................................................................140
4.4 Maintaining DSVPN.......................................................................................................................................142
4.4.1 Displaying the DSVPN Configuration..................................................................................................142
4.4.2 Clearing DSVPN Statistics....................................................................................................................142
4.5.1 Example for Configuring DSVPN When Branches Learn Routes from Each Other............................143
Issue 02 (2012-03-30) Huawei Proprietary and Confidential vi

4.5.2 Example for Configuring DSVPN When Branches Have Only Summarized Routes to the Central Office
........................................................................................................................................................................148
5 SSL VPN Configuration...........................................................................................................153

5.1 SSL VPN Overview........................................................................................................................................154
5.2 SSL VPN Features Supported by the AR150/200..........................................................................................155
5.3 Configuring Basic SSL VPN Functions.........................................................................................................156
5.3.2 Creating a Virtual Gateway...................................................................................................................157
5.3.3 Configuring Intranet and Extranet Interfaces........................................................................................157
5.3.4 Binding an AAA Domain to the Virtual Gateway................................................................................158
5.3.5 Enabling Basic SSL VPN Functions.....................................................................................................159
5.4 Managing SSL VPN Users.............................................................................................................................160
5.5 Configuring SSL VPN Services.....................................................................................................................162
5.5.2 Creating a Virtual Gateway...................................................................................................................163
5.5.3 Configuring the Web Proxy Service......................................................................................................163
5.5.4 Configuring the Port Forwarding Service.............................................................................................164
5.5.5 Configuring the IP Forwarding Service.................................................................................................165
5.6.1 Example for Configuring the SSL VPN Gateway.................................................................................167
Issue 02 (2012-03-30) Huawei Proprietary and Confidential vii

Configuration Guide - VPN 1 GRE Configuration
1 GRE Configuration
About This Chapter
Generic Routing Encapsulation (GRE) encapsulates the packets of certain network layer
protocols so that the encapsulated packets can be transmitted over the IPv4 network.
1.1 Introduction to GRE

The transmission of packets in a Generic Routing Encapsulation (GRE) tunnel involves two
processes: encapsulation and decapsulation. After receiving a packet of a certain network layer
protocol that needs to be encapsulated and routed, the system adds a GRE header to the packet,
and encapsulates the packet into a packet of another protocol, such as IP.
1.2 GRE Features Supported by the AR150/200
GRE features supported by the AR150/200 include the following: enlargement of the operation
scope of the network running a hop-limited protocol, and working in conjunction with the IP
Security Protocol (IPSec) to compensate for the IPSec flaw in multicast data protection.
1.3 Configuring GRE
You can configure GRE only after a GRE tunnel is configured.
1.4 Configuring the Keepalive Function
Before configuring a tunnel policy and a GRE tunnel for the VPN, enable the GRE tunnel
Keepalive function. With this function enabled, the VPN does not select the GRE tunnel that
cannot reach the remote end, and data loss can be avoided.
1.5 Maintaining GRE
This section describes how to reset the statistics of a tunnel interface and monitor the GRE
running status.
1.6 Configuration Examples
Familiarize yourself with the configuration procedures against the networking diagrams. This
section provides networking requirements, configuration notes, and configuration roadmap in
configurations examples.
Issue 02 (2012-03-30) Huawei Proprietary and Confidential 1

1.1 Introduction to GRE

The transmission of packets in a Generic Routing Encapsulation (GRE) tunnel involves two
processes: encapsulation and decapsulation. After receiving a packet of a certain network layer
protocol that needs to be encapsulated and routed, the system adds a GRE header to the packet,
and encapsulates the packet into a packet of another protocol, such as IP.
GRE encapsulates the packets of certain network layer protocols. After encapsulation, these
packets can be transmitted over the network by another network layer protocol, such as IP.
GRE can serve as a Layer 3 tunneling protocol for VPNs. A tunnel is a virtual point-to-point
connection and can be regarded as a virtual interface that supports only point-to-point
connections. This interface provides a path to transmit encapsulated datagrams. GRE
encapsulates and decapsulates datagrams at both ends of the tunnel.
1.2 GRE Features Supported by the AR150/200

GRE features supported by the AR150/200 include the following: enlargement of the operation
scope of the network running a hop-limited protocol, and working in conjunction with the IP
Security Protocol (IPSec) to compensate for the IPSec flaw in multicast data protection.
Enlarging the Operation Scope of the Network Running a Hop-Limited Protocol

If the hop count between two terminals in Figure 1-1 is more than 15, the two terminals cannot
communicate with each other.
Figure 1-1 Networking diagram of enlarged network operation scope
IP
network
IP IP
network network
Tunnel
PC PC
When the tunnel is used in the network, a few hops are hidden. This enlarges the scope of the
network operation.
Working in Combination with IPSec to Compensate for the IPSec Flaw in Multicast
Data Protection
Based on GRE, multicast data can be encapsulated and transmitted in the GRE tunnel. Based on
IPSec, only the unicast data can realize encrypted protection.

Figure 1-2 Networking diagram of GRE-IPSec tunnel application
Internet
Remote
IPSec tunnel office
Corporate
intranet GRE tunnel network
As shown in Figure 1-2, if the multicast data is transmitted in the IPSec tunnel, establish the
GRE tunnel and encapsulate the multicast data with GRE. Then encrypt the encapsulated
multicast data with IPSec. When these tasks are performed, the encrypted multicast data can be
transmitted in the IPSec tunnel.
1.3 Configuring GRE

You can configure GRE only after a GRE tunnel is configured.
1.3.1 Establishing the Configuration Task

Before configuring a GRE tunnel, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the data required for the configuration.
Applicable Environment
To set up a GRE tunnel, create a tunnel interface first, and configure the GRE functions on the
tunnel interface. If the tunnel interface is deleted, all the configurations on the interface are
deleted.
Pre-configuration Tasks
Before configuring an ordinary GRE tunnel, complete the following task:
l Configuring reachable routes between the source and destination interfaces
Data Preparation
To configure an ordinary GRE tunnel, you need the following data.
No. Data
1 Number of the tunnel interface
2 Source address and destination address of the tunnel

No. Data
3 IP address of the tunnel interface
4 Key of the tunnel interface
1.3.2 Configuring a Tunnel Interface

After creating a tunnel interface, specify GRE as the encapsulation type, set the tunnel source
address or source interface, and set the tunnel destination address. In addition, set the tunnel
interface network address so that the tunnel can support dynamic routing protocols.
Context
Perform the following steps on the routers at the two ends of a tunnel.
Procedure
Step 1 Run:
system-view
The system view is displayed.

Step 2 Run:
interface tunnel interface-number
A tunnel interface is created and the tunnel interface view is displayed.

Step 3 Run:
tunnel-protocol gre
The tunnel is encapsulated with GRE.

Step 4 Run:
source { source-ip-address | interface-type interface-number }
The source address or source interface of the tunnel is configured.
NOTE
l The virtual IP address of the VRRP backup group can be configured as the source address of the GRE
tunnel.
l The bridge-if interface can not be configured as the source interface of the GRE tunnel.
The source interface of the tunnel cannot be the interface of the tunnel, but can be specified as
the interface of another tunnel.
Step 5 Run:
destination ip-address
The destination address of the tunnel is configured.

Step 6 (Optional) Run:
mtu mtu
The Maximum Transmission Unit (MTU) of the tunnel interface is modified.

The new MTU takes effect only after you run the shutdown command and the undo
shutdown command on the interface.
Step 7 Choose one of the following commands to configure the IP address of the tunnel interface.
l Run the ip address ip-address { mask | mask-length } [ sub ] command to configure the IP
address of the tunnel interface.
l Run the ip address unnumbered interface interface-type interface-number command to
configure IP unnumbered for the tunnel interface.
To support dynamic routing protocols on a tunnel, configure a network address for the tunnel
interface. The network address of the tunnel interface may not be a public address, but should
be in the same network segment on both ends of the tunnel.
By default, the network address of a tunnel interface is not set.
----End
1.3.3 Configuring Routes for the Tunnel

Routes for a tunnel must be available on both the source and destination devices so that packets
encapsulated with GRE can be forwarded correctly. A route passing through tunnel interfaces
can be a static route or a dynamic route.
Context
Perform the following steps on the devices at two ends of a tunnel.
NOTE
The packets encapsulated with GRE are forwarded correctly only if the routes for the tunnel are available
on both the source and destination routers.
Procedure
Step 1 Run:
system-view

Step 2 Choose one of the following methods to configure routes passing through the tunnel interface.
l Run the ip route-static ip-address { mask | mask-length } tunnel interface-number
[ description text ] command to configure a static route.
The static route must be configured on both ends of the tunnel. In this command, the
destination address is neither the destination address of the tunnel nor the address of the
opposite tunnel interface, but the destination address of the packet that is not encapsulated
with GRE. The outbound interface must be the local tunnel interface.
l Configure dynamic routes using IGP or BGP. Details for the procedure are not provided here.
For the configuration of dynamic routes, see the AR150/200 Configuration Guide - IP
Routing.
When configuring a dynamic routing protocol, enable the dynamic routing protocol on both
the tunnel interface and the interface connected to the private network. To ensure correct
routing, do not choose the tunnel interface as the next hop when configuring the route to the
physical or logical interface of the destination tunnel.
Use Router A in Figure 1-3 as an example. The source interface of Tunnel 0/0/1 is Eth 1/0/0
on Router A, and its destination interface is Eth 2/0/0 on Router C. If a dynamic routing

protocol is used, the protocol must be configured on the tunnel interface and the Eth interface
connected to the PC. Moreover, in the routing table of Router A, the egress with the
destination as the network segment where Eth 2/0/0 on Router C resides cannot be Tunnel
0/0/1.
In practical configurations, configure a multi-process routing protocol or change the metric
value of the tunnel interface. This prevents the tunnel interface from being selected as the
outbound interface of routes to the destination physical interface of the tunnel.
In practical configurations, tunnel interfaces and physical interfaces connected to the public
network should use different routing protocols or different processes of the same routing
protocol. With one of these procedures in place, you can avoid selecting a tunnel interface
as an outbound interface for packets destined for the destination of the tunnel. In addition, a
physical interface is prevented from forwarding user packets that should be forwarded
through the tunnel.
Figure 1-3 Diagram of configuring the GRE dynamic routing protocol
Backbone
Eth1/0/0 Eth2/0/0
RouterA Tunnel RouterC
Eth2/0/0 Tunnel0/0/1 Tunnel0/0/2 Eth1/0/0
PC1 PC2
----End
1.3.4 (Optional) Configuring GRE Security Options

To enhance the security of a GRE tunnel, configure end-to-end checksum authentication or key
authentication. This security mechanism can prevent the tunnel interface from incorrectly
identifying and receiving packets from other devices.
Context
Perform the following steps on the routers at two ends of a tunnel.
Procedure
Step 1 Run:
system-view

Step 2 Run:

The tunnel interface view is displayed.

Step 3 Run:
gre checksum
End-to-end checksum authentication is configured for the tunnel.

By default, end-to-end checksum authentication is disabled.
Step 4 Run:
gre key key-number
The key is set for the tunnel interface.

If the keys are set for tunnel interfaces on the two ends of the tunnel, ensure that they have the
same key number. Alternatively, you may choose not to set the keys for tunnel interfaces on
both ends of the tunnel.
By default, no key is configured for the tunnel.
NOTE
Step 3 and Step 4 can be performed in random order.
----End
1.3.5 Checking the Configuration

After a GRE tunnel is set up, you can view the running status and routing information about the
tunnel interface.
Context
The configurations of the GRE function are complete.
Procedure
l Run the display interface tunnel [ interface-number ] command to check tunnel interface
information.
l Run the display ip routing-table command to check the IPv4 routing table.
l Run the ping -a source-ip-address host command to check whether the two ends of the
tunnel can successfully ping each other.
----End
Example
Run the display interface tunnel command. If the tunnel interface is Up, the configuration
succeeds. For example:
<Huawei> display interface Tunnel 0/0/1
Tunnel0/0/1 current state : UP
Line protocol current state : UP
Description:HUAWEI, AR Series, Tunnel0/0/1 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 5.5.5.2/24
Encapsulation is TUNNEL, loopback not set
Tunnel source 150.1.1.1 (Ethernet4/0/0), destination 150.1.1.2
Tunnel protocol/transport GRE/IP, key disabled
keepalive disabled
Checksumming of packets disabled

Current system time: 2008-03-04 19:17:30

300 seconds input rate 0 bits/sec, 0 packets/sec
300 seconds output rate 0 bits/sec, 0 packets/sec
0 seconds input rate 0 bits/sec, 0 packets/sec
0 seconds output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
0 input error
0 packets output, 0 bytes
0 output error
Input bandwidth utilization : --
Output bandwidth utilization : --
Run the display ip routing-table command. If the route passing through the tunnel interface
exists in the routing table, the configuration succeeds. For example:
[Huawei] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Ethernet2/0/0
10.1.1.2/32 Direct 0 0 D 127.0.0.1 InLoopBack0
10.2.1.0/24 Static 60 0 D 40.1.1.1 Tunnel0/0/2
40.1.1.0/24 Direct 0 0 D 40.1.1.1 Tunnel0/0/2
Run the ping -a source-ip-address host command to see that the ping from the local tunnel
interface to the destination tunnel succeeds.
<Huawei> ping -a 40.1.1.1 40.1.1.2
PING 40.1.1.2: 56 data bytes, press CTRL_C to break
Reply from 40.1.1.2: bytes=56 Sequence=1 ttl=255 time=24 ms
--- 40.1.1.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 24/34/48 ms
1.4 Configuring the Keepalive Function

Before configuring a tunnel policy and a GRE tunnel for the VPN, enable the GRE tunnel
Keepalive function. With this function enabled, the VPN does not select the GRE tunnel that
cannot reach the remote end, and data loss can be avoided.

Before configuring the GRE tunnel Keepalive function, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the required data. This can help
you complete the configuration task quickly and accurately.
Application Environment
The Keepalive function can be configured on one end of a GRE tunnel to test the GRE tunnel
status. If the remote end is found unreachable, the tunnel is disconnected on time to avoid data
black hole.

Figure 1-4 GRE tunnel supporting Keepalive
Source Internet Destination

GRE tunnel
RouterA RouterB
Before configuring the Keepalive function, complete the following tasks:
l Configuring the link layer attributes of the interfaces
l Assigning IP addresses to the interfaces
l Establishing the GRE tunnel and keeping the tunnel Up
Data Preparation
To configure the Keepalive function, you need the following data.
No. Data
1 Interval for sending Keepalive messages
2 Retry times of the unreachable timer
1.4.2 Enabling the Keepalive Function

The GRE tunnel Keepalive function is unidirectional. To implement the Keepalive function on
both ends, enable the Keepalive function on both ends of a GRE tunnel.
Context
Perform the following steps on the router that requires the Keepalive function.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
tunnel-protocol gre

The tunnel is encapsulated with GRE.

Step 4 Run:
keepalive [ period period [ retry-times retry-times ] ]
The Keepalive function is enabled.

The GRE tunnel Keepalive function is unidirectional. Therefore, to realize the Keepalive
function on both ends, enable the Keepalive function on both ends of a GRE tunnel. One end
can be configured with the Keepalive function regardless of whether the remote end is enabled
with the Keepalive function. But it is still recommended to enable the Keepalive function on
both ends of the GRE tunnel.
TIP
Before configuring the tunnel policy and the GRE tunnel for the VPN, enable the GRE tunnel Keepalive
function. With this function enabled, the VPN does not select the GRE tunnel that cannot reach the remote
end, and the data loss can be avoided. The reasons for enabling the Keepalive function are listed below:
l If the Keepalive function is not enabled, the local tunnel interface may always be Up regardless of
whether data reaches the remote end.
l If the Keepalive function is enabled on the local end, the local tunnel interface is set Down when the
remote end is unreachable. As a result, the VPN does not select the unreachable GRE tunnel and the
data is not lost.
----End

After a GRE tunnel is enabled with the Keepalive function, you can view the Keepalive packets
and Keepalive Response packets sent and received by the GRE tunnel interfaces.
Prerequisites
The Keepalive function is enabled on the GRE tunnel.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
display keepalive packets count
Check the Keepalive packets and Keepalive Response packets sent and received by the GRE
tunnel interface.
----End
Example
On the tunnel interface that is enabled with the Keepalive function, run the display keepalive
packets count command to ascertain the number of sent Keepalive packets and received

Keepalive Response packets on both the local end and the remote end. If the Keepalive function
is successfully configured on the local tunnel interface, the number of sent Keepalive packets
or received Keepalive Response packets on the local end is not 0.
[Huawei] interface tunnel 0/0/1
[Huawei-Tunnel0/0/1] tunnel-protocol gre
[Huawei-Tunnel0/0/1] keepalive
[Huawei-Tunnel0/0/1] display keepalive packets count
Send 34 keepalive packets to peers, Receive 34 keepalive response packets from peers
Receive 0 keepalive packets from peers, Send 0 keepalive response packets to peers.
1.5 Maintaining GRE

This section describes how to reset the statistics of a tunnel interface and monitor the GRE
running status.
1.5.1 Resetting the Statistics of a Tunnel Interface

When you need to reset the statistics of a tunnel interface, you can run the reset commands to
clear the Keepalive packets and Keepalive Response packets sent and received by a GRE tunnel
interface.
Procedure
l Run the reset counters interface tunnel [ interface-number ] command in the system view
to reset statistics about the tunnel interface.
l Reset statistics about Keepalive packets on the tunnel interface.
1. Run:
system-view

2. Run:

3. Run:
reset keepalive packets count
Reset the statistics on Keepalive packets on the tunnel interface.
NOTE
You can run the reset keepalive packets count command only in the tunnel interface view,
and the interface tunnel protocol must be GRE.
----End
1.5.2 Monitoring the Running Status of GRE

In routine maintenance, you can run the GRE related display commands to view the GRE running
status.
Context
In routine maintenance, you can run the following commands to view the GRE running status.

Procedure
l Run the display interface tunnel [ interface-number ] command to check the tunnel
interface running status.
l Run the display ip routing-table command to check the routing table on the CE.
----End
1.5.3 Debugging GRE

When a GRE fault occurs, you can run the L2TP related debugging commands to debug GRE
and locate the fault.
Context
NOTE
The debugging process affects system performance. Therefore, after finishing the debugging process, run
the undo debugging all command immediately to disable the debugging.
When GRE goes abnormal, run the debugging commands in the user view to view debugging
information, locate the fault, and analyze the cause.
Procedure
l Run the debugging tunnel keepalive command in the user view to debug the Keepalive
function of the GRE tunnel.
----End

Familiarize yourself with the configuration procedures against the networking diagrams. This
section provides networking requirements, configuration notes, and configuration roadmap in
configurations examples.
1.6.1 Example for Configuring a Static Route for GRE

This section provides an example for configuring a static route for GRE. In this networking,
traffic between users is transmitted through a GRE tunnel; a static route is configured between
the device and its connected client.
Networking Requirements
In Figure 1-5, Router A, Router B, and Router C belong to the VPN backbone network and
OSPF runs between them.
GRE is enabled between Router A and Router C to achieve interworking between PC 1 and PC
2.
PC1 takes Router A as its default gateway, and PC2 takes Router C as its default gateway.
NOTE
AR150/200 is RouterA, or RouterC.

Figure 1-5 Networking diagram of configuring a static route for GRE

RouterB
Eth1/0/0 Eth2/0/0
20.1.1.2/24 30.1.1.1/24
RouterA Eth0/0/8 Eth0/0/8 RouterC

20.1.1.1/24 30.1.1.2/24
Tunnel
VLANIF 11 40.1.1.1/24 40.1.1.2/24 VLANIF 11
10.1.1.2/24 10.2.1.2/24
PC1 PC2
10.1.1.1/24 10.2.1.1/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure a dynamic routing protocol on routers.

2. Create a tunnel interface on Router A and Router C.
3. Specify the source address of the tunnel interface as the IP address of the interface that
sends the packet.
4. Specify the destination address of the tunnel interface as the IP address of the interface that
receives the packet.
5. Assign network addresses to the tunnel interfaces to enable the tunnel to support the
dynamic routing protocol.
6. Configure the static route between Router A and its connected PC, and the static route
between Router C and its connected PC to make the traffic between PC1 and PC2
transmitted through the GRE tunnel.
7. Configure the egress of the static route as the local tunnel interface.
Data Preparation
To complete the configuration, you need the following data:
l Data for running OSPF

l Source address and destination address of the GRE tunnel, and IP addresses of tunnel
interfaces
Procedure
Step 1 Assign an IP address to each interface.

Assign an IP address to each interface as shown in Figure 1-5. The specific configuration is not
mentioned here.
Step 2 Configure IGP for the VPN backbone network.
# Configure Router A.
[RouterA] ospf 1
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
# Configure Router B.
[RouterB] ospf 1
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
[RouterC] ospf 1
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
After the configuration, run the display ip routing-table command on Router A and Router C.
You can find that they both learn the OSPF route to the network segment of the remote interface.
Take Router A as an example.
[RouterA] display ip routing-table
------------------------------------------------------------------------------
20.1.1.0/24 Direct 0 0 D 20.1.1.1 Ethernet

0/0/8
30.1.1.0/24 OSPF 10 2 D 20.1.1.2 Ethernet
0/0/8
Step 3 Configure the tunnel interface.

[RouterA] interface tunnel 0/0/1
[RouterA-Tunnel0/0/1] ip address 40.1.1.1 24
[RouterA-Tunnel0/0/1] source 20.1.1.1
[RouterA-Tunnel0/0/1] destination 30.1.1.2
[RouterA-Tunnel0/0/1] quit
[RouterC] interface tunnel 0/0/1
[RouterC-Tunnel0/0/1] ip address 40.1.1.2 24
[RouterC-Tunnel0/0/1] source 30.1.1.2

[RouterC-Tunnel0/0/1] destination 20.1.1.1

[RouterC-Tunnel0/0/1] quit
After the configuration, the status of tunnel interfaces goes Up, and the tunnel interfaces can
ping each other successfully.
Take Router A as an example:
[RouterA] ping -a 40.1.1.1 40.1.1.2
0.00% packet loss
Step 4 Configure a static route.

[RouterA] ip route-static 10.2.1.0 24 tunnel 0/0/1
[RouterC] ip route-static 10.1.1.0 24 tunnel 0/0/1
After the configuration, run the displayip routing-table command on Router A and Router C.
You can find the static route to the network segment of the remote user end through the tunnel
interface.
------------------------------------------------------------------------------
10.2.1.0/24 Static 60 0 D 40.1.1.1 Tunnel0/0/1

0/0/8
30.1.1.0/24 OSPF 10 2 D 20.1.1.2 Ethernet
0/0/8
40.1.1.0/24 Direct 0 0 D 40.1.1.1 Tunnel0/0/1
PC 1 and PC 2 can ping each other successfully.
----End
Configuration Files
l Configuration file of Router A

#
sysname RouterA
#
vlan batch 11
#
interface Vlanif11
ip address 10.1.1.2 255.255.255.0
#
interface Ethernet0/0/1
port link-type access
port default vlan 11
#
ip address 20.1.1.1 255.255.255.0
#
interface Tunnel0/0/1
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
destination 30.1.1.2
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
#
ip route-static 10.2.1.0 255.255.255.0 Tunnel0/0/1
#
return
l Configuration file of Router B
#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#
ip address 30.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
l Configuration file of Router C
#
sysname RouterB
#
vlan batch 11
#
interface Vlanif11
ip address 10.2.1.2 255.255.255.0
#
#
ip address 30.1.1.2 255.255.255.0
#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
#
ospf 1
area 0.0.0.0

network 30.1.1.0 0.0.0.255

#
#
return
1.6.2 Example for Configuring a Dynamic Routing Protocol for GRE

This section provides an example for configuring a dynamic route for GRE. In this networking,
traffic between users is transmitted through a GRE tunnel; a dynamic route is configured between
the device and its connected user.
In Figure 1-6, Router A, Router B, and Router C belong to the VPN backbone network and
OSPF runs between them.
GRE is enabled between Router A and Router C for the interworking between PC1 and PC2.
PC1 takes Router A as its default gateway, and PC2 takes Router C as its default gateway.
OSPF is enabled on the tunnel interface. OSPF process 1 is used for the VPN backbone network
and OSPF process 2 is used for user access.
NOTE
Figure 1-6 Networking diagram of configuring a dynamic routing protocol for GRE
RouterB
Eth1/0/0 Eth2/0/0
20.1.1.2/24 30.1.1.1/24
OSPF 1
Eth0/0/8 Eth0/0/8
20.1.1.1/24 30.1.1.2/24
RouterA Tunnel RouterC
Tunnel0/0/1 OSPF 2 Tunnel0/0/1
Eth0/0/1 Eth0/0/1
40.1.1.1/24 40.1.1.2/24
VLANIF 11 VLANIF 11
10.1.1.2/24 10.2.1.2/24
10.2.1.1/24
10.1.1.1/24
PC1 PC2

1. Configure IGP on each router in the backbone network to realize the interworking between
these devices. Here OSPF process 1 is used.
2. Create the GRE tunnel between routers that are connected to PCs.Then routers can
communicate through the GRE runnel.
3. Configure the dynamic routing protocol on the network segments through which PCs access
the backbone network. Here OSPF process 2 is used.
Data Preparation
l Source address and destination address of the GRE tunnel
l IP addresses of the interfaces on both ends of the GRE tunnel
Procedure
mentioned here.
Step 2 Configure IGP for the VPN backbone network.
The specific configuration procedures are the same as those in 1.6.1 Example for Configuring
a Static Route for GRE and are not mentioned here.
Step 3 Configuring the tunnel interfaces
The specific configuration procedures are the same as those in 1.6.1 Example for Configuring
a Static Route for GRE and are not mentioned here.
Step 4 Configure OSPF on the tunnel interfaces.
[RouterA] ospf 2
[RouterA-ospf-2] area 0
[RouterA-ospf-2-area-0.0.0.0] quit
[RouterA-ospf-2] quit
[RouterC] ospf 2
[RouterC-ospf-2] area 0
[RouterC-ospf-2-area-0.0.0.0] quit
[RouterC-ospf-2] quit
Step 5 Verify the configuration.

After the configuration, run the display ip routing-table command on Router A and Router C.
You can find the OSPF route to the network segment of the remote user end through the tunnel
interface. Moreover, the next hop to the destination physical address (30.1.1.0/24) of the tunnel
is not the tunnel interface.


------------------------------------------------------------------------------
10.2.1.0/24 OSPF 60 0 D 40.1.1.1 Tunnel0/0/1

0/0/8
30.1.1.0/24 OSPF 10 2 D 20.1.1.2 Ethernet
0/0/8
40.1.1.0/24 Direct 0 0 D 40.1.1.1 Tunnel0/0/1
PC 1 and PC 2 can ping each other successfully.
----End
Configuration Files
#
sysname RouterA
#
vlan batch 11
#
interface Vlanif11
ip address 10.1.1.2 255.255.255.0
#
#
ip address 20.1.1.1 255.255.255.0
#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
#ospf 2
area 0.0.0.0
network 40.1.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return

#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#

ip address 30.1.1.1 255.255.255.0

#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return

#
sysname RouterC
#
vlan batch 11
#
interface Vlanif11
ip address 10.2.1.2 255.255.255.0
#
#
ip address 30.1.1.2 255.255.255.0
#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#ospf 2
area 0.0.0.0
network 40.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
1.6.3 Example for Configuring a GRE Tunnel to Transmit VPN

Multicast Data Encrypted with IPSec
This section provides an example for configuring a GRE tunnel to transmit multicast packets
encrypted with IPSec. In this networking, a GRE tunnel is set up between devices; multicast
packets are encapsulated with GRE and then IPSec.
In Figure 1-7, Router A and Router C are required to transmit multicast packets, and the multicast
packets must be encrypted through IPSec. Before being encrypted through IPSec, multicast
packets must be encapsulated with GRE because IPSec cannot directly encrypt multicast packets.
NOTE

Figure 1-7 Networking diagram of transmitting IPSec-encrypted multicast packets through a

GRE tunnel
RouterB
Eth1/0/0 Eth2/0/0
20.1.1.2/24 30.1.1.1/24
RouterA Eth0/0/8 Eth0/0/8 RouterC

20.1.1.1/24 30.1.1.2/24
GRE with IPSec
VLANIF 11 40.1.1.1/24 40.1.1.2/24 VLANIF 11
10.1.1.2/24 10.2.1.2/24
10.1.1.1/24 10.2.1.1/24
1. Configure OSPF on the backbone network devices, namely, Router A, Router B, and
Router C, to realize the interworking between these devices.
2. Create a GRE tunnel between Router A and Router C to encapsulate multicast packets.
3. Create an IPSec tunnel between Router A and Router C to encrypt the GRE encapsulated
multicast packets.
Data Preparation
l Data for configuring the routing protocol for the backbone network
l IP addresses of the interfaces on both ends of the GRE tunnel
l Parameters for configuring IKE such as pre-shared-key and remote-name
l Data for configuring IPSec such as IPSec proposal name and ACL
Procedure
Step 1 Configure the routing protocol.
Configure a routing protocol on Router A, Router B, and Router C to implement the interworking
between these devices. OSPF is configured in this example. The configuration details are not
mentioned here.
After the configuration,

l Router A and Router C are routable.

l Router A can successfully ping Eth0/0/8 of Router C.
l Router C can successfully ping Eth0/0/8 of Router A.
Step 2 Configure the interfaces of the GRE tunnel.
[RouterA] interface tunnel0/0/1
[RouterA-Tunnel0/0/1] ip address 40.1.1.1 255.255.255.0
[RouterA-Tunnel0/0/1] tunnel-protocol gre
[RouterC] interface tunnel0/0/1
[RouterC-Tunnel0/0/1] ip address 40.1.1.2 255.255.255.0
[RouterC-Tunnel0/0/1] tunnel-protocol gre
[RouterC-Tunnel0/0/1] source 30.1.1.2
[RouterC-Tunnel0/0/1] destination 20.1.1.1
After the configuration,

l The GRE tunnel between Router A and Router C is set up.
l The status of the tunnel interfaces is Up.
Step 3 Enable multicast.
# Enable the multicast routing protocol globally. Enable PIM DM on the tunnel interfaces, and
enable PIM DM and IGMP on the interfaces connected to the PCs.
[RouterA] multicast routing-enable
[RouterA] interface ethernet 2/0/0
[RouterA-Vlanif11] pim dm
[RouterA-Vlanif11] igmp enable
[RouterA-Vlanif11] quit
[RouterA] interface tunnel0/0/1
[RouterA-Tunnel0/0/1] pim dm
[RouterC] multicast routing-enable
[RouterC] interface ethernet 2/0/0
[RouterC-Vlanif11] pim dm
[RouterC-Vlanif11] igmp enable
[RouterC-Vlanif11] quit
[RouterC] interface tunnel0/0/1
[RouterC-Tunnel0/0/1] pim dm
# After multicast is enabled, the multicast data between Router A and Router C is transmitted
through the GRE tunnel.
Step 4 Configure aggressive IKE negotiation between Router A and Router C.
NOTE
To encapsulate multicast packets with GRE and then encrypt the multicast packets with IPSec, the remote
address in IKE peer mode must be the destination address of the local tunnel.

[RouterA] ike local-name rta

[RouterA] ike peer RouterC v1
[RouterA-ike-peer-routerc] exchange-mode aggressive
[RouterA-ike-peer-routerc] local-id-type name
[RouterA-ike-peer-routerc] pre-shared-key 12345
[RouterA-ike-peer-routerc] remote-name rtc
[RouterA-ike-peer-routerc] remote-address 30.1.1.2
[RouterA-ike-peer-routerc] quit
[RouterC] ike local-name rtc
[RouterC] ike peer RouterA v1
[RouterC-ike-peer-routera] exchange-mode aggressive
[RouterC-ike-peer-routera] local-id-type name
[RouterC-ike-peer-routera] pre-shared-key 12345
[RouterC-ike-peer-routera] remote-name rta
[RouterC-ike-peer-routera] remote-address 20.1.1.1
[RouterC-ike-peer-routera] quit
Step 5 Configure IPSec.

NOTE
Encapsulate multicast packets with GRE and then encrypt these packets with IPSec. Note that the source
and destination addresses for the local end of the tunnel must match the ACL of the IPSec policy, and the
IPSec policy must be applied to the physical interface transmitting data.
# Configure IPSec on Router A and Router C. The default parameters of the IPSec proposal is
used in this example.
[RouterA] acl number 3000
[RouterA-acl-adv-3000] rule permit ip source 20.1.1.1 0 destination 30.1.1.2 0
[RouterA-acl-adv-3000] quit
[RouterA] ipsec proposal p1
[RouterA-ipsec-proposal-p1] quit
[RouterA] ipsec policy policy1 1 isakmp
[RouterA-ipsec-policy-isakmp-policy1-1] security acl 3000
[RouterA-ipsec-policy-isakmp-policy1-1] ike-peer RouterC
[RouterA-ipsec-policy-isakmp-policy1-1] proposal p1
[RouterA-ipsec-policy-isakmp-policy1-1] quit
[RouterA] interface ethernet 0/0/8
[RouterA-Ethernet0/0/8] ipsec policy policy1
[RouterA-Ethernet0/0/8] quit
[RouterC] acl number 3000
[RouterC-acl-adv-3000] rule permit ip source 30.1.1.2 0 destination 20.1.1.1 0
[RouterC-acl-adv-3000] quit
[RouterC] ipsec proposal p1
[RouterC-ipsec-proposal-p1] quit
[RouterC] ipsec policy policy1 1 isakmp
[RouterC-ipsec-policy-isakmp-policy1-1] security acl 3000
[RouterC-ipsec-policy-isakmp-policy1-1] ike-peer RouterA
[RouterC-ipsec-policy-isakmp-policy1-1] proposal p1
[RouterC-ipsec-policy-isakmp-policy1-1] quit
[RouterC] interface ethernet 0/0/8
[RouterC-Ethernet0/0/8] ipsec policy policy1
[RouterC-Ethernet1/0/0] quit
# After the configuration, the multicast data between Router A and Router C can be transmitted
through the GRE tunnel encrypted with IPSec.
Step 6 On the source device and the destination device of the tunnel, configure the tunnel to forward
routes.

[RouterA] ip route-static 10.2.1.0 255.255.255.0 tunnel 0/0/1
[RouterC] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/1
# After PC1 and PC2 successfully ping each other, you can view that IKE negotiation is
configured and IPSec encryption takes effect.
[RouterA] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------------
3 30.1.1.2 0 RD 2
2 30.1.1.2 0 RD 1
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
[RouterA] display ips sa
===============================
Interface: Ethernet0/0/8
Path MTU: 1500
===============================
-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Mode : ISAKMP
-----------------------------
Connection ID : 3
Encapsulation mode: Tunnel
Tunnel local : 20.1.1.1
Tunnel remote : 30.1.1.2
[Outbound ESP SAs]

SPI: 1644488112 (0x6204e5b0)
Proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-MD5
SA remaining key duration (bytes/sec): 1887436628/3542
Max sent sequence-number: 2
UDP encapsulation used for NAT traversal: N
[Inbound ESP SAs]

SPI: 2182908365 (0x821c89cd)
Max received sequence-number: 3
[RouterC] display ike sa
---------------------------------------------------------------
2 20.1.1.1 0 RD|ST 2
1 20.1.1.1 0 RD|ST 1
Flag Description:
[RouterC] display ips sa
===============================
Interface: Ethernet0/0/8
Path MTU: 1500
===============================

-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Mode : ISAKMP
-----------------------------
Connection ID : 2
[Outbound ESP SAs]

SPI: 2182908365 (0x821c89cd)
[Inbound ESP SAs]

SPI: 1644488112 (0x6204e5b0)
----End
Configuration Files
#
sysname RouterA
#
vlan batch 11
#
multicast routing-enable
#
ike local-name rta
#
acl number 3000
rule 5 permit ip source 20.1.1.1 0 destination 30.1.1.2 0
#
ipsec proposal p1
#
ike peer routerc v1
exchange-mode aggressive
pre-shared-key 12345
local-id-type name
remote-name rtc
remote-address 30.1.1.2
#
ipsec policy policy1 1 isakmp
security acl 3000
ike-peer routerc
proposal p1
#
interface Vlanif11
ip address 10.1.1.2 255.255.255.0
pim dm
igmp enable
#
#
ip address 20.1.1.1 255.255.255.0
ipsec policy policy1

#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
pim dm
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
#
#
return
#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#
interface Vlanif11
ip address 30.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
#
sysname RouterC
#
sysname RouterC
#
vlan batch 11
#
multicast routing-enable
#
ike local-name rta
#
acl number 3000
rule 5 permit ip source 30.1.1.2 0 destination 20.1.1.1 0
#
ipsec proposal p1
#
ike peer routerc v1
exchange-mode aggressive
pre-shared-key 12345
local-id-type name
remote-name rta
remote-address 30.1.1.2
#
ipsec policy policy1 1 isakmp
security acl 3000
ike-peer routerc
proposal p1
#
interface Vlanif11
ip address 10.2.1.2 255.255.255.0
pim dm
igmp enable
#


#
ip address 30.1.1.2 255.255.255.0
#
ip address 40.1.1.2 255.255.255.0
tunnel-protocol gre
source 30.1.1.2
pim dm
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
#
return
1.6.4 Example for Configuring the CE to Access a VPN Through a

GRE Tunnel of the Public Network
This section provides an example for configuring a CE to access a VPN through a GRE tunnel
on the public network. In this networking, the PE is indirectly connected to the CE; thus, no
physical interface can be bound to the VPN instance on the PE. Then, a GRE tunnel over the
public network is required between the CE and PE and the GRE tunnel is required to be bound
to the VPN instance on the PE. This allows the CE to access the VPN through the GRE tunnel.
As shown in Figure 1-8,
l routerPE1 and PE2 are located in the MPLS backbone network.
l CE1 is connected to PE1 through R1.
l CE2 is connected to PE2 directly.
l CE1 and CE2 belong to the same VPN.
CE1 and CE2 are required to interwork with each other.
NOTE
AR150/200 is CE1.

Figure 1-8 Networking diagram in which CEs access a VPN through the GRE tunnel of the
public network
Loopback1 Loopback1
MPLS
R1
Eth1/0/0 Eth1/0/0 Eth2/0/0 PE2
Eth2/0/0 Eth1/0/0 Eth2/0/0
Eth0/0/8 PE1 CE2
nel Tunnel0/0/1 Eth1/0/0
Tun
CE1
Tunnel0/0/1 Eth2/0/0
Eth0/0/1
VLANIF 11
PC1 PC2
Router Interface IP address

CE1 Vlanif 11 21.1.1.2/24
CE1 Eth0/0/8 30.1.1.1/24
CE1 Tunnel0/0/1 2.2.2.1/24
R1 Eth1/0/0 30.1.1.2/24
R1 Eth2/0/0 50.1.1.1/24
PE1 Loopback1 1.1.1.9/32
PE1 Eth1/0/0 50.1.1.2/24
PE1 Eth2/0/0 110.1.1.1/24
PE1 Tunnel0/0/1 2.2.2.2/24
PE2 Loopback1 3.3.3.9/32
PE2 Eth1/0/0 110.1.1.2/24
PE2 Eth2/0/0 11.1.1.2/24
CE2 Eth1/0/0 11.1.1.1/24
CE2 Eth2/0/0 41.1.1.2/24
PE1 and CE1 are indirectly connected. So the VPN instance on PE1 cannot be bound to the
physical interface on PE1. In such a situation, a GRE tunnel is required between CE1 and PE1.
vpn1 on PE1 can then be bound to the GRE tunnel, and CE1 can access the VPN through the
GRE tunnel.
1. Configure OSPF10 on PE1 and PE2 to implement the interworking between the two
devices, and then enable MPLS.
2. Configure OSPF20 on CE1, R1, and PE1 to implement the interworking between the three
devices.
3. Establish a GRE tunnel between CE1 and PE1.

4. Create VPN instances on PE1 and PE2. Then bind the VPN instance on PE1 to the GRE
tunnel interface, and bind the VPN instance on PE2 to the connected physical interface of
CE2.
5. Configure IS-IS routes between CE1 and PE1, and between CE2 and PE2 to implement
the interworking between the CEs and PEs.
6. Configure BGP on PEs to implement the interworking between CE1 and CE2.
Data Preparation
l IP addresses of the interfaces, process ID of the routing protocol, and AS number
l VPN instance names, RDs, and VPN targets on PEs
Procedure
Step 1 Configure the IP address for each interface and the routing protocol for the MPLS backbone
network.
Configure OSPF10 on PE1 and PE2, and then configure MPLS and LDP. The detailed
configurations are not mentioned here.
Step 2 Configure a routing protocol between CE1, R1, and PE1.
Configure OSPF20 on CE1, R1, and PE1. The detailed configurations are not mentioned here.
Step 3 Establish a GRE tunnel between CE1 and PE1.
# Configure CE1.
[CE1] interface tunnel0/0/1
[CE1-Tunnel0/0/1] ip address 2.2.2.1 255.255.255.0
[CE1-Tunnel0/0/1] tunnel-protocol gre
[CE1-Tunnel0/0/1] source 30.1.1.1
[CE1-Tunnel0/0/1] destination 50.1.1.2
# Configure PE1.
[PE1] interface tunnel0/0/1
[PE1-Tunnel0/0/1] ip address 2.2.2.2 255.255.255.0
[PE1-Tunnel0/0/1] tunnel-protocol gre
[PE1-Tunnel0/0/1] source 50.1.1.2
[PE1-Tunnel0/0/1] destination 30.1.1.1
# After the configuration, a GRE tunnel is established between CE1 and PE1.
Step 4 Create a VPN instance named vpn1 on PE1 and bind the VPN instance to the GRE tunnel.
[PE1]ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 100:1
[PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 export-extcommunity
[PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 import-extcommunity
[PE1-vpn-instance-vpn1-af-ipv4] quit
[PE1-vpn-instance-vpn1] quit
[PE1-Tunnel0/0/1] ip binding vpn-instance vpn1
[PE1-Tunnel0/0/1] ip address 2.2.2.2 255.255.255.0
Step 5 Create a VPN instance named vpn1 on PE2 and bind the VPN instance to the Eth interface.
[PE2]ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 200:1

[PE2-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 export-extcommunity

[PE2-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 import-extcommunity
[PE2-vpn-instance-vpn1-af-ipv4] quit
[PE2-vpn-instance-vpn1] quit
[PE2] interface ethernet2/0/0
[PE2- Ethernet2/0/0] ip binding vpn-instance vpn1
[PE2- Ethernet2/0/0] ip address 11.1.1.2 255.255.255.0
Step 6 Configure the IS-IS route between CE1 and PE1.
# Configure CE1.
[CE1] isis 50
[CE1-isis-50] network-entity 50.0000.0000.0001.00
[CE1-isis-50] quit
[CE1] interface ethernet1/0/0
[CE1-Ethernet1/0/0] isis enable 50
[CE1-Ethernet1/0/0] quit
[CE1] interface tunnel0/0/1
[CE1-Tunnel0/0/1] isis enable 50
[CE1-Tunnel0/0/1] quit
# Configure PE1.
[PE1] isis 50 vpn-instance vpn1
[PE1-isis-50] network-entity 50.0000.0000.0002.00
[PE1-isis-50] quit
[PE1-Tunnel0/0/1] isis enable 50
[PE1-Tunnel0/0/1] quit
Step 7 Configure the IS-IS route between CE2 and PE2.
# Configure CE2.
[CE2] isis 50
[CE2-isis-50] network-entity 50.0000.0000.0004.00
[CE2-isis-50] quit
# Configure PE2.
[PE2] isis 50 vpn-instance vpn1
[PE2-isis-50] network-entity 50.0000.0000.0003.00
[PE2-isis-50] quit
[PE2] interface ethernet2/0/0
[PE2-Ethernet2/0/0] isis enable 50
[PE2-Ethernet2/0/0] quit
Step 8 Set up the MP-BGP peer relationship between PE1 and PE2.
# On PE1, specify PE2 as an IBGP peer, set up the IBGP connection by using the loopback
interface, and enable the capability of exchanging VPN IPv4 routing information between PE1
and PE2.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 1
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE1-bgp-af-vpnv4] quit
# Enter the view of the BGP VPN instance vpn1 and import the direct routes and IS-IS routes.

[PE1-bgp] ipv4-family vpn-instance vpn1

[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] import-route isis 50
# On PE2, specify PE1 as an IBGP peer, set up the IBGP connection by using the loopback
interface, and enable the capability of exchanging VPN IPv4 routing information between PE2
and PE1.
[PE2] bgp 100
[PE2-bgp] peer 1.1.1.9 as-number 100
[PE2-bgp] peer 1.1.1.9 connect-interface loopback 1
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpnv4] peer 1.1.1.9 enable
[PE2-bgp-af-vpnv4] quit
# Enter the view of the BGP VPN instance vpn1 and import the direct routes and IS-IS routes.
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] import-route direct
[PE2-bgp-vpn1] import-route isis 50
Step 9 Import BGP routes into IS-IS.

# Configure PE1.
[PE1] isis 50
[PE1-isis-50] import-route bgp
# Configure PE2.
[PE2] isis 50
[PE2-isis-50] import-route bgp

# After the configuration, CE1 and CE2 can successfully ping each other.
<CE1> ping 41.1.1.2
0.00% packet loss
<CE2> ping 21.1.1.2
0.00% packet loss
----End
Configuration Files
l Configuration file of CE1
#

sysname CE1
#
isis 50
network-entity 50.0000.0000.0001.00
#
ip address 21.1.1.2 255.255.255.0
isis enable 50
#
interface Vlanif11
ip address 10.1.1.2 255.255.255.0
#
#
ip address 2.2.2.1 255.255.255.0
tunnel-protocol gre
source 30.1.1.1
isis enable 50
#
ospf 20
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return
l Configuration file of R1
#
sysname R1
#
ip address 30.1.1.2 255.255.255.0
#
ip address 50.1.1.1 255.255.255.0
#
ospf 20
area 0.0.0.0
network 30.1.1.0 0.0.0.255
network 50.1.1.0 0.0.0.255
#
return
l Configuration file of PE1
#
sysname PE1
#
ip vpn-instance vpn1
route-distinguisher 100:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
mpls lsr-id 1.1.1.9
mpls
lsp-trigger all
#
mpls ldp
#
isis 50 vpn-instance vpn1
network-entity 50.0000.0000.0002.00
import-route bgp
#
ip address 50.1.1.2 255.255.255.0
#
ip address 110.1.1.1 255.255.255.0

mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ip binding vpn-instance vpn1
ip address 2.2.2.2 255.255.255.0
tunnel-protocol gre
source 50.1.1.2
isis enable 50
#
bgp 100
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpn1
import-route direct
import-route isis 50
#
ospf 10
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 110.1.1.0 0.0.0.255
#
ospf 20
area 0.0.0.0
network 50.1.1.0 0.0.0.255
#
return
l Configuration file of PE2
#
sysname PE2
#
ip vpn-instance vpn1
route-distinguisher 200:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
mpls lsr-id 3.3.3.9
mpls
lsp-trigger all
#
mpls ldp
#
isis 50 vpn-instance vpn1
network-entity 50.0000.0000.0003.00
import-route bgp
#
ip address 110.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip binding vpn-instance vpn1
ip address 11.1.1.2 255.255.255.0
isis enable 50
#

interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
ipv4-family vpn-instance vpn1
import-route direct
import-route isis 50
#
ospf 10
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 110.1.1.0 0.0.0.255
#
return
l Configuration file of CE2

#
sysname CE2
#
isis 50
network-entity 50.0000.0000.0004.00
#
ip address 11.1.1.1 255.255.255.0
isis enable 50
#
ip address 41.1.1.2 255.255.255.0
isis enable 50
#
return
1.6.5 Example for Configuring the Keepalive Function for GRE

This section provides an example for configuring the Keepalive function of the GRE tunnel. In
this manner, the VPN does not select the GRE tunnel that cannot reach the remote end, and data
loss can be avoided.
As shown in Figure 1-9, Router A and Router B are configured with the GRE protocol. The two
ends of the GRE tunnel need be configured with the Keepalive function.
NOTE

Figure 1-9 Networking diagram of configuring the Keepalive function on two ends of a GRE
tunnel
Eth0/0/8 Eth0/0/8
20.1.1.1/24 Internet 30.1.1.2/24
GRE Tunnel
RouterA RouterB
Tunnel0/0/1 Tunnel0/0/1
40.1.1.1/24 40.1.1.2/24
To enable the Keepalive function on one end of the GRE tunnel, run the keepalive command in
the tunnel interface view on the end.
TIP
If the Keepalive function is enabled on the source end, the forwarding function is obligatory, and the
Keepalive function is optional for the destination end.
Data Preparation
l Data for configuring the routing protocol for the backbone network
l Interval for sending Keepalive messages
l Parameters of unreachable timer
Procedure
Step 1 Configure Router A and Router B to implement the interworking between the two devices.
The detailed procedures are not mentioned here.
Step 2 Configure a tunnel on Router A and enable the Keepalive function.
<RouterA> system-view
[RouterA] interface tunnel 0/0/1
[RouterA-Tunnel0/0/1] ip address 40.1.1.1 255.255.255.0
[RouterA-Tunnel0/0/1] keepalive period 20 retry-times 3
Step 3 Configure a tunnel on Router B and enable the Keepalive function.

<RouterB> system-view
[RouterB] interface tunnel 0/0/1
[RouterB-Tunnel0/0/1] ip address 40.1.1.2 255.255.255.0
[RouterB-Tunnel0/0/1] source 30.1.1.2
[RouterB-Tunnel0/0/1] destination 20.1.1.1
[RouterB-Tunnel0/0/1] keepalive period 20 retry-times 3
[RouterB-Tunnel0/0/1] quit

# The tunnel interface on Router A can successfully ping the tunnel interface on Router B.

<RouterA> ping -a 40.1.1.1 40.1.1.2

0.00% packet loss
# Enable the debugging of the Keepalive messages on Router A and view information about the
Keepalive messages.
<RouterA> terminal monitor
<RouterA> terminal debugging
<RouterA> debugging tunnel keepalive
May 18 2011 11:36:11.590.1+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP:Judge keepalive
finished. Received keepalive detecting packet from peer router.
<RouterA>
May 18 2011 11:36:11.590.2+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP_NSR: Mainboard u
lKeepaliveReceiveOpposite++ then send mbuf to slave when RECEIVE keepalive packe
t.
<RouterA>
May 18 2011 11:36:11.590.3+00:00 AR1220 TUNNEL/7/debug:GRE_FWD: Receive peer kee
palive on mainboard successfully. Put into decapsulation.
<RouterA>
May 18 2011 11:36:15.120.1+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP:Judge keepalive
finished. Received keepalive response packet from peer router.
<RouterA>
May 18 2011 11:36:15.120.2+00:00 AR1220 TUNNEL/7/debug:GRE_FWD: Receive the resp
onse keepalive packet on mainboard successfully, keepalive finished.
<RouterA>
May 18 2011 11:36:15.120.3+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP_NSR: Mainboard s
end mbuf to slaveboard when RECEIVE response packet.
----End
Configuration Files
#
sysname RouterA
#
ip address 20.1.1.1 255.255.255.0
#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
keepalive period 20
#
return

#
sysname RouterB
#
ip address 30.1.1.2 255.255.255.0
#
ip address 40.1.1.2 255.255.255.0
tunnel-protocol gre

source 30.1.1.2
keepalive period 20
#
return

Configuration Guide - VPN 2 L2TP Configuration
2 L2TP Configuration
About This Chapter
L2TP is a VPN technology that facilitates the tunneling of PPP frames and allows the Layer 2
termination points and PPP session endpoints to reside on different devices.
2.1 L2TP Overview

The L2TP protocol, which embodies the advantages of L2F and PPTP, is a industry standard on
Layer 2 tunnel protocols defined by the IETF.
2.2 Configuring Basic L2TP Functions
In L2TP configurations, you need to configure basic L2TP functions before configuring other
L2TP functions.
2.3 Configuring LAC
After being configured as an LAC, a device determines whether the user is an access user and
whether to initiate a connection to an LNS.
2.4 Configuring LNS
After receiving a tunnel setup request from an LAC, an LNS checks the authentication method
and determines whether to allow the LAC to set up an L2TP tunnel.
2.5 Adjusting L2TP Connection
After an L2TP tunnel is set up, you can configure or adjust L2TP parameters.
2.6 Maintaining L2TP
This section describes how to disconnect a tunnel forcibly, and monitor the running status of
L2TP.
This section provides L2TP configuration examples.

2.1 L2TP Overview

The L2TP protocol, which embodies the advantages of L2F and PPTP, is a industry standard on
Layer 2 tunnel protocols defined by the IETF.
2.1.1 Introduction to L2TP

L2TP messages are used in the maintenance of L2TP tunnels and transmission of PPP frames.
These messages are transmitted through UDP port 1701 in the TCP/IP protocol suite. L2TP uses
two types of messages: control messages and data messages.
The Point to Point Protocol (PPP) defines a kind of encapsulation technique, which ensures the
transmission of datagram of multiple protocols over Layer 2 point-to-point links. During the
transmission, PPP is performed between users and the Network Access Server (NAS), with Layer
2 link endpoints and PPP session termination points residing on the same device.
The Layer 2 Tunneling Protocol (L2TP) is used to transmit the Layer 2 PPP datagram over a
tunnel. L2TP extends the PPP model because L2TP permits Layer 2 link endpoints and PPP
session termination points to stay at different devices, and can realize information exchange
based on packet-switching technology. By combining the advantages of the Layer 2 Forwarding
(L2F) and Point-to-Point Tunneling Protocol (PPTP), L2TP is defined by the Internet
Engineering Task Force (IETF) as an industry standard of the Layer 2 tunneling protocol.
2.1.2 L2TP Features Supported by the AR150/200

The AR150/200 supports three L2TP tunnel modes.
Three Typical L2TP Tunnel Modes

Figure 2-1 shows the tunnel modes between the remote system and the L2TP Network Server
(LNS), and between the L2TP Access Concentrator (LAC) client (host running L2TP) and LNS.
Figure 2-1 Networking diagram of three typical L2TP tunnel modes

LAC
client
LAC
PSTN/ Network
Remote ISDN
system
LNS
Internal
server
Network
PC LAN
LAC
LNS
Internal
server

The three methods to establish an L2TP tunnel are as follows:
l NAS-initialized: initiated by remote users. The remote user connects to the LAC through
Public Switched Telephony Network (PSTN) or Integrated Services Digital Network
(ISDN). The LAC sends a request to the LNS for establishing a tunnel connection through
the Internet. Remote user addresses are assigned by the LNS. The LNS or the agent on the
LAC performs authentication and accounting on the remote user.
l Client-initialized: initiated directly by LAC users who support L2TP. In this mode, LAC
clients can send a request for establishing a tunnel connection directly to an LNS, without
the need to pass through the LAC device. The addresses of the LAC clients are assigned
by the LNS.
l LAC-Auto-Initiated: In most cases, an L2TP user directly dials up to a LAC, and only PPP
connection is established between the user and LAC. If the LAC serves also as a PPP client,
connection between the user and LAC can be established in other modes in addition to PPP.
The users can send IP packets to the LAC, and then the LAC forwards the packets to the
LNS. To make the LAC serve as a PPP client, create a virtual PPP user and server on the
LAC. The virtual PPP user negotiates with the virtual PPP server, and the virtual PPP server
establishes an L2TP tunnel with the LNS to negotiate with the LNS.
The AR150/200 can serve as a LAC and an LNS at the same time, and supports the incoming
calls of multiple concurrent users. If sufficient memory and line capacity are provided, L2TP
can receive and initiate multiple calls at the same time.
2.2 Configuring Basic L2TP Functions

In L2TP configurations, you need to configure basic L2TP functions before configuring other
L2TP functions.

Before configuring basic L2TP functions, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the required data. This can help you complete
the configuration task quickly and accurately.
The L2TP group is an important concept that you need to know when configuring L2TP. After
configuring an L2TP group, you can flexibly configure L2TP functions on the device and realize
point-to-point or point-to-multipoint networking applications between the L2TP Access
Concentrator (LAC) and the L2TP Network Server (LNS).
None
Data Preparation
To configure basic L2TP functions, you need the following data.

No. Data
1 Number of the L2TP group
2 Names of the tunnels on the LAC side and the LNS side
2.2.2 Configuring Basic L2TP Capability

To configure L2TP, you need to enable L2TP, create an L2TP group, and then configure other
functions. The specific configuration varies with the role of the device (LAC or LNS).
Context
The L2TP groups are numbered separately on the LAC and LNS. To establish the association
between the L2TP groups on LAC and LNS, you need to ensure that the configurations of the
L2TP groups are consistent, such as the received peer name of the tunnel, initiation of the L2TP
connection request, and LNS address.
After creating an L2TP group, you can configure other L2TP functions in the L2TP group view.
The configuration may vary with the role of the device (LAC or LNS).
Perform the following operations on the LAC side and the LNS side.
Procedure
Step 1 Run:
system-view

Step 2 Run:
l2tp enable
L2TP is enabled.
The L2TP functions can be realized only if L2TP is enabled. If L2TP is disabled, the device
cannot offer related L2TP functions even if parameters of L2TP have been configured.
By default, L2TP is disabled, and no L2TP group exists.
Step 3 Run:
l2tp-group group-number
An L2TP group is created and the L2TP group view is displayed.

The group number 1 indicates a default L2TP group.
To receive the request for establishing a tunnel connection from an unknown peer, or meet the
testing requirement, you can create a default L2TP group.
Step 4 Run:
tunnel name tunnel-name
The name of a tunnel at the local end is configured.

You can specify the name of a tunnel at the local end on either the LAC side or the LNS side.
By default, the name of a tunnel at the local end is the host name of the device.

NOTE
The name of the tunnel on the LAC side must be the same as the remote end name of the receiving tunnel
on the LNS side.
----End
2.3 Configuring LAC

After being configured as an LAC, a device determines whether the user is an access user and
whether to initiate a connection to an LNS.

Before configuring an LAC, familiarize yourself with the applicable environment, complete the
pre-configuration tasks, and obtain the required data. This can help you complete the
configuration task quickly and accurately.
A device does not send a request for establishing an L2TP tunnel with another device or an LNS
server until certain conditions are met.
To judge whether a user is an access user and whether a connection with the LNS needs to be
established, you must set conditions to distinguish the information about the access user and
specify the IP address of the LNS.
Either of two triggering conditions, namely, a full user name, or the specified domain name of
a user, is needed to initiate the L2TP connection request.
When initiating a tunnel establishment request, the LAC needs to send the source address of the
tunnel to the LNS.
Before configuring the LAC, complete the following tasks:
l Configuring Basic L2TP Functions
Data Preparation
To configure the LAC, you need the following data.
No. Data
2 IP address of the LNS
3 User full name or domain name used to trigger an L2TP connection
4 Interface type and interface number used to initiate the request for tunnel establishment
5 User name and password used for authentication

No. Data
6 (For RADIUS authentication) Authentication scheme name, RADIUS template name,

IP addresses and interfaces of RADIUS servers, key, and retransmission times
2.3.2 Configuring an L2TP Connection on LAC Side

After receiving a call from an LAC client, an LAC sends a connection request to an LNS in the
configuration sequence of the LNSs. If receiving a response from an LNS, the LNS becomes
the peer of the L2TP tunnel.
Context
Do as follows on the router:
Procedure
Step 1 Run:
system-view

Step 2 Run:
The L2TP group view is displayed.

Step 3 Choose one of the following triggering conditions to initiate a call when the local end is specified
as the LAC:
l If a user accesses the L2TP tunnel by providing the domain name, run the start l2tp { ip ip-
address }&<1-4> domain domain-name command to specify the triggering condition as the
domain name.
l If a user accesses the L2TP tunnel by providing the full user name, run the start l2tp { ip
ip-address }&<1-4> fullusername user-name command to specify the triggering condition
as the full user name.
----End
2.3.3 (Optional) Configuring LAC Auto-Dial

The router initiates virtual private dial-up network (VPDN) dialup and serves as a PPP client
and LAC.
Context
Enterprises expect virtual private networks (VPNs) to be constructed between the headquarters
and branches. The VPN construction costs, however, are high if the enterprises lease resources
from carriers. The VPDN technology allows an enterprise to construct a VPN, and the carrier
needs to provide Internet access for the enterprise. The investments are lowered. Branch routers
establish the VPDN network by dialing up and serve as PPP clients and LACs.
Perform the following steps on the router.

Procedure
Step 1 Run:
system-view

Step 2 Run:
interface virtual-template vt-number
A virtual template interface is created and the virtual template interface view is displayed.
Step 3 Configure an IP address for the virtual interface in any of the following methods:
l Run:
ip address ip-address { mask | mask-length }
An IP address is configured for the interface.

l Run:
ip address ppp-negotiate
The dialer interface is configured to obtain an IP address from PPP negotiation.

l Run:
ip address unnumbered interface interface-type interface-number
The virtual template interface is configured to borrow an IP address from another interface.
Step 4 Run the following command as required.
l Run:
ppp pap local-user username password { cipher | simple } password
The user name and password in PAP authentication are configured.

l 1. Run:
ppp chap user username
The user name in CHAP authentication is configured.

2. Run:
ppp chap password { cipher | simple } password
The password in CHAP authentication is configured.

The user name and password configured on the local device must be the same as those configured
on the remote device. By default, the local device sends a request to the remote device with the
empty user name and password in PAP authentication.
Step 5 Run:
l2tp-auto-client enable
LAC auto-dial is enabled.

Step 6 Run:
quit
Return to the system view.

Step 7 Run:
ip route-static ip-address { mask | mask-length } virtual-template vt-number
A static route is configured.

Set the destination network segment of the static route to the network segment of the headquarters
and the outbound interface to the virtual PPP interface. After the configurations are complete,

packets from users are sent out from the LAC through the PPP interface and reach the LNS
through an L2TP tunnel.
----End
2.3.4 (Optional) Configuring Local Authentication on LAC Side

An LAC authenticates the user through local authentication. The LAC is configured with the
user name and password. Whether the password is in cipher text or in plaintext is determined
by the user. The password in cipher text is more secure.
Context
NOTE
For more information about Authorization, Authentication and Accounting (AAA), refer to the Huawei
AR150&200 Series Enterprise Routers Configuration Guide - Security.
Do as followings on the router:
Procedure
Step 1 Run:
system-view
Step 2 Run:
aaa
The AAA view is displayed.
Step 3 Choose one of the following methods to configure the user name and password.
l To configure a password displayed in plain text, run the local-user user-name password
simple password command.
l To configure a password displayed in encrypted text, run the local-user user-name
password cipher password command.
The LAC checks the user name and password of an access user. If they are consistent with the
local registered user name and password, the user is valid. The access user can initiate a tunnel
connection request only after the authentication on the LAC side succeeds.
By default, the LAC side is configured with no user name and password. and the local
authentication is adopted. Therefore, the LAC side must be configured with user name and
password for local authentication.
The password in plain text is a string of 1 to 16 characters and the password in cipher text is a
string of 24 characters.
----End
2.3.5 (Optional) Configuring RADIUS Authentication on LAC Side

An LAC sends the user name and password of the user to the RADIUS server for authentication.
The RADIUS protocol performs centralized management over a large number of dispersed users
and performs authentication, authorization, and accounting on users.

Procedure
l Creating the Authentication and Accounting (AAA) Scheme
1. Run:
system-view

2. Run:
aaa

3. Run:
authentication-scheme authentication-scheme-name
An authentication scheme is created and the view of the authentication scheme is

displayed.
4. Run:
authentication-mode radius
The authentication mode is specified as RADIUS.

5. Run:
quit
Return to the AAA view.

6. Run:
accounting-scheme accounting-scheme-name
An accounting scheme is created and the view of the accounting scheme is displayed.
NOTE
RADIUS accounting is optional.

7. Run:
accounting-mode radius
The accounting mode is specified as RADIUS.

l Configuring the RADIUS Template and Related Parameters
1. Run:
system-view

2. Run:
radius-server template template-name
A RADIUS server template is created.

3. Run:
radius-server authentication ip-address port
The IP address and port of the RADIUS authentication server are configured.
4. Run:
radius-server accounting ip-address port

The IP address and port of the RADIUS accounting server are configured.
5. Run:
radius-server shared-key { cipher | simple } key-string
The key of the RADIUS server is configured.

6. Run:
radius-server retransmit retry-times
The retransmitting times of the RADIUS server are configured.

l Creating a Domain and Applying the RADIUS Template and the Authentication and
Accounting Scheme
1. Run:
system-view

2. Run:
aaa

3. Run:
domain domain-name
The domain is created and the domain view is displayed.

4. Run:
radius-server template-name
The RADIUS template is applied.

5. Run:
authentication-scheme authentication-scheme-name
The authentication scheme is applied.

6. Run:
accounting-scheme accounting-scheme-name
The accounting scheme is applied.

NOTE
The mandatory configurations on the RADIUS service are the user name, password, IP address for
the NAS device to access the RADIUS server, shared key, and port number of the RADIUS server.
The user name and password must be set the same as the user side.
----End

After an LAC is configured, you can view information about L2TP tunnels and L2TP sessions.
Prerequisites
The configurations of the LAC function are complete.

Procedure
l Run the display l2tp tunnel command to check information about the L2TP tunnel.
l Run the display l2tp session command to check information about the L2TP session.
l Run the display l2tp-group [ group-number ] command to check the configuration about
one special L2TP group.
----End
Example
Run the display l2tp tunnel command on the LAC side. If information about the L2TP tunnel
is displayed, it means the configurations on both the LAC side and the LNS side succeed. For
example:
<Huawei> display l2tp tunnel
Total tunnel = 1
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
1 1 202.38.160.1 57344 1 LAC
Run the display l2tp session command, and you can view that the L2TP session is established.
For example:
<Huawei> display l2tp session
Total session = 1
LocalSID RemoteSID LocalTID
2036 1469 1
Run the display l2tp-group [ group-number ] command, and you can check the configuration
about one special L2TP group. For example:
<Huawei> display l2tp-group 1
-----------------------------------------------
L2tp-index : 1
GroupType : REQUEST_DIALIN_L2TP
TunnelAuth : Use tunnel authentication
LocalName : lac1
TunnelPass : huawei
Encrypt : 0
Hello : 60
Retransmit : 5
Timeout : 2
IfIndex : 4294967295
SrcIp : 255.255.255.255
VtNum : 0
RemoteName :
ForceChap : 0
LcpReg : 0
LcpMismatch : 0
tunnel each user : 0
-----------------------------------------------
2.4 Configuring LNS

After receiving a tunnel setup request from an LAC, an LNS checks the authentication method
and determines whether to allow the LAC to set up an L2TP tunnel.


Before configuring an LNS, familiarize yourself with the applicable environment, complete the
pre-configuration tasks, and obtain the required data. This can help you complete the
An LNS offers different virtual templates to receive the tunnel-establishing requests from
different LACs. After receiving one of these requests, the LNS needs to check whether the name
of the LAC (remote end) are valid, and then decide whether to permit the remote end to establish
a tunnel.
After an LAC performs the user authentication, an LNS can re-authenticates the user. That is,
the user is authenticated twice. One is on the LAC, and the other is on the LNS.
After a user passes the authentication on the LNS, the user can communicate with the LNS. If
the user authentication on the LNS fails, L2TP is notified to remove the L2TP connection. In
this manner, an L2TP tunnel is established only after authentications on both the LAC and the
LNS are successful.
The LNS authenticates users in three ways, namely, agent authentication, mandatory CHAP
authentication, and LCP re-negotiation. Among them, the LCP re-negotiation has the highest
priority.
l LCP re-negotiation
LCP re-negotiation adopts the authentication mode configured on the related virtual
template.
For the NAS-initialized VPN service, a user firstly performs the PPP negotiation with
the NAS when a PPP session starts. If the negotiation is performed well, then NAS
initializes an L2TP tunnel connection, and transmits user information to the LNS. The
LNS then judges whether the user is legal or not based on the received agent
authentication information.
If a more restrict authentication is required on the LNS, or the LNS needs to obtain
certain user information directly (Mostly when the LNS and LAC are from different
providers), LCP re-negotiation needs to be performed between the LNS and the user,
whereas the agent authentication information on the NAS is ignored.
l Mandatory CHAP authentication
If only mandatory CHAP authentication is configured, the LNS performs CHAP
authentication for users.
l Agent authentication
If neither LCP re-negotiation nor mandatory CHAP authentication is configured, the LNS
performs agent authentication for users. In this authentication mode, the LAC sends all user
authentication information to the LNS. The LNS then authenticate the user information
based on the local configuration.
Suppose the authentication mode configured on the virtual template is CHAP, and that
configured on LAC is PAP when LNS adopts agent authentication. The authentication
cannot pass successfully, because the authentication level of CHAP is higher than that of
PAP.

NOTE
After LCP re-negotiation is enabled, if authentication is not configured on the related virtual template, LNS
will not perform secondary authentication for the user. In this manner, the user is authenticated only once
on the LAC.
For other cases, secondary authentication is performed. The authentication mode "none" is also a type of
authentication.
Before configuring the LNS, you need to complete the following tasks:
l Configuring Basic L2TP Functions

l Configuring a virtual template to establish an L2TP connection
Data Preparation
To configure LNS, you need the following data.
No. Data
2 Number of the virtual template
3 Name of remote end in the tunnel
4 Local user name and password
2.4.2 Configuring an L2TP Connection on LNS

After receiving a tunnel setup request from an LAC, an LNS checks the LAC name and allows
the LAC to set up an L2TP tunnel if the LAC name is a valid name of the remote end. The LNS
can receive the tunnel setup requests from different LACs by using different virtual templates.
Context
Do as follows on LNS:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Choose one of the following commands to configure the name of the remote end of the tunnel.

l If the L2TP group number is not 1, run the allow l2tp virtual-template virtual-template-
number remote remote-name command.
l If the L2TP group number is 1, run the allow l2tp virtual-template virtual-template-
number [ remote remote-name ] command.
The default L2TP group number is 1. When the group number of L2TP is set to 1, you need not
specify the remote name of the tunnel. If you specify the name of the remote end in the view of
the L2TP group 1, L2TP group 1 will not be regarded as the default L2TP group any more.
NOTE
Only the L2TP group with the group number 1 can be set as the default group.
In the same L2TP group, the start command and the allow l2tp command are mutually exclusive. When
one is configured, the other becomes invalid automatically.
----End
2.4.3 (Optional) Configuring User Authentication on LNS

After an LAC performs user authentication, an LNS can re-authenticates the user. The LNS
authenticates users in three ways, namely, agent authentication, mandatory CHAP
authentication, and LCP re-negotiation. LCP re-negotiation has the highest priority.
Context
NOTE
For more information about AAA, refer to the Huawei AR150&200 Series Enterprise Routers
Configuration Guide - Security.
Do as follows on LNS:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Choose one of the following commands to configure the authentication scheme.
l Run the mandatory-lcp command to configure the mandatory LCP re-negotiation.
l Run the mandatory-chap to configure the mandatory local CHAP authentication.
l Skip this step to perform the agent authentication.
By default, the agent authentication is adopted.
Step 4 Run:
quit

Step 5 Run:
aaa

Step 6 Choose one of the following commands to configure the user authentication.
l Run the local-user user-name password { simple | cipher } password command to configure
the user name and password if the local authentication is adopted.
The password in plain text is a string of 1 to 16 characters and the password in cipher text is
a string of 24 characters.
l For the mandatory local CHAP authentication, LCP re-negotiation, and agent authentication,
the user name and password for authentication must be set on LNS.
l If the RADIUS authentication is adopted, see 2.3.5 (Optional) Configuring RADIUS
Authentication on LAC Side.
The user name and password configured on LNS must be consistent with those configured on
LAC.
By default, the local authentication is adopted.
----End
2.4.4 Allocating Addresses to Access Users

Users belong to different domains. The users whose domains are not specified belong to the
default domain. After an L2TP tunnel is set up between an LAC and an LNS, the LNS selects
an IP address from the IP address pool of the domain to which the user belongs and then assigns
the IP address to the user.
Context
In the AR150/200, each access user belongs to a domain. If a user with no domain specified
accesses an L2TP tunnel, the user uses the default domain. After the L2TP tunnel between the
LAC and LNS is set up, the LNS should assign the IP address for the access user from the address
pool of the user domain.
Procedure
Step 1 For details of the address pool configuration and address assignment, refer to the Huawei
AR150&200 Series Enterprise Routers Configuration Guide - IP Services and Configuration
Guide - Security.
----End

After an LNS is configured, you can view information about L2TP tunnels and L2TP sessions.
Prerequisites
The configurations of the LNS function are complete.
Procedure
l Run the display l2tp tunnel command to check information about the L2TP tunnel.
l Run the display l2tp session command to check information about the L2TP session.

l Run the display l2tp-group [ group-number ] command to check the configuration about
one special L2TP group.
l Run the display access-user command to view information about the accessed users.
----End
Example
Run the display l2tp tunnel command. If information about the L2TP tunnel is displayed, it
means the configuration succeeds. For example:
<Huawei> display l2tp tunnel
Total tunnel = 1
1 1 12.1.1.1 1701 1 LNS
Run the display l2tp session command, and you can view that the L2TP session is established.
For example:
<Huawei> display l2tp session
Total session = 1
1 1 1
Run the display l2tp-group [ group-number ] command, and you can check the configuration
about one special L2TP group. For example:
<Huawei> display l2tp-group 1
-----------------------------------------------
L2tp-index : 1
GroupType : ACCEPT_DIALIN_L2TP
TunnelAuth : Use tunnel authentication
LocalName : lns
TunnelPass : huawei
Encrypt : 0
Hello : 60
Retransmit : 5
Timeout : 2
IfIndex : 4294967295
SrcIp : 255.255.255.255
VtNum : 1
RemoteName : lac1
ForceChap : 0
LcpReg : 0
LcpMismatch : 0
tunnel each user : 0
-----------------------------------------------
2.5 Adjusting L2TP Connection

After an L2TP tunnel is set up, you can configure or adjust L2TP parameters.

Before adjusting an L2TP tunnel, familiarize yourself with the applicable environment, complete
the pre-configuration tasks, and obtain the required data. This can help you complete the

This section describes the common L2TP configurations, which can be applied for either the
LAC or the LNS.
l Tunnel authentication: Either an LAC or an LNS can send tunnel authentication requests.
An L2TP tunnel can be established only if both the LAC and the LNS are enabled with the
tunnel authentication, and have the same password (not null). Otherwise, the local end
disconnects the tunnel automatically. If the tunnel authentications are disabled on both ends,
the L2TP tunnel still cannot be established even if the passwords on two ends are the same.
l Attribute Value Pair (AVP) hidden transmission: AVP is adopted in the L2TP protocol to
transmit and negotiate some parameter attributes of L2TP. For the sake of security, users
transmit these AVPs in hidden mode.
l Hello packets sending: To check the connectivity of a tunnel, the LAC and the LNS send
Hello packets to each other periodically, and the receiver responds the peer within a
specified interval. If no response is received from the peer within the specified interval, the
local end resends the Hello packets. After the Hello packets are resent for more than three
times, the L2TP tunnel is regarded as disconnected. The tunnel connection needs to be re-
established between the LAC and the LNS.
NOTE
All the configurations described in this section are optional. You can take the default settings in most cases.
None
Data Preparation
To adjust the L2TP connection, you need the following data.
No. Data
2 Password for tunnel authentication
3 Interval for sending Hello packets
2.5.2 Configuring Security Options for L2TP Connection

To ensure security, you can enable tunnel authentication on both ends, enable tunnel
authentication before setting up a tunnel, and transmit AVPs in hidden mode.
Context
Do as follows on the LNS side or the LAC:
Procedure
Step 1 Run:
system-view


Step 2 Run:

Step 3 Run:
tunnel authentication
The tunnel authentication is enabled.

By default, the tunnel authentication is enabled.
You can decide whether to enable tunnel authentication before establishing a tunnel connection.
To ensure the tunnel security, you are recommended to enable the tunnel authentication.
NOTE
If tunnel authentication is enabled on one end (either the LAC or the LNS), the peer must be enabled with
tunnel authentication.
Step 4 Choose one of the following commands to configure a password.

l Run the tunnel password simple password command to configure a password in plain text.
l Run the tunnel password cipher password command to configure a password in encrypted
text.
By default, the password for tunnel authentication is null.
Step 5 Run:
tunnel avp-hidden
The AVP data is transmitted in hidden mode.

By default, the AVP data is transmitted in plain text. The function of AVP hidden transmission
works only when both ends adopt the tunnel authentication.
----End
2.5.3 Configuring L2TP Connection Parameters

After an L2TP tunnel is set up, you can configure or adjust the interval for sending Hello packets.
Context
Do as follows on the LNS or the LAC:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
tunnel timer hello interval
The interval for sending Hello packets is set.
By default, the interval for sending Hello packets is 60 seconds.
----End
2.6 Maintaining L2TP

This section describes how to disconnect a tunnel forcibly, and monitor the running status of
L2TP.
2.6.1 Disconnecting a Tunnel Forcibly

When there are no access users, a network fault occurs, or the administrator needs to disconnect
a tunnel, you can run the reset l2tp tunnel command to disconnect the tunnel and the sessions in
the tunnel.
Procedure
l Run the reset l2tp tunnel { peer-name remote-name | local-id tunnel-id } command to
disconnect the L2TP tunnel forcibly in the user view.
If the parameter peer-name is specified, all the tunnels with this name are cleared. If the
parameter tunnel-id is specified, only the tunnel with this tunnel ID is cleared.
A tunnel is cleared when the number of access users is 0, a network fault occurs, or the
administrator needs to disconnect the tunnel.
In addition, either the LAC or the LNS can request for clearing a tunnel initiatively. The
side receiving the clearing request must reply with the Acknowledgement (ACK) message,
and then wait for a certain period before performing the tunnel clearing operation. In this
manner, even if the ACK message is lost, the side can still have time to receive the resent
clearing request.
After an L2TP tunnel is disconnected forcibly, all control and session connections in the
tunnel are cleared. The tunnel can be re-established when a new user dials in.
----End
2.6.2 Monitoring the Running Status of L2TP

In routine maintenance, you can run the L2TP-related display commands to view the running
status of L2TP.
Context
In routine maintenance, you can run the following commands to view the running status of L2TP.
Procedure
l Run the display l2tp session command to view information about the L2TP session.

l Run the display l2tp tunnel command to view information about the L2TP tunnel.
l Run the display access-user command to view information about the user sessions.
l Run the display l2tp-group command to view information about current L2TP groups.
----End
2.6.3 Debugging L2TP Information

When an L2TP fault occurs, you can run the L2TP related debugging commands to debug L2TP
and locate the fault.
Context
NOTE
Debugging affects the system performance. So, after the debugging, run the undo debugging all command
to disable it immediately.
When an L2TP fault occurs, run the following debugging commands in the user view to debug
L2TP and locate the fault.
For the procedure of outputting the debugging information, see the chapter "Maintenance and
Debugging" in the Huawei AR150&200 Series Enterprise Routers Configuration Guide - System
Management.
Procedure
l Run the debugging l2tp all command in the user view to enable complete L2TP debugging.
l Run the debugging l2tp control command in the user view to enable control packet
debugging.
l Run the debugging l2tp dump command in the user view to enable PPP packet debugging.
l Run the debugging l2tp error command in the user view to enable L2TP error debugging.
l Run the debugging l2tp event command in the user view to enable L2TP event debugging.
l Run the debugging l2tp hidden command in the user view to enable hidden AVP
debugging.
l Run the debugging l2tp payload command in the user view to enable L2TP packet
debugging.
l Run the debugging l2tp timestamp command in the user view to enable L2TP time stamp
debugging.
----End

This section provides L2TP configuration examples.
2.7.1 Example for Configuring NAS-Initialized VPNs (Domain

Name Access)
This section provides an example for configuring a NAS-initialized VPN with users accessing
the network through domain names, and the user name and password being authenticated locally
on the LAC and LNS.

As shown in Figure 2-2, PC1 connects the Public Switched Telephone Network (PSTN) through
a Modem; and then connects the LAC, namely, Router A, across the PSTN. PC2 connects Router
A through a tunnel. The LAC and the LNS are connected through the Internet. The LAC and
the LNS communicate with each other through a tunnel. Users access the tunnel by using domain
names. On both the LAC and the LNS, the user name and the password are authenticated locally.
NOTE
When the AR150/200 communicates with a non-Huawei device, configure the AR150/200 to invert clock
signals transmitted by a synchronous serial interface as required.
Figure 2-2 Networking diagram of a NAS-Initialized VPN
Modem
PC1 PSTN RouterA RouterB
Internet
ISDN LAC LNS

Server
Tunnel headquarters
PC2
1. A user intends to communicate with the server in the headquarters. The IP address of the
server is a private address. In this manner, the user cannot access the server directly through
the Internet. A VPN is then needed to help the user access the data of the internal network.
2. The user accesses the headquarters by using the domain name "huawei.com". The LNS
needs to configure an address pool in this domain that can allocate an IP address for the
user.
Data Preparation
l Consistent user name, domain name, and password of the router at both the user side and
the LAC side
l Protocol used on the LNS side, tunnel authentication mode (CHAP is used), password for
the tunnel, and local and remote names of the LNS
l Number, IP address, and network mask of the virtual template
l L2TP group number
l Number, range, and address mask of the remote address pool

Procedure
Step 1 Configure the user side.
Create a dial-in connection, and an access number named Huawei1. In addition, receive the
address assigned by the LNS server.
Enter the user name "vpdnuser@huawei.com" in the dial-up terminal window that pops up, with
the password being Hello. Note that the user name and password should have been registered
on the LNS server of the company.
Step 2 Configure Router A (LAC).
In this example, the IP address of Serial 1/0/0 on the LAC that connects the tunnel is
202.38.160.1; the IP address of Serial 1/0/0 on the LNS that connects the tunnel is 202.38.160.2.
# Configure IP addresses for both serial ports.

<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface serial 1/0/0
[RouterA-Serial1/0/0] link-protocol ppp
[RouterA-Serial1/0/0] ip address 202.38.160.1 255.255.255.0
[RouterA-Serial1/0/0] quit
# Create an L2TP group and configure related attributes.

[RouterA] l2tp enable
[RouterA] l2tp-group 1
[RouterA-l2tp1] tunnel name LAC
[RouterA-l2tp1] start l2tp ip 202.38.160.2 domain huawei.com
# Enable the tunnel authentication and set a tunnel authentication password.

[RouterA-l2tp1] tunnel authentication
[RouterA-l2tp1] tunnel password simple quidway
[RouterA-l2tp1] quit
# Set the user name and password. Note that the user name and password must be consistent
with those set on the user side.
[RouterA] aaa
[RouterA-aaa] local-user vpdnuser@huawei.com password simple Hello
[RouterA-aaa] local-user vpdnuser@huawei.com service-type ppp
# Create a domain that users access.

[RouterA-aaa] domain huawei.com
Step 3 Configure Router B (LNS).
# Configure an IP address for Serial 1/0/0 on the LNS.

[Huawei] sysname RouterB
[RouterB] interface serial 1/0/0
[RouterB-Serial1/0/0] link-protocol ppp
[RouterB-Serial1/0/0] ip address 202.38.160.2 255.255.255.0
[RouterB-Serial1/0/0] quit
# Create a virtual template and configure related parameters.

[RouterB] interface virtual-template 1
[RouterB-Virtual-Template1] ip address 192.168.0.1 255.255.255.0
[RouterB-Virtual-Template1] ppp authentication-mode chap
[RouterB-Virtual-Template1] quit

# Enable L2TP and create an L2TP group.

[RouterB] l2tp enable
[RouterB] l2tp-group 1
# Configure the name of the local end and the name of the peer.
[RouterB-l2tp1] tunnel name LNS
[RouterB-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable the tunnel authentication and set a tunnel authentication password.

[RouterB-l2tp1] tunnel authentication
[RouterB-l2tp1] tunnel password simple quidway
# Configure the mandatory local CHAP authentication.

[RouterB-l2tp1] mandatory-chap
[RouterB-l2tp1] quit
# # Set the user name and password. Note that the user name and password must be consistent
with those set on the LAC side.
[RouterB] aaa
[RouterB-aaa] local-user vpdnuser@huawei.com password simple Hello
[RouterB-aaa] local-user vpdnuser@huawei.com service-type ppp
# Configure a domain that users access.

[RouterB-aaa] domain huawei.com
[RouterB-aaa-domain-huawei.com] quit
[RouterB-aaa] quit
# Set an address pool to assign addresses to dial-in users.

[RouterB] ip pool 1
[RouterB-ip-pool-1]network 192.168.0.0 24

After VPN users log into the tunnel, run the display l2tp tunnel command. You can find that
the tunnel is set up. Take the display on the LNS as an example:
[RouterB] display l2tp tunnel
Total tunnel = 1
1 1 202.38.160.1 57344 1 LAC
Run the display l2tp session command. You can check whether the L2TP session is set up. Take
the display on the LNS side as an example.
[RouterB] display l2tp session
Total session = 1
2036 1469 1
In this manner, VPN users can access the server in the headquarters.
----End
Configuration Files
#
sysname RouterA

#
l2tp
enable
#
aaa
authentication-scheme
default
authorization-scheme
default
accounting-scheme
default
domain
default
domain
default_admin
domain
huawei.com
local-user vpdnuser@huawei.com password simple
Hello
local-user vpdnuser@huawei.com service-type
ppp
#
interface
Serial1/0/0
link-protocol
ppp
ip address 202.38.160.1
255.255.255.0
#
l2tp-group
1
tunnel password simple
quidway
tunnel name
LAC
start l2tp ip 202.38.160.2 domain
huawei.com
#
return
#
sysname RouterB
#
ip pool
1
network 192.168.0.0 mask
255.255.255.0
#
aaa
authentication-scheme
default
authorization-scheme
default
accounting-scheme
default
domain
default
domain
huawei.com
local-user vpdnuser@huawei.com password simple
Hello
local-user vpdnuser@huawei.com service-type
ppp
#
interface Virtual-
Template1
ppp authentication-mode
chap
ip address 192.168.0.1

255.255.255.0
#
interface
Serial1/0/0
link-protocol
ppp
ip address 202.38.160.2
255.255.255.0
#
l2tp-group
1
mandatory-
chap
allow l2tp virtual-template 1 remote
LAC
tunnel password simple
quidway
tunnel name
LNS
#
return
2.7.2 Example for Configuring NAS-Initialized VPNs (Dialup

Access)
This section provides an example for configuring a NAS-initialized VPN with VPN users
accessing the NAS through the PSTN or ISDN.
As shown in Figure 2-3, Users access the NAS through the PSTN or the Integrated Services
Digital Network (ISDN). The LNS, namely, Router A, connects the NAS through the Internet.
Figure 2-3 Networking diagram of NAS-initialized VPN
Internet
PSTN/ISDN
Tunnel
VPN RouterA
Client NAS Headquarters
LNS
The procedure for a user to access the headquarters is as follows:
1. A user dials in the PSTN or ISDN.

2. The NAS performs the user authentication. If the user is found to be a VPN user, the NAS
sends a tunnel-connecting request to the LNS.
3. After a tunnel between the NAS and the LNS is set up, the NAS sends the information
about the negotiation with the VPN user as the contents of the packets to the LNS.
4. The LNS decides whether to accept the connecting request according to the negotiated
information.

5. The user communicates with the headquarters by using the tunnel between the NAS and
the LNS.
6. The user accesses the headquarters network by using the default domain (the domain name
is "default") and adopts the local authentication. The addresses are allocated from the
address pool. In this mode, the address pool should be configured in the AAA view of the
LNS.
Data Preparation
l User name, password, and access code of the VPN
l User name and password for the Remote Authentication Dial in User Service (RADIUS)
authentication (the same as user name and password of the VPN)
l On the LNS router, number of the virtual template, IP address and mask of the template,
and L2TP group number
Procedure
Step 1 Configure the user side.
Enter the VPN user name "vpdnuser", the password "Hello", and the access code "170" in the
dial-up network window. Then enter the user name and password for the RADIUS authentication
in the dial-up terminal window.
Step 2 Configure NAS.
In this example, the access server is used as the LAC device.
# Set 170 as the access code on the access server.
# On the RADIUS access server, set the user name and password for a VPN user, and set the IP
address for the corresponding LNS device. (In this example, the IP address of the LNS interface
connected with the tunnel is 202.38.160.2.)
# Define the local device name as A8010, and fulfill the tunnel authentication. The password
used in the tunnel authentication is "huawei".
NOTE
To configure A8010, refer to the corresponding A8010 manuals.
Step 3 Configure the LNS router.

# Configure an IP address for Serial 1/0/0.
# Create a virtual template and configure related parameters.

[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ip address 192.168.0.1 255.255.255.0
[RouterA-Virtual-Template1] ppp authentication-mode chap

[RouterA-Virtual-Template1] remote address pool 1

[RouterA-Virtual-Template1] quit
# Enable L2TP and create an L2TP group.

# Configure the name of the tunnel local end and the peer end on LNS.
[RouterA-l2tp1] tunnel name LNS
[RouterA-l2tp1] allow l2tp virtual-template 1 remote A8010
# Enable the tunnel authentication and set the password.

[RouterA-l2tp1] tunnel password simple huawei
# Create an address pool and assign an address to a dial-in user.

[RouterA] ip pool 1
[RouterA-ip-pool-1]network 192.168.0.0 mask 24
# Set the user name and password, which must be the same as those set on the user side.
[RouterA] aaa
[RouterA-aaa] local-user vpdnuser password simple Hello
[RouterA-aaa] local-user vpdnuser service-type ppp
[RouterA-aaa] quit

After VPN users log in to the LAC or LNS devices, run the display l2tp tunnel command and
you can find the tunnel is set up. Take the display on the LAC as an example:
<RouterA> display l2tp tunnel
Total tunnel = 1
1 1 202.38.160.3 1701 1 A8010
Running the display l2tp session command, you can check whether sessions are set up. Take
the display on the LNS as an example.
<RouterA> display l2tp session
Total session = 1
1469 2036 1
In this manner, the VPN user can access the network of the headquarters.
----End
Configuration Files
NOTE
Only the configuration file of the LNS is listed.

#
sysname RouterA
#
l2tp enable
#
ip pool 1
network 192.168.0.0 mask 255.255.255.0
#

aaa
authentication-scheme default
authorization-scheme default
accounting-scheme default
local-user vpdnuser password simple Hello
local-user vpdnuser service-type ppp
#
interface Virtual-Template1
ppp authentication-mode chap
remote address pool 1
ip address 192.168.0.1 255.255.255.0
#
interface Serial 1/0/0
link-protocol ppp
ip address 202.38.160.2 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote A8010
tunnel password simple huawei
tunnel name LNS
#
return
2.7.3 Example for Configuring Client-Initialized VPNs

This section provides an example for configuring a client-initialized VPN with clients accessing
the NAS through the PSTN.
As shown in Figure 2-4, the staff on business trip accesses the NAS through the PSTN, and
Router A on the LNS side of the company headquarters connects the NAS through the Internet.
The data generated during the communication between the staff and the LNS is transmitted
through the tunnel.
Figure 2-4 Networking diagram of client-initialized VPNs
Staff on NAS RouterA

errands LNS
PSTN Internet
Server
Headquarters
Tunnel
1. The VPN user firstly connects the Internet, and then originates the tunnel connection request
to the LNS.
2. A virtual tunnel is set up between the VPN user and the LNS after the LNS accepts this
connection request.

3. The VPN user communicates with the company headquarters by using the tunnel between
the VPN user and LNS.
4. The VPN user accesses the network with the default domain (the domain name is "default")
and adopts the local authentication by default. The address is allocated from the address
pool. In this condition, you need to configured the address pool in the AAA view on the
LNS.
Data Preparation
l User name and password of the VPN
l IP address of the interface through which the LNS connects with the tunnel
l Number, IP address, and mask of the virtual-template interface, as well as L2TP group
number
Procedure
Step 1 Configure the devices on the VPN client side.
The L2TP client software must be configured on the host of the VPN client side and users can
connect to the Internet by dialing up. Then perform the following configurations. Note that the
setting process may vary with the client software.
# Set the VPN user name as "vpdnuser", and the password as "Hello".
# Set the IP address of LNS as the IP address of the interface on the router to access the Internet.
In this example, the IP address of the interface on the LNS connected with the tunnel is
202.38.160.2.
# Modify connection attributes, and adopt the L2TP protocol.
# If the hosts on the client side support IPSec, disable IPSec.
Step 2 Configure the LNS routers.
# Create and configure a virtual-template interface.
[RouterA-Virtual-Template1] ppp authentication-mode chap
[RouterA-Virtual-Template1] remote address pool 1
# Enable L2TP and set an L2TP group.

# Configure the names of the local end and the tunnel peer on the LNS.
[RouterA-l2tp1] tunnel name LNS
[RouterA-l2tp1] allow l2tp virtual-template 1 remote vpdnuser
# Disable the tunnel authentication.

[RouterA-l2tp1] undo tunnel authentication

# Define an address pool to assign addresses for dial-in users.

[RouterA] ip pool 1
[RouterA-ip-pool-1]network 192.168.0.0 mask 24
# Set the user name and password the same as the configurations on the VPN client side.
[RouterA] aaa
[RouterA-aaa] local-user vpdnuser password simple Hello
[RouterA-aaa] local-user vpdnuser service-type ppp
[RouterA-aaa] quit

After VPN users log in to the LAC or LNS devices, run the display l2tp tunnel command on
the LNS and you can find the tunnel is set up. For example:
[RouterA] display l2tp tunnel
Total tunnel = 1
1 1 192.168.0.2 2134 1 vpdnuser
Run the display l2tp session command. You can find that the session is set up. For example:
[RouterA] display l2tp session
Total session = 1
1576 1036 1
At the same time, VPN users can access the headquarters.
----End
Configuration Files
The configuration file of the LNS is as follows:
NOTE
Only the configuration files related to L2TP are listed.

#
sysname RouterA
#
l2tp enable
#
ip pool 1
network 192.168.0.0 mask 255.255.255.0
#
aaa
local-user vpdnuser password simple Hello
local-user vpdnuser service-type ppp
#
ppp authentication-mode chap
ip address 192.168.0.1 255.255.255.0
#
l2tp-group 1
undo tunnel authentication
allow l2tp virtual-template 1 remote vpdnuser
tunnel name LNS
#
return

2.7.4 Example for Configuring LAC-Auto-Initiated VPN

This example shows how to configure LAC-auto-initiated VPN.
Departments in the enterprise headquarters need to use independent network segments. Staff in
branches need to access the networks of their own departments. To meet these requirements, an
L2TP tunnel can be established between the branch routers and router in the headquarters. As
shown in Figure 2-5, a PC in the branch connects to the LAC (RouterA) through a LAN interface,
and RouterA connects to the LNS (RouterB) through the Internet. The tunnel between RouterA
and RouterB implements communication between the branch and headquarters.
NOTE
When the AR150/200 communicates with a non-Huawei device, configure the AR150/200 to invert clock
signals transmitted by a synchronous serial interface as required.
Figure 2-5 Networking diagram of the LAC-auto-initiated VPN

PC RouterA RouterB
Serial1/0/0 Serial1/0/0
LAN 12.1.1.2/24
Internet 12.1.1.1/24
192.168.1.0/24
LAC LNS Server

headquarters
Tunnel 192.168.0.2/24
1. Enable L2TP and create a virtual PPP user on the LAC. The virtual PPP user sends a
connection request to the server in the headquarters through the L2TP tunnel. After the
request is authenticated, the server assigns a private IP address to the virtual PPP user.
2. Configure a route with the destination segment of headquarters, and outbound interface of
the virtual PPP user interface. Enable the auto-dial function on the LAC.
3. Configure an IP address pool in the domain on the LNS.
Data Preparation
l Number, IP address, and mask of the LAC virtual template interface

l L2TP group number
l Protocol used on the LNS, authentication mode (CHAP is used in this example), tunnel
password, local and remote device names of the LNS.
l Number, range, and mask of the remote address pool.

Procedure
Step 1 Configure RouterA (the LAC side).
In this example, the IP address of Serial1/0/0 on RouterA is 12.1.1.2, and the IP address of
Serial1/0/0 on RouterB is 12.1.1.1.
# Assign an IP address to Serial1/0/0 on RouterA.
# Set the user name and password, which must be the same as those on the user side.
[RouterA] aaa
[RouterA-aaa] local-user huawei password simple 123
[RouterA-aaa] local-user huawei service-type ppp
[RouterA-aaa] quit
# Configure an L2TP group and its attributes.

[RouterA-l2tp1] tunnel name LAC
[RouterA-l2tp1] start l2tp ip 12.1.1.1 fullusername huawei
# Enable tunnel authentication and set the tunnel authentication password.

[RouterA-l2tp1] tunnel password simple 123
# Configure the user name and password, authentication mode, and IP address for the virtual
PPP user.
[RouterA-Virtual-Template1] ppp pap local-user huawei password simple 123
# Configure a private route so that the packets sent to the headquarters are forwarded through
L2TP tunnels.
[RouterA] ip route-static 192.168.0.0 255.255.255.0 Virtual-Template1
# Enable RouterA to establish an L2TP tunnel.

[RouterA-virtual-template1] l2tp-auto-client enable
Step 2 Configure RouterB (the LNS side)

# Assign an IP address to Serial1/0/0 on RouterB.
[Huawei] sysname RouterB
[RouterB] interface serial 1/0/0
[RouterB-Serial1/0/0] link-protocol ppp
[RouterB-Serial1/0/0] ip address 12.1.1.1 255.255.255.0
[RouterB-Serial1/0/0] quit
# Create and configure a virtual template.

[RouterB] interface virtual-template 1

[RouterB-Virtual-Template1] ppp authentication-mode pap

[RouterB-Virtual-Template1] remote address pool 1
[RouterB-Virtual-Template1] ip address 13.1.1.1 255.255.255.0
[RouterB-Virtual-Template1] quit
# Enable L2TP and configure an L2TP group.

[RouterB] l2tp enable
[RouterB]l2tp-group 1
# Set the local and remote device names for the LNS.
[RouterB-l2tp1] tunnel name LNS
[RouterB-l2tp1]allow l2tp virtual-template 1 remote LAC
# Enable tunnel authentication and set the tunnel password.

[RouterB-l2tp1] tunnel authentication
[RouterB-l2tp1] tunnel password simple 123
[RouterB-l2tp1] quit
# Set the user name and password, which must be the same as those on the LAC side.
[RouterB] aaa
[RouterB-aaa] local-user huawei password simple 123
[RouterB-aaa] quit
# Configure an IP address pool for assigning IP addresses to users.

[RouterB] ip pool 1
[RouterB-ip-pool-1] gateway-list 13.1.1.1
[RouterB-ip-pool-1] network 13.1.1.0 mask 255.255.255.0
[RouterB-ip-pool-1] quit

# Run the display l2tp tunnel command on the LAC and LNS to check the tunnel when a VPN
user gets online. The following shows the command output on the LNS:
[RouterB] display l2tp tunnel
Total tunnel = 1
1 1 12.1.1.1 1701 1 LNS
# Run the display l2tp session command to check the session status. The following shows the
command output on the LNS:
[RouterB] display l2tp session
Total session = 1
1 1 1
# The VPN user can access the resources in the enterprise headquarters.
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
l2tp enable
#
aaa

domain default
local-user huawei password simple 123
local-user huawei service-type ppp
#
ppp pap local-user huawei password simple 123
ip address 13.1.1.2 255.255.255.0
l2tp-auto-client enable
#
interface Serial1/0/0
link-protocol ppp
ip address 12.1.1.2 255.255.255.0
#
l2tp-group 1
tunnel password simple 123
tunnel name LAC
start l2tp ip 12.1.1.1 fullusername huawei
#
ip route-static 192.168.0.0 255.255.255.0 Virtual-Template1
#
return
l Configuration file of RouterB

#
sysname RouterB
#
l2tp enable
#
ip pool 1
gateway-list 13.1.1.1
network 13.1.1.0 mask 255.255.255.0
#
aaa
domain default
local-user huawei password simple 123
local-user huawei service-type ppp
#
ppp authentication-mode pap
ip address 13.1.1.1 255.255.255.0
#
interface Serial1/0/1
link-protocol ppp
ip address 12.1.1.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote LAC
tunnel password simple 123
tunnel name LNS
#
return

Configuration Guide - VPN 3 IPSec Configuration
3 IPSec Configuration
About This Chapter
IP Security (IPSec) uses data encryption and data source authentication at the IP layer to ensure
data confidentiality and integrity and prevent replay of data packets. Internet Key Exchange
(IKE) enables key negotiation and security associations (SAs) establishment to simplify use and
management of IPSec. This chapter describes how to configure IPSec and IKE.
3.1 IPSec Overview

The IP Security (IPSec) protocol family is a series of protocols defined by the Internet
Engineering Task Force (IETF). This protocol family provides high quality, interoperable, and
cryptology-based security for IP packets. Communicating parties encrypt data and authenticate
the data source at the IP layer to ensure data confidentiality and integrity and prevent replay of
data packets.
3.2 IPSec Features Supported by the AR150/200
The AR150/200 supports an IPSec tunnel established manually, or using IKE negotiation, IPSec
tunnel interface, or Efficient VPN policy.
3.3 Establishing an IPSec Tunnel Manually
You can establish IPSec tunnels manually when the network topology is simple.
3.4 Establishing an IPSec Tunnel Through IKE Negotiation
IKE provides an automatic protection mechanism to distribute keys, authenticate the identity,
and set up SAs on an insecure network.
3.5 Establishing an IPSec Tunnel Using an IPSec Tunnel Interface
This section describes how to create an IPSec tunnel interface and apply an IPSec profile to the
IPSec tunnel interface so that the IPSec profile configuration takes effect on the IPSec tunnel
interface.
3.6 Establishing an IPSec Tunnel Using the Efficient VPN Policy
Using an Efficient VPN policy to establish an IPSec tunnel simplifies the configuration and
reduces manual configuration workload.
3.7 Maintaining IPSec
This section describes how to display the IPSec configuration and clear the IPSec statistics.

This section provides several configuration examples of IPSec.

3.1 IPSec Overview

The IP Security (IPSec) protocol family is a series of protocols defined by the Internet
Engineering Task Force (IETF). This protocol family provides high quality, interoperable, and
cryptology-based security for IP packets. Communicating parties encrypt data and authenticate
the data source at the IP layer to ensure data confidentiality and integrity and prevent replay of
data packets.
IPSec uses two security protocols: Authentication Header (AH) protocol and Encapsulating
Security Payload (ESP). Key exchange and SA establishment in IPSec is implemented by the
Internet Key Exchange (IKE) protocol, which simplifies use and management of IPSec.
IPSec involves the following terms:
l Security association (SA)
An SA is a set of conventions adopted by the communicating parties. For example, it
determines the security protocol (AH, ESP, or both), encapsulation mode (transport
mode or tunnel mode), key algorithm (DES, 3DES, or AES), shared key to protect
certain flow, and the lifetime of the shared key.
An SA is unidirectional, at least two SAs are required to protect data flows in
bidirectional communication. If two peers need to communicate using both AH and
ESP, each peer needs to establish two SAs for the two protocols.
An SA is identified by three parameters: Security Parameter Index (SPI), destination IP
address, and security protocol ID (AH or ESP).
l Encapsulation mode
Transport mode: AH or ESP is inserted behind the IP header but before all transport-
layer protocols, as shown in Figure 3-1.
Tunnel mode: AH or ESP is inserted before the original IP header but behind a new IP
header, as shown in Figure 3-2.
Figure 3-1 Packet format in transport mode
Mode
transport
Protocol
AH IP Header AH TCP Header data
IP Header ESP TCP Header data ESP

ESP ESP Auth data
Tail
AH-ESP IP Header AH ESP TCP Header data ESP Tail ESP Auth data

Figure 3-2 Packet format in tunnel mode
Mode
tunnel
Protocol
AH new IP Header AH raw IP Header TCP Header data
ESP new IP raw IP

ESP TCP Header dataESP Tail ESP Auth data
Header Header
AH-ESP new IP Header AH ESPraw IP Header TCP Header data ESP TailESP Auth data
l Authentication algorithm and encryption algorithm

IPSec uses the Message Digest 5 (MD5) algorithm, Secure Hash Algorithm (SHA-1)
or Secure Hash Algorithm (SHA-2) for authentication. The MD5 algorithm computes
faster than the SHA-1 algorithm, but the SHA-1 algorithm is more secure than the MD5
algorithm. SHA-2 increases the number of encrypted data bits and is more secure than
SHA-1.
IPSec uses the DES, Triple Data Encryption Standard (3DES), or Advanced Encryption
Standard (AES) algorithm for encryption. The ASE algorithm encrypts plain text by
using a key of 128 bits, 192 bits, or 256 bits.
l Negotiation mode
IPSec uses two negotiation modes to establish SAs: manual mode (manual) and IKE
negotiation mode (isakmp).
3.2 IPSec Features Supported by the AR150/200

The AR150/200 supports an IPSec tunnel established manually, or using IKE negotiation, IPSec
tunnel interface, or Efficient VPN policy.
The AR150/200 implements IPSec tunnel setup as follows:
l In manual mode or IKE negotiation mode, an IPSec tunnel is established based on ACLs.
IPSec peers can use various security protection measures (authentication, encryption, or
both) on different data flows.
The general process of establishing an IPSec tunnel in manual mode or IKE negotiation
mode is as follows:
1. Define an ACL to specify the data flows to be protected.
2. Configure an IPSec proposal to specify the security protocol, authentication algorithm,
encryption algorithm, and encapsulation mode.
3. Configure an IPSec policy or an IPSec policy group to specify the association between
data flows and the IPSec proposal (protection measures for the data flows), SA
negotiation mode, peer IP address (start and end points of the protection path), required
key, and SA lifetime.
l An IPSec tunnel established using an IPSec tunnel interface is based on routes. If the
outbound interface in a route is the IPSec tunnel interface, IPSec protects the data flows
forwarded along the route. The IPSec configuration takes effect after the configured IPSec
profile is applied to the IPSec tunnel interface.

The general process of establishing an IPSec tunnel using tunnel interfaces is as follows:
1. Configure an IPSec proposal to specify the security protocol, authentication algorithm,
encryption algorithm, and encapsulation mode.
2. Configure an IKE Peer.
3. Configure an IPSec profile and bind it to an IPSec profile to protect data flows, IKE
peer parameters, and SA lifetime.
4. Apply the IPSec profile to the IPSec tunnel interface.
l When an IPSec tunnel is established using the Efficient VPN policy, only mandatory
parameters, such as the IP address and pre-shared key, need to be configured on the remote
device. Other parameters, such as authentication and encryption algorithms used in IKE
negotiation, and the IPSec proposal, are preconfigured on the server. When the remote
device initiates IPSec tunnel negotiation, it sends its IKE capabilities including
authentication algorithm and encryption algorithm, and IPSec proposal it supports to the
server. The server establishes an IPSec tunnel with the remote device according to the
preconfigured IPSec tunnel parameters and those sent from the remote device.
NOTE
The Efficient VPN function is used with a license. To use the Efficient VPN function, apply for and purchase
the following license from the Huawei local office:
l AR150&200 Value-Added Security Package
3.3 Establishing an IPSec Tunnel Manually

You can establish IPSec tunnels manually when the network topology is simple.

Before manually establishing an IPSec tunnel, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the required data.
Data flows must be authenticated to ensure data transmission security. In a high security scenario,
data flows must be authenticated and encrypted. In such a scenario, configure IPSec on the device
that initiates the IPSec service and the device that terminates the IPSec service.
Before establishing an IPSec tunnel manually, complete the following tasks:
l Setting parameters of the link-layer protocol for the interfaces to ensure that the link-layer
protocol on the interfaces is Up
l Configuring routes between the source and the destination
Data Preparation
To establish an IPSec tunnel manually, you need the following data.

No. Data
1 Parameters of an advanced ACL
2 IPSec proposal name, security protocol, authentication algorithm of AH,

authentication algorithm and encryption algorithm of ESP, and packet
encapsulation mode
3 IPSec policy settings, including:

l Name and sequence number of the IPSec policy
l Local and peer IP addresses of the tunnel
l Inbound and outbound SPIs for AH or ESP
l Inbound and outbound authentication keys (character string or hexadecimal
number) for AH or ESP
l (optional) VPN instance name
4 Type and number of the interface to which the IPSec policy is applied
NOTE
Use the AH or ESP protocol based on requirements on your network.
3.3.2 Defining Protected Data Flows

IPSec can protect different data flows. In real-world applications, configure an ACL to define
the protected data flows and apply the ACL to a security policy.
Procedure
Step 1 Run:
system-view
Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto } ]
An advanced ACL is created and the ACL view is displayed.
Step 3 Run:
rule
An ACL rule is configured.
NOTE
l The ACL must be configured to match the data flows accurately. It is recommended that you set the
action of the ACL rule to permit for the data flows that need to be protected.
l Create different ACLs and IPSec policies for the data flows with different security requirements.
----End

3.3.3 Configuring an IPSec Proposal

An IPSec proposal defines the security protocol, authentication algorithm, encryption algorithm,
and packet encapsulation mode. Both ends of a tunnel must use the same IPSec proposal
configuration.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.

transform { ah | esp | ah-esp }
The security protocol is specified.

By default, the ESP protocol defined in RFC 2406 is used.
ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
The authentication algorithm used by AH is specified.

By default, AH uses the MD5 authentication algorithm.
esp authentication-algorithm [ md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ]
The authentication algorithm used by ESP is specified.

By default, both ESP and AH use the MD5 authentication algorithm.
You can configure the authentication and encryption algorithms only after selecting a security
protocol using the transform command.
esp encryption-algorithm [ 3des | des | aes-128 | aes-192 | aes-256 ]
The encryption algorithm used by ESP is specified.

By default, ESP uses the DES encryption algorithm.
encapsulation-mode { transport | tunnel }
The packet encapsulation mode is configured.

By default, the tunnel mode is used.
----End
3.3.4 Configuring an IPSec Policy

After establishing an IPSec tunnel manually, configure an IPSec policy for the tunnel.

Context
CAUTION
When configuring SPI, string authentication key (string-key), hexadecimal authentication key
(authentication-hex), and hexadecimal encryption key (encryption-hex) on two ends of an
IPSec tunnel, ensure that the inbound parameters on the local end are the same as the outbound
parameters on the remote end, and the outbound parameters on the local end are the same as the
inbound parameters on the remote end.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy policy-name seq-number manual
An IPSec policy is created.

An IPSec policy group can contain up to 10000 IPSec policies. By default, no IPSec policy
exists.
Step 3 Run:
security acl acl-number
An ACL is applied to the IPSec policy.

An IPSec policy can use only one ACL. If more than one ACL is applied to the IPSec policy,
the last configured ACL takes effect.
Step 4 Run:
proposal proposal-name
An IPSec proposal is applied to the IPSec policy.

If the manual mode is used, an IPSec policy can use only one proposal. If an IPSec proposal has
been applied to the IPSec policy, cancel the existing proposal before applying a new one to the
IPSec policy. In addition, the IPSec proposals applied on the two ends of a tunnel must have the
same security protocol, algorithm, and packet encapsulation mode.
Step 5 Run:
tunnel local ip-address
The IP address of the local end is configured.

Step 6 Run:
tunnel remote ip-address
The IP address of the remote end is configured.

Step 7 Run:
sa spi inbound { ah | esp } spi-number
The SPI of the inbound SA is configured.

NOTE
The security protocol must be the same as the security protocol specified in the transform command in
3.3.3 Configuring an IPSec Proposal. If the security protocol specified in transform is ah-esp, both the
ah and esp protocols must be configured in the sa spi command.
Step 8 Run:
sa spi outbound { ah | esp } spi-number
The SPI of the outbound SA is configured.
NOTE
l When configuring an SA, set both inbound and outbound parameters.

l The SA parameters on two ends of a tunnel must match each other. The inbound SPI of the local end must
be the same as the outbound SPI of the remote end, and the outbound SPI of the local end must be the same
as the inbound SPI of the remote end.
Step 9 Run:
sa authentication-hex { inbound | outbound } { ah | esp } hex-key
The authentication key (a hexadecimal number) of the security protocol is configured.

Step 10 Run:
sa string-key { inbound | outbound } { ah | esp } string-key
The authentication key (a character string) of the security protocol is configured.
CAUTION
Use the same key format on the two ends. For example, if the key on one end is a character string
but the key on the other end is a hexadecimal number, the IPSec tunnel cannot be established.
If you configure the keys in different formats, the last configured key takes effect.
Step 11 Run:
sa encryption-hex { inbound | outbound } esp hex-key
The encryption key (a hexadecimal number) is configured for ESP.
NOTE
l If the AH protocol is specified, run either the sa authentication-hex or sa string-key command.

l If the ESP protocol is specified, run one of the sa authentication-hex, sa string-key, and sa
encryption-hex commands.
l To manually create an IPSec tunnel, use the sa spi command together with the sa authentication-
hex, sa string-key, or sa encryption-hex command.

sa binding vpn-instance vpn-instance-name
A VPN instance is associated with the SA.
----End
3.3.5 Applying an IPSec Policy to an Interface

A manually configured IPSec policy can be applied to only one interface.

Context
An interface can use only one IPSec policy. An IPSec policy group that establishes an SA through
IKE negotiation can be applied to multiple interfaces, whereas an IPSec policy group that is used
to establish an SA manually can be applied only to one interface. If the applied IPSec policy
establishes an SA in manual mode, the SA is generated immediately.
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface interface-type interface-number
The interface view is displayed.

Step 3 Run:
ipsec policy policy-name
An IPSec policy is applied to the interface.
----End

After an IPSec tunnel is manually established, you can check information about the SA, IPSec
proposal, and IPSec policy.
Prerequisites
The configurations required for establishing an IPSec tunnel manually are complete.
Procedure
l Run the display ipsec sa command to view information about the SA.
l Run the display ipsec proposal [ name proposal-name ] command to view information
about the IPSec proposal.
l Run the display ipsec policy [ brief | name policy-name [ seq-number ] ] command to view
information about the IPSec policy.
----End
3.4 Establishing an IPSec Tunnel Through IKE Negotiation

IKE provides an automatic protection mechanism to distribute keys, authenticate the identity,
and set up SAs on an insecure network.

Before establishing an IPSec tunnel through IKE negotiation, familiarize yourself with the
applicable environment, complete the pre-configuration tasks, and obtain the required data.

Application Environment
Data flows must be authenticated to ensure data transmission security. In a high security scenario,
data flows must be authenticated and encrypted. In such a scenario, configure IPSec on the device
that initiates the IPSec service and the device that terminates the IPSec service.
When the network topology is complex, you can establish IPSec tunnels through IKE
negotiation.
Before establishing an IPSec tunnel through IKE negotiation, complete the following tasks:
l Setting parameters of the link-layer protocol and IP addresses for the interfaces to ensure
that the link-layer protocol on the interfaces is Up
Data Preparation
To establish an IPSec tunnel through IKE negotiation, you need to the following data.
No. Data
2 Priority of the IKE proposal, encryption algorithm, authentication algorithm, and

authentication method used in IKE negotiation, identifier of the Diffie-Hellman
group, and SA lifetime
3 IKE peer name, negotiation mode, IKE proposal name, IKE peer ID type, pre-
shared key, remote address, and remote host name

authentication algorithm and encryption algorithm of ESP, and packet
encapsulation mode
5 Name and sequence number of the IPSec policy, (optional) Perfect Forward
Secrecy (PFS) feature used in IKE negotiation
6 (Optional) Name of the IPSec policy template
7 (Optional) Local address of the IPSec policy group, time-based global SA

lifetime, traffic-based global SA lifetime, interval for sending keepalive packets,
timeout inertial of keepalive packets, and interval for sending NAT update packets
8 Type and number of the interface to which the IPSec policy is applied
NOTE
Use the AH or ESP protocol based on requirements on your network.
3.4.2 Defining Protected Data Flows

IPSec can protect different data flows. In real-world applications, configure an ACL to define
the protected data flows and apply the ACL to a security policy.

Procedure
Step 1 Run:
system-view
Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto }]
Step 3 Run:
rule
An ACL rule is configured.
NOTE
l The ACL must be configured to match the data flows accurately. It is recommended that you set the
action of the ACL rule to permit for the data flows that need to be protected.
l Create different ACLs and IPSec policies for the data flows with different security requirements.
----End
3.4.3 (Optional) Configuring an IKE Proposal

You can create multiple IKE proposals with different priority levels. The two ends must have
at least one matching IKE proposal for IKE negotiation.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ike proposal proposal-number
An IKE proposal is created and the IKE proposal view is displayed.
The IKE negotiation succeeds only when the two ends use the IKE proposals with the same
settings.

encryption-algorithm { des-cbc |3des-cbc | aes-cbc-128 | aes-cbc-192 | aes-
cbc-256 }
The encryption algorithm is configured.
By default, an IKE proposal uses the DES-CBC encryption algorithm.

authentication-method { pre-share | rsa-signature }
The authentication method used by an IKE proposal is configured.
By default, an IKE proposal uses pre-shared key authentication.


authentication-algorithm { md5 | sha1 | aes_xcbc_mac_96 }
The authentication algorithm is configured.

By default, an IKE proposal uses the SHA-1 algorithm.
dh { group1 | group2 | group5 | group14 }
The Diffie-Hellman group is specified.

prf { hmac-md5 | hmac-sha1 | aes_xcbc_128 }
The algorithm used to generate the pseudo random number is specified.

sa duration interval
The SA lifetime is set.

If the lifetime expires, the IKE SA is automatically updated.
You can set the lifetime only for the SAs established through IKE negotiation. The lifetime of
manually created SAs is not limited. That is, the manually created SAs are always effective.
----End
3.4.4 Configuring an IKE Peer
Procedure
Step 1 Run:
system-view

Step 2 Run:
ike peer peer-name [ v1 | v2 ]
An IKE peer is created and the IKE peer view is displayed.

exchange-mode { main | aggressive }
The IKE negotiation mode is configured.

In aggressive mode, the local ID type must be set to ip or name in step 5. In main mode, the
local ID type must be set to ip.
If the IKE peer uses IKEv2, skip this step.
ike-proposal proposal-number
An IKE proposal is configured.

local-id-type { ip | name }

The local ID type is configured.
By default, the IP address of the local end is used as the local ID.

local-address address
By default, the local end address is the IP address of the interface bound to the IPSec policy.

peer-id-type { ip | name }
The peer ID type is configured.
By default, the IP address of the local end is used as the local ID.
The peer-id-type command is valid only when IKEv2 is used.

nat traversal
NAT traversal is enabled.
When NAT traversal is enabled, local-id-type must be set to name.

pre-shared-key key-string
The pre-shared key used by the local end and remote peer is configured.
If pre-shared key authentication is configured, configure a pre-shared key for each remote peer.
The two ends of an IPSec tunnel must use the same pre-shared key.
When pre-shared key authentication is configured, an authenticator must be configured.
Step 10 Run:
remote-address { ip-address | host-name }
The IP address or the domain name of the remote peer is configured.
NOTE
In the IPSec policy template mode, you do not need to run the remote-address command.

A VPN instance is associated with the SA.
By specifying the VPN instance that the remote end of the IPSec tunnel belongs to, you can
implement multi-instance IPSec connections. The configuration takes effect only on the initiator
of the IPSec tunnel. The initiator needs to obtain the outbound interface when sending packets.
This command specifies the VPN that the remote end belongs to. According to the VPN, the
tunnel initiator can obtain the outbound interface and send packets through the outbound
interface. The packets received by the remote peer contain the VPN attribute, so you do not need
to specify the VPN on the remote peer.

remote-name name

The remote host name is configured. Perform this step only when name authentication is used
in aggressive mode.
If IKEv2 is used, set local-id-type to ip and peer-id-type to name, and configure remote-
name.
inband ocsp
The Online Certificate Status Protocol (OCSP) is enabled for the IKE peer.
pki realm realm-name
A public key infrastructure (PKI) domain is bound to the IKE peer.

After a PKI domain is bound to an IKE peer, the IKE peer can obtain the CA certificate and
local certificate based on the PKI domain configuration.
Step 15 Run:
quit

ike local-name local-name
The local host name used in the IKE negotiation is configured.

Perform this step when the local-id-type is set to name.
----End
3.4.5 Configuring an IPSec Proposal

Both ends of the tunnel must be configured with the same security protocol, authentication
algorithm, encryption algorithm, and packet encapsulation mode.
Procedure
Step 1 Run:
system-view

Step 2 Run:
An IPSec proposal is created and the IPSec proposal view is displayed.

transform { ah | esp | ah-esp }
The security protocol is configured.

By default, the ESP protocol defined in RFC 2406 is used.
ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
The authentication algorithm used by AH is configured.

By default, AH uses the MD5 authentication algorithm.

esp authentication-algorithm [ md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ]
The authentication algorithm used by ESP is configured.

By default, ESP uses the MD5 authentication algorithm.
esp encryption-algorithm { 3des | des | aes-128 | aes-192 | aes-256 }
The encryption algorithm used by ESP is configured.

By default, ESP uses the DES encryption algorithm.
encapsulation-mode { transport | tunnel }
The packet encapsulation mode is configured.

By default, the security protocol uses the tunnel mode to encapsulate IP packets.
----End
3.4.6 Configuring an IPSec Policy

After configuring an IKE peer, apply it to an IPSec policy. Then the two ends can start IKE
negotiation.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy policy-name seq-number isakmp [ template template-name ]
An IPSec policy is created.

Step 3 Run:
An IPSec proposal is applied to the IPSec policy.

An IPSec policy that uses IKE negotiation can reference a maximum of six IPSec proposals.
During IKE negotiation, the two ends of the IPSec tunnel use the IPSec proposals with the same
parameter settings first.
Step 4 Run:
An ACL is applied to the IPSec policy.

sa trigger-mode { auto | traffic-based }
The SA triggering mode is configured.

After IKE negotiation phase 1 succeeds, the IPSec SA is established in the specified triggering
mode. In automatic triggering mode, the IPSec SA is established immediately after IKE
negotiation phase 1 succeeds. In traffic-based triggering mode, the IPSec SA is established only
after packets are received.
By default, the automatic triggering mode is used.
sa duration { traffic-based kilobytes | time-based interval }

l In IKEv1, the IKE peers compare the lifetime set in their IPSec proposals and use the smaller
value as the IPSec SA lifetime.
l In IKEv2, the IKE peers do not negotiate the SA lifetime. Instead, they use the locally set
SA lifetime.
l The default IPSec SA lifetime is 3600 seconds, and the default traffic volume is 1843200
kilobytes.
Step 7 Run:
ike-peer peer-name
An IKE peer is applied to the IPSec policy.
NOTE
For details on how to configure an IKE peer, see 3.4.4 Configuring an IKE Peer.

pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 }
The Perfect Forward Secrecy (PFS) feature used in the negotiation is configured.
If PFS is specified on the local end, you also need to specify PFS on the remote peer. The Diffie-
Hellman group specified on the two ends must be the same; otherwise, the negotiation fails. If
the remote end uses the template mode, the Diffie-Hellman groups can be different.
----End
3.4.7 Configuring an IPSec Policy Template

An IPSec policy template can be used to configure multiple IPSec policies, reducing the
workload of establishing multiple IPSec tunnels.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy-template policy-template-name seq-number
An IPSec policy template is created.


An ACL is applied to the IPSec policy template.
Step 4 Run:
An IPSec proposal is applied to the IPSec policy template.
An IPSec policy that uses IKE negotiation can reference a maximum of six IPSec proposals.
During IKE negotiation, the two ends of the IPSec tunnel use the IPSec proposals with the same
parameter settings first.

sa duration { traffic-based kilobytes | time-based interval }
The IPSec SA lifetime is set.
Step 6 Run:
ike-peer peer-name
An IKE peer is applied to the IPSec policy template.

The Perfect Forward Secrecy (PFS) feature used in the negotiation is configured.
By default, the PFS feature is not used in IKE negotiation.
----End
3.4.8 (Optional) Setting Optional Parameters

This section describes how to set optional parameters for IKE negotiation.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipsec sa global-duration { time-based interval | traffic-based kilobytes }
The global SA lifetime is set.
You can set the lifetime only for the SAs established through IKE negotiation. The lifetime of
manually created SAs is not limited. That is, the manually created SAs are always effective.
If the SA lifetime is not set in an IPSec policy, the global lifetime is used.
The new global lifetime does not affect the IPSec policies that have their own lifetime or the
SAs that have been established. The new global lifetime will be used to establish new SAs during
IKE negotiation.
Step 3 Run:
ike heartbeat-timer interval interval
The interval for sending heartbeat packets is set.

Step 4 Run:
ike heartbeat-timer timeout interval
The timeout interval of heartbeat packets is set.
If the interval for sending heartbeat packets is set on one end, the timeout interval of heartbeat
packets must be set on the other end.
On a network, packet loss rarely occurs consecutively more than three times. Therefore, the
timeout interval of heartbeat packets on one end can be set to three times the interval for sending
heartbeat packets on the other end.
Step 5 Run:
ike nat-keepalive-timer interval interval
The interval for sending NAT keepalive packets is set.
Step 6 Run:
ipsec anti-replay { enable | disable }
The anti-replay function is set.
Step 7 Run:
ipsec df-bit { clear | set | copy }
The DF flag bit is set on the IPSec tunnel.
Step 8 Run:
ipsec fragmentation before-encryption
The fragmentation mode of IPSec packets is set.
Step 9 Run:
ike peer
The IKE peer view is displayed.
Step 10 Run:
Step 11 Run following commands to configure the dead peer detection (DPD) function.
l Run:
dpd { idle-time seconds | retransmit-interval seconds | retry-limit times }
The idle time for DPD, retransmission interval of DPD packets, and maximum number of
retransmissions are set.
l Run:
dpd msg { seq-hash-notify | seq-notify-hash }
The sequence of payload in DPD packets is configured.

l Run:
dpd type { on-demand | periodic }
The DPD mode is configured.
----End

3.4.9 (Optional) Configuring Route Injection

Route injection associates route selection with the IPSec tunnel status. If the IPSec tunnel is Up,
the route of the IPSec peer can be added and advertised. If the IPSec tunnel is Down, the route
of the IPSec peer can be deleted and withdrawn.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy policy-name seq-number isakmp
The IPSec policy view is displayed.

The IPSec policy must be configured using IKE negotiation or an IPSec tunnel interface.
Step 3 Run:
route inject { static | dynamic } [ preference preference ]
Route injection is enabled.

By default, route injection is disabled.
----End
3.4.10 Applying an IPSec policy to an interface

An interface can use only one IPSec policy. An IPSec policy for IKE negotiation can be applied
to multiple interfaces.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

Only one IPSec policy can be applied to an interface. An IPSec policy can be applied to multiple
interfaces.
After the configuration is complete, the packets transmitted between two ends of the IPSec tunnel
trigger SA establishment through IKE negotiation. In automatic triggering mode, the SA is
established immediately after the IKE negotiation succeeds. In traffic-based triggering mode,
the SA is established only after data flows matching the IPSec policy are sent from the interface.

After IKE negotiation succeeds and the SA is established, the data flows are encrypted and then
transmitted between two ends.
----End

After an IPSec tunnel is established through IKE negotiation, you can view information about
the SA, configuration of the IKE peer, and configuration of the IKE proposal.
Prerequisites
The configurations required to establish an IPSec tunnel through IKE negotiation are complete.
Procedure
l Run the display ike sa [ v2 ] [ conn-id connid | peer-name peername | phase phase-
number | verbose ] command to view information about the SAs established through IKE
negotiation.
l Run the display ike peer [ name peer-name ] [ verbose ] command to view the
configuration of a specified IKE peer or all IKE peers.
l Run the display ike proposal command to view the configuration of a specified IKE
proposal or all IKE proposals.
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | peerip
peer-ip-address ] command to view the configuration of a specified SA or all SAs.
l Run the display ipsec policy [ brief | name policy-name [ seq-number ] ] command to view
information about a specified IPSec policy or all IPSec policies.
l Run the display ipsec proposal [ name proposal-name ] command to view information
about a specified IPSec proposal or all IPSec proposals.
----End
3.5 Establishing an IPSec Tunnel Using an IPSec Tunnel

Interface
This section describes how to create an IPSec tunnel interface and apply an IPSec profile to the
IPSec tunnel interface so that the IPSec profile configuration takes effect on the IPSec tunnel
interface.

Before establishing an IPSec tunnel using an IPSec tunnel interface, familiarize yourself with
the applicable environment, complete the pre-configuration tasks, and obtain the data required
for configuration. This will help you complete the configuration task quickly and accurately.
An IPSec profile simplifies IPSec policy management. After an IPSec profile is applied to an
IPSec tunnel interface, only one IPSec tunnel is generated and this tunnel protects all the data
flows passing through the IPSec tunnel interface.

Before establishing an IPSec tunnel using an IPSec tunnel interface, complete the following
tasks:
l Setting link layer protocol parameters and IP addresses for interfaces to ensure that the link
layer protocol on the interfaces is Up
Data Preparation
To establish an IPSec tunnel using an IPSec tunnel interface, you need the following data.
No. Data

authentication algorithm and encryption algorithm of ESP, packet encapsulation
mode, and PFS feature
2 IKE peer name, negotiation mode, IKE proposal name, IKE peer ID type, pre-
shared key
3 SA lifetime and global SA lifetime
4 Number, IP address, and source and destination IP addresses of the IPSec tunnel
interface
5 Number of the IPSec tunnel interface to which an IPSec profile is applied
3.5.2 Configuring an IPSec Profile

An IPSec profile simplifies IPSec policy management.
Context
An IPSec profile defines the IKE peer, IPSec proposal, SA lifetime, and Perfect Forward Secrecy
(PFS). To ensure successful IKE negotiation, parameters in the IPSec profile on the local end
and remote end must match.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec profile profile-name
An IPSec profile is created and the IPSec profile view is displayed.

IPSec profiles can only be applied to IPSec tunnel interfaces.
Step 3 Run:

An IPSec proposal referenced by an IPSec profile is configured.
An IPSec profile can reference a maximum of 12 IPSec proposals. By default, an IPSec profile
does not reference any IPSec proposals.
NOTE
For details on how to configure an IKE proposal, see 3.4.5 Configuring an IPSec Proposal.
Step 4 Run:
ike-peer peer-name
An IKE peer referenced by an IPSec profile is configured.
By default, an IPSec profile does not reference any IKE peers.
NOTE
For details on how to configure an IKE peer, see 3.4.4 Configuring an IKE Peer.

The Diffie-Hellman group referenced by an IPSec profile during negotiation is configured.
By default, an IPSec profile does not reference any Diffie-Hellman group during negotiation.

sa duration { traffic-based kilobytes | time-based seconds }
Step 7 Run:
quit

ipsec sa global-duration { time-based seconds | traffic-based kilobytes }
The global SA lifetime is set.
By default, the global SA lifetime represented by time is 3600 seconds; the global SA lifetime
represented by traffic volume is 1843200 kilobytes.
----End
3.5.3 Configuring an IPSec Tunnel Interface

This section describes how to apply an IPSec profile to an IPSec tunnel interface.
Context
An IPSec tunnel interface encapsulates the IPSec header into packets. To make a configured
IPSec profile take effect, configure an IPSec tunnel interface and apply the IPSec profile to the
IPSec tunnel interface.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ip address
An IPv4 address is configured for the tunnel interface.
Step 4 Run:
tunnel-protocol { gre [ p2mp ] | ipsec | ipv4-ipv6 | none }
The encapsulation mode is set for the tunnel interface.
NOTE
A tunnel interface can be bound to an IPSec profile only when the encapsulation mode of the tunnel interface
is set to IPSec, GRE, or Multipoint GRE (MGRE).
Step 5 Run:
The source address is configured for the tunnel interface.
NOTE
It is recommended that you specify the interface type and number for source. If you specify an IP address
that is dynamically assigned to an interface, the IPSec configuration may fail to be restored because of
invalid source address.

destination dest-ip-address
The destination address is configured for the tunnel interface.
If the encapsulation mode of a tunnel interface is set to IPSec, you only need to configure the
destination address for one IKE peer. If the encapsulation mode of a tunnel interface is set to
GRE, you need to configure destination addresses for both IKE peers.
Step 7 Run:
An IPSec profile is applied to the tunnel interface.
By default, no IPSec profile is applied to an interface.
----End

After an IPSec tunnel is established using an IPSec tunnel interface, you can view the
configuration of the IPSec profile, IPSec proposal, SA, and IPSec tunnel interface.

Prerequisites
All the configurations of the IPSec tunnel established using an IPSec tunnel interface are
complete.
Procedure
l Run the display ipsec profile [ brief | name profile-name ] command to check the IPSec
profile information.
l Run the display ipsec proposal [ name proposal-name ] command to check the IPSec
proposal information.
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | profile
profile-name | peerip peer-ip-address ] command to check the SA information.
l Run the display this command in the interface view to check the configuration of the tunnel
interface.
----End
3.6 Establishing an IPSec Tunnel Using the Efficient VPN

Policy
Using an Efficient VPN policy to establish an IPSec tunnel simplifies the configuration and
reduces manual configuration workload.

Before configuring the Efficient VPN policy, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the data required for
configuration. This will help you complete the configuration task quickly and accurately.
You must perform a great number of IPSec configurations on two peers to establish an IPSec
tunnel between the peers. The configurations include the authentication and encryption
algorithms used in IKE negotiation, Diffie-Hellman key agreement protocol, and IPSec proposal.
If the network has hundreds of sites, the IPSec configurations on remote devices are complicated.
Huawei provides the Efficient VPN solution, which allows remote branches to easily connect
to the enterprise headquarters and releases enterprise administrators from complex manual
configurations.
Preconfiguration Tasks
Before configuring the Efficient VPN policy, complete the following tasks:
l Configuring link layer protocol parameters for interfaces to ensure that the link layer
protocol status on the interfaces is Up
Data Preparation
To configure the Efficient VPN policy, you need the following data.

No. Data
2 Name and priority of the IKE proposal, encryption algorithm, authentication

algorithm, and authentication method used in IKE negotiation, identifier of the
Diffie-Hellman group, SA lifetime, and IPSec proposal name
3 Name and sequence number of an IPSec policy, and name and sequence number
of an IPSec policy template
4 DNS server address, WINS server address, and allocable network segment
address in the global address pool
5 IKE local address, IKE peer address, and peer name
3.6.2 Configuring Client Mode

The client mode of the Efficient VPN policy protects data flows whose addresses are NAT
translated.
Context
Only mandatory parameters, such as the IP address and pre-shared key, need to be configured
on a remote device. Other parameters, such as authentication and encryption algorithms used in
IKE negotiation, and the IPSec proposal, are preconfigured on the server.
Procedure
Step 1 Perform the following steps on the remote router:
1. Run:
system-view

2. Run:
ipsec efficient-vpn efficient-vpn-name mode client
An IPSec Efficient VPN policy in client mode is created and the Efficient VPN policy view
is displayed.
3. Run:
remote-address { ip-address | host-name } { v1 | v2 }
An IP address or domain name is configured for the remote IKE peer.

4. (Optional) Run:
remote-name name
A name is specified for the remote IKE peer.

5. (Optional) Run:
An authentication method is specified for the IKE proposal.

6. (Optional) Run:
pre-shared-key key
An authenticator is configured for pre-shared key authentication.

7. Run:
quit

8. Run:

9. Run:
ipsec efficient-vpn(interface view) efficient-vpn-name
The Efficient VPN policy is applied to the interface.

Step 2 Perform the following steps on the server router:
1. Run:
system-view

2. Run:
ip pool ip-pool-name
A global address pool is created.

3. Run:
network ip-address [ mask { mask | mask-length } ]
An allocable network segment address is specified for the global address pool.
4. Run:
quit

5. Run:
aaa

6. Run:
service-scheme service-scheme-name
A service scheme is created and the service scheme view is displayed.

7. (Optional) Run:
dns ip-address
The IP address of the primary DNS server is specified.

8. (Optional) Run:
dns ip-address secondary
The IP address of the secondary DNS server is specified.

9. Run:
ip-pool pool-name [ move-to new-position ]
The location of the IP address pool is specified in the AAA service scheme.

10. (Optional) Run:

wins ip-address
The IP address of the primary WINS server is specified.

11. (Optional) Run:
wins ip-address secondary
The IP address of the secondary WINS server is specified.

12. Run:
quit

13. Run:
quit

14. Run:
ike-proposal proposal-number
An IKE proposal is configured.

For details, see 3.4.3 (Optional) Configuring an IKE Proposal.
NOTE
The DH group used in IKE negotiation must be set to dh group2 for an efficient-vpn policy.
15. Run:
quit

16. Run:
ike peer peer-name { v1 | v2 }
An IKE peer is configured.

For details, see 3.4.4 Configuring an IKE Peer.
NOTE
l When the IKE v1 version is used, the aggressive mode must be enabled using exchange-mode.
l Run the service-scheme command to bind the IKE peer to the AAA service scheme.
17. Run:
quit

18. Run:
An IPSec proposal is configured.

For details, see 3.4.5 Configuring an IPSec Proposal.
NOTE
l encapsulation-mode must be set to tunnel to establish an IPSec tunnel using the Efficient VPN policy.
l The Efficient VPN policy supports only Encapsulating Security Payload (ESP).
19. Run:

quit

20. Run:
ipsec policy-template template-name seq-number
An IPSec policy template is created.

For details, see 3.4.7 Configuring an IPSec Policy Template.
21. Run:
quit

22. Run:
ipsec policy policy-name seq-number isakmp template template-name
An SA is created using the configured IPSec policy template.

For details, see 3.4.6 Configuring an IPSec Policy.
23. Run:
quit

24. Run:

25. Run:
----End
3.6.3 Configuring Network Mode

The network mode of the Efficient VPN policy protects data flows that match ACLs.
Context
Perform the following steps on the routers on the remote device and server:
Procedure
Step 1 Run:
system-view

Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto } ]

Step 3 Run:
rule

The ACL rule is configured in the ACL view.
NOTE
Afer the ACL is applied, the ACL rules can match only IP packets.
Step 4 Run:
quit
Step 5 Run:
ipsec efficient-vpn efficient-vpn-name mode network
An IPSec Efficient VPN policy in network mode is created and the Efficient VPN view is
displayed.
Step 6 Run:
An ACL rule is used.
Step 7 Run:
remote-address { ip-address | host-name } { v1 | v2 }
An IP address or domain name is configured for the remote IKE peer.

remote-name name
The name of the remote IKE peer is specified.

An authentication method is specified for the IKE proposal.
By default, an IKE proposal uses pre-shared key authentication.

pre-shared-key key
The key is specified for pre-shared key authentication.
By default, no key is specified for pre-shared key authentication.

The perfect forward secrecy (PFS) features is used in IKE negotiation.

pki realm realm-name
A PKI domain is specified.

A VPN instance is specified to bind the IPSec tunnel.

NOTE
Before executing this command, configure the VPN instance.

local-id-type { ip | name }
The type of IKE ID is set.

By default, the IKE ID is in format of the IP address.
An IP address is configured for the local end of IKE negotiation.

Step 16 Run:
quit

aaa

service-scheme service-scheme-name
A service scheme is created and the service scheme view is displayed.

dns ip-address
The IP address of the primary DNS server is configured.

dns ip-address secondary
The IP address of the secondary DNS server is configured.

wins ip-address
The IP address of the primary WINS server is configured.

wins ip-address secondary
The IP address of the secondary WINS server is configured.

quit

quit

Step 25 Run:


Step 26 Run:
ipsec efficient-vpn efficient-vpn-name
The Efficient VPN policy is applied to the interface.
----End
3.6.4 Verifying the Configuration

After completing Efficient VPN configuration, you can view information about the IPSec
proposal, SA, IPSec Efficient VPN policy, and IPSec tunnel established using the Efficient VPN
policy.
Prerequisites
All Efficient VPN configurations are complete.
Procedure
number | verbose ] command to check information about the IPSec tunnel established
through IKE negotiation.
profile-name | efficient-vpn efficient-vpn-name | peerip peer-ip-address ] command to
check information about SAs.
l Run the display ipsec proposal [ name proposal-name ] command to check information
about IPSec proposals.
l Run the display ipsec efficient-vpn [ brief | capality | name efficient-vpn-name ] command
to check information about the Efficient VPN policy.
----End
3.7 Maintaining IPSec

This section describes how to display the IPSec configuration and clear the IPSec statistics.
3.7.1 Displaying the IPSec Configuration

You can run the following display commands to view information about the SA, established
IPSec tunnel, and statistics about IPSec packets.
Prerequisites
The configurations of IPSec are complete.
Procedure
profile-name | peerip peer-ip-address ] command to check information about the IPSec
SA.

number | verbose ] command to check information about the IPSec tunnel that is
established.
l Run the display ipsec statistics { ah | esp } command to check the statistics about IPSec
packets.
l Run the display ike statistics { all | msg | v1 | v2 } command to check the statistics about
IKE packets.
l Run the display ipsec profile [ brief | name profile-name ] command to check information
about the IPSec profile.
l Run the display ipsec efficient-vpn [ brief | capality | name efficient-vpn-name ] command
to check information about the Efficient VPN policy.
----End
3.7.2 Clearing IPSec Information

This section describes how to clear the statistics about IPSec and IKE packets, information about
SAs, and information about the IPSec tunnels established through IKE negotiation.
Context
CAUTION
The statistics cannot be restored after being cleared.
Procedure
l Run the reset ipsec statistics { ah | esp } command in the user view to clear the statistics
about IPSec packets.
l Run the reset ike statistics { all | msg } command in the user view to clear the statistics
about IKE packets.
l Run the reset ipsec sa [ remote ip-address | policy policy-name [ seq-number ] |
parameters dest-address { ah | esp } spi ] command in the user view to clear an SA.
l Run the reset ipsec sa profile profile-name command in the user view to clear the SA
generated by the IPSec profile.
l Run the reset ipsec sa efficient-vpn efficient-vpn-name command in the user view to clear
the SA generated by the Efficient VPN policy.
l Run the reset ike sa { all | conn-id connection-id } command in the user view to delete a
specified IPSec tunnel or all established IPSec tunnels.
----End

This section provides several configuration examples of IPSec.

3.8.1 Example for Establishing an SA Manually

You can establish security associations (SAs) manually when the network topology is simple.
When there are a large number of devices on the network, it is difficult to establish SAs manually,
and network security cannot be ensured.
As shown in Figure 3-3, an IPSec tunnel is established between RouterA and RouterB to protect
data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B (10.1.2.0/24). The
IPSec tunnel uses the ESP protocol, DES encryption algorithm, and SHA-1 authentication
algorithm.
Figure 3-3 Network diagram for configuring IPSec

Eth 1/0/0 Eth 1/0/0
202.138.163.1/24 202.138.162.1/24
RouterA RouterB
Internet
IPSec Tunnel
PC A 10.1.1.2/24 PC B
10.1.2.2/24
1. Configure IP addresses for interfaces.
2. Configure Access Control Lists (ACLs) and define the data flows to be protected.
3. Configure static routes to peers.
4. Configure an IPSec proposal.
5. Configure IPSec policies and apply the ACLs and IPSec proposal to the IPSec policies.
6. Apply IPSec policies to interfaces.
Procedure
Step 1 Configure IP addresses for the interfaces on RouterA and RouterB.
# Assign an IP address to the interface of RouterA.
[Huawei] interface ethernet 1/0/0
[Huawei-Ethernet1/0/0] ip address 202.138.163.1 255.255.255.0
[Huawei-Ethernet1/0/0] quit

# Assign an IP address to the interface of RouterB.

Step 2 Configure ACLs on RouterA and RouterB to define the data flows to be protected.
# Configure an ACL on RouterA.
[Huawei] acl number 3101
[Huawei-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0
0.0.0.255
[Huawei-acl-adv-3101] quit
# Configure an ACL on RouterB.

0.0.0.255
Step 3 Configure static routes to the peers on RouterA and RouterB.

# Configure a static route to the peer on RouterA. In this example, the next hop to PCB is
202.138.163.2.
[Huawei] ip route-static 10.1.2.0 255.255.255.0 202.138.163.2
# Configure a static route to the peer on RouterB. In this example, the next hop to PCA is
202.138.162.2.
Step 4 Create an IPSec proposal on RouterA and RouterB.

# Create the IPSec proposal on RouterA.
[Huawei] ipsec proposal tran1
[Huawei-ipsec-proposal-tran1] esp authentication-algorithm sha1
[Huawei-ipsec-proposal-tran1] quit
# Create the IPSec proposal on RouterB.

Run the display ipsec proposal command on RouterA and RouterB to view the configuration
of the IPSec proposal. Take the display on RouterA as an example.
[Huawei] display ipsec proposal
Number of Proposals: 1
IPsec proposal name: tran1

Transform : esp-new
ESP protocol : Authentication SHA1-HMAC-96
Encryption DES
Step 5 Create IPSec policies on RouterA and RouterB.

# Create an IPSec policy on RouterA.
[Huawei] ipsec policy map1 10 manual
[Huawei-ipsec-policy-manual-map1-10] security acl 3101
[Huawei-ipsec-policy-manual-map1-10] proposal tran1

[Huawei-ipsec-policy-manual-map1-10] tunnel remote 202.138.162.1

[Huawei-ipsec-policy-manual-map1-10] tunnel local 202.138.163.1
[Huawei-ipsec-policy-manual-map1-10] sa spi outbound esp 12345
[Huawei-ipsec-policy-manual-map1-10] sa spi inbound esp 54321
[Huawei-ipsec-policy-manual-map1-10] sa string-key outbound esp abcdefg
[Huawei-ipsec-policy-manual-map1-10] sa string-key inbound esp gfedcba
[Huawei-ipsec-policy-manual-map1-10] quit
# Create an IPSec policy on RouterB.

[Huawei] ipsec policy use1 10 manual
[Huawei-ipsec-policyl-manual-use1-10] security acl 3101
[Huawei-ipsec-policyl-manual-use1-10] proposal tran1
[Huawei-ipsec-policyl-manual-use1-10] tunnel remote 202.138.163.1
[Huawei-ipsec-policyl-manual-use1-10] tunnel local 202.138.162.1
[Huawei-ipsec-policyl-manual-use1-10] sa spi outbound esp 54321
[Huawei-ipsec-policyl-manual-use1-10] sa spi inbound esp 12345
[Huawei-ipsec-policyl-manual-use1-10] sa string-key outbound esp gfedcba
[Huawei-ipsec-policyl-manual-use1-10] sa string-key inbound esp abcdefg
[Huawei-ipsec-policyl-manual-use1-10] quit
Run the display ipsec policy command on RouterA and RouterB to view the configurations of
the IPSec policies. Take the display on RouterA as an example.
[Huawei] display ipsec policy
===========================================
IPsec Policy Group: "map1"
Using interface: {}
===========================================
Sequence number: 10
Security data flow: 3101
Tunnel local address: 202.138.163.1
Tunnel remote address: 202.138.162.1
Proposal name:tran1
Inbound AH setting:
AH SPI:
AH string-key:
AH authentication hex key:
Inbound ESP setting:
ESP SPI: 54321 (0xd431)
ESP string-key: gfedcba
ESP encryption hex key:
ESP authentication hex key:
Outbound AH setting:
AH SPI:
AH string-key:
AH authentication hex key:
Outbound ESP setting:
ESP SPI: 12345 (0x3039)
ESP string-key: abcdefg
ESP encryption hex key:
ESP authentication hex key:
Step 6 Apply the IPSec policies to the interfaces of RouterA and RouterB.
# Apply the IPSec policy to the interface of RouterA.
[Huawei-Ethernet1/0/0] ipsec policy map1
# Apply the IPSec policy to the interface of RouterB.

[Huawei-Ethernet1/0/0] ipsec policy use1
Run the display ipsec sa command on RouterA and RouterB to view the configuration of the
IPSec SAs. Take the display on RouterA as an example.

[Huawei] display ipsec sa

===============================
Interface: Ethernet 1/0/0
Path MTU: 1500
===============================
-----------------------------
IPsec policy name: "map1"
Sequence number: 10
Acl Group: 3101
Acl rule: 0
Mode: Manual
-----------------------------
Tunnel local : 202.138.163.1
Tunnel remote: 202.138.162.1
[Outbound ESP SAs]

SPI: 12345 (0x3039)
Proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-SHA1
No duration limit for this SA
[Inbound ESP SAs]

SPI: 54321 (0xd431)
Proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-SHA1
No duration limit for this SA
Step 7 Verify the configurations.

After the configurations are complete, PC A can ping PC B successfully. You can run the display
ipsec statistics esp command to view packet statistics.
----End
Configuration Files
#
acl number
3101
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0
0.0.0.255
#
ipsec proposal
tran1
esp authentication-algorithm
sha1
#
ipsec policy map1 10
manual
security acl
3101
proposal
tran1
tunnel local
202.138.163.1
tunnel remote
202.138.162.1
sa spi inbound esp
54321
sa string-key inbound esp
gfedcba
sa spi outbound esp
12345
sa string-key outbound esp
abcdefg
#

ip route-static 10.1.2.0 255.255.255.0

202.138.163.2
#
ip address 202.138.163.1 255.255.255.0
ipsec policy map1
#
return

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
esp authentication-algorithm
sha1
#
ipsec policy use1 10
manual
security acl
3101
proposal tran1
tunnel local
202.138.162.1
tunnel remote
202.138.163.1
sa spi inbound esp
12345
sa string-key inbound esp
abcdefg
sa spi outbound esp
54321
sa string-key outbound esp
gfedcba
#
ip route-static 10.1.1.0 255.255.255.0

202.138.162.2
#
ip address 202.138.162.1 255.255.255.0
ipsec policy use1
#
return
3.8.2 Example for Configuring IKE Negotiation Using Default

Settings
This section provides an example for configuring IKE negotiation using default settings.
As shown in Figure 3-4, an IPSec tunnel is established between RouterA and RouterB. This
IPSec tunnel protects data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B
(10.1.2.0/24). The IPSec tunnel uses the ESP protocol, DES encryption algorithm, and MD5
authentication algorithm.

NOTE
l In this example, the default IKE proposal is used.

l By default, a new IPSec proposal created using the ipsec proposal command uses the ESP protocol, DES
encryption algorithm, MD5 authentication algorithm, and tunnel encapsulation mode.
Figure 3-4 Network diagram for configuring IKE negotiation
Eth 1/0/0 Eth 1/0/0

202.138.163.1/24 202.138.162.1/24
RouterA RouterB
Internet
IPSec Tunnel
PC A 10.1.1.2/24 PC B
10.1.2.2/24

2. Specify the local host ID and IKE peer for IKE negotiation.
Procedure



Step 2 Configure local IDs and IKE peers on RouterA and RouterB.
# Configure the local ID and IKE peer on RouterA.

[Huawei] ike peer spub v1
[Huawei-ike-peer-spub] pre-shared-key huawei
[Huawei-ike-peer-spub] remote-address 202.138.162.1
[Huawei-ike-peer-spub] quit
NOTE
In aggressive mode, if the value of local-id-type is name, configure the IP address of the remote peer
(remote-address x.x.x.x) on the local end.
# Configure the local ID and IKE peer on RouterB.

[Huawei] ike peer spua v1
[Huawei-ike-peer-spua] pre-shared-key huawei
[Huawei-ike-peer-spua] remote-address 202.138.163.1
[Huawei-ike-peer-spua] quit
Run the display ike peer command on RouterA and RouterB to view the configuration of the
IKE peer. Take the display on RouterA as an example.
[Huawei] display ike peer name spub verbose
----------------------------------------
Peer name : spub
Exchange mode : main on phase 1
Pre-shared-key : huawei
Local ID type : IP
DPD : Disable
DPD mode : Periodic
DPD idle time : 30
DPD retransmit interval : 15
DPD retry limit : 3
Host name :
Peer Ip address : 202.138.162.1
VPN name :
Local IP address :
Remote name :
Nat-traversal : Disable
Configured IKE version : Version one
PKI realm : NULL
Inband OCSP : Disable
----------------------------------------

0.0.0.255

0.0.0.255
202.138.163.2.

202.138.162.2.



Transform : esp-new
ESP protocol : Authentication MD5-HMAC-96
Encryption DES

[Huawei] ipsec policy map1 10 isakmp
[Huawei-ipsec-policy-isakmp-map1-10] ike-peer spub
[Huawei-ipsec-policy-isakmp-map1-10] proposal tran1
[Huawei-ipsec-policy-isakmp-map1-10] security acl 3101
[Huawei-ipsec-policy-isakmp-map1-10] quit

[Huawei] ipsec policy use1 10 isakmp
[Huawei-ipsec-policy-isakmp-use1-10] ike-peer spua
[Huawei-ipsec-policy-isakmp-use1-10] proposal tran1
[Huawei-ipsec-policy-isakmp-use1-10] security acl 3101
[Huawei-ipsec-policy-isakmp-use1-10] quit
===========================================
IPsec policy group: "map1"
Using interface: {}
===========================================
Sequence number: 10
Peer name: spub
Perfect forward secrecy: None
Proposal name: tran1
IPsec SA local duration(time based): 3600 seconds
IPsec SA local duration(traffic based): 1843200 kilobytes
SA trigger mode: Automatic
Route inject: None



===============================
path MTU: 1500
===============================
-----------------------------
sequence number: 10
mode: isakmp
-----------------------------
Connection id: 3
encapsulation mode: tunnel
tunnel local : 202.138.163.1 tunnel remote: 202.138.162.1
[inbound ESP SAs]
spi: 1406123142 (0x53cfbc86)
proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
sa remaining key duration (bytes/sec): 1887436528/3575
max received sequence-number: 4
udp encapsulation used for nat traversal: N
[outbound ESP SAs]
spi: 3835455224 (0xe49c66f8)
proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
max sent sequence-number: 5

After the configurations are complete, PC A can ping PC B successfully. The data transmitted
between PC A and PC B is encrypted.
Run the display ike sa command on RouterA, and the following information is displayed:
[Huawei] display ike sa
---------------------------------------------------------
14 202.138.162.1 0 RD|ST 1
16 202.138.162.1 0 RD|ST 2
Flag Description:
----End
Configuration Files
#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1

#
ike peer spub
v1
pre-shared-key
huawei
remote-address
202.138.162.1
#
isakmp
security acl
3101
ike-peer
spub
proposal
tran1
#
ip route-static 10.1.2.0 255.255.255.0 202.138.163.2

#
ip address 202.138.163.1 255.255.255.0
ipsec policy map1
#
return

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
esp authentication-algorithm sha1
#
ike peer spua
v1
pre-shared-key
huawei
remote-address
202.138.163.1
#
isakmp
security acl
3101
ike-peer
spua
proposal
tran1
#
ip route-static 10.1.1.0 255.255.255.0 202.138.162.2

#
ip address 202.138.162.1 255.255.255.0
ipsec policy use1
#
return
3.8.3 Example for Configuring IKE Negotiation

IKE automatically establishes an SA and performs key exchange to improve efficiency of SA
establishment and ensure network security.

As shown in Figure 3-5, an IPSec tunnel is established between RouterA and RouterB. This
IPSec tunnel protects data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B
(10.1.2.0/24). The IPSec tunnel uses the ESP protocol, DES encryption algorithm, and SHA-1
authentication algorithm.
Figure 3-5 Network diagram for configuring IKE negotiation

Eth 1/0/0 Eth 1/0/0
202.138.163.1/24 202.138.162.1/24
RouterA RouterB
Internet
IPSec Tunnel
PC A 10.1.1.2/24 PC B
10.1.2.2/24
2. Configure an IKE proposal.
3. Specify the local host ID and IKE peer for IKE negotiation.
Procedure



Step 2 Create an IKE proposal on RouterA and RouterB.

# Create the IKE proposal on RouterA.
[Huawei] ike proposal 1
[Huawei-ike-proposal-1] encryption-algorithm aes-cbc-128
[Huawei-ike-proposal-1] authentication-algorithm md5
[Huawei-ike-proposal-1] quit
# Create the IKE proposal on RouterB.

[Huawei-ike-proposal-1] encryption-algorithm aes-cbc-128
[Huawei-ike-proposal-1] authentication-algorithm md5
[Huawei] ike local-name huawei01
[Huawei-ike-peer-spub] exchange-mode aggressive
[Huawei-ike-peer-spub] ike-proposal 1
[Huawei-ike-peer-spub] local-id-type name
[Huawei-ike-peer-spub] remote-name huawei02
[Huawei-ike-peer-spub] remote-address 202.138.162.1
[Huawei-ike-peer-spub] local-address 202.138.163.1
NOTE
In aggressive mode, if the value of local-id-type is name, configure the IP address of the remote peer
(remote-address x.x.x.x) on the local end.

[Huawei] ike local-name huawei02
[Huawei-ike-peer-spua] exchange-mode aggressive
[Huawei-ike-peer-spua] ike-proposal 1
[Huawei-ike-peer-spua] local-id-type name
[Huawei-ike-peer-spua] remote-name huawei01
[Huawei-ike-peer-spua] remote-address 202.138.163.1
[Huawei-ike-peer-spua] local-address 202.138.162.1
----------------------------------------
Peer name : spub
Exchange mode : aggressive on phase 1
Proposal : 1
Local ID type : Name
DPD : Disable
DPD mode : Periodic
DPD idle time : 30
DPD retry limit : 3
Host name :
Peer Ip address : 202.138.162.1
VPN name :
Local IP address : 202.138.163.1

Remote name : huawei02

Configured IKE version : Version one
Auto-configure : Disable
PKI realm : NULL
----------------------------------------

0.0.0.255

0.0.0.255
202.138.163.2.
202.138.162.2.

[Huawei-ipsec-proposal-tran1] encapsulation-mode tunnel
[Huawei-ipsec-proposal-tran1] transform esp
[Huawei-ipsec-proposal-tran1] esp encryption-algorithm des

[Huawei-ipsec-proposal-tran1] encapsulation-mode tunnel
[Huawei-ipsec-proposal-tran1] transform esp
[Huawei-ipsec-proposal-tran1] esp encryption-algorithm des

Transform : esp-new
Encryption DES


[Huawei] ipsec policy map1 10 isakmp
[Huawei-ipsec-policy-isakmp-map1-10] ike-peer spub
[Huawei-ipsec-policy-isakmp-map1-10] proposal tran1
[Huawei-ipsec-policy-isakmp-map1-10] security acl 3101
[Huawei-ipsec-policy-isakmp-map1-10] quit

[Huawei] ipsec policy use1 10 isakmp
[Huawei-ipsec-policy-isakmp-use1-10] ike-peer spua
[Huawei-ipsec-policy-isakmp-use1-10] proposal tran1
[Huawei-ipsec-policy-isakmp-use1-10] security acl 3101
[Huawei-ipsec-policy-isakmp-use1-10] quit
===========================================
IPsec policy group: "map1"
Using interface: {}
===========================================
Sequence number: 10
Peer name: spub
Perfect forward secrecy: None
Proposal name: tran1
IPsec SA local duration(time based): 3600 seconds
IPsec SA local duration(traffic based): 1843200 kilobytes
SA trigger mode: Automatic
Route inject: None

===============================
path MTU: 1500
===============================
-----------------------------
sequence number: 10
mode: isakmp
-----------------------------
Connection id: 3
encapsulation mode: tunnel
tunnel local : 202.138.163.1 tunnel remote: 202.138.162.1
[inbound ESP SAs]
spi: 1406123142 (0x53cfbc86)

proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1

max received sequence-number: 4
[outbound ESP SAs]
spi: 3835455224 (0xe49c66f8)
proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1
max sent sequence-number: 5

After the configurations are complete, PC A can ping PC B successfully. The data transmitted
between PC A and PC B is encrypted.
---------------------------------------------------------
14 202.138.162.1 0 RD|ST 1
16 202.138.162.1 0 RD|ST 2
Flag Description:
----End
Configuration Files
#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
#
ike proposal
1
encryption-algorithm aes-
cbc-128
authentication-algorithm md5
#
ike local-name huawei01
#
ike peer spub
v1
exchange-mode
aggressive
pre-shared-key
huawei
ike-proposal
1
local-id-type
name
remote-name
huawei02
local-address
202.138.163.1
remote-address
202.138.162.1
#

isakmp
security acl
3101
ike-peer
spub
proposal
tran1
#
ip route-static 10.1.2.0 255.255.255.0 202.138.163.2

#
ip address 202.138.163.1 255.255.255.0
ipsec policy map1
#
return

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
#
ike proposal
1
encryption-algorithm aes-
cbc-128
authentication-algorithm md5
#
ike local-name huawei02
#
ike peer spua
v1
exchange-mode
aggressive
pre-shared-key
huawei
ike-proposal
1
local-id-type
name
remote-name
huawei01
local-address
202.138.162.1
remote-address
202.138.163.1
#
isakmp
security acl
3101
ike-peer
spua
proposal
tran1
#
ip route-static 10.1.1.0 255.255.255.0 202.138.162.2

#
ip address 202.138.162.1 255.255.255.0
ipsec policy use1

#
return
3.8.4 Example for Establishing an IPSec Tunnel Using an IPSec

Tunnel Interface
An IPSec tunnel can be established using an IPSec tunnel interface. This method simplifies the
IPSec configuration, reduces costs between devices on the IPSec network, and makes service
application flexible.
traffic on the IPSec tunnel interface. The IPSec tunnel uses the AH-ESP protocol, 3DES
encryption algorithm, and SHA-1 authentication algorithm.
Figure 3-6 Networking diagram for establishing an IPSec tunnel using the IPSec tunnel interface
Eth1/0/0 Eth1/0/0
202.138.163.1/24 202.138.162.1/24
RouterA RouterB
Internet
Tunnel0/0/0 Tunnel0/0/0
192.168.1.1/24 192.168.1.2/24
IPSec Tunnel
10.1.1.2/24
10.1.2.2/24
Network A Network B
1. Assign IP addresses to interfaces.
3. Configure IKE proposals.
4. Specify the local IDs and IKE peers required in IKE negotiation.
5. Configure IPSec proposals.
6. Configure IPSec profiles and bind the IPSec proposals and IKE peers to the IPSec profiles.
7. Apply the IPSec profiles to the IPSec tunnel interfaces.
Procedure



# Configure a static route to the remote peer on RouterA. This example assumes that the next
hop address in the route to RouterB is 202.138.163.2.
# Configure a static route to the remote peer on RouterB. This example assumes that the next
Step 3 Create IKE proposals on RouterA and RouterB.

# Create an IKE proposal on RouterA.
[Huawei-ike-proposal-1] dh group5
[Huawei-ike-proposal-1] authentication-algorithm aes_xcbc_mac_96
[Huawei-ike-proposal-1] prf aes_xcbc_128
# Create an IKE proposal on RouterB.

[Huawei-ike-proposal-1] authentication-algorithm aes_xcbc_mac_96
[Huawei-ike-proposal-1] prf aes_xcbc_128
[Huawei-ike-peer-spub] ike-proposal 1

[Huawei-ike-peer-spua] ike-proposal 1
----------------------------------------
Peer name : spub
proposal : 1
Local ID type :
DPD : Disable
DPD mode : Periodic
DPD idle time : 30


DPD retry limit : 3
Peer ID type :
Host name :
Peer IP address :
VPN name :
Local IP address : 202.138.163.1
Remote name :
Configured IKE version : Version two
Auto-configure : Disable
PKI realm : NULL
----------------------------------------
Step 5 Create IPSec proposals on RouterA and RouterB.

# Create an IPSec proposal on RouterA.
[Huawei-ipsec-proposal-tran1] transform ah-esp
[Huawei-ipsec-proposal-tran1] ah authentication-algorithm sha1
[Huawei-ipsec-proposal-tran1] esp encryption-algorithm 3des
# Create an IPSec proposal on RouterB.

[Huawei-ipsec-proposal-tran1] transform ah-esp
[Huawei-ipsec-proposal-tran1] ah authentication-algorithm sha1
[Huawei-ipsec-proposal-tran1] esp encryption-algorithm 3des
IPSec proposal name: tran1

Transform : ah-esp-new
AH protocol : Authentication SHA1-HMAC-96
Encryption 3DES
Step 6 Create IPSec profiles on RouterA and RouterB.

# Create an IPSec profile on RouterA.
[Huawei] ipsec profile profile1
[Huawei-ipsec-profile-profile1] proposal tran1
[Huawei-ipsec-profile-profile1] ike-peer spub
[Huawei-ipsec-profile-profile1] quit
# Create an IPSec profile on RouterB.

[Huawei] ipsec profile profile2
[Huawei-ipsec-profile-profile1] proposal tran1
[Huawei-ipsec-profile-profile1] ike-peer spua
[Huawei-ipsec-profile-profile1] quit
Step 7 Apply the IPSec profiles to the interfaces of RouterA and RouterB.
# Apply the IPSec profile to the interface of RouterA.

[Huawei-Tunnel0/0/0] ip address 192.168.1.1 24

[Huawei-Tunnel0/0/0] source 202.138.163.1
[Huawei-Tunnel0/0/0] destination 202.138.162.1
[Huawei-Tunnel0/0/0] ipsec profile profile1
[Huawei-Tunnel0/0/0] quit
# Apply the IPSec profile to the interface of RouterB.

[Huawei-Tunnel0/0/0] ip address 192.168.1.2 24
[Huawei-Tunnel0/0/0] source 202.138.162.1
[Huawei-Tunnel0/0/0] destination 202.138.163.1
[Huawei-Tunnel0/0/0] ipsec profile profile2

Run the display ipsec profile command on RouterA and RouterB to view the configurations of
the IPSec profiles. Take the display on RouterA as an example.
[Huawei] display ipsec profile
===========================================
IPSec profile : profile1
Using interface: Tunnel0/0/0
===========================================
IPSec Profile Name :profile1
Peer Name :spub
PFS Group :0 (0:Disable 1:Group1 2:Group2 5:Group5 14:Group14)
SecondsFlag :0 (0:Global 1:Local)
SA Life Time Seconds :3600
KilobytesFlag :0 (0:Global 1:Local)
SA Life Kilobytes :1843200
Number of IPSec Proposals :1
IPSec Proposals Name :tran1
----End
Configuration Files
#
ipsec proposal tran1
transform ah-esp
ah authentication-algorithm sha1
esp encryption-algorithm 3des
#
ip route-static 10.1.2.0 255.255.255.0 202.138.163.2

#
ike proposal 1
dh group5
authentication-algorithm aes_xcbc_mac_96
prf aes_xcbc_128
#
ike peer spub v2
pre-shared-key huawei
ike-proposal 1
#
ipsec profile profile1
ike-peer spub
proposal tran1
#
ip address 192.168.1.1 255.255.255.0
tunnel-protocol gre

source 202.138.163.1
#
ip address 202.138.163.1 255.255.255.0
#
return

#
transform ah-esp
ah authentication-algorithm sha1
esp encryption-algorithm 3des
#
ip route-static 10.1.1.0 255.255.255.0 202.138.162.2

#
ike proposal 1
dh group5
authentication-algorithm aes_xcbc_mac_96
prf aes_xcbc_128
#
ike peer spua v2
ike-proposal 1
#
ike-peer spua
proposal tran1
#
ip address 192.168.1.2 255.255.255.0
tunnel-protocol gre
source 202.138.162.1
#
ip address 202.138.162.1 255.255.255.0
#
return
3.8.5 Example for Establishing an SA Using Efficient VPN in Client

Mode
This topic describes an example for establishing an SA using Efficient VPN in client mode in
the actual networking.
data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B (10.1.2.0/24). An SA
is established and the key is exchanged automatically between the Remote and Server,
simplifying the configuration and improving efficiency.

Figure 3-7 Networking for Establishing an SA Using Efficient VPN in Client Mode
RouterA RouterB
Remote Internet Server

Eth1/0/0 Eth1/0/0
60.1.1.1/24 60.1.2.1/24
IPSec Tunnel
10.1.1.2/24 10.1.2.2/24
PC A PC B
The configuration roadmap on RouterA is as follows:
1. Assign an IP address to an interface.
2. Configure a static route.
3. Configure the Efficient VPN policy in client mode.
4. Configure an address for the peer end in IKE negotiation.
5. Configure a pre-shared key.
6. Apply the Efficient VPN policy to the interface.
The configuration roadmap on RouterB is as follows:
3. Configure the resource attributes to be allocated.
4. Configure the IKE proposal and IKE peer.
5. Configure the IPSec proposal, template policy, and policy group.
6. Apply the policy group to the interface.
Procedure
Step 1 Configure RouterA.
1. Assign an IP address to the interface on RouterA.
2. Configure a static route to the remote peer on RouterA. This example assumes that the next
3. Configure the Efficient VPN policy in client mode.

[Huawei] ipsec efficient-vpn 2 mode client
4. Configure an address for the peer end in IKE negotiation.

[Huawei-ipsec-efficient-vpn-2] remote-address 60.1.2.1 v2
5. Configure a pre-shared key.

[Huawei-ipsec-efficient-vpn-2] pre-shared-key huawei
[Huawei-ipsec-efficient-vpn-2] quit

[Huawei] interface ethernet1/0/0
[Huawei-Ethernet1/0/0] ipsec efficient-vpn 2
Step 2 Configure RouterB.

1. Assign an IP address to the interface on RouterB.
2. Configure a static route to the remote peer on RouterB. This example assumes that the next
hop address in the route to RouterA is 60.1.2.2.
3. Configure the resource attributes to be allocated: the IP address, DNS server address, and
WINS server address.
[Huawei] ip pool pooltest
[Huawei-ip-pool-pooltest] network 100.1.1.0 mask 255.255.255.128
[Huawei-ip-pool-pooltest] quit
[Huawei] aaa
[Huawei-aaa] service-scheme schemetest
[Huawei-aaa-service-schemetest] dns 2.2.2.2
[Huawei-aaa-service-schemetest] dns 2.2.2.3 secondary
[Huawei-aaa-service-schemetest] ip-pool pooltest
[Huawei-aaa-service-schemetest] wins 3.3.3.2
[Huawei-aaa-service-schemetest] wins 3.3.3.3 secondary
[Huawei-aaa-service-schemetest] quit
[Huawei-aaa] quit
4. Configure the IKE proposal and IKE peer.

[Huawei] ike peer rut3 v2
[Huawei-ike-peer-rut3] pre-shared-key huawei
[Huawei-ike-peer-rut3] ike-proposal 5
[Huawei-ike-peer-rut3] service-scheme schemetest
[Huawei-ike-peer-rut3] quit
5. Configure the IPSec proposal, template policy, and policy group.

[Huawei] ipsec policy-template use1 10
[Huawei-ipsec-policy-templet-use1-10] ike-peer rut3
[Huawei-ipsec-policy-templet-use1-10] proposal tran1
[Huawei-ipsec-policy-templet-use1-10] sa duration time-based 600000
[Huawei-ipsec-policy-templet-use1-10] quit
[Huawei] ipsec policy policy1 10 isakmp template use1
6. Apply the policy group to the interface.

[Huawei-Ethernet1/0/0] ipsec policy policy1
Step 3 Verify the configuration

1. After the preceding configuration, RouterA can still ping RouterB and the data transmitted
between them is encrypted.

[Huawei] display ike sa v2
---------------------------------------------------------
64 60.1.2.1 0 RD|ST 2
62 60.1.2.1 0 RD|ST 1
Flag
Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--
TIMEOUT
2. Run the display ipsec sa command on RouterA and RouterB to view the IPSec
configuration. The display on RouterA is used as an example.
===============================
Path MTU: 1500
===============================
-----------------------------
IPSec efficient-vpn name: "2"
Mode: EFFICIENTVPN-CLIENT MODE
-----------------------------
Connection ID : 64
Flow source : 100.1.1.126/255.255.255.255 0/0
Flow destination : 0.0.0.0/0.0.0.0 0/0
[Outbound ESP SAs]
SPI: 3752053811 (0xdfa3cc33)
proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-MD5
[Inbound ESP SAs]
SPI: 4182141148 (0xf94668dc)
proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-MD5
3. Run the display ipsec efficient-vpn command on RouterA to view information about the
Efficient VPN policy.
[Huawei] display ipsec efficient-vpn
===========================================
IPSec efficient-vpn name: 2
Using interface : Ethernet1/0/0
===========================================
IPSEC Efficient-vpn Name : 2
IPSEC Efficient-vpn Mode : 1 (1:Client 2:Network)
ACL Number :
Auth Method : 8 (8:PSK 9:RSA)
VPN name :
Local ID Type : 1 (1:IP 2:Name)
Remote Address : 60.1.2.1
IKE Version : 2 (1:IKEv1 2:IKEv2)
FQDN :
Pre Shared Key : huawei
PFS Type : 0 (0:Disable 1:Group1 2:Group2 5:Group5
14:Group14)
Local Address :
Remote Name :
PKI Object :
Interface loopback : LoopBack100
Interface loopback IP : 100.1.1.126/32

Dns server IP : 2.2.2.2, 2.2.2.3

Wins server IP : 3.3.3.2, 3.3.3.3
----End
Configuration Files
#
ipsec efficient-vpn 2 mode client
remote-address 60.1.2.1 v2
#
ip address 60.1.1.1 255.255.255.0
ipsec efficient-vpn 2
#
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2

#
return

#
#
ike proposal 5
dh
group2
ike peer rut3

v2
pre-shared-key
huawei
ike-proposal
5
service-scheme
schemetest
#
ipsec policy-template use1

10
ike-peer
rut3
proposal
tran1
sa duration time-based
600000
#
ipsec policy policy1 10 isakmp template

use1
#
ip pool
pooltest
network 100.1.1.0 mask

255.255.255.128
#
aaa
service-scheme
schemetest

dns
2.2.2.2
dns 2.2.2.3
secondary
ip-pool
pooltest
wins
3.3.3.2
wins 3.3.3.3
secondary
#
interface
Ethernet1/0/0
ip address 60.1.2.1
255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 60.1.2.2

#
return
3.8.6 Example for Establishing an SA Using Efficient VPN in

Network Mode
This topic describes an example for establishing an SA using Efficient VPN in network mode
in the actual networking.
data flows that are transmitted between the subnet of PC A (10.1.1.0/24) and subnet of PC B
(10.1.2.0/24) and match the ACL. In network mode, the remote device does not apply for or an
IP address, and NAT and PAT are disabled on the remote device.
Figure 3-8 Networking for Establishing an SA Using Efficient VPN in Network Mode
RouterA Eth1/0/0 Eth1/0/0 RouterB

Remote
100.1.1.1/24 Internet 100.1.2.1/24
Server
Eth1/0/0.1 Eth1/0/0.1
99.1.1.1/24 99.1.2.1/24
IPSec Tunnel
10.1.1.2/24
10.1.2.2/24
PC A PC B

The configuration roadmaps of RouterA and RouterB are as follows:
3. Configure ACLs and define the data flows to be protected.
4. Configure the Efficient VPN policy in network mode.
Procedure
[Huawei] interface ethernet 1/0/0.1
[Huawei-Ethernet1/0/0.1] ip address 99.1.1.1 255.255.255.0
[Huawei-Ethernet1/0/0.1] control-vid 1 dot1q-termination
[Huawei-Ethernet1/0/0.1] dot1q termination vid 1
[Huawei-Ethernet1/0/0.1] arp broadcast enable
[Huawei-Ethernet1/0/0.1] quit
# Assign an IP address to the interface on RouterB.

[Huawei-Ethernet1/0/0.1] ip address 99.1.2.1 255.255.255.0
[Huawei-Ethernet1/0/0.1] control-vid 1 dot1q-termination
[Huawei-Ethernet1/0/0.1] dot1q termination vid 1
[Huawei-Ethernet1/0/0.1] arp broadcast enable
[Huawei-Ethernet1/0/0.1] quit

# Configure a static route to the remote peer on RouterA. This example assumes that the next
# Configure a static route to the remote peer on RouterB. This example assumes that the next
hop address in the route to RouterA is 100.1.2.2.
[Huawei-acl-adv-3000] rule 5 permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255


[Huawei-acl-adv-3000] rule 5 permit ip source 10.1.2.0 0.0.0.255 destination

10.1.1.0 0.0.0.255
Step 4 Configure the Efficient VPN policies in network mode on RouterA and RouterB.
# Configure the Efficient VPN policy in network mode on RouterA.
[Huawei] ipsec efficient-vpn easyvpn_1 mode network
[Huawei-ipsec-efficient-vpn-easyvpn_1] remote-address 99.1.2.1 v1
[Huawei-ipsec-efficient-vpn-easyvpn_1] pre-shared-key htipl1.,;[-09876543211;'[]
[Huawei-ipsec-efficient-vpn-easyvpn_1] security acl 3000
[Huawei-ipsec-efficient-vpn-easyvpn_1] quit
# Configure the Efficient VPN policy in network mode on RouterB.

[Huawei] ipsec efficient-vpn easyvpn_1 mode network
[Huawei-ipsec-efficient-vpn-easyvpn_1] remote-address 99.1.1.1 v1
[Huawei-ipsec-efficient-vpn-easyvpn_1] pre-shared-key htipl1.,;[-09876543211;'[]
[Huawei-ipsec-efficient-vpn-easyvpn_1] security acl 3000
[Huawei-ipsec-efficient-vpn-easyvpn_1] quit
Step 5 Apply the Efficient VPN policies to the sub-interfaces of RouterA and RouterB.
# Apply the Efficient VPN policy to the sub-interface on RouterA.
[Huawei-Ethernet1/0/0.1] ipsec efficient-vpn easyvpn_1
# Apply the Efficient VPN policy to the sub-interface on RouterB.
[Huawei-Ethernet1/0/0.1] ipsec efficient-vpn easyvpn_1
Step 6 Verify the configuration

After the preceding configuration, RouterA can still ping RouterB and the data transmitted
between them is encrypted.
l Run the display ipsec sa command on RouterA and RouterB to view the IKE configuration.
The display on RouterA is used as an example.
---------------------------------------------------------
3 99.1.2.1 0 RD|ST 2
2 99.1.2.1 0 RD|ST 1
Flag
Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--
TIMEOUT
l Run the display ipsec sa command on RouterA and RouterB to view the IPSec configuration.
The display on RouterA is used as an example.
===============================
Interface: Ethernet 1/0/0.1
Path MTU: 1500
===============================
-----------------------------
IPSec efficient-vpn name: "easyvpn_1"
mode: EFFICIENTVPN-NETWORK MODE
-----------------------------
Connection ID: 3
encapsulation mode: Tunnel
tunnel local : 99.1.1.1
tunnel remote : 99.1.2.1
Flow source : 100.1.1.1/0.0.0.0 0/0
Flow destination : 100.1.2.1/0.0.0.0 0/0
[Outbound ESP SAs]
SPI: 71167994 (0x43deffa)

proposal: ESP-ENCRYPT-AES-256 SHA2-512-256

[Intbound ESP SAs]
SPI: 1488468104 (0x58b83888)
Proposal: ESP-ENCRYPT-AES-256 SHA2-512-256
----End
Configuration Files
#
acl number 3000
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec efficient-vpn easyvpn_1 mode network
pre-shared-key htipl1.,;[-09876543211;'[]
security acl 3000
#
ip address 100.1.1.1 255.255.255.0
#
ip route-static 10.1.2.0 255.255.255.0 100.1.1.2

#
interface Ethernet1/0/0.1
control-vid 1 dot1q-termination
dot1q termination vid 1
ip address 99.1.1.1 255.255.255.0
ipsec efficient-vpn easyvpn_1
arp broadcast enable
#
return

#
acl number 3000
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
#
ipsec efficient-vpn easyvpn_1 mode network
pre-shared-key htipl1.,;[-09876543211;'[]
security acl 3000
#
ip address 100.1.2.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 100.1.2.2

#
interface Ethernet1/0/0.1
control-vid 1 dot1q-termination
dot1q termination vid 1
ip address 99.1.2.1 255.255.255.0
ipsec efficient-vpn easyvpn_1
arp broadcast enable
#
return

Configuration Guide - VPN 4 DSVPN Configuration
4 DSVPN Configuration
About This Chapter
DSVPN can be configured on the source branch, destination branch, and central office routers.
4.1 DSVPN Overview

Dynamic Smart Virtual Private Network (DSVPN) is a technology that allows branches to use
the NBMA Next Hop Resolution Protocol (NHRP) to dynamically establish data forwarding
tunnels in the hub-spoke model.
4.2 DSVPN Features Supported by the AR150/200
Before implementing the DSVPN feature on the AR150/200, consider routing plans and
configure Multipoint GRE (MGRE) tunnel interfaces.
4.3 Configuring DSVPN
When Dynamic Smart VPN (DSVPN) is configured, IPSec does not need to be configured. If
IPSec is configured to protect GRE traffic, the remote IP address in an NHRP mapping entry
needs to be advertised to the local device to establish an IPSec tunnel.
4.4 Maintaining DSVPN
This section describes how to display the DSVPN configuration and clear DSVPN statistics.
This section describes how to configure DSVPN when different routing plans are used.

4.1 DSVPN Overview

Dynamic Smart Virtual Private Network (DSVPN) is a technology that allows branches to use
the NBMA Next Hop Resolution Protocol (NHRP) to dynamically establish data forwarding
tunnels in the hub-spoke model.
In the traditional hub-spoke model, data traffic concentrates at branches and the central office.
If data traffic is transmitted between two branches, to implement IP Security (IPSec), the central
office needs to decrypt data on the tunnel of the source branch and encrypt the data on the tunnel
of the destination branch. Traffic between the two branches needs to pass through the central
office, wasting resources of the central office and causing a delay in traffic forwarding. To solve
this problem, the DSVPN technology is used to enable the two branches to dynamically establish
a data forwarding tunnel.
To enable two branches to directly establish an tunnel, ensure that the next hop of the route
between the two branch subnets is a branch device. The following routing plans are available:
l Static routes are configured on branches.

Static routes to other branch subnets are configured on the source branch so that tunnels
can be established between two branches.
l Branches learn routes from each other.
Routing protocols are enabled to allow routes to be learned between branches, and between
branches and the central office. All the branches must be connected to the same logical
interface of the central office device so that routes can be advertised between branches. If
the Routing Information Protocol (RIP) is enabled, the split horizon function must be
disabled to ensure that routes are directly advertised between branches.
l Branches have only summarized routes to the central office.
If branches need to learn routes from each other, they must have high-performance and
large-capacity devices. To solve this problem and enable branches to directly communicate
with each other, configure the path from a branch to the central office as the default
forwarding path and allow branches to use NHRP packets to exchange routing information.
NOTE
When DSVPN is configured, IPSec does not need to be configured. If IPSec is configured to protect GRE
traffic, the remote IP address in an NHRP mapping entry needs to be advertised to the local device to
establish an IPSec tunnel.
4.2 DSVPN Features Supported by the AR150/200

Before implementing the DSVPN feature on the AR150/200, consider routing plans and
configure Multipoint GRE (MGRE) tunnel interfaces.
When branches learn routes from each other or have only summarized routes to the central office,
perform the following operations to configure DSVPN:
1. Create tunnel interfaces and specify source addresses for tunnel interfaces.
2. Configure routes between AR150/200s.
3. Configure NHRP mapping entries of the central office device on branch devices.

NOTE
The DSVPN function is used with a license. To use the DSVPN function, apply for and purchase the
following license from the Huawei local office:
l AR150&200 DSVPN (Dynamic Smart VPN) Function
4.3 Configuring DSVPN

When Dynamic Smart VPN (DSVPN) is configured, IPSec does not need to be configured. If
IPSec is configured to protect GRE traffic, the remote IP address in an NHRP mapping entry
needs to be advertised to the local device to establish an IPSec tunnel.

Before configuring DSVPN, familiarize yourself with the applicable environment, complete the
pre-configuration tasks, and obtain the data required for configuration. This will help you
complete the configuration task quickly and accurately.
In the traditional hub-spoke model, data traffic concentrates at branches and the central office.
If data traffic is transmitted between two branches, to implement IPSec, the central office needs
to decrypt data on the tunnel of the sending branch and encrypt the data on the tunnel of the
receiving branch. Traffic between the two branches needs to pass through the central office,
wasting resources of the central office and causing a delay in traffic forwarding. To solve this
problem, the DSVPN technology is used to enable the two branches to dynamically establish a
data forwarding tunnel.
Before configuring DSVPN, complete the following task:
l Setting link layer parameters and IP addresses for interfaces so that the network layer
protocol of the interfaces is Up
Data Preparation
To configure DSVPN, you need the following data.
No. Data
1 Numbers, IP addresses, source IP addresses (or source interfaces) of tunnel

interfaces
2 NHRP authentication string, NHRP registration interval, and NHRP entry holding
time
3 (Optional) IPSec profile, IKE peer, and IKE proposal

4.3.2 Configuring MGRE

To configure MGRE, create a tunnel interface, and configure the tunnel encapsulation mode, IP
address, and source address for the tunnel interface.
Context
After creating a tunnel interface, set the tunnel encapsulation mode to Multipoint GRE (MGRE)
and configure a source address for the tunnel interface. To enable the tunnel interface to support
dynamic routing protocols, configure an IP address for the tunnel interface. Perform the
following operations on the routers of branches and the central office.
Procedure
Step 1 Run:
system-view
Step 2 Run:
A tunnel interface is created and the tunnel interface view is displayed.
Step 3 Run:
tunnel-protocol gre p2mp
The tunnel encapsulation mode is set to MGRE.
NOTE
You must configure the tunnel encapsulation mode before setting the source IP address or other parameters
for a tunnel interface. Changing the encapsulation mode of a tunnel interface deletes other parameters of
the tunnel interface.
Step 4 Run:
ip address ip-address { mask | mask-length }
The IP address of the tunnel interface is configured.
Step 5 Run:
The source address or source interface is configured for the tunnel interface.
----End
4.3.3 Configuring Tunnel Routes

To implement DSVPN, configure routes between branches.
Context
The routes passing through a tunnel must be available on branches and the central office so that
packets encapsulated with the MGRE header can be forwarded correctly. These routes can be
static routes or dynamic routes. Perform the following operations on the routers of branches and
the central office.

Procedure
Step 1 Run:
system-view

Step 2 Choose one of the following methods to configure routes passing through a tunnel interface:
l Run:
ip route-static ip-address { mask | mask-length } tunnel interface-number
[ description text ]
A static route is configured.

NOTE
A static route must be configured on both the source and destination devices.
l Configure dynamic routes. Dynamic routing can be implemented using OSPF, RIP, or BGP.
For the configuration of a dynamic routing protocol, see Huawei AR150&200 Series
Configuration Guide - IP Routing.
NOTE
l If OSPF is configured, the OSPF network type of the tunnel interface must be broadcast.
l If RIP is configured, the split horizon function must be disabled on the tunnel interface.
----End
4.3.4 Configuring NHRP on a Branch

This section describes how to configure NHRP mapping entries on a branch device.
Context
NHRP allows a source device on a Non-Broadcast Multiple Access (NBMA) network to obtain
the public address of the next hop to the destination device. Perform the following operations
on the router of a branch.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
The tunnel encryption mode is set to MGRE.

Step 4 Run:
nhrp entry protocol-address nbma-address [ register ]
An NHRP mapping entry is configured.


nhrp authentication string
The NHRP authentication string is configured.

By default, no NHRP authentication string is configured.
nhrp registration interval seconds
The NHRP registration interval is configured.

By default, a branch device registers with the central office device at an interval of 1800 seconds.
nhrp entry holdtime seconds seconds
The holding time of NHRP entries is configured.

By default, the holding time of NHRP entries is 7200 seconds.
Step 8 Run:
nhrp shortcut
The NHRP shortcut function is enabled.

By default, the NHRP shortcut function is disabled.
NOTE
This step is required when branches have only summarized routes to the central office.
----End
4.3.5 Configuring NHRP on the Central Office

This section describes how to configure NHRP mapping entries on the central office device.
Context
NHRP allows a source device on a Non-Broadcast Multiple Access (NBMA) network to obtain
the public address of the next hop to the destination device. Perform the following operations
on the router of the central office.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
The tunnel encryption mode is set to MGRE.


nhrp authentication string
The NHRP authentication string is configured.
By default, no NHRP authentication string is configured.
If the NHRP authentication string is configured only on a branch device but not on the central
office device, the NHRP authentication string is not used for authentication.
Step 5 Run:
nhrp entry multicast dynamic
Dynamically registered branches are added to the NHRP multicast member table.
By default, no dynamically registered branch is added to the NHRP multicast member table.
NOTE
This step is required when branches learn routes from each other.

nhrp entry holdtime seconds seconds
The holding time of NHRP mapping entries is configured.
By default, the holding time of NHRP mapping entries is 7200 seconds.
Step 7 Run:
nhrp registration no-unique
The AR150/200 is configured to override conflicting NHRP mapping entries during NHRP
registration.
By default, the AR150/200 does not override conflicting NHRP mapping entries during NHRP
registration.
Step 8 Run:
nhrp redirect
The NHRP redirect function is enabled.
By default, the NHRP redirect function is disabled.
NOTE
This step is required when branches have only summarized routes to the central office.
----End
4.3.6 (Optional) Configuring an IPSec Profile

An IPSec profile simplifies IPSec policy management.
Context
When DSVPN is configured, IPSec does not need to be configured. If IPSec is configured to
protect GRE traffic, the remote IP address in an NHRP mapping entry needs to be advertised to
the local device to establish an IPSec tunnel. Perform the following operations on the routers of
branches and the central office.

Procedure
Step 1 Run:
system-view
Step 2 Run:
An IPSec profile is created and the IPSec profile view is displayed.
Step 3 Run:
ike peer peer-name
An IKE peer is bound to the IPSec profile.
By default, no IKE peer is bound to any IPSec profile.
NOTE
For the detailed configuration of an IKE peer, see 3.4.4 Configuring an IKE Peer.
Step 4 Run:
An IKE proposal is bound to the IPSec profile.
By default, no IKE proposal is bound to any IPSec profile.
NOTE
For the detailed configuration of an IKE proposal, see 3.4.5 Configuring an IPSec Proposal.
Step 5 Run:
The router is configured to use Perfect Forward Secrecy (PFS) in IPSec negotiation.
By default, PFS is not used in IPSec negotiation.
Step 6 Run:
quit
Step 7 Run:
Step 8 Run:
tunnel-protocol { gre [ p2mp ] | ipsec | ipv4-ipv6 | none }
The tunnel encapsulation mode is configured.
A tunnel interface can be bound to an IPSec profile only when the encapsulation mode of the
tunnel interface is set to IPSec, GRE, or Multipoint GRE (MGRE).
Step 9 Run:

The tunnel interface is bound to an IPSec profile.

----End

After DSVPN is configured, you can view NHRP mapping entries and IPSec profile
configuration.
Prerequisites
All DSVPN configurations are complete.
Procedure
l Run the display nhrp peer command to check NHRP mapping entries.
l Run the display ipsec profile [ brief | name profile-name ] command to check the IPSec
profile configuration.
----End
4.4 Maintaining DSVPN

This section describes how to display the DSVPN configuration and clear DSVPN statistics.
4.4.1 Displaying the DSVPN Configuration

You can run the display commands to check NHRP mapping entries and NHRP packet statistics.
Prerequisites
All DSVPN configurations are complete.
Procedure
l Run the display nhrp peer command to check NHRP mapping entries.
l Run the display nhrp statistics interface interface-type interface-number command to
check NHRP packet statistics.
----End
4.4.2 Clearing DSVPN Statistics

This section describes how to clear NHRP packet statistics.
Context
CAUTION
Statistics cannot be restored after being cleared. Exercise caution when you run the reset
command.

Procedure
l Run the reset nhrp statistics interface interface-type interface-number command in the
user view to clear the NHRP packet statistics on a specified tunnel interface.
----End

This section describes how to configure DSVPN when different routing plans are used.
4.5.1 Example for Configuring DSVPN When Branches Learn

Routes from Each Other
This section describes how to configure DSVPN when branches learn routes from each other.
As shown in Figure 4-1, the hub (central office), Spoke1 (a branch), and Spoke2 (a branch)
belong to the same autonomous system (AS). They can communicate with each other on the IP
network using routing protocols.
Figure 4-1 Configuring DSVPN when branches learn routes from each other
Spoke1
(branch)
Eth1/0/0 44.3.1.2/24
NHRP
Tunnel 0/0/0 Eth1/0/0
172.16.1.101/24 44.1.1.1/24
Internet Hub
NHRP (central office)
Tunnel 0/0/0 NHRP Tunnel 0/0/0
172.16.1.102/24 172.16.1.1/24
Eth1/0/0 44.4.1.2/24
Spoke2
(branch)
1. Run a routing protocol on the Routers to implement interconnection.

2. Create tunnel interfaces on the Routers (Spoke1, Spoke2, and the hub) and specify source
addresses for tunnel interfaces.
3. Configure NHRP mapping entries of the hub on Spoke1 and Spoke2.

Data Preparation
l Reachable routes between the Routers

l Source addresses of tunnel interfaces on the Routers
Procedure
mentioned here.
Step 2 Configure routes between the Routers.
# Configure OSPF on the Ethernet interface of the hub

[Huawei] ospf 2
[Huawei-ospf-2] area 0
[Huawei-ospf-2-area-0.0.0.0] network 44.1.1.0 0.0.0.255
[Huawei-ospf-2-area-0.0.0.0] quit
[Huawei-ospf-2] quit
# Configure OSPF on the Ethernet interface of the Spoke1

[Huawei] ospf 2
[Huawei-ospf-2-area-0.0.0.0]network 44.3.1.0 0.0.0.255
# Configure OSPF on the Ethernet interface of the Spoke2

[Huawei] ospf 2
Step 3 Configure OSPF on the tunnel interfaces.
# Configure hub
[Huawei] ospf 3
# Configure Spoke1
[Huawei] ospf 3
# Configure Spoke2
[Huawei] ospf 3

Step 4 Configure tunnel interfaces on the Routers and configure NHRP mapping entries of the hub on
Spoke1 and Spoke2.
# Configure a tunnel interface on the hub.

[Huawei] system-view
[Huawei-Tunnel0/0/0] ip address 172.16.1.1 255.255.255.0
[Huawei-Tunnel0/0/0] tunnel-protocol gre p2mp
[Huawei-Tunnel0/0/0] source ethernet 1/0/0
[Huawei-Tunnel0/0/0] nhrp entry multicast dynamic
[Huawei-Tunnel0/0/0] ospf network-type broadcast
[Huawei-Tunnel0/0/0] ospf dr-priority 10
# Configure a tunnel interface and an NHRP mapping entry of the hub on Spoke1.
[Huawei-Tunnel0/0/0] nhrp entry 172.16.1.1 44.1.1.1 register
# Configure a tunnel interface and an NHRP mapping entry of the hub on Spoke2.
After the preceding configurations are complete, check the NHRP mapping entries on Spoke1
and Spoke2.
Run the display nhrp peer all command on Spoke1, and the command output is as follows.
[Huawei] display nhrp peer all
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2011.08.18-15:10:26
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Created time : 2011.08.18-15:12:53
Expire time : --
NOTE
If you run the display nhrp peer all command on Spoke1 and Spoke2, you can view only the NHRP
mapping entry of the hub.
On the hub, check the NHRP mapping entries on Spoke1 and Spoke2.

Run the display nhrp peer all command on the hub, and the command output is as follows.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.101 32 44.3.1.2 172.16.1.101 dynamic route tunnel
-------------------------------------------------------------------------------
Created time : 2008.01.07-18:07:45
Expire time : 2008.01.07-20:07:52
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Created time : 2008.01.07-18:11:51
Expire time : 2008.01.07-20:11:57
Step 6 Run the ping command on the spoke.

If you enable Spoke1 and Spoke2 to ping each other, you can see that Spoke1 and Spoke2 have
learned NHRP mapping entries from each other.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Created time : 2011.08.18-15:10:26
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Created time : 2011.08.18-16:09:31
Expire time : 2011.08.18-18:09:31
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Created time : 2011.08.18-15:12:53
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Created time : 2011.08.18-16:10:33
Expire time : 2011.08.18-18:10:33
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.102 32 44.4.1.2 172.16.1.102 dynamic local
-------------------------------------------------------------------------------


Created time : 2011.08.18-16:10:33
Expire time : 2011.08.18-18:10:33
----End
Configuration Files
l Configuration file of Spoke1
#
ip address 44.3.1.2 255.255.255.0
#
ip address 172.16.1.101 255.255.255.0
source Ethernet1/0/0
nhrp entry 172.16.1.1 44.1.1.1 register
ospf network-type broadcast
ospf dr-priority 8
#
ospf 2
area 0.0.0.0
network 44.3.1.0 0.0.0.255
#
ospf 3
area 0.0.0.0
network 172.16.1.0 0.0.0.255
#
return

#
ip address 44.4.1.2 255.255.255.0
#
ip address 172.16.1.102 255.255.255.0
ospf dr-priority 8
#
ospf 2
area 0.0.0.0
network 44.4.1.0 0.0.0.255
#
ospf 3
area 0.0.0.0
network 172.16.1.0 0.0.0.255
#
return
l Configuration file of the hub

#
ip address 44.1.1.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
ospf dr-priority 10
#
ospf 2

area 0.0.0.0
network 44.4.1.0 0.0.0.255
#
ospf 3
area 0.0.0.0
network 172.16.1.0 0.0.0.255
#
return
4.5.2 Example for Configuring DSVPN When Branches Have Only

Summarized Routes to the Central Office
This section describes how to configure DSVPN when branches have only summarized routes
to the central office.
As shown in Figure 4-2, the hub (central office), Spoke1 (a branch), and Spoke2 (a branch)
belong to the same autonomous system (AS). They can communicate with each other on the IP
network using routing protocols.
Figure 4-2 Configuring DSVPN when branches have only summarized routes to the central
office
Spoke1
(branch)
Eth1/0/0 44.3.1.2/24
NHRP
Tunnel 0/0/0 Eth1/0/0
172.16.1.101/24 Internet 44.1.1.1/24 Hub
NHRP (central office)
Tunnel 0/0/0 NHRP Tunnel 0/0/0
172.16.1.102/24 172.16.1.1/24
Eth1/0/0 44.4.1.2/24
Spoke2
(branch)
1. Run a routing protocol on the Routers to implement interconnection.

2. Create tunnel interfaces on the Routers (Spoke1, Spoke2, and the hub) and specify source
addresses for tunnel interfaces.
3. Enable NHRP redirect on the hub and NHRP shortcut on Spoke1 and Spoke2.
4. Configure NHRP mapping entries of the hub on Spoke1 and Spoke2.

Data Preparation
l Reachable routes between the Routers
l Source addresses of tunnel interfaces on the Routers
Procedure
mentioned here.
Step 2 Configure routes between the Routers.
# Configure RIP on the Ethernet interface of the hub
[Huawei] rip
[Huawei-rip-1] network 44.0.0.0
[Huawei-rip-1] version 2
[Huawei-rip-1] quit
# Configure RIP on the Ethernet interface of the Spoke1

[Huawei] rip
[Huawei-rip-1] quit
# Configure RIP on the Ethernet interface of the Spoke2

[Huawei] rip
[Huawei-rip-1] quit
Step 3 Configure RIP on the tunnel interfaces.

# Configure hub
[Huawei] rip 2
[Huawei-rip-1] quit
# Configure Spoke1
[Huawei] rip 2
[Huawei-rip-1] quit
# Configure Spoke2
[Huawei] rip 2
[Huawei-rip-1] quit
Step 4 Configure tunnel interfaces on the Routers and configure NHRP mapping entries of the hub on
Spoke1 and Spoke2.
# Configure a tunnel interface and enable NHRP redirect on the hub.


[Huawei-Tunnel0/0/0] nhrp redirect
[Huawei-Tunnel0/0/0] nhrp entry multicast dynamic
# Configure a tunnel interface and an NHRP mapping entry of the hub, and enable NHRP shortcut
on Spoke1.
[Huawei-Tunnel0/0/0] nhrp shortcut
# Configure a tunnel interface and an NHRP mapping entry of the hub, and enable NHRP shortcut
on Spoke2.
[Huawei-Tunnel0/0/0] nhrp shortcut

After the preceding configurations are complete, check the NHRP mapping entries on Spoke1
and Spoke2.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Created time : 2011.08.18-15:10:26
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Created time : 2011.08.18-15:12:53
Expire time : --
NOTE
If you run the display nhrp peer all command on Spoke1 and Spoke2, you can view only the NHRP
mapping entry of the hub.
On the hub, check the NHRP mapping entries on Spoke1 and Spoke2.
Run the display nhrp peer all command on the hub, and the command output is as follows.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Created time : 2008.01.07-18:07:45
Expire time : 2008.01.07-20:07:52
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Created time : 2008.01.07-18:11:51
Expire time : 2008.01.07-20:11:57
Step 6 Run the ping command on the spoke.
If you enable Spoke1 and Spoke2 to ping each other, you can see that Spoke1 and Spoke2 have
learned NHRP mapping entries from each other.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Created time : 2011.08.18-15:10:26
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Created time : 2011.08.18-16:09:31
Expire time : 2011.08.18-18:09:31
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 44.1.1.1 172.16.1.1 static hub
-------------------------------------------------------------------------------
Created time : 2011.08.18-15:12:53
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Created time : 2011.08.18-16:10:33
Expire time : 2011.08.18-18:10:33
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.102 32 44.4.1.2 172.16.1.102 dynamic local
-------------------------------------------------------------------------------
Created time : 2011.08.18-16:10:33
Expire time : 2011.08.18-18:10:33
----End

Configuration Files
#
ip address 44.3.1.2 255.255.255.0
#
ip address 172.16.1.101 255.255.255.0
nhrp shortcut
#
rip 1
version 2
network 44.0.0.0
#
rip 2
version 2
network 172.16.1.0
#
return

#
ip address 44.4.1.2 255.255.255.0
#
ip address 172.16.1.102 255.255.255.0
nhrp shortcut
#
rip 1
version 2
network 44.0.0.0
#
rip 2
version 2
network 172.16.1.0
#
return
l Configuration file of the hub

#
ip address 44.1.1.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
nhrp redirect
#
rip 1
version 2
network 44.0.0.0
#
rip 2
version 2
network 172.16.1.0
#
return

Configuration Guide - VPN 5 SSL VPN Configuration
5 SSL VPN Configuration
About This Chapter
SSL VPN (Secure Sockets Layer VPN) is a type of secure access VPN technology. Based on
the HTTPS protocol, SSL VPN uses the data encryption, user identity authentication, and
message integrity check mechanisms of the SSL protocol to help ensure that remote access to
enterprise intranets is safe and secure.
5.1 SSL VPN Overview

The SSL VPN (Secure Sockets Layer VPN) technology allows employees, customers, and
partners to access the enterprise's intranet through the Internet anytime and anywhere.
5.2 SSL VPN Features Supported by the AR150/200
The AR150/200 supports the following SSL VPN features: virtual gateway, basic VPN
functions, SSL VPN user management, and SSL VPN services.
5.3 Configuring Basic SSL VPN Functions
The configurations of basic SSL VPN functions include extranet/intranet interfaces and AAA
domain.
5.4 Managing SSL VPN Users
The user management functions include configuring user information, maximum number of
online users, and maximum online duration of users, and forcibly disconnecting users.
5.5 Configuring SSL VPN Services
The AR150/200 supports three service types as an SSL VPN gateway: Web proxy, port
forwarding, and IP forwarding.
This section provides several SSL VPN configuration examples.

5.1 SSL VPN Overview

The SSL VPN (Secure Sockets Layer VPN) technology allows employees, customers, and
partners to access the enterprise's intranet through the Internet anytime and anywhere.
As the Internet technologies develop, people can access an enterprise's internal resources
whether they are at home, at work, or on the move. Enterprise employees, customers, and partners
desire access to enterprises' intranets anywhere and anytime. Unauthorized users or insecure
access hosts may threaten security of enterprises' intranets.
Secure access VPN protects enterprises' intranets against attacks and prevents data theft.
SSL VPN is a type of secure access VPN technology. Based on the HTTPS protocol, SSL VPN
uses the data encryption, user identity authentication, and message integrity check mechanisms
of the SSL protocol to help ensure that remote access to enterprise intranets is safe and secure.
SSL VPN is a remote access technology. As shown in Figure 5-1, SSL VPN meets the following
remote access requirements:
l Dynamic remote access: Users can use any terminals to access an enterprise's intranet
through the Internet anytime and anywhere.
l Differentiated user access privileges: The SSL VPN gateway assigns different access
privileges to employees, partners, and other users on the Internet. Each user can only access
authorized resources.
l Terminals with different operating systems and application programs: Terminals running
different operating systems and application programs can access the enterprise's intranet.
Figure 5-1 Remote access
Home Mobile office
SSL VPN gateway
PC Internet LAN
Internal servers
Partner
Hotel

5.2 SSL VPN Features Supported by the AR150/200

The AR150/200 supports the following SSL VPN features: virtual gateway, basic VPN
functions, SSL VPN user management, and SSL VPN services.
Virtual Gateway
Basic SSL VPN Functions

domain.
l When functioning as an SSL VPN gateway, the AR150/200 provides two types of
interfaces: extranet interface and intranet interface.
An extranet interface connects to the Internet. Users on a virtual gateway can access the
web login page by using the extranet interface address.
An intranet interface connects to an internal server, allowing the virtual gateway to
communicate with the internal server.
l To prevent unauthorized users from accessing internal resources and protect intranet
security, each virtual gateway must authenticate login users. After being bound to an AAA
domain, a virtual gateway performs AAA authentication for all login users. Only the
authenticated users are allowed to access internal resources.
To use an AR150/200 as an SSL VPN gateway, you must configure and enable the basic SSL
VPN functions. If the basic SSL VPN functions are disabled, no user can access internal servers
through the SSL VPN gateway.
SSL VPN User Management

User management functions include:
l Configuring user information

To log in to virtual gateways, each authorized user needs a user name and a password. All
the user names and passwords of the locally authenticated users are stored on virtual
gateways. After a user enters the user name and password, the virtual gateway checks
whether they are identical with the locally stored user name and password of this user. If
they are identical, the virtual gateway allows the user to log in.
l Configuring the maximum number of online users
An administrator can limit the number of online users. When the number of online users
on the virtual gateway exceeds the limit, no more user can log in.
l Configuring the maximum online duration of users
If an online user does not use services for a long time, the user still occupies resources. To
avoid a waste of resources, configure the maximum online duration for users. A user whose
online duration exceeds the limit is logged off forcibly. The virtual gateway still stores
information about the disconnected users.
l Forcibly disconnecting users from virtual gateways

An administrator can disconnect a user by specifying the user's name or ID or disconnect

all users from a virtual gateway. The virtual gateway still stores information about the
disconnected users.
SSL VPN Service

l The Web proxy service is based on the HTTPS protocol. Users access the internal Web
server through the SSL VPN gateway. The SSL VPN gateway functions as a proxy that
forwards data between users and the internal Web server. This function helps ensure that
access to the internal Web server is secure.
l The port forwarding function allows applications to access internal servers using TCP.
Users can access the TCP-based services on the internal network. The typical port
forwarding services include Telnet login, desktop sharing, and mailing.
l The IP forwarding function allows remote terminals to communicate with internal servers
at the network layer. For example, the remote terminals are allowed to ping internal servers.
SSL VPN License

The SSL VPN function is used with a license. To use the SSL VPN function, apply for and
purchase the following license from the Huawei local office:
NOTE
The maximum number of online SSL VPN users is limited by the license. The SSL VPN function has
multiple capacity licenses, which allow different numbers of access users. Select one or more capacity
licenses according to service requirements. The device supports a maximum of two online SSL VPN users
without a license.
5.3 Configuring Basic SSL VPN Functions

domain.

Before configuring basic SSL VPN functions, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the data required for the
configuration. This will help you complete the configuration task quickly and accurately.
domain.
To use an AR150/200 as an SSL VPN gateway, you must configure and enable the basic SSL
VPN functions. If the basic SSL VPN functions are disabled, no user can access internal servers

Before configuring basic SSL VPN functions, complete the following tasks:
l Configuring IP addresses for the interfaces which will be configured as intranet and extranet
interfaces
l Creating the AAA domain that you want to bind to the virtual gateway
Data Preparation
To configure the basic SSL VPN functions, you need the following data.
No. Data
1 Name of the virtual gateway
2 Types and numbers of the interfaces to be configured as intranet and extranet

interfaces
3 AAA domain name to be bound to the virtual gateway
5.3.2 Creating a Virtual Gateway

The AR150/200 functioning as an SSL VPN gateway manages users and services based on
virtual gateways.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
sslvpn gateway gateway-name
A virtual gateway is created and its view is displayed.
By default, no virtual gateway exists on an AR150/200.
----End
5.3.3 Configuring Intranet and Extranet Interfaces

A virtual gateway has an intranet interface and an extranet interface.

Figure 5-2 Interfaces of a virtual gateway
Extranet Intranet
interface interface
Remote terminal
Internet LAN
SSL VPN gateway Internal servers
When functioning as an SSL VPN gateway, the AR150/200 provides two types of interfaces:
extranet interface and intranet interface.
l An extranet interface connects to the Internet. Users on a virtual gateway can access the
web login page by using the extranet interface address.
l An intranet interface connects to an internal server, allowing the virtual gateway to
communicate with the internal server.
NOTE
The intranet and extranet interfaces must be Layer 3 interfaces and have IP addresses.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The virtual gateway view is displayed.

Step 3 Run:
extranet interface interface-type interface-number
The extranet interface is configured.

By default, no extranet interface exists on a virtual gateway.
Step 4 Run:
intranet interface interface-type interface-number
The intranet interface is configured.

By default, no intranet interface exists on a virtual gateway.
----End
5.3.4 Binding an AAA Domain to the Virtual Gateway

To prevent unauthorized users from accessing internal resources and protect intranet security,
each virtual gateway must authenticate login users.

Context
After being bound to an AAA domain, a virtual gateway performs AAA authentication for all
login users. Only the authenticated users are allowed to access internal resources.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
bind domain domain-name
An AAA domain is bound to the virtual gateway.

By default, no AAA domain is bound to a virtual gateway.
For the configuration of an AAA domain, see AAA Configuration in the Huawei AR150&200
Series Enterprise Routers Configuration Guide - Security.
----End
5.3.5 Enabling Basic SSL VPN Functions

After you configure the basic SSL VPN functions, enable them to make the functions effective.
Prerequisites
The following basic SSL VPN configurations have been completed:
l Extranet and intranet interfaces (See 5.3.3 Configuring Intranet and Extranet
Interfaces.)
l AAA domain (See 5.3.4 Binding an AAA Domain to the Virtual Gateway.)
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
enable
The basic SSL VPN functions are enabled.

By default, the basic SSL VPN functions are disabled.
----End

After the configurations of basic SSL VPN functions are complete, you can verify the
configurations.
Procedure
l Run the display sslvpn gateway [ gateway-name ] command to check the virtual gateway
configurations.
----End
5.4 Managing SSL VPN Users

The user management functions include configuring user information, maximum number of
online users, and maximum online duration of users, and forcibly disconnecting users.
User management functions include:
l Configuring user information

To log in to virtual gateways, each authorized user needs a user name and a password. All
the user names and passwords of the locally authenticated users are stored on virtual
gateways. After a user enters the user name and password, the virtual gateway checks
whether they are identical with the locally stored user name and password of this user. If
they are identical, the virtual gateway allows the user to log in.
NOTE
On a configuration terminal, only one user can log in to a virtual gateway.

l Configuring the maximum number of online users
An administrator can limit the number of online users. When the number of online users
on the virtual gateway exceeds the limit, no more user can log in.
NOTE
The number of online SSL VPN users supported by the AR150/200 is limited by the license. The
number of online SSL VPN users that each license support depends on the license level. The
AR150/200 supports a maximum of two online SSL VPN users without a license. To enable the
AR150/200 to support more online SSL VPN users, buy licenses from Huawei local office.
l Configuring the maximum online duration of users
If an online user does not use services for a long time, the user still occupies resources. To
avoid a waste of resources, configure the maximum online duration for users. A user whose
online duration exceeds the limit is logged off forcibly. The virtual gateway still stores
information about the disconnected users.
l Forcibly disconnecting users from virtual gateways
An administrator can disconnect a user by specifying the user's name or ID or disconnect
all users from a virtual gateway. The virtual gateway still stores information about the
disconnected users.

Before configuring user management, complete the following task:
l Creating a virtual gateway
Procedure
Step 1 Run:
system-view

Step 2 Run the following commands to configure the user name and password for logging in to the
virtual gateway:
1. Run the aaa command to enter the AAA view.
2. Run the local-user user-name service-type sslvpn command to set the user type to SSL
VPN user.
3. Run the local-user user-name password { simple | cipher } password command to
configure a password for logging in to the SSL VPN virtual gateway.
4. Run the quit command to return to the system view.
By default, no user name or password is configured on the AR150/200.
Step 3 Run:

max-user number
The maximum number of online users allowed by the virtual gateway is configured.
NOTE
The number of online SSL VPN users supported by the AR150/200 is limited by the license. The number
of online SSL VPN users that each license support depends on the license level. The AR150/200 supports
a maximum of two online SSL VPN users without a license. To enable the AR150/200 to support more
online SSL VPN users, buy licenses from Huawei local office.

max-online-time number
The maximum online duration of users allowed by the virtual gateway is configured.
By default, the maximum online duration of users allowed by the virtual gateway is 120 minutes.
cut user { name user-name | id user-id | all }
Users are forcibly disconnected from the virtual gateway.
----End
Checking the Configuration

After user management configurations are complete, you can verify the configurations.

configurations.
l Run the display sslvpn gateway gateway-name access-user [ user-name ] command to
view user information on the virtual gateway.
5.5 Configuring SSL VPN Services


Before configuring SSL VPN services, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the data required for the configuration. This
will help you complete the configuration task quickly and accurately.
Figure 5-3 Remote access to internal servers using the SSL VPN gateway
Web server
Email
Remote host SSL VPN gateway
Internet Intranet
LAN
SSL tunnel
Internal host FTP server
As shown in Figure 5-3, an SSL VPN gateway is located at an intranet's edge, and works with
the browsers installed on remote terminals or clients downloaded using browsers to protect user
data on the Internet. Additionally, the SSL VPN gateway functions as the proxy to allow users
to access internal servers.
Before configuring an SSL VPN service, complete the following task:
l Creating a virtual gateway
Data Preparation
To configure the SSL VPN serviced, you need the following data.

No. Data
1 Name of the virtual gateway
2 SSL VPN service name
3 Service parameters:
l Web proxy parameters: Web server's URL
l Port forwarding parameters: application server's IP address and port number
l IP forwarding parameters: IP address pool, ACL, routing mode, destination IP
address and mask of user route (for Split mode)
5.5.2 Creating a Virtual Gateway

The AR150/200 functioning as an SSL VPN gateway manages users and services based on
virtual gateways.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
A virtual gateway is created and its view is displayed.

By default, no virtual gateway exists on an AR150/200.
----End
5.5.3 Configuring the Web Proxy Service

The Web proxy service is based on the HTTPS protocol. Users access the internal Web server
Context
Figure 5-4 Web proxy service network
SSL VPN gateway Web server

Remote terminal
Internet LAN

As shown in Figure 5-4, users access the internal Web server through the SSL VPN gateway.
The SSL VPN gateway functions as a proxy that forwards data between users and the internal
Web server. This function helps ensure that access to the internal Web server is secure.
The URL for the internal Web server must be specified so that users can access the Web server.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
service-type web-proxy resource resource-name
The Web proxy service is created and its view is displayed.
By default, the virtual gateway does not provide the Web proxy service.

description description
The description for the Web proxy service is configured.
Step 5 Run:
link url [ web-tunnel ]
A URL is configured for an internal Web server.
By default, an internal Web server does not have a URL.
NOTE
If the Web proxy function on the SSL VPN gateway is invalid, enable the tunnel mode; however, the tunnel
mode lowers security.
----End
5.5.4 Configuring the Port Forwarding Service

The port forwarding function allows applications to access internal servers using TCP.
Context
Figure 5-5 Port forwarding service network
SSL VPN gateway Application server

Remote terminal
Internet LAN

As shown in Figure 5-5, users can access the TCP-based services on the internal network. The
typical port forwarding services include Telnet login, desktop sharing, and mailing.
NOTE
The TCP-based port numbers on the remote terminal and application server must be the same; otherwise,
the port forwarding service will fail.
The IP address and port number of the internal application server must be specified so that users
can access the application server.
To use the port forwarding service, a client software program is automatically downloaded from
the web page to transmit application-layer data through SSL connections. Users do not need to
upgrade their TCP program.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
service-type port-forwarding resource resource-name
The port forwarding service is created and its view is displayed.
By default, the virtual gateway does not provide the port forwarding service.

The description for the port forwarding service is configured.
Step 5 Run:
server ip-address ip-address port port-number
The IP address and port number are configured for the port forwarding service.
By default, no IP address or port number is configured for the port forwarding service.
----End
5.5.5 Configuring the IP Forwarding Service

The SSL VPN gateway allows remote terminals to communicate with internal servers at the
network layer.

Context
Figure 5-6 IP forwarding service network
SSL VPN gateway

Remote terminal Application server
Internet LAN
As shown in Figure 5-6, the SSL VPN gateway allows remote terminals to communicate with
internal servers at the network layer. For example, they can share files.
To use the IP forwarding service, client software specific to the IP forwarding service must be
downloaded from the web page and installed on the terminals. After the client software is
installed, a virtual network adapter is also installed on the terminal. The client software is
responsible for setting up an SSL connection between the terminal and gateway, requesting an
IP address for the virtual network adapter, and creating a route with the virtual network adapter
as outbound interface.
After an IP address pool is bound to the IP forwarding service, an IP address is allocated from
the IP address pool to the terminal.
To limit user access, you can use the bind acl command to apply an ACL to the IP forwarding
service. Alternatively, you can set the routing mode to Split. In the Split mode, a terminal can
only communicate with the servers in the specified network segment.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
service-type ip-forwarding resource resource-name
The IP forwarding service is created and its view is displayed.

By default, the virtual gateway does not provide the IP forwarding service.
The description for the IP forwarding service is configured.

Step 5 Run:
bind ip-pool pool-name
An IP address pool is bound to the IP forwarding service.

By default, no IP address pool is bound to the IP forwarding service.
NOTE
If you configure a lease for the IP addresses in the IP address pool, ensure that the lease is longer than the
maximum online duration of SSL VPN users.

bind acl acl-number
An ACL is bound to the IP forwarding service.
Step 7 (Optional) Set the routing mode.

l Run the route-mode full command to set the routing mode to Full.
l Run the route-mode split command to set the routing mode to Split.
By default, the routing mode is Full.
If you set the routing mode to Split, perform step 8.

route-split ip address ip-address mask { mask-length | mask }
The network segment that users can access is specified.
NOTE
If users close the Internet Explorer when using the IP forwarding service, the running program cannot stop
and routes cannot be restored. In this situation, stop and restart the network adapter.
----End

After the configurations of SSL VPN services are complete, you can verify the service
configurations.
Procedure
configurations.
l Run the display sslvpn gateway gateway-name resource class { web-proxy | port-
forwarding | ip-forwarding } command to check the resources on a virtual gateway.
----End

This section provides several SSL VPN configuration examples.
5.6.1 Example for Configuring the SSL VPN Gateway

This example describes how to control the access privileges of an enterprise's marketing
personnel who access the SSL VPN gateway.

Networking Environment
As shown in Figure 5-7, an enterprise's network connects to the Internet using a Router that
functions as an SSL VPN gateway. The marketing personnel on external networks access the
enterprise's intranet through the Router.
The marketing personnel have the following access requirements:
l Access the internal Web server and mail server, share desktop with the internal host
10.138.10.21, and ping the internal hosts 10.138.10.64-10.138.10.95.
Configure the Router to meet the access requirements of marketing personnel.
Figure 5-7 SSL VPN gateway network
Mail server
Marketing
Eth2/0/0 Vlanif 10
personnel
Intranet
Internet LAN
Router
Desktop
sharing host Web server
l Create a virtual gateway on the Router for marketing personnel and configure resources to
meet the access requirements of marketing personnel.
Data Preparation
l Data on the intranet
Resource Type IP Address Port Number
Web server 10.138.10.1 80
Mail server 10.138.10.3 995
Host for desktop sharing 10.138.10.21 3389
Remote host 10.138.10.32-10.138.10.192 -
l Data on virtual gateways

User Virt Extranet Intranet AAA User Name and Network

Type ual Interfac Interfac Dom Password Segment
Gate e e ain
way
Na
me
Mark mark Ethernet Vlanif10 defau Michael and 10.135.30.

eting et 2/0/0 lt Michael123456 0/24
perso Jessica and
nnel Jessica654321
NOTE
Choose an AAA domain according to service requirements. For the configuration of an AAA domain, see
AAA Configuration in the Huawei AR150&200 Series Enterprise Routers Configuration Guide - Security.
l IP address of extranet interface Ethernet2/0/0: 1.1.1.1/24
l IP address of intranet interface Vlanif10: 10.138.10.254/24
l IP address pool: 10.139.30.0/24
NOTE
Before configuring the SSL VPN gateway, configure the Router as an HTTPS server and ensure that reachable
routes exist between Router, internal servers, and terminals.
Procedure
Step 1 Configure an IP address pool.
[Huawei] sysname Router
[Router] ip pool market_pool
[Router-ip-pool-company_pool] network 10.139.30.0 mask 24
[Router-ip-pool-company_pool] quit
Step 2 Create a virtual gateway named market.
[Router] sslvpn gateway market
Step 3 Configure the intranet/extranet interfaces and bind an AAA domain to the virtual gateway.
[Router-sslvpn-market] extranet interface ethernet 2/0/0

[Router-sslvpn-market] intranet interface vlanif 10
[Router-sslvpn-market] bind domain default
[Router-sslvpn-market] enable
[Router-sslvpn-market] quit
Step 4 Configure user information.
[Router] aaa
[Router-aaa] local-user liming service-type sslvpn
[Router-aaa] local-user liming password cipher liming123456
[Router-aaa] local-user wangjun service-type sslvpn
[Router-aaa] local-user wangjun password cipher wangjun654321
[Router-aaa] quit
Step 5 Configure SSL VPN services.

# Configure the Web proxy service.
[Router] sslvpn gateway market

[Router-sslvpn-market] service-type web-proxy resource market_web-proxy
[Router-sslvpn-market-wp-res-market_web-proxy] link http://10.138.10.1:80/
[Router-sslvpn-market-wp-res-market_web-proxy] quit
# Configure the port forwarding service to allow marketing personnel to access the mail server
and share desktop with the internal host 10.138.10.21.
[Router-sslvpn-market] service-type port-forwarding resource market_port-

forwarding
[Router-sslvpn-market-pf-res-market_port-forwarding] server ip-address 10.138.10.3
port 995
[Router-sslvpn-market-pf-res-market_port-forwarding] server ip-address
10.138.10.21 port 3389
[Router-sslvpn-market-pf-res-market_port-forwarding] quit
# Configure the IP forwarding service to allow marketing personnel to ping the internal hosts
10.138.10.64-10.138.10.95.
[Router-sslvpn-market] service-type ip-forwarding resource market_ip-forwarding

[Router-sslvpn-market-if-res-market_ip-forwarding] bind ip-pool market_pool
[Router-sslvpn-market-if-res-market_ip-forwarding] route-mode split
[Router-sslvpn-market-if-res-market_ip-forwarding] route-split ip address
10.138.10.64 mask 27
[Router-sslvpn-market-if-res-market_ip-forwarding] quit
[Router-sslvpn-market] quit

Open the Internet Explorer on the terminal, such as a computer, and enter https://1.1.1.1/sslvpn
to access the login page. Enter the user name and password, and select the virtual gateway
market. After authentication, you can see a resource list on the Web page, including the Web
server, mail server, and host for desktop sharing, and ping the hosts on
10.138.10.64-10.138.10.95.
----End
Configuration Files
#
sysname Router
#
aaa
local-user liming password cipher !9$"OZ$+1"-',917]_2Y71!!
local-user liming service-type sslvpn
local-user wangjun password cipher =S@P;D^[S_2)S(YTABR0IQ!!
local-user wangjun service-type sslvpn
#
interface Ethernet 2/0/0
ip address 1.1.1.1 255.255.255.0
#
interface Vlanif 10
ip address 10.138.10.254 255.255.255.0
#
ip pool company_pool
network 10.139.30.0 mask 24
#
sslvpn gateway market
extranet interface ethernet 2/0/0
intranet interface vlanif 10
bind domain default

service-type web-proxy resource market_web-proxy

link http://10.138.10.1:80/
service-type port-forwarding resource market_port-forwarding
server ip-address 10.138.10.3 port 995
server ip-address 10.138.10.21 port 3389
service-type ip-forwarding resource market_ip-forwarding
bind ip-pool market_pool
route-mode split
route-split ip address 10.138.10.64 mask 27
#
return


Configuration Guide - VPN Huawei

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuration Guide - VPN Huawei

Uploaded by

Copyright:

Available Formats

Huawei AR150&200 Series Enterprise Routers

Configuration Guide - VPN

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2012-03-30) Huawei Proprietary and Confidential i

About This Document

This document describes how to configure the VPN.

This document is intended for:

l Data configuration engineers

Indicates a hazard with a high level of risk, which if not

Indicates a hazard with a medium or low level of risk, which

Indicates a potentially hazardous situation, which if not

NOTE Provides additional information to emphasize or supplement

Issue 02 (2012-03-30) Huawei Proprietary and Confidential ii

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by vertical

[ x | y | ... ] Optional items are grouped in brackets and separated by vertical

{ x | y | ... }* Optional items are grouped in braces and separated by vertical

[ x | y | ... ]* Optional items are grouped in brackets and separated by vertical

# A line starting with the # sign is comments.

Interface Numbering Conventions

Changes in Issue 02 (2012-03-30)

Changes in Issue 01 (2011-12-30)

Issue 02 (2012-03-30) Huawei Proprietary and Confidential iii

About This Document.....................................................................................................................ii

Issue 02 (2012-03-30) Huawei Proprietary and Confidential iv

2.3.1 Establishing the Configuration Task.......................................................................................................42

Issue 02 (2012-03-30) Huawei Proprietary and Confidential v

3.4.7 Configuring an IPSec Policy Template...................................................................................................88

Issue 02 (2012-03-30) Huawei Proprietary and Confidential vi

5 SSL VPN Configuration...........................................................................................................153

Issue 02 (2012-03-30) Huawei Proprietary and Confidential vii

About This Chapter

1.1 Introduction to GRE

Issue 02 (2012-03-30) Huawei Proprietary and Confidential 1

1.1 Introduction to GRE

1.2 GRE Features Supported by the AR150/200

Enlarging the Operation Scope of the Network Running a Hop-Limited Protocol

Figure 1-1 Networking diagram of enlarged network operation scope

Issue 02 (2012-03-30) Huawei Proprietary and Confidential 2

Figure 1-2 Networking diagram of GRE-IPSec tunnel application

1.3 Configuring GRE

1.3.1 Establishing the Configuration Task

1 Number of the tunnel interface

2 Source address and destination address of the tunnel

Issue 02 (2012-03-30) Huawei Proprietary and Confidential 3

3 IP address of the tunnel interface

4 Key of the tunnel interface

1.3.2 Configuring a Tunnel Interface

The system view is displayed.

A tunnel interface is created and the tunnel interface view is displayed.

The tunnel is encapsulated with GRE.

The source address or source interface of the tunnel is configured.

The destination address of the tunnel is configured.

The Maximum Transmission Unit (MTU) of the tunnel interface is modified.

Issue 02 (2012-03-30) Huawei Proprietary and Confidential 4

1.3.3 Configuring Routes for the Tunnel

The system view is displayed.

Issue 02 (2012-03-30) Huawei Proprietary and Confidential 5

Figure 1-3 Diagram of configuring the GRE dynamic routing protocol

RouterA Tunnel RouterC