06 VPN Volume Book

Table of Contents
1 DVPN Configuration 1-1

DVPN Overview 1-1
Basic Concepts of DVPN 1-1
Operation of DVPN1-2
Networking Structures of DVPN 1-2
Implementation of DVPN 1-3
Supported DVPN Features1-5
DVPN Configuration Task List 1-6
Configuring AAA1-7
Configuring the VAM Server 1-7
VAM Server Configuration Task List 1-7
Creating a VPN Domain 1-7
Enabling VAM Server 1-7
Configuring the Listening IP Address and UDP Port Number1-8
Configuring the Security Parameters of VAM Protocol Packets 1-8
Specifying the Client Authentication Mode1-9
Configuring the Hubs1-9
Configuring the Pre-Shared Key of the VAM Server1-10
Configuring Keepalive Parameters1-10
Configuring a VAM Client1-11
VAM Client Configuration Task List1-11
Creating a VAM Client 1-11
Setting the VAM Protocol Packet Retransmission Interval 1-11
Specifying the Primary VAM Server 1-12
Specifying the Secondary VAM Server 1-12
Configuring the Username and Password1-12
Specifying the VPN Domain of the VAM Client1-13
Specifying the Pre-Shared Key of the VAM Client 1-13
Enabling VAM Client1-13
Configuring an IPsec Profile 1-14
Configuration Prerequisites 1-14
Configuration Procedure1-14
Configuring the DVPN Tunnel Parameters1-15
Configuring Routing 1-18
Displaying and Maintaining DVPN 1-18
DVPN Configuration Examples1-19
Full Mesh DVPN Configuration Example 1-19
Hub-Spoke DVPN Configuration Example 1-32
2 GRE Configuration 2-1
GRE Overview 2-1
Introduction to GRE 2-1
i
GRE Security Options 2-3

GRE Applications 2-3
Protocols and Standards 2-5
Configuring a GRE over IPv4 Tunnel2-5
Configuring a GRE over IPv6 Tunnel2-7
Displaying and Maintaining GRE 2-9
GRE over IPv4 Tunnel Configuration Examples2-9
GRE over IPv4 Tunnel Configuration Example (on Routers)2-9
GRE over IPv4 Tunnel Configuration Example (on Switches)2-12
GRE over IPv6 Tunnel Configuration Examples2-15
GRE over IPv6 Tunnel Configuration Example (on Routers)2-15
GRE over IPv6 Tunnel Configuration Example (on Switches)2-18
Troubleshooting GRE2-22
3 L2TP Configuration 3-1
L2TP Overview3-1
Introduction3-1
Typical L2TP Networking Application3-2
Basic Concepts of L2TP3-3
L2TP Tunnel Modes and Tunnel Establishment Process 3-4
L2TP Features3-7
Protocols and Standards 3-7
L2TP Configuration Task List3-7
Configuring Basic L2TP Capability 3-8
Configuring an LAC3-9
Configuring an LAC to Initiate Tunneling Requests for Specified Users3-9
Configuring an LAC to Transfer AVP Data in Hidden Mode 3-9
Configuring AAA Authentication of VPN Users on LAC Side3-10
Configuring an LNS3-11
Creating a Virtual Interface Template3-11
Configuring the Local Address and the Address Pool for Allocation3-11
Configuring an LNS to Grant Certain L2TP Tunneling Requests 3-12
Configuring User Authentication on an LNS 3-13
Configuring AAA Authentication of VPN Users on LNS Side3-14
Enabling L2TP Multi-Instance 3-14
Specifying to Send ACCM3-15
Configuring L2TP Connection Parameters 3-15
Configuring L2TP Tunnel Authentication3-15
Setting the Hello Interval 3-16
Enabling Tunnel Flow Control 3-16
Disconnecting Tunnels by Force 3-17
Displaying and Maintaining L2TP 3-17
L2TP Configuration Examples 3-17
NAS-Initiated VPN 3-17
Client-Initiated VPN 3-19
ii
L2TP Multi-Domain Application 3-21

Complicated Network Application3-24
Troubleshooting L2TP3-24
4 L2TP-Based EAD Configuration4-1
L2TP-Based EAD Overview4-1
Configuring L2TP-Based EAD 4-2
Displaying and Maintaining L2TP-Based EAD 4-2
L2TP-Based EAD Configuration Example 4-2
Network Requirements 4-2
5 SSL VPN Configuration4-1
SSL VPN Overview 4-1
Configuring SSL VPN4-2
Configuring SSL VPN 4-3
SSL VPN Configuration Example 4-3
iii
DVPN Configuration
Support for some features may vary with device models.
Support for some commands may vary with device models. For relevant information, refer to the
corresponding command manual.
All the MSR series routers are centralized devices.
The MSR series routers support VPN instances, therefore supporting the vpn-instance keyword.
When configuring DVPN, go to these sections for information you are interested in:
z
DVPN Overview
DVPN Configuration Task List
Displaying and Maintaining DVPN
DVPN Configuration Examples
DVPN Overview
Nowadays, more and more enterprises are demanding for virtual private networks (VPNs) to connect
their branches across the public network. However, branches of an enterprise usually use dynamically
assigned IP addresses to access the public network and each of them has no way to know the public
IP addresses of the other branches in advance. This makes it difficult for establishing VPNs. Dynamic
virtual private network (DVPN) is intended to address this issue.
DVPN collects, maintains, and distributes dynamic public addresses through the VPN Address
Management (VAM) protocol, making VPN establishment available between enterprise branches that
use dynamic addresses to access the public network.
In DVPN, a collection of nodes connected to the public network form a VPN. From the perspective of
DVPN, the public network is the link layer of the VPN, and the tunnels which are used as the virtual
channels between subnets of an intranet constitute the network layer. Branch devices dynamically
access the public network. DVPN can get the public IP addresses of the peers through VAM to set up
secure internal tunnels conveniently.
When a DVPN device forwards a packet from a user subnet to another, it performs these operations:
1)
Obtaining the next hop on the private network through a routing protocol.
2)
Inquiring the public network address of the next hop through the VAM protocol.
3)
Encapsulating the packet, using the public address as the destination address of the tunnel.
4)
Sending the packet down the tunnel to the destination.
Basic Concepts of DVPN

The following key roles are involved in DVPN:
1-1
DVPN node
A DVPN node is a device at an end of a DVPN tunnel. It can be a networking device or a host. A DVPN
node takes part in tunnel setup and must implement VAM client.
VAM server
A VAM server receives registration information from DVPN nodes and manages and maintains
information about DVPN clients. Currently, a VAM server is usually a high performance routing device
with VAM server enabled.
VAM client
A VAM client registers its private address, public address, and VAM ID with the VAM server and
obtains information about other VAM clients from the VAM server. The VAM client function must be
implemented on DVPN nodes. Unless otherwise noted, the term VAN client in this document refers
to a Hub or a Spoke.
Hub
A Hub is a type of VAM client. As a central device of a VPN, it is the exchange center of routing
information. A Hub in a Hub-Spoke network is also a data forwarding center.
Spoke
A Spoke is a type of VAM client. Usually acting as the gateway of a branch office, a Spoke does not
forward data received from other DVPN nodes.
AAA server
An Authentication, Authorization, and Accounting (AAA) server is used for user authentication and
accounting.
Operation of DVPN
DVPN employs the client/server model. Operating at the application layer of the TCP/IP protocol stack,
DVPN uses UDP as its transport layer protocol.
A DVPN consists of one server and multiple clients. The public address of the server in a DVPN must
be static. The private address of a client needs to be statically assigned, while the public address of a
client can be manually configured or dynamically assigned. All the private addresses of the nodes
composing a DVPN must belong to the same network segment.
Each client registers the mapping of its private address and public address with the server. After a
client registers its address mapping with the server, other clients can get the public address of this
client from the server. This is for DVPN tunnel establishment between clients. Each client uses the
VAM protocol to communicate with the server and uses the DVPN tunneling protocol to establish,
maintain, and remove tunnels to other clients. Whenever there is a change in the topology, the server
will be notified automatically.
Networking Structures of DVPN

DVPN supports two typical networking structures, full mesh and Hub-Spoke.
z
Full mesh DVPN: In a full mesh DVPN, Spokes can communicate with each other directly by
establishing tunnels between them, and the Hub is mainly used as the routing information
exchange center. As shown in Figure 1-1, after the Spokes (the clients) register with the VAM
server and get the Hub information in the VPN domain, they establish permanent tunnels with the
Hub. Any two Spokes can establish a tunnel directly between them, which is dynamic and will be
aged out if no data exchange occurs on it during the specified period of time (the idle timeout for
the Spoke-Spoke tunnel).
1-2
Figure 1-1 Full mesh DVPN networking diagram

VAM server
Hub
Hub-Spoke
Public network
Spoke 1
Spoke 2
Spoke-Spoke
Data
Site 1
Site 2
Hub-Spoke DVPN. In a Hub-Spoke DVPN, no tunnel can be established between two Spokes,
and data between them has to be forwarded through the Hub. That is, the Hub is used as both the
routing information exchange center and the data forwarding center. As shown in Figure 1-2,
each Spoke establishes a permanent tunnel with the Hub, and data between Spokes is forwarded
through the Hub.
Figure 1-2 Hub-Spoke DVPN networking diagram

VAM server
Hub
Public network
ta
Da
Da
ta
Hub-Spoke
Spoke 1
Spoke 2
Site 1
Site 2
Implementation of DVPN
DVPN works in three phases: connection initialization, registration, and tunnel establishment. The
following is a brief description of the phases:
Connection initialization phase

When a client accesses the server for the first time, connection initialization is performed first. During
the initialization procedure, the two parties negotiate whether VAM protocol packets should be secured.
1-3
If so, they negotiate the packet encryption and integrity validation algorithms, generate the keys, and
acknowledge the negotiated result. After the connection initialization process completes, the client
proceeds with the registration phase. Figure 1-3 shows the initialization process.
Figure 1-3 Initialization process
Client
Server
1) Connection request
2) Connection response
3) Negotiation acknowledgement
4) Negotiation acknowledgement
2)
The client sends the server a connection request, which carries the supported encryption and
integrity validation algorithms.
3)
Upon reception of the connection request, the server and the client begin to negotiate the
algorithms to be used, with the server dominating the negotiation. When negotiating an algorithm
to be used, the VAM server first compares the algorithm of the highest priority on its own
algorithm list against the algorithm list of the client. If a match is found, the algorithm is used. If not,
the server compares its next-highest priority algorithm against the list. The operation continues
until a match is found or all the algorithms on the servers algorithm list have been compared. If a
match is found, the server sends to the client a connection response, which carries the
negotiation result, and at the same time, the server and the client generate the encryption key and
integrity validation key.
4)
The client and server respectively checks whether the algorithm negotiation and key negotiation
are successful through the negotiation acknowledge packets.
Registration phase
Figure 1-4 Registration process
Figure 1-4 shows the registration process:

1)
The client sends the server a registration request, which carries information about the client.
2)
Upon reception of the registration request, the server first determines whether to authenticate the
identity of the client. If identity authentication is not required, the server directly registers the client
and sends the client a registration acknowledgement. Otherwise, the server sends the client an
identity authentication request, indicating the required authentication algorithm. In the case of
CHAP authentication, a random number is also sent.
3)
The client submits its identity information to the server.

1-4
4)
After receiving the identity information of the client, the server sends an authentication request to
the AAA server and, after receiving the expected authentication acknowledgement, sends an
accounting request to the AAA server. When the server receives the accounting
acknowledgement, it sends the client a registration acknowledgement, telling the client
information about the Hubs in the VPN.
Tunnel establishment phase

After a Spoke successfully registers itself, it needs to establish a permanent tunnel with a Hub. A
Spoke can establish permanent tunnels with up to two Hubs. If there are two Hubs in a VPN domain, a
permanent tunnel is required between the Hubs. Figure 1-5 shows the tunnel establishment process.
Figure 1-5 Tunnel establishment process
Spoke/Hub
Hub
1) Tunnel establishment request
2) Tunnel established
Spoke
Spoke
1) Tunnel establishment request
2) Tunnel established
2)
The initiator originates a tunnel establishment request.
Hub-Spoke tunnel: After a Spoke registers itself successfully, it needs to establish a permanent
tunnel with each Hub in the VPN. Upon receiving the registered information of the hubs from the
server, the Spoke checks whether a tunnel is present to each Hub. If no tunnel exists between the
Spoke and a Hub, the Spoke sends a tunnel establishment request to the Hub.
Hub-Hub tunnel: After a Hub registers itself successfully, the server sends the registered
information of the other Hubs in the VPN to the Hub and the Hub checks whether a tunnel exists
to each of its peer Hubs. If not, the Hub sends a tunnel establishment request to the peer Hub.
Spoke-Spoke tunnel: In a full mesh network, when a Spoke receives a data packet but finds no
tunnel for forwarding the packet, it sends an address resolution request to the server and then,
after receiving the resolved address, sends a tunnel establishment request to the peer Spoke.
3)
The tunnel establishment request receiver saves the tunnel establishment information and sends
a response to the sender. If the request sender receives the response, a tunnel is established.
Otherwise, tunnel establishment attempt fails.
Supported DVPN Features

NAT traversal of DVPN packets
When a Spoke needs to communicate with another Spoke, one of the following cases will occur:
z
If neither of the two Spokes is behind a NAT gateway, a direct tunnel will be established between
them.
If only the tunnel initiator resides behind a NAT gateway, a Spoke-Spoke tunnel can be
established traversing the NAT gateway.
1-5
If the tunnel request receiver is behind a NAT gateway, packets must be forwarded by a Hub
before the intended receiver originates a tunnel establishment request.
If both Spokes reside behind NAT gateways, no tunnel can be established between them and
packets between them will be forwarded by a Hub.
Support for dynamic VAM client IP address

As each VAM client registers its public and private addresses with the VAM server and can get the
public address of the peer VAM client from the VAM server, no tunnel destination address needs to be
configured on either tunnel interface of a tunnel. When a VAM client has its IP address changed, it
reregisters with the VAM server, thus supporting dynamic IP address.
AAA identity authentication of VAM clients on the VAM server

After the initialization process completes, a VAM client registers with the VAM server. You can specify
to authenticate VAM clients during the registration process. VAM supports PAP authentication and
CHAP authentication. The VAM server uses AAA to authenticate clients in the VPN domain. A VAM
client must pass authentication to access the VPN.
Identity authentication of the VAM server and VAM client using the pre-shared key
A VAM client and the VAM server must be configured with the same pre-shared key to generate the
encryption/integrity validation key. The VAM client/VAM server can determine whether the pre-shared
keys of both sides are the same by checking the result of packet decryption and integrity validation, so
as to implement identity authentication of the VAM server/VAM client.
Encryption of VAM protocol packets

VAM protocol packets can be encrypted by using AES-128, DES, or 3DES.
IPsec protection of data packets

Data packets in a DVPN tunnel can be protected by IPsec (using the ESP protocol and IKE).
Centralized management of policies

A VAM server manages all policies in a VPN domain centrally.
Support for multiple VPN domains

A VAM server supports up to 10 VPN domains.
DVPN Configuration Task List

When configuring DVPN, you are recommended to perform configuration in the order of the VAM
server, the Hub(s), and the Spokes.
Complete the following tasks to configure DVPN:
Task
Remarks
Configuring AAA
Optional
Configuring the VAM Server
Required
Configuring a VAM Client
Required
Configuring an IPsec Profile
Optional
Server side configuration
Client side configuration
Configuring the DVPN Tunnel

Parameters
Configuring Routing
1-6
Required
Required
Configuring AAA
A VAM server can employ AAA to authenticate the identities of clients accessing a VPN domain. For
AAA configuration, refer to AAA RADIUS HWTACACS Configuration in the Security Volume.
Configuring the VAM Server

VAM Server Configuration Task List
Complete the following tasks to configure a VAM server:
Task
Remarks
Creating a VPN Domain
Required
Enabling VAM Server
Required
Configuring the Listening IP Address and UDP Port Number
Required
Configuring the Security Parameters of VAM Protocol Packets
Optional
Specifying the Client Authentication Mode
Optional
Configuring the Hubs
Required
Configuring the Pre-Shared Key of the VAM Server
Required
Configuring Keepalive Parameters
Optional
Creating a VPN Domain

Follow these steps to create a VPN domain:
To do
Use the command
Enter system view
system-view
Create a VPN domain and

enter VPN domain view
Remarks
Required
vam server vpn vpn-name
No VPN domain exists by default.
Enabling VAM Server

Follow these steps to enable VAM server:
To do
Use the command
Enter system view
system-view
Enable VAM server for
vam server enable { all |
one or all VPN domains
vpn vpn-name }
Enable VAM server for
Enable VAM server

a VPN domain
Remarks
Required
Use either approach.
Disabled by default
server enable
1-7
Configuring the Listening IP Address and UDP Port Number

Follow these steps to configure the listening IP address and UDP port number of the VAM server:
To do
Enter system view
Configure the listening IP address
and UDP port number of the
server
Use the command
Remarks
system-view
vam server ip-address ip-address
Required
[ port port-number ]
Not configured by default
A VAM server listens to packets sent from VAM clients on only the configured IP address and UDP
port. A VAM server uses the same listening IP address and UDP port for all VPN domains.
Configuring the Security Parameters of VAM Protocol Packets

Based on the packet integrity authentication algorithm and encryption algorithm configuration, a VAM
server negotiates with a client to determine the protocol packets integrity authentication and
encryption algorithms to be used between them.
Follow these steps to configure VAM protocol packet security parameters:
To do
Use the command
Remarks
Enter system view
system-view
Enter VPN domain view
Specify the algorithms for protocol

packet authentication and their
priorities
Optional
authentication-algorithm { none
| { md5 | sha-1 } * }
By default, SHA-1 is used for

protocol packet authentication.
Optional
Specify the algorithms for protocol

packet encryption and their
priorities
encryption-algorithm { { 3des |
aes-128 | des } * | none }
By default, three encryption

algorithms are available and
preferred in this order: AES-128,
3DES and DES.
1-8
In the connection initialization process, SHA-1 is always used for authenticating connection
requests from clients and connection responses from the server. Whether subsequent protocol
packets are to be authenticated and what algorithms are available for authentication depend on
your configuration.
In the connection initialization process, AES-128 is always used for encrypting connection
requests from clients and connection responses from the server. Whether subsequent protocol
packets are to be encrypted and what algorithms are available for encryption depend on your
configuration.
The configuration order of the algorithms determines the priorities of the algorithms.
Specifying the Client Authentication Mode

Currently, a VAM server supports only PAP and CHAP authentication.
Follow these steps to configure the client authentication mode:
To do
Use the command
Remarks
Enter system view
system-view
Required
By default, a VAM server
Specify the client
authentication-method { none | { chap |
performs CHAP authentication
authentication mode
pap } [ domain name-string ] }
of clients, using the default

domain configured for the
system.
Configuring the Hubs

Follow these steps to configure a Hub:
To do
Use the command
Remarks
Enter system view
system-view
Configure a Hub by specifying its
hub private-ip private-ip-address
Required
IP addresses
[ public-ip public-ip-address ]
No Hub is configured by default.
1-9
The public IP address is optional. When a Hub registers, the VAM server will get the public
address of the Hub. If you specify both the private and public addresses of a Hub on the server,
the server considers a client being a valid Hub only when both the public and private addresses
that the client registers with the server match those configured on the server.
Currently, up to two Hubs and 200 Spokes can be configured in a VPN domain.
Configuring the Pre-Shared Key of the VAM Server

The pre-shared key is used to generate the keys for securing the channels between the server and a
client. In the connection initialization process, the pre-shared key is used to generate the initial key for
validating and encrypting connection requests and connection responses. If encryption and
authentication is needed for subsequent packets, the pre-shared key is also used to generate the
connection key for validating and encrypting the subsequent packets.
Follow these steps to configure the pre-shared key of the VAM server:
To do
Use the command
Remarks
Enter system view
system-view
Configure the pre-shared key of
pre-shared-key { cipher | simple }
the VAM server
key-string
Required
No pre-shared key exists by
default.
Configuring Keepalive Parameters

A client sends keepalive packets to the server periodically, while the server sends responses back to
prove its existence. If a server receives no keepalive packets from a client within a specified period
(which equals the product of the keepalive interval and the maximum number of transmission
attempts), the server removes information about the client and logs off the client.
You can set the interval at which a client sends keepalive packets and the maximum number of
transmission attempts. After a client registers with the server, the server sends these settings to the
client through its response packet.
Follow these steps to configure keepalive parameters:
To do
Use the command
Remarks
Enter system view
system-view
Set the keepalive interval
keepalive interval time-interval
Optional
10 seconds by default
Set the maximum number of
transmission attempts
Optional
keepalive retry retry-times
3 by default
1-10
Your keepalive settings only apply to the clients registered after the configuration. The clients
registered before that continue to use the old settings.
Configuring a VAM Client

VAM Client Configuration Task List
Complete the following tasks to configure a VAM client:
Task
Remarks
Creating a VAM Client
Required
Setting the VAM Protocol Packet Retransmission Interval
Optional
Specifying the Primary VAM Server
Required
Specifying the Secondary VAM Server
Optional
Configuring the Username and Password
Optional
Specifying the VPN Domain of the VAM Client
Required
Specifying the Pre-Shared Key of the VAM Client
Required
Enabling VAM Client
Required
Creating a VAM Client

Follow these steps to create a VAM client:
To do
Enter system view
Create a VAM client and enter
its view
Use the command
Remarks
system-view
Required
vam client name client-name
No client is created by default.
Setting the VAM Protocol Packet Retransmission Interval

If a client sends a VAM protocol packet to the server but receives no response in a specified period of
time, it retransmits the packet. A VAM protocol packet can be a connection request, negotiation
acknowledgement, registration request, or authentication request.
Follow these steps to set the interval for retransmitting a VAM protocol packet:
To do
Enter system view
Use the command
Remarks
system-view
1-11
Enter VAM client view

Set the VAM protocol packet
retransmission interval
Optional
resend interval time-interval

The maximum number of attempts to retransmit a VAM protocol packet is always 3; it is unmodifiable.
Specifying the Primary VAM Server

Follow these steps to specify the primary VAM server:
To do
Use the command
Remarks
Enter system view
system-view
server primary ip-address
Required
ip-address [ port port-number ]
Not specified by default
Specify the primary VAM server
Specifying the Secondary VAM Server

Follow these steps to specify the secondary VAM server:
To do
Use the command
Remarks
Enter system view
system-view
server secondary ip-address
Required
ip-address [ port port-number]
Specify the primary VAM server
Configuring the Username and Password

A client needs a username and a password to be authenticated by the server. You can configure the
username and password for a client by creating a local user.
Follow these steps to configure a username and password for a VAM client:
To do
Use the command
Remarks
Enter system view
system-view
1-12
Configure a username and
user username password { cipher |
Required
password for the client
simple } string
Not configured by default
Only one local user can be configured for a VAM client.
Specifying the VPN Domain of the VAM Client

Follow these steps to specify the VPN domain of the VAM client:
To do
Use the command
Remarks
Enter system view
system-view
Required
Specify the VPN domain of the

VAM client
vpn vpn-name
A VAM client does not belong to

any VPN domain by default.
Specifying the Pre-Shared Key of the VAM Client

The pre-shared key is used to generate the keys for security of the channels between the server and a
client.
Follow these steps to specify the pre-shared key of the VAM client:
To do
Use the command
Remarks
Enter system view
system-view
Specify the pre-shared key of
pre-shared-key { cipher | simple }
Required
the VAM client
key-string
In a VPN domain, all the VAM clients and the VAM server must be configured with the same
pre-shared key.
Enabling VAM Client

Follow these steps to enable VAM client:
1-13
To do
Use the command
Enter system view
system-view
Enable VAM client for
Remarks
vam client enable { all |
all VAM clients or a
name client-name }
specified VAM client

Enable VAM client
Required
Use either approach.
vam client name

Enable VAM client for a
Disabled by default
client-name
VAM client
client enable
Configuring an IPsec Profile

An IPsec profile can be used to secure the transmission of data packets and control packets over a
DVPN tunnel. It uses the security protocol of ESP and employs IKE for security policy negotiation.
Configuration Prerequisites
Complete these tasks before configuring an IPsec profile:
z
Configure the IPsec proposals for the IPsec profile to reference
Configure the IKE peer for the IPsec profile to reference
For detailed configuration information about IPsec and IKE, refer to IPsec Configuration in the Security
Volume.
Configuration Procedure
Follow the following steps to configure an IPsec profile:
To do
Enter system view
Use the command

system-view
Remarks
Required
Create an IPsec profile and enter

IPsec profile view
ipsec profile profile-name
By default, no IPsec profile is

created.
Required
Specify the IPsec proposals for the

IPsec profile to reference
proposal proposal-name&<1-6>
By default, an IPsec profile

references no IPsec proposal.
Required
Specify the IKE peer for the IPsec

profile to reference
ike-peer peer-name
By default, an IPsec profile

references no IKE peer
1-14
Optional
By default, PFS is not used for
Enable and configure perfect
pfs { dh-group1 | dh-group2 |
negotiation.
forward secrecy (PFS)
dh-group5 | dh-group14 }
For information about PFS, refer to

IPsec Configuration in the Security
Volume.
Optional
Configure the SA lifetime
sa duration { time-based
seconds | traffic-based kilobytes }
By default, an IPsec profile uses

the global SA lifetime.
An IPsec profile depends on IKE for SA negotiation. An IPsec profile can reference up to six IPsec
proposals. IKE searches for IPsec proposals that match at both ends during negotiation. If no
match is found, SAs cannot be established and the packets requiring IPsec protection will be
discarded.
When IKE uses a security policy to initiate a negotiation, if the local end uses PFS, the remote
end must also use PFS for negotiation and both ends must use the same Diffie-Hellman (DH)
group; otherwise, the negotiation will fail.
When an IPsec profile is used to protect DVPN traffic, the IPsec proposals referenced by the
IPsec profile must be configured to use the ESP protocol.
As DVPN addresses are dynamic, the setting by the remote-address keyword for the IKE peer
that an IPsec profile references does not take effect on the initiator.
For information about commands ipsec profile, proposal, ike-peer, pfs and sa duration, refer
to IPsec Commands in the Security Volume.
For information about global SA lifetime, refer to IPsec Configuration in the Security Volume.
Configuring the DVPN Tunnel Parameters

IP addresses have been configured for the source interfaces (VLAN interfaces, Ethernet interfaces, or
Loopback interfaces) of the virtual tunnel interfaces and there are routes available between the
interfaces.
Follow these steps to configure a DVPN tunnel:
To do
Enter system view
Use the command

system-view
1-15
Remarks
Required
Create a tunnel interface and enter
its view
interface tunnel number
No tunnel interface is created by

default.
Required
Configure a private IPv4 address
ip address ip-address { mask |
A tunnel interface has no private
for the tunnel interface
mask-length } [ sub ]
IPv4 address configured by

default.
Required
Configure the tunnel mode as

DVPN
The default tunnel mode varies

tunnel-protocol dvpn udp
with device model.

The two ends of a tunnel must
work in the same tunnel mode.
Required
The source IP address is the IP
Specify the source address or
source { ip-address |
interface of the tunnel interface
interface-type interface-number }
address of the physical interface

that sends the DVPN packets.
A tunnel interface has no source
address or interface configured by
default.
Required
A DVPN tunnel interface must be
bound to a VAM client; otherwise
the tunnel interface cannot come
Bind a VAM client to the tunnel

interface
up.
vam client client-name
The client to be bound must exist
and has not been bound to any
other tunnel interface.
No VAM client is bound to a DVPN
tunnel interface by default.
Optional
The defaults are as follows:
Set the DVPN keepalive interval

and transmission attempt limit
keepalive [ seconds [ times ] ]
10 seconds for the DVPN

keepalive interval,
3 times for the transmission

attempt limit.
Set the idle timeout for the
dvpn session idle-time
Optional
Spoke-Spoke tunnel
time-interval
Set the DVPN tunneling quiet
dvpn session dumb-time
Optional
period
time-interval
1-16
Required
Specify the network type of the
ospf network-type { broadcast |
A DVPN tunnel can use only two
OSPF interface
p2mp }
types of OSPF interfaces:

broadcast and point to multi-point
(P2MP).
Optional for a Hub, while required
for a Spoke.
By default, the interface DR priority
is 1.
Set the DR priority of the OSPF

interface
ospf dr-priority priority
The DR priority of a Hub should be

higher than that of a Spoke. It is
recommended to set the DR
priority of a Spoke to 0 to keep the
Spoke from participating in
DR/BDR election.
Optional
Bind an IPsec profile to the DVPN

tunnel interface
By default, no IPsec profile is

ipsec profile ipsec-profile-name
bound to a DVPN tunnel interface.

The IPsec profile to be bound must
already exist.
Optional
To isolate individual VPN domains,
Associate the tunnel interface with
ip binding vpn-instance
a VPN instance
vpn-instance-name
you need to configure VPN

multi-instance to distinguish routes
of private networks.
By default, a tunnel interface is
associated with no VPN instance.
1-17
If you configure the source address of a tunnel interface by specifying the source interface, the
tunnel takes the primary IP address of the source interface as its source address.
Tunnel interfaces of the same VPN domain must be configured with private addresses in the
same segment.
Tunnel interfaces of the same VPN domain must be configured with the same DVPN keepalive
interval and transmission attempt limit.
A DVPN tunnel interface can reference only one IPsec profile. To change the IPsec profile
referenced by a DVPN tunnel interface, you need to cancel the reference of the current IPsec
profile and then apply a new IPsec profile to the tunnel interface.
When configuring the network type of an OSPF interface, select broadcast for a full mesh network
and P2MP for a Hub-Spoke network.
For details about commands interface tunnel, tunnel-protocol, and source, refer to Tunneling
Commands of the IP Services Volume. For information about command ipsec profile, refer to
IPsec Commands in the Security Volume.
For details about the ospf network-type and ospf dr-priority commands, refer to OSPF
Commands of the IP Routing Volume.
For details about VPN multi-instance configuration, refer to MPLS L3VPN Configuration of the
MPLS Volume.
Configuring Routing
After you establish private networks across the public network using DVPN, you need to perform
routing configuration for devices in the private networks. In private networks of this type, route-related
operations, such as neighbor discovery, route updating, routing table establishment, are done over
DVPN tunnels. Routing information is exchanged between Hubs or Hubs and Spokes; it is not
exchanged between Spokes. Currently, OSPF can be used in DVPN networks.
For information about OSPF configuration on DVPN clients, refer to OSPF Configuration in the IP
Routing Volume.
Displaying and Maintaining DVPN

To do
Use the command
Display address mapping
display vam server
information about VAM clients
address-map { all | vpn
registered with the VAM server
vpn-name [ private-ip private-ip ] }
Display statistics about VAM

clients registered with the VAM
server
Display registration information

about VAM clients
display vam server statistic { all

| vpn vpn-name }
Remarks
Available in any view
display vam client

{ address-map | fsm }
[ client-name ]
1-18
display dvpn session { all |

Display information about DVPN
interface interface-type
tunnels
interface-number [ private-ip
ip-address ] }
Display information about a
display ipsec profile [ name
specified or all IPsec profiles
profile-name ]
reset dvpn session { all |

Remove DVPN tunnels
interface interface-type
interface-number [ private-ip
Available in user view
ip-address ] }
For information about command display ipsec profile, refer to IPsec Commands in the Security
Volume.
DVPN Configuration Examples

Full Mesh DVPN Configuration Example
Network requirements
z
In the full mesh networks shown in Figure 1-6, the primary VAM server (main) and the secondary
VAM server (backup) manage and maintain information about the nodes. The AAA server takes
charge of VAM client authentication and accounting. With each being the backup of the other, the
two Hubs perform data forwarding and routing information exchange.
Permanent tunnels are established between each Hub-Spoke pair.
Spokes in the same VPN exchange data through dynamically established tunnels between them.
1-19
Figure 1-6 Network diagram for full mesh DVPN configuration

Hub 1
VPN 1 and VPN 2 Hub-to-Hub

static tunnel
Tunnel1
Tunnel2
Hub 2
Eth1/1
Eth1/1
VPN 1 Hub-to-Spoke static tunnel
Tunnel1
Tunnel2
AAA server
IP network
Eth1/1

Main server
Eth1/1
Spoke-to-Spoke dynamic tunnel
Tunnel1
Eth1/1
Eth1/1
Hub 2
Main server
Backup server
AAA server
Interface
Eth1/1
Tunnel1
Tunnel2
Eth1/1
Tunnel1
Tunnel2
Eth1/1
Eth1/1
Eth1/1
Eth1/2
Site 1
Device
Hub 1
Backup server
Tunnel2
Spoke 2
Spoke 1
Eth1/2
Tunnel1
Tunnel2
Spoke 3
Eth1/2
Site 2
IP address
192.168.1.1/24
10.0.1.1/24
10.0.2.1/24
192.168.1.2/24
10.0.1.2/24
10.0.2.2/24
192.168.1.22/24
192.168.1.33//24
192.168.1.11/24
Site 3
Device
Spoke 1
Spoke 2
Spoke 3
Interface
Eth1/1
Eth1/2
Tunnel1
Eth1/1
Eth1/2
Tunnel1
Tunnel2
Eth1/1
Eth1/2
Tunnel2
Configuration procedure
1)
Configure the primary VAM server (main)
Configure IP addresses for the interfaces (omitted)
Configure AAA
<MainServer> system-view
# Configure RADIUS scheme radsun.

[MainServer] radius scheme radsun
[MainServer-radius-radsun] primary authentication 192.168.1.11 1812
[MainServer-radius-radsun] primary accounting 192.168.1.11 1813
[MainServer-radius-radsun] key authentication expert
[MainServer-radius-radsun] key accounting expert
[MainServer-radius-radsun] server-type standard
[MainServer-radius-radsun] user-name-format with-domain
[MainServer-radius-radsun] quit
# Configure ISP domain domain1 to use RADIUS scheme radsun.

[MainServer] domain domain1
[MainServer-isp-domain1] authentication default radius-scheme radsun
[MainServer-isp-domain1] accounting default radius-scheme radsun
[MainServer-isp-domain1] quit
[MainServer] domain default enable domain1
z
Configure the VAM server
# Specify the listening address of the server.

1-20
IP address
192.168.1.3/24
10.0.3.1/24
10.0.1.3/24
192.168.1.4/24
10.0.4.1/24
10.0.1.4/24
10.0.2.4/24
192.168.1.5/24
10.0.5.1/24
10.0.2.3/24
[MainServer] vam server ip-address 192.168.1.22
# Create VPN domain 1.

[MainServer] vam server vpn 1
# Set the pre-shared key to 123.

[MainServer-vam-server-vpn-1] pre-shared-key simple 123
# Set the VAM client authentication mode to CHAP.

[MainServer-vam-server-vpn-1] authentication-method chap
# Specify the IP addresses of the Hubs for VPN 1.

[MainServer-vam-server-vpn-1] hub private-ip 10.0.1.1
[MainServer-vam-server-vpn-1] quit


# Set the VAM client authentication mode to PAP.

[MainServer-vam-server-vpn-2] authentication-method pap

[MainServer-vam-server-vpn-1] quit
# Enable VAM server for all VPNs.

[MainServer] vam server enable all
2)
Configure the secondary VAM server (backup)
Except for the listening IP address configuration, the configurations for the secondary VAM server are
the same as those for the primary VAM server and are thus omitted.
3)
Configure Hub 1
Configure IP addresses for the interfaces (omitted)
Configure the VAM clients
<Hub1> system-view
# Create a VAM client named dvpn1hub1 for VPN 1.

[Hub1] vam client name dvpn1hub1
[Hub1-vam-client-name-dvpn1hub1] vpn 1
# Specify the IP addresses of the VAM servers and set the pre-shared key.
[Hub1-vam-client-name-dvpn1hub1] server primary ip-address 192.168.1.22
[Hub1-vam-client-name-dvpn1hub1] server secondary ip-address 192.168.1.33
[Hub1-vam-client-name-dvpn1hub1] pre-shared-key simple 123
# Create a local user named dvpn1hub1, setting the password as dvpn1hub1.

[Hub1-vam-client-name-dvpn1hub1] user dvpn1hub1 password simple dvpn1hub1
[Hub1-vam-client-name-dvpn1hub1] client enable
[Hub1-vam-client-name-dvpn1hub1] quit

1-21

z
Configure the IPsec profile
# Configure the IPsec proposal.

[Hub1] ipsec proposal vam
[Hub1-ipsec-proposal-vam] encapsulation-mode tunnel
[Hub1-ipsec-proposal-vam] transform esp
[Hub1-ipsec-proposal-vam] esp encryption-algorithm des
[Hub1-ipsec-proposal-vam] esp authentication-algorithm sha1
[Hub1-ipsec-proposal-vam] quit
# Configure the IKE peer.

[Hub1] ike peer vam
[Hub1-ike-peer-vam] pre-shared-key abcde
[Hub1-ike-peer-vam] quit
# Configure the IPsec profile.

[Hub1] ipsec profile vamp
[Hub1-ipsec-profile-vamp] proposal vam
[Hub1-ipsec-profile-vamp] ike-peer vam
[Hub1-ipsec-profile-vamp] sa duration time-based 600
[Hub1-ipsec-profile-vamp] pfs dh-group2
[Hub1-ipsec-profile-vamp] quit
z
Configure DVPN tunnels
# Configure tunnel interface Tunnel 1 for VPN 1.

[Hub1] interface tunnel 1
[Hub1-Tunnel1] tunnel-protocol dvpn udp
[Hub1-Tunnel1] vam client dvpn1hub1
[Hub1-Tunnel1] ip address 10.0.1.1 255.255.255.0
[Hub1-Tunnel1] source ethernet 1/1
[Hub1-Tunnel1] ospf network-type broadcast
[Hub1-Tunnel1] ipsec profile vamp
[Hub1-Tunnel1] quit

[Hub1-Tunnel2] quit
z
Configure OSPF
# Configure OSPF for the public network.

[Hub1] ospf 100
[Hub1-ospf-100] area 0
[Hub1-ospf-100-area-0.0.0.0] network 192.168.1.1 0.0.0.255
[Hub1-ospf-100-area-0.0.0.0] quit
# Configure OSPF for the private networks.

[Hub1] ospf 200
1-22

[Hub1] ospf 300
4)
Configure Hub 2
Configure IP addresses for the interfaces (omitted).
Configure the VAM clients.
<Hub2> system-view




z


[Hub2] ike peer vam

1-23
Configure the DVPN tunnels.

[Hub2-Tunnel1] quit

[Hub2-Tunnel2] quit
z
Configure OSPF

[Hub2] ospf 100

[Hub2] ospf 200
[Hub2] ospf 300
5)
Configure Spoke 1
Configure the VAM client.
<Spoke1> system-view
# Create a VAM client named dvpn1spoke1 for VPN 1.

[Spoke1] vam client name dvpn1spoke1
[Spoke1-vam-client-name-dvpn1spoke1] vpn 1
[Spoke1-vam-client-name-dvpn1spoke1] server primary ip-address 192.168.1.22
[Spoke1-vam-client-name-dvpn1spoke1] server secondary ip-address 192.168.1.33
[Spoke1-vam-client-name-dvpn1spoke1] pre-shared-key simple 123
# Create a local user named dvpn1spoke1, setting the password as dvpn1spoke1.

[Spoke1-vam-client-name-dvpn1spoke1] user dvpn1spoke1 password simple dvpn1spoke1
[Spoke1-vam-client-name-dvpn1spoke1] client enable
[Spoke1-vam-client-name-dvpn1spoke1] quit
z

1-24
[Spoke1] ipsec proposal vam

[Spoke1-ipsec-proposal-vam] encapsulation-mode tunnel
[Spoke1-ipsec-proposal-vam] transform esp
[Spoke1-ipsec-proposal-vam] esp encryption-algorithm des
[Spoke1-ipsec-proposal-vam] esp authentication-algorithm sha1
[Spoke1-ipsec-proposal-vam] quit

[Spoke1] ike peer vam
[Spoke1-ike-peer-vam] pre-shared-key abcde
[Spoke1-ike-peer-vam] quit

[Spoke1] ipsec profile vamp
[Spoke1-ipsec-profile-vamp] proposal vam
[Spoke1-ipsec-profile-vamp] sa duration time-based 600
[Spoke1-ipsec-profile-vamp] pfs dh-group2
[Spoke1-ipsec-profile-vamp] quit
z
Configure the DVPN tunnel.

[Spoke1] interface tunnel 1
[Spoke1-Tunnel1] tunnel-protocol dvpn udp
[Spoke1-Tunnel1] vam client dvpn1spoke1
[Spoke1-Tunnel1] ip address 10.0.1.3 255.255.255.0
[Spoke1-Tunnel1] source ethernet 1/1
[Spoke1-Tunnel1] ospf network-type broadcast
[Spoke1-Tunnel1] ospf dr-priority 0
[Spoke1-Tunnel1] ipsec profile vamp
[Spoke1-Tunnel1] quit
z
Configure OSPF

[Spoke1] ospf 100
[Spoke1-ospf-100] area 0
[Spoke1-ospf-100-area-0.0.0.0] network 192.168.1.3 0.0.0.255
[Spoke1-ospf-100-area-0.0.0.0] quit
# Configure OSPF for the private network.

[Spoke1] ospf 200
6)
Configure Spoke 2


1-25



z



[Spoke2-ipsec-profile-vamp] ike-peer vam
z
Configure the DVPN tunnels.


1-26

z
Configure OSPF

[Spoke2] ospf 100

[Spoke2] ospf 200
[Spoke2] ospf 300
7)
Configure Spoke 3


z



1-27
z

z
Configure OSPF

[Spoke3] ospf 100

[Spoke3] ospf 200
8)
Verify the configuration
# Display the address mapping information of all VAM clients registered with the primary VAM server
(main).
[MainServer] display vam server address-map all
VPN name: 1
Total address-map number: 4
Private-ip
Public-ip
10.0.1.1
192.168.1.1
Hub
Type
0H 52M 7S
Holding time
10.0.1.2
192.168.1.2
Hub
0H 47M 31S
10.0.1.3
192.168.1.3
Spoke
0H 28M 25S
10.0.1.4
192.168.1.4
Spoke
0H 19M 15S
VPN name: 2
Private-ip
Public-ip
Type
Holding time
10.0.2.1
192.168.1.1
Hub
0H 51M 44S
10.0.2.2
192.168.1.2
Hub
0H 46M 45S
10.0.2.3
192.168.1.5
Spoke
0H 11M 25S
10.0.2.4
192.168.1.4
Spoke
0H 18M 32S
# Display the address mapping information of all VAM clients registered with the secondary VAM
server (backup).
[BackupServer] display vam server address-map all
VPN name: 1
Private-ip
Public-ip
Type
Holding time
10.0.1.1
192.168.1.1
Hub
0H 55M 3S
10.0.1.2
192.168.1.2
Hub
0H 50M 30S
1-28
10.0.1.3
192.168.1.3
Spoke
0H 31M 24S
10.0.1.4
192.168.1.4
Spoke
0H 22M 15S
VPN name: 2
Private-ip
Public-ip
Type
Holding time
10.0.2.1
192.168.1.1
Hub
0H 54M 43S
10.0.2.2
192.168.1.2
Hub
0H 49M 44S
10.0.2.3
192.168.1.5
Spoke
0H 14M 24S
10.0.2.4
192.168.1.4
Spoke
0H 21M 32S
The above output indicates that Hub 1, Hub 2, Spoke 1, Spoke 2, and Spoke 3 all have registered their
address mapping information with the VAM servers.
# Display the DVPN tunnel information of Hub 1.
[Hub1] display dvpn session all
Interface: Tunnel1 VPN name: 1 Total number: 3
Private IP:
10.0.1.2
Public IP:
192.168.1.2
Session type:
Hub-Hub
State: SUCCESS
Holding time: 0h 1m 44s
Input: 101 packets, 100 data packets, 1 control packets
87 multicasts, 0 errors
Output: 106 packets, 99 data packets, 7 control packets
Private IP:
10.0.1.3
Public IP:
192.168.1.3
Session type:
Hub-Spoke
State: SUCCESS
Private IP:
10.0.1.4
Public IP:
192.168.1.4
Session type:
Hub-Spoke
State: SUCCESS

Private IP:
10.0.2.2
Public IP:
192.168.1.2
Session type:
Hub-Hub
1-29
State: SUCCESS
Private IP:
10.0.2.4
Public IP:
192.168.1.4
Session type:
Hub-Spoke
State: SUCCESS
Private IP:
10.0.2.3
Public IP:
192.168.1.5
Session type:
Hub-Spoke
State: SUCCESS
The above information indicates that:

z
In VPN 1, Hub 1 has established a permenent tunnel with Hub 2, Spoke 1, and Spoke 2
respectively.
In VPN 2, Hub 1 has established a permenent tunnel with Hub 2, Spoke 2, and Spoke 3
respectively.
The DVPN tunnel information of Hub 2 is similar to that of Hub 1.

# Display the DVPN tunnel information of Spoke 2.
[Spoke2] display dvpn session all
Private IP:
10.0.1.1
Public IP:
192.168.1.1
Session type:
Spoke-Hub
State: SUCCESS
Private IP:
10.0.1.2
Public IP:
192.168.1.2
Session type:
Spoke-Hub
State: SUCCESS
1-30


Private IP:
10.0.2.1
Public IP:
192.168.1.1
Session type:
Spoke-Hub
State: SUCCESS
Private IP:
10.0.2.2
Public IP:
192.168.1.2
Session type:
Spoke-Hub
State: SUCCESS
The above information indicates that Spoke 2 has established a permenent Hub-Spoke tunnel with
Hub 1 and Hub 2 respectively in both VPN 1 and VPN 2.
The DVPN tunnel information of Spoke 1 and Spoke 3 is similar to that of Spoke 2.
# On Spoke 2, ping private address 10.0.5.1 of Spoke 3.
[Spoke2] ping 10.0.5.1
PING 10.0.5.1: 56 data bytes, press CTRL_C to break
Reply from 10.0.5.1: bytes=56 Sequence=1 ttl=254 time=5 ms
--- 10.0.5.1 ping statistics --5 packet(s) transmitted

5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 4/4/5 ms
# Display the DVPN tunnel information of interface Tunnel 2 on Spoke 2.

[Spoke2] display dvpn session interface tunnel 2
Private IP:
10.0.2.1
Public IP:
192.168.1.1
Session type:
Spoke-Hub
State: SUCCESS
1-31

Private IP:
10.0.2.2
Public IP:
192.168.1.2
Session type:
Spoke-Hub
State: SUCCESS
Private IP:
10.0.2.3
Public IP:
192.168.1.5
Session type:
Spoke-Spoke
State: SUCCESS
The above information indicates that a Spoke-Spoke tunnel has been established dynamically
between Spoke 2 and Spoke 3.
Hub-Spoke DVPN Configuration Example

z
In the Hub-Spoke networks shown in Figure 1-7, data is forwarded along Hub-Spoke tunnels. The
primary and secondary VAM servers (the main and backup servers in the following figure)
manage and maintain information about the nodes. The AAA server takes charge of VAM client
authentication and accounting. With each being the backup of the other, the two Hubs perform
data forwarding and routing information exchange.
Permanent tunnels are established between each Hub-Spoke pair.
1-32
Figure 1-7 Network diagram for Hub-Spoke DVPN configuration

Hub 1
Hub 2
Eth1/1
Tunnel1
Eth1/1
Tunnel1
AAA server
IP network
Eth1/1
Main server
Eth1/1
Tunnel1
Eth1/1
Tunnel1
Eth1/1
Backup server
VPN 1 and VPN 2 Hub-to-Hub

static tunnel
Eth1/2
Eth1/2
Spoke 1
Site 1
Site 1
Device
Hub 1
Hub 2
Main server
Backup server
AAA server
Interface
Eth1/1
Tunnel1
Eth1/1
Tunnel1
Eth1/1
Eth1/1
Spoke 2
IP address
192.168.1.1/24
10.0.1.1/24
192.168.1.2/24
10.0.1.2/24
192.168.1.22/24
192.168.1.33//24
192.168.1.11/24
Device
Spoke 1
Spoke 2
Interface
Eth1/1
Eth1/2
Tunnel1
Eth1/1
Eth1/2
Tunnel1
1)
Configure the primary VAM server (main)
Configure AAA.
<MainServer> system-view
# Configure RADIUS scheme radsun.

[MainServer] radius scheme radsun
[MainServer-radius-radsun] primary authentication 192.168.1.11 1812
[MainServer-radius-radsun] primary accounting 192.168.1.11 1813
[MainServer-radius-radsun] key authentication expert
[MainServer-radius-radsun] key accounting expert
[MainServer-radius-radsun] server-type standard
[MainServer-radius-radsun] user-name-format with-domain
[MainServer-radius-radsun] quit
# Configure ISP domain domain1 to use RADIUS scheme radsun.

[MainServer] domain domain1
[MainServer-isp-domain1] authentication default radius-scheme radsun
[MainServer-isp-domain1] accounting default radius-scheme radsun
[MainServer-isp-domain1] quit
[MainServer] domain default enable domain1
z
Configure the VAM server
# Specify the listening address of the server.

[MainServer] vam server ip-address 192.168.1.22

1-33
IP address
192.168.1.3/24
10.0.2.1/24
10.0.1.3/24
192.168.1.4/24
10.0.3.1/24
10.0.1.4/24

# Set VAM client authentication mode to CHAP.

[MainServer-vam-server-vpn-1] authentication-method chap

# Enable VAM server for all VPNs.

[MainServer] vam server enable all
2)
Configure the secondary VAM server (backup)
Except for the listening IP address configuration, the configurations for the secondary VAM server are
the same as those for the primary VAM server and are thus omitted.
3)
Configure Hub 1
<Hub1> system-view


z

[Hub1-ipsec -proposal-vam] encapsulation-mode tunnel
[Hub1-ipsec -proposal-vam] transform esp
[Hub1-ipsec -proposal-vam] esp encryption-algorithm des
[Hub1-ipsec -proposal-vam] esp authentication-algorithm sha1
[Hub1-ipsec -proposal-vam] quit

[Hub1] ike peer vam

z
Configure DVPN tunnels.

1-34

[Hub1-Tunnel1] ospf network-type p2mp
[Hub1-Tunnel1] quit
z
Configure OSPF

[Hub1] ospf 100

[Hub1] ospf 200
4)
Configure Hub 2
<Hub2> system-view


z


[Hub2] ike peer vam

1-35
z

[Hub2-Tunnel1] ospf network-type p2mp
[Hub2-Tunnel1] quit
z
Configure OSPF

[Hub2] ospf 100

[Hub2] ospf 200
5)
Configure Spoke 1


z



1-36

z

[Spoke1-Tunnel1] ospf network-type p2mp
z
Configure OSPF

[Spoke1] ospf 100

[Spoke1] ospf 200
6)
Configure Spoke 2


z


1-37


z

[Spoke2-Tunnel1] ospf network-type p2mp
z
Configure OSPF

[Spoke2] ospf 100

[Spoke2] ospf 200
7)
# Display the address mapping information of all VAM clients registered with the primary VAM server
(main).
[MainServer] display vam server address-map all
VPN name: 1
Private-ip
Public-ip
Type
Holding time
10.0.1.1
192.168.1.1
Hub
0H 7M 35S
10.0.1.2
192.168.1.2
Hub
0H 13M 8S
10.0.1.3
192.168.1.3
Spoke
0H 3M 58S
10.0.1.4
192.168.1.4
Spoke
0H 0M 29S
# Display the address mapping information of all VAM clients registered with the secondary VAM
server (backup).
[BackupServer] display vam server address-map all
VPN name: 1
1-38
Private-ip
Public-ip
Type
Holding time
10.0.1.1
192.168.1.1
Hub
0H 8M 46S
10.0.1.2
192.168.1.2
Hub
0H 14M 58S
10.0.1.3
192.168.1.3
Spoke
0H 5M 9S
10.0.1.4
192.168.1.4
Spoke
0H 1M 40S
The above output indicates that Hub 1, Hub 2, Spoke 1, and Spoke 2 all have registered their address
mapping information with the VAM servers.
# Display the DVPN tunnel information of Hub 1.
[Hub1] display dvpn session all
Private IP:
10.0.1.2
Public IP:
192.168.1.2
Session type:
Hub-Hub
State: SUCCESS
Private IP:
10.0.1.3
Public IP:
192.168.1.3
Session type:
Hub-Spoke
State: SUCCESS
Private IP:
10.0.1.4
Public IP:
192.168.1.4
Session type:
Hub-Spoke
State: SUCCESS
The above information indicates that in VPN 1, Hub 1 has established a permenent tunnel with Hub 2,
Spoke 1, and Spoke 2 respectively. The DVPN tunnel information of Hub 2 is similar to that of Hub 1.
Private IP:
10.0.1.1
Public IP:
192.168.1.1
Session type:
Spoke-Hub
State: SUCCESS
1-39

Private IP:
10.0.1.2
Public IP:
192.168.1.2
Session type:
Spoke-Hub
State: SUCCESS
The above information indicates that in VPN 1, Spoke 1 has established a permenent Hub-Spoke
tunnel with Hub 1 and Hub 2 respectively. The DVPN tunnel information of Spoke 2 is similar to that of
Spoke 1.
# On Spoke 1, ping private address 10.0.3.1 of Spoke 2.
[Spoke1] ping 10.0.3.1
0.00% packet loss

Private IP:
10.0.2.1
Public IP:
192.168.1.1
Session type:
Spoke-Hub
State: SUCCESS
Private IP:
10.0.2.2
Public IP:
192.168.1.2
Session type:
Spoke-Hub
State: SUCCESS
1-40
The above information indicates that Spoke 1 and Spoke 2 have no dynamic Spoke-Spoke tunnel
established between them, and they exchange data through the Hub.
1-41
GRE Configuration
Support for some features on the MSR series is shown below:
Feature
GRE-IPSec tunnel application
MSR 900
Yes
MSR 20-1X
Yes
MSR 20
Yes
MSR 30
Yes
MSR 50
Yes
When configuring GRE, go to these sections for information you are interested in:
z
GRE Overview
Configuring a GRE over IPv4 Tunnel
Displaying and Maintaining GRE
GRE over IPv4 Tunnel Configuration Examples
Troubleshooting GRE
GRE Overview
Introduction to GRE
Generic Routing Encapsulation (GRE) is a protocol designed for encapsulating and carrying the
packets of one network layer protocol (for example, IP or IPX) over another network layer protocol (for
example, IP). GRE is a tunneling technology and serves as a Layer 3 tunneling protocol.
A GER tunnel is a virtual point-to-point connection for transferring encapsulated packets. Packets are
encapsulated at one end of the tunnel and de-encapsulated at the other end. Figure 2-1 depicts the
encapsulation and de-encapsulation processes.
Figure 2-1 X protocol networks interconnected through the GRE tunnel
2-1
The following takes the network shown in Figure 2-1 as an example to describe how an X protocol
packet traverses the IP network through a GRE tunnel.
Encapsulation process
1)
After receiving an X protocol packet through the interface connected to Group 1, Router A submits
it to the X protocol for processing.
2)
The X protocol checks the destination address field in the packet header to determine how to
route the packet.
3)
If the packet must be tunneled to reach its destination, Router A sends it to the tunnel interface.
4)
Upon receipt of the packet, the tunnel interface encapsulates it in a GRE packet. Then, the system
encapsulates the packet in an IP packet and forwards the IP packet based on its destination
address and the routing table.
Format of an encapsulated packet

Figure 2-2 shows the format of an encapsulated packet.
Figure 2-2 Format of an encapsulated packet
As an example, Figure 2-3 shows the format of an X packet encapsulated for transmission over an IP
tunnel.
Figure 2-3 Format of an X packet encapsulated for transmission over an IP tunnel
These are the terms involved:

z
Payload: Packet that needs to be encapsulated and transmitted.
Passenger protocol: Protocol that the payload packet uses, IPX in the example.
Encapsulation or carrier protocol: Protocol used to encapsulate the payload packet, that is, GRE.
Delivery or transport protocol: Protocol used to encapsulate the GRE packet and then forward the
packet to the other end of the tunnel, IP in this example.
Depending on the transport protocol, two tunnel modes are present: GRE over IPv4 and GRE over
IPv6.
De-encapsulation process
De-encapsulation is the reverse process of encapsulation:
1)
Upon receiving an IP packet from the tunnel interface, Router B checks the destination address.
2-2
2)
If the destination is itself, Router B strips off the IP header of the packet and submits the resulting
packet to the GRE protocol.
3)
The GRE protocol checks the key, checksum and sequence number in the packet, and then strips
off the GRE header and submits the payload to the X protocol for forwarding.
Encapsulation and de-encapsulation processes on both ends of the GRE tunnel and the resulting
increase in data volumes will degrade the forwarding efficiency for the GRE-enabled device to some
extent.
GRE Security Options

For the purpose of tunnel security, GRE provides two options: tunnel interface key and end-to-end
checksum.
According to RFC 1701,
z
If the Key Present field of a GRE packet header is set to 1, the Key field will carry the key for the
receiver to authenticate the source of the packet. This key must be the same at both ends of a
tunnel. Otherwise, packets delivered over the tunnel will be discarded.
If the Checksum Present bit of a GRE packet header is set to 1, the Checksum field contains valid
information. The sender calculates the checksum for the GRE header and the payload and sends
the packet containing the checksum to the peer. The receiver calculates the checksum for the
received packet and compares it with that carried in the packet. If the checksums are the same,
the receiver considers the packet intact and continues to process the packet. Otherwise, the
receiver discards the packet.
GRE Applications
GRE supports these types of applications:
z
Multi-protocol communications through a single-protocol backbone
Scope enlargement of a hop-limited protocol
VPN creation by connecting discontinuous subnets
GRE-IPsec tunnel application
2-3
Multi-protocol communications through a single-protocol backbone

Figure 2-4 Multi-protocol communications through a single-protocol backbone
In the example shown in Figure 2-4, Group 1 and Group 2 are local networks running Novell IPX, and
Team 1 and Team 2 are local networks running IP. Through the GRE tunnel between Router A and
Router B, Group 1 can communicate with Group 2 and Team 1 can communicate with Team 2. They
will not interfere with each other.
Scope enlargement of a hop-limited protocol such as RIP

Figure 2-5 Network scope enlargement
When the hop count between two terminals exceeds 15, the terminals cannot communicate with each
other. Using GRE, you can hide some hops so as to enlarge the scope of the network.
VPN creation by connecting discontinuous subnets

Figure 2-6 Connect discontinuous subnets with a tunnel to form a VPN
2-4
In the example as shown in Figure 2-6, Group 1 and Group 2 running Novell IPX are deployed in
different cities. They can constitute a trans-WAN virtual private network (VPN) through the tunnel.
GRE-IPsec tunnel application

Figure 2-7 GRE-IPsec tunnel application
GRE can work with IPsec, allowing data packets like routing protocol, voice, and video packets to be
encapsulated by GRE and then encrypted by IPsec to improve security of data transmission in a
tunnel.
Support for the cooperation of GRE and IPsec depends on the device model.
Protocols and Standards

z
RFC 1701: Generic Routing Encapsulation (GRE)
RFC 1702: Generic Routing Encapsulation over IPv4 networks
RFC 2784: Generic Routing Encapsulation (GRE)

Interfaces on a device, such as VLAN interfaces, Ethernet interfaces, and loopback interfaces, are
configured with IPv4 addresses and can communicate. These interfaces can be used as the source of
a virtual tunnel interface to ensure the reachability of the tunnel destination address.
Follow these steps to configure a GRE over IPv4 tunnel:
To do
Enter system view
Use the command

system-view
Remarks
Required

tunnel interface view
interface tunnel interface-number
By default, a device has no tunnel

interface.
2-5
Required
Configure an IPv4 address for the
tunnel interface
mask-length }
By default, a tunnel interface has

no IPv4 address.
Optional
Set the tunnel mode to GRE over

IPv4
with the device model.

tunnel-protocol gre
Note that you need to configure

the same tunnel mode on both
ends of a tunnel. Otherwise,
packet delivery will fail.
Required
Configure the source address or
source { ip-address |
By default, no source address or
interface for the tunnel interface
interface is configured for a tunnel

interface.
Required
Configure the destination address

destination ip-address
By default, no destination address

is configured for a tunnel interface.
Enable GRE keepalive and set the

interval and the maximum number
Optional
keepalive [ seconds [ times ] ]
Disabled by default
of transmission attempts
Enable the GRE packet checksum
function
Optional
gre checksum
Disabled by default
Optional
By default, no key is configured for
Configure the key for the GRE

tunnel interface
gre key key-number
a GRE tunnel interface.

have the same key or have no key
at the same time.
Optional
Configure a route through the

tunnel
Refer to the IP Routing Volume.
Each end of the tunnel must have

a route (static or dynamic) through
the tunnel to the other end.
Enable the expedite termination

function
Optional
expediting enable
Disabled by default
Optional
Specify the IP address and mask
expediting subnet ip-address
for the expedite termination subnet
mask
No expedite termination subnet is

configured by default.
Note that:
2-6
Support for commands expediting enable and expediting subnet depends on the device model.
For details about tunnel interfaces and more configuration commands in a tunnel interface, refer to
Tunneling Configuration in the IP Services Volume. For details about the expedite termination
function, refer to Tunneling Configuration in the IP Services Volume.
For information about commands interface tunnel, tunnel-protocol, source, destination,

expediting enable, and expediting subnet, refer to Tunneling Commands in the IP Services
Volume.
The source address and destination address of a tunnel uniquely identify a path. They must be
configured at both ends of the tunnel and the source address at one end must be the destination
address at the other end and vice versa.
Tunnel interfaces using the same encapsulation protocol must have different source addresses
and destination addresses.
If you configure a source interface for a tunnel interface, the tunnel interface takes the primary IP
address of the source interface as its source address.
You can enable or disable the checksum function at both ends of the tunnel as needed. If the
checksum function is enabled at the local end but not at the remote end, the local end calculates
the checksum of a packet to be sent but does not check the checksum of a received packet.
Contrarily, if the checksum function is enabled at the remote end but not at the local end, the local
end checks the checksum of a received packet but does not calculate the checksum of a packet to
be sent.
When configuring a route through the tunnel, you can configure a static route, using the address of
the network segment that the original packet is destined for as its destination address and the
address of the peer tunnel interface as its next hop. Or, you can enable a dynamic routing protocol
on both the tunnel interface and the router interface connecting the private network, so that the
dynamic routing protocol can establish a routing entry that allows the tunnel to forward packets
through the tunnel. It is not allowed to set up a static route whose destination address is in the
subnet of the tunnel interface.

Interfaces on a device, such as VLAN interfaces, Ethernet interfaces, and loopback interfaces, are
configured with IPv6 addresses and can communicate. These interfaces can serve as the source of a
virtual tunnel interface to ensure the reachability of the destination address.
Follow these steps to configure a GRE over IPv6 tunnel:
To do
Enter system view
Enable the IPv6 packet forwarding
function
Use the command

system-view
Remarks
Required
ipv6
Disabled by default
Required

tunnel interface view
interface tunnel interface-number
By default, there is no tunnel

interface on a device.
2-7
Required
Configure an IPv4 address for the
tunnel interface
mask-length }
By default, no IPv4 address is

configured for a tunnel interface.
Required
Set the tunnel mode to GRE over

IPv6.
with the device model.

tunnel-protocol gre ipv6
Note that you need to configure

the same tunnel mode on both
ends of a tunnel. Otherwise,
packet delivery will fail.
Required
Configure the source address or
source { ipv6-address |
By default, no source address or
interface for the tunnel interface
interface is configured for a tunnel

interface.
Required
Configure the destination address

destination ipv6-address
By default, no destination address

is configured for a tunnel interface.
Set the maximum number of

encapsulations in the tunnel
Enable the GRE packet checksum
function
Optional
encapsulation-limit [ number ]
4 by default
Optional
gre checksum
Disabled by default
Optional
By default, no key is configured for
Configure the key for the GRE

tunnel interface
gre key key-number
a GRE tunnel interface.

have the same key or have no key
at the same time.
Optional
Configure a route through the

tunnel
Refer to the IP Routing Volume.
Each end of the tunnel must have

a route (static or dynamic) through
the tunnel to the other end.
Note that:
z
For information about commands interface tunnel, tunnel-protocol, source, destination, and
encapsulation-limit, refer to Tunneling Commands in the IP Services Volume.
For details about tunnel interfaces and more configuration commands in a tunnel interface, refer to
Tunneling Configuration in the IP Services Volume.
If you delete a tunnel interface, the functions configured on this tunnel interface will be removed as
well.
2-8
The source address and destination address of a tunnel uniquely identify a path. They must be
configured at both ends of the tunnel and the source address at one end must be the destination
address at the other end and vice versa.
Tunnel interfaces using the same encapsulation protocol must have different source addresses
and destination addresses.
If you configure a source interface for a tunnel interface, the tunnel interface takes the primary IP
address of the source interface as its source address.
You can enable or disable the checksum function at both ends of the tunnel as needed. If the
checksum function is enabled at the local end but not at the remote end, the local end calculates
the checksum of a packet to be sent but does not check the checksum of a received packet.
Contrarily, if the checksum function is enabled at the remote end but not at the local end, the local
end checks the checksum of a received packet but does not calculate the checksum of a packet to
be sent.
When configuring a route through the tunnel, you can configure a static route, using the address of
the network segment the original packet is destined for as its destination address and the address
of the peer tunnel interface as its next hop. Or, you can enable a dynamic routing protocol on both
the tunnel interface and the router interface connecting the private network, so that the dynamic
routing protocol can establish a routing entry that allows the tunnel to forward packets through the
tunnel. It is not allowed to set up a static route whose destination address is in the subnet of the
tunnel interface.
Displaying and Maintaining GRE

To do
Use the command
Display information about a
display interface tunnel
specified or all tunnel interfaces
[ number ]
Display IPv6 information about a
display ipv6 interface tunnel
tunnel interface
[ number ] [ verbose ]
Remarks
Support for the display ipv6 interface tunnel command depends on the device model.
For information about commands display interface tunnel and display ipv6 interface tunnel,
refer to Tunneling Commands in the IP Services Volume.

GRE over IPv4 Tunnel Configuration Example (on Routers)
Router A and Router B are interconnected through the Internet. Two private IPv4 subnets Group 1 and
Group 2 are interconnected through a GRE tunnel between the two routers.
2-9
Figure 2-8 Network diagram for a GRE over IPv4 tunnel (on routers)
Before the configuration, make sure that Router A and Router B are reachable to each other.
1)
Configure Router A
# Configure an IPv4 address for interface Ethernet 1/1.

<RouterA> system-view
[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ip address 10.1.1.1 255.255.255.0
[RouterA-Ethernet1/1] quit
# Configure an IPv4 address for interface Serial 2/0, the physical interface of the tunnel.
[RouterA] interface serial 2/0
[RouterA-Serial2/0] ip address 1.1.1.1 255.255.255.0
[RouterA-Serial2/0] quit
# Create an interface named Tunnel 0.

[RouterA] interface tunnel 0
# Configure an IPv4 address for interface Tunnel 0.

[RouterA-Tunnel0] ip address 10.1.2.1 255.255.255.0
# Configure the tunnel encapsulation mode.

[RouterA-Tunnel0] tunnel-protocol gre
# Configure the source address of interface Tunnel 0 to be the IP address of Serial 2/0.
[RouterA-Tunnel0] source 1.1.1.1
# Configure the destination address of interface Tunnel 0 to be the IP address of Serial 2/1 on Router
B.
[RouterA-Tunnel0] destination 2.2.2.2
[RouterA-Tunnel0] quit
# Configure a static route from Router A through interface Tunnel 0 to Group 2.

[RouterA] ip route-static 10.1.3.0 255.255.255.0 tunnel 0
2)
Configure Router B

<RouterB> system-view
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] ip address 10.1.3.1 255.255.255.0
[RouterB-Ethernet1/1] quit
[RouterB] interface serial 2/1
[RouterB-Serial2/1] ip address 2.2.2.2 255.255.255.0
2-10
[RouterB-Serial2/1] quit

[RouterB] interface tunnel 0
# Configure an IP address for interface Tunnel 0.

[RouterB-Tunnel0] ip address 10.1.2.2 255.255.255.0

[RouterB-Tunnel0] tunnel-protocol gre
# Configure the source address of interface Tunnel 0 to be the IP address of interface Serial 2/1.
[RouterB-Tunnel0] source 2.2.2.2
# Configure the destination address of interface Tunnel 0 to be the IP address of interface Serial 2/0 on
Router A.
[RouterB-Tunnel0] destination 1.1.1.1
[RouterB-Tunnel0] quit
# Configure a static route from Router B through interface Tunnel 0 to Group 1.

[RouterB] ip route-static 10.1.1.0 255.255.255.0 tunnel 0
3)
# After the above configuration, display the tunnel infterface status on Router A and Router B
respectively.
[RouterA] display interface tunnel 0
Tunnel0 current state: UP
Line protocol current state: UP
Description: Tunnel0 Interface
The Maximum Transmit Unit is 1476
Internet Address is 10.1.2.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set.
Tunnel source 1.1.1.1, destination 2.2.2.2
Tunnel keepalive disabled
Tunnel protocol/transport GRE/IP
GRE key disabled
Checksumming of GRE packets disabled
Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0
Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0
Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0
Last clearing of counters: Never
Last 300 seconds input: 0 bytes/sec, 0 packets/sec
Last 300 seconds output: 0 bytes/sec, 0 packets/sec
10 packets input, 840 bytes
0 input error
10 packets output, 840 bytes
0 output error
[RouterB] display interface tunnel 0
GRE key disabled
2-11

0 input error
0 output error
# From Router B, you can ping the IP address of Ethernet 1/1 on Router A.
[RouterB] ping 10.1.1.1

0.00% packet loss
GRE over IPv4 Tunnel Configuration Example (on Switches)

Switch A and Switch B are interconnected through the Internet. Two private IPv4 subnets Group 1 and
Group 2 are interconnected through a GRE tunnel between the two switches.
Figure 2-9 Network diagram for a GRE over IPv4 tunnel (on switches)
Before the configuration, make sure that Switch A and Switch B are reachable to each other.
1)
Configure Switch A

<SwitchA> system-view
2-12
[SwitchA] vlan 100

[SwitchA-vlan100] port ethernet 1/1
[SwitchA-vlan100] quit
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] ip address 10.1.1.1 255.255.255.0
[SwitchA-Vlan-interface100] quit
# Configure an IPv4 address for interface Ethernet 1/2, the physical interface of the tunnel.
[SwitchA] vlan 101

[SwitchA] interface tunnel 1

[SwitchA-Tunnel1] ip address 10.1.2.1 255.255.255.0

[SwitchA-Tunnel1] tunnel-protocol gre
# Configure the source address of interface Tunnel 1 to be the IP address of the VLAN interface of
interface Ethernet 1/2.
[SwitchA-Tunnel1] source vlan-interface 101
# Configure the destination address for interface Tunnel 1 (IP address of the VLAN interface to which
Ethernet 1/2 of Switch B belongs).
[SwitchA-Tunnel1] destination 2.2.2.2
[SwitchA-Tunnel1] quit
# Create service loopback group 1, setting the service type to tunnel.

[SwitchA] service-loopback group 1 type tunnel
# Add interface Ethernet 1/3 to service loopback group 1.

[SwitchA] interface ethernet 1/3
[SwitchA-Ethernet1/3] undo stp enable
[SwitchA-Ethernet1/3] port service-loopback group 1
# Apply service loopback group 1 to the tunnel in tunnel interface view.

[SwitchA-Ethernet1/3] quit
[SwitchA-Tunnel1] service-loopback-group 1
# Configure a static route from Switch A through interface Tunnel 1 to Group 2.

[SwitchA] ip route-static 10.1.3.0 255.255.255.0 tunnel 1
2)
Configure Switch B

<SwitchB> system-view
[SwitchB] vlan 100
[SwitchB-vlan100] port ethernet 1/1
[SwitchB-vlan100] quit
[SwitchB] interface vlan-interface 100
[SwitchB-Vlan-interface100] ip address 10.1.3.1 255.255.255.0
[SwitchB-Vlan-interface100] quit
# Configure an IPv4 address for interface Ethernet 1/2, the physical interface of the tunnel.
[SwitchB] vlan 101
2-13


[SwitchB] interface tunnel 1

[SwitchB-Tunnel1] ip address 10.1.2.2 255.255.255.0

[SwitchB-Tunnel1] tunnel-protocol gre
# Configure the source address for interface Tunnel 1 (IP address of the VLAN interface to which
Ethernet 1/2 belongs).
[SwitchB-Tunnel1] source vlan-interface 101
# Configure the destination address for interface Tunnel 1 (IP address of the VLAN interface to which
Ethernet 1/2 of Switch A belongs).
[SwitchB-Tunnel1] destination 1.1.1.1
[SwitchB-Tunnel1] quit

[SwitchB] service-loopback group 1 type tunnel

[SwitchB] interface ethernet 1/3
[SwitchB-Ethernet1/3] undo stp enable
[SwitchB-Ethernet1/3] port service-loopback group 1

[SwitchB-Ethernet1/3] quit
[SwitchB-Tunnel1] service-loopback-group 1
# Configure a static route from Switch B through interface Tunnel 1 to Group 1.

[SwitchB] ip route-static 10.1.1.0 255.255.255.0 Tunnel 1
3)
# After the above configuration, view the tunnel interface status on Switch A and Switch B respectively.
[SwitchA] display interface tunnel 1
Encapsulation is TUNNEL, service-loopback-group ID is 1.
GRE key disabled
2-14

0 input error
0 output error
[SwitchB] display interface tunnel 1
GRE key disabled
0 input error
0 output error
# From Switch B, you can ping the IP address of VLAN-interface 100 on Switch A.
[SwitchB] ping 10.1.1.1

0.00% packet loss

GRE over IPv6 Tunnel Configuration Example (on Routers)
Two IPv4 subnets Group 1 and Group 2 are interconnected through a GRE tunnel over the IPv6
network between Router A and Router B.
2-15
Figure 2-10 Network diagram for a GRE over IPv6 tunnel (on routers)
Before the configuration, make sure that Router A and Router B are reachable to each other.
1)
Configure Router A
<RouterA> system-view
# Enable IPv6.
[RouterA] ipv6

[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] ip address 10.1.1.1 255.255.255.0
[RouterA-Ethernet1/1] quit
[RouterA] interface serial 2/0
[RouterA-Serial2/0] ipv6 address 2002::1:1 64
[RouterA-Serial2/0] quit

[RouterA] interface tunnel 0

[RouterA-Tunnel0] ip address 10.1.2.1 255.255.255.0

[RouterA-Tunnel0] tunnel-protocol gre ipv6
[RouterA-Tunnel0] source 2002::1:1
Router B).
[RouterA-Tunnel0] destination 2002::2:1
[RouterA-Tunnel0] quit
# Configure a static route from Router A through interface Tunnel 0 to Group 2.

2)
Configure Router B
<RouterB> system-view
# Enable IPv6.
[RouterB] ipv6

[RouterB] interface ethernet 1/1
2-16
[RouterB-Ethernet1/1] ip address 10.1.3.1 255.255.255.0

[RouterB-Ethernet1/1] quit
# Configure an IPv6 address for interface Serial 2/1, the physical interface of the tunnel).
[RouterB] interface serial 2/1
[RouterB-Serial2/1] ipv6 address 2002::2:1 64
[RouterB-Serial2/1] quit

[RouterB] interface tunnel 0

[RouterB-Tunnel0] ip address 10.1.2.2 255.255.255.0

[RouterB-Tunnel0] tunnel-protocol gre ipv6
[RouterB-Tunnel0] source 2002::2:1
Router A.
[RouterB-Tunnel0] destination 2002::1:1
[RouterB-Tunnel0] quit
# Configure a static route from Router B through interface Tunnel 0 to Group 1.

[RouterB] ip route-static 10.1.1.0 255.255.255.0 tunnel 0
3)
# After the above configuration, display the tunnel infterface status on Router A and Router B
respectively.
[RouterA] display interface Tunnel 0
Tunnel source 2002::1:1, destination 2002::2:1
Tunnel protocol/transport GRE/IPv6
GRE key disabled
0 input error
0 output error
[RouterB] display interface Tunnel 0
2-17

GRE key disabled
0 input error
0 output error
# From Router B, you can ping the IP address of Ethernet 1/1 on Router A.
[RouterB] ping 10.1.1.1

0.00% packet loss
GRE over IPv6 Tunnel Configuration Example (on Switches)

Two IPv4 subnets Group 1 and Group 2 are interconnected through a GRE tunnel over the IPv6
network between Switch A and Switch B.
Figure 2-11 Network diagram for a GRE over IPv6 tunnel (on switches)
Before the configuration, make sure that Switch A and Switch B are reachable to each other.
2-18
1)
Configure Switch A
<SwitchA> system-view
# Enable IPv6.
[SwitchA] ipv6
# Configure interface VLAN-interface 100.

[SwitchA] vlan 100
# Configure interface VLAN-interface 101, the physical interface of the tunnel.

[SwitchA] vlan 101
[SwitchA-Vlan-interface101] ipv6 address 2002::1:1 64


[SwitchA-Tunnel0] ip address 10.1.2.1 255.255.255.0

[SwitchA-Tunnel0] tunnel-protocol gre ipv6
# Configure the source address of interface Tunnel 0 to be the IP address of interface VLAN-interface
100.
[SwitchA-Tunnel0] source 2002::1:1
# Configure the destination address of interface Tunnel 0 to be the IP address of interface

VLAN-interface 101 on Switch B.
[SwitchA-Tunnel0] destination 2002::2:1

[SwitchA] service-loopback group 1 type tunnel

[SwitchA] interface ethernet 1/3
[SwitchA-Ethernet1/3] undo stp enable
[SwitchA-Ethernet1/3] port service-loopback group 1

[SwitchA-Ethernet1/3] quit
[SwitchA-Tunnel0] service-loopback-group 1
# Configure a static route from Switch A through interface Tunnel 0 to Group 2.

[SwitchA] ip route-static 10.1.3.0 255.255.255.0 tunnel 0
2)
Configure Switch B
<SwitchB> system-view
# Enable IPv6.
[SwitchB] ipv6
2-19
# Configure interface VLAN-interface 100.

[SwitchB] vlan 100
# Configure interface VLAN-interface 101, the physical interface of the tunnel.

[SwitchB] vlan 101
[SwitchB-Vlan-interface101] ipv6 address 2002::2:1 64


[SwitchB-Tunnel0] ip address 10.1.2.2 255.255.255.0

[SwitchB-Tunnel0] tunnel-protocol gre ipv6
# Configure the source address of interface Tunnel 0 to be the IP address of interface VLAN-interface
101.
[SwitchB-Tunnel0] source 2002::2:1
# Configure the destination address of interface Tunnel 0 to be the IP address of interface

VLAN-interface 101 on Switch A.
[SwitchB-Tunnel0] destination 2002::1:1
[SwitchB-Tunne10] quit

[SwitchB] service-loopback group 1 type tunnel

[SwitchB] interface ethernet 1/3
[SwitchB-Ethernet1/3] undo stp enable
[SwitchB-Ethernet1/3] port service-loopback group 1

[SwitchB-Ethernet1/3] quit
[SwitchB-Tunnel0] service-loopback-group 1
# Configure a static route from Switch B through interface Tunnel 0 to Group 1.

[SwitchB] ip route-static 10.1.1.0 255.255.255.0 tunnel 0
3)
Verify the configuraion
# After the above configuration, view the tunnel interface status on Switch A and Switch B respectively.
[SwitchA] display interface Tunnel 0
2-20

GRE key disabled
0 input error
0 output error
[SwitchB] display interface Tunnel 0
GRE key disabled
0 input error
0 output error
# From Switch B, you can ping the IP address of VLAN-interface 100 on Switch A.
[SwitchB] ping 10.1.1.1

0.00% packet loss
2-21
Troubleshooting GRE
The key to configuring GRE is to keep the configurations consistent. Most faults can be located by
using the debugging gre or debugging tunnel command. This section analyzes one type of fault for
illustration, with the scenario shown in Figure 2-12.
Figure 2-12 Troubleshoot GRE
Symptom: The interfaces at both ends of the tunnel are configured correctly and can ping each other,
but Host A and Host B cannot ping each other.
Solution:
z
On Router A and Router C, execute the display ip routing-table command in any view
respectively. On Router A, observe whether there is a route from Router A through Tunnel 0 to
10.2.0.0/16. On Router C, observe whether there is a route from Router C through Tunnel 0 to
10.1.0.0/16.
If an expected static route is missing, use the route-static command in system view to configure.
For example, configure a static route on Router A as follows:
2-22
L2TP Configuration
When configuring L2TP, go to these sections for information you are interested in:
z
L2TP Overview
L2TP Configuration Task List
Displaying and Maintaining L2TP
L2TP Configuration Examples
Troubleshooting L2TP
The term router and the router icon in this document refer to a router in a generic sense or a Layer 3
switch.
L2TP Overview
This section covers these topics:
z
Introduction
Basic Concepts of L2TP
L2TP Tunnel Modes and Tunnel Establishment Process
L2TP Features
Introduction
A virtual private dial-up network (VPDN) is a virtual private network (VPN) that utilizes the dial-up
function of public networks such as ISDN or PSTN networks to provide access services for enterprises,
small Internet service providers (ISPs), and telecommuters. VPDN provides an economical and
effective, point-to-point way for remote users to connect to their home LANs.
The VPDN technology uses a specialized network communication protocol to build secure VPNs
across public networks for enterprises. Branches away from the headquarters and staff on business
3-1
can remotely access the Intranet resources in the headquarters through a virtual tunnel over public
networks, while other users on the public networks cannot.
A VPDN tunnel can be NAS-initiated or client-initiated:
z
NAS-initiated VPDN tunnel. The network access server (NAS) connects a users PPP connection
to the corporate VPDN gateway through a VPDN tunneling protocol, establishing a tunnel with the
VPDN gateway. The tunneling is transparent to users. A user only needs to perform login
operation once to access the enterprise network, which authenticates the user and assigns the
user a private IP address, eliminating the necessity of the user for a public address. This mode
requires that the NAS support VPDN and the authentication system support VPDN attributes.
Client-initiated VPDN tunnel. A user accesses the Internet first, and then establishes a tunnel with
the VPDN gateway through a piece of dedicated client software, such as the L2TP client offered
by Windows 2000. In this mode, a user can access the enterprise network anytime from any place,
without the involvement of any ISP. However, users must install dedicated software, which means
that they must use platforms supporting L2TP client. Usually, Windows 2000 platform is used.
In general, a VPDN gateway can be a router or a dedicated VPN server.

There are primarily three VPDN tunneling protocols:
z
PPTP: Point-to-Point Tunneling Protocol
L2F: Layer 2 Forwarding
L2TP: Layer 2 Tunneling Protocol.
L2TP is currently the most widely-used VPDN tunneling protocol.
Typical L2TP Networking Application

Figure 3-1 shows a typical VPDN built by using L2TP.
Figure 3-1 VPDN built by using L2TP
A VPDN built by using L2TP consists of three components:

z
Remote system
A remote system is usually the host of a remote user or the routing device of a remote branch that
needs to access the VPDN network.
z
LAC
An L2TP access concentrator (LAC) is a device that is attached to a packet-switched network and has
a PPP end system and the L2TP capability. An LAC is usually a NAS located at a local ISP, which
provides access services mainly for PPP users.
3-2
An LAC lies between an LNS and a remote system. Upon receiving a packet from a remote system, it
encapsulates the packet by using L2TP and sends the resulting packet to the LNS. Upon receiving a
packet from an LNS, it de-encapsulates the packet and sends it to the intended remote system.
Between an LAC and a remote system is a local connection or a PPP link. Usually, a PPP link is used
in a VPDN application.
z
LNS
An L2TP network server (LNS) is a device providing the L2TP server side services on a PPP end
system. It is usually an edge device of an enterprise network.
As an end system of an L2TP tunnel, an LNS is the peer of an LAC. It is the logical termination point of
a PPP session that is tunneled by the LAC. That is, with L2TP, the logical termination point of a PPP
session is moved from an LAC to an LNS, which resides on the enterprise network.
Basic Concepts of L2TP

Background of L2TP
The point-to-Point Protocol (PPP) defines an encapsulation mechanism that allows a point-to-point link
to carry packets of various protocols. When PPP runs between a user and a NAS, the PPP session
terminates at the same physical device where the Layer 2 link terminates, that is, the NAS.
L2TP is intended to tunnel PPP packets. It extends the PPP model by allowing the Layer 2 link
endpoint and the PPP session endpoint to reside on different devices interconnected by a
packet-switched network. This allows PPP sessions to cross a Frame Relay network or the Internet.
Combining the advantages of L2F and PPTP, L2TP has become the Layer 2 tunneling industry
standard of the Internet Engineering Task Force (IETF).
L2TP architecture
Figure 3-2 shows the relationship between the PPP frame, control channel, and data channel. PPP
frames are transferred over the unreliable L2TP data channels, while control messages are transferred
within the reliable L2TP control channels.
Figure 3-2 L2TP architecture
Figure 3-3 L2TP packet encapsulation structure
Figure 3-3 depicts the encapsulation structure of an L2TP data packet between the LAC and the LNS.
Usually, L2TP data is transferred in the form of User Data Protocol (UDP) packets. The well-known
UDP port for L2TP is 1701, which is only used in the initial tunnel creation stage. The L2TP tunnel
initiator selects an idle port (which may not be 1701) to send a packet to port 1701 of the receiver. After
receiving the packet, the receiver also selects an idle port (which may not be 1701 either) to return a
3-3
packet to the specified port of the initiator. From then on, the two parties use the negotiated ports to
communicate until the tunnel is disconnected.
Tunnel and session

Two types of connections are present between an LNS and an LAC: tunnel and session.
z
A tunnel is between an LNS and an LAC.
A session is multiplexed on a tunnel and represents a PPP session on the tunnel.
Multiple L2TP tunnels can be established between an LNS and an LAC. A tunnel consists of a control
connection and one or more sessions. A session can be set up only after the tunnel is created. A
session corresponds to one PPP data stream between the LAC and the LNS.
Both control messages and PPP frames are transferred on the tunnel. L2TP uses Hello packets to
check the connectivity of a tunnel. The LAC and LNS regularly send Hello packets to each other. If no
response packet is received in a certain period of time, the tunnel is torn down.
Control message and data message

L2TP supports two types of messages: control messages and data messages.
z
Control messages are intended for establishment and maintenance of tunnels and sessions and
for transmission control. Control messages are transmitted over a reliable channel, which
supports flow control and congestion control.
Data messages are intended to encapsulate PPP frames to be tunneled. Data messages are
transmitted over an unreliable channel without flow control, congestion control, and
retransmission mechanisms.
Control messages and data messages share the same header structure. An L2TP header contains a
tunnel ID and a session ID, which are used to identify the tunnel and session respectively. Packets with
the same tunnel ID but different session IDs are multiplexed to the same tunnel. The tunnel ID and
session ID in a header are those of the intended receiver, not the sender.
L2TP Tunnel Modes and Tunnel Establishment Process

Two typical L2TP tunnel modes
There are two typical L2TP tunnel modes: NAS-initiated and client-initiated.
z
NAS-initiated
In this mode, a remote system dials in the LAC through a PPPoE/ISDN network, and the LAC initiates
a tunneling request to the LNS over the Internet, as shown in Figure 3-4. The LNS will assign the
remote system a private IP address. Authentication and accounting of remote systems can be
implemented on the LAC or on the LNS.
Figure 3-4 NAS-initiated tunnel mode
Client-initiated
3-4
In this mode, after being permitted to access the Internet, a remote system running the L2TP client
application (LAC client) initiates a tunneling request to the LNS directly without any dedicated LAC
device. The LNS will assign the LAC client a private IP address.
In this mode, a LAC client needs a public network address in order to communicate with the LNS
through the Internet.
Figure 3-5 Client-initiated tunnel mode
L2TP tunnel establishment process

Figure 3-6 shows a typical L2TP network.
Figure 3-6 Typical L2TP network
Figure 3-7 depicts the setup procedure of an L2TP call in NAS-initiated mode.
3-5
Figure 3-7 L2TP call setup procedure
The setup procedure of an L2TP call is as follows:

2)
The remote user (Host A) makes a PPP call.
3)
Host A and the LAC (Router A) perform PPP LCP negotiation.
4)
The LAC authenticates the remote user using the Password Authentication Protocol (PAP) or
Challenge Handshake Authentication Protocol (CHAP).
5)
The LAC sends the authentication information (the username and password) to its RADIUS server
for authentication.
6)
The LAC RADIUS server authenticates the user.
7)
If the user passes authentication, the LAC initiates a tunneling request to the LNS.
8)
If authentication of the tunnel is required, the LAC sends a CHAP challenge to the LNS. The LNS
returns a CHAP response and sends its CHAP challenge to the LAC. Accordingly, the LAC returns
a CHAP response to the LNS.
9)
The tunnel passes authentication.
10) The LAC sends the CHAP response, response identifier, and PPP negotiation parameters of the
user to the LNS.
11) The LNS sends an access request to its RADIUS server for authentication.
12) The RADIUS server authenticates the access request and returns a response if the user passes
authentication.
13) If the LNS is configured to perform a mandatory CHAP authentication of the user, the LNS sends
a CHAP challenge to the user and the user returns a CHAP response.
14) The LNS resends the access request to its RADIUS server for authentication.
15) The RADIUS server authenticates the access request and returns a response if the user passes
authentication.
16) The LNS assigns an internal IP address to the remote user. Now, the user can access the internal
resources of the enterprise network.
3-6
L2TP Features
1)
Flexible identity authentication mechanism and high security
L2TP itself does not provide security for connections. However, it has all the security features of PPP
for it allows for PPP authentication (CHAP or PAP). L2TP can also cooperate with IPsec to guarantee
data security, making tunneled data more resistant to attacks. In addition, tunnel encryption,
end-to-end data encryption, and end-to-end application-layer data encryption technologies can be
used together with L2TP for higher data security as required.
2)
Multi-protocol transmission
L2TP tunnels PPP frames, which can be used to encapsulate packets of multiple network layer
protocols.
3)
RADIUS authentication
An LAC and LNS can send the username and password of a remote user to a RADIUS server for
authentication.
4)
Private address allocation
An LNS can reside behind the firewall of a corporate network, dynamically allocating private addresses
to remote users and managing the corporate private addresses (RFC 1918). This facilitates address
management and improves security.
5)
Accounting flexibility
Accounting can be carried out on the LAC and LNS simultaneously, allowing bills to be generated on
the ISP side and charging and auditing to take place on the enterprise gateway. L2TP can provide
such accounting data as statistics on inbound and outbound traffic (in packets and bytes) and
connection start time and end time. All these enable flexible accounting.
6)
Reliability
L2TP supports LNS backup. When the connection to the primary LNS is torn down, an LAC can
establish a new one with a secondary LNS, enhancing the reliability and fault tolerance of VPN
services.

z
RFC 1661: The Point-to-Point Protocol (PPP)
RFC 1918: Address Allocation for Private Internets
RFC 2661: Layer Two Tunneling Protocol "L2TP"
L2TP Configuration Task List

To configure a device as an LAC or LNS, you need to configure basic L2TP capability on the device at
first, and then perform LAC- or LNS-specific configurations. L2TP connection parameter configuration
tasks apply to both LAC and LNS and are optional. You may configure them as needed.
Complete the following tasks to configure L2TP:
Task
Remarks
Enable L2TP
Configuring Basic L2TP
Capability
Create an L2TP group

Specify the local name of the tunnel
3-7
Required
Configuring an LAC to Initiate Tunneling Requests for Specified

Users
Configuring an LAC
Configuring an LNS
Required
Configuring an LAC to Transfer AVP Data in Hidden Mode
Optional
Configuring AAA Authentication of VPN Users on LAC Side
Required
Creating a Virtual Interface Template
Required
Configuring the Local Address and the Address Pool for Allocation
Required
Configuring an LNS to Grant Certain L2TP Tunneling Requests
Required
Configuring User Authentication on an LNS
Optional
Configuring AAA Authentication of VPN Users on LNS Side
Optional
Enabling L2TP Multi-Instance
Optional
Specifying to Send ACCM
Optional
Configuring L2TP Tunnel Authentication

Configuring L2TP
Setting the Hello Interval
Connection Parameters
Enabling Tunnel Flow Control
Optional
Disconnecting Tunnels by Force
Configuring Basic L2TP Capability

An L2TP group is intended to represent a group of parameters and corresponds to one VPN user or
one group of VPN users. This not only allows for flexible L2TP configuration on devices, but also
facilitates one-to-one and one-to-many networking applications of LACs and LNSs. An L2TP group has
only local significance. However, you need to ensure that the relevant settings of the corresponding
L2TP groups on the LAC and LNS match respectively. For example, the local tunnel name configured
on the LAC must match the remote tunnel name configured on the LNS.
L2TP must be enabled for L2TP configuration to take effect. Tunnel names are used during tunnel
negotiation between an LAC and an LNS.
Follow these steps to configure basic L2TP capability:
To do
Use the command
Enter system view
system-view
Enable L2TP
l2tp enable
Remarks
Required
Disabled by default
Create an L2TP group and enter

its view
Required
l2tp-group group-number
By default, no L2TP group exists.
3-8
Optional
Specify the local name of the
tunnel
tunnel name name
The system name of the device is

used by default.
Configuring an LAC
An LAC is responsible to establish tunnels with corresponding LNSs for users and sends user packets
to LNSs through the tunnels. Before configuring an LAC, you need to enable L2TP and create an L2TP
group.
Configuring an LAC to Initiate Tunneling Requests for Specified Users

An LAC initiates tunneling requests only to specified LNSs for specified users. You can specify the
users to be serviced and the LNSs to be connected with.
You can specify the users to be serviced by providing the fully qualified name or the domain name.
Follow these steps to configure the LAC:
To do
Use the command
Remarks
Enter system view
system-view
Enter L2TP group view
Enable the device to initiate

tunneling requests to one or more
IP addresses for one or more
specified VPN users
start l2tp { ip ip-address }&<1-5>

{ domain domain-name |
Required
fullusername user-name }
Up to five LNSs can be configured. The LAC initiates an L2TP tunneling request to its specified LNSs
one by one in their configuration order until it receives an acknowledgement from an LNS, which
becomes the tunnel peer.
Configuring an LAC to Transfer AVP Data in Hidden Mode

With L2TP, some parameters are transferred as attribute value pair (AVP) data. You can configure an
LAC to transfer AVP data in hidden mode, namely, encrypt AVP data before transmission, for higher
security.
Follow these steps to configure an LAC to transfer AVP data in hidden mode:
To do
Use the command
Remarks
Enter system view
system-view
3-9
Optional
Specify that AVP data be
transferred in hidden mode
tunnel avp-hidden
By default, AVP data is transferred

in plain text.
Configuring AAA Authentication of VPN Users on LAC Side

You can configure an LAC to perform AAA authentication of VPN users and initiate tunneling request
for only qualified users. No tunnel will be established for unqualified users.
The device supports both local AAA authentication and remote AAA authentication:
z
With local AAA authentication, you need to create a local user and configure a password for each
remote user on the LAC. The LAC will authenticate a remote user by matching the provided
username and password against those configured locally.
With remote AAA authentication, you need to configure the username and password of each user
on the RADIUS/HWTACACS server. The LAC will send the username and password of a remote
user to the server for identity authentication.
Follow these steps to configure the local authentication, authorization, and accounting:
To do
Enter system view
Create a local user and enter its
view
Use the command
Remarks
system-view
local-user username
Required
By default, no local user or
Configure a password for the local
password { simple | cipher }
user
password
Authorize the user to use the PPP

service
Return to system view
Create an ISP domain and enter
its view
password is configured on an LAC.
service-type ppp
Required
quit
domain isp-name
Required
authentication ppp local
Optional
authorization ppp local
Local
Configure the domain to use local

authentication/authorization/accou
authentication/authorization/accou
nting for its PPP users

accounting ppp local
3-10
nting is used by default.
For successful authentication of users, you also need to perform PPP configurations on the
corresponding interface of the LAC, for example, the asynchronous serial interface connecting
with users. For PPP configuration information, refer to PPP Configuration in the Access Volume.
You need to configure the authentication type of PPP users as PAP or CHAP on the user access
interfaces.
For information about AAA configuration commands and remote AAA authentication method
configuration, refer to AAA Configuration in the Security Volume.
Configuring an LNS
An LNS responds the tunneling requests from an LAC, authenticates users, and assign IP addresses
for users.
Before configuring an LNS, you need to enable L2TP and create an L2TP group.
Creating a Virtual Interface Template

A virtual interface template is intended to provide parameters for virtual access interfaces to be
dynamically created by the device, such as logical MP interfaces and logical L2TP interfaces.
After an L2TP session is established, a virtual access interface is needed for data exchange with the
peer. An LNS can use different virtual access (VA) interfaces to exchange data with different LACs.
Hence, you need to specify the virtual interface template for receiving calls. The system will
dynamically create a VA interface based on the configuration parameters in the specified virtual
interface template.
Follow these steps to create a virtual interface template:
To do
Use the command
Enter system view
system-view
Create a virtual interface template
interface virtual-template
and enter its view
virtual-template-number
Remarks
Required
By default, no virtual interface
template exists.
Configuring the Local Address and the Address Pool for Allocation
After an L2TP tunnel is set up between an LAC and an LNS, the LNS needs to assign an IP address to
a VPN user. For this purpose, you can specify an IP address directly, or specify an address pool.
Before specifying an address pool, use the ip pool command in system view or ISP domain view to
define the address pool. For a VPN user to be authenticated, an IP address will be selected from the
address pool configured in ISP domain view; for a VPN user not to be authenticated, it will be selected
from the global address pool defined in system view.
For details about the ip pool command, refer to AAA Commands in the Security Volume.
Follow these steps to configure a local address and address pool:
3-11
To do
Use the command
Enter system view
system-view
Enter virtual interface template
view
Configure the local IP address
Configure the authentication mode

for PPP users

mask-length } [ sub ]
Remarks
Required
ppp authentication-mode { chap
Optional
| pap } [ [ call-in ] domain
By default, no authentication is
isp-name ]
performed for PPP users.
Specify the address pool for
Optional
allocating an IP address to a VPN
remote address { pool
user, or assign an IP address to
[ pool-number ] | ip-address }
By default, address pool 0 (the

default address pool) is used.
the user directly
Configuring an LNS to Grant Certain L2TP Tunneling Requests

Upon receiving a tunneling request, an LNS determines whether to grant the tunneling request by
checking whether the tunnel name of the LAC matches that configured, and determines the virtual
interface template to be used to create the VA interface.
Follow these steps to configure an LNS to grant certain L2TP tunneling requests:
To do
Remarks
Enter system view
system-view
Specify the
If the L2TP
allow l2tp virtual-template
virtual interface
group number is
template for
not 1
receiving calls,
the tunnel name
Use the command
on the LAC, and
If the L2TP
the domain
group number is
name
1 (the default)
virtual-template-number remote
remote-name [ domain
Required
domain-name ]
Use either command.
allow l2tp virtual-template
By default, an LNS denies all
virtual-template-number [ remote
incoming calls.
remote-name ] [ domain
domain-name ]
The start l2tp and allow l2tp commands are mutually exclusive. Configuring one of them disables
the other one automatically.
The LAC side tunnel name configured on the LNS must be consistent with the local tunnel name
configured on the LAC.
3-12
Configuring User Authentication on an LNS

An LNS may be configured to authenticate a user that has passed authentication on the LAC to
increase security. In this case, the user is authenticated twice, once on the LAC and once on the LNS.
Only when the two authentications succeed can an L2TP tunnel be set up. This helps in providing
higher security.
On an L2TP network, an LNS authenticates users in three ways: proxy authentication, mandatory
CHAP authentication, and LCP re-negotiation.
If neither LCP re-negotiation nor mandatory CHAP authentication is configured, an LNS performs
proxy authentication of users. In this case, the LAC sends to the LNS all authentication information
from users as well as the authentication mode configured on the LAC itself.
Among these three authentication methods, LCP re-negotiation has the highest priority. If both LCP
re-negotiation and mandatory CHAP authentication are configured, an LNS uses LCP re-negotiation
and the authentication mode configured on the corresponding virtual interface template. If only
mandatory CHAP authentication is configured, an LNS will perform CHAP authentication of users.
Configuring mandatory CHAP authentication

With mandatory CHAP authentication configured, a VPN user that depends on a NAS to initiate
tunneling requests is authenticated twice: once when accessing the NAS and once on the LNS by
using CHAP.
Follow these steps to configure mandatory CHAP authentication:
To do
Use the command
Remarks
Enter system view
system-view
Required
Configure mandatory CHAP

authentication
mandatory-chap
By default, CHAP authentication is

not performed on an LNS.
When the LNS uses proxy authentication and the user authentication information passed from the
LAC to the LNS is valid: if the authentication type configured on the virtual interface template is
PAP, the proxy authentication succeeds and a session can be established for the user; if the
authentication type configured on the virtual interface template is CHAP but that configured on the
LAC is PAP, the proxy authentication will fail and no session can be set up. This is because the
level of CHAP authentication, which is required by the LNS, is higher than that of PAP
authentication, which the LAC provides.
Some PPP clients may not support re-authentication, in which case LNS side CHAP
authentication will fail.
3-13
Specifying to perform LCP re-negotiation with users

In an NAS-initiated dial-up VPDN, a user first negotiates with the NAS at the start of a PPP session. If
the negotiation succeeds, the NAS initiates an L2TP tunneling request and sends the user information
to the LNS. The LNS then determines whether the user is valid according to the proxy authentication
information received.
Under some circumstances (when there is a need to perform authentication and accounting on the
LNS, for example), another round of Link Control Protocol (LCP) negotiation is required between the
LNS and the user. In this case, the proxy authentication information from the NAS will be neglected.
If you enable LCP re-negotiation but configure no authentication for the corresponding virtual interface
template, the LNS will not perform additional authentication of users (in this case, users are
authenticated only once on the LAC) and will directly allocate addresses from the global address pool
to the PPP users.
Follow these steps to specify to perform LCP re-negotiation with users:
To do
Use the command
Remarks
Enter system view
system-view
Required
Specify to perform LCP

re-negotiation with users
mandatory-lcp
By default, an LNS does not

perform LCP re-negotiation with
users.
Configuring AAA Authentication of VPN Users on LNS Side

You need to configure AAA on the LNS when either of the following is true:
z
Mandatory CHAP authentication is configured on the LNS
Mandatory LCP re-negotiation authentication is configured on the LNS and the virtual interface
template requires authenticating PPP users.
After you configure AAA on the LNS, the LNS can authenticate the identities (usernames and
passwords) of VPN users for a second time. If a user passes the AAA authentication, the user can
communicate with the LNS. Otherwise, the L2TP session will be removed.
LNS side AAA configurations are similar to those on an LAC. Refer to Configuring AAA Authentication
of VPN Users on LAC Side for detailed information.
Enabling L2TP Multi-Instance

If multiple enterprises share the same LNS device and use the same name for the tunnel peers (LAC
devices), the LNS device is not able to differentiate which users belong to which enterprises. In this
case, enable the L2TP multi-instance function on the device to act as the LNS, so that the device can
differentiate multiple VPN domains and thus service users of different enterprises simultaneously.
In an L2TP multi-instance application, you need to specify the domain to which the VPN users belong
by using the domain keyword in the allow l2tp virtual-template command. After an L2TP tunnel is
established, the LNS gets the domain name carried in the session negotiation packet and searches to
determine whether there is the same domain among those locally configured for VPN users. If there is
3-14
an L2TP group whose tunnel peer name and domain name match, the LNS will establish a session
according to the configuration information of the group. In this way, different sessions will be
established for VPN users of different domains.
Follow these steps to enable the L2TP multi-instance function:
To do
Enter system view
Enable the L2TP multi-instance
function
Use the command

system-view
Remarks
Required
l2tpmoreexam enable
Disabled by default
In L2TP multi-instance applications, if the same remote tunnel name is configured on the LNS for
different L2TP groups, the tunnel authentication settings must also be the same respectively.
Otherwise, the expected tunnels and sessions cannot be established because the tunnel
authentication passwords do not match.
Specifying to Send ACCM

According to RFC 2661, the Asynchronous Control Character Map (ACCM) AVP is for an LNS to notify
the LAC of the ACCM that it has negotiated with the PPP peer.
In practice, LACs from some manufacturers support ACCM, while LACs from some others do not.
Therefore, an LNS needs to know whether it should send ACCM.
By default, an LNS sends ACCM. You can configure the LNS not to send ACCM if the LAC does not
support ACCM.
Follow these steps to configure an LNS to send ACCM:
To do
Use the command
Enter system view
system-view
Specify to send ACCM
l2tp sendaccm enable
Remarks
Required
By default, an LNS sends ACCM.
Configuring L2TP Connection Parameters

These L2TP connection parameter configuration tasks apply to both LACs and LNSs and are optional.
Configuring L2TP Tunnel Authentication

You can specify whether tunnel authentication must be performed for a tunnel to be set up. Either the
LAC or the LNS can initiate a tunnel authentication request. Whenever tunnel authentication is
enabled on one side, a tunnel can be set up successfully only if tunnel authentication is also enabled
on the other side and the two sides are configured with the same password that is not null.
3-15
Follow these steps to configure L2TP tunnel authentication:

To do
Use the command
Remarks
Enter system view
system-view
Enable the L2TP tunnel

authentication function
Optional
tunnel authentication
Enabled by default
Configure the password for
tunnel password { simple | cipher }
Required
tunnel authentication
password
The password is null by default.
You are recommended to enable tunnel authentication for tunnel security. To change the tunnel
authentication password, do so after tearing down the tunnel. Otherwise, your change does not take
effect.
Setting the Hello Interval

To check the connectivity of a tunnel, the LAC and LNS regularly send Hello packets to each other.
Upon receipt of a Hello packet, the LAC or LNS returns a response packet. If the LAC or LNS receives
no Hello response packet from the peer within a specified period of time, it retransmits the Hello packet.
If it receives no response packet from the peer after transmitting the Hello packet for three times, it
considers that the L2TP tunnel is down and tries to re-establish a tunnel with the peer.
Follow these steps to set the Hello interval:
To do
Use the command
Remarks
Enter system view
system-view
Set the hello interval
tunnel timer hello hello-interval
Optional
Enabling Tunnel Flow Control

The L2TP tunnel flow control function is for control of data packet in transmission. Data packets may
arrive out of order and the flow control function helps in buffering and adjusting out-of-order data
packets.
Follow these steps to enable tunnel flow control:
To do
Enter system view
Use the command
Remarks
system-view
3-16

Enable the tunnel flow control
function
Optional
tunnel flow-control
Disabled by default
Disconnecting Tunnels by Force

You can disconnect a tunnel when there are no users online or a network failure occurs. Either the LAC
or the LNS can initiate a tunnel disconnection request. Once a tunnel is disconnected, the control
connection and all the sessions within the tunnel will be removed. When a user dials in, a new tunnel
will be established.
Follow these steps to disconnect tunnels by force:
To do
Disconnect tunnels by force
Use the command

reset l2tp tunnel { id tunnel-id |
name remote-name }
Remarks
Available in user view
Displaying and Maintaining L2TP

To do
Display information about L2TP
tunnels
Display information about L2TP
sessions
Use the command
Remarks
display l2tp tunnel
display l2tp session
L2TP Configuration Examples

Either the NAS or the client can initiate an L2TP call. The next sections are for the NAS-initiated VPN
and the client-initiated VPN respectively.
NAS-Initiated VPN
A VPN user accesses the corporate headquarters as follows:
1)
The user dials in to the NAS.
2)
The NAS determines whether the user is a valid VPN client. If so, it initiates a tunneling request to
the LNS.
3)
After a tunnel is set up between the NAS and the LNS, the NAS transfers what it has negotiated
with the VPN user to the LNS.
4)
The LNS decides whether to accept the connection request according to the negotiated results.
5)
The user communicates with the headquarters over the tunnel between the NAS and the LNS.
3-17
Figure 3-8 Network diagram for the NAS-initiated VPN
1)
LAC side configuration
Configure the NAS
# Configure IP addresses for the interfaces. (Omitted)

# Create a local user named vpdnuser, set the password, and enable PPP service.
<LAC> system-view
[LAC] local-user vpdnuser
[LAC-luser-vpdnuser] password simple Hello
[LAC-luser-vpdnuser] service-type ppp
[LAC-luser-vpdnuser] quit
# Configure interface Async 1/0.

[LAC] interface async 1/0
[LAC-Async1/0] ip address 1.1.1.1 255.255.255.0
[LAC-Async1/0] ppp authentication-mode chap
[LAC-Async1/0] quit
# Enable L2TP.
[LAC] l2tp enable
# Create an L2TP group and configure its attributes.

[LAC] l2tp-group 1
[LAC-l2tp1] tunnel name LAC
[LAC-l2tp1] start l2tp ip 1.1.2.2 fullusername vpdnuser
# Enable tunnel authentication and specify the tunnel authentication password.

[LAC-l2tp1] tunnel authentication
[LAC-l2tp1] tunnel password simple aabbcc
2)
Configure the LNS

# Create a local user named vpdnuser, set the password, and enable PPP service. Note that the
username and password must match those configured on the client.
<LNS> system-view
[LNS] local-user vpdnuser
[LNS-luser-vpdnuser] password simple Hello
[LNS-luser-vpdnuser] service-type ppp
[LNS-luser-vpdnuser] quit
# Configure local authentication for the VPN user.

[LNS] domain system
[LNS-isp-system] authentication ppp local
[LNS-isp-system] ip pool 1 192.168.0.2 192.168.0.100
[LNS-isp-system] quit
# Enable L2TP.
[LNS] l2tp enable
# Configure the virtual interface template.

3-18
[LNS] interface virtual-template 1

[LNS-virtual-template1] ip address 192.168.0.1 255.255.255.0
[LNS-virtual-template1] ppp authentication-mode chap domain system
[LNS-virtual-template1] remote address pool 1
[LNS-virtual-template1] quit
# Create an L2TP group, specify the virtual interface template for receiving calls and specify the name
of the tunnel on the peer.
[LNS] l2tp-group 1
[LNS-l2tp1] tunnel name LNS
[LNS-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable tunnel authentication and specify the tunnel authentication password.

[LNS-l2tp1] tunnel authentication
[LNS-l2tp1] tunnel password simple aabbcc
3)
User side operation
In the dial-up network window, enter vpdnuser as the username, Hello as the password.
4)
Verify the configurations
# After the dial-up connection is established, the user host can get an IP address (192.168.0.2 for
example) and can ping the private IP address of the LNS (192.168.0.1).
# On the LNS, use the display l2tp tunnel command to check the L2TP tunnels established.
[LNS] dis l2tp tunnel
Total tunnel = 1
LocalTID RemoteTID RemoteAddress

1
1.1.2.1
Port
1701
Sessions RemoteName
LAC
# On the LNS, use the display l2tp session command to check the L2TP sessions established.
[LNS] display l2tp session
Total session = 1
LocalSID RemoteSID LocalTID

23142
729
Client-Initiated VPN
As shown in Figure 3-9, a VPN user accesses the corporate headquarters as follows:
1)
The user first accesses the Internet, and then initiates a tunneling request to the LNS directly.
2)
After the LNS accepts the connection request, an L2TP tunnel is set up between the LNS and the
VPN user.
3)
The VPN user communicates with the headquarters over the tunnel.
Figure 3-9 Network diagram for the client-initiated VPN

2.1.1.1/24
Internet
Eth1/1
1.1.2.2/24
Corporate
network
LNS
VPN user
L2TP tunnel
3-19
1)
Configure the LNS

# Configure the route between the LNS and the user host. (Omitted)
# Create a local user named vpdnuser, set the password, and enable PPP service. Note that the
username and password must match those configured on the client.
<LNS> system-view
[LNS] local-user vpdnuser
[LNS-luser-vpdnuser] password simple Hello
[LNS-luser-vpdnuser] service-type ppp
[LNS-luser-vpdnuser] quit
# Configure local authentication for the VPN user.

[LNS] domain system
[LNS-isp-system] authentication ppp local
[LNS-isp-system] ip pool 1 192.168.0.2 192.168.0.100
[LNS-isp-system] quit
# Enable L2TP.
[LNS] l2tp enable
# Configure the virtual interface template.

[LNS-virtual-template1] ip address 192.168.0.1 255.255.255.0
[LNS-virtual-template1] ppp authentication-mode chap domain system
[LNS-virtual-template1] remote address pool 1
[LNS-virtual-template1] quit
# Create an L2TP group and specify the virtual interface template for receiving calls.
[LNS] l2tp-group 1
[LNS-l2tp1] allow l2tp virtual-template 1
2)
Configure the VPN user
On the user host, create a virtual private network connection by using the Windows system, or install
the L2TP client software (such as WinVPN Client) on the host and connect the host to the Internet in
dial-up mode. The IP address of the user host is 2.1.1.1. Configure a route between the user host and
the LNS (1.1.2.2), and then perform the following configurations (the configuration procedure depends
on the client software):
# Specify the VPN username as vpdnuser and the password as Hello.
# Specify the Internet interface address of the security gateway as the IP address of the LNS. In this
example, the Ethernet interface for the tunnel on the LNS has an IP address of 1.1.2.2.
# Modify the connection attributes, setting the protocol to L2TP, the encryption attribute to customized
and the authentication mode to CHAP.
3)
# On the user host, initiate the L2TP connection. After the connection is established, the user host can
get the IP address 192.168.0.2 and can ping the private IP address of the LNS (192.168.0.1).
# On the LNS, use the display l2tp session command to check the L2TP session established.
[LNS-l2tp1] display l2tp session
Total session = 1
3-20
647
# On the LNS, use the display l2tp tunnel command to check the L2TP tunnel established.
[LNS-l2tp1] display l2tp tunnel
Total tunnel = 1

1
2.1.1.1
Port
1701
Sessions RemoteName
l2tpuser
L2TP Multi-Domain Application

Multiple enterprises share an LNS. Users of different enterprises access their corporate servers
through L2TP VPDNs respectively.
Host A is a user of enterprise 1, which has the domain name of aaa.net.
Host B is a user of enterprise 2, which has the domain name of bbb.net.
Figure 3-10 Network diagram for L2TP multi-domain application
Corporate
network 1
Host A
Eth1/3
1.1.1.1/24
Eth1/2
1.1.2.1/24
Eth1/1
1.1.1.2/24
WAN
L2TP tunnel
Eth1/1
1.1.2.2/24
LAC
LNS
Corporate
network 2
Host B
1)
Configure the LAC
In this example, Ethernet 1/1 and Ethernet 1/3 on the LAC are both user access interfaces. The IP
address of Ethernet 1/2 through which the LAC connects to the tunnel is 1.1.2.1, and the IP address of
Ethernet 1/1 through which the LNS connects to the tunnel is 1.1.2.2.
# Create two local users, set the passwords, and enable PPP service.
<LAC> system-view
[LAC] local-user vpdn1
[LAC-luser-vpdn1] password simple 11111
[LAC-luser-vpdn1] service-type ppp
[LAC-luser-vpdn1] quit
[LAC] local-user vpdn2
[LAC-luser-vpdn2] password simple 22222
[LAC-luser-vpdn2] service-type ppp
[LAC-luser-vpdn2] quit
# Configure local authentication for the users.

[LAC] domain aaa.net
[LAC-isp-aaa.net] authentication ppp local
[LAC-isp-aaa.net] quit
[LAC] domain bbb.net
[LAC-isp-bbb.net] authentication ppp local
3-21
[LAC-isp-bbb.net] quit
# Configure PPPoE servers on interface Ethernet 1/1 and Ethernet 1/3 respectively.
[LAC] interface ethernet 1/3
[LAC-Ethernet1/3] pppoe-server bind virtual-template 100
[LAC-Ethernet1/3] quit
[LAC-Ethernet1/1] pppoe-server bind virtual-template 101
# Configure an IP address for interface Ethernet 1/2.

[LAC-Ethernet1/2] ip address 1.1.2.1 255.255.255.0
# Create the virtual interface templates and configure CHAP authentication.

[LAC] interface virtual-template 100
[LAC-Virtual-Template100] ppp authentication-mode chap domain aaa.net
[LAC-Virtual-Template100] quit
[LAC] interface virtual-template 101
[LAC-Virtual-Template101] ppp authentication-mode chap domain bbb.net
[LAC-Virtual-Template101] quit
# Create two L2TP groups and configure related attributes.

[LAC] l2tp enable
[LAC] l2tp-group 1
[LAC-l2tp1] tunnel name LAC-1
[LAC-l2tp1] start l2tp ip 1.1.2.2 domain aaa.net
[LAC-l2tp1] quit
[LAC] l2tp-group 2
[LAC-l2tp2] tunnel name LAC-2
[LAC-l2tp2] start l2tp ip 1.1.2.2 domain bbb.net
# Enable the tunnel authentication and specify a tunnel authentication password.

[LAC-l2tp2] tunnel password simple 12345
[LAC-l2tp2] quit
[LAC] l2tp-group 1
[LAC-l2tp1] tunnel password simple 12345
2)
Configure the LNS
<LNS> system-view
[LNS] l2tp enable
[LNS] l2tpmoreexam enable
# Create two local users, set the passwords, and enable PPP service.
[LNS] local-user vpdn1
[LNS-luser-vpdn1] password simple 11111
[LNS-luser-vpdn1] service-type ppp
[LNS-luser-vpdn1] quit
[LNS] local-user vpdn2
[LNS-luser-vpdn2] password simple 22222
[LNS-luser-vpdn2] service-type ppp
[LNS-luser-vpdn2] quit
# Specify the IP address of Ethernet 1/1 through which the LNS connects to the tunnel as 1.1.2.2.
[LNS] interface ethernet 1/1
[LNS-Ethernet1/1] ip address 1.1.2.2 255.255.255.0
3-22
[LNS-Ethernet1/1] quit
# Create two address pools.

[LNS] domain aaa.net
[LNS-isp-aaa.net] authentication ppp local
[LNS-isp-aaa.net] ip pool 1 10.0.1.10 10.0.1.100
[LNS-isp-aaa.net] quit
[LNS] domain bbb.net
[LNS-isp-bbb.net] authentication ppp local
[LNS-isp-bbb.net] ip pool 1 10.0.2.10 10.0.2.100
[LNS-isp-bbb.net] quit
# Create two virtual interface templates.

[LNS-Virtual-Template1] ip address 10.0.1.1 255.255.255.0
[LNS-Virtual-Template1] remote address pool 1
[LNS-Virtual-Template1] ppp authentication-mode chap domain aaa.net
[LNS-Virtual-Template1] quit
[LNS-Virtual-Template2] ip address 10.0.2.1 255.255.255.0
[LNS-Virtual-Template2] remote address pool 1
[LNS-Virtual-Template2] ppp authentication-mode chap domain bbb.net
[LNS-Virtual-Template2] quit
# Create two L2TP groups.

[LNS] l2tp-group 3
[LNS-l2tp3] allow l2tp virtual-template 1 remote LAC-1 domain aaa.net
[LNS-l2tp3] tunnel password simple 12345
[LNS-l2tp3] quit
[LNS] l2tp-group 4
[LNS-l2tp4] allow l2tp virtual-template 2 remote LAC-2 domain bbb.net
[LNS-l2tp4] tunnel password simple 12345
If RADIUS authentication is required on the LNS, modify the AAA configurations as needed. For AAA
configuration details, refer to AAA Configuration in the Security Volume.
3)
Configure the users
Create a dial-up connection on each host.

z
On Host A, enter vpdn1@aaa.net as the username and 11111 as the password in the dial-up
terminal window.
On Host B, enter vpdn2@aaa.net as the username and 22222 as the password in the dial-up
terminal window.
4)
# After Host A establishes a dial-up connection with enterprise 1, Host A gets IP address 10.0.1.10 and
can ping the private address of the LNS (10.0.1.1).
# After Host B establishes a dial-up connection with enterprise 2, Host B gets IP address 10.0.2.10 and
can ping the private address of the LNS (10.0.2.1).
# On the LNS, use the display l2tp session command to check the L2TP sessions established.
[LNS-l2tp1] display l2tp session
Total session = 2
3-23

17345
4351
23914
10923
# On the LNS, use the display l2tp tunnel command to check the L2TP tunnels established.
[LNS-l2tp1] display l2tp tunnel
Total tunnel = 2
Port
Sessions RemoteName
1.1.2.1
1701
LAC-1
1.1.2.1
1701
LAC-2
Complicated Network Application

A security gateway can serve as an LAC and an LNS simultaneously. Additionally, it has the ability to
support more than one incoming call. Should there be enough memory and physical lines, L2TP can
receive and make multiple calls at the same time. You can refer to the above examples for complicated
network configuration.
Note that many L2TP applications rely on static routes to initiate connection requests.
Troubleshooting L2TP
The VPN connection setup process is rather complicated. The following presents an analysis of some
common faults occurred in the process. Before troubleshooting the VPN, make sure that the LAC and
LNS are connected properly across the public network.
Symptom 1: Users cannot log in.
Analysis and solution:
Possible reasons for login failure are as follows:
1)
Tunnel setup failure, which may occur in the following cases:
The address of the LNS is set incorrectly on the LAC.
No L2TP group is configured on the LNS (usually a router) to receive calls from the tunnel peer.
For details, refer to the description of the allow command.
Tunnel authentication fails. For successful tunnel authentication, tunnel authentication must be
enabled on both the LAC and LNS and the passwords for tunnel authentication configured on the
two sides must match.
If the tunnel is torn down by force on the local end but the remote end has not received the
notification packet for reasons such as network delay, a new tunnel cannot be set up.
2)
PPP negotiation failure, which may occur in the following cases:
The usernames and/or passwords are incorrectly configured on the LAC or not configured on the
LNS.
The LNS cannot allocate addresses. This may be because the address pool is too small or no
address pool is configured.
The authentication type is inconsistent. For example, if the default authentication type for a VPN
connection created on Windows 2000 is Microsoft Challenge Handshake Authentication Protocol
(MSCHAP) but the remote end does not support MSCHAP, PPP negotiation will fail. In this case,
CHAP is recommended.
Symptom 2: Data transmission fails. A connection is setup but data cannot be transmitted. For
example, the LAC and LNS cannot ping each other.
Analysis and solution:
3-24
Possible reasons for data transmission failure are as follows:

3)
The user address is set incorrectly. Usually, the address of a user is allocated by the LNS.
However it can also be set by the user. If the address set by the user is not in the same network
segment as that allocated by the LNS, data transmission fails. It is recommended that addresses
be allocated by the LNS.
4)
Congestion occurs on the Internet backbone and the packet loss ratio is high. L2TP data
transmission is based on UDP, which does not provide the packet error control function. If the line
is not stable, the LAC and LNS may not be able to ping each other and L2TP applications may fail.
3-25
L2TP-Based EAD Configuration

When configuring the L2TP-based EAD function, go to these sections for information you are
interested in:
z
L2TP-Based EAD Overview
Configuring L2TP-Based EAD
Displaying and Maintaining L2TP-Based EAD
L2TP-Based EAD Configuration Example
L2TP-Based EAD Overview

When EAD is used, a PPP user that has passed access authentication must undergo security
authentication on the EAD server before accessing network resources normally. If the security
authentication fails, the user can access only the resources in the quarantined area.
The following describes the detailed procedure:
1)
The iNode client (the user host) connects to the LNS device through L2TP. After the client passes
PPP authentication, the CAMS/iMC server issues the isolation ACL to the device, which will then
filter packets from the client using the firewall function.
2)
After the IP Control Protocol (IPCP) negotiation, the CAMS/iMC server notifies its IP address,
which is permitted by the isolation ACL, to the iNode client by way of the device.
3)
The CAMS/iMC server performs EAD authentication and security check for the iNode client. After
the client passes the security authentication, the CAMS/iMC server issues a security ACL to the
device to allow the client to access network resources normally.
Make sure that the ACLs to be assigned by the authentication server have been configured
appropriately on the LNS device. An empty ACL or incorrect ACL rules can cause EAD
authentication failure.
You can configure different ACLs for different hosts. The device filters packets of a host according
to the corresponding ACL.
It is recommended to deploy this function for remote clients across the Internet. For LAN users, it
is recommended to use portal authentication instead.
For information about packet filtering firewall, refer to Firewall Configuration in the Security
Volume.
For information about AAA and RADIUS, refer to AAA Configuration in the Security Volume.
For information about portal, refer to Portal Configuration in the Security Volume.
4-1
Configuring L2TP-Based EAD

Complete the AAA, RADIUS, L2TP, packet filtering firewall, and PPP related configurations.
Follow these steps to configure the L2TP-based EAD function:
To do
Use the command
Enter system view
system-view
Create a virtual template (VT)
interface and enter VT interface view
Enable the L2TP-based EAD

function
Remarks
Required
Required
ppp access-control enable
Disabled by default
Specify the fragment match mode for

all packet filtering firewalls on the
virtual access (VA) interfaces
created on the VT interface
ppp access-control
Optional
match-fragments { exactly |
normally }
Standard mode applies by default.
Displaying and Maintaining L2TP-Based EAD

To do
Display statistics about dynamic
firewalls on the VA interfaces
created on the specified VT
interface
Use the command
Remarks
display ppp access-control

{ interface interface-type
interface-number }
L2TP-Based EAD Configuration Example

Network Requirements
As shown in Figure 4-1, configure the router to implement the EAD function:
z
In the public network, the Host communicates with the LNS at Layer 3 through an L2TP tunnel.
The intranet is on network segment 10.100.0.0/24.
Both the security policy server and the RADIUS server are hosted by the CAMS/iMC platform,
whose IP address is 10.110.91.146/24.
The virus and patch server is in the quarantined area, and its IP address is 10.22.2.2/24.
The client agent is in the quarantined area, and its IP address is 10.22.2.1/24.
The host is on the network segment 10.200.1.0/24.
It is required that the host must pass identity authentication and security authentication to access the
network resources. If the host fails the security authentication, it can access only the virus and patch
server.
4-2
Figure 4-1 Network diagram for L2TP-based EAD configuration
Eth
10 1/1
.11
0.9
1.1
/24
1)
Configure the router
# Assign an IP address to Ethernet 1/1, which is connected to the CAMS/iMC server.

<Router> system-view
[Router] interface ethernet1/1
[Router-Ethernet1/1] ip address 10.110.91.1 255.255.255.0
[Router-Ethernet1/1] quit
# Assign an IP address to Ethernet 1/2, which is connected to the iNode client.

# Assign an IP address to Ethernet 1/3.

# Configure a RADIUS scheme that uses the CAMS/iMC server, setting the IP address to
10.110.91.146/24, and the keys to sysname.
[Router] radius scheme cams
[Router-radius-cams] server-type extended
[Router-radius-cams] primary authentication 10.110.91.146
[Router-radius-cams] primary accounting 10.110.91.146
[Router-radius-cams] key authentication sysname
[Router-radius-cams] key accounting sysname
[Router-radius-cams] quit
# Configure domain system to use the RADIUS scheme for PPP user authentication and accounting,
and use the IP address pool 10.200.1.0/24 to assign IP addresses to remote hosts.
[Router] domain system
[Router-isp-system] authentication ppp radius-scheme cams
[Router-isp-system] ip pool 1 10.200.1.2 10.200.1.254
[Router-isp-system] quit
4-3
# Configure the IP address of the virtual template interface, enable PAP authentication on this interface,
specify the address pool to be used to assign addresses for PPP users, enable L2TP access based
EAD, and set fragment match mode to exactly.
[Router] interface virtual-template 1
[Router-Virtual-Template1] ip address 10.200.1.1 255.255.255.0
[Router-Virtual-Template1] ppp authentication-mode pap
[Router-Virtual-Template1] remote address pool 1
[Router-Virtual-Template1] ppp access-control enable
[Router-Virtual-Template1] ppp access-control match-fragments exactly
[Router-Virtual-Template1] quit
# Enable L2TP service, configure an L2TP group, configure the local tunnel name as LNS, and disable
tunnel authentication.
[Router] l2tp enable
[Router] l2tp-group 1
[Router-l2tp1] tunnel name LNS
[Router-l2tp1] undo tunnel authentication
[Router-l2tp1] allow l2tp virtual-template 1
[Router-l2tp1] quit
# Enable the firewall function, specify the default filtering action as denying packets, and enable
fragment inspection.
[Router] firewall enable
[Router] firewall default deny
[Router] firewall fragments-inspect
# Configure security ACL 2000, so that users passing security authentication can access the Internet.
[Router] acl number 2000
[Router-acl-basic-2000] rule 0 permit
[Router-acl-basic-2000] quit
# Configure isolation ACL 3000, so that users failing security authentication can access only
quarantine area 10.22.2.0/24.
[Router] acl number 3000
[Router-acl-adv-3000] rule 0 permit ip destination 10.22.2.0 0.0.0.255
2)
Configure the CAMS/iMC server
Specify ACL 2000 as the security ACL and ACL 3000 as the isolation ACL in the security policy for the
user.
Refer to the related CAMS/iMC documentation for detailed configurations.
4-4
SSL VPN Configuration
When configuring SSL VPN, go to these sections for information you are interested in:
z
SSL VPN Overview
Configuring SSL VPN
SSL VPN Configuration Example
SSL VPN Overview

SSL VPN is a VPN technology based on Secure HTTP (HTTPS, that is, SSL-supported HTTP). It
works between the transport layer and the application layer. Using the certificate-based identify
authentication, data encryption, and integrity verification mechanisms that the SSL protocol provides,
SSL VPN can establish secure connections for communications at the application layer.
SSL VPN has been widely used for secure, remote Web-based access. For example, it can allow
remote users to access the corporate network securely. Figure 5-1 shows a typical SSL VPN network.
On the SSL VPN gateway, the network administrator creates resources corresponding to the servers in
the internal network. To access an internal server, a remote user first needs to establish an HTTPS
connection with the SSL VPN gateway and selects the resources to be accessed. Then, the SSL VPN
gateway forwards the resource access request to the internal server. In the SSL VPN deployed
network, the SSL VPN gateway will establish an SSL connection with a remote user and then will
authenticate the user before allowing the user to access an internal server, and therefore the internal
servers are well protected.
4-1
Figure 5-1 Network diagram for SSL VPN configuration
Administrator
Internet
SSL VPN gateway
Internal servers
Remote user
The following is how SSL VPN operates:

2)
The administrator logs in to the Web interface of the SSL VPN gateway through HTTPS, and then
creates resources corresponding to the internal servers.
3)
The remote user establishes an HTTPS connection with the SSL VPN gateway. The SSL VPN
gateway and the remote user authenticate each other using the certificate-based authentication
function provided by SSL.
4)
After the HTTPS connection is established, the user can try to log in to the Web interface of the
SSL VPN gateway by entering the username, password, and authentication method (RADIUS
authentication, for example). The SSL VPN gateway will verify the user information.
5)
After logging in to the Web interface, the user finds the resources to access on the Web interface
and then sends an access request to the SSL VPN gateway through an SSL connection.
6)
The SSL VPN gateway resolves the request, interacts with the corresponding server, and then
forwards the servers reply to the user.
Configuring SSL VPN

When configuring the SSL VPN gateway, you need to:
z
Specify the SSL server policy to be used by the SSL VPN service. To manage the SSL VPN
gateway or access the internal resources, both administrators and remote users need to log in to
the Web interface of the SSL VPN gateway through HTTPS. Therefore, it is required to specify an
SSL server policy on the SSL VPN gateway so that the gateway can determine the SSL
parameters to be used for providing the SSL VPN service.
Specify the TCP port number to be used by the SSL VPN service. The SSL VPN gateway acts as
the HTTPS server to provide the Web interface for administrators and remote users to log in.
Therefore, you need to specify the TCP port number for providing the HTTPS service.
Enable the SSL VPN service. Administrators and remote users can access the Web interface of
the SSL VPN gateway only after the SSL VPN service is enabled on the gateway.
Before configuring SSL VPN, you need to create an SSL server policy. For how to configure an SSL
server policy, refer to SSL Configuration in the Security Volume.
4-2
Configuring SSL VPN

Follow these steps to configure SSL VPN:
To do
Enter system view
Use the command
Remarks
system-view
Required
Specify the SSL server policy
ssl-vpn server-policy
By default, no SSL server policy is
and port to be used by the SSL
server-policy-name [ port
specified for the SSL VPN service
VPN service
port-number ]
and the SSL VPN service uses TCP

port 443.
Required
Enable the SSL VPN service
ssl-vpn enable
Disabled by default
SSL VPN Configuration Example

As shown in Figure 5-2, configure SSL and enable SSL VPN service on the SSL VPN gateway, so that
administrators and common users can log in to the Web interface of the SSL VPN gateway through
HTTPS and then manage and access the internal resources of the corporate network through the SSL
VPN gateway.
In this configuration example:
z
The IP address of the SSL VPN gateway is 10.1.1.1/24.
The IP address of the Certificate Authority (CA) is 10.2.1.1/24. The name of the CA is CA server,
which is used to issue certificates to the SSL VPN gateway and remote users.
Figure 5-2 Network diagram for SSL VPN configuration
4-3
In this example, the Windows Server is used as the CA. You need to install the Simple Certificate
Enrollment Protocol (SCEP) plugin on the CA.
Before the following configurations, make sure that the intended SSL VPN gateway, the CA, and
the host used by the remote user can reach each other, and the CA is enabled with the CA service
and can issue certificates to the device (SSL VPN gateway) and the host.
1)
Apply for a certificate for the SSL VPN gateway
# Configure a PKI entity named en and specify the common name of the entity as http-server.
<Device> system-view
[Device] pki entity en
[Device-pki-entity-en] common-name http-server
[Device-pki-entity-en] quit
# Configure a PKI domain named sslvpn, and specify the trusted CA as ca server, the URL of the RA
server as http://10.2.1.1/certsrv/mscep/mscep.dll, registration authority for certificate requesting as
RA, and the entity as en.
[Device] pki domain sslvpn
[Device-pki-domain-sslvpn] ca identifier ca server
[Device-pki-domain-sslvpn] certificate request url http://10.2.1.1/certsrv/mscep/mscep.dll
[Device-pki-domain-sslvpn] certificate request from ra
[Device-pki-domain-sslvpn] certificate request entity en
[Device-pki-domain-sslvpn] quit
# Generate the local RSA key pair.

[Device] public-key local create rsa
# Retrieve the CA certificate.

[Device] pki retrieval-certificate ca domain sslvpn
# Apply for a certificate for the device.

[Device] pki request-certificate domain sslvpn
2)
Configure an SSL server policy for the SSL VPN service
# Configure an SSL server policy named myssl, and specify the policy to use PKI domain sslvpn.
[Device] ssl server-policy myssl
[Device-ssl-server-policy-myssl] pki-domain sslvpn
[Device-ssl-server-policy-myssl] quit
3)
Configure SSL VPN
# Specify the SSL server policy myssl and port 443 (default) for the SSL VPN service.
[Device] ssl-vpn server-policy myssl
# Enable the SSL VPN service.

[Device] ssl-vpn enable
4)
On the user host, launch the IE browser and input https://10.1.1.1/svpn/en/index.htm in the address
bar. You should be able to open the Web login interface of the SSL VPN gateway.
4-4
Refer to PKI Commands in the Security Volume for details of PKI configuration commands.
Refer to Public Key Commands in the Security Volume for details of the public-key local create
rsa command.
Refer to SSL Commands in the Security Volume for details of SSL configuration commands.
4-5

06 VPN Volume Book

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

06 VPN Volume Book

Загружено:

Авторское право:

Доступные форматы

Table of Contents

1 DVPN Configuration 1-1

GRE Security Options 2-3

L2TP Multi-Domain Application 3-21

Support for some features may vary with device models.

All the MSR series routers are centralized devices.

DVPN Configuration Task List

Displaying and Maintaining DVPN

DVPN Configuration Examples

Sending the packet down the tunnel to the destination.

Basic Concepts of DVPN

Networking Structures of DVPN

Figure 1-1 Full mesh DVPN networking diagram

Figure 1-2 Hub-Spoke DVPN networking diagram

Connection initialization phase

Figure 1-4 shows the registration process:

The client submits its identity information to the server.

Tunnel establishment phase

The initiator originates a tunnel establishment request.

Supported DVPN Features

Support for dynamic VAM client IP address

AAA identity authentication of VAM clients on the VAM server

Encryption of VAM protocol packets

IPsec protection of data packets

Centralized management of policies

Support for multiple VPN domains

DVPN Configuration Task List

Configuring the VAM Server

Configuring a VAM Client

Configuring an IPsec Profile

Server side configuration

Client side configuration

Configuring the DVPN Tunnel

Configuring the VAM Server

Creating a VPN Domain

Enabling VAM Server

Configuring the Listening IP Address and UDP Port Number

Configuring the Security Parameters of VAM Protocol Packets

Specifying the Client Authentication Mode

Configuring the Hubs

Configuring the Pre-Shared Key of the VAM Server

Configuring Keepalive Parameters

Creating a VPN Domain

Use the command

Enter system view

Create a VPN domain and

Enabling VAM Server

Use the command

Enter system view

vam server enable { all |

one or all VPN domains

Enable VAM server for

vam server vpn vpn-name

Enable VAM server

Configuring the Listening IP Address and UDP Port Number

Use the command

vam server ip-address ip-address

Not configured by default

Configuring the Security Parameters of VAM Protocol Packets

Use the command

Enter system view

Enter VPN domain view

vam server vpn vpn-name

Specify the algorithms for protocol