Professional Documents
Culture Documents
V200R002C00
Issue 02
Date 2012-03-30
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.
Website: http://www.huawei.com
Email: support@huawei.com
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.
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
&<1-n> The parameter before the & sign can be repeated 1 to n times.
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Contents
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
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.1 Establishing the Configuration Task.......................................................................................................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.3.6 Checking the Configuration.....................................................................................................................81
3.4 Establishing an IPSec Tunnel Through IKE Negotiation.................................................................................81
3.4.1 Establishing the Configuration Task.......................................................................................................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
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.3.7 Checking the Configuration...................................................................................................................142
4.4 Maintaining DSVPN.......................................................................................................................................142
4.4.1 Displaying the DSVPN Configuration..................................................................................................142
4.4.2 Clearing DSVPN Statistics....................................................................................................................142
4.5 Configuration Examples.................................................................................................................................143
4.5.1 Example for Configuring DSVPN When Branches Learn Routes from Each Other............................143
4.5.2 Example for Configuring DSVPN When Branches Have Only Summarized Routes to the Central Office
........................................................................................................................................................................148
1 GRE Configuration
Generic Routing Encapsulation (GRE) encapsulates the packets of certain network layer
protocols so that the encapsulated packets can be transmitted over the IPv4 network.
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.
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.
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
No. Data
Context
Perform the following steps on the routers at the two ends of a tunnel.
Procedure
Step 1 Run:
system-view
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 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
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
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.
Backbone
Eth1/0/0 Eth2/0/0
PC1 PC2
----End
Context
Perform the following steps on the routers at two ends of a tunnel.
Procedure
Step 1 Run:
system-view
NOTE
Step 3 and Step 4 can be performed in random order.
----End
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
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
20.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
40.1.1.0/24 Direct 0 0 D 40.1.1.1 Tunnel0/0/2
40.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
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
Reply from 40.1.1.2: bytes=56 Sequence=2 ttl=255 time=33 ms
Reply from 40.1.1.2: bytes=56 Sequence=3 ttl=255 time=48 ms
Reply from 40.1.1.2: bytes=56 Sequence=4 ttl=255 time=33 ms
Reply from 40.1.1.2: bytes=56 Sequence=5 ttl=255 time=36 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
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.
Pre-configuration Tasks
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
Context
Perform the following steps on the router that requires the Keepalive function.
Procedure
Step 1 Run:
system-view
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
Prerequisites
The Keepalive function is enabled on the GRE tunnel.
Procedure
Step 1 Run:
system-view
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.
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
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
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
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
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.
10.1.1.1/24 10.2.1.1/24
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data:
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
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 12 Routes : 12
# Configure Router C.
[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
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
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
Reply from 40.1.1.2: bytes=56 Sequence=2 ttl=255 time=33 ms
Reply from 40.1.1.2: bytes=56 Sequence=3 ttl=255 time=48 ms
Reply from 40.1.1.2: bytes=56 Sequence=4 ttl=255 time=33 ms
Reply from 40.1.1.2: bytes=56 Sequence=5 ttl=255 time=36 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
# Configure Router C.
[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.
Take Router A as an example:
[RouterA] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 16 Routes : 16
----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
#
interface Ethernet0/0/8
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
#
interface Ethernet1/0/0
ip address 20.1.1.2 255.255.255.0
#
interface Ethernet2/0/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
#
interface Ethernet0/0/1
port link-type access
port default vlan 11
#
interface Ethernet0/0/8
ip address 30.1.1.2 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
Networking Requirements
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
AR150/200 is RouterA, or RouterC.
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
Configuration Roadmap
The configuration roadmap is as follows:
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
To complete the configuration, you need the following data:
l Source address and destination address of the GRE tunnel
l IP addresses of the interfaces on both ends of the GRE tunnel
Procedure
Step 1 Assign an IP address to each interface.
Assign an IP address to each interface as shown in Figure 1-6. The specific configuration is not
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.
# Configure Router A.
[RouterA] ospf 2
[RouterA-ospf-2] area 0
[RouterA-ospf-2-area-0.0.0.0] network 40.1.1.0 0.0.0.255
[RouterA-ospf-2-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-2-area-0.0.0.0] quit
[RouterA-ospf-2] quit
# Configure Router C.
[RouterC] ospf 2
[RouterC-ospf-2] area 0
[RouterC-ospf-2-area-0.0.0.0] network 40.1.1.0 0.0.0.255
[RouterC-ospf-2-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[RouterC-ospf-2-area-0.0.0.0] quit
[RouterC-ospf-2] quit
----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
#
interface Ethernet0/0/8
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
#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
Networking Requirements
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
AR150/200 is RouterA, or RouterC.
10.1.1.1/24 10.2.1.1/24
Configuration Roadmap
The configuration roadmap is as follows:
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
To complete the configuration, you need the following data:
l Data for configuring the routing protocol for the backbone network
l Source address and destination address of the GRE tunnel
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.
# Configure Router C.
[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
[RouterC-Tunnel0/0/1] quit
# Configure Router C.
[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
[RouterC-Tunnel0/0/1] quit
# 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.
# Configure Router A.
# Configure Router C.
[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
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.
# Configure Router A.
[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
# Configure Router C.
[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.
# Configure Router A.
[RouterA] ip route-static 10.2.1.0 255.255.255.0 tunnel 0/0/1
# Configure Router C.
[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
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
===============================
Interface: Ethernet0/0/8
Path MTU: 1500
===============================
-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Mode : ISAKMP
-----------------------------
Connection ID : 2
Encapsulation mode: Tunnel
Tunnel local : 30.1.1.2
Tunnel remote : 20.1.1.1
----End
Configuration Files
l Configuration file of Router A
#
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
#
interface Ethernet0/0/1
port link-type access
port default vlan 11
#
interface Ethernet0/0/8
ip address 20.1.1.1 255.255.255.0
ipsec policy policy1
#
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
pim dm
#
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
#
interface Ethernet1/0/0
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
l Configuration file of Router C
#
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
#
interface Ethernet0/0/1
port link-type access
Networking Requirements
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
Configuration Roadmap
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.
The configuration roadmap is as follows:
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
To complete the configuration, you need the following data:
l IP addresses of the interfaces, process ID of the routing protocol, and AS number
l Source address and destination address of the GRE tunnel
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] interface tunnel0/0/1
[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
# 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] interface tunnel0/0/1
[PE1-Tunnel0/0/1] isis enable 50
[PE1-Tunnel0/0/1] quit
# Configure CE2.
[CE2] isis 50
[CE2-isis-50] network-entity 50.0000.0000.0004.00
[CE2-isis-50] quit
[CE2] interface ethernet1/0/0
[CE2-Ethernet1/0/0] isis enable 50
[CE2-Ethernet1/0/0] quit
[CE2] interface ethernet2/0/0
[CE2-Ethernet2/0/0] isis enable 50
[CE2-Ethernet2/0/0] 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.
# 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
# Configure PE2.
[PE2] isis 50
[PE2-isis-50] import-route bgp
----End
Configuration Files
l Configuration file of CE1
#
sysname CE1
#
isis 50
network-entity 50.0000.0000.0001.00
#
interface Ethernet0/0/8
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
#
interface Ethernet0/0/1
port link-type access
port default vlan 11
#
interface Tunnel0/0/1
ip address 2.2.2.1 255.255.255.0
tunnel-protocol gre
source 30.1.1.1
destination 50.1.1.2
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
#
interface Ethernet1/0/0
ip address 30.1.1.2 255.255.255.0
#
interface Ethernet2/0/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
#
interface Ethernet1/0/0
ip address 50.1.1.2 255.255.255.0
#
interface Ethernet2/0/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
#
interface Tunnel0/0/1
ip binding vpn-instance vpn1
ip address 2.2.2.2 255.255.255.0
tunnel-protocol gre
source 50.1.1.2
destination 30.1.1.1
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
#
interface Ethernet1/0/0
ip address 110.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Ethernet2/0/0
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
Networking Requirements
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
AR150/200 is RouterA, or RouterC.
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
Configuration Roadmap
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
To complete the configuration, you need the following data:
l Data for configuring the routing protocol for the backbone network
l Source address and destination address of the GRE tunnel
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] source 20.1.1.1
[RouterA-Tunnel0/0/1] destination 30.1.1.2
[RouterA-Tunnel0/0/1] keepalive period 20 retry-times 3
[RouterA-Tunnel0/0/1] quit
# 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
l Configuration file of Router A
#
sysname RouterA
#
interface Ethernet0/0/8
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
keepalive period 20
#
return
source 30.1.1.2
destination 20.1.1.1
keepalive period 20
#
return
2 L2TP Configuration
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.
LAC
PSTN/ Network
Remote ISDN
system
LNS
Internal
server
Network
PC LAN
LAC
LNS
Internal
server
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.
Applicable Environment
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).
Pre-configuration Tasks
None
Data Preparation
To configure basic L2TP functions, you need the following data.
No. Data
2 Names of the tunnels on the LAC side and the LNS side
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
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
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
Applicable Environment
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.
Pre-configuration Tasks
Before configuring the LAC, complete the following tasks:
Data Preparation
To configure the LAC, you need the following data.
No. Data
4 Interface type and interface number used to initiate the request for tunnel establishment
No. Data
Context
Do as follows on the router:
Procedure
Step 1 Run:
system-view
----End
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
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 }
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
packets from users are sent out from the LAC through the PPP interface and reach the LNS
through an L2TP tunnel.
----End
Context
NOTE
For more information about Authorization, Authentication and Accounting (AAA), refer to the Huawei
AR150&200 Series Enterprise Routers Configuration Guide - Security.
Procedure
Step 1 Run:
system-view
Step 2 Run:
aaa
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
Procedure
l Creating the Authentication and Accounting (AAA) Scheme
Do as follows on the router:
1. Run:
system-view
An accounting scheme is created and the view of the accounting scheme is displayed.
NOTE
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 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
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
-----------------------------------------------
Applicable Environment
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.
Pre-configuration Tasks
Before configuring the LNS, you need to complete the following tasks:
Data Preparation
To configure LNS, you need the following data.
No. Data
Context
Do as follows on LNS:
Procedure
Step 1 Run:
system-view
Step 2 Run:
l2tp-group group-number
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
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 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.
----End
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
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
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
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
LocalSID RemoteSID LocalTID
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
-----------------------------------------------
Applicable Environment
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.
Pre-configuration Tasks
None
Data Preparation
To adjust the L2TP connection, you need the following data.
No. Data
Context
Do as follows on the LNS side or the LAC:
Procedure
Step 1 Run:
system-view
NOTE
If tunnel authentication is enabled on one end (either the LAC or the LNS), the peer must be enabled with
tunnel authentication.
----End
Context
Do as follows on the LNS or the LAC:
Procedure
Step 1 Run:
system-view
Step 3 Run:
tunnel timer hello interval
----End
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
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
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
Networking Requirements
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.
Modem
Internet
Configuration Roadmap
The configuration roadmap is as follows:
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
To complete the configuration, you need the following data:
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.
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.
# 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
# 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
# # 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
Total tunnel = 1
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
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
LocalSID RemoteSID LocalTID
2036 1469 1
In this manner, VPN users can access the server in the headquarters.
----End
Configuration Files
l Configuration file of Router A
#
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
l Configuration file of Router B
#
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
Networking Requirements
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.
Internet
PSTN/ISDN
Tunnel
VPN RouterA
Client NAS Headquarters
LNS
Configuration Roadmap
The procedure for a user to access the headquarters is as follows:
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
To complete the configuration, you need the following data:
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
l Number, range, and address mask of the remote address pool
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
# 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
# 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
Total tunnel = 1
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
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
LocalSID RemoteSID LocalTID
1469 2036 1
In this manner, the VPN user can access the network of the headquarters.
----End
Configuration Files
NOTE
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
Networking Requirements
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.
Server
Headquarters
Tunnel
Configuration Roadmap
The configuration roadmap is as follows:
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
To complete the configuration, you need the following data:
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
l Number, range, and address mask of the remote address pool
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.
<Huawei> system-view
[Huawei] sysname RouterA
[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
# 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
[RouterA-l2tp1] quit
# 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
Run the display l2tp session command. You can find that the session is set up. For example:
[RouterA] display l2tp session
Total session = 1
LocalSID RemoteSID LocalTID
1576 1036 1
----End
Configuration Files
The configuration file of the LNS is as follows:
NOTE
Networking Requirements
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.
Configuration Roadmap
The configuration roadmap is as follows:
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
To complete the configuration, you need the following data:
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.
<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 12.1.1.2 255.255.255.0
[RouterA-Serial1/0/0] quit
# 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 the user name and password, authentication mode, and IP address for the virtual
PPP user.
[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ppp pap local-user huawei password simple 123
[RouterA-Virtual-Template1] ip address 13.1.1.2 255.255.255.0
[RouterA-Virtual-Template1] quit
# 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
# Set the local and remote device names for the LNS.
[RouterB-l2tp1] tunnel name LNS
[RouterB-l2tp1]allow l2tp virtual-template 1 remote LAC
# 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
Total tunnel = 1
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
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
LocalSID RemoteSID LocalTID
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
authentication-scheme default
authorization-scheme default
accounting-scheme default
domain default
local-user huawei password simple 123
local-user huawei service-type ppp
#
interface Virtual-Template1
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
3 IPSec Configuration
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.
Mode
transport
Protocol
AH IP Header AH TCP Header data
AH-ESP IP Header AH ESP TCP Header data ESP Tail ESP Auth data
Mode
tunnel
Protocol
AH-ESP new IP Header AH ESPraw IP Header TCP Header data ESP TailESP Auth data
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
Applicable 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.
Pre-configuration Tasks
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
4 Type and number of the interface to which the IPSec policy is applied
NOTE
Procedure
Step 1 Run:
system-view
Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto } ]
Step 3 Run:
rule
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
Procedure
Step 1 Run:
system-view
----End
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
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
NOTE
Step 9 Run:
sa authentication-hex { inbound | outbound } { ah | esp } hex-key
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
NOTE
----End
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
----End
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
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.
Pre-configuration Tasks
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
l Configuring routes between the source and the destination
Data Preparation
To establish an IPSec tunnel through IKE negotiation, you need to the following data.
No. Data
3 IKE peer name, negotiation mode, IKE proposal name, IKE peer ID type, pre-
shared key, remote address, and remote host name
5 Name and sequence number of the IPSec policy, (optional) Perfect Forward
Secrecy (PFS) feature used in IKE negotiation
8 Type and number of the interface to which the IPSec policy is applied
NOTE
Procedure
Step 1 Run:
system-view
Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto }]
Step 3 Run:
rule
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
Procedure
Step 1 Run:
system-view
Step 2 Run:
ike proposal proposal-number
The IKE negotiation succeeds only when the two ends use the IKE proposals with the same
settings.
----End
Procedure
Step 1 Run:
system-view
By default, the IP address of the local end is used as the local ID.
By default, the local end address is the IP address of the interface bound to the IPSec policy.
By default, the IP address of the local end is used as the local ID.
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.
Step 10 Run:
remote-address { ip-address | host-name }
NOTE
In the IPSec policy template mode, you do not need to run the remote-address command.
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.
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.
Step 13 (Optional) Run:
inband ocsp
The Online Certificate Status Protocol (OCSP) is enabled for the IKE peer.
Step 14 (Optional) Run:
pki realm realm-name
----End
Procedure
Step 1 Run:
system-view
----End
Procedure
Step 1 Run:
system-view
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.
Step 6 (Optional) Run:
sa duration { traffic-based kilobytes | time-based interval }
NOTE
For details on how to configure an IKE peer, see 3.4.4 Configuring an IKE Peer.
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
Procedure
Step 1 Run:
system-view
Step 4 Run:
proposal proposal-name
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 6 Run:
ike-peer peer-name
The Perfect Forward Secrecy (PFS) feature used in the negotiation is configured.
----End
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipsec sa global-duration { time-based interval | traffic-based kilobytes }
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
Step 4 Run:
ike heartbeat-timer timeout interval
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
Step 6 Run:
ipsec anti-replay { enable | disable }
Step 7 Run:
ipsec df-bit { clear | set | copy }
Step 8 Run:
ipsec fragmentation before-encryption
Step 9 Run:
ike peer
Step 10 Run:
local-address address
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 }
----End
Procedure
Step 1 Run:
system-view
----End
Procedure
Step 1 Run:
system-view
After IKE negotiation succeeds and the SA is established, the data flows are encrypted and then
transmitted between two ends.
----End
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
Applicable Environment
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.
Pre-configuration Tasks
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
l Configuring routes between the source and the destination
Data Preparation
To establish an IPSec tunnel using an IPSec tunnel interface, you need the following data.
No. Data
2 IKE peer name, negotiation mode, IKE proposal name, IKE peer ID type, pre-
shared key
4 Number, IP address, and source and destination IP addresses of the IPSec tunnel
interface
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
proposal proposal-name
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
NOTE
For details on how to configure an IKE peer, see 3.4.4 Configuring an IKE Peer.
By default, an IPSec profile does not reference any Diffie-Hellman group during negotiation.
Step 7 Run:
quit
By default, the global SA lifetime represented by time is 3600 seconds; the global SA lifetime
represented by traffic volume is 1843200 kilobytes.
----End
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:
interface tunnel interface-number
Step 3 Run:
ip address
Step 4 Run:
tunnel-protocol { gre [ p2mp ] | ipsec | ipv4-ipv6 | none }
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:
source { source-ip-address | interface-type interface-number }
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.
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:
ipsec profile profile-name
----End
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
Applicable Environment
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
l Configuring routes between the source and the destination
Data Preparation
To configure the Efficient VPN policy, you need the following data.
No. Data
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
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
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 }
6. (Optional) Run:
pre-shared-key key
An allocable network segment address is specified for the global address pool.
4. Run:
quit
The location of the IP address pool is specified in the AAA service scheme.
NOTE
The DH group used in IKE negotiation must be set to dh group2 for an efficient-vpn policy.
15. Run:
quit
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
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
----End
Context
Perform the following steps on the routers on the remote device and server:
Procedure
Step 1 Run:
system-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:
security acl acl-number
Step 7 Run:
remote-address { ip-address | host-name } { v1 | v2 }
NOTE
----End
Prerequisites
All Efficient VPN configurations are complete.
Procedure
l Run the display ike sa [ v2 ] [ conn-id connid | peer-name peername | phase phase-
number | verbose ] command to check information about the IPSec tunnel established
through IKE negotiation.
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | profile
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
Prerequisites
The configurations of IPSec are complete.
Procedure
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | profile
profile-name | peerip peer-ip-address ] command to check information about the IPSec
SA.
l Run the display ike sa [ v2 ] [ conn-id connid | peer-name peername | phase phase-
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
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
Networking Requirements
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.
RouterA RouterB
Internet
IPSec Tunnel
PC A 10.1.1.2/24 PC B
10.1.2.2/24
Configuration Roadmap
The configuration roadmap is as follows:
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> system-view
[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
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 a static route to the peer on RouterB. In this example, the next hop to PCA is
202.138.162.2.
[Huawei] ip route-static 10.1.1.0 255.255.255.0 202.138.162.2
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
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] interface ethernet 1/0/0
[Huawei-Ethernet1/0/0] ipsec policy map1
[Huawei-Ethernet1/0/0] quit
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.
-----------------------------
IPsec policy name: "map1"
Sequence number: 10
Acl Group: 3101
Acl rule: 0
Mode: Manual
-----------------------------
Encapsulation mode: Tunnel
Tunnel local : 202.138.163.1
Tunnel remote: 202.138.162.1
----End
Configuration Files
l Configuration file of RouterA
#
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
#
Networking Requirements
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
RouterA RouterB
Internet
IPSec Tunnel
PC A 10.1.1.2/24 PC B
10.1.2.2/24
Configuration Roadmap
The configuration roadmap is as follows:
Procedure
Step 1 Configure IP addresses for the interfaces on RouterA and RouterB.
Step 2 Configure local IDs and IKE peers on RouterA and RouterB.
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.
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
----------------------------------------
Step 3 Configure ACLs on RouterA and RouterB to define the data flows to be protected.
# 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.
[Huawei] ip route-static 10.1.1.0 255.255.255.0 202.138.162.2
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
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
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
Step 7 Apply the IPSec policies to the interfaces of RouterA and RouterB.
# Apply the IPSec policy to the interface of RouterA.
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
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
sa remaining key duration (bytes/sec): 1887436464/3575
max sent sequence-number: 5
udp encapsulation used for nat traversal: N
----End
Configuration Files
l Configuration file of RouterA
#
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
#
ike peer spub
v1
pre-shared-key
huawei
remote-address
202.138.162.1
#
ipsec policy map1 10
isakmp
security acl
3101
ike-peer
spub
proposal
tran1
#
Networking Requirements
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.
RouterA RouterB
Internet
IPSec Tunnel
PC A 10.1.1.2/24 PC B
10.1.2.2/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses for interfaces.
2. Configure an IKE proposal.
3. Specify the local host ID and IKE peer for IKE negotiation.
4. Configure Access Control Lists (ACLs) and define the data flows to be protected.
5. Configure static routes to peers.
6. Configure an IPSec proposal.
7. Configure IPSec policies and apply the ACLs and IPSec proposal to the IPSec policies.
8. 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> system-view
[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
Step 3 Configure local IDs and IKE peers on RouterA and RouterB.
# Configure the local ID and IKE peer on RouterA.
[Huawei] ike local-name huawei01
[Huawei] ike peer spub v1
[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] pre-shared-key huawei
[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
[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.
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 : aggressive on phase 1
Pre-shared-key : huawei
Proposal : 1
Local ID type : Name
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 : 202.138.163.1
Step 4 Configure ACLs on RouterA and RouterB to define the data flows to be protected.
# 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.
[Huawei] ip route-static 10.1.1.0 255.255.255.0 202.138.162.2
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
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
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
Step 8 Apply the IPSec policies to the interfaces of RouterA and RouterB.
# Apply the IPSec policy to the interface of RouterA.
[Huawei] interface ethernet 1/0/0
[Huawei-Ethernet1/0/0] ipsec policy map1
[Huawei-Ethernet1/0/0] quit
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
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)
----End
Configuration Files
l Configuration file of RouterA
#
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
#
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
#
ipsec policy map1 10
isakmp
security acl
3101
ike-peer
spub
proposal
tran1
#
#
return
Networking Requirements
As shown in Figure 3-6, an IPSec tunnel is established between RouterA and RouterB to protect
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
Configuration Roadmap
The configuration roadmap is as follows:
1. Assign IP addresses to interfaces.
2. Configure static routes to peers.
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
Step 1 Configure IP addresses for the interfaces on RouterA and RouterB.
# Assign an IP address to the interface of RouterA.
<Huawei> system-view
[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
# Configure a static route to the remote peer on RouterB. This example assumes that the next
hop address in the route to RouterB is 202.138.162.2.
[Huawei] ip route-static 10.1.1.0 255.255.255.0 202.138.162.2
Step 4 Configure local IDs and IKE peers on RouterA and RouterB.
# Configure the local ID and IKE peer on RouterA.
[Huawei] ike peer spub v2
[Huawei-ike-peer-spub] ike-proposal 1
[Huawei-ike-peer-spub] pre-shared-key huawei
[Huawei-ike-peer-spub] 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
Pre-shared-key : huawei
proposal : 1
Local ID type :
DPD : Disable
DPD mode : Periodic
DPD idle time : 30
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
Step 7 Apply the IPSec profiles to the interfaces of RouterA and RouterB.
# Apply the IPSec profile to the interface of RouterA.
[Huawei] interface tunnel 0/0/0
----End
Configuration Files
l Configuration file of RouterA
#
ipsec proposal tran1
transform ah-esp
ah authentication-algorithm sha1
esp authentication-algorithm sha1
esp encryption-algorithm 3des
#
#
ike peer spub v2
pre-shared-key huawei
ike-proposal 1
#
ipsec profile profile1
ike-peer spub
proposal tran1
#
interface Tunnel0/0/0
ip address 192.168.1.1 255.255.255.0
tunnel-protocol gre
source 202.138.163.1
destination 202.138.163.2
ipsec profile profile1
#
interface Ethernet1/0/0
ip address 202.138.163.1 255.255.255.0
#
return
#
ike peer spua v2
pre-shared-key huawei
ike-proposal 1
#
ipsec profile profile2
ike-peer spua
proposal tran1
#
interface Tunnel0/0/0
ip address 192.168.1.2 255.255.255.0
tunnel-protocol gre
source 202.138.162.1
destination 202.138.163.1
ipsec profile profile2
#
interface Ethernet1/0/0
ip address 202.138.162.1 255.255.255.0
#
return
Networking Requirements
As shown in Figure 3-7, 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). 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
IPSec Tunnel
10.1.1.2/24 10.1.2.2/24
PC A PC B
Configuration Roadmap
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:
1. Assign an IP address to an interface.
2. Configure a static route.
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.
<Huawei> system-view
[Huawei] interface ethernet 1/0/0
[Huawei-Ethernet1/0/0] ip address 60.1.1.1 255.255.255.0
[Huawei-Ethernet1/0/0] quit
2. Configure a static route to the remote peer on RouterA. This example assumes that the next
hop address in the route to RouterB is 60.1.1.2.
[Huawei] ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
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.
[Huawei] ip route-static 10.1.1.0 255.255.255.0 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
Run the display ike sa command on RouterA, and the following information is displayed:
[Huawei] display ike sa v2
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
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
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
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.
[Huawei] display ipsec sa
===============================
Interface: Ethernet 1/0/0
Path MTU: 1500
===============================
-----------------------------
IPSec efficient-vpn name: "2"
Mode: EFFICIENTVPN-CLIENT MODE
-----------------------------
Connection ID : 64
Encapsulation mode: Tunnel
Tunnel local : 60.1.1.1
Tunnel remote : 60.1.2.1
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
SA remaining key duration (bytes/sec): 1887436800/1390
Max sent sequence-number: 0
UDP encapsulation used for NAT traversal: N
[Inbound ESP SAs]
SPI: 4182141148 (0xf94668dc)
proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-MD5
SA remaining key duration (bytes/sec): 1887436800/1390
Max received sequence-number: 0
UDP encapsulation used for NAT traversal: N
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
----End
Configuration Files
l Configuration file of RouterA
#
ipsec efficient-vpn 2 mode client
remote-address 60.1.2.1 v2
pre-shared-key huawei
#
interface Ethernet1/0/0
ip address 60.1.1.1 255.255.255.0
ipsec efficient-vpn 2
#
proposal
tran1
sa duration time-based
600000
#
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
ipsec policy policy1
#
Networking Requirements
As shown in Figure 3-8, an IPSec tunnel is established between RouterA and RouterB to protect
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
PC A PC B
Configuration Roadmap
The configuration roadmaps of RouterA and RouterB are as follows:
1. Assign an IP address to an interface.
2. Configure a static route.
3. Configure ACLs and define the data flows to be protected.
4. Configure the Efficient VPN policy in network mode.
5. Apply the Efficient VPN policy to the interface.
Procedure
Step 1 Configure IP addresses for the interfaces on RouterA and RouterB.
# Assign an IP address to the interface of RouterA.
<Huawei> system-view
[Huawei] interface ethernet 1/0/0
[Huawei-Ethernet1/0/0] ip address 100.1.1.1 255.255.255.0
[Huawei-Ethernet1/0/0] quit
[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
# 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] ip route-static 10.1.1.0 255.255.255.0 100.1.2.2
Step 3 Configure ACLs on RouterA and RouterB to define the data flows to be protected.
# Configure an ACL on RouterA.
[Huawei] acl number 3000
[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] quit
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
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] interface ethernet 1/0/0.1
[Huawei-Ethernet1/0/0.1] ipsec efficient-vpn easyvpn_1
# Apply the Efficient VPN policy to the sub-interface on RouterB.
[Huawei] interface ethernet 1/0/0.1
[Huawei-Ethernet1/0/0.1] ipsec efficient-vpn easyvpn_1
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.
[Huawei] display ipsec sa
===============================
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)
----End
Configuration Files
l Configuration file of RouterA
#
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
remote-address 99.1.2.1 v1
pre-shared-key htipl1.,;[-09876543211;'[]
security acl 3000
#
interface Ethernet1/0/0
ip address 100.1.1.1 255.255.255.0
#
4 DSVPN Configuration
DSVPN can be configured on the source branch, destination branch, and central office routers.
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:
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.
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 Value-Added Security Package
l AR150&200 DSVPN (Dynamic Smart VPN) Function
Applicable Environment
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.
Pre-configuration Tasks
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
2 NHRP authentication string, NHRP registration interval, and NHRP entry holding
time
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:
interface tunnel interface-number
Step 3 Run:
tunnel-protocol gre p2mp
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 }
Step 5 Run:
source { source-ip-address | interface-type interface-number }
The source address or source interface is configured for the tunnel interface.
----End
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
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
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
NOTE
This step is required when branches have only summarized routes to the central office.
----End
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
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.
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
NOTE
This step is required when branches have only summarized routes to the central office.
----End
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:
ipsec profile profile-name
Step 3 Run:
ike peer peer-name
NOTE
For the detailed configuration of an IKE peer, see 3.4.4 Configuring an IKE Peer.
Step 4 Run:
proposal proposal-name
NOTE
For the detailed configuration of an IKE proposal, see 3.4.5 Configuring an IPSec Proposal.
Step 5 Run:
pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 }
The router is configured to use Perfect Forward Secrecy (PFS) in IPSec negotiation.
Step 6 Run:
quit
Step 7 Run:
interface tunnel interface-number
Step 8 Run:
tunnel-protocol { gre [ p2mp ] | ipsec | ipv4-ipv6 | none }
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:
ipsec profile profile-name
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
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
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
Networking Requirements
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)
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data:
Procedure
Step 1 Assign an IP address to each interface.
Assign an IP address to each interface as shown in Figure 4-1. The specific configuration is not
mentioned here.
# Configure hub
[Huawei] ospf 3
[Huawei-ospf-2] area 0
[Huawei-ospf-2-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[Huawei-ospf-2-area-0.0.0.0] quit
[Huawei-ospf-2] quit
# Configure Spoke1
[Huawei] ospf 3
[Huawei-ospf-2] area 0
[Huawei-ospf-2-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[Huawei-ospf-2-area-0.0.0.0] quit
[Huawei-ospf-2] quit
# Configure Spoke2
[Huawei] ospf 3
[Huawei-ospf-2] area 0
[Huawei-ospf-2-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[Huawei-ospf-2-area-0.0.0.0] quit
[Huawei-ospf-2] 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 an NHRP mapping entry of the hub on Spoke1.
[Huawei] system-view
[Huawei] interface tunnel 0/0/0
[Huawei-Tunnel0/0/0] ip address 172.16.1.101 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 172.16.1.1 44.1.1.1 register
[Huawei-Tunnel0/0/0] ospf network-type broadcast
[Huawei-Tunnel0/0/0] ospf dr-priority 8
# Configure a tunnel interface and an NHRP mapping entry of the hub on Spoke2.
[Huawei] system-view
[Huawei] interface tunnel 0/0/0
[Huawei-Tunnel0/0/0] ip address 172.16.1.102 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 172.16.1.1 44.1.1.1 register
[Huawei-Tunnel0/0/0] ospf network-type broadcast
[Huawei-Tunnel0/0/0] ospf dr-priority 8
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 : --
Run the display nhrp peer all command on Spoke2, 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: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.
[Huawei] display nhrp peer all
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.101 32 44.3.1.2 172.16.1.101 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2008.01.07-18:07:45
Expire time : 2008.01.07-20:07:52
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.102 32 44.4.1.2 172.16.1.102 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2008.01.07-18:11:51
Expire time : 2008.01.07-20:11:57
Run the display nhrp peer all command on Spoke2, 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:12:53
Expire time : --
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.101 32 44.3.1.2 172.16.1.101 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2011.08.18-16:10:33
Expire time : 2011.08.18-18:10:33
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.102 32 44.4.1.2 172.16.1.102 dynamic local
-------------------------------------------------------------------------------
----End
Configuration Files
l Configuration file of Spoke1
#
interface Ethernet1/0/0
ip address 44.3.1.2 255.255.255.0
#
interface Tunnel0/0/0
ip address 172.16.1.101 255.255.255.0
tunnel-protocol gre p2mp
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
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
Networking Requirements
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)
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data:
l Reachable routes between the Routers
l Source addresses of tunnel interfaces on the Routers
Procedure
Step 1 Assign an IP address to each interface.
Assign an IP address to each interface as shown in Figure 4-2. The specific configuration is not
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 Spoke1
[Huawei] rip 2
[Huawei-rip-1] network 172.16.1.0
[Huawei-rip-1] version 2
[Huawei-rip-1] quit
# Configure Spoke2
[Huawei] rip 2
[Huawei-rip-1] network 172.16.1.0
[Huawei-rip-1] version 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] system-view
[Huawei] interface tunnel 0/0/0
# Configure a tunnel interface and an NHRP mapping entry of the hub, and enable NHRP shortcut
on Spoke1.
[Huawei] system-view
[Huawei] interface tunnel 0/0/0
[Huawei-Tunnel0/0/0] ip address 172.16.1.101 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 shortcut
[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, and enable NHRP shortcut
on Spoke2.
[Huawei] system-view
[Huawei] interface tunnel 0/0/0
[Huawei-Tunnel0/0/0] ip address 172.16.1.102 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 shortcut
[Huawei-Tunnel0/0/0] nhrp entry 172.16.1.1 44.1.1.1 register
Run the display nhrp peer all command on Spoke2, 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: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.
[Huawei] display nhrp peer all
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.101 32 44.3.1.2 172.16.1.101 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2008.01.07-18:07:45
Expire time : 2008.01.07-20:07:52
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.102 32 44.4.1.2 172.16.1.102 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2008.01.07-18:11:51
Expire time : 2008.01.07-20:11:57
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.
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 : --
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.102 32 44.4.1.2 172.16.1.102 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2011.08.18-16:09:31
Expire time : 2011.08.18-18:09:31
Run the display nhrp peer all command on Spoke2, 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:12:53
Expire time : --
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.101 32 44.3.1.2 172.16.1.101 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2011.08.18-16:10:33
Expire time : 2011.08.18-18:10:33
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
172.16.1.102 32 44.4.1.2 172.16.1.102 dynamic local
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 2011.08.18-16:10:33
Expire time : 2011.08.18-18:10:33
----End
Configuration Files
l Configuration file of Spoke1
#
interface Ethernet1/0/0
ip address 44.3.1.2 255.255.255.0
#
interface Tunnel0/0/0
ip address 172.16.1.101 255.255.255.0
tunnel-protocol gre p2mp
source Ethernet1/0/0
nhrp entry 172.16.1.1 44.1.1.1 register
nhrp shortcut
#
rip 1
version 2
network 44.0.0.0
#
rip 2
version 2
network 172.16.1.0
#
return
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.
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.
PC Internet LAN
Internal servers
Partner
Hotel
Virtual Gateway
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.
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.
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.
Applicable Environment
The configurations of basic SSL VPN functions include extranet/intranet interfaces and AAA
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
through the SSL VPN gateway.
Pre-configuration Tasks
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
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
sslvpn gateway gateway-name
----End
Applicable Environment
Extranet Intranet
interface interface
Remote terminal
Internet LAN
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
----End
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
----End
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
----End
Procedure
l Run the display sslvpn gateway [ gateway-name ] command to check the virtual gateway
configurations.
----End
Applicable Environment
User management functions include:
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.
Pre-configuration Tasks
Before configuring user management, complete the following task:
l Creating a virtual gateway
Procedure
Step 1 Run:
system-view
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.
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.
Step 6 (Optional) Run:
cut user { name user-name | id user-id | all }
----End
l Run the display sslvpn gateway [ gateway-name ] command to check the virtual gateway
configurations.
l Run the display sslvpn gateway gateway-name access-user [ user-name ] command to
view user information on the virtual gateway.
Applicable Environment
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
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.
The AR150/200 supports three service types as an SSL VPN gateway: Web proxy, port
forwarding, and IP forwarding.
Pre-configuration Tasks
Before configuring an SSL VPN service, complete the following task:
Data Preparation
To configure the SSL VPN serviced, you need the following data.
No. Data
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)
Context
Procedure
Step 1 Run:
system-view
----End
Context
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:
sslvpn gateway gateway-name
Step 3 Run:
service-type web-proxy resource resource-name
By default, the virtual gateway does not provide the Web proxy service.
Step 5 Run:
link url [ web-tunnel ]
NOTE
If the Web proxy function on the SSL VPN gateway is invalid, enable the tunnel mode; however, the tunnel
mode lowers security.
----End
Context
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:
sslvpn gateway gateway-name
Step 3 Run:
service-type port-forwarding resource resource-name
By default, the virtual gateway does not provide the port forwarding service.
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
Context
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
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.
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
Procedure
l Run the display sslvpn gateway [ gateway-name ] command to check the virtual gateway
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
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.
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.
Mail server
Marketing
Eth2/0/0 Vlanif 10
personnel
Intranet
Internet LAN
Router
Desktop
sharing host Web server
Configuration Roadmap
The configuration roadmap is as follows:
l Create a virtual gateway on the Router for marketing personnel and configure resources to
meet the access requirements of marketing personnel.
Data Preparation
To complete the configuration, you need the following data:
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> system-view
[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 3 Configure the intranet/extranet interfaces and bind an AAA domain to the virtual gateway.
[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
# 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.
# Configure the IP forwarding service to allow marketing personnel to ping the internal hosts
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
return