01-04 IPSec Configuration
01-04 IPSec Configuration
4 IPSec Configuration
To solve the preceding problems, Internet Protocol Security (IPSec) was developed to address
some of the security flaws of IP. It works at the IP layer and provides transparent security
services for IP network communication.
Definition
IPSec is a suite of protocols defined by the Internet Engineering Task Force (IETF) for
providing secure transmission of data over IP networks. These protocols include the
Authentication Header (AH) and Encapsulation Security Payload (ESP). The IPSec
framework also includes key exchange and algorithms used for authentication and encryption.
These protocols allow two devices to establish an IPSec tunnel between them, so that data is
securely forwarded over the IPSec tunnel.
Benefits
IPSec uses encryption and authentication to provide secure transmission of service data over
the Internet. Key aspects of this are as follows:
l Data origin authentication: The receiver checks validity of the sender.
l Data encryption: The sender encrypts data packets and transmits them in ciphertext on
the Internet. The receiver decrypts or directly forwards the received data packets.
l Data integrity: The receiver authenticates the received data to ensure that it has not been
tampered with during transmission.
l Anti-replay: The receiver rejects old or duplicate packets to prevent attacks that
malicious users initiate by resending obtained packets.
IPSec SAs need to be established for secure data transmission between IPSec peers. An IPSec
SA is identified by three parameters: security parameter index (SPI), destination IP address,
and security protocol number (AH or ESP). The SPI is a 32-bit value generated to uniquely
identify an SA, and is encapsulated in an AH or ESP header.
IPSec SAs are unidirectional and are generally established in pairs (inbound and outbound).
Therefore, at least one pair of IPSec SAs are established between two IPSec peers to form a
secure IPSec tunnel that protects data flows in both directions, as shown in Figure 4-1.
Internet
Inbound SA1 Outbound
Outbound SA2 Inbound
IPSec Tunnel
Peer A Peer B
Pre-encrypted packet
Encrypted packet
In addition, the number of IPSec SAs required also depends on the security protocols used to
protect traffic between two peers. If either AH or ESP is used, two SAs are required to protect
incoming and outgoing traffic. If both AH and ESP are used, four SAs are required, two for
each protocol.
IPSec SAs can be established manually or through the Internet Key Exchange (IKE)
protocol. Table 4-1 compares the two IPSec SAs establishment modes.
l AH
AH is used to authenticate, but not encrypt, IP traffic. An AH header is appended to the
standard IP header in each data packet, as described in 4.2.1.3 Encapsulation Modes.
AH provides data origin authentication and data integrity check that is performed on an
entire IP packet. The sender performs hash calculation on data packets and the
authentication key. Upon receipt of data packets carrying the calculation result, the
receiver also performs hash calculation and compares the calculation result with that
received from the sender. Any changes to the data during transmission will invalidate the
calculation result.
l ESP
ESP provides encryption and optional authentication. An ESP header is appended to the
standard IP header in each data packet, and an ESP trailer and ESP Authentication Data
are appended to each data packet, as described in 4.2.1.3 Encapsulation Modes. ESP
encrypts the IP payload and then encapsulates it into a data packet to ensure data
confidentiality. ESP protects the IP header only in tunnel mode.
Table 4-2 compares AH and ESP.
Protocol number 51 50
Data integrity Supported (checking the entire IP Supported (not checking the IP
check packet) header in transport mode;
checking the entire IP packet in
tunnel mode)
Sequence Number
32 bits
Next 8 bits This field identifies the type of the payload following the AH
Header header. In transport mode, the Next Header field is the number of
the protected upper-layer protocol (TCP or UDP) or ESP. In tunnel
mode, the Next Header field is the number of the IP or ESP
protocol.
NOTE
When AH and ESP are used together, the Next Header following an AH
header is an ESP header.
Payload 8 bits This field specifies the length of the AH header in 32-bit words (4-
Len byte units) minus 2. The default value is 4.
Reserve 16 bits This field is reserved for future use and defaults to 0.
d
Authenti Integral This field contains the result of Integrity Check Value (ICV)
cation multiple calculation, which is used by the receiver for data integrity check.
Data of 32 Authentication algorithms include MD5, SHA1, and SHA2.
bits. It is NOTE
96 bits The MD5 and SHA1 authentication algorithms have security risks. The
in SHA2 algorithm is recommended.
common
cases.
ESP header
Figure 4-3 shows the format of an ESP header, and Table 4-4 describes fields in the ESP
header.
Authenticated
Payload data (variable)
Encrypted
Padding
(0-255 octets) ESP
Pad Next trailer
Length Header
Authentication Data (Variable) ESP
Integrity Check Value (ICV) authentication
32 bits
Payload - This field contains the protected variable-length data content in the
data original IP packet. The type of content protected by ESP is identified
by the Next Header field.
Padding - This field extends the payload data to a size that fits the encryption's
cipher block size. The Padding field length depends on the payload
data length and algorithm.
Pad 8 bits This field specifies the length of the Padding field. The value 0
Length indicates no padding.
Next 8 bits This field identifies the type of the payload following the ESP
Header header. In transport mode, the Next Header field is the number of the
protected upper-layer protocol (TCP or UDP). In tunnel mode, the
Next Header field is the number of the IP protocol.
Authenti Integral This field contains the result of ICV calculation, which is used by the
cation multipl receiver for data integrity check. Authentication algorithms are the
Data e of 32 same as those of AH.
bits. It The authentication function of ESP is optional. If data check is
is 96 enabled, an ICV value is appended to encrypted data.
bits in
commo
n cases.
Transport Mode
IPSec transport mode works by inserting an AH or ESP header between an IP header and a
transport-layer protocol header to protect the TCP, UDP, or ICMP payload. Because no
additional IP header is added, IP addresses in the original packets are visible in the IP header
of the post-encrypted packet. Figure 4-4 shows an example of TCP packet encapsulation in
transport mode.
IP AH TCP
AH data
Header Header Header
Authenticated
(except variable fields in IP Header)
IP ESP TCP ESP ESP
data
ESP Header Header Header Trailer Auth data
Encrypted
Authenticated
IP AH ESP TCP ESP ESP
data
Header Header Header Header Trailer Auth data
AH-ESP
ESP encrypted
ESP authenticated
AH authenticated (except variable fields in IP Header)
Tunnel Mode
IPSec tunnel mode works by encrypting and authenticating an entire IP packet, including the
IP header and payload. In this mode, an AH or ESP header is added before the raw IP header,
and a new IP header is added before the AH or ESP header. Figure 4-5 shows an example of
TCP packet encapsulation in tunnel mode.
In tunnel mode, AH protects the new IP header, but ESP does not.
l The tunnel mode is more secure because original IP packets are completely authenticated
and encrypted. This mode hides the IP address, protocol type, and port number in an
original IP packet.
l The tunnel mode generates an additional IP header, occupying more bandwidth than the
transport mode.
l The transport mode is mainly used for communication between two hosts or between a
host and a VPN gateway. The tunnel mode is mainly used for communication between
two VPN gateways or between a host and a VPN gateway.
When both AH and ESP are used to protect traffic, they must use the same encapsulation
mode.
IPSec provides two security mechanisms: encryption and authentication. The encryption
mechanism ensures data confidentiality and prevents data from being intercepted during
transmission. The authentication mechanism ensures data integrity and reliability and prevents
data from being forged or tampered with during transmission.
Encryption
IPSec uses symmetric encryption algorithms to encrypt and decrypt data. Figure 4-6 shows
the process of encrypting and decrypting data through the same key (that is, a symmetric key)
between two IPSec peers.
A symmetric key used for encryption and decryption can be configured manually or generated
automatically through IKE negotiation.
Common symmetric encryption algorithms include Data Encryption Standard (DES), Triple
Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). DES and
3DES are not recommended because they are insecure and pose security risks.
Authentication
IPSec uses the Keyed-Hash Message Authentication Code (HMAC) function to compare
digital signatures to check integrity and authenticity of data packets.
Encryption and authentication are often used together. As shown in Figure 4-7, the IPSec
sender encrypts an IP packet, generates a digital signature through an authentication algorithm
and a symmetric key, and then sends both the encrypted IP packet and digital signature to the
IPSec receiver. The digital signature is included in the Integrity Check Value (ICV) field of an
AH or ESP header. For details, see 4.2.1.2 Security Protocols. The IPSec receiver processes
the encrypted packet using the same authentication algorithm and symmetric key, and
compares the received digital signature with the locally generated one to check integrity and
authenticity of data in the received IP packet. The IPSec receiver discards any packets that fail
the authentication and decrypts only those that pass the authentication.
Encrypted ICV
ICV
IP packet
Encrypted
ICV
IP packet
Similar to a symmetric key used for encryption, a symmetric key used for authentication can
be configured manually or generated automatically through IKE Protocol negotiation.
Common authentication algorithms include Message Digest 5 (MD5), Secure Hash Algorithm
1 (SHA1), and SHA2. MD5 and SHA1 are not recommended because they are insecure and
pose security risks.
How to securely share a symmetric key is an important issue during encryption and
authentication using the key. Two methods are available to address this issue:
l Out-of-band key sharing
An encryption key and an authentication key are manually configured on the IPSec
sender and receiver. The two parties ensure key consistency in out-of-band mode, for
example, by exchanging phone calls or emails. This mode not only has poor security and
scalability, but also multiplies the workload in configuring keys in point-to-multipoint
networking. In addition, this mode is difficult to implement because the keys need to be
modified periodically for security purposes.
l Using a secure key distribution protocol
Keys are generated through IKE negotiation. The IKE protocol uses the DH algorithm to
implement secure key distribution over an insecure network. This mode is easy to
configure and provides high scalability, especially on a large dynamic network. Two
communicating parties exchange keying materials to calculate shared keys. Even if a
third party obtains all the exchanged data used to calculate the shared keys, it cannot
calculate the shared keys. Therefore, this mode greatly improves security.
IKE Protocol
IKE is a UDP-based application-layer protocol built on the Internet Security Association and
Key Management Protocol (ISAKMP) framework. IPsec uses the IKE protocol for key auto-
negotiation and IPSec SA establishment, simplifying IPSec configuration and maintenance.
Figure 4-8 shows the relationship between IKE and IPSec. Two peers establish an IKE SA for
identity authentication and key exchange. Protected by the IKE SA, the peers negotiate a pair
of IPSec SAs using the AH or ESP protocol and other configured parameters. Subsequently,
data is encrypted and transmitted between the peers in an IPSec tunnel.
An IKE SA is bidirectional, so only one IKE SA needs to be established between two peers.
Peer A Peer B
IKE SA IKE SA
UDP UDP
AH/ESP AH/ESP
IP
Encry IP
packet
hash value, the authentication succeeds. Otherwise, authentication fails. For a peer
that has multiple remote IPSec peers, PSK authentication requires each pair of peers
to have the same PSK. This authentication method can be easily implemented on
small-scale networks but has low security.
– RSA signature authentication: Two peers use a certificate issued by a certificate
authority (CA) to verify the validity of a digital certificate. Each peer has a public
key (transmitted over the network) and a private key (possessed by itself). The
sender computes a hash value for original packets, and then encrypts the hash value
using its private key to generate a digital signature. The receiver decrypts the digital
signature using the public key received from the sender, and then computes a hash
value for packets. If the computed hash value is the same as that decrypted from the
digital signature, the authentication succeeds. Otherwise, authentication fails. RSA
signature authentication provides high security but requires digital certificates
issued by a CA. This authentication method is applicable to large-scale networks.
IKE supports the following authentication algorithms: MD5, SHA1, SHA2-256,
SHA2-384, and SHA2-512.
l Identity protection
After a key is generated, identity data is encrypted using the key to ensure secure
transmission.
IKE supports the following encryption algorithms: DES, 3DES, AES-128, AES-192, and
AES-256.
l DH
DH is a public key exchange method that generates keying materials and uses ISAKMP
messages to exchange keying materials between the sender and receiver. The two
devices compute the same symmetric key and generate an encryption key and an
authentication key based on this symmetric key. The encryption key and authentication
key are never exchanged between the two devices. DH key exchange is central to IKE.
l Perfect Forward Secrecy (PFS)
If PFS is enabled, an additional DH key exchange is performed when keys used in IPSec
SAs are generated based on the keys used in the IKE SA. This ensures that the keys used
in IPSec SAs remain indecipherable even if a key used in the IKE SA is deciphered.
l The MD5 and SHA1 authentication algorithms are insecure. The more secure SHA2-256,
SHA2-384, or SHA2-512 algorithm is recommended.
l The DES and 3DES encryption algorithms are insecure. The more secure AES algorithm is
recommended.
IKE versions
IKE has two versions: IKEv1 and IKEv2. IKEv2 has the following advantages over IKEv1:
IKEv1 goes through two phases to establish SAs. In phase 1, two peers negotiate and
establish a secure tunnel, which is an IKE SA. In phase 2, the peers establish a pair of IPSec
SAs for secure data transmission through the secure tunnel established in phase 1.
IKEv1 Phase 1
IKEv1 phase 1 needs to establish an IKE SA. After an IKE SA is established, all the ISAKMP
messages transmitted between two IPSec peers are encrypted and authenticated. The secure
tunnel established in phase 1 enables IPSec peers to communicate securely in phase 2.
IKEv1 phase 1 can use either main mode or aggressive mode.
The main mode requires three exchanges between the peers, totaling six ISAKMP messages,
as shown in Figure 4-9. The three exchanges are described as follows:
1. Messages (1) and (2) are used for proposal exchange.
The initiator sends one or more IKE proposals to the responder. The responder then
searches for IKE proposals and sends the first matched proposal to the initiator. IKE
proposals of the initiator and responder match if they have the same encryption
algorithm, authentication algorithm, authentication method, and DH group identifier.
2. Messages (3) and (4) are used for key information exchange.
The initiator and responder exchange the DH public value and nonce value to generate
the IKE SA authentication key and encryption key.
3. Messages (5) and (6) are used for exchanging identity and authentication information.
The initiator and responder use the generated keys to authenticate each other and the
information exchanged in main mode.
l An IKE proposal is a set of algorithms used to secure IKE negotiation, including the encryption
algorithm, authentication algorithm, DH group, and authentication method.
l A nonce value is a random number that is used to check whether the IKE SA is alive and to protect
against replay attacks.
The aggressive mode requires only two exchanges, totaling three messages. Messages (1) and
(2) are used to negotiate an IKE proposal and exchange the DH public value, mandatory
auxiliary information, and identity information. Message (2) also contains the identity
information sent by the responder to the initiator for authentication. Message (3) is used by
the responder to authenticate the initiator. Figure 4-9 shows IKEv1 phase 1.
Compared with the main mode, the aggressive mode reduces the number of exchanged
messages and speeds up the negotiation. However, the aggressive mode does not encrypt
identity information.
IKEv1 Phase 2
IKEv1 phase 2 establishes IPSec SAs and generates keys for securely transmitting data. This
phase uses the quick mode. This mode uses the keys generated in phase 1 to verify the
integrity of ISAKMP messages and identities of the initiator and responder, and to encrypt
ISAKMP messages, ensuring exchange security. Figure 4-10 shows IKEv1 phase 2.
Initiator Responder
Send IPSec
1 Search matching
proposals, identity,
IPSec proposal and
and authentication
generate keys
data
Send acknowledged
Accept IPSec 2 IPSec proposal,
proposal and
identity, and
generate keys
authentication data
Send acknowledged 3
Accept information
information
In IKEv1 phase 2, two IPSec SAs are established through three ISAKMP messages:
1. The initiator sends local security parameters and identity authentication information to
the responder.
Security parameters include protected data flows and parameters to be negotiated, such
as the IPSec proposal. Identity authentication information includes the keys generated in
phase 1 and keying materials generated in phase 2, and can be used to authenticate the
peer again.
An IPSec proposal is a set of protocols and algorithms used for negotiation, including the security
protocol, encryption algorithm, and authentication algorithm.
2. The responder sends acknowledged security parameters and identity authentication
information, and generates new keys.
The encryption key and authentication key used for secure data transmission over IPSec
SAs are generated based on the keys generated in phase 1 and parameters such as the SPI
and protocol. This ensures that each IPSec SA has unique encryption and authentication
keys.
If PFS is enabled, the DH algorithm is used again to generate shared keys, based on
which the encryption key and authentication key are calculated. Therefore, during
parameter negotiation, a DH key group needs to be negotiated for PFS.
3. The initiator sends acknowledged information to communicate with the responder.
IKEv1 negotiation then ends.
The process of establishing SAs through IKEv2 negotiation is much simpler than that through
IKEv1 negotiation. To establish a pair of IPSec SAs, IKEv1 requires two phases: main or
aggressive mode + quick mode. At least nine messages are exchanged in main mode + quick
mode, and at least six messages are exchanged in aggressive mode + quick mode. In normal
cases, IKEv2 requires only two exchanges, totaling four messages, to establish a pair of IPSec
SAs. One additional Create_Child_SA Exchange can be used to establish another pair of
IPSec SAs if required, during which only two messages are exchanged.
Initial Exchanges
In normal cases, IKEv2 establishes the first pair of IPSec SAs through Initial Exchanges.
Corresponding to IKEv1 phase 1, Initial Exchanges involve four messages in two exchanges,
as shown in Figure 4-11.
Initiator Responder
Non-encrypted information
Encrypted information
Messages (1) and (2) are used in exchange 1 (called IKE_SA_INIT) to negotiate IKE SA
parameters in plaintext, including the encryption key, authentication key, random number, and
DH key. After IKE_SA_INIT is complete, shared keying material is generated, from which all
keys used by IPSec SAs are derived.
Messages (3) and (4) are used in exchange 2 (called IKE_AUTH) to authenticate identities of
the two parties and the first two messages, and to negotiate IPSec SA parameters. The two
messages are encrypted. IKEv2 supports RSA signature authentication, PSK authentication,
and EAP authentication. The initiator does not set the authentication payload in message (3)
to indicate that EAP authentication is required.
Create_Child_SA Exchange
After one pair of IPSec SAs is established based on an IKE SA, Create_Child_SA Exchange
can be performed to negotiate more pairs of IPSec SAs. In addition, Create_Child_SA
Exchange can be performed for IKE SA re-negotiation.
Create_Child_SA Exchange involves two messages in one exchange and corresponds to
IKEv1 phase 2. The initiator in Create_Child_SA Exchange can be the initiator or responder
in Initial Exchanges. Create_Child_SA Exchange can be performed only after Initial
Exchanges are complete. Messages transmitted in Create_Child_SA Exchange are protected
by keys negotiated in Initial Exchanges.
Similar to IKEv1, when PFS is enabled, Create_Child_SA Exchange requires an additional
DH exchange to generate new keying material. All keys used by child SAs are derived from
this keying material.
Informational Exchange
IKEv2 peers perform Informational Exchange to exchange control information, including
error information and notifications, as shown in Figure 4-12.
Informational Exchange must be performed under the protection of an IKE SA. Specifically,
Informational Exchange is performed after Initial Exchanges are complete. Control
information may belong to an IKE SA or a child SA. Therefore, Informational Exchange must
be protected by the IKE SA or the IKE SA based on which child IPSec SAs are established
accordingly.
Initiator Responder
Perform operations
Send control 1 based on control
information
information
2 Respond to control
Accept information
information
Figure 4-13 L2TP over IPSec packet encapsulation and tunnel negotiation
IPSec decapsulation,
PPP L2TP encapsulation,
L2TP decapsulation,
encapsulation IPSec encapsulation
PPP decapsulation
Data PPP packet IPSec packet Data Data
Private IP
Data
Ethernet
Private IP Header
PPP
Header
PPPoE
Header
1. L2TP 2. Two IPSec encapsulation modes
Ethernet
encapsulation Transport mode Tunnel mode
Header
Data Data Data
Direction of a data flow Private IP Private IP Private IP
Packet PPP PPP PPP
Header Header Header
L2TP L2TP L2TP
Header Header Header
UDP UDP UDP
Header Header Header
Public IP AH Public IP
Header AH
Public IP Header
Public IP
Packets are encapsulated by L2TP, and then by IPSec. In the IP header added during IPSec
encapsulation, the source IP address is the IP address of the interface to which the IPSec
policy is applied, and the destination IP address is the IP address of the peer interface to
which the IPSec policy on the remote peer is applied.
IPSec protects the data flows from the source to the destination of the L2TP tunnel. In the
new IP header added during L2TP encapsulation, the source IP address is the address of the
L2TP source interface, and the destination IP address is the address of the L2TP destination
interface. When a branch connects to the headquarters, the source address of the L2TP tunnel
is the IP address of the outbound interface on the L2TP access concentrator (LAC), and the
destination address is the IP address of the inbound interface on the L2TP network server
(LNS).
A public IP address is added to the header in L2TP encapsulation. Compared with the
transport mode, an additional public IP address is added in tunnel mode. As a result, the
packets are larger and more packets will be fragmented in tunnel mode. Therefore, the
transport mode of L2TP over IPSec is recommended.
The L2TP over IPSec negotiation sequence and packet encapsulation process are the same for
employees on the move and employees at branch offices. The difference is that, L2TP and
IPSec encapsulation is performed on clients when employees on the move connect to the
headquarters. The L2TP source address is the private address assigned to the client. The
address can be any address in the address pool configured on the LNS. The destination
address of the L2TP tunnel is the address of the inbound interface on the LNS.
Figure 4-14 Packet encapsulation and tunnel negotiation in GRE over IPSec
In the IP header added during IPSec encapsulation, the source IP address is the IP address of
the interface to which the IPSec policy is applied, and the destination IP address is the IP
address of the peer interface to which the IPSec policy on the remote peer is applied.
IPSec protects the data flows from the GRE source address to the GRE destination address. In
the IP header added during GRE encapsulation, the source address is the source address of the
GRE tunnel, and the destination address is the destination address of the GRE tunnel.
independently, and therefore IP addresses on different private networks may overlap. The
IPSec multi-instance function can be configured on the VPN gateway to bind IPSec tunnels of
the three enterprises to different VPN instances. This ensures that packets with the same
destination IP addresses can be correctly forwarded.
Entrprise 1 Enterprise 1
headquarters VPN gateway
Branch
FW VPN1
Entrprise 2 VPN2 Enterprise 2
headquarters Branch
VPN3
Entrprise 2
headquarters Enterprise 3
Branch
IPSec tunnel
Branch Standby HQ
link
Branch Standby HQ
link
Tunnel interface 2
Server Server
IPSec tunnel
Data flows
IPSec Multi-link
In Figure 4-17, Router_A connects to Router_B through active and standby links. An IPSec
tunnel is established between a physical interface of Router_A and a tunnel interface of
Router_B. On RouterB, traffic is processed by IPSec on the tunnel interface and sent out by a
physical interface according to the routing table. When the active link fails, the corresponding
route is unreachable and traffic is switched to the standby link. Re-negotiation is not required
for the IPSec tunnel, so traffic can be rapidly switched.
PC
PC
Active link
Branch Tunnel1 HQ
Standby Router_B
Router_A
Server link Server
IPSec Tunnel
PC
Active PC
link
Branch Tunnel1 HQ
Standby Router_B
Router_A
Server link
Server
Data flows
A tunnel interface can implement multi-link redundancy. This mode is simpler and switches
traffic faster than the active/standby links.
NOTICE
In the scenario where an IPSec gateway is connected to different ISP networks or the same
ISP network but the active and standby links are connected to different access routers of the
same ISP network across LANs or areas, if the active link becomes faulty, the device on the
standby link may discard the IPSec packets whose source address belongs to a different ISP
network or access router. Therefore, before configuring link redundancy, check whether
active/standby link switching is allowed in the actual network environment.
IPSec Tunnel
PC PC
Branch
Headquarters
Router_A Router_B
Server Server
This network requires that two gateways on both ends of the tunnel have fixed IP addresses or
fixed domain names, and both parties be able to initiate a connection.
Figure 4-19 shows a network for the branch to access the headquarters through an L2TP over
IPSec tunnel. The outbound interfaces of the LAC (FW_A) and L2TP network server (LNS)
(FW_B) have fixed IP addresses. A user in the branch dials FW_A through PPPoE. FW_A
then initiates a tunnel setup request to FW_B over the Internet. An L2TP over IPSec is set up
between FW_A and FW_B. Then FW_A authenticates the user, and FW_B can also
authenticate the user again after the user is successfully authenticated by FW_A. After the
user is successfully authenticated by FW_B, FW_B assigns a private IP address to the user.
Figure 4-19 Branch accessing the headquarters through an L2TP over IPSec tunnel
Branch Headquarters
PC PC
Branch Headquarters
Router_A Router_B
Server Server
GRE over IPSec supports the transport and tunnel encapsulation modes. Compared to the
transport mode, the tunnel mode adds an extra IPSec header, which makes the packet longer
and more likely to be fragmented. Therefore, GRE over IPSec in transport mode is
recommended.
IPSec Tunnel
Router_A
(Spoke) Server
Branch 1 Router_C
(Hub)
HQ
Branch 2
Router_B PC
(Spoke)
IPSec Tunnel
The headquarters has a fixed public IP address or a fixed domain name. Branches support
static or dynamic public IP addresses and private IP addresses. Data traffic is transmitted in
the following scenarios:
l Branches do not need to communicate with each other.
Deploy IPSec VPN between the headquarters and branches.
l Branches need to communicate with each other.
If branches access the Internet using dynamic public IP addresses, traditional IPSec VPN
will cause branches to fail to directly communicate with each other. Communication data
between branches has to be forwarded through the headquarters. This consumes the CPU
and memory resources of the hub (FW_C). In addition, the headquarters must
encapsulate and decapsulate traffic between branches, causing additional network delay.
To resolve this problem, deploy Dynamic Smart VPN (DSVPN) to set up VPN tunnels
between branches using dynamic IP addresses. However, multipoint GRE (mGRE)
tunnels do not have the encryption function and cannot ensure communication security.
To achieve communication security, bind DSVPN with the IPSec security framework,
that is, deploy DSVPN over IPSec. For details about DSVPN over IPSec, see 3.2.4
DSVPN Protected by IPSec.
major concern in remote access. IPSec VPN can be deployed to establish an IPSec tunnel
between a user terminal and the gateway of the core network. IPSec ensures secure and
reliable data transmission.
As shown in Figure 4-22, mobile users (such as traveling staff) use built-in VPN dial-up
software of Windows or other dial-up software to access the enterprise network. L2TP
provides the user authentication function, but no encryption function. To ensure security,
deploy L2TP over IPSec and set up an L2TP over IPSec tunnel between the PC and enterprise
gateway Router. Packets are encapsulated using L2TP and then encrypted using IPSec before
being transmitted, ensuring communication security.
Access users are authenticated locally or remotely by the authentication server (RADIUS
server, for example) in the headquarters. After authentication is successful, Router assigns
private IP addresses within the headquarters network to users (PCs or mobile terminals).
Figure 4-22 Remote access of mobile users using L2TP over IPSec
L2TP over IPSec Tunnel
Router
Enterprise
network
PC
RADIUS Server
Using an ACL to establish An ACL defines data flows 4.7 Using an ACL to
an IPSec tunnel to be protected by an IPSec Establish an IPSec Tunnel
tunnel. You need to
configure an IPSec policy
and apply it to an interface
to protect data
communication. You can use
an ACL to establish an
IPSec tunnel in manual
mode or IKE negotiation
mode.
SAs can be established in
either of the following
modes:
l Manual mode: All
information required by
SAs must be manually
configured.
l IKE negotiation mode:
IPSec peers use IKE to
negotiate keys and
dynamically create and
maintain SAs.
The manual mode applies to
small-sized networks or
scenarios where a few IPSec
peers exist. The IKE
negotiation mode applies to
medium- and large-sized
networks.
In manual mode, an ACL is used to establish an IPSec tunnel. In other modes, SAs are
generated through IKE negotiation to establish an IPSec tunnel and an IKE peer needs to be
configured and referenced.
Licensing Requirements
When using the Efficient VPN policy to establish an IPSec tunnel, note the following points:
l If a branch server needs to provide services for external users through NAT, the nat
static command must be used on the remote device.
l When a remote device requests an IP address from the Efficient VPN server, a loopback
interface is dynamically created on the remote device. Other services cannot be
configured on the loopback interface.
IPSec is a basic feature of the device and is not under license control.
For Efficient VPN-capable devices, their licensing requirements for the Efficient VPN
function are as follows:
Impact on Performance
l The DH group value has impacts on IKE negotiation performance (such as the tunnel
creation rate). A higher DH group value has greater impacts on IKE negotiation
performance (for example, the tunnel creation rate greatly decreases).
l When the number of IPSec tunnels is greater than 50% of the maximum limit, high CPU
usage alarms may be generated in a short period of time after the undo ipsec policy or
undo ipsec profile command is run. After all the SAs are cleared, the CPU usage
restores to the normal range.
l Setting the MTU to a value less than 256 bytes is not recommended for the interface to
which an IPSec policy group applies. As IP packets become longer after IPSec
processing, a small MTU makes the interface divide a large IP packet into multiple
fragments. The peer device may not properly receive or process such fragmented
packets.
l When a NAT device is deployed between IPSec peers, NAT traversal must be enabled
and the security protocol must be ESP.
l In AH encapsulation mode, the DF flag bit of the inner packet is inherited to the outer
packet, and the Router combines it with the DF flag bit of the outer layer to calculate the
checksum of the packet. If the peer end of the tunnel removes the DF flag bit from the
outer packet and then calculates the checksum, the checksums on both ends of the tunnel
are inconsistent. As a result, the interconnection fails. To prevent this, run the ipsec df-
bit clear command to ensure that the checksums on both ends of the tunnel are
consistent.
l When the IPSec protocol on both the AR and its connected other device uses the SHA-2
algorithm, an IPSec tunnel can be established but traffic cannot be transmitted if the
SHA-2 encryption and decryption modes on the two devices are different. If so, you are
advised to run the ipsec authentication sha2 compatible enable command on the AR to
set the SHA-2 encryption and decryption modes to be the same as those on the other
device.
l Packets before and after IPSec encryption supported by the AR650&AR1600&AR6100
series routers can contain 1800 bytes at most.
l It is not recommended that IPSec be deployed on both physical interfaces and tunnel
interfaces. If IPSec is deployed on both physical interfaces and tunnel interfaces, the
device functioning as the negotiation responder first attempts to perform tunnel
negotiation through IPSec of a tunnel interface. If the device does not match IPSec
access requirements of the tunnel interface, the device attempts to perform tunnel
negotiation through IPSec of a physical interface.
l In transport mode, the flow information after IPSec negotiation must be consistent with
the IPSec tunnel address, which is a 32-bit host address.
Before establishing an IPSec tunnel using an ACL, complete the following tasks:
l Configure a reachable route between source and destination interfaces.
l (Optional) If ACL-based GRE over IPSec needs to be configured, perform the following
configurations:
a. Create a tunnel interface and set the type of the interface to GRE.
b. Configure source and destination IP addresses, and interface IP addresses. The
source IP address is the IP address of the outbound interface on the gateway, and
the destination IP address is the IP address of the outbound interface on the remote
gateway.
c. Add tunnel interfaces to a zone.
Configuration Process
Figure 4-23 shows the configuration process (IKEv1 is used).
1 Preparations
(1) Define data flows to be
protected by IPSec (3) Define IKE protection method (4) Define attributes of IKE peers
(1) Configure an advanced ACL (3) Configure an IKE proposal (4) Configure an IKE peer
ike proposal ike peer
Configure an advanced Configure an authentication
ACL rule mode Reference an IKE proposal
rule permit ip authentication-method ike-proposal
(2) Define IPSec protection method Configure an authentication
algorithm Configure an authentication
(2)Configure an IPSec proposal authentication-algorithm key
ipsec proposal
Configure an encryption Configure a remote IP
Configure a security algorithm address
protocol encryption-algorithm remote-address
transform
Configure a DH group Configure a phase 1
Configure an authentication negotiation mode
dh
algorithm exchange-mode
authentication-algorithm
IKE SA lifetime (Optional) Set parameter
Configure an encryption
sa duration extensions
algorithm
encryption-algorithm
(Optional) Set parameter
Configure an encapsulation
extensions
mode
encapsulation-mode
2 Configure an IPSec policy. Use a specified protection method for specified data flows.
· Manually created IPSec policy · IPSec policy established · IPSec policy established using
in IKE negotiation mode an IPSec policy template
Configure an IPSec policy
Configure an IPSec policy Configure an IPSec policy
template
ipsec policy manual ipsec policy isakmp
ipsec policy-template
Reference an IPSec
Reference an ACL Reference an ACL
proposal
security acl security acl
proposal
Reference an IPSec
Reference an IPSec proposal Reference an IKE peer
proposal
proposal ike-peer
proposal
Configure source and
Reference an IKE peer (Optional) Set parameter
destination of an IPSec tunnel
ike-peer extensions
tunnel local
tunnel remote
Configure SPIs of the inbound (Optional) Set parameter
and outbound Sas extensions Reference an IPSec policy
sa spi outbound template in an IPSec policy
sa spi inbound ipsec policy policy-name
seq-number isakmp
Configure authentication and template
encryption keys of inbound and
outbound SAs
3 Apply an IPSec policy group to an interface. An IPSec tunnel is established when IPSec parameters at
both ends are the same.
Enter the system view Enter the interface view
system-view interface
+ Apply the IPSec policy
(Optional) Set parameter
group
extensions
ipsec policy
Context
IPSec can protect one or more data flows, and the ACL specifies data flows to be protected by
IPSec. Therefore, you need to create an ACL and apply the ACL to an IPSec policy. An IPSec
policy can reference only one ACL. Note the following points:
l If data flows have different security requirements, create different ACLs and IPSec
policies.
l If data flows have the same security requirements, configure multiple rules in an ACL.
ACL Keyword Usage
Each ACL rule is a deny or permit clause. In IPSec applications, a permit clause identifies a
data flow protected by IPSec, and a deny clause identifies a data flow that is not protected by
IPSec. An ACL can contain multiple rules. A packet is processed according to the first rule
that it matches.
l In the outbound direction of an SA
If a packet matches a permit clause, IPSec encapsulates and sends the packet. If a packet
matches a deny clause or does not match a permit clause, IPSec directly forwards the
packet. A matched permit clause indicates that a data flow needs to be protected and a
pair of SAs is created.
l In the inbound direction of an SA
The packet protected by IPSec is decrypted and the packet not protected by IPSec is
forwarded.
If 4.7.8 (Optional) Configuring IPSec Check is performed, the device re-checks whether the IP
header of the decrypted IPSec packet is in the range defined by the ACL. If the decrypted IPSec packet
matches the permit clause, the device continues to process the IPSec packet. If the decrypted IPSec
packet does not match the permit clause, the device discards the IPSec packet.
Precautions
l The protocols defined in the ACLs on both ends of the IPSec tunnel must be the same.
For example, if the protocol on one end is IP, the protocol must also be IP on the other
end.
l When ACL rules at both ends of an IPSec tunnel mirror each other, SAs can be set up
successfully no matter which party initiates negotiation. If ACL rules at both ends of an
IPSec tunnel do not mirror each other, SAs can be set up successfully only when the
range specified by ACL rules on the initiator is included in the range specified by ACL
rules on the responder. It is recommended that ACL rules at both ends of an IPSec tunnel
mirror each other. That is, the source and destination addresses of an ACL rule at one
end are the destination and source addresses of an ACL rule at the other end. The IKEv1
and IKEv2 configurations are as follows:
If IPSec policies in ISAKMP mode are configured at both ends, ACL rules at both ends
of an IPSec tunnel must mirror each other. If an IPSec policy in ISAKMP mode is
configured at one end and an IPSec policy using an IPSec policy template is configured
at the other end, the range specified by ACL rules in the IPSec policy in ISAKMP mode
can be included in the range specified by ACL rules in the IPSec policy using an IPSec
policy template. The devices use overlapping ACL rules as the negotiation result.
l Avoid overlapped address segments in ACL rules. Rules with overlapped address
segments may affect each other, causing data flow mismatch.
l The ACL referenced in an IPSec policy group cannot contain rules of the same ID.
l ACL rules referenced in all IPSec policies of an IPSec policy group cannot overlap. In
the following example, ACL 3001 and ACL 3002 overlap.
acl number 3001
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
acl number 3002
rule 5 permit ip source 10.1.0.0 0.0.255.255 destination 10.1.0.0 0.0.255.255
l When the responder uses an IPSec policy template, note the following points:
If data flows to be protected are not specified, the responder accepts the range of data
flows to be protected on the initiator. If data flows to be protected are specified, the ACL
on the responder must mirror the ACL on the initiator or the range specified by the ACL
on the responder must cover the range specified by the ACL on the initiator.
After an IPSec tunnel has been established, if both permit and deny actions are
configured in an ACL rule in the IPSec policy template view, the deny action does not
take effect.
l If NAT is configured on an interface to which an IPSec policy is applied, IPSec may not
take effect because NAT is performed first. You can use the following methods:
– Configure the destination IP address that matches the deny clause in an ACL
referenced by NAT as the destination IP address in an ACL rule referenced by
IPSec. In this case, data flows protected by IPSec are not translated by NAT.
– Configure the ACL rule referenced by NAT to match the IP address translated by
NAT.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run acl [ number ] acl-number [ match-order { config | auto } ]
An advanced ACL is created and the advanced ACL view is displayed. acl-number ranges
from 3000 to 3999.
Step 3 Run the following commands as required.
l Run the rule [ rule-id ] { deny | permit } ip [ destination { destination-address
destination-wildcard | any } | source { source-address source-wildcard | any } | dscp
dscp | vpn-instance vpn-instance-name ] * command to configure a rule to match the IP
protocol.
l Run the rule [ rule-id ] { deny | permit } tcp [ destination { destination-address
destination-wildcard | any } | destination-port eq port | source { source-address source-
wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] *
command to configure a rule to match the TCP protocol.
l Run the rule [ rule-id ] { deny | permit } udp [ destination { destination-address
destination-wildcard | any } | destination-port eq port | source { source-address source-
wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] *
command to configure a rule to match the UDP protocol.
l Run the rule [ rule-id ] { deny | permit } gre [ destination { destination-address
destination-wildcard | any } | source { source-address source-wildcard | any } | dscp
If the data flow to be protected carries VPN labels, the corresponding vpn-instance-name must be specified
during the ACL configuration.
----End
Configuration Guidelines
The configurations of rules vary in different scenarios. For details, see the following
examples:
Site-to-Site IPSec VPN
A site-to-site IPSec tunnel is set up between gateway A and gateway B. Gateway A protects
subnet 10.1.1.0/24 and gateway B protects subnet 192.168.196.0/24.
Configurations on gateway A:
[Huawei] acl 3001
[Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination
192.168.196.0 0.0.0.255
Configurations on gateway B:
[Huawei] acl 3001
[Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
l To allow the communication between branches and the headquarters, and between
branches through the headquarters, set the source address of the ACL at the headquarters
to all subnets of the headquarters and branches. Set the destination address to all branch
subnets. The source addresses of the ACLs at the branch offices remain, but the
destination addresses must be the subnets of the headquarters and all other branches.
The ACL at the headquarters is configured as follows:
10.1.2.0 0.0.0.255
[Huawei-acl-adv-3001] quit
Configuration on endpoint B:
[Huawei] acl number 3001
[Huawei-acl-adv-3001] rule permit ip source 1.2.1.1 0 destination 1.1.1.1 0
[Huawei-acl-adv-3001] quit
Context
An IPSec proposal, as part of an IPSec policy or an IPSec profile, defines security parameters
for IPSec SA negotiation, including the security protocol, encryption and authentication
algorithms, and encapsulation mode. Both ends of an IPSec tunnel must be configured with
the same parameters.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.
Step 3 Run transform { ah | esp | ah-esp }
A security protocol is configured.
By default, an IPSec proposal uses ESP.
Step 4 An authentication or encryption algorithm is configured.
l If AH is used, you can only configure the AH-specific authentication algorithm because
AH only authenticates packets.
Run ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
An AH-specific authentication algorithm is configured.
By default, the AH authentication algorithm is SHA2-256.
l When ESP is specified, ESP can encrypt/authenticate, or encrypt and authenticate
packets. Configure the ESP-specific authentication or encryption algorithm.
– Run esp authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 |
sha2-512 }
When GRE over IPSec is configured, a public IP header is added to packets during GRE encapsulation.
Compared with the transport mode, the tunnel mode adds another public IP header. In tunnel mode, the
packet length is longer and packets are more likely to be fragmented. The transport mode is therefore
recommended.
----End
and specifies the SA negotiation mode, source and destination of the IPSec tunnel, key, and
SA lifetime.
An IPSec policy is identified by its name and sequence number, and multiple IPSec policies
with the same IPSec policy name constitute an IPSec policy group. An IPSec policy can be
established manually, in ISAKMP mode, or using an IPSec policy template. For IPSec
policies that are established in ISAKMP mode and using an IPSec policy template, parameters
are generated through IKE negotiation.
Select an IPSec policy establishment mode as needed:
l When a GRE over IPSec tunnel is established using an ACL, an IPSec policy in ISAKMP mode can only
be configured on gateways at both ends.
Context
All security parameters of an IPSec policy configuring in manual mode need to be configured
manually. The configuration workload is heavy, so the IPSec policy applies to a small-scale
network environment.
When configuring an IPSec policy in manual mode, ensure that:
l Inbound and outbound SAs' parameters, including the authentication/encryption key and
security parameter index (SPI), are configured on IPSec peers.
l The inbound SA's parameters on the local end is the same as the outbound SA's
parameters on the remote end, and the outbound SA's parameters on the local end is the
same as the inbound SA's parameters on the remote end.
After an IPSec policy group is applied to an interface, to add or delete an IPSec policy in the
IPSec policy group or modify parameters of the IPSec policy, unbind the IPSec policy group
from the interface and then apply the IPSec policy group to the interface again so that IPSec
policies in the IPSec policy group take effect.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec policy policy-name seq-number manual
An IPSec policy is created in manual mode and the IPSec policy view is displayed.
By default, no IPSec policy is created.
Step 3 Run security acl acl-number
An ACL is referenced in the IPSec policy.
By default, an IPSec policy does not reference an ACL.
acl-number is an advanced ACL that has been created.
An IPSec policy can reference only one ACL. Before referencing a new ACL, you must
delete the original ACL that has been referenced.
l The security protocol specified in authentication and encryption key configuration commands must
be the same as that specified in the transform command in 4.7.2 Configuring an IPSec Proposal.
If the security protocol specified in the transform command is ah-esp, both ah and esp
authentication and encryption keys must be specified.
l The two ends of an IPSec tunnel must use the authentication keys in the same format. For example,
if the key on one end is a character string but the key on the other end is a hexadecimal number, the
IPSec tunnel cannot be established.
l If simple is specified, the password is saved in the configuration file in plain text. This brings
security risks. It is recommended that you specify cipher to save the password in cipher text.
l If the inbound authentication keys in a character string and hexadecimal notation are configured, the
one configured later overwrites the original one.
When ESP is used and the authentication key in a character string is used, the device automatically
generates the encryption key of ESP. You do not need to configure the encryption key of ESP.
----End
Context
An IPSec policy configured in Internet Security Association and Key Management Protocol
(ISAKMP) mode applies to a scenario where the remote IP address is fixed, and is often used
in branch configuration.
Negotiated IPSec parameters of an IPSec policy are defined in the IPSec policy view, and the
negotiation initiator and responder must use the same IPSec parameters. The end that has an
ISAKMP IPSec policy configured can initiate IKE negotiation.
After an IPSec policy group to which an IPSec policy belongs is applied to an interface, the
following situations occur:
l To modify the IPSec proposal parameters, unbind the IPSec policy group from the
interface and then apply the IPSec policy group to the interface again.
l If other parameters are modified, these parameters will take effect during the next
negotiation and are invalid for the tunnels that have been established through
negotiation.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec policy policy-name seq-number isakmp
An IPSec policy is created in ISAKMP mode and the IPSec policy view is displayed.
By default, no IPSec policy is created.
Step 3 (Optional) Run alias alias
When referencing multiple IPSec proposals in an IPSec policy, ensure that the encapsulation modes of all
IPSec proposals referenced by the IPSec policy at both ends are the same. That is, the encapsulation modes
are all transport or tunnel modes.
local end of an IPSec tunnel. Otherwise, run the tunnel local applied-interface
command to specify the IP address of the interface to which an IPSec policy is applied as
the local address of an IPSec tunnel.
l If the interface to which an IPSec policy is applied has multiple IP addresses (one
primary IP address and several secondary IP addresses), run the tunnel local ipv4-
address command to specify one of these IP addresses as the IP address for the local end
of an IPSec tunnel. Otherwise, run the tunnel local applied-interface command to
specify the primary IP address of the interface as the local address of an IPSec tunnel.
l If equal-cost routes exist between the local and remote ends, run the tunnel local
command to specify a local IP address for an IPSec tunnel.
l If an IPSec policy is created in IKE negotiation mode, the tunnel local on the local end must be the
same as remote-address (IKE peer view) that the remote end references from the IKE peer.
l You do not need to specify the tunnel local (local address) for the IKE peer referenced in an IPSec
profile, because the local address is the source address of the GRE, mGRE or IPSec virtual tunnel
interface. For the IKE peer referenced in an IPSec profile, tunnel local does not take effect.
l When applying an IPSec policy to a tunnel interface and running the source command to specify an
IP address for the interface, you must run the tunnel local command to configure a tunnel local
address. Otherwise, IKE negotiation will fail.
l In an IPSec hot standby scenario, tunnel local must be set to a virtual IP address.
An outbound interface on the IPSec tunnel for IKE negotiation packets is configured.
By default, no outbound interface is configured on the IPSec tunnel for IKE negotiation
packets.
When there are multiple outbound interfaces, the device determines the outbound interface for
IKE negotiation packets based on routes. If the outbound interface for IKE negotiation
packets differs from that for IPSec service packets, IKE negotiation may fail. In this case,
perform this step to specify a correct outbound interface.
Step 10 (Optional) Run pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group19 | dh-
group20 | dh-group21 }
The device is configured to use perfect forward secrecy (PFS) when the local end initiates
negotiation.
By default, PFS is not used when the local end initiates negotiation.
When the local end initiates negotiation, there is an additional Diffie-Hellman (DH) exchange
in IKEv1 phase 2 or IKEv2 CREATE_CHILD_SA exchange. The additional DH exchange
ensures security of the IPSec SA key and improves communication security.
If PFS is specified on the local end, you also need to specify PFS on the remote end. The DH
group specified on the two ends must be the same; otherwise, negotiation fails. When an
IPSec policy in ISAKMP mode is used on the local end while an IPSec policy configured
using an IPSec policy template is used on the remote end, no DH group needs to be
configured on the remote end. The DH group on the responder is used for negotiation.
Step 11 (Optional) Run respond-only enable
The local end is configured not to initiate negotiation.
By default, if the local end establishes an IPSec tunnel based on the IPSec policy configured
in ISAKMP mode, the local end initiates an IPSec negotiation.
If two IPSec peers establish an IPSec tunnel based on the IPSec policy configured in
ISAKMP mode, both ends initiate negotiation. You can configure one end as the responder
that does not initiate negotiation, which can help you check packet processing and locate
IPSec faults.
Step 12 (Optional) Run policy enable
The IPSec policy is enabled.
By default, IPSec policies in an IPSec policy group are enabled.
----End
Context
When an IPSec policy template is used to configure IPSec policies, the configuration
workload for establishing multiple IPSec tunnels can be reduced. This IPSec policy
configuration mode is often used in the headquarters in scenarios where the remote IP address
is not fixed (for example, the remote end obtains an IP address through PPPoE) or there are
multiple remote devices.
When an IPSec tunnel is set up using an IPSec policy through an IPSec policy template, the
initiator determines optional parameters, and the responder accepts the parameters delivered
by the initiator. The end that has an IPSec policy configured using an IPSec policy template
can only function as the responder to receive negotiation requests.
When using an IPSec policy template to configure an IPSec policy, note the following points:
l If one end (responder) of an IPSec tunnel has an IPSec policy configured using an IPSec
policy template, the other end (initiator) must have an IPSec policy configured in
ISAKMP mode.
l In an IPSec policy template, an IPSec proposal and IKE peer must be referenced, and
other parameters are optional. The initiator determines optional parameters in the IPSec
policy template, and the responder accepts the parameters delivered by the initiator.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec policy-template template-name seq-number
An IPSec policy template is created and the IPSec policy template view is displayed.
By default, no IPSec policy template is created.
By default, the system uses the combination of the name and sequence number of an IPSec
policy template as the alias. If the default alias has been used by another IPSec policy
template, the system uses the combination of the current time as well as the name and
sequence number of an IPSec policy template as the alias.
One IPSec policy template can reference only one ACL. Before referencing a new ACL, you
must delete the ACL that has been referenced.
If data flows to be protected are not specified, the responder accepts the range of data flows to
be protected on the initiator. If data flows to be protected are specified, the ACL on the
responder must mirror the ACL on the initiator or the range specified by the ACL on the
responder must cover the range specified by the ACL on the initiator.
An IPSec policy template can reference a maximum of 12 IPSec proposals. During IKE
negotiation, the two ends of an IPSec tunnel first use the IPSec proposals with the same
parameter settings. If IPSec proposals with the same parameter settings cannot be found, an
SA cannot be set up.
When referencing multiple IPSec proposals in an IPSec policy template, ensure that the encapsulation mode
of IPSec proposals referenced by the IPSec policy template at one end are the same as the encapsulation
mode of IPSec proposals referenced by the IPSec policy at the other end. That is, the encapsulation mode at
both ends must be transport or tunnel.
l If an IPSec policy is created in IKE negotiation mode, the tunnel local on the local end must be the same
as remote-address (IKE peer view) that the remote end references from the IKE peer.
l You do not need to specify the tunnel local (local address) for the IKE peer referenced in an IPSec
profile, because the local address is the source address of the GRE, mGRE or IPSec virtual tunnel
interface. For the IKE peer referenced in an IPSec profile, tunnel local does not take effect.
l When applying an IPSec policy to a tunnel interface and running the source command to specify an IP
address for the interface, you must run the tunnel local command to configure a tunnel local address.
Otherwise, IKE negotiation will fail.
l In an IPSec hot standby scenario, tunnel local must be set to a virtual IP address.
When an IPSec policy template references the identity filter set, the allowed IKE peer can be specified
at the local end. An IPSec tunnel can be established successfully only when the remote end matches one
or more access conditions in the identity filter set and IPSec parameters at both ends match.
Step 10 (Optional) Run pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group19 | dh-
group20 | dh-group21 }
The device is configured to use perfect forward secrecy (PFS) when the local end initiates
negotiation.
By default, PFS is not used when the local end initiates negotiation.
When the local end initiates negotiation, there is an additional Diffie-Hellman (DH) exchange
in IKEv1 phase 2 or IKEv2 CREATE_CHILD_SA exchange. The additional DH exchange
ensures security of the IPSec SA key and improves communication security.
If PFS is specified on the local end, you also need to specify PFS on the remote end. The DH
group specified on the two ends must be the same; otherwise, negotiation fails. When an
IPSec policy in ISAKMP mode is used on the local end while an IPSec policy configured
using an IPSec policy template is used on the remote end, no DH group needs to be
configured on the remote end. The DH group on the responder is used for negotiation.
Step 11 (Optional) Run policy enable
The referenced IPSec policy template name template-name must be different from the IPSec
policy name policy-name.
Only one IPSec policy in an IPSec policy group can reference the policy template, and
number of this policy must be larger than that of other policies. If the IPSec policy created
using the policy template does not have the lowest priority, other IPSec policies in the same
IPSec policy group do not take effect.
----End
Context
l The IPSec SA lifetime is only valid for the IPSec SAs established in IKE negotiation mode.
Manually established IPSec SAs are always valid.
l The configured IPSec SA lifetime is only valid for the new IPSec SAs established in IKE
negotiation mode.
For a dynamic SA, configure the SA hard lifetime so that the SA can be updated in real time,
reducing the crash risk and improving security.
Time-based soft lifetime (soft timeout The value is 70% of the actual hard
period) lifetime (hard timeout period).
Traffic-based soft lifetime (soft timeout l For IKEv1, the value is 70% of the
traffic) actual hard lifetime (hard timeout
traffic).
l For IKEv2, the value is 65% to 75%
of the actual hard lifetime (hard
timeout traffic) plus or minus a
random value.
Before an IPSec SA becomes invalid, IKE negotiates a new IPSec SA for the remote end. The
remote end uses the new IPSec SA to protect IPSec communication immediately after the new
IPSec SA is negotiated. If service traffic is transmitted, the original IPSec SA is deleted
immediately. If no service traffic is transmitted, the original IPSec SA will be deleted after
10s or the hard lifetime expires.
If the time-based lifetime and traffic-based lifetime are both set for an IPSec SA, the IPSec
SA becomes invalid when either lifetime expires.
You can set the global IPSec SA lifetime or set the IPSec SA lifetime in an IPSec policy. If
the IPSec SA lifetime is not set in an IPSec policy, the global lifetime is used. If both the
global IPSec SA lifetime or the IPSec SA lifetime in an IPSec policy are set, the IPSec SA
lifetime in the IPSec policy takes effect.
Procedure
l Set the global IPSec SA hard lifetime.
a. Run system-view
By default, the global time-based SA hard lifetime is 3600 seconds and the global
traffic-based SA hard lifetime is 1843200 Kbytes.
l Set the IPSec SA hard lifetime in an IPSec policy.
a. Run system-view
An IPSec policy template is created and the IPSec policy template view is
displayed.
c. Run sa duration { time-based seconds | traffic-based kilobytes }
The IPSec SA hard lifetime is set in the IPSec policy.
By default, the IPSec SA hard lifetime is not set in an IPSec policy. The system
uses the global IPSec SA hard lifetime.
d. (Optional) Run sa keep-holding-to hard-duration
The device is configured to delete the original IPSec SA after the hard lifetime
expires during IPSec SA re-negotiation.
By default, during IPSec SA re-negotiation, the device deletes the original IPSec
SA immediately after using the new IPSec SA to transmit data.
After a new IPSec SA is negotiated, if the peer device still uses the original IPSec
SA to transmit data while the local device deletes the original IPSec SA
immediately after using the new IPSec SA to transmit data, the IPSec SAs on the
two devices will be different. This will cause IPSec traffic interruption. In this case,
it is recommended to perform this step on the local device.
This function takes effect only for IPSec SAs established through IKEv1
negotiation.
----End
Only SAs established in IKE negotiation mode support the anti-replay function. Manually configured
SAs do not support the anti-replay function.
To ensure non-stop service forwarding, the configured IPSec anti-replay window size takes effect only
for new or re-negotiated IPSec policies but not for existing ones.
Replayed packets are packets that have been processed. IPSec uses the sliding window (anti-
replay window) mechanism to check replayed packets. Each AH or ESP packet has a 32-bit
sequence number. In an SA, sequence numbers of packets increase. If the sequence number of
a received authenticated packet is the same as that of a decapsulated packet or if the sequence
number is out of the sliding window, the device considers the packet as a replayed packet.
Decapsulating replayed packets consumes many resources and makes system performance
deteriorate, resulting in a Denial Of Service (DoS) attack. After the anti-replay function is
enabled, the system discards replayed packets and does not encapsulate them, saving system
resources.
In some situations, for example, when network congestion occurs or QoS is performed for
packets, the sequence numbers of some service data packets may be different from those in
common data packets. The device that has IPSec anti-replay enabled considers the packets as
replayed packets and discards them. You can disable global IPSec anti-replay to prevent
packets from being discarded incorrectly or adjust the IPSec anti-replay window size to meet
service requirements.
The anti-replay function can be configured globally or in an IPSec policy or profile:
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Enable the anti-replay function. Run the following commands as required.
l Enable the anti-replay function globally.
a. Run ipsec anti-replay enable
The anti-replay function is enabled globally.
b. Run ipsec anti-replay window window-size
The global IPSec anti-replay window size is configured.
By default, the global IPSec anti-replay window size is 1024 bits.
l Enable the anti-replay function in an IPSec policy.
a. Run ipsec policy policy-name seq-number [ isakmp | manual ]
An IPSec policy is created and the IPSec policy view is displayed.
b. Run anti-replay window window-size
The IPSec anti-replay window size is configured in the IPSec policy.
By default, the anti-replay window size of a single IPSec tunnel is not set. The
global value is used.
l Enable the anti-replay function in an IPSec policy template.
a. Run ipsec policy-template template-name seq-number
An IPSec policy template is created and the IPSec policy template view is
displayed.
b. Run anti-replay window window-size
The IPSec anti-replay window size is configured in the IPSec policy template.
By default, the anti-replay window size of a single IPSec tunnel is not set. The
global value is used.
----End
fragmentation and reassembly, it cannot decapsulate packets and will discard or incorrectly
process packets, affecting packet transmission.
To prevent this problem, configure IPSec fragmentation before encryption on the local device.
Subsequently, the local device calculates the length of encapsulated packets. If the length
exceeds the MTU, the device fragments the packets and then encapsulates each fragment.
After packets reach the IPSec remote device, the remote device can decapsulate the fragments
without having to reassemble them. The decapsulated packets will be forwarded normally.
Procedure
1. Run system-view
The system view is displayed.
2. Run ipsec fragmentation before-encryption
The fragmentation mode of packets is set to fragmentation before encryption for all
IPSec tunnels.
By default, the packet fragmentation mode for all IPSec tunnels is fragmentation after
encryption.
The DF flag in IPSec packets determines whether IPSec packets can be fragmented. If
DF flag settings disable fragmentation when the fragmentation mode is used, run the
ipsec df-bit { clear | set | copy } command in the system view to enable fragmentation
on IPSec packets.
For the established IPSec tunnels, you need to restart them after running this command.
Otherwise, the command function does not take effect.
Only SAs established in IKE negotiation mode support the route injection function. Manually
configured SAs do not support the route injection function.
The device does not support route injection function when the IPSec policy group is bound to a Layer 2
interface.
When an enterprise headquarters and its branch establish an IPSec tunnel, a static route to the
branch subnet needs to be configured on the headquarters gateway. If there are many branch
subnets, a large number of static routes need to be configured on the headquarters gateway.
When branch subnets change, the static route configuration needs to be modified on the
headquarters gateway, causing a difficulty in network maintenance. Route injection injects
routes to branch subnets to the headquarters gateway based on IPSec tunnel information,
which reduces manual configuration and improves configuration correctness. If a static route
from the branch to the headquarters gateway does not need to be configured manually,
configure route injection.
The route injection function enables a device to generate a route based on the destination
network segment in the flow information of the IPSec SA established on the device. The next
hop of the route is the peer address in the IPSec SA by default.
In Figure 4-24, an IPSec tunnel is established between the branch gateway and headquarters
gateway. The host a1 indicates the branch subnet and the host b1 indicates the headquarters
subnet. An ACL rule is configured on the headquarters gateway and branch gateway to enable
IPSec to protect data traffic from b1 to a1 and data traffic from a1 to b1 respectively. When the
route injection function is disabled, the headquarters gateway needs to ensure that the route to
the branch subnet is reachable. After the route injection function is enabled on the
headquarters gateway, the gateway automatically generates a routing entry with the
destination IP address being the destination network segment in the flow information of the
IPSec SA established by the local end and the next hop being the IPSec tunnel local IP
address of the branch gateway.
IPSec Tunnel
Host a1 IP3 Host b1
IPa1 IP1 IP2 IPb1
Branch Headquarters
gateway gateway
① ① Headquarters
Branch rule permit ip source
subnet
rule permit ip source subnet
IPa1 destination IPb1 IPb1 destination IPa1
② Original route ③ Route added after route
injection is enabled
Destination IP Next Hop Destination IP Next Hop
IP1 IP3 IPa1 IP1
l Static mode: The generated route is added to the local device immediately, and is
independent of IPSec tunnel status change.
l Dynamic mode: If the IPSec tunnel is Up, the generated route can be added to the local
device. If the IPSec tunnel is Down, the generated route can be deleted from the local
device.
Compared with static route injection, dynamic route injection is relevant to the IPSec
tunnel status. Dynamic route injection prevents IPSec peers from sending IPSec packets
over the IPSec tunnel in Down state, reducing packet loss.
You can configure a priority for the route generated through route injection. For example,
when there is another route to the same destination as the route, specify the same priority for
the routes so that traffic can be load balanced. If different priorities are specified for the
routes, the routes can back up each other.
Procedure
Step 1 Run system-view
Step 2 An IPSec policy in IKE negotiation mode or an IPSec policy template is configured.
l Run ipsec policy policy-name seq-number isakmp
An IPSec policy is created in IKE negotiation mode and the IPSec policy view is
displayed.
l Run ipsec policy-template template-name seq-number
An IPSec policy template is created and the IPSec policy template view is displayed.
Step 3 Run route inject [ nexthop ipv4-address ] { static | dynamic } [ preference preference ]
Route injection is enabled.
By default, route injection is disabled.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec decrypt check
Post-IPSec check is enabled.
By default, the device does not check decrypted IPSec packets.
----End
QoS for IPSec packets implements refined QoS management on IPSec packets, choose either
of the following configurations as required:
l After packets are encapsulated using IPSec, the packets do not contain QoS related
parameters, such as header of the original packet and protocol number. Pre-extraction of
original IP packets needs to be configured if QoS needs to group encapsulated packets
based on the 5-tuple information such as original packet header and protocol number.
l When a device implements IPSec encapsulation and decapsulation on packets, it will
result in transmission delay and require higher bandwidth. Therefore, the device needs to
provide differentiated services for IPSec packets to reduce the delay, lower the packet
loss ratio, and maximize bandwidth for IPSec traffic. You can group IPSec packets into
one QoS group to allow QoS to implement differentiated services for IPSec packets.
Figure 4-25 shows the procedure for configuring QoS.
For details on QoS, see Huawei AR Series V300R003 Configuration Guide - QoS Configuring
MQC.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Enter the view where QoS for IPSec packets is configured.
l View of the IPSec policy established in manual mode
Run ipsec policy policy-name seq-number manual
An IPSec policy is created in manual mode and the IPSec policy view is displayed.
l View of the IPSec policy established in IKE negotiation mode
Run ipsec policy policy-name seq-number isakmp
An IPSec policy is created in IKE negotiation mode and the IPSec policy view is
displayed.
l IPSec policy template view
Run ipsec policy-template policy-template-name seq-number
An IPSec policy template is created and the IPSec policy template view is displayed.
Choose either of the preceding methods.
Step 3 Enable the QoS function for IPSec packets.
l Run qos pre-classify
Pre-extraction of original IP packets is enabled.
By default, pre-extraction of original IP packets is disabled.
----End
Follow-up Procedure
l After pre-extraction of original IP packets is enabled, run the if-match acl { acl-number |
acl-name } command in the traffic classifier view to configure a matching rule based on
the ACL.
l After QoS for IPSec packets is enabled, run the if-match qos-group qos-group-value
command in the traffic classifier view to configure a matching rule based on the QoS
group.
If an SA is established in manual mode, you can bind a VPN instance to an IPSec tunnel in an IPSec
policy. If an SA is established in IKE negotiation mode, you can bind a VPN instance to an IPSec tunnel
on an IKE peer. For details, see 4.10.8 (Optional) Configuring IPSec VPN Multi-instance.
When multiple branches connected to the headquarters network across the Internet using
IPSec, you can configure IPSec VPN Multi-instance, thereby isolating traffic of different
branches.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec policy policy-name seq-number manual
An IPSec policy is created in manual mode and the IPSec policy view is displayed.
Step 3 Run sa binding vpn-instance vpn-instance-name
A VPN instance is bound to an IPSec tunnel.
The VPN instance specified by vpn-instance-name must have been created using the ip vpn-
instance command, and must be the same as the VPN instance bound to the ACL that is
referenced by an IPSec policy.
----End
4.7.11 (Optional) Allowing New Users with the Same Traffic Rule
as Original Branch Users to Access the Headquarters Network
Context
After the enterprise branch and its headquarters establish an IPSec tunnel, the IP address of
the branch gateway interface to which an IPSec policy group is applied changes due to the
link status change. For example, the branch gateway connects to the Internet through dial-up
and establishes an IPSec tunnel with the headquarters. The headquarters gateway has an
existing IPSec tunnel to protect IPSec packets exchanged between the headquarters gateway
and branch gateway (original users). Because data flows of new users are the same, the branch
gateway and headquarters gateway cannot reestablish an IPSec tunnel. After the local IP
address of the IPSec tunnel on the branch gateway changes, the branch gateway (new users)
and headquarters gateway cannot rapidly reestablish an IPSec tunnel to protect IPSec traffic
exchanged between them.
You can configure the device to allow new users with the same traffic rule as original branch
users to access the headquarters network so that the existing IPSec SAs can be rapidly aged
and a new IPSec tunnel can be established.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec remote traffic-identical accept
The device is configured to allow new users with the same traffic rule as original branch users
to access the headquarters network.
By default, the device allows branch or other users to quickly access the headquarters network
after their IP addresses are changed.
----End
record IPSec tunnel index to IPSec tunnel mapping. In this mapping table, the device searches
for the corresponding IPSec tunnel based on an IPSec tunnel index. However, when an IPSec
tunnel is re-established, its IPSec tunnel index changes by default. As a result, the IPSec
tunnel cannot be found based on its previous IPSec tunnel index. In this case, configure the
device to keep IPSec tunnel indexes unchanged based on the peer IP address during IPSec
tunnel re-establishment. This configuration ensures that an IPSec tunnel can be found using
its fixed IPSec tunnel index.
l This function works only when devices on both ends use fixed IPv4 addresses and establish only one
IPSec tunnel.
l During IPSec tunnel re-establishment, this function allows the device to keep only the first 1024
IPSec tunnel indexes unchanged based on the sequence in which IPSec tunnels are re-established.
l An IPSec tunnel index mapping table cannot be backed up, so this function does not work in an
active/standby switchover scenario.
Procedure
Step 1 Run system-view
The system view is displayed.
The device is configured to keep IPSec tunnel indexes unchanged based on the peer IP
address during IPSec tunnel re-establishment.
By default, the device is not configured to keep IPSec tunnel indexes unchanged based on the
peer IP address during IPSec tunnel re-establishment.
----End
Context
To improve network reliability, the enterprise gateway often connects to the Internet Service
Provider (ISP) through two egress links, which work in backup or load balancing mode.
When two outbound interfaces are configured with IPSec policies with the same parameter
settings, services need to be smoothly switched between the two links corresponding to the
two outbound interfaces. The two outbound interfaces negotiate with their peers to establish
IPSec SAs respectively. When an active/standby switchover occurs, the two peers need to
perform IKE negotiate again to generate IPSec SAs. The IKE re-negotiation causes IPSec
service interruption in a short time.
You can configure a multi-link shared IPSec policy group and use a loopback interface on the
local device to establish an IPSec tunnel with the remote device. When an active/standby
switchover occurs, IPSec services are not interrupted. The two IPSec-enabled physical
interfaces share the same IPSec SA. When services are switched between links corresponding
to the physical interfaces, the IPSec SA is not deleted as long as the loopback interface status
remains unchanged. In addition, IKE re-negotiation is not required because the same IPSec
SA is used to protect IPSec services.
As shown in Figure 4-26, packets of branch gateway RouterA reach headquarters gateway
RouterB through two egress links. If an egress link is faulty, IPSec communication between
RouterA and RouterB is not affected. The multi-link shared mode improves network
reliability.
Interface 1
RouterA RouterB
Branch Headquarters
gateway subnet
Interface 2
IPSec Tunnel
SubnetA SubnetB
One loopback interface maps to only one multi-link shared IPSec policy group.
Procedure
Step 1 Run system-view
----End
Context
On a live network, to improve network reliability, a branch gateway connects to the
headquarters using multiple links. The branch gateway needs to determine on which link an
IPSec tunnel is established. You can associate IPSec with NQA so that the branch gateway
controls IPSec tunnel setup or teardown according to the , which ensures that only one link is
available at any time. The association implements redundancy control of the IPSec tunnel.
Prerequisites
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec policy policy-name seq-number isakmp
The view of the ISAKMP IPSec policy is displayed.
Step 3 Run connect track { nqa admin-name test-name | nqa-group nqa-group-name } { up |
down }
The device is configured to control IPSec tunnel setup according to status.
By default, the device is configured to not control IPSec tunnel setup according to status.
Step 4 Run disconnect track { nqa admin-name test-name | nqa-group nqa-group-name } { up |
down }
The device is configured to control IPSec tunnel teardown according to status.
By default, the device is configured to not control IPSec tunnel teardown according to status.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec policy policy-name seq-number isakmp
The view of the ISAKMP IPSec policy is displayed.
Step 3 Run connect track vrrp vrid interface interface-type interface-number { master | backup }
The device is configured to control IPSec tunnel setup according to the VRRP status.
By default, the device is not configured to control IPSec tunnel setup according to the VRRP
status.
The connect track and disconnect track commands must be configured simultaneously to
implement gateway redundancy.
Step 4 Run disconnect track vrrp vrid interface interface-type interface-number { master |
backup }
The device is configured to control IPSec tunnel teardown according to the VRRP status.
By default, the device is not configured to control IPSec tunnel teardown according to the
VRRP status.
----End
Context
In scenarios where branches connect to the headquarters, if a branch has a too large protection
data flow range configured, traffic of other branches may be incorrectly diverted to the
branch. In this case, you can configure IPSec mask filtering to check and restrict access of
flow information negotiated by the IPSec tunnel. After this function is configured, the device
checks the source and destination IP address masks of the peer device. If the mask values are
greater than or equal to the configured values, subsequent negotiation continues. Otherwise,
the IPSec SA negotiation fails.
The device checks and restricts the access of flow information only when it adopts the IPSec policy
template.
Procedure
Step 1 Run system-view
Step 2 Run ipsec netmask { source source-mask | [ source source-mask ] destination destination-
mask }
----End
Context
To use IPSec to protect data flows on an interface, apply an IPSec policy group to the
interface. After an IPSec policy group is unbound from an interface, the interface does not
provide IPSec protection.
An IPSec policy group is a set of IPSec policies with the same name but different sequence
numbers. An IPSec policy group can contain multiple IPSec policies established manually or
in IKE negotiation mode but only one IPSec policy template, as shown in Figure 4-27. One
IPSec policy corresponds to one advanced ACL. In an IPSec policy group, an IPSec policy
with a smaller sequence number has a higher priority.
…
ACL 3005
20 isakmp rule 5
rule 10
21 template
policy-name
ACL 3007
22 manual rule 5
rule 10
…
ACL 3010
30 manual
rule 5
…
After an IPSec policy group is applied to an interface, all IPSec policies in the group are
applied to the interface and protect different data flows.
When sending a packet, an interface matches the packet with IPSec policies in an IPSec
policy group in ascending order of sequence number. If the packet matches the ACL
referenced by an IPSec policy, the packet is processed based on the IPSec policy. If no
matching ACL is found after all IPSec policies are checked, the interface sends the packet
directly without IPSec protection.
When applying an IPSec policy group to an interface, note the following points:
l The interface where IPSec policies are applied must be the interface where an IPSec
tunnel is established, and the interface must be the outbound interface in the private route
to the remote end. If an IPSec policy is applied to another interface but not the target
interface, VPN service forwarding may fail.
l Only one IPSec policy group can be applied to an interface, and an IPSec policy group
can be applied to only one interface.
l After an IPSec policy group is applied to an interface, referenced ACLs and IKE peers in
IPSec policies of the IPSec policy group cannot be modified.
l When applying an IPSec policy to a tunnel interface and running the source command to specify an IP
address for the interface, you must run the tunnel local command to configure a tunnel local address.
Otherwise, IKE negotiation will fail.
l When multiple branches connect to the headquarters, multiple tunnel interfaces in the headquarters
borrow the same physical interface IP address. In this scenario, the headquarters can identify the tunnel
interface connected to a branch through the peer IP address or peer ID of the IKE peer (Only IKEv1 in
aggressive mode supports the peer ID mode.).
l When multiple branches are connected to the headquarters, if some tunnel interfaces at the headquarters
borrow an IP address from a physical interface, borrow an IP address from a physical interface as their
source address, or borrow a virtual IP address from a physical interface as their tunnel local address, the
mappings between IKE peers and tunnel interfaces may be incorrect. As a result, an IPSec tunnel fails to
be established.
Procedure
Step 1 Run system-view
After an IPSec policy established in IKE negotiation mode is applied to an interface, an IPSec
tunnel can be triggered in auto or traffic mode using the sa trigger-mode { auto | traffic-
based } command.
After an SA is created successfully, data flows are transmitted securely over the IPSec tunnel.
When the number of IPSec tunnels is larger than 50% of the maximum limit, high CPU usage
alarms may be generated in a short period of time after the undo ipsec policy command is
run. After all the SAs are cleared, the CPU usage restores to the normal range.
----End
Precautions
If you modify the tunnel-protocol parameter of a tunnel interface, the IPSec policy group
applied to the tunnel interface will be deleted. After the modification, apply the IPSec policy
group to the tunnel interface as required.
In an IPSec policy group, if multiple policies are bound to different IKE peers, the remote
addresses specified in the IKE peers cannot be the same. Otherwise, IKE negotiation of some
IPSec policies fails.
Procedure
l Run the display ipsec proposal [ brief | name proposal-name ] command to check
IPSec proposal information.
l Run the display ipsec policy [ brief | name policy-name [seq-number ] ] command to
check IPSec policy information.
l Run the display ike identity [ name identity-name ] command to check identity filter set
information.
l Run the display ipsec policy-template [ brief | name policy-template-name [ seq-
number ] ] command to check IPSec policy template information.
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | remote
ipv4-address ] command to check IPSec SA information.
l Run the display ipsec global config command to check global IPSec configuration.
l If an IPSec tunnel is established in IKE negotiation mode, check the IKE configuration.
See 4.10.14 Verifying the IKE Configuration.
----End
Pre-configuration Tasks
Before using an IPSec tunnel interface to establish an IPSec tunnel, complete the following
tasks:
l Configure a reachable route between source and destination interfaces.
l Determine data flows to be protected by IPSec and importing data flows to the IPSec
tunnel interface.
l Determine parameters in an IPSec proposal.
Configuration Procedure
After an IPSec policy is referenced by an IPSec profile, apply the IPSec profile to an IPSec
tunnel interface and establish an IPSec tunnel through the virtual tunnel interface.
Context
An IPSec proposal, as part of an IPSec policy or an IPSec profile, defines security parameters
for IPSec SA negotiation, including the security protocol, encryption and authentication
algorithms, and encapsulation mode. Both ends of an IPSec tunnel must be configured with
the same parameters.
The IPSec proposal referenced by an IPSec tunnel interface supports only the tunnel mode, that is, you
must specify tunnel in the encapsulation-mode command.
Procedure
Step 1 Run system-view
When IKEv2 is used, the encapsulation modes in all the IPSec proposals configured on the
IKE initiator must be the same; otherwise, IKE negotiation fails.
When GRE over IPSec is configured, a public IP header is added to packets during GRE encapsulation.
Compared with the transport mode, the tunnel mode adds another public IP header. In tunnel mode, the
packet length is longer and packets are more likely to be fragmented. The transport mode is therefore
recommended.
By default, the SHA-2 algorithm is not compatible with earlier software versions.
When IPSec uses the SHA-2 algorithm, if the devices on two ends of an IPSec tunnel are
from different vendors or run different software versions, they may use different encryption
and decryption methods. In this situation, traffic between devices is interrupted.
----End
Context
An IPSec profile defines how to protect data flows, including IPSec proposals, IKE
negotiation parameters for SA setup, SA lifetime, and PFS status. An IPSec profile is similar
to an IPSec Policy. Compared with the IPSec policy, the IPSec profile is identified by its
name and can be configured only in IKE negotiation mode.
In an IPSec profile, you do not need to use ACL rules to define data flows. Instead, all the
data flows routed to the IPSec tunnel interface are protected. After an IPSec profile is applied
to an IPSec tunnel interface, only one IPSec tunnel is created. The IPSec tunnel protects all
the data flows routed to the IPSec tunnel interface, simplifying IPSec policy management.
To ensure successful IKE negotiation, parameters in the IPSec profile on the local and remote
ends must match.
Procedure
Step 1 Run system-view
l You do not need to specify the tunnel local (local address) for the IKE peer referenced in an IPSec
profile, because the local address is the source address of the GRE, mGRE or IPSec virtual tunnel
interface. For the IKE peer referenced in an IPSec profile, tunnel local does not take effect.
l When an IPSec profile is used, the destination address of the IPSec tunnel interface configured using
the destination command is preferentially used as the remote address for IKE negotiation. When the
remote-address and destination commands are configured at the same time, ensure that the
configured IP addresses are the same; otherwise, IKE negotiation will fail. To implement IKE peer
redundancy, do not configure the destination command on the IPSec tunnel interface. Instead,
configure the remote-address command on the IKE peer referenced by the IPSec profile.
l For the detailed configuration of an IKE peer, see 4.10.2 Configuring an IKE Peer.
An outbound interface on the IPSec tunnel for IKE negotiation packets is configured.
By default, no outbound interface is configured on the IPSec tunnel for IKE negotiation
packets.
When there are multiple outbound interfaces, the device determines the outbound interface for
IKE negotiation packets based on routes. If the outbound interface for IKE negotiation
packets differs from that for IPSec service packets, IKE negotiation may fail. In this case,
perform this step to specify a correct outbound interface.
For details on how to configure an identity filter set, see 4.10.5 (Optional) Configuring an Identity
Filter Set.
Step 7 (Optional) Run pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group19 | dh-
group20 | dh-group21 }
The device is configured to use perfect forward secrecy (PFS) when the local end initiates
negotiation.
By default, PFS is not used when the local end initiates negotiation.
When the local end initiates negotiation, there is an additional Diffie-Hellman (DH) exchange
in IKEv1 phase 2 or IKEv2 CREATE_CHILD_SA exchange. The additional DH exchange
ensures security of the IPSec SA key and improves communication security.
If PFS is specified on the local end, you also need to specify PFS on the remote end. The DH
group specified on the two ends must be the same; otherwise, negotiation fails. When an
IPSec policy in ISAKMP mode is used on the local end while an IPSec policy configured
using an IPSec policy template is used on the remote end, no DH group needs to be
configured on the remote end. The DH group on the responder is used for negotiation.
----End
Context
l The configured IPSec SA lifetime is only valid for the new IPSec SAs established in IKE
negotiation mode.
For a dynamic SA, configure the SA hard lifetime so that the SA can be updated in real time,
reducing the crash risk and improving security.
Time-based soft lifetime (soft timeout The value is 70% of the actual hard
period) lifetime (hard timeout period).
Traffic-based soft lifetime (soft timeout l For IKEv1, the value is 70% of the
traffic) actual hard lifetime (hard timeout
traffic).
l For IKEv2, the value is 65% to 75%
of the actual hard lifetime (hard
timeout traffic) plus or minus a
random value.
Before an IPSec SA becomes invalid, IKE negotiates a new IPSec SA for the remote end. The
remote end uses the new IPSec SA to protect IPSec communication immediately after the new
IPSec SA is negotiated. If service traffic is transmitted, the original IPSec SA is deleted
immediately. If no service traffic is transmitted, the original IPSec SA will be deleted after
10s or the hard lifetime expires.
If the time-based lifetime and traffic-based lifetime are both set for an IPSec SA, the IPSec
SA becomes invalid when either lifetime expires.
You can set the global SA hard lifetime or set the SA hard lifetime in an IPSec profile. If the
SA hard lifetime is not set in an IPSec profile, the global hard lifetime is used. If both the
global SA hard lifetime and the SA hard lifetime in an IPSec profile are set, the SA hard
lifetime in the IPSec profile takes effect.
Procedure
l Set the global IPSec SA hard lifetime.
a. Run system-view
By default, the global time-based SA hard lifetime is 3600 seconds and the global
traffic-based SA hard lifetime is 1843200 Kbytes.
l Setting the IPSec SA hard lifetime in an IPSec profile.
a. Run system-view
By default, the IPSec SA hard lifetime is not set in an IPSec profile. The system
uses the global IPSec SA hard lifetime.
----End
Context
Replayed packets are packets that have been processed. IPSec uses the sliding window (anti-
replay window) mechanism to check replayed packets. Each AH or ESP packet has a 32-bit
sequence number. In an SA, sequence numbers of packets increase. If the sequence number of
a received authenticated packet is the same as that of a decapsulated packet or if the sequence
number is out of the sliding window, the device considers the packet as a replayed packet.
Decapsulating replayed packets consumes many resources and makes system performance
deteriorate, resulting in a Denial Of Service (DoS) attack. After the anti-replay function is
enabled, the system discards replayed packets and does not encapsulate them, saving system
resources.
In some situations, for example, when network congestion occurs or QoS is performed for
packets, the sequence numbers of some service data packets may be different from those in
common data packets. The device that has IPSec anti-replay enabled considers the packets as
replayed packets and discards them. You can disable global IPSec anti-replay to prevent
packets from being discarded incorrectly or adjust the IPSec anti-replay window size to meet
service requirements.
The anti-replay function can be configured globally or in an IPSec profile.
l Configuring the anti-replay function globally
The global anti-replay function is valid for all created IPSec profiles. When the same
anti-replay window parameters need to be set for many IPSec profiles, you do not need
to run commands one by one. You just need to set global parameters. The configuration
efficiency is therefore improved.
l Configuring the anti-replay function in an IPSec profile
The anti-replay function can be configured separately for an IPSec profile. In this case,
the anti-replay function for the IPSec profile is not affected by the global configuration.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Enable the anti-replay function. Run the following commands as required.
l Enable the anti-replay function globally.
a. Run ipsec anti-replay enable
The anti-replay function is enabled globally.
b. Run ipsec anti-replay window window-size
The global IPSec anti-replay window size is configured.
By default, the IPSec anti-replay window size is 1024 bits.
l Enable the anti-replay function in an IPSec policy.
----End
Procedure
1. Run system-view
The system view is displayed.
2. Run ipsec fragmentation before-encryption
The fragmentation mode of packets is set to fragmentation before encryption for all
IPSec tunnels.
By default, the packet fragmentation mode for all IPSec tunnels is fragmentation after
encryption.
The DF flag in IPSec packets determines whether IPSec packets can be fragmented. If
DF flag settings disable fragmentation when the fragmentation mode is used, run the
ipsec df-bit { clear | set | copy } command in the system view to enable fragmentation
on IPSec packets.
For the established IPSec tunnels, you need to restart them after running this command.
Otherwise, the command function does not take effect.
decapsulated IPSec packet of the inbound SA may be not defined in an ACL. For example,
the IP header of attack packets may be out of the range defined in the ACL. After post-IPSec
check is configured, the device re-checks whether the IP header of the decapsulated IPSec
packet is in the range defined in an ACL. If the IP header matches the permit rule, the device
performs subsequent operations on the packet. Otherwise, the device discards the IPSec
packet. The network security is therefore improved.
The generated ACL varies depending on the encapsulation mode of the virtual tunnel
interface:
l When the encapsulation mode is set to IPSec, the source and destination addresses in the
ACL are both any, indicating that all data flows destined for the tunnel interface are
protected.
l When the encapsulation mode is set to GRE, the source and destination addresses in the
ACL are the source and destination addresses of the tunnel interface respectively.
Procedure
Step 1 Run system-view
----End
Context
In network planning, QoS needs to be configured to provide differentiated services for
different traffic flows to optimize network service capabilities. QoS groups the packets
sharing common features into one class and provides the same QoS level for traffic of the
same type. In this manner, QoS provides differentiated services for different types of packets.
QoS for IPSec packets implements refined QoS management on IPSec packets, choose either
of the following configurations as required:
l After packets are encapsulated using IPSec, the packets do not contain QoS related
parameters, such as header of the original packet and protocol number. Pre-extraction of
original IP packets needs to be configured if QoS needs to group encapsulated packets
based on the 5-tuple information such as original packet header and protocol number.
l When a device implements IPSec encapsulation and decapsulation on packets, it will
result in transmission delay and require higher bandwidth. Therefore, the device needs to
provide differentiated services for IPSec packets to reduce the delay, lower the packet
loss ratio, and maximize bandwidth for IPSec traffic. You can group IPSec packets into
one QoS group to allow QoS to implement differentiated services for IPSec packets.
For details on QoS, see Huawei AR Series V300R003 Configuration Guide - QoS Configuring
MQC.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Enter the view where QoS for IPSec packets is configured.
l IPSec profile view
Run ipsec profile profile-name
An IPSec profile is created and the IPSec profile view is displayed.
l The tunnel interface view
Run interface tunnel interface-number
The tunnel interface view is displayed.
Choose either of the preceding methods.
Step 3 Enable the QoS function for IPSec packets.
l Run qos pre-classify
Pre-extraction of original IP packets is enabled.
By default, pre-extraction of original IP packets is disabled.
l Run qos group qos-group-value
The QoS group to which IPSec packets belong is configured.
By default, no QoS group is configured.
----End
Follow-up Procedure
l After pre-extraction of original IP packets is enabled, run the if-match acl { acl-number |
acl-name } command in the traffic classifier view to configure a matching rule based on
the ACL.
l After QoS for IPSec packets is enabled, run the if-match qos-group qos-group-value
command in the traffic classifier view to configure a matching rule based on the QoS
group.
Context
In an MIB table, an IPSec tunnel index is the unique identifier of an IPSec tunnel. During
IPSec tunnel establishment, the device generates an IPSec tunnel index mapping table to
record IPSec tunnel index to IPSec tunnel mapping. In this mapping table, the device searches
for the corresponding IPSec tunnel based on an IPSec tunnel index. However, when an IPSec
tunnel is re-established, its IPSec tunnel index changes by default. As a result, the IPSec
tunnel cannot be found based on its previous IPSec tunnel index. In this case, configure the
device to keep IPSec tunnel indexes unchanged based on the peer IP address during IPSec
tunnel re-establishment. This configuration ensures that an IPSec tunnel can be found using
its fixed IPSec tunnel index.
l This function works only when devices on both ends use fixed IPv4 addresses and establish only one
IPSec tunnel.
l During IPSec tunnel re-establishment, this function allows the device to keep only the first 1024
IPSec tunnel indexes unchanged based on the sequence in which IPSec tunnels are re-established.
l An IPSec tunnel index mapping table cannot be backed up, so this function does not work in an
active/standby switchover scenario.
Procedure
Step 1 Run system-view
The system view is displayed.
The device is configured to keep IPSec tunnel indexes unchanged based on the peer IP
address during IPSec tunnel re-establishment.
By default, the device is not configured to keep IPSec tunnel indexes unchanged based on the
peer IP address during IPSec tunnel re-establishment.
----End
Context
As shown in Figure 4-29, a headquarters sets up an IPSec tunnel with its branch using a
tunnel interface. If requesting, sending or accepting of subnet route information is not
configured, data flows to be protected through IPSec need to be imported to the tunnel
interface based on the static or dynamic routes.
l When the remote network topology changes, you must modify routes on the local device
to ensure IPSec protection for nonstop data transmission.
l When a new branch is added to the network and wants to establish an IPSec tunnel with
the headquarters, you must configure routes to the branch on the headquarters gateway.
Figure 4-29 Requesting, sending or accepting of subnet route information not configured
TunnelA TunnelB
PC a1 IPSec Tunnel PC b1
IPA IPB
PC a2 Branch Headquarters PC b2
gateway gateway
…
…
ip route-static IPB tunnelA
ip route-static IPA tunnelB
PC aM PC bN
As shown in Figure 4-30, you only need to configure the subnet address to be protected
through IPSec on the local device. The local device then sends subnet route information to the
remote device that generates routes based on the information.
In the IPSec configuration,
l When the remote network topology changes, you do not need to modify routes on the
local device.
l When a new branch is added to the network and wants to establish an IPSec tunnel with
the headquarters, you do not need to add routes to the branch on the headquarters
gateway.
Branch Headquarters
TunnelA Tunnel-TemplateB
192.168.1.1/24 192.168.1.2/24
PC a1 IPSec Tunnel PC b1
IPA IPB
PC a2 Branch Headquarters PC b2
gateway gateway
…
…
· Requesting subnet route information
PC aM Request subnet route PC bN
① information Receive the request
ACL 3000
Generate routes rule permit ip source IPB
② interface Tunnel-TemplateB
Destination IP Next Hop
IPB Tunnel-TemplateB Send subnet route
information
· Sending and accepting subnet route information
ACL 3000
rule permit ip source IPA
① interface TunnelA Accept subnet route
Send subnet route information
information ACL 3000
rule permit ip source IPB
Accept subnet route interface Tunnel-TemplateB
②
information Send subnet route
information
③ Generate routes
Destination IP Next Hop Destination IP Next Hop
IPB Tunnel-TemplateB IPA TunnelA
Procedure
l Configuring requesting of subnet route information
After a local device is enabled to request subnet route information, the remote device
will send subnet route information directly without enabling send subnet route
information.
Requesting of subnet route information takes effect on the IKE negotiation initiator only.
The local device requests subnet route information, generates a route based on the
received subnet route information.
a. Run system-view
The system view is displayed.
b. Run ike peer peer-name
An IKE peer is created and the IKE peer view is displayed.
c. Run undo version 1
The IKE protocol version used by IKE peers is configured.
By default, IKE peers support IKEv1 and IKEv2.
If IKEv1 and IKEv2 are enabled, IKEv2 is used in the negotiation initiation, and
IKEv1 and IKEv2 are used in negotiation response.
d. (Optional) Run config-exchange request
The device is enabled to request subnet route information from a peer.
By default, the device does not request subnet route information from a peer.
e. Run route accept [ preference preference-number ] [ tag tag-value ]
The device is enabled to generate a route based on the received subnet route
information and define the priority and tag value for the route.
By default, the device does not generate routes based on the received subnet route
information.
The remote device configures subnet route information to be sent, sends subnet
route information directly after receiving the request.
a. Run system-view
The system view is displayed.
b. Run aaa
The AAA view is displayed.
c. Run service-scheme service-scheme-name
A service scheme is created and the service scheme view is displayed.
d. Run route set acl acl-number
Local subnet information to be sent to the peer is configured.
By default, no local subnet information to be sent to the peer is configured.
acl-number specifies an advanced ACL that has been created.
e. Run route set interface
An IP address which is to be sent to the peer is configured for the interface.
By default, no IP address which is to be sent to the peer is configured for the
interface.
l Configuring sending and accepting of subnet route information
After a local device is enabled to send subnet route information and a remote device is
enabled to accept subnet route information, sending of subnet route information is
enabled in one direction. To enable bidirectional sending of subnet route information, the
headquarters and branch devices must be enabled to send and accept subnet route
information at the same time.
The local device sends subnet route information.
If IKEv1 and IKEv2 are enabled, IKEv2 is used in the negotiation initiation, and
IKEv1 and IKEv2 are used in negotiation response.
d. Run config-exchange set accept
The device is enabled to accept subnet route information from a peer.
By default, the device does not accept subnet route information from a peer.
e. Run route accept [ preference preference-number ] [ tag tag-value ]
The device is enabled to generate a route based on the received subnet route
information and define the priority and tag value for the route.
By default, the device does not generate routes based on the received subnet route
information.
----End
If you apply an IPSec profile to the tunnel template interface, the IKE peer referenced in the IPSec profile can
only be IKEv2.
In V300R003C10 and later versions, when multiple branches connect to the headquarters, multiple tunnel
interfaces in the headquarters borrow the same physical interface IP address. In this scenario, the headquarters
can identify the tunnel interface connected to a branch through the peer IP address or peer ID of the IKE peer
(only IKEv1 in aggressive mode supports the peer ID mode). If you run the destination command on a tunnel
interface of the headquarters to specify the IP address of a branch interface, the headquarters preferentially
uses this IP address to identify the access of the branch.
When multiple branches are connected to the headquarters, if some tunnel interfaces at the headquarters
borrow an IP address from a physical interface and borrow an IP address from a physical interface as their
source address, the mappings between IKE peers and tunnel interfaces may be incorrect. As a result, an IPSec
tunnel fails to be established.
Procedure
l Configuring a Tunnel Interface
a. Run system-view
The system view is displayed.
An IPSec profile can be bound to an IPSec tunnel interface only when the tunnel
encapsulation mode is set to IPSec, GRE, or Multipoint GRE (mGRE):
l IPSec: An IPSec tunnel established on a tunnel interface ensures security of unicast
data transmitted on the Internet.
l GRE: The IPSec tunnel interface provides GRE over IPSec and transmits unicast and
multicast data. The IPSec tunnel interface first adds a GRE header to packets, and then
adds an IPSec header to the packets so that packets are reliably transmitted.
l mGRE (specified by gre and p2mp): The IPSec tunnel interface provides Dynamic
Smart Virtual Private Network (DSVPN) functions. See 3 DSVPN Configuration.
d. Run the following commands as required.
n Run ip address ip-address { mask | mask-length } [ sub ]
A private IPv4 address is configured for the tunnel interface.
n On the IPSec tunnel interface, run ip address ike-negotiated
An IPv4 address is requested for the tunnel interface through IKEv2
negotiation.
e. Run source { [ vpn-instance vpn-instance-name ] source-ip-address | interface-
type interface-number [ standby ] }
The source address or source interface is configured.
You can specify the vpn-instance vpn-instance-name parameter only when the
encapsulation mode of a tunnel interface is set to IPSec or mGER.
This command takes effect only when the encapsulation mode of the tunnel interface is IPSec or
GRE and the destination command has been configured on the tunnel interface.
If the source address of the tunnel template interface is dynamically obtained, you are
advised to specify the source interface when running the source command. This prevents the
impact of address change on the IPSec configuration.
f. (Optional) Run tunnel pathmtu enable
The device is enabled to learn the MTU of packets allowed on an IPSec tunnel.
By default, the device cannot learn the MTU of packets allowed on an IPSec tunnel.
g. Run ipsec profile profile-name
The IPSec profile is applied to a tunnel template interface so that data flows on the
interface are protected by IPSec.
By default, no IPSec profile is applied to the tunnel template interface.
You can apply only one IPSec profile to a tunnel template interface. An IPSec
profile can be applied to only one tunnel template interface.
When the number of IPSec tunnels is larger than 50% of the maximum limit, high
CPU usage alarms may be generated in a short period of time after the undo ipsec
profile command is run. After all the SAs are cleared, the CPU usage restores to the
normal range.
----End
Configuration Guidelines
l The IPSec profile configuration applied to a tunnel interface is deleted if you modify the
value of the parameter source or destination on the tunnel interface. Apply the IPSec
profile to the tunnel interface again.
l If you modify the tunnel-protocol parameter of a tunnel interface, the IPSec policy
group applied to the tunnel interface will be deleted. After the modification, apply IPSec
policy group to the tunnel interface as required.
l The IPSec profile configuration applied to a tunnel template interface is deleted if you
modify the value of the parameter source on the tunnel template interface. Apply the
IPSec profile to the tunnel template interface again.
l To disable IPSec negotiation, you must run the shutdown command to shut down the
corresponding physical interface but not the tunnel interface.
Prerequisites
The configurations of the IPSec tunnel that is established using a virtual tunnel interface are
complete.
Procedure
l Run the display ipsec proposal [ brief | name proposal-name ] command to check
IPSec proposal information.
l Run the display ipsec profile [ brief | name profile-name ] command to check IPSec
profile information.
l Run the display ike identity [ name identity-name ] command to check IKE identity
information.
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | remote
ipv4-address ] command to check IPSec SA information.
l Run the display ipsec global config command to check global IPSec configuration.
l Check IKE information. See 4.10.14 Verifying the IKE Configuration.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.
Step 3 Run transform { ah | esp | ah-esp }
A security protocol is configured.
By default, an IPSec proposal uses ESP.
Step 4 An authentication or encryption algorithm is configured.
l If AH is used, you can only configure the AH-specific authentication algorithm because
AH only authenticates packets.
Run ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
An AH-specific authentication algorithm is configured.
By default, AH uses the SHA2-256 authentication algorithm.
When IKEv2 is used, the encapsulation modes in all the IPSec proposals configured on the
IKE initiator must be the same; otherwise, IKE negotiation fails.
By default, the SHA-2 algorithm is not compatible with earlier software versions.
When IPSec uses the SHA-2 algorithm, if the devices on two ends of an IPSec tunnel are
from different vendors or run different software versions, they may use different encryption
and decryption methods. In this situation, traffic between devices is interrupted.
----End
Context
An IPSec point-to-multipoint (P2MP) security policy is a prerequisite for creating SAs and
determines the methods used to protect specified data flows.
Procedure
Step 1 Run system-view
An IPSec P2MP security policy is created and the IPSec P2MP security policy view is
displayed.
An IPSec P2MP security policy can reference only one IPSec proposal. A new IPSec proposal
can be referenced only after the precious referenced one has been deleted.
By default, the lifetime of an IPSec SA in an IPSec P2MP security policy is 1440 minutes.
By default, the anti-replay window size of a single IPSec tunnel is not configured on a device
and the system uses the current global IPSec anti-replay window size.
----End
Context
In a tunnel optimization scenario, you need to enable the IPSec P2MP security policy function
on a tunnel interface before performing IPSec encryption for BGP packets.
Procedure
Step 1 Run system-view
By default, the IPSec P2MP security policy function is disabled on a tunnel interface.
----End
Prerequisites
All configurations of the IPSec tunnel have been completed.
Procedure
l Run the display ipsec proposal [ brief | name proposal-name ] or display ipsec
proposal [ brief | name proposal-name ] ctrl-plane command to check information
about the IPSec proposal.
l Run the display ipsec p2mp-policy [ name policy-name ] command to check
configuration information about the IPSec P2MP security policy.
l Run the display ipsec local p2mp-sa command to check configuration information
about the local IPSec P2MP SA.
l Run the display ipsec peer p2mp-sa command to check configuration information about
the remote IPSec P2MP SA.
----End
Pre-configuration Tasks
Before configuring IKE, complete the following tasks:
l Determine parameters in an IKE proposal.
l Determine the PKI domain that the IKE peer belongs to if RSA signature authentication
is used.
For details on how to configure PKI, see Huawei AR Series V300R003 Configuration Guide - Security.
Configuration Process
Configure matching parameters at the two ends to complete IKE negotiation.
If no IKE proposal is created, the system has a default IKE proposal with the lowest priority. If you specify
only the sequence number when creating an IKE proposal, the parameters of the IKE proposal are also the
default parameters.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ike proposal proposal-number
An IKE proposal is created and the IKE proposal view is displayed.
Step 3 Run authentication-method { pre-share | rsa-signature | digital-envelope }
An authentication method is configured.
By default, an IKE proposal uses pre-shared key authentication.
The authentication methods in the IKE proposals used by the IKE peer must be the same.
Otherwise, IKE negotiation fails.
Digital envelope authentication is released by the State Encryption Administration of China. It can be used
only for IKEv1 negotiation in main mode. It cannot be used for IKEv1 negotiation in aggressive mode or for
IKEv2 negotiation.
When IKE peers use IKEv2, you need to run the re-authentication interval command to make the
configured authentication method take effect.
The MD5 and SHA1 algorithms are susceptible to attacks and their use is not recommended.
In IKEv1 certificate negotiation, if the authentication algorithm sha2-512 is configured, the RSA key length
must be greater than 1024.
The following encryption algorithms are listed in descending order of security level:
AES-256, AES-192, AES-128, 3DES, and DES.
The DES and 3DES algorithms are susceptible to attacks and their use is not recommended.
The security level order of the DH groups is: group21 > group20 > group19 > group14 >
group5 > group2 > group1.
The DH groups, group1, group2, and group5 are susceptible to attacks and their use is not
recommended.
The HMAC-MD5 and HMAC-SHA1 algorithms are susceptible to attacks and their use is not
recommended.
----End
Relevant Content
Video: Configuring an IKE Proposal
Context
When an IPSec tunnel is established in IKE negotiation mode, you need to reference an IKE
peer and configure attributes between IKE peers during IKE negotiation. When configuring
attributes between IKE peers, note the following points:
l The IKE peers must use the same IKE version.
l The IKE peers that use IKEv1 must use the same negotiation mode.
l Identity authentication parameters of the IKE peers must match.
IKE has two versions: IKEv1 and IKEv2. The differences between IKEv1 and IKEv2 are as
follows:
l IKEv1 requires the phase 1 negotiation mode, whereas IKEv2 does not.
l IKEv1 does not support the Online Certificate Status Protocol (OCSP) for an IKE peer,
whereas IKEv2 supports.
l IKEv2 supports the re-authentication interval to enhance security, whereas IKEv1 does
not support the re-authentication interval.
Pre-configuration Tasks
Before configuring an IKE peer, complete the following tasks:
l Import the local certificate and CA root certificate on the authenticated end and import
the CA root certificate on the authenticating end if RSA signature authentication is used.
l Generate the RSA key pair on the authenticated end if RSA key authentication is used.
In IKEv1 certificate negotiation, if the authentication algorithm sha2-512 is configured,
the RSA key length must be greater than 1024.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ike peer peer-name
An IKE peer is created and the IKE peer view is displayed.
By default, no IKE peer is created in the system.
Step 3 Run version { 1 | 2 }
The IKE protocol version used by IKE peers is configured.
By default, IKE peers support IKEv1 and IKEv2.
Step 4 (Optional) Run exchange-mode { main | aggressive | auto }
IKEv1 phase 1 negotiation mode is set.
By default, the main mode is used in IKEv1 phase 1.
l Aggressive mode: provides faster negotiation speed, but cannot protect identities.
l Auto-sensing mode: The main mode is used if the device serves as the initiator. If the
device serves as the responder, both the main mode and aggressive mode can be used.
Step 5 (Optional) Run local-address ipv4-address
The local IP address in IKE negotiation is configured.
By default, the system selects an outbound interface according to a route and uses the IP
address of the outbound interface as the local IP address.
Generally, you do not need to configure the local IP address.
l If the IP address of an interface bound to an IPSec policy is variable or unknown, run the
local-address ipv4-address command to specify the IP address of another interface such
as a loopback interface as the local IP address.
l If an interface bound to an IPSec policy is configured with one primary IP address and
multiple secondary IP addresses, run the local-address ipv4-address command to specify
one IP address as the local IP address.
l If the local and remote ends have equal-cost routes, run the local-address ipv4-address
command to specify the local IP address so that IPSec packets can be sent out from the
specified interface.
Step 6 (Optional) Run remote-address { [ vpn-instance vpn-instance-name ] { ipv4-address | host-
name host-name } | authentication-address start-ipv4-address [ end-ipv4-address ] }
The remote IP address or domain name used in IKE negotiation is configured.
By default, an IKE peer has no domain name, remote IP address, or remote IP address range
configured.
If a VPN instance has been configured on the interface applied with an IPSec policy, the vpn-
instance-name parameter needs to be configured. After this parameter is configured, the
device searches for a route to the remote IP address in the specified VPN during IPSec tunnel
negotiation. If more than one remote IP address or domain name is configured, the specified
vpn-instance-name must be the same.
If the remote device has a variable IP address and a fixed domain name, you must specify
host-name to configure the remote domain name. In this situation, the remote end must have
Dynamic Domain Name System (DDNS) configured to bind domain names to dynamic IP
addresses, and the local end must have DNS configured for domain name resolution.
You can specify authentication-address to configure the pre-NAT IP address as the remote
authentication address when the following conditions are met:
l Two devices use IKEv2.
l The remote device uses the internal IP address.
l Packets traverse the NAT device.
l The IP address is used for authentication.
The post-NAT IP address needs to be used as the remote address in this situation.
Step 7 Run ike-proposal proposal-number
An IKE proposal is referenced.
The IKE proposal must have been created.
By default, an IKE peer does not reference an IKE proposal
1) Run quit
Return to the system view.
2) Run ike user-table user-table-id
An IKE user table is created and its view is displayed, or the view of an
existing IKE user table is displayed directly.
3) Run user user-name
An IKE user is created and its view is displayed, or the view of an
existing IKE user is displayed directly.
4) Run pre-shared-key key
The pre-shared key used by IKE peers is configured when IKE peers use
pre-shared key authentication during IKE negotiation.
By default, the pre-shared key used by IKE peers is not configured when
IKE peers use pre-shared key authentication during IKE negotiation.
5) Run id-type { any any-id | fqdn remote-fqdn | ip ipv4-address | user-
fqdn remote-user-fqdn }
The IKE user ID type and ID are configured.
By default, the IKE user ID type and ID are not configured.
The value of id-type is the remote ID.
When IKEv1 in main mode is used, the value of id-type must be set to ip.
In NAT traversal scenarios, ipv4-address should be set to the IP address
that is translated using NAT.
Table 4-9 Relationship between the local ID type, local ID, remote ID type, and
remote ID
Local ID Type Local ID Remote ID Remote ID
Type
By default, the IP address of the local end is used as the local ID.
ii. (Optional) Run local-id id
The local ID used in IKE negotiation is set.
You need to configure the local ID when the ID type of an IKE peer is FQDN
or User-FQDN.
○ When the local ID type is IP, you do not need to perform this step. In this case, the
device uses the IP address of the interface for establishing an IPSec tunnel as the local
ID by default. If the interface has multiple IP addresses, for example, primary and
secondary IP addresses are configured, the device uses the IP address configured by the
tunnel local command as the local ID.
○ If the ID type is FQDN or User-FQDN, you can also run the ike local-name local-name
command in the system view to configure the local ID during IKE negotiation. Then all
IKE peers of the device use this local ID for identity authentication.
○ The local ID configured by the local-id command takes precedence over the local ID
configured by the ike local-name command.
iii. Run remote-id-type { any | fqdn | ip | user-fqdn | none }
The remote ID type used in IKE negotiation is set.
By default, no remote ID type is set.
iv. (Optional) Run remote-id id
The remote ID used in IKE negotiation is set.
When the remote ID type is IP, the value configured by the remote-address
command is used as the remote ID by default, regardless of whether the
remote-id command is configured.
l RSA signature authentication
a. Configure the ID type and ID value.
For RSA signature authentication, the remote ID type or remote ID on the local end
must be consistent with corresponding fields in the local certificate on the remote
end. Configure the ID type and ID value according to Table 4-10.
Table 4-10 Relationship between the local ID type, local ID, remote ID type, and
remote ID
Local ID Type Local ID Remote ID Remote ID
Type
DN Subject: DN remote-id /
CN=devicea CN=devicea
You need to configure the local ID when the ID type of an IKE peer is FQDN
or User-FQDN.
viii. Run remote-id-type { any | dn | fqdn | ip | user-fqdn | none }
The remote ID type used in IKE negotiation is set.
By default, no remote ID type is set.
The local and remote ID types of an IKE peer must be the same.
ix. (Optional) Run remote-id id
The remote ID used in IKE negotiation is set.
When the remote ID type is IP, the value configured by the remote-address
command is used as the remote ID by default, regardless of whether the
remote-id command is configured.
If the local ID type is FQDN or User-FQDN, the remote end uses the remote-id
specified in the IKE peer as the remote ID for IKEv1 negotiation. However, for IKEv2
negotiation, the remote end preferentially uses the value of the DNS (corresponding to
FQDN) or email (corresponding to User-FQDN) field in the certificate. If the fields are
unavailable, the remote end uses the remote-id specified in the IKE peer for
negotiation.
x. (Optional) Run inband ocsp
The device is configured to validate the remote certificate based on the OCSP
validation result sent from the remote device when IKEv2 uses RSA signature
authentication.
By default, the device does not validate the remote certificate based on the
OCSP validation result sent from the remote device when IKEv2 uses RSA
signature authentication.
xi. (Optional) Run inband crl
The device is configured to validate the remote certificate based on the CRL
sent from the remote device when IKEv2 uses RSA signature authentication.
By default, the device does not validate the remote certificate based on the
CRL sent from the remote device when IKEv2 uses RSA signature
authentication.
If both the inband ocsp and inband crl commands are run, the certificate is
considered valid only when the certificate verifications in OCSP and CRL
modes are passed.
xii. (Optional) Run ikev2 id-match-certificate enable
The device is enabled to check certificate identity information of the remote
device during IKEv2 certificate negotiation.
By default, the device does not check certificate identity information of the
remote device during IKEv2 certificate negotiation.
After this command is configured, the local device only checks the Subject
field, IP address, FQDN, or email of the remote device. If the information
differs from the ID (DN, IP address, FQDN, or User-FQDN) of the remote
device, IKEv2 negotiation fails.
xiii. (Optional) Run certificate-request empty-payload enable
The certificate request payload is empty.
By default, certificate request payloads carry CA information.
By default, the device does not send IKE SA lifetime notification messages.
IKEv1 peers negotiate the lifetime, and a smaller SA lifetime at the two ends is used. When a
Huawei device and a non-Huawei device establish an IPSec tunnel and they use different IKE
SA lifetimes, run this command to enable the device to send IKE SA lifetime notification
messages. By doing this, two ends can successfully perform IKE negotiation.
In remote access, IPSec peers periodically send re-authentication packets, which reduces
potential risks of attacks and improves IPSec network security.
----End
Context
After the SA lifetime is set, SAs are updated in real time and difficult to decipher, enhancing
security.
Before an IKE SA becomes invalid, IKE negotiates a new IKE SA for the remote end. The
remote end uses the new IKE SA to protect IPSec communication immediately after the new
IKE SA is negotiated. If service traffic is transmitted, the original IKE SA is deleted
immediately. If no service traffic is transmitted, the original IKE SA will be deleted after 10s
or the hard lifetime expires.
Changing the lifetime does not affect the established IKE SAs, and the changed value is used
for establishing new IKE SAs in subsequent negotiation.
Procedure
1. Run system-view
The system view is displayed.
2. Run ike proposal proposal-number
The IKE proposal view is displayed.
3. Run sa duration time-value
The IKE SA hard lifetime is set.
By default, the IKE SA lifetime is 86400s.
If the hard lifetime ends, IKE SAs are updated automatically. IKE negotiation involves
Diffie-Hellman key calculation, which takes a long period of time. To ensure that IKE
SA update does not affect secure communication, you are advised to set the lifetime to a
value greater than 600s.
Context
Heartbeat detection enables the local end to periodically send heartbeat packets to the remote
end. If the local end does not receive heartbeat packets within the timeout interval, the local
end considers the remote end as unreachable and deletes the IKE SA or IPSec SA between
IKE peers.
The interval at which heartbeat packets are sent at the local end must be used with the timeout
interval of heartbeat packets at the remote end. If the remote end does not receive any
heartbeat packet within the timeout interval and the IKE SA carries a timeout tag, the IKE SA
and its corresponding IPSec SA are deleted. If the IKE SA does not carry a timeout tag, it is
marked as timeout.
If IKE peers use IKEv1 during negotiation, the device supports heartbeat detection. If IKE peers use
IKEv2 during negotiation, the device does not support heartbeat detection.
Procedure
Step 1 Run system-view
By default, a heartbeat packet uses old type sequence number mechanism and does not carry
the SPI list.
By default, the timeout interval during which an IKE SA waits for a heartbeat packet is not
configured.
When ike heartbeat-timer interval is configured at one end, the ike heartbeat-timer
timeout command must be used at the other end.
The timeout interval of heartbeat packets must be longer than the interval at which heartbeat
packets are sent. Generally, packet loss does not occur for more than three consecutive times
on a network. Therefore, it is recommended that the timeout interval of heartbeat packets be
three times the interval at which heartbeat packets are sent.
----End
Context
In IPSec communication, heartbeat detection technology detects faults at the remote end and
prevents packet loss. However, periodically sending heartbeat messages consumes CPU
resources at both ends and limits the number of established IPSec sessions.
Dead Peer Detection (DPD) technology sends DPD packets based on IPSec packets between
IKE peers, and does not periodically send heartbeat packets. When the local end can receive
IPSec traffic from the remote end, the local end considers the remote end as active. The local
end sends DPD packets to detect the status of the remote end when the local end does not
receive IPSec traffic from the remote end within a given period of time. If the local end does
not receive response packets after sending DPD packets several times, the local end considers
the remote end as unreachable and deletes the IKE SA or IPSec SA between IKE peers.
If heartbeat detection is used, the two ends periodically send heartbeat packets and settings at
the two ends must match. If DPD is used, settings except the payload sequence in DPD
packets at the two ends do not need to match. When IPSec packets are exchanged between
IKE peers, DPD packets are not sent. DPD packets are sent only when one end does not
receive IPSec packets from the other end in a period of time. This saves resources.
When both heartbeat detection and DPD are used, DPD takes effect.
When the configured DPD detection parameters do not match the end, the device restarts IKE negotiation
after the DPD probe fails, which affects the performance of the end device.
The detection mode and DPD are configured based on the dpd type command. Two DPD
modes are available:
l On-demand DPD
When the local end needs to send IPSec packets to the remote end, the local end
determines that the DPD idle time is reached and sends a DPD request packet to the
remote end.
l Periodic DPD
If the local end does not receive IPSec packets or a DPD request packet from the remote
end after the DPD idle time expires, it periodically sends a DPD request packet to the
remote end.
If the local end does not receive a DPD response packet from the remote end within the DPD
packet retransmission interval, the local end retransmits the DPD request packet. If the local
end still does not receive a DPD response packet after the DPD packet retransmission count is
reached, the local end considers that the remote end goes offline, and deletes the IKE SA and
IPSec SA.
Procedure
1. Run system-view
The system view is displayed.
2. Run ike peer peer-name
The IKE peer view is displayed.
3. (Optional) Run dpd msg { seq-hash-notify | seq-notify-hash }
The sequence of the payload in DPD packets is configured.
By default, the sequence of the payload in DPD packets is seq-notify-hash.
The two ends must use the same sequence of the payload in DPD packets; otherwise,
DPD does not take effect.
4. (Optional) Run dpd msg notify-hash-sequence learning
Automatic learning of the payload sequence of DPD packets is enabled.
By default, automatic learning of the payload sequence of DPD packets is enabled.
After this command is configured, when the local end receives a DPD packet from the
remote end, the local end learns the payload sequence of the DPD packet and sends a
DPD packet in the same payload sequence.
Context
l When a device functions as a responder during IKE negotiation, it can specify the peer
allowed to connect to it to improve security.
An IPSec policy template or an IPSec profile specifies the peer based on the identity
filter set.
As shown in Figure 4-31, the headquarters gateway RouterC functions as the responder.
An IPSec policy template is configured on RouterC, only RouterA matches the IP
address in the identity filter set.
GE0/0/1
60.1.2.1/24
Headquarters
Branch B
RouterB
Branch B
gateway
l In an IPSec over DSVPN application, multiple mGRE tunnel interfaces are configured
on the hub which provides only one IP address for spoke access. The mGRE tunnel
interfaces use the same source address or source interface. To solve this problem, set
parameters in the identity filter set to specify the mGRE tunnel interface of each IKE
packet.
For the detailed configuration of DSVPN, see DSVPN Configuration.
In a DSVPN application as shown in Figure 4-32, Spoke1 and Spoke2 belong to
DSVPN 1, while Spoke3 and Spoke4 belong to DSVPN 2. Spoke1 wants to
communicate with Spoke2, and Spoke3 wants to communicate with Spoke4. However,
the hub provides only one public network IP address for spokes access. After you
configure an identity filter set on the hub, it determines the mGRE tunnel interface of
each spoke based on parameters in the identity filter set.
Figure 4-32 Responder specifying a qualified initiator in the IPSec over DSVPN
application
Tunnel0/0/0 Tunnel0/0/0
172.10.1.2/24 Tunnel0/0/0 Tunnel0/0/0 172.10.2.3/24
172.10.1.3/24 172.10.2.2/24
Spoke1 Spoke2 Spoke3 Spoke4
DSVPN 1
DSVPN 2
Procedure
Step 1 Run system-view
You can set one or more parameters in the identity filter set view, depending on the device specification.
----End
Follow-up Procedure
Run the match ike-identity identity-name command in the ipsec policy template view or
IPSec profile view to reference the identity filter set.
Procedure
l Configure the DSCP priority globally.
a. Run system-view
The system view is displayed.
b. Run ike dscp dscp-value
The DSCP priority of IKE packets is configured globally.
By default, the global DSCP priority of IKE packets is 0.
l Configure the DSCP priority on an IKE peer.
a. Run system-view
The system view is displayed.
b. Run ike peer peer-name
An IKE peer is created and the IKE peer view is displayed.
Context
During IPSec VPN deployment, the initiator on a private network may need to establish an
IPSec tunnel with the responder on a public network. To ensure that an IPSec tunnel can be
established when a network address translation (NAT) device exists, NAT traversal is
required, as shown in Figure 4-33.
Private
network
Authentication Header (AH) integrity check involves the hash calculation for IP packets
including the IP address, whereas NAT changes the IP address and causes the hash value
change. Packets on the IPSec tunnel that has AH enabled cannot traverse a NAT device.
During Encapsulating Security Payload (ESP) integrity check, an outer IP header is not
checked. If only address translation is performed, ESP can work properly. ESP is a Layer 3
protocol and does not support port setting, so there is also a problem in ESP when NAT port
translation is used. To address this issue, NAT traversal encapsulates ESP packets with a UDP
header. In transport mode, a standard UDP header is inserted between the original IP header
and an ESP header during NAT traversal. In tunnel mode, a standard UDP header is inserted
between the new IP header and an ESP header during NAT traversal. When ESP packets pass
through a NAT device, the NAT device translates the IP address and port number of the outer
IP header and inserted UDP header. After the translated packets reach the remote end of the
IPSec tunnel, the remote end processes these packets in the same manner as IPSec packets.
If no IPSec packets are transmitted on an IPSec tunnel in a period of time, NAT session
entries may be aged out and deleted because the NAT session entries have the keepalive time.
As a result, the IPSec tunnel cannot transmit IPSec packets between the NAT device and the
IKE peer connected to the public network. To prevent NAT session entries from being aged,
an IKE SA on the private network side of the NAT device sends NAT Keepalive packets to its
remote end at an interval to maintain the NAT session.
If NAT traversal is enabled, the IPSec proposal referenced using the ipsec proposal command supports
only ESP. AH authenticates the entire IP packet. Any modification in the IP header causes an AH check
failure. Therefore, NAT traversal cannot be implemented on an IPSec tunnel protected by AH.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ike peer peer-name
An IKE peer is created and the IKE peer view is displayed.
Step 3 Run nat traversal
NAT traversal is enabled.
By default, the NAT traversal is enabled.
Step 4 Run quit
Return to the system view.
Step 5 Run ipsec nat-traversal source-port port-number
The UDP port number for IPSec NAT traversal is configured.
By default, the UDP port number for IPSec NAT traversal is 4500.
Step 6 Run ike nat-keepalive-timer interval interval
The interval for sending Keepalive packets is set.
By default, the interval for sending NAT Keepalive packets is 20 seconds.
----End
from different sites. A VPN instance bound in SA mode has a higher priority than a VPN
instance bound in IKE user mode.
The configuration takes effect only on the initiator of an IPSec tunnel. The initiator needs to obtain the
outbound interface when sending packets. The packets received by the remote peer contain the VPN
attribute, so the remote peer can still receive packets when no VPN is specified for it.
Procedure
l Binding a VPN instance in SA mode
a. Run system-view
The system view is displayed.
b. Run ike peer peer-name
An IKE peer is created and the IKE peer view is displayed.
c. Run sa binding vpn-instance vpn-instance-name
A VPN instance that IPSec tunnel traffic belongs to is specified.
By default, a VPN instance that IPSec tunnel traffic belongs to is not configured.
The VPN instance has been created using the ip vpn-instance command and the route
distinguisher (RD) has been configured for the VPN instance using the route-
distinguisher command.
The specified VPN instance must be the same as the VPN instance bound to the ACL
rule that is referenced by the 4.7.3 Configuring an IPSec Policy.
l Binding a VPN instance in IKE user mode
a. Run system-view
The system view is displayed.
b. Run ike user-table user-table-id
An IKE user table is created and its view is displayed, or the view of an existing
IKE user table is displayed directly.
c. Run user user-name
An IKE user is created and its view is displayed, or the view of an existing IKE user
is displayed directly.
d. Run vpn-instance-traffic { public | name vpn-instance-name }
A VPN instance corresponding to user traffic of the IKE user table is configured.
By default, the VPN instance corresponding to user traffic of the IKE user table is
not configured.
The VPN instance has been created using the ip vpn-instance command and the
route distinguisher (RD) has been configured for the VPN instance using the route-
distinguisher command.
The specified VPN instance must be the same as the VPN instance bound to the
ACL rule that is referenced by the 4.7.3 Configuring an IPSec Policy.
e. Run quit
Return to the IKE user table view.
f. Run quit
Return to the system view.
----End
Context
By default, no dependency exists between IPSec SA and IKE SA, that is, the two SAs can be
deleted separately. If the IKE SA is deleted but the corresponding IPSec SA still exists, traffic
forwarding will be effected. You can enable dependency between IPSec SA and IKE SA to
ensure that an IPSec SA is deleted when its corresponding IKE SA is deleted.
The system supports two configuration modes: global configuration and configuration on an
IKE peer. Parameters configured on an IKE peer take precedence over those configured
globally. When parameters are not configured on an IKE peer, the global parameter settings
take effect.
Procedure
l Global configuration
a. Run system-view
----End
Context
To improve network reliability, two devices can be deployed at the headquarters to connect to
the branch gateway. In an IPSec policy, two IP addresses or domain names of the remote IKE
peer can be configured on the branch gateway. The branch gateway first attempts to use the
first configured IP address or domain name to establish an IKE connection with the
headquarters gateway. If establishing an IKE connection fails or the dead peer detection
(DPD) fails, the branch gateway uses the second IP address or domain name to establish an
IKE connection.
If the IP address of the first IKE peer is unreachable in the scenario that two IP addresses are
configured, the branch gateway uses the second IP address to establish an IKE connection
only when establishing an IKE connection fails or DPD fails. It takes a long time, and traffic
cannot be switched back to the faulty gateway when it recovers.
You can use the Network Quality Analysis (NQA) or Bidirectional Forwarding Detection
(BFD) to detect the status of the IP address of an IKE peer and to make sure whether the IP
address of the IKE peer is valid according to the detection result. When the IP address of one
IKE peer is invalid, the traffic can be quickly switched to another IKE peer. This ensures that
when one headquarters gateway fails, the traffic can be quickly switched to another
headquarters gateway. You can also configure revertive switching of an IKE peer to ensure
that traffic can be switched back to the originally restored headquarters gateway.
Prerequisites
l If the NQA test instance status is used to determine whether the remote address of an
IKE peer is valid, ensure that the NQA test instance has been created. The device
supports only association between IPSec and NQA of ICMP type. For details on how to
configure an NAQ test instance of ICMP type, see Configuring an ICMP Test Instance.
l If the BFD session instance status is used to determine whether the remote address of an
IKE peer is valid, ensure that the BFD session has been created. For details on how to
configure a BFD session, see Configuring Single-Hop BFD.
Procedure
Step 1 Run system-view
The device is configured to determine whether the remote address of an IKE peer is valid
according to the NQA test instance or BFD session status.
By default, the device is configured to not determine whether the remote address of an IKE
peer is valid according to the NQA test instance or BFD session status.
----End
Procedure
l System view
a. Run system-view
The system view is displayed.
b. Run ike certificate-check disable
The device is configured not to verify certificates of all IKE peer.
By default, the device verifies certificates of all IKE peer.
l IKE peer view
a. Run system-view
The system view is displayed.
b. Run ike peer peer-name
The IKE peer view is displayed.
c. Run certificate-check disable
The device is configured not to verify certificates of an IKE peer.
By default, the device verifies certificates of an IKE peer.
----End
fragmentation so that the IKEv2 packet longer than the MTU specified by mtu-size is
fragmented before being encrypted. This configuration prevents the encrypted IKEv2 packet
from being fragmented before transmission.
Procedure
Step 1 Run system-view
IKEv2 packet fragmentation must be enabled on both ends. Otherwise, this function does not
take effect.
----End
Context
In an IKEv2 scenario, when the local device deletes the child SA and initiates IKEv2
negotiation to the peer device again, the default negotiation message carries the
IKEV2_NOTIFY_DELETE_OLD_CHILDSA payload, instructing the peer device to delete
the old child SA. If the peer device does not support the processing of this payload, IKEv2
negotiation between the two ends fails. To prevent this problem, disable the local device from
instructing the peer device to delete the old child SA so that the IKEv2 negotiation message
does not carry this payload.
Procedure
Step 1 Run system-view
The function of instructing the peer device to delete the old child SA is disabled.
By default, the function of instructing the peer device to delete the old child SA is enabled.
----End
Prerequisites
The IKE configurations are complete.
Procedure
l Run the display ike identity [ name identity-name ] command to check information
about an identity filter set.
l Run the display ike peer [ brief | name peer-name ] command to check IKE peer
information.
l Run the display ike proposal [ number proposal-number ] command to check
parameters in the IKE proposal.
l Run the display ike sa [ remote ipv4-address ] command to check brief information
about IKE SAs.
l Run the display ike sa [ remote-id-type remote-id-type ] remote-id remote-id command
to check brief information about IKE SAs based on the remote ID.
l Run the display ike sa verbose { remote ipv4-address | connection-id connection-id |
[ remote-id-type remote-id-type ] remote-id remote-id } command to check detailed
information about IKE SAs.
l Run the display ike global config command to check global IKE configuration.
l Run the display ike user-table [ number user-table-id [ user-name user-name ] ]
command to check IKE user table information.
----End
Prerequisites
All IPSec configurations are complete.
In routine maintenance, you can run the following commands in any view to check whether
IPSec is functioning properly.
Procedure
l Run the display ike sa [ remote ipv4-address ] command to check brief information
about IKE SAs.
l Run the display ike sa [ remote-id-type remote-id-type ] remote-id remote-id command
to check brief information about IKE SAs based on the remote ID.
l Run the display ike sa verbose { remote ipv4-address | connection-id connection-id |
[ remote-id-type remote-id-type ] remote-id remote-id } command to check detailed
information about IKE SAs.
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | remote
ipv4-address ] command to check IPSec SA information.
l Run the display ipsec p2mp-sa-statistics command to check statistics on P2MP SA
packets.
NOTICE
Statistics cannot be restored after being cleared. Exercise caution when you run the reset
commands.
When the number of IPSec tunnels is larger than 50% of the maximum limit, high CPU usage
alarms may be generated in a short period of time after the reset ipsec sa or reset ike sa
command is run. After all the SAs are cleared, the CPU usage restores to the normal range.
Procedure
l Run the reset ipsec sa [ remote ipv4-address | policy policy-name [ seq-number ] |
parameters ipv4-address { ah | esp } spi | profile profile-name ] command in the user
view to clear established SAs.
l After confirming information to be cleared, run the reset ipsec p2mp-sa command in the
user view to clear IPSec P2MP SA.
----End
Networking Requirements
As shown in Figure 4-34, RouterA (branch gateway) and RouterB (headquarters gateway)
communicate through the Internet. The branch subnet is 10.1.1.0/24 and the headquarters
subnet is 10.1.2.0/24.
The enterprise wants to protect data flows between the branch subnet and the headquarters
subnet. An IPSec tunnel can be manually set up between the branch gateway and headquarters
gateway because they communicate over the Internet and only a few branches gateway need
to be maintained.
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
Branch gateway Headquarter gateway
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24
10.1.2.2/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses and static routes for interfaces on RouterA and RouterB so that
routes between RouterA and RouterB are reachable.
2. Configure ACLs to define data flows to be protected.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IPSec policies and reference ACLs and IPSec proposals in the IPSec policies
to determine the methods used to protect data flows.
5. Apply IPSec policy groups to interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterB is 1.1.1.2.
[RouterA] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
[RouterA] ip route-static 10.1.2.0 255.255.255.0 1.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 2.1.1.2.
[RouterB] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
[RouterB] ip route-static 10.1.1.0 255.255.255.0 2.1.1.2
Step 2 Configure ACLs on RouterA and RouterB to define data flows to be protected.
# Configure an ACL on RouterA to define data flows sent from 10.1.1.0/24 to 10.1.2.0/24.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[RouterA-acl-adv-3101] quit
# Configure an ACL on RouterB to define data flows sent from 10.1.2.0/24 to 10.1.1.0/24.
[RouterB] acl number 3101
[RouterB-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[RouterB-acl-adv-3101] quit
Run the display ipsec proposal command on RouterA and RouterB to view the IPSec
proposal configuration.
Step 4 Create IPSec policies on RouterA and RouterB.
# Manually create an IPSec policy on RouterA.
[RouterA] ipsec policy map1 10 manual
[RouterA-ipsec-policy-manual-map1-10] security acl 3101
[RouterA-ipsec-policy-manual-map1-10] proposal tran1
[RouterA-ipsec-policy-manual-map1-10] tunnel remote 2.1.1.1
[RouterA-ipsec-policy-manual-map1-10] tunnel local 1.1.1.1
[RouterA-ipsec-policy-manual-map1-10] sa spi outbound esp 12345
[RouterA-ipsec-policy-manual-map1-10] sa spi inbound esp 54321
[RouterA-ipsec-policy-manual-map1-10] sa string-key outbound esp cipher huawei
[RouterA-ipsec-policy-manual-map1-10] sa string-key inbound esp cipher huawei
[RouterA-ipsec-policy-manual-map1-10] quit
Run the display ipsec policy command on RouterA and RouterB to view the configurations
of the IPSec policies.
Step 5 Apply IPSec policy groups to interfaces on RouterA and RouterB.
# Apply the IPSec policy group to the interface of RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ipsec policy map1
[RouterA-GigabitEthernet1/0/0] quit
# After the configurations are complete, PC A can ping PC B successfully. You can run the
display ipsec statistics command to view packet statistics.
# Run the display ipsec sa command on RouterA and RouterB to view the IPSec
configuration. The display on RouterA is used as an example.
[RouterA] display ipsec sa
ipsec sa information:
===============================
Interface: GigabitEthernet1/0/0
===============================
-----------------------------
IPSec policy name: "map1"
Sequence number: 10
Acl group: 3101
Acl rule: -
Mode: Manual
-----------------------------
Encapsulation mode: Tunnel
Tunnel local : 1.1.1.1
Tunnel remote : 2.1.1.1
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3101
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ipsec policy map1 10 manual
security acl 3101
proposal tran1
tunnel local 1.1.1.1
tunnel remote 2.1.1.1
sa spi inbound esp 54321
sa string-key inbound esp cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!
%^%#
sa spi outbound esp 12345
sa string-key outbound esp cipher %^%#K{JG:rWVHPMnf;5\|,GW(Luq'qi8BT4nOj
%5W5=)%^%#
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
ipsec policy map1
#
interface GigabitEthernet2/0/0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
ip route-static 10.1.2.0 255.255.255.0 1.1.1.2
#
return
Figure 4-35 Establishing an IPSec tunnel in IKE negotiation mode using default settings
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
Branch gateway Headquarter gateway
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24
10.1.2.2/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses and static routes for interfaces on RouterA and RouterB so that
routes between RouterA and RouterB are reachable.
2. Configure ACLs to define data flows to be protected.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IKE peers to define IKE negotiation attributes.
5. Configure IPSec policies and reference ACLs and IPSec proposals in the IPSec policies
to determine the methods used to protect data flows.
6. Apply IPSec policy groups to interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterB is 1.1.1.2.
[RouterA] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
[RouterA] ip route-static 10.1.2.0 255.255.255.0 1.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 2.1.1.2.
[RouterB] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
[RouterB] ip route-static 10.1.1.0 255.255.255.0 2.1.1.2
Step 2 Configure ACLs on RouterA and RouterB to define data flows to be protected.
# Configure an ACL on RouterA to define data flows sent from 10.1.1.0/24 to 10.1.2.0/24.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[RouterA-acl-adv-3101] quit
# Configure an ACL on RouterB to define data flows sent from 10.1.2.0/24 to 10.1.1.0/24.
[RouterB] acl number 3101
[RouterB-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[RouterB-acl-adv-3101] quit
Run the display ipsec proposal command on RouterA and RouterB to view the IPSec
proposal configuration.
Step 4 Configure IKE peers on RouterA and RouterB.
# Configure an IKE proposal on RouterA.
[RouterA] ike proposal 5
[RouterA-ike-proposal-5] encryption-algorithm aes-128
[RouterA-ike-proposal-5] authentication-algorithm sha2-256
[RouterA-ike-proposal-5] dh group14
[RouterA-ike-proposal-5] quit
# Configure an IKE peer on RouterA and set the pre-shared key and remote ID according to
default settings.
[RouterA] ike peer spub
[RouterA-ike-peer-spub] undo version 2
[RouterA-ike-peer-spub] ike-proposal 5
[RouterA-ike-peer-spub] pre-shared-key cipher huawei@123
[RouterA-ike-peer-spub] remote-address 2.1.1.1
[RouterA-ike-peer-spub] quit
# Configure an IKE peer on RouterB and set the pre-shared key and remote ID according to
default settings.
[RouterB] ike peer spua
[RouterB-ike-peer-spua] undo version 2
[RouterB-ike-peer-spua] ike-proposal 5
[RouterB-ike-peer-spua] pre-shared-key cipher huawei@123
[RouterB-ike-peer-spua] remote-address 1.1.1.1
[RouterB-ike-peer-spua] quit
Run the display ipsec policy command on RouterA and RouterB to view the configurations
of the IPSec policies.
# After the configurations are complete, PC A can ping PC B successfully. Data exchanged
between PC A and PC B is encrypted. You can run the display ipsec statistics command to
view packet statistics.
# Run the display ike sa command on RouterA. The following information is displayed:
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
Number of IKE SA : 2
--------------------------------------------------------------------------------
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3101
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm
aes-128
dh
group14
authentication-algorithm
sha2-256
authentication-method pre-
share
integrity-algorithm hmac-
sha2-256
prf hmac-sha2-256
#
ike peer spub
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 2.1.1.1
#
ipsec policy map1 10 isakmp
security acl 3101
ike-peer spub
proposal tran1
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
ipsec policy map1
#
interface GigabitEthernet2/0/0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
ip route-static 10.1.2.0 255.255.255.0 1.1.1.2
#
return
dh
group14
authentication-algorithm
sha2-256
authentication-method pre-
share
integrity-algorithm hmac-
sha2-256
prf hmac-sha2-256
#
ike peer spua
undo version 2
pre-shared-key cipher %^%#K{JG:rWVHPMnf;5\|,GW(Luq'qi8BT4nOj%5W5=)%^%#
ike-proposal 5
remote-address 1.1.1.1
#
ipsec policy use1 10 isakmp
security acl 3101
ike-peer spua
proposal tran1
#
interface GigabitEthernet1/0/0
ip address 2.1.1.1 255.255.255.0
ipsec policy use1
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
ip route-static 10.1.1.0 255.255.255.0 2.1.1.2
#
return
Figure 4-36 Establishing an IPSec tunnel between the enterprise headquarters and branch
using an IPSec policy template
PC A
192.168.1.1/24
Branch A
GE0/0/2
192.168.1.2/24
RouterA
Branch A IPSe
c Tunn
gateway GE0/0/1 e l
GE0/0/1
60.1.1.1/24
60.1.3.1/24
RouterC
Headquarters gateway
GE0/0/1 e l GE0/0/2
60.1.2.1/24 c Tunn
IPSe 192.168.3.2/24
RouterB
Branch B GE0/0/2
gateway 192.168.2.2/24 Headquarters
PC C
Branch B 192.168.3.1/24
PC B
192.168.2.1/24
Configuration Roadmap
The headquarters gateway can only respond to IPSec negotiation requests initiated by branch
gateways because it cannot identify IP addresses of branch gateways. An IPSec policy
template is configured on RouterC and is referenced in an IPSec policy so that RouterC can
receive IPSec negotiation requests initiated by branch gateways to complete setup of multiple
IPSec tunnels.
1. Configure IP addresses and static routes for interfaces so that routes among the three
gateways are reachable.
2. Configure ACLs to define the data flows to be protected.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IKE peers to define IKE negotiation attributes.
– Configure RouterA to use its IP address for authentication with RouterC because
RouterA uses a fixed IP address for access.
– Configure RouterB to use its name for authentication with RouterC because
RouterB uses a dynamic IP address for access.
5. Configure an identity filter set on RouterC to permit access from RouterA and RouterB.
This prevents other unauthorized initiators from establishing an IPSec tunnel with
RouterC.
– Check the IP address of RouterA.
– Check the name of RouterB.
6. Configure IPSec policies on RouterA, RouterB, and RouterC. RouterC uses an IPSec
policy template to create an IPSec policy.
7. Apply IPSec policy groups to interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA, RouterB, and RouterC so
that routes among them are reachable.
# Assign an IP address to each interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ip address 60.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/1] quit
[RouterA] interface gigabitethernet 0/0/2
[RouterA-GigabitEthernet0/0/2] ip address 192.168.1.2 255.255.255.0
[RouterA-GigabitEthernet0/0/2] quit
# Configure a static route to the peer on RouterA. This example assumes that the next-hop
address of the route to RouterC is 60.1.1.2.
[RouterA] ip route-static 60.1.3.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the outbound
interface of the route to the headquarters is GE0/0/1.
[RouterB] ip route-static 60.1.3.0 255.255.255.0 gigabitethernet 0/0/1
[RouterB] ip route-static 192.168.3.0 255.255.255.0 60.gigabitethernet 0/0/1
# Configure a static route to the peer on RouterC. This example assumes that the next-hop
address of the route to RouterA and RouterB is 60.1.3.2.
[RouterC] ip route-static 0.0.0.0 0.0.0.0 60.1.3.2
Step 2 Configure ACLs on RouterA and RouterB to define the data flows to be protected.
Because RouterC uses an IPSec policy template to create an IPSec policy, so referencing an ACL is optional.
If an ACL is configured on RouterC, specify the destination address in the ACL.
# Configure an ACL on RouterA to define the data flows sent from 192.168.1.0/24 to
192.168.3.0/24.
[RouterA] acl number 3002
[RouterA-acl-adv-3002] rule permit ip source 192.168.1.0 0.0.0.255 destination
192.168.3.0 0.0.0.255
[RouterA-acl-adv-3002] quit
# Configure an ACL on RouterB to define the data flows sent from 192.168.2.0/24 to
192.168.3.0/24.
[RouterB] acl number 3002
[RouterB-acl-adv-3002] rule permit ip source 192.168.2.0 0.0.0.255 destination
192.168.3.0 0.0.0.255
[RouterB-acl-adv-3002] quit
Configure the local name as huaweirt1 and the local ID type as FQDN for IKE negotiation because RouterB
uses a dynamic IP address for access.
[RouterB] ike local-name huaweirt1
[RouterB] ike peer rut1
[RouterB-ike-peer-rut1] undo version 2
[RouterB-ike-peer-rut1] ike-proposal 5
[RouterB-ike-peer-rut1] pre-shared-key cipher huawei@123
[RouterB-ike-peer-rut1] local-id-type fqdn
[RouterB-ike-peer-rut1] remote-address 60.1.3.1
[RouterB-ike-peer-rut1] quit
RouterC functions as the IKE responder and uses an IPSec policy template to create an IPSec policy, so the
remote-address command does not need to be used.
[RouterC] ike peer rut1
[RouterC-ike-peer-rut1] undo version 2
[RouterC-ike-peer-rut1] ike-proposal 5
[RouterC-ike-peer-rut1] pre-shared-key cipher huawei@123
[RouterC-ike-peer-rut1] quit
Step 6 Configuring IPSec policies on RouterA, RouterB, and RouterC. RouterC uses an IPSec policy
template to create an IPSec policy.
# Create an IPSec policy on RouterA.
[RouterA] ipsec policy policy1 10 isakmp
[RouterA-ipsec-policy-isakmp-policy1-10] ike-peer rut1
[RouterA-ipsec-policy-isakmp-policy1-10] proposal tran1
[RouterA-ipsec-policy-isakmp-policy1-10] security acl 3002
[RouterA-ipsec-policy-isakmp-policy1-10] quit
# Configure an IPSec policy template on RouterC and reference the IPSec policy template in
the IPSec policy.
Step 7 Apply IPSec policy groups to interfaces on RouterA, RouterB, and RouterC.
# Apply an IPSec policy group to the interface of RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ipsec policy policy1
[RouterA-GigabitEthernet0/0/1] quit
Number of IKE SA : 2
---------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
# Run the display ike sa command on RouterC. The following information is displayed:
[RouterC] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
961 60.1.2.1:500 RD v1:2 FQDN huaweirt1
933 60.1.2.1:500 RD v1:1 FQDN huaweirt1
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
Number of IKE SA : 4
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.3.0
0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 60.1.3.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.1.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 60.1.1.2
ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
#
return
Networking Requirements
As shown in Figure 4-37, RouterA and RouterB are branch gateways, and RouterC is the
headquarters gateway. The headquarters and branches communicate through the Internet. The
gateways' IP addresses are fixed. The subnets of branch A, branch B, and headquarters are
192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 respectively.
The enterprise wants to protect data flows between the branch subnets and the headquarters
subnet. IPSec tunnels can be set up between the branch gateways and headquarters gateway
because they communicate over the Internet. Because branch gateways' IP addresses can be
specified on the headquarters gateway, an IPSec policy group can be configured on RouterC.
Then the headquarters gateway can initiate IPSec negotiation to each branch gateway or
receive IPSec negotiation requests from each branch gateway to complete setup of multiple
IPSec tunnels.
Figure 4-37 Establishing multiple IPSec tunnels between the enterprise headquarters and
branches using IPSec policies
PC A
192.168.1.1/24
Branch A
GE0/0/2
192.168.1.2/24
RouterA
Branch A IPSe
c Tunn
gateway GE0/0/1 e l
GE0/0/1
60.1.1.1/24
60.1.3.1/24
RouterC
Headquarters gateway
GE0/0/1 e l GE0/0/2
60.1.2.1/24 c Tunn
IPSe 192.168.3.2/24
RouterB
Branch B GE0/0/2
gateway 192.168.2.2/24 Headquarters
PC C
Branch B 192.168.3.1/24
PC B
192.168.2.1/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses and static routes for interfaces so that routes among the three
gateways are reachable.
2. Configure ACLs to define data flows to be protected.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IKE peers to define IKE negotiation attributes.
5. Configure IPSec policies on RouterA and RouterB. Create IPSec policy groups on
RouterC to define protection methods for data flows between RouterA and RouterC, and
between RouterB and RouterC.
6. Apply IPSec policy groups to interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA, RouterB, and RouterC so
that routes among them are reachable.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ip address 60.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/1] quit
[RouterA] interface gigabitethernet 0/0/2
[RouterA-GigabitEthernet0/0/2] ip address 192.168.1.2 255.255.255.0
[RouterA-GigabitEthernet0/0/2] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterC is 60.1.1.2.
[RouterA] ip route-static 60.1.3.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterC is 60.1.2.2.
[RouterB] ip route-static 60.1.3.0 255.255.255.0 60.1.2.2
[RouterB] ip route-static 192.168.3.0 255.255.255.0 60.1.2.2
[RouterC-GigabitEthernet0/0/1] quit
[RouterC] interface gigabitethernet 0/0/2
[RouterC-GigabitEthernet0/0/2] ip address 192.168.3.2 255.255.255.0
[RouterC-GigabitEthernet0/0/2] quit
# Configure a static route to the peer on RouterC. This example assumes that the next hop
address in the route to RouterA and RouterB is 60.1.3.2.
[RouterC] ip route-static 60.1.1.0 255.255.255.0 60.1.3.2
[RouterC] ip route-static 60.1.2.0 255.255.255.0 60.1.3.2
[RouterC] ip route-static 192.168.1.0 255.255.255.0 60.1.3.2
[RouterC] ip route-static 192.168.2.0 255.255.255.0 60.1.3.2
Step 2 Configure ACLs on RouterA, RouterB, and RouterC to define data flows to be protected.
# Configure an ACL on RouterA to define data flows sent from 192.168.1.0/24 to
192.168.3.0/24.
[RouterA] acl number 3002
[RouterA-acl-adv-3002] rule permit ip source 192.168.1.0 0.0.0.255 destination
192.168.3.0 0.0.0.255
[RouterA-acl-adv-3002] quit
Run the display ipsec proposal command on RouterA, RouterB, and RouterC to view the
IPSec proposal configuration. The display on RouterA is used as an example.
Step 5 Configure IPSec policies on RouterA and RouterB, and configure an IPSec policy group on
RouterC.
Run the display ipsec policy command on RouterA and RouterB to view the configurations
of the IPSec policies.
Run the display ipsec policy command on RouterC.
Step 6 Apply IPSec policy groups to interfaces on RouterA, RouterB, and RouterC.
# Apply the IPSec policy group to the interface of RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ipsec policy policy1
[RouterA-GigabitEthernet0/0/1] quit
Number of IKE SA : 2
---------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
# Run the display ike sa command on RouterC. The following information is displayed:
[RouterC] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
961 60.1.2.1:500 RD v1:2 IP 60.1.2.1
933 60.1.2.1:500 RD v1:1 IP 60.1.2.1
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
Number of IKE SA : 4
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.3.0
0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 60.1.3.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#IRFGEiFPJ1$&a'Qy,L*XQL_+*Grq-=yMb}ULZdS6%^%#
ike-proposal 5
remote-address 60.1.1.1
#
ike peer rut2
undo version 2
pre-shared-key cipher %^%#(3fr1!&6O=)!GN#~{)n,2fq>4#4+%;lMTs5(]:c)%^%#
ike-proposal 5
remote-address 60.1.2.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
ipsec policy policy1 11 isakmp
security acl 3003
ike-peer rut2
proposal tran1
#
interface GigabitEthernet0/0/1
ip address 60.1.3.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.3.2 255.255.255.0
#
ip route-static 60.1.1.0 255.255.255.0 60.1.3.2
ip route-static 60.1.2.0 255.255.255.0 60.1.3.2
ip route-static 192.168.1.0 255.255.255.0 60.1.3.2
ip route-static 192.168.2.0 255.255.255.0 60.1.3.2
#
return
Networking Requirements
In Figure 4-38, a large enterprise has achieved interconnection between branches and
between branches and the headquarters using DSVPN, and different services are transmitted
through different networks, for example, service 1 is transmitted through network 1, and
service 2 is transmitted through network 2.
The enterprise requires that the data transmitted between branches and between branches and
the headquarters be encrypted.
Figure 4-38 Establishing a DSVPN over IPSec tunnel between the headquarters and branches
across different networks
LoopBack0
10.1.2.1/24
Branch 1 Tunnel0/0/0
10.1.2.0/24 10.2.1.2/24
Tunnel0/0/1
10.3.1.2/24
Spoke1 GE1/0/0
2.1.1.1/24 LoopBack0
Network 1 10.1.1.1/24
GE1/0/0 Hub
1.1.1.1/24
Headquarters
10.1.1.0/24
Tunnel0/0/0
LoopBack0 10.2.1.1/24
10.1.3.1/24 Network 2
Tunnel0/0/1
Spoke2 10.3.1.1/24
GE1/0/0
3.1.1.1/24
Branch 2 Tunnel0/0/0
10.1.3.0/24 10.2.1.3/24
Tunnel0/0/1
10.3.1.3/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses for interfaces and OSPF routes to ensure that private and public
network routes are reachable.
2. Configure DSVPN and differentiate different services through tunnel interfaces so that
different services can be transmitted through different networks.
3. Configure IPSec and establish a DSVPN over IPSec tunnel using an IPSec profile to
encrypt data.
Procedure
Step 1 Configure IP addresses for interfaces and configure OSPF routes.
# Configure IP addresses for interfaces of the Hub. The configurations of Spoke1 and Spoke2
are similar to that of the Hub, and are not mentioned here.
<Huawei> system-view
[Huawei] sysname Hub
# Configure OSPF routes on the Hub. The configurations of Spoke1 and Spoke2 are similar to
that of the Hub, and are not mentioned here.
[Hub] ospf 2 router-id 1.1.1.1
[Hub-ospf-2] area 0.0.0.1
[Hub-ospf-2-area-0.0.0.1] network 1.1.1.0 0.0.0.255
[Hub-ospf-2-area-0.0.0.1] quit
[Hub-ospf-2] quit
[Hub] ospf 1 router-id 10.1.1.1
[Hub-ospf-1] area 0.0.0.0
[Hub-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[Hub-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[Hub-ospf-1-area-0.0.0.0] network 10.3.1.0 0.0.0.255
[Hub-ospf-1-area-0.0.0.0] quit
[Hub-ospf-1] quit
# Configure Spoke1. The configuration of Spoke2 is similar to that of Spoke1, and is not
mentioned here.
[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/0] source gigabitethernet 1/0/0
[Spoke1-Tunnel0/0/0] gre key cipher 123
[Spoke1-Tunnel0/0/0] nhrp entry 10.2.1.1 1.1.1.1 register
[Spoke1-Tunnel0/0/0] ospf network-type p2mp
[Spoke1-Tunnel0/0/0] nhrp shortcut
[Spoke1-Tunnel0/0/0] quit
[Spoke1] interface tunnel 0/0/1
[Spoke1-Tunnel0/0/1] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/1] source gigabitethernet 1/0/0
[Spoke1-Tunnel0/0/1] gre key cipher 456
[Spoke1-Tunnel0/0/1] nhrp entry 10.3.1.1 1.1.1.1 register
[Spoke1-Tunnel0/0/1] ospf network-type p2mp
[Spoke1-Tunnel0/0/1] nhrp shortcut
[Spoke1-Tunnel0/0/1] quit
If the same outbound interface is specified for multiple tunnel interfaces, the same IPSec profile
must be applied to these tunnel interfaces and the shared parameter must be configured for these
tunnel interfaces. Otherwise, both ends cannot establish an IPSec tunnel.
# Configure the Hub. The configurations of Spoke1 and Spoke2 are similar to that of the
Hub, and are not mentioned here.
[Hub] interface tunnel 0/0/0
[Hub-Tunnel0/0/0] ipsec profile profile1 shared
[Hub-Tunnel0/0/0] quit
[Hub] interface tunnel 0/0/1
[Hub-Tunnel0/0/1] ipsec profile profile1 shared
[Hub-Tunnel0/0/1] quit
If you run the display nhrp peer all command on Spoke1 and Spoke2, you can view only the
static NHRP mapping entry of Hub.
The command output shows that a DSVPN tunnel has been established between the
Spokes and Hub.
2. Run the display ipsec sa command to view IPSec SA information. The following
displays IPSec SA information on Spoke1.
[Spoke1] display ipsec sa
ipsec sa information:
===============================
Shared interface: GigabitEthernet1/0/0
Interface: Tunnel0/0/1
Tunnel0/0/0
===============================
-----------------------------
IPSec profile name: "profile1"
Mode : PROF-ISAKMP
-----------------------------
Connection ID : 2
Encapsulation mode: Tunnel
Holding time : 0d 0h 13m 43s
Tunnel local : 2.1.1.1/500
Tunnel remote : 1.1.1.1/500
Flow source : 2.1.1.1/255.255.255.255 47/0-65535
Flow destination : 1.1.1.1/255.255.255.255 47/0-65535
The command output shows that an IPSec tunnel has been established between the
Spokes and Hub.
3. Run the ping command and check the configuration result.
On Spoke1, ping the private network address 10.1.3.1 of Spoke2, finding that Spoke1
and Spoke2 can obtain the dynamic NHRP peer entry of each other.
# Run the ping -a 10.1.2.1 10.1.3.1 command on Spoke1. The command output is as
follows:
[Spoke1] ping -a 10.1.2.1 10.1.3.1
PING 10.1.3.1: 56 data bytes, press CTRL_C to break
Reply from 10.1.3.1: bytes=56 Sequence=1 ttl=254 time=3 ms
Reply from 10.1.3.1: bytes=56 Sequence=2 ttl=255 time=2 ms
Reply from 10.1.3.1: bytes=56 Sequence=3 ttl=255 time=2 ms
Reply from 10.1.3.1: bytes=56 Sequence=4 ttl=255 time=2 ms
Reply from 10.1.3.1: bytes=56 Sequence=5 ttl=255 time=2 ms
# Run the display nhrp peer all command on Spoke1. The following displays the
command output of Spoke1.
[Spoke1] display nhrp peer all
------------------------------------------------------------------------------
----
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
------------------------------------------------------------------------------
----
10.2.1.1 32 1.1.1.1 10.2.1.1 hub up
------------------------------------------------------------------------------
----
Tunnel interface: Tunnel0/0/0
Created time : 01:29:22
Expire time : --
------------------------------------------------------------------------------
----
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
------------------------------------------------------------------------------
----
10.1.3.1 32 3.1.1.1 10.2.1.3 remote-network up
------------------------------------------------------------------------------
----
Tunnel interface: Tunnel0/0/0
Created time : 00:00:31
Expire time : 01:59:32
------------------------------------------------------------------------------
----
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
------------------------------------------------------------------------------
----
10.2.1.3 32 3.1.1.1 10.2.1.3 remote up
------------------------------------------------------------------------------
----
Tunnel interface: Tunnel0/0/0
Created time : 00:00:31
Expire time : 01:59:32
------------------------------------------------------------------------------
----
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
------------------------------------------------------------------------------
----
10.1.2.1 32 2.1.1.1 10.2.1.2 local up
------------------------------------------------------------------------------
----
Tunnel interface: Tunnel0/0/0
Created time : 00:00:31
Expire time : 01:59:32
------------------------------------------------------------------------------
----
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
------------------------------------------------------------------------------
----
10.3.1.1 32 1.1.1.1 10.3.1.1 hub up
------------------------------------------------------------------------------
----
Tunnel interface: Tunnel0/0/1
Created time : 00:11:27
Expire time : --
The command output shows that a DSVPN tunnel has been established between the
Spokes.
# Run the display ipsec sa command on Spoke1 and Spoke2. The following displays the
command output of Spoke1.
[Spoke1] display ipsec sa
ipsec sa information:
===============================
Shared interface: GigabitEthernet1/0/0
Interface: Tunnel0/0/1
Tunnel0/0/0
===============================
-----------------------------
IPSec profile name: "profile1"
Mode : PROF-ISAKMP
-----------------------------
Connection ID : 2
Encapsulation mode: Tunnel
Holding time : 0d 0h 20m 20s
Tunnel local : 2.1.1.1/500
Tunnel remote : 1.1.1.1/500
Flow source : 2.1.1.1/255.255.255.255 47/0-65535
Flow destination : 1.1.1.1/255.255.255.255 47/0-65535
-----------------------------
IPSec profile name: "profile1"
Mode : PROF-ISAKMP
-----------------------------
Connection ID : 4
Encapsulation mode: Tunnel
Holding time : 0d 0h 1m 4s
Tunnel local : 2.1.1.1/500
Tunnel remote : 3.1.1.1/500
Flow source : 2.1.1.1/255.255.255.255 47/0-65535
Flow destination : 3.1.1.1/255.255.255.255 47/0-65535
The command output shows that an IPSec tunnel has been established between the
Spokes.
4. Data can be encrypted for transmission between branches and between branches and the
headquarters.
----End
Configuration Files
l Hub configuration file
#
sysname Hub
#
ipsec proposal pro1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal 1
encryption-algorithm aes-256
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
#
ike peer hub
undo version 2
pre-shared-key cipher %^%#,cRg/1n'D7m{Jl;qH5l<p<_;HRGX:Z1|I+'Ej$(V%^%#
ike-proposal 1
#
ipsec profile profile1
ike-peer hub
proposal pro1
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 10.1.1.1 255.255.255.0
#
interface Tunnel0/0/0
ip address 10.2.1.1 255.255.255.0
tunnel-protocol gre p2mp
source GigabitEthernet1/0/0
gre key cipher %^%#iPh1-~G^|K+|P44)07a&kw%V3s:4hI"\Lt,WG::J%^%#
ospf network-type p2mp
ipsec profile profile1 shared
nhrp redirect
nhrp entry multicast dynamic
#
interface Tunnel0/0/1
ip address 10.3.1.1 255.255.255.0
tunnel-protocol gre p2mp
source GigabitEthernet1/0/0
gre key cipher %^%#$Xg\"^id!Y7B8()7:\+J>OZO&n"||ED0cR7s+WZR%^%#
ospf network-type p2mp
ipsec profile profile1 shared
nhrp redirect
nhrp entry multicast dynamic
#
ospf 1 router-id 10.1.1.1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
ospf 2 router-id 1.1.1.1
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return
l Spoke1 configuration file
#
sysname Spoke1
#
ipsec proposal pro1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal 1
encryption-algorithm aes-256
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
#
ike peer spoke
undo version 2
pre-shared-key cipher %^%#,cRg/1n'D7m{Jl;qH5l<p<_;HRGX:Z1|I+'Ej$(V%^%#
ike-proposal 1
#
#
interface Tunnel0/0/0
ip address 10.2.1.3 255.255.255.0
tunnel-protocol gre p2mp
source GigabitEthernet1/0/0
gre key cipher %^%#iPh1-~G^|K+|P44)07a&kw%V3s:4hI"\Lt,WG::J%^%#
ospf network-type p2mp
ipsec profile profile1 shared
nhrp shortcut
nhrp entry 10.2.1.1 1.1.1.1 register
#
interface Tunnel0/0/1
ip address 10.3.1.3 255.255.255.0
tunnel-protocol gre p2mp
source GigabitEthernet1/0/0
gre key cipher %^%#$Xg\"^id!Y7B8()7:\+J>OZO&n"||ED0cR7s+WZR%^%#
ospf network-type p2mp
ipsec profile profile1 shared
nhrp shortcut
nhrp entry 10.3.1.1 1.1.1.1 register
#
ospf 1 router-id 10.1.3.1
area 0.0.0.0
network 10.1.3.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
ospf 2 router-id 3.1.1.1
area 0.0.0.1
network 3.1.1.0 0.0.0.255
#
return
Figure 4-39 Establishing IPSec tunnels for branch access to the headquarters using different
pre-shared keys
PC A
192.168.1.1/24
Branch A
GE0/0/2
192.168.1.2/24
RouterA
Branch A IPSe
c Tunn
gateway GE0/0/1 e l
GE0/0/1
60.1.1.1/24
60.1.3.1/24
RouterC
Headquarters gateway
GE0/0/1 e l GE0/0/2
60.1.2.1/24 c Tunn
IPSe 192.168.3.2/24
RouterB
Branch B GE0/0/2
gateway 192.168.2.2/24 Headquarters
PC C
Branch B 192.168.3.1/24
PC B
192.168.2.1/24
Configuration Roadmap
The headquarters gateway can only respond to IPSec negotiation requests initiated by branch
gateways because it is difficult to specify IP addresses for branch gateways on the
headquarters gateway. As a result, you can deploy a policy template on RouterC and reference
this template in an IPSec policy. To allow branch gateways to connect to the headquarters
using different pre-shared keys, configure an IKE user table on RouterC to allocate pre-shared
keys for branches. The branches initiate IPSec negotiation using allocated pre-shared keys to
establish IPSec tunnels.
Procedure
Step 1 Configure an IP address and a static route for each interface on RouterA, RouterB, and
RouterC to ensure that there are reachable routes among them.
# Configure an IP address for each interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ip address 60.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/1] quit
[RouterA] interface gigabitethernet 0/0/2
[RouterA-GigabitEthernet0/0/2] ip address 192.168.1.2 255.255.255.0
[RouterA-GigabitEthernet0/0/2] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to the headquarters is 60.1.1.2.
[RouterA] ip route-static 60.1.3.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to the headquarters is 60.1.2.2.
[RouterB] ip route-static 60.1.3.0 255.255.255.0 60.1.2.2
[RouterB] ip route-static 192.168.3.0 255.255.255.0 60.1.2.2
# Configure a static route to the peer on RouterC. This example assumes that the next hop
address in the route to the branch gateways A and B is 60.1.3.2.
[RouterC] ip route-static 0.0.0.0 0.0.0.0 60.1.3.2
Step 2 Configure an ACL on RouterA and RouterB to define the data flows to be protected.
RouterC creates an IPSec policy through the IPSec policy template; therefore, this step is optional. If you
configure an ACL on RouterC, you must specify the destination address in the ACL rule.
[RouterB-ike-peer-rut1] ike-proposal 5
[RouterB-ike-peer-rut1] pre-shared-key cipher huawei@124
[RouterB-ike-peer-rut1] remote-address 60.1.3.1
[RouterB-ike-peer-rut1] quit
# Configure an IKE user table on RouterC to allocate pre-shared keys for branches.
When the IKEv1 main mode and pre-shared key authentication are used, id-type can only be set to ip,
and in NAT traversal scenarios, the IP address must be set to the post-NAT address. If a branch
dynamically obtains an IP address, you must use the IKEv1 aggressive mode or IKEv2 and advised to
set id-type to fqdn.
[RouterC] ike user-table 10
[RouterC-ike-user-table-10] user routera
[RouterC-ike-user-table-10-routera] id-type ip 60.1.1.1
[RouterC-ike-user-table-10-routera] pre-shared-key huawei@123
[RouterC-ike-user-table-10-routera] quit
[RouterC-ike-user-table-10] user routerb
[RouterC-ike-user-table-10-routerb] id-type ip 60.1.2.1
[RouterC-ike-user-table-10-routerb] pre-shared-key huawei@124
[RouterC-ike-user-table-10-routerb] quit
As the responder to IKE negotiation requests, RouterC creates an IPSec policy through the IPSec policy
template. You do not need to set remote-address.
[RouterC] ike peer rut1
[RouterC-ike-peer-rut1] undo version 2
[RouterC-ike-peer-rut1] ike-proposal 5
[RouterC-ike-peer-rut1] user-table 10
[RouterC-ike-peer-rut1] quit
Step 5 Create an IPSec policy on RouterA, RouterB, and RouterC respectively. RouterC creates an
IPSec policy through the IPSec policy template.
# Create an IPSec policy on RouterA.
[RouterA] ipsec policy policy1 10 isakmp
[RouterA-ipsec-policy-isakmp-policy1-10] ike-peer rut1
[RouterA-ipsec-policy-isakmp-policy1-10] proposal tran1
[RouterA-ipsec-policy-isakmp-policy1-10] security acl 3002
[RouterA-ipsec-policy-isakmp-policy1-10] quit
# Create a policy template on RouterC and apply the policy template to an IPSec policy.
[RouterC] ipsec policy-template use1 10
[RouterC-ipsec-policy-templet-use1-10] ike-peer rut1
[RouterC-ipsec-policy-templet-use1-10] proposal tran1
[RouterC-ipsec-policy-templet-use1-10] quit
[RouterC] ipsec policy policy1 10 isakmp template use1
Step 6 Apply an IPSec policy group to the interface of RouterA, RouterB, and RouterC.
# After the configurations are complete, PC A and PC B can ping PC C successfully. The data
transmitted among them is encrypted.
# Run the display ike sa command on RouterA and RouterB to view the IKE configuration.
The command output on RouterA is used as an example.
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
---------------------------------------------------------------------------
24366 60.1.3.1:500 RD|ST v1:2 IP 60.1.3.1
24274 60.1.3.1:500 RD|ST v1:1 IP 60.1.3.1
Number of IKE SA : 2
---------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
# Run the display ike sa command on RouterC. The command output is displayed as follows:
[RouterC] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
961 60.1.2.1:500 RD v1:2 IP 60.1.2.1
933 60.1.2.1:500 RD v1:1 IP 60.1.2.1
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
Number of IKE SA : 4
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l RouterA configuration file
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.3.0
0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 60.1.3.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.1.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 60.1.1.2
ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
#
return
#
interface GigabitEthernet0/0/1
ip address 60.1.2.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.2.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 60.1.2.2
ip route-static 192.168.3.0 255.255.255.0 60.1.2.2
#
return
Networking Requirements
As shown in Figure 4-40, Router_B and Router_C are the gateways of enterprise branches,
and Router_A is the gateway of the headquarters. The headquarters and branches
communicate through the public network.
The enterprise requires IPSec protection for the traffic between the headquarters and
branches. Multiple tunnel interfaces of the headquarters borrow the same physical interface IP
address, and one tunnel interface corresponds to one branch.
PC2
10.1.2.2/24
Branch
GE1/0/3
10.1.2.1/24 Tunnel0/0/0
Router_B IPSe
Tunnel0/0/0
c Tunn
GE1/0/1 el
GE1/0/1
1.1.5.1/24
1.1.3.1/24
Router_A
GE1/0/1 el GE1/0/3
1.1.6.1/24 c Tunn
IPSe 10.1.1.1/24
Tunnel0/0/1
Router_C
Tunnel0/0/1
HQ
GE1/0/3
10.1.3.1/24
Branch PC1
10.1.1.2/24
PC3
10.1.3.2/24
Configuration Roadmap
1. Configure the IP address and static route on each interface to implement communication
between interfaces.
2. Configure security policies in ISAKMP mode, including the data flows to be protected
and proposal parameters.
Multiple tunnel interfaces of the headquarters borrow the same physical interface IP
address to establish an IPSec tunnel with a branch. Therefore, the headquarters uses the
peer IP address of the IKE peer to identify the tunnel interface connected to the branch.
In this instance, multiple IKE peers need to be configured and multiple IPSec policies
created at the headquarters. In addition, different IPSec policies are applied to the tunnel
interfaces.
When multiple branches connect to the headquarters, multiple tunnel interfaces in the headquarters
borrow the same physical interface IP address. In this scenario, the headquarters can identify the tunnel
interface connected to a branch through the peer IP address or peer ID of the IKE peer (Only IKEv1 in
aggressive mode supports the peer ID mode.).
Procedure
Step 1 Configure Router_A.
1. Configure interface IP addresses and static routes.
a. Configure interface IP addresses.
<Huawei> system-view
[Huawei] sysname Router_A
[Router_A] interface gigabitethernet 1/0/3
[Router_A-GigabitEthernet1/0/3] ip address 10.1.1.1 24
[Router_A-GigabitEthernet1/0/3] quit
[Router_A] interface gigabitethernet 1/0/1
[Router_A-GigabitEthernet1/0/1] ip address 1.1.3.1 24
[Router_A-GigabitEthernet1/0/1] quit
[Router_A] interface tunnel 0/0/0
[Router_A-Tunnel0/0/0] tunnel-protocol ipsec
[Router_A-Tunnel0/0/0] ip address unnumbered interface gigabitethernet
1/0/1
[Router_A-Tunnel0/0/0] quit
[Router_A] interface tunnel 0/0/1
[Router_A-Tunnel0/0/1] tunnel-protocol ipsec
[Router_A-Tunnel0/0/1] ip address unnumbered interface gigabitethernet
1/0/1
[Router_A-Tunnel0/0/1] quit
b. Configure static routes to the branches. Assume that the next hop of the static routes
is 1.1.3.2.
[Router_A] ip route-static 0.0.0.0 0.0.0.0 1.1.3.2
[Router_A] ip route-static 10.1.2.0 255.255.255.0 tunnel 0/0/0
[Router_A] ip route-static 10.1.3.0 255.255.255.0 tunnel 0/0/1
Step 2 Configure Router_B. The configuration of Router_C is similar and will not be mentioned
here.
1. Configure interface IP addresses and static routes.
a. Configure interface IP addresses.
<Huawei> system-view
[Huawei] sysname Router_B
[Router_B] interface gigabitethernet 1/0/3
[Router_B-GigabitEthernet1/0/3] ip address 10.1.2.1 24
[Router_B-GigabitEthernet1/0/3] quit
[Router_B] interface gigabitethernet 1/0/1
[Router_B-GigabitEthernet1/0/1] ip address 1.1.5.1 24
[Router_B-GigabitEthernet1/0/1] quit
[Router_B] interface tunnel 0/0/0
[Router_B-Tunnel0/0/0] tunnel-protocol ipsec
[Router_B-Tunnel0/0/0] ip address unnumbered interface gigabitethernet
1/0/1
[Router_B-Tunnel0/0/0] quit
b. Configure static routes to the headquarters. Assume that the next hop of the static
route is 1.1.5.2.
[Router_B] ip route-static 0.0.0.0 0.0.0.0 1.1.5.2
[Router_B] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/0
# Run the display ike sa command. If information about the IKE SA and IPSec SA is
displayed, the IPSec tunnel is established successfully. The following uses Router_A as an
example:
[Router_A] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
------------------------------------------------------------------------------
50336907 1.1.5.1:500 RD|ST|A v2:2 IP 1.1.5.1
50336906 1.1.5.1:500 RD|ST|A v2:1 IP 1.1.5.1
33554436 1.1.6.1:500 RD|ST|A v2:2 IP 1.1.6.1
33554435 1.1.6.1:500 RD|ST|A v2:1 IP 1.1.6.1
Number of IKE SA : 4
------------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Router_A configuration file
#
sysname Router_A
#
acl number 3000
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
acl number 3001
rule 10 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.3.0 0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal 10
encryption-algorithm aes-256
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer b
pre-shared-key cipher %^%#W)04NhZ:bP=~"=KQu\CN6KcK#NE5:(Os2L57]r5I%^%#
ike-proposal 10
remote-address 1.1.5.1
ike peer c
pre-shared-key cipher %^%#W)04NhZ:bP=~"=KQu\CN6KcK#NE5:(Os2L57]r5I%^%#
ike-proposal 10
remote-address 1.1.6.1
#
#
ip route-static 0.0.0.0 0.0.0.0 1.1.5.2
ip route-static 10.1.1.0 255.255.255.0 Tunnel0/0/0
#
return
with the headquarters gateway RouterA. If the attempt fails, the branch gateway establishes an
IPSec tunnel with the headquarters gateway RouterB.
Figure 4-41 Establishing an IPSec tunnel between the branch and headquarters with a
redundant gateway
RouterA
Headquarters
gateway A
GE0/0/2
192.168.1.2/24
RouterC e l
c Tunn
Branch IPSe GE0/0/1
gateway 60.1.1.1/24
Configuration Roadmap
1. Configure the IP address and static route on each interface to implement communication
between interfaces.
2. Configure an ACL to define the data flows to be protected by the IPSec tunnel.
3. Configure an IPSec proposal to define the traffic protection method.
4. Configure an IKE peer and define the attributes used for IKE negotiation.
5. Create an IPSec policy on RouterA, RouterB, and RouterC respectively to determine
protection methods used for protecting different types of data flows. On RouterA and
RouterB, IPSec policies are created through IPSec policy templates.
6. Apply an IPSec policy group to an interface so that the interface can protect traffic.
Procedure
Step 1 Configure an IP address and a static route for each interface on RouterA, RouterB, and
RouterC to ensure that there are reachable routes among them.
# Assign an IP address to each interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to the headquarters subnet is 60.1.1.2.
[RouterA] ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to the headquarters subnet is 60.1.2.2.
[RouterB] ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
[RouterB] ip route-static 192.168.3.0 255.255.255.0 60.1.2.2
# Configure a static route to the peer on RouterC. This example assumes that the next hop
address in the route to the headquarters gateway A and B is 70.1.1.2.
[RouterC] ip route-static 0.0.0.0 0.0.0.0 70.1.1.2
Step 2 Configure an ACL on RouterA and RouterB to define the data flows to be protected.
RouterA and RouterB create an IPSec policy through the IPSec policy template; therefore, this step is
optional. If you configure an ACL on RouterA and RouterB, you must specify the destination address in the
ACL rule.
# Configure an ACL on RouterC to define the data flows from subnet 192.168.3.0/24 to
subnet 192.168.1.0/24.
[RouterC] acl number 3002
[RouterC-acl-adv-3002] rule permit ip source 192.168.3.0 0.0.0.255 destination
192.168.1.0 0.0.0.255
[RouterC-acl-adv-3002] quit
Run the display ipsec proposal command on RouterA, RouterB, and RouterC to view the
configuration of the IPSec proposal. The command output on RouterA is used as an example.
[RouterA] display ipsec proposal name tran1
RouterA and RouterB function as responders to respond to an IKE negotiation request; therefore, they create
IPSec policies through IPSec policy templates. You do not need to set remote-address.
Step 5 Create an IPSec policy on RouterA, RouterB, and RouterC respectively. On RouterA and
RouterB, IPSec policies are created through IPSec policy templates.
# Create an ipsec policy template on RouterA and apply the ipsec policy template to an IPSec
policy.
[RouterA] ipsec policy-template use1 10
[RouterA-ipsec-policy-templet-use1-10] ike-peer rut1
[RouterA-ipsec-policy-templet-use1-10] proposal tran1
[RouterA-ipsec-policy-templet-use1-10] quit
[RouterA] ipsec policy policy1 10 isakmp template use1
# Create an ipsec policy template on RouterB and apply the ipsec policy template to an IPSec
policy.
[RouterB] ipsec policy-template use1 10
[RouterB-ipsec-policy-templet-use1-10] ike-peer rut1
[RouterB-ipsec-policy-templet-use1-10] proposal tran1
[RouterB-ipsec-policy-templet-use1-10] quit
[RouterB] ipsec policy policy1 10 isakmp template use1
Step 6 Apply an IPSec policy group to the interface of RouterA, RouterB, and RouterC.
# After the configurations are complete, PC C can ping PC A successfully. The data
transmitted between PC C and PC A is encrypted.
# Run the display ike sa command on RouterA and RouterB to view the IKE configuration.
The command output on RouterA is used as an example.
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
---------------------------------------------------------------------------
24366 70.1.1.1:500 RD|ST v1:2 IP 70.1.1.1
24274 70.1.1.1:500 RD|ST v1:1 IP 70.1.1.1
Number of IKE SA : 2
---------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
# Run the display ike sa command on RouterC. The command output is displayed as follows:
[RouterC] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
Number of IKE SA : 2
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
#
ipsec policy-template use1 10
ike-peer rut1
proposal tran1
#
ipsec policy policy1 10 isakmp template use1
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
undo version 2
pre-shared-key cipher %^%#IRFGEiFPJ1$&a'Qy,L*XQL_+*Grq-=yMb}ULZdS6%^%#
ike-proposal 5
remote-address 60.1.1.1
remote-address 60.1.2.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
#
interface GigabitEthernet0/0/1
ip address 70.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.3.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 70.1.1.2
#
return
Figure 4-42 Establishing an IPSec tunnel between the enterprise headquarters and branch
using a multi-link shared IPSec policy group
LoopBack0
1.1.1.1/32 GE1/0/0
GE1/0/0 60.1.1.1/24
70.1.1.1/24
RouterA RouterB
Branch gateway Headquarters gateway
GE3/0/0 GE2/0/0 GE3/0/0
10.1.1.1/24 80.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Headquarters
Branch subnet
subnet
Configuration Roadmap
The branch gateway uses a loopback interface to establish an IPSec tunnel with the
headquarters gateway, and the two egress links and the headquarters gateway only negotiate a
shared IPSec SA. The configuration roadmap is as follows:
1. Configure IP addresses and static routes for interfaces on RouterA and RouterB so that
routes between RouterA and RouterB are reachable.
2. Configure ACLs to define data flows to be protected.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IKE peers to define IKE negotiation attributes.
5. Configure IPSec policies and reference ACLs and IPSec proposals in the IPSec policies
to determine the methods used to protect data flows.
6. Apply IPSec policy groups to interfaces. Configure a multi-link shared IPSec policy
group on RouterA so that the IPSec policy group can be shared by multiple interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 70.1.1.1 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 80.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
[RouterA] interface gigabitethernet 3/0/0
[RouterA-GigabitEthernet3/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet3/0/0] quit
[RouterA] interface loopback 0
[RouterA-LoopBack0] ip address 1.1.1.1 255.255.255.255
[RouterA-LoopBack0] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
addresses corresponding to the two outbound interfaces in the route to RouterB are 70.1.1.2
and 80.1.1.2.
[RouterA] ip route-static 10.1.2.0 255.255.255.0 70.1.1.2 preference 10
[RouterA] ip route-static 10.1.2.0 255.255.255.0 80.1.1.2 preference 20
[RouterA] ip route-static 60.1.1.0 255.255.255.0 70.1.1.2 preference 10
[RouterA] ip route-static 60.1.1.0 255.255.255.0 80.1.1.2 preference 20
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 60.1.1.2.
Step 2 Configure ACLs on RouterA and RouterB to define data flows to be protected.
# Configure an ACL on RouterA to define data flows sent from 10.1.1.0/24 to 10.1.2.0/24.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[RouterA-acl-adv-3101] quit
# Configure an ACL on RouterB to define data flows sent from 10.1.2.0/24 to 10.1.1.0/24.
[RouterB] acl number 3101
[RouterB-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[RouterB-acl-adv-3101] quit
# Configure an IKE peer on RouterB, reference the IKE proposal, and set the pre-shared key
and remote ID.
# Configure a multi-link shared IPSec policy group on RouterA and apply the IPSec policy
group to the two interfaces.
[RouterA] ipsec policy policy1 shared local-interface loopback 0
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ipsec policy policy1
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ipsec policy policy1
[RouterA-GigabitEthernet2/0/0] quit
# After the configurations are complete, PC A can ping PC B successfully. Data exchanged
between PC A and PC B is encrypted. You can run the display ipsec statistics command to
view packet statistics.
# Run the display ike sa command on RouterA. The following information is displayed:
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
937 60.1.1.1:500 RD|ST v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD|ST v1:1 IP 60.1.1.1
Number of IKE SA : 2
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3101
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal prop
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 60.1.1.1
#
ipsec policy policy1 10 isakmp
security acl 3101
ike-peer rut
proposal prop
#
ipsec policy policy1 shared local-interface LoopBack0
#
interface GigabitEthernet1/0/0
ip address 70.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet2/0/0
ip address 80.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet3/0/0
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ip route-static 10.1.2.0 255.255.255.0 70.1.1.2 preference 10
ip route-static 10.1.2.0 255.255.255.0 80.1.1.2 preference 20
ip route-static 60.1.1.0 255.255.255.0 70.1.1.2 preference 10
ip route-static 60.1.1.0 255.255.255.0 80.1.1.2 preference 20
#
return
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut
undo version 2
pre-shared-key cipher %^%#K{JG:rWVHPMnf;5\|,GW(Luq'qi8BT4nOj%5W5=)%^%#
ike-proposal 5
remote-address 1.1.1.1
#
ipsec policy policy1 10 isakmp
security acl 3101
ike-peer rut
proposal prop
#
interface GigabitEthernet1/0/0
ip address 60.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet3/0/0
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.1 255.255.255.255 60.1.1.2
ip route-static 10.1.1.0 255.255.255.0 60.1.1.2
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
ip route-static 80.1.1.0 255.255.255.0 60.1.1.2
#
return
Figure 4-43 Establishing an IPSec tunnel between the enterprise headquarters and branch
through PPPoE
PPPoE_Server
PPPoE_Client
GE1/0/0
RouterA GE1/0/0 6.6.6.6/24 RouterB
Branch gateway Headquarters gateway
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Headquarters
Branch subnet
subnet
If both the branch gateway and headquarters gateway connect to the public network through PPPoE, the
remote-address host-name host-name command must be run on them to specify the domain name for
IPSec negotiation. Otherwise, the IPSec tunnel cannot be established.
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from
the PPPoE server.
2. Configure the IKE negotiation mode in which an IPSec tunnel is set up. RouterB
functions as the responder to receive IPSec negotiation requests initiated by RouterA.
Procedure
Step 1 Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from the
PPPoE server.
# Configure a dialer access group to permit all IPv4 packets to pass through.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] dialer-rule
[RouterA-dialer-rule] dialer-rule 1 ip permit
[RouterA-dialer-rule] quit
# Bind the dialer interface to a physical interface and establish a PPPoE session.
[RouterA] interface gigabitethernet1/0/0
[RouterA-GigabitEthernet1/0/0] pppoe-client dial-bundle-number 1
[RouterA-GigabitEthernet1/0/0] quit
# Configure LAN users to dial up using public network addresses translated through NAT.
[RouterA] acl number 3002
[RouterA-acl-adv-3002] rule 5 permit ip source 10.1.1.0 0.0.0.255
[RouterA-acl-adv-3002] quit
[RouterA] interface dialer 1
[RouterA-Dialer1] nat outbound 3002
[RouterA-Dialer1] quit
# On RouterA, configure a static route to PC B. The route uses the IP address of the dialer
interface as the next hop address.
[RouterA] ip route-static 6.6.6.0 24 dialer1
[RouterA] ip route-static 10.1.2.0 24 dialer1
Step 2 On RouterA, set parameters for establishing an IPSec tunnel in IKE negotiation mode.
# Configure an ACL to control data flows from the branch subnet 10.1.1.0/24 to the
headquarters subnet 10.1.2.0/24. Assume that the NAT-translated branch subnet address is
1.1.1.0/24 (that is, public network address obtained through PPPoE dial-up).
[RouterA] acl number 3003
[RouterA-acl-adv-3003] rule permit ip source 1.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[RouterA-acl-adv-3003] quit
Run the display ipsec policy command to view the IPSec policy configuration.
# Apply the IPSec policy group to the dialer interface.
[RouterA] interface dialer 1
[RouterA-Dialer1] ipsec policy policy1
[RouterA-Dialer1] quit
Step 3 On RouterB used as the responder, set parameters for establishing an IPSec tunnel in IKE
negotiation mode.
# Configure an IP address for an interface and a static route to the peer.
<Huawei> system-view
[Huawei] sysname RouterB
[RouterB] interface gigabitethernet 1/0/0
[RouterB-GigabitEthernet1/0/0] ip address 6.6.6.6 255.255.255.0
[RouterB-GigabitEthernet1/0/0] quit
[RouterB] interface gigabitethernet 2/0/0
[RouterB-GigabitEthernet2/0/0] ip address 10.1.2.1 255.255.255.0
[RouterB-GigabitEthernet2/0/0] quit
# Configure a static route to the peer. This example assumes that the next hop address in the
route is 6.6.6.254.
[RouterB] ip route-static 0.0.0.0 0.0.0.0 6.6.6.254
Run the display ipsec policy-template command to view the IPSec policy template
configuration.
# Reference the IPSec policy template in the IPSec policy.
[RouterB] ipsec policy policy1 10 isakmp template temp1
Number of IKE SA : 2
-------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 10.1.1.0 0.0.0.255
acl number 3003
rule 5 permit ip source 1.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal prop1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 6.6.6.6
#
ipsec policy policy1 10 isakmp
security acl 3003
ike-peer rut1
proposal prop1
#
interface Dialer1
link-protocol ppp
ppp chap user [email protected]
ppp chap password cipher %@%@^_PfANXK0(,Jr-(3p]"R,eOL%@%@
ip address ppp-negotiate
The enterprise wants to protect traffic exchanged between RouterA and RouterB.
GE2/0/0 GE2/0/0
10.1.0.1/24 10.2.0.1/24
IPSec Tunnel
PC A PC B
10.1.0.2/24 10.2.0.2/24
Configuration Roadmap
RouterA and RouterB communicate through the NAT gateway, so NAT traversal must be
enabled for establishing an IPSec tunnel. The configuration roadmap is as follows:
1. Configure IP addresses and static routes for interfaces on RouterA and RouterB so that
routes between RouterA and RouterB are reachable.
2. Configure an ACL on RouterA to define data flows to be protected.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IKE peers to define IKE negotiation attributes.
5. Configure IPSec policies on RouterA and RouterB. RouterB uses an IPSec policy
template to create an IPSec policy.
6. Apply IPSec policy groups to interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 192.168.0.2 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.0.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterB is 192.168.0.1.
[RouterA] ip route-static 0.0.0.0 0.0.0.0 192.168.0.1
<Huawei> system-view
[Huawei] sysname RouterB
[RouterB] interface gigabitethernet 1/0/0
[RouterB-GigabitEthernet1/0/0] ip address 1.2.0.1 255.255.255.0
[RouterB-GigabitEthernet1/0/0] quit
[RouterB] interface gigabitethernet 2/0/0
[RouterB-GigabitEthernet2/0/0] ip address 10.2.0.1 255.255.255.0
[RouterB-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 1.2.0.2.
[RouterB] ip route-static 10.1.0.0 255.255.255.0 1.2.0.2
[RouterB] ip route-static 192.168.0.0 255.255.255.0 1.2.0.2
Step 2 # Configure an ACL on RouterA to define data flows sent from 10.1.0.0/24 to 10.2.0.0/24.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule permit ip source 10.1.0.0 0.0.0.255 destination
10.2.0.0 0.0.0.255
[RouterA-acl-adv-3101] quit
Run the display ipsec policy command on RouterA and RouterB to view the configurations
of the IPSec policies.
Step 7 Apply IPSec policy groups to interfaces on RouterA and RouterB.
# Apply the IPSec policy group to the interface of RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ipsec policy policy1
[RouterA-GigabitEthernet1/0/0] quit
Number of IKE SA : 2
---------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
ike local-name rta
#
acl number 3101
rule 5 permit ip source 10.1.0.0 0.0.0.255 destination 10.2.0.0 0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rta
undo version 2
exchange-mode aggressive
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
local-id-type fqdn
remote-id rtb
remote-address 1.2.0.1
#
ipsec policy policy1 10 isakmp
security acl 3101
ike-peer rta
proposal tran1
#
interface GigabitEthernet1/0/0
ip address 192.168.0.2 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet2/0/0
ip address 10.1.0.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 192.168.0.1
#
return
Figure 4-45 Establishing an IPSec tunnel in IKE negotiation mode by specifying DNs
CA Server
70.1.1.7
RouterA RouterB
GE1/0/0 GE1/0/0
GE2/0/0 60.1.1.1/24 60.1.2.1/24 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Branch Headquarters
Subnet Subnet
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses and static routes for interfaces on RouterA and RouterB so that
routes between RouterA and RouterB are reachable.
2. Apply for digital certificates from the CA server. The digital certificates are used for
RSA signature authentication.
3. Configure ACLs to define data flows to be protected.
4. Configure IPSec proposals to define the method used to protect IPSec traffic.
5. Configure IKE peers to define IKE negotiation attributes.
6. Configure IPSec policies and reference ACLs, IPSec proposals, and IKE peers in the
IPSec policies to define protection methods for data flows between RouterA and
RouterB.
7. Apply IPSec policy groups to interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterB is 60.1.1.2.
[RouterA] ip route-static 60.1.2.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 60.1.2.2.
[RouterB] ip route-static 60.1.1.0 255.255.255.0 60.1.2.2
[RouterB] ip route-static 10.1.1.0 255.255.255.0 60.1.2.2
Step 2 Configure ACLs on RouterA and RouterB to define data flows to be protected.
# Configure an ACL on RouterA to define data flows sent from 10.1.1.0/24 to 10.1.2.0/24.
[RouterA] acl number 3001
[RouterA-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[RouterA-acl-adv-3001] quit
# Configure an ACL on RouterB to define data flows sent from 10.1.2.0/24 to 10.1.1.0/24.
[RouterB] acl number 3001
[RouterB-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[RouterB-acl-adv-3001] quit
Step 3 Configure PKI entities and PKI domains on RouterA and RouterB, which are used to apply
for digital certificates from the CA server.
Before obtaining and installing a local certificate, the device obtains and installs a CA
certificate first. The CA and local certificates are named rta_ca.cer and rta_local.cer.
Before obtaining and installing a local certificate, the device obtains and installs a CA
certificate first. The CA and local certificates are named rtb_ca.cer and rtb_local.cer.
Number of IKE SA : 2
---------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
pki entity rta
country CN
state jiangsu
locality nanjing
organization huawei
organization-unit VPN
common-name ipsec
#
pki realm rta
ca id ca_root
enrollment-url http://70.1.1.7:8080/certsrv/mscep/mscep.dll times 4 ra
entity rta
fingerprint sha256
e71add0744360e91186b828412d279e06dcc15a4ab4bb3d13842820396b526a0
rsa local-key-pair
rsa_scep
password cipher %$%$\1HN-bn(k;^|O85OAtYF3(M4%$%
$
auto-enroll 60 regenerate
#
acl number 3001
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal prop
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method rsa-signature
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rta
undo version 2
ike-proposal 5
local-id-type dn
remote-address 60.1.2.1
pki realm rta
#
ipsec policy policy1 10 isakmp
security acl 3001
ike-peer rta
proposal prop
#
interface GigabitEthernet1/0/0
ip address 60.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet2/0/0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 60.1.2.0 255.255.255.0 60.1.1.2
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
#
return
Figure 4-46 Establishing an IPSec tunnel through negotiation initiated by the branch user that
dynamically obtains an IP address
PPPoE_Server
PPPoE_Client
GE1/0/0
RouterA GE1/0/0 6.6.6.6/24 RouterB
Branch gateway Headquarter gateway
GE2/0/0 GE2/0/0
10.1.2.1/24
IPSec Tunnel
PC B
PC A
10.1.2.2/24
Branch subnet
Headquarters subnet
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from
the PPPoE server.
2. Enable DHCP on RouterA so that IP addresses can be dynamically allocated through
DHCP.
3. Configure the IKE negotiation mode in which an IPSec tunnel is set up. RouterB
functions as the responder to receive IPSec negotiation requests initiated by RouterA.
Procedure
Step 1 Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from the
PPPoE server.
# Configure a dialer access group to permit all IPv4 packets to pass through.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] dialer-rule
[RouterA-dialer-rule] dialer-rule 1 ip permit
[RouterA-dialer-rule] quit
# Bind the dialer interface to a physical interface and establish a PPPoE session.
# On RouterA, configure a static route to PC B. The route uses the IP address of Dialer1 as
the next hop address.
[RouterA] ip route-static 6.6.6.0 24 dialer1
[RouterA] ip route-static 10.1.2.0 24 dialer1
Step 2 Enable DHCP on RouterA so that IP addresses can be dynamically allocated through DHCP.
# Enable DHCP and configure a global address pool.
[RouterA] dhcp enable
[RouterA] ip pool pooltest
[RouterA-ip-pool-pooltest] network 10.1.1.0 mask 255.255.255.0
[RouterA-ip-pool-pooltest] quit
Step 3 On RouterA, set parameters for establishing an IPSec tunnel in IKE negotiation mode.
# Configure an ACL to define data flows destined for 10.1.2.0/24.
[RouterA] acl number 3003
[RouterA-acl-adv-3003] rule permit ip destination 10.1.2.0 0.0.0.255
[RouterA-acl-adv-3003] quit
Step 4 On RouterB used as the responder, set parameters for establishing an IPSec tunnel in IKE
negotiation mode.
# Configure a static route to peer. This example assumes that the next hop address in the route
is 6.6.6.1.
[RouterB] ip route-static 10.1.1.0 255.255.255.0 6.6.6.1
Because RouterB as the responder uses an IPSec policy template to configure an IPSec policy,
so you do not need to specify the remote IP address for the IKE peer.
[RouterB] ike peer rut1
[RouterB-ike-peer-rut1] undo version 2
[RouterB-ike-peer-rut1] pre-shared-key cipher Huawei@1234
[RouterB-ike-peer-rut1] ike-proposal 5
[RouterB-ike-peer-rut1] quit
# After the configurations are complete, PC A can ping PC B successfully. Data exchanged
between PC A and PC B is encrypted. You can run the display ipsec statistics command to
view packet statistics.
# Run the display ike sa command on RouterA. The following information is displayed:
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
-------------------------------------------------------------------------
246 6.6.6.6:500 RD|ST v1:2 IP 6.6.6.6
245 6.6.6.6:500 RD|ST v1:1 IP 6.6.6.6
Number of IKE SA : 2
-------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3003
rule 5 permit ip destination 10.1.2.0 0.0.0.255
#
ipsec proposal prop1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 6.6.6.6
#
ipsec policy policy1 10 isakmp
security acl 3003 dynamic-source
ike-peer rut1
proposal prop1
#
interface Dialer1
link-protocol ppp
ppp chap user [email protected]
ppp chap password cipher %@%@^_PfANXK0(,Jr-(3p]"R,eOL%@%@
policy policy1
#
interface GigabitEthernet1/0/0
pppoe-client dial-bundle-number 1
#
interface GigabitEthernet2/0/0
dhcp select global
#
dialer-rule
dialer-rule 1 ip permit
#
ip route-static 6.6.6.0 255.255.255.0 dialer1
ip route-static 10.1.2.0 255.255.255.0 Dialer1
#
return
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
Branch gateway Headquarters gateway
GE2/0/0 Tunnel0/0/0 Tunnel0/0/0 GE2/0/0
10.1.1.1/24 192.168.1.1/24 192.168.1.2/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Headquarters
Branch subnet
subnet
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses and static routes for interfaces on RouterA and RouterB so that
routes between RouterA and RouterB are reachable.
2. Configure IPSec proposals to define the method used to protect IPSec traffic.
3. Configure IKE peers to define IKE negotiation attributes.
4. Configure IPSec profiles and reference IPSec proposals and IKE peers in the IPSec
profiles to determine the methods used to protect data flows.
5. Apply IPSec profiles to IPSec tunnel interfaces.
6. Configure static routes on IPSec tunnel interfaces and import data flows to be protected
by IPSec to the tunnel interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterB is 1.1.1.12.
[RouterA] ip route-static 2.1.1.0 255.255.255.0 1.1.1.12
[RouterB-GigabitEthernet1/0/0] quit
[RouterB] interface gigabitethernet 2/0/0
[RouterB-GigabitEthernet2/0/0] ip address 10.1.2.1 255.255.255.0
[RouterB-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 2.1.1.2.
[RouterB] ip route-static 1.1.1.10 255.255.255.0 2.1.1.2
Run the display ipsec proposal command on RouterA and RouterB to view the IPSec
proposal configuration.
Step 3 Configure IKE peers on RouterA and RouterB.
# Create an IKE proposal on RouterA.
[RouterA] ike proposal 5
[RouterA-ike-proposal-5] authentication-algorithm sha2-256
[RouterA-ike-proposal-5] encryption-algorithm aes-128
[RouterAike-proposal-5] dh group14
[RouterA-ike-proposal-5] quit
Step 5 Apply the IPSec profiles to IPSec tunnel interfaces on RouterA and RouterB.
Run the display ipsec profile command on RouterA and RouterB to view the IPSec profile
configuration.
Step 6 Configure static routes on IPSec tunnel interfaces and import data flows to be protected by
IPSec to the tunnel interfaces.
# After the configurations are complete, run the display ike sa command on RouterA and
RouterB to view the IKE SA configuration. The display on RouterA is used as an example.
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
Number of IKE SA : 2
--------------------------------------------------------------------------------
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer spub
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
#
ipsec profile profile1
ike-peer spub
proposal tran1
#
interface Tunnel0/0/0
ip address 192.168.1.1 255.255.255.0
tunnel-protocol ipsec
source 1.1.1.1
destination 2.1.1.1
ipsec profile profile1
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.12
ip route-static 10.1.2.0 255.255.255.0 tunnel0/0/0
#
return
#
interface Tunnel0/0/0
ip address 192.168.1.2 255.255.255.0
tunnel-protocol ipsec
source 2.1.1.1
destination 1.1.1.1
ipsec profile profile1
#
interface GigabitEthernet1/0/0
ip address 2.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.10 255.255.255.0 2.1.1.2
ip route-static 10.1.1.0 255.255.255.0 tunnel0/0/0
#
return
Networking Requirements
As shown in Figure 4-48, RouterA (branch gateway) and RouterB (headquarters gateway)
communicate through the Internet.
The enterprise wants to protect traffic including multicast data between the headquarters and
branch. As IPSec cannot be applied to multicast data directly, GRE over IPSec can be
established between virtual tunnel interfaces to protect traffic on tunnel interfaces.
Figure 4-48 Establishing GRE over IPSec tunnel using a tunnel interface
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
Branch gateway Headquarters gateway
GE2/0/0 Tunnel0/0/0 Tunnel0/0/0 GE2/0/0
10.1.1.1/24 192.168.1.1/24 192.168.1.2/24 10.1.2.1/24
PC A PC B
10.1.1.2/24 10.1.2.2/24
Branch subnet Headquarters subnet
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses and static routes for physical interfaces on RouterA and RouterB
so that routes between RouterA and RouterB are reachable.
2. Configure a GRE tunnel interface.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
Procedure
Step 1 Configure IP addresses and static routes for physical interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterB is 1.1.1.2.
[RouterA] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 2.1.1.2.
[RouterB] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
# Configure RouterB.
[RouterB] interface tunnel 0/0/0
[RouterB-Tunnel0/0/0] ip address 192.168.1.2 255.255.255.0
[RouterB-Tunnel0/0/0] tunnel-protocol gre
[RouterB-Tunnel0/0/0] source 2.1.1.1
[RouterB-Tunnel0/0/0] destination 1.1.1.1
[RouterB-Tunnel0/0/0] quit
Step 6 Apply the IPSec profiles to IPSec tunnel interfaces on RouterA and RouterB.
# Apply the IPSec profile to the interface of RouterA.
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1
[RouterA-Tunnel0/0/0] quit
Run the display ipsec profile command on RouterA and RouterB to view the IPSec profile
configuration.
Step 7 Configure static routes on IPSec tunnel interfaces and import data flows to be protected by
IPSec to the tunnel interfaces.
# Configure a static route on the tunnel interface of RouterA.
[RouterA] ip route-static 10.1.2.0 255.255.255.0 tunnel 0/0/0
Number of IKE SA : 2
--------------------------------------------------------------------------------
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer spub
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
#
ipsec profile profile1
ike-peer spub
proposal tran1
#
interface Tunnel0/0/0
ip address 192.168.1.1 255.255.255.0
tunnel-protocol gre
source 1.1.1.1
destination 2.1.1.1
ipsec profile profile1
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
ip route-static 10.1.2.0 255.255.255.0 tunnel0/0/0
#
return
Figure 4-49 Establishing IPSec over GRE tunnel using a tunnel interface
Branch Headquarters
gateway GE1/0/0 gateway
GE1/0/0
Router_1 1.1.1.1/24 2.1.1.1/24 Router_2
Tunnel0/0/0 Tunnel0/0/0
GE2/0/0 GE2/0/0
192.168.1.1/24 192.168.1.2/24
10.1.1.1/24 10.1.2.1/24
IPSec over GRE
Tunnel0/0/1 Tunnel0/0/1
192.168.2.1/24 192.168.2.2/24
PC_1 PC_2
10.1.1.2/24 10.1.2.2/24
Branch Headquarters
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses and static routes for physical interfaces on Router_1 and
Router_2 so that routes between Router_1 and Router_2 are reachable.
2. Configure a GRE tunnel interface.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IKE peers to define IKE negotiation attributes.
5. Configure IPSec profiles and reference IPSec policies and IKE peers in the IPSec
profiles.
6. Configure IPSec tunnel interfaces and specify a GRE tunnel interface as the source
interface of the IPSec tunnel and the other GRE tunnel interface as the outbound
interface for routes to the destination address of the IPSec tunnel.
7. Apply IPSec profiles to the IPSec tunnel interfaces to enable IPSec on the interfaces.
8. Configure static routes for the IPSec tunnel interfaces to import data flows to be
protected by IPSec to the interfaces.
Procedure
Step 1 Configure IP addresses and static routes for physical interfaces on Router_1 and Router_2.
# Assign an IP address to an interface on Router_1.
<Huawei> system-view
[Huawei] sysname Router_1
[Router_1] interface gigabitethernet 1/0/0
[Router_1-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[Router_1-GigabitEthernet1/0/0] quit
[Router_1] interface gigabitethernet 2/0/0
[Router_1-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[Router_1-GigabitEthernet2/0/0] quit
# Configure a static route to the peer on Router_1. This example assumes that the next hop
address in the route to Router_2 is 1.1.1.2.
[Router_1] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
# Configure a static route to the peer on Router_2. This example assumes that the next hop
address in the route to Router_1 is 2.1.1.2.
[Router_2] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
# Configure Router_2.
[Router_2] interface tunnel 0/0/0
[Router_2-Tunnel0/0/0] ip address 192.168.1.2 255.255.255.0
[Router_2-Tunnel0/0/0] tunnel-protocol gre
[Router_2-Tunnel0/0/0] source 2.1.1.1
[Router_2-Tunnel0/0/0] destination 1.1.1.1
[Router_2-Tunnel0/0/0] quit
Step 6 Configure an IPSec tunnel interface on Router_1 and Router_2 respectively. Specify a GRE
tunnel interface as the source interface of the IPSec tunnel and the other GRE tunnel interface
as the outbound interface for routes to the destination address of the IPSec tunnel.
# Configure Router_1.
[Router_1] interface tunnel 0/0/1
[Router_1-Tunnel0/0/1] ip address 192.168.2.1 255.255.255.0
[Router_1-Tunnel0/0/1] tunnel-protocol ipsec
[Router_1-Tunnel0/0/1] source tunnel 0/0/0
[Router_1-Tunnel0/0/1] destination 192.168.1.2
[Router_1-Tunnel0/0/1] quit
# Configure Router_2.
[Router_2] interface tunnel 0/0/1
[Router_2-Tunnel0/0/1] ip address 192.168.2.2 255.255.255.0
Run the display ipsec profile command on Router_1 and Router_2 to view the IPSec profile
configuration.
Step 8 Configure static routes on IPSec tunnel interfaces and import data flows to be protected by
IPSec to the tunnel interfaces.
# Configure a static route on the tunnel interface of Router_1.
[Router_1] ip route-static 10.1.2.0 255.255.255.0 tunnel 0/0/1
Number of IKE SA : 2
--------------------------------------------------------------------------------
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
----End
Configuration Files
l Configuration file of Router_1
#
sysname Router_1
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer spub
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
#
ipsec profile profile1
ike-peer spub
proposal tran1
#
interface Tunnel0/0/0
ip address 192.168.1.1 255.255.255.0
tunnel-protocol gre
source 1.1.1.1
destination 2.1.1.1
#
interface Tunnel0/0/1
ip address 192.168.2.1 255.255.255.0
tunnel-protocol ipsec
source Tunnel0/0/0
destination 192.168.1.2
ipsec profile profile1
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.1.2.0 255.255.255.0 tunnel0/0/1
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
#
return
l Configuration file of Router_2
#
sysname Router_2
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer spua
undo version 2
pre-shared-key cipher %^%#K{JG:rWVHPMnf;5\|,GW(Luq'qi8BT4nOj%5W5=)%^%#
ike-proposal 5
#
ipsec profile profile1
ike-peer spua
proposal tran1
#
interface Tunnel0/0/0
ip address 192.168.1.2 255.255.255.0
tunnel-protocol gre
source 2.1.1.1
destination 1.1.1.1
#
interface Tunnel0/0/1
ip address 192.168.2.2 255.255.255.0
tunnel-protocol ipsec
source Tunnel0/0/0
destination 192.168.1.1
ipsec profile profile1
#
interface GigabitEthernet1/0/0
ip address 2.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 tunnel0/0/1
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
#
return
Networking Requirements
In Figure 4-50, Router1 is the gateway of an enterprise branch, and Router2 is the gateway of
the headquarters. Router1 and Router2 communicate through the public network.
On the live network, the enterprise branch communicates with the headquarters through a
GRE tunnel. The enterprise wants to protect traffic excluding multicast data between the
headquarters and branch. An IPSec over GRE tunnel can be established based on ACL to
protect traffic between the headquarters and branch.
Figure 4-50 Establishing an IPSec over GRE tunnel between the headquarters and branch
Branch gateway Headquarters
Router1 GE1/0/0 GE1/0/0 gateway
1.1.1.1/24 2.1.1.1/24 Router2
Tunnel0/0/0 Tunnel0/0/0
GE2/0/0 GE2/0/0
10.2.1.1/24 10.2.1.2/24
10.1.1.1/24 10.1.2.1/24
IPSec over GRE
PC1 PC2
10.1.1.2/24 10.1.2.2/24
Branch Headquarters
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure the IP address and static route on each physical interface to ensure reachable
routes between the interfaces.
Procedure
Step 1 Configure an IP address and a static route for each physical interface on the routers.
# Configure Router1.
<Huawei> system-view
[Huawei] sysname Router1
[Router1] interface gigabitethernet 1/0/0
[Router1-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[Router1-GigabitEthernet1/0/0] quit
[Router1] interface gigabitethernet 2/0/0
[Router1-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[Router1-GigabitEthernet2/0/0] quit
# Configure a static route to the remote end on Router1. This example assumes that the next
hop address of the route is 1.1.1.2.
[Router1] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
# Configure Router2.
<Huawei> system-view
[Huawei] sysname Router2
[Router2] interface gigabitethernet 1/0/0
[Router2-GigabitEthernet1/0/0] ip address 2.1.1.1 255.255.255.0
[Router2-GigabitEthernet1/0/0] quit
[Router2] interface gigabitethernet 2/0/0
[Router2-GigabitEthernet2/0/0] ip address 10.1.2.1 255.255.255.0
[Router2-GigabitEthernet2/0/0] quit
# Configure a static route to the remote end on Router2. This example assumes that the next
hop address of the route is 2.1.1.2.
[Router2] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
# Configure Router2.
[Router2] interface tunnel 0/0/0
[Router2-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[Router2-Tunnel0/0/0] tunnel-protocol gre
[Router2-Tunnel0/0/0] source 2.1.1.1
Step 3 Configure static routes for tunnel interfaces so that data flows are imported to the tunnel
interfaces.
# Configure Router1.
[Router1] ip route-static 10.1.2.0 255.255.255.0 tunnel 0/0/0
# Configure Router2.
[Router2] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/0
After the configuration is complete, run the display tunnel-info all command on the routers
to view GRE tunnel establishment information. The command output on Router1 is used as an
example.
[Router1] display tunnel-info all
* -> Allocated VC Token
Tunnel ID Type Destination Token
----------------------------------------------------------------------
0x1 gre 2.1.1.1 1
Step 4 Create an ACL on the routers to define the data flows to be protected.
# Configure Router1.
[Router1] acl number 3101
[Router1-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[Router1-acl-adv-3101] quit
# Configure Router2.
[Router2] acl number 3101
[Router2-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[Router2-acl-adv-3101] quit
# Configure Router2.
[Router2] ipsec proposal tran1
[Router2-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[Router2-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[Router2-ipsec-proposal-tran1] quit
# Configure Router2.
[Router2] ike proposal 5
[Router2-ike-proposal-5] authentication-algorithm sha2-256
[Router2-ike-proposal-5] encryption-algorithm aes-128
[Router2-ike-proposal-5] dh group14
[Router2-ike-proposal-5] quit
[Router2] ike peer spua
[Router2-ike-peer-spua] undo version 2
[Router2-ike-peer-spua] ike-proposal 5
[Router2-ike-peer-spua] pre-shared-key cipher Huawei@1234
[Router2-ike-peer-spua] remote-address 10.2.1.1
[Router2-ike-peer-spua] quit
# Configure Router1.
[Router1] ipsec policy map1 10 isakmp
[Router1-ipsec-policy-isakmp-map1-10] proposal tran1
[Router1-ipsec-policy-isakmp-map1-10] ike-peer spub
[Router1-ipsec-policy-isakmp-map1-10] security acl 3101
[Router1-ipsec-policy-isakmp-map1-10] quit
# Configure Router2.
[Router2] ipsec policy use1 10 isakmp
[Router2-ipsec-policy-isakmp-use1-10] proposal tran1
[Router2-ipsec-policy-isakmp-use1-10] ike-peer spua
[Router2-ipsec-policy-isakmp-use1-10] security acl 3101
[Router2-ipsec-policy-isakmp-use1-10] quit
# Configure Router1.
[Router1] interface tunnel 0/0/0
[Router1-Tunnel0/0/0] ipsec policy map1
[Router1-Tunnel0/0/0] quit
# Configure Router2.
[Router2] interface tunnel 0/0/0
[Router2-Tunnel0/0/0] ipsec policy use1
[Router2-Tunnel0/0/0] quit
# After the configuration is complete, run the display ike sa command on the routers to view
the SA establishment information. The command output on Router1 is used as an example.
[Router1] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
------------------------------------------------------------------------------
20 10.2.1.2:500 RD|A v1:2 IP 10.2.1.2
19 10.2.1.2:500 RD|A v1:1 IP 10.2.1.2
Number of IKE SA : 2
------------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
After an SA is successfully established, data transmitted between the headquarters and branch
is encrypted.
----End
Configuration Files
l Router1 configuration file
#
sysname Router1
#
acl number 3101
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
#
ike peer spub
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
remote-address 10.2.1.2
#
ipsec policy map1 10 isakmp
security acl 3101
ike-peer spub
proposal tran1
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.1.1 255.255.255.0
#
interface Tunnel0/0/0
ip address 10.2.1.1 255.255.255.0
tunnel-protocol gre
source 1.1.1.1
destination 2.1.1.1
ipsec policy map1
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/0
#
return
Figure 4-51 Establishing IPSec over DSVPN tunnels between Hub and Spokes
Tunnel0/0/0
Branch 1 10.2.1.2/24
GE1/0/0
GE1/0/1 1.1.2.10/24
10.1.2.1/24
Spoke1
GE1/0/1
10.1.1.1/24
GE1/0/0
1.1.1.10/24
Headquarters
Tunnel0/0/0
10.2.1.1/24
Hub
Spoke2
GE1/0/1
10.1.3.1/24 GE1/0/0
1.1.3.10/24
Tunnel0/0/0
Branch 2
10.2.1.3/24
Assume that the dynamic addresses obtained by Spoke1 and Spoke2 are 1.1.2.10 and 1.1.3.10,
respectively.
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure DSVPN to implement VPN interconnection between the Spokes because the
Spokes connect to the public network using dynamic IP addresses and the Spokes do not
know the public IP addresses of each other.
2. Deploy DSVPN in shortcut mode because there are a large number of Spokes.
3. Configure OSPF to simplify maintenance because subnets of the Hub and Spokes
frequently change.
4. Configure IPSec over DSVPN to encrypt data transmitted between the Hub and Spokes
using IPSec before transmitting the data using DSVPN.
Procedure
Step 1 Configure IP addresses for interfaces.
# Configure Spoke1.
<Huawei> system-view
[Huawei] sysname Spoke1
[Spoke1] interface gigabitethernet 1/0/0
[Spoke1-GigabitEthernet1/0/0] ip address dhcp-alloc
[Spoke1-GigabitEthernet1/0/0] quit
[Spoke1] interface gigabitethernet 1/0/1
[Spoke1-GigabitEthernet1/0/1] ip address 10.1.2.1 255.255.255.0
[Spoke1-GigabitEthernet1/0/1] quit
[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[Spoke1-Tunnel0/0/0] quit
# Configure Spoke2.
<Huawei> system-view
[Huawei] sysname Spoke2
[Spoke2] interface gigabitethernet 1/0/0
[Spoke2-GigabitEthernet1/0/0] ip address dhcp-alloc
[Spoke2-GigabitEthernet1/0/0] quit
[Spoke2] interface gigabitethernet 1/0/1
[Spoke2-GigabitEthernet1/0/1] ip address 10.1.3.1 255.255.255.0
[Spoke2-GigabitEthernet1/0/1] quit
[Spoke2] interface tunnel 0/0/0
[Spoke2-Tunnel0/0/0] ip address 10.2.1.3 255.255.255.0
[Spoke2-Tunnel0/0/0] quit
Step 2 Configure OSPF to ensure reachable routes over the public network.
# Configure Spoke1.
[Spoke1] ospf 2
[Spoke1-ospf-2] area 0.0.0.1
[Spoke1-ospf-2-area-0.0.0.1] network 1.1.2.0 0.0.0.255
[Spoke1-ospf-2-area-0.0.0.1] quit
[Spoke1-ospf-2] quit
# Configure Spoke2.
[Spoke2] ospf 2
[Spoke2-ospf-2] area 0.0.0.1
[Spoke2-ospf-2-area-0.0.0.1] network 1.1.3.0 0.0.0.255
[Spoke2-ospf-2-area-0.0.0.1] quit
[Spoke2-ospf-2] quit
# Configure Spoke1.
# Configure Spoke2.
[Spoke2] ospf 1 router-id 10.2.1.3
[Spoke2-ospf-1] area 0.0.0.0
[Spoke2-ospf-1-area-0.0.0.0] network 10.1.3.0 0.0.0.255
[Spoke2-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[Spoke2-ospf-1-area-0.0.0.0] quit
[Spoke2-ospf-1] quit
# Configure Spoke1.
[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/0] source gigabitethernet 1/0/0
[Spoke1-Tunnel0/0/0] nhrp entry 10.2.1.1 1.1.1.10 register
[Spoke1-Tunnel0/0/0] ospf network-type p2mp
[Spoke1-Tunnel0/0/0] quit
# Configure Spoke2.
[Spoke2] interface tunnel 0/0/0
[Spoke2-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke2-Tunnel0/0/0] source gigabitethernet 1/0/0
[Spoke2-Tunnel0/0/0] nhrp entry 10.2.1.1 1.1.1.10 register
[Spoke2-Tunnel0/0/0] ospf network-type p2mp
[Spoke2-Tunnel0/0/0] quit
# Configure Spoke2.
[Spoke2] acl number 3101
[Spoke2-acl-adv-3101] rule permit ip source 10.1.3.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[Spoke2-acl-adv-3101] rule permit ip source 10.1.3.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[Spoke2-acl-adv-3101] quit
# Configure Spoke1.
[Spoke1] ike proposal 1
[Spoke1-ike-proposal-1] dh group14
[Spoke1-ike-proposal-1] encryption-algorithm aes-256
[Spoke1-ike-proposal-1] authentication-algorithm sha2-256
[Spoke1-ike-proposal-1] prf aes-xcbc-128
[Spoke1-ike-proposal-1] quit
# Configure Spoke2.
[Spoke2] ike proposal 1
[Spoke2-ike-proposal-1] dh group14
[Spoke2-ike-proposal-1] encryption-algorithm aes-256
[Spoke2-ike-proposal-1] authentication-algorithm sha2-256
[Spoke2-ike-proposal-1] prf aes-xcbc-128
[Spoke2-ike-proposal-1] quit
# Configure Spoke1.
[Spoke1] ike peer spoke1
[Spoke1-ike-peer-spoke1] undo version 2
[Spoke1-ike-peer-spoke1] ike-proposal 1
[Spoke1-ike-peer-spoke1] pre-shared-key cipher Huawei@1234
[Spoke1-ike-peer-spoke1] remote-address 10.2.1.1
[Spoke1-ike-peer-spoke1] dpd type periodic
[Spoke1-ike-peer-spoke1] dpd idle-time 40
[Spoke1-ike-peer-spoke1] quit
# Configure Spoke2.
[Spoke2] ike peer spoke2
[Spoke2-ike-peer-spoke2] undo version 2
[Spoke2-ike-peer-spoke2] ike-proposal 1
[Spoke2-ike-peer-spoke2] pre-shared-key cipher Huawei@1234
[Spoke2-ike-peer-spoke2] remote-address 10.2.1.1
[Spoke2-ike-peer-spoke2] dpd type periodic
[Spoke2-ike-peer-spoke2] dpd idle-time 40
[Spoke2-ike-peer-spoke2] quit
# Configure Spoke1.
[Spoke1] ipsec proposal pro1
[Spoke1-ipsec-proposal-pro1] transform esp
[Spoke1-ipsec-proposal-pro1] esp authentication-algorithm sha2-256
[Spoke1-ipsec-proposal-pro1] esp encryption-algorithm aes-256
[Spoke1-ipsec-proposal-pro1] quit
# Configure Spoke2.
[Spoke2] ipsec proposal pro1
[Spoke2-ipsec-proposal-pro1] transform esp
[Spoke2-ipsec-proposal-pro1] esp authentication-algorithm sha2-256
[Spoke2-ipsec-proposal-pro1] esp encryption-algorithm aes-256
[Spoke2-ipsec-proposal-pro1] quit
# Configure Spoke1.
[Spoke1] ipsec policy policy1 10 isakmp
[Spoke1-ipsec-policy-isakmp-policy1-10] ike-peer spoke1
[Spoke1-ipsec-policy-isakmp-policy1-10] proposal pro1
[Spoke1-ipsec-policy-isakmp-policy1-10] security acl 3101
[Spoke1-ipsec-policy-isakmp-policy1-10] quit
# Configure Spoke2.
[Spoke2] ipsec policy policy1 10 isakmp
[Spoke2-ipsec-policy-isakmp-policy1-10] ike-peer spoke2
[Spoke2-ipsec-policy-isakmp-policy1-10] proposal pro1
[Spoke2-ipsec-policy-isakmp-policy1-10] security acl 3101
[Spoke2-ipsec-policy-isakmp-policy1-10] quit
Step 10 Apply the security policy to the tunnel interfaces to enable IPSec protection.
# Configure the Hub.
[Hub] interface tunnel 0/0/0
[Hub-Tunnel0/0/0] ipsec policy policy1
[Hub-Tunnel0/0/0] quit
# Configure Spoke1.
[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] ipsec policy policy1
[Spoke1-Tunnel0/0/0] quit
# Configure Spoke2.
[Spoke2] interface tunnel 0/0/0
[Spoke2-Tunnel0/0/0] ipsec policy policy1
[Spoke2-Tunnel0/0/0] quit
Number of IKE SA : 2
------------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
The command output shows that an SA is successfully established between Spoke1 and the
Hub to encrypt data transmitted between them.
After pinging 10.1.3.1 from Spoke1, run the display ike sa command to view the SA
establishment information. The command output on Spoke1 is used as an example.
[Spoke1] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
------------------------------------------------------------------------------
22 10.2.1.3:500 RD|A v1:2 IP 10.2.1.3
21 10.2.1.3:500 RD|A v1:1 IP 10.2.1.3
20 10.2.1.1:500 RD|A v1:2 IP 10.2.1.1
19 10.2.1.1:500 RD|A v1:1 IP 10.2.1.1
Number of IKE SA : 2
------------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
The command output shows that an SA is successfully established between Spoke1 and
Spoke2 to encrypt data transmitted between them.
----End
Configuration Files
l Hub configuration file
#
sysname Hub
#
ipsec proposal pro1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal 1
encryption-algorithm
aes-256
dh
group14
authentication-algorithm sha2-256
prf aes-xcbc-128
#
ike peer hub
undo version 2
pre-shared-key cipher %^%#O3uIP\/YNF+`AcJhbZ&C7y*iVlOOU@DraF58J4=;%^%#
ike-proposal 1
dpd type periodic
dpd idle-time 40
#
ipsec policy-template use1 10
ike-peer hub
proposal pro1
#
Networking Requirements
As shown in Figure 4-52, the LAC is the enterprise branch gateway and the LNS is the
enterprise headquarters gateway. The LAC automatically dials up to establish L2TP
connections between the LNS for secure communication.
The enterprise requires that service packets transmitted over the L2TP tunnel be protected
from being intercepted and tampered. L2TP over IPSec can be configured to encrypt service
packets transmitted between the enterprise headquarters and branch.
Figure 4-52 Configuring L2TP over IPSec to implement secure communication between the
headquarters and branch
10.1.10.2/24
L2TP over IPSec PC2
VT1 10.1.2.2/24
10.1.1.1/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure the IP address and static route on each interface to implement communication
between interfaces.
2. Enable L2TP on the LAC. The PPP user sends a connection request to the LNS in the
headquarters through an L2TP tunnel. After the PPP user is authenticated, a tunnel is set
up.
3. On the LAC, configure a reachable route to the LNS and the enable the auto dial-up
function.
4. On the LNS, configure L2TP, create a PPP user, and configure a route to the public
network segment.
5. Configure an ACL to define the data flows to be protected by the IPSec tunnel.
6. Configure an IPSec proposal to define the traffic protection method.
7. Configure an IKE peer and define the attributes used for IKE negotiation.
8. Configure an IPSec policy, and apply the ACL, IPSec proposal, and IKE peers to the
IPSec policy to define the data flows to be protected and protection method.
9. Apply the IPSec policy group to an interface so that the interface can protect traffic.
Procedure
Step 1 Assign IP addresses to interfaces and configure a static route to the remote device.
# Configure a public network route on the LAC to implement a reachable route to the LNS. A
static route is used in this example, and the next-hop IP address is 1.1.2.2.
[LAC] ip route-static 1.1.1.1 255.255.255.0 1.1.2.2
# Configure a public network route on the LNS to implement a reachable route to the LAC. A
static route is used in this example, and the next-hop IP address is 1.1.1.2.
[LNS] ip route-static 1.1.2.1 255.255.255.0 1.1.1.2
# On the LAC, enable L2TP globally, create an L2TP group, and configure the user huawei to
establish an L2TP connection to the LNS.
[LAC] l2tp enable
[LAC] l2tp-group 1
[LAC-l2tp1] tunnel name lac
[LAC-l2tp1] start l2tp ip 1.1.1.1 fullusername huawei
# Enable tunnel authentication and set the tunnel password on the LAC.
[LAC-l2tp1] tunnel authentication
[LAC-l2tp1] tunnel password cipher huawei
[LAC-l2tp1] quit
# Configure the user name and password, PPP authentication, and IP address for the virtual
PPP user on the LAC.
[LAC] interface virtual-template 1
[LAC-Virtual-Template1] ppp chap user huawei
[LAC-Virtual-Template1] ppp chap password cipher Huawei@1234
[LAC-Virtual-Template1] ip address ppp-negotiate
[LAC-Virtual-Template1] quit
# Configure a private network route on the LAC, so users in the enterprise branch can
communicate with users in the headquarters.
[LAC] ip route-static 10.1.2.0 255.255.255.0 virtual-template 1
# Configure AAA authentication, user name huawei, and password Huawei@1234 on the
LNS.
[LNS] aaa
[LNS-aaa] local-user huawei password
Please configure the login password (8-128)
It is recommended that the password consist of at least 2 types of characters, i
ncluding lowercase letters, uppercase letters, numerals and special characters.
Please enter password:
Please confirm password:
Info: Add a new user.
Warning: The new user supports all access modes. The management user access mode
s such as Telnet, SSH, FTP, HTTP, and Terminal have security risks. You are advi
sed to configure the required access modes only.
[LNS-aaa] local-user huawei service-type ppp
[LNS-aaa] quit
# Configure an IP address pool for the LNS and assign an IP address to the dial-up interface
of the LAC.
[LNS] ip pool 1
[LNS-ip-pool-1] network 10.1.1.0 mask 24
[LNS-ip-pool-1] gateway-list 10.1.1.1
[LNS-ip-pool-1] quit
# Create a virtual interface template and configure PPP negotiation parameters on the LNS.
[LNS] interface virtual-template 1
[LNS-Virtual-Template1] ppp authentication-mode chap
[LNS-Virtual-Template1] remote address pool 1
[LNS-Virtual-Template1] ip address 10.1.1.1 255.255.255.0
[LNS-Virtual-Template1] quit
# Configure the LNS tunnel name and specify the LAC tunnel name.
[LNS-l2tp1] tunnel name lns
[LNS-l2tp1] allow l2tp virtual-template 1 remote lac
# Configure a private network route on the LNS, so users in the headquarters can
communicate with users in the enterprise branch.
[LNS] ip route-static 10.1.10.0 255.255.255.0 virtual-template 1
# Create an IKE peer on the LAC and set the pre-shared key and remote ID based on the
default configuration.
[LAC] ike peer spub
[LAC-ike-peer-spub] undo version 2
[LAC-ike-peer-spub] ike-proposal 5
[LAC-ike-peer-spub] pre-shared-key cipher Huawei@1234
[LAC-ike-peer-spub] remote-address 1.1.1.1
[LAC-ike-peer-spub] quit
# Create an IKE peer on the LNS and set the pre-shared key and remote ID based on the
default configuration.
[LNS] ike peer spua
[LNS-ike-peer-spua] undo version 2
[LNS-ike-peer-spua] ike-proposal 5
[LNS-ike-peer-spua] pre-shared-key cipher Huawei@1234
[LNS-ike-peer-spua] remote-address 1.1.2.1
[LNS-ike-peer-spua] quit
Step 7 Apply the IPSec policy group to an interface so that the interface can protect traffic.
# Apply an IPSec policy group to the interface of the LAC.
[LAC] interface gigabitethernet 1/0/0
[LAC-GigabitEthernet1/0/0] ipsec policy map1
[LAC-GigabitEthernet1/0/0] quit
Number of IKE SA : 2
--------------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
# Run the display l2tp tunnel command on the LAC or LNS to view L2TP tunnel and
session information. The command output for the LAC is shown as an example.
[LAC] display l2tp tunnel
Total tunnel : 1
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
1 1 1.1.1.1 1701 1 lns
----End
Configuration Files
l Configuration file of the LAC
#
sysname LAC
#
l2tp enable
#
acl number 3101
rule 5 permit ip source 1.1.2.0 0.0.0.255 destination 1.1.1.0 0.0.0.255
#
ipsec proposal tran1
remote-address 1.1.2.1
#
ipsec policy use1 10 isakmp
security acl 3101
ike-peer spua
proposal tran1
#
ip pool 1
network 10.1.1.0 mask 255.255.255.0
gateway-list 10.1.1.1
#
aaa
local-user huawei password cipher $1a$_<`.CO&(:LeS/$#F
\H0Qv8B]KAZja3}3q'RNx;VI$
local-user huawei service-type ppp
#
interface Virtual-Template1
ppp authentication-mode chap
remote address pool 1
ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
ipsec policy use1
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote lac
tunnel password cipher %@%@EB~j7Je>;@>uNr''D=J<]\WL%@%@
tunnel name lns
#
ip route-static 1.1.2.1 255.255.255.0 1.1.1.2
ip route-static 10.1.10.0 255.255.255.0 Virtual-Template1
#
return
Figure 4-53 Configuring a virtual tunnel template interface for IPSec Tunnel setup
Tunnel0/0/0 Tunnel-Template0
192.168.1.1/24 192.168.1.2/24
IPSec Tunnel
RouterA RouterB
Branch gateway GE1/0/0 GE1/0/0 Headquarters gateway
GE2/0/0 GE2/0/0
1.1.1.1/24 2.1.1.1/24
10.1.1.1/24 10.1.2.1/24
PC A PC B
10.1.1.2/24 10.1.2.2/24
Branch subnet Headquarters
subnet
Configuration Roadmap
The configuration roadmap is as follows:
Procedure
Step 1 Configure IP addresses and static routes on the interfaces of RouterA and RouterB.
# Configure a static route from RouterA to RouterB. This example assumes that the next hop
address of the route is 1.1.1.2.
[RouterA] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
<Huawei> system-view
[Huawei] sysname RouterB
[RouterB] interface gigabitethernet 1/0/0
[RouterB-GigabitEthernet1/0/0] ip address 2.1.1.1 255.255.255.0
[RouterB-GigabitEthernet1/0/0] quit
[RouterB] interface gigabitethernet 2/0/0
[RouterB-GigabitEthernet2/0/0] ip address 10.1.2.1 255.255.255.0
[RouterB-GigabitEthernet2/0/0] quit
# Configure a static route from RouterB to RouterA. This example assumes that the next hop
address of the route is 2.1.1.2.
[RouterB] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
Step 2 Configure ACLs to define the subnet that the local device needs to protect.
# Configure an ACL on RouterA to permit data flows with the source address 10.1.1.0/24 to
pass through.
[RouterA] acl number 3001
[RouterA-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255
[RouterA-acl-adv-3001] quit
# Configure an ACL on RouterB to permit data flows with the source address 10.1.2.0/24 to
pass through.
[RouterB] acl number 3001
[RouterB-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255
[RouterB-acl-adv-3001] quit
Step 3 Configure AAA service schemes to define the subnet route information that the local device
needs to send.
# Configure an AAA service scheme on RouterA.
[RouterA] aaa
[RouterA-aaa] service-scheme schemetest
[RouterA-aaa-service-schemetest] route set acl 3001
[RouterA-aaa-service-schemetest] route set interface
[RouterA-aaa-service-schemetest] quit
[RouterA-aaa] quit
Run the display ipsec proposal command on RouterA and RouterB to view the configuration
of the IPSec proposal.
Step 7 Apply the IPSec profiles to the interfaces of RouterA and RouterB.
# Apply the IPSec profile to the interface of RouterA.
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ip address 192.168.1.1 255.255.255.0
[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] source gigabitethernet1/0/0
[RouterA-Tunnel0/0/0] destination 2.1.1.1
[RouterA-Tunnel0/0/0] ipsec profile profile1
[RouterA-Tunnel0/0/0] quit
# Run the display ipsec profile command on RouterA and RouterB to view the IPSec profile
configuration.
Step 8 Verify the configuration.
# Run the display ike sa command on RouterA and RouterB to view the IKE SA
configuration. The display on RouterA is used as an example.
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
Number of IKE SA : 2
--------------------------------------------------------------------------------
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
# Run the display ip routing-table command on RouterA and RouterB to view route
information. This example only shows information about subnet routes that are successfully
sent.
[RouterA] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 16 Routes : 16
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3001
rule 5 permit ip source 10.1.1.0 0.0.0.255
#
ike-proposal 5
service-scheme schemetest
route accept
config-exchange set accept
config-exchange set send
#
ipsec profile profile1
ike-peer peer2
proposal prop1
#
aaa
service-scheme schemetest
route set acl 3001
route set interface
#
interface GigabitEthernet1/0/0
ip address 2.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
#
interface Tunnel-Template0
ip address unnumbered interface LoopBack0
tunnel-protocol ipsec
source GigabitEthernet1/0/0
ipsec profile profile1
#
interface LoopBack0
ip address 192.168.1.2 255.255.255.255
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
#
return
Figure 4-54 Networking diagram for configuring rapid switchover and revertive switching
RouterA
Headquarters
gateway A
GE0/0/2
192.168.1.2/24
RouterC GE0/0/1
Branch gateway GE0/0/1
60.1.1.1/24
70.1.1.1/24
Headquarters
GE0/0/2
GE0/0/1
192.168.2.2/24
60.1.2.1/24
PC_2
GE0/0/2 192.168.1.1/24
192.168.1.2/24
RouterB
Branch
Headquarter
s gateway B
PC_1
192.168.2.1/24
Configuration Roadmap
Since the branch and headquarters communicate over the public network, you can set up an
IPSec tunnel between them to provide security protection. The configuration roadmap is as
follows:
1. Configure the IP address on each interface and static routes to the peer to implement
communication between interfaces.
2. Configure an NQA test instance to monitor the link between the branch gateway and
headquarters gateway A.
3. Configure ACLs to define the data flows to be protected by the IPSec tunnel.
4. Configure IPSec proposals to define the traffic protection methods.
5. Create IKE peers and configure the device to determine the validity of the peer address
according to the NQA test instance status, so that traffic can be rapidly switched from
gateway A to gateway B when gateway A fails. Enable revertive switching of the IKE
peer to ensure that traffic can be switched back to gateway A when gateway A recovers.
6. Configure IPSec policies to define the data protection methods.
7. Apply the IPSec policies to interfaces so that the interfaces can protect traffic.
Procedure
Step 1 Configure an IP address for each interface and static routes to the peer on RouterA, RouterB,
and RouterC to ensure that there are reachable routes among them.
# Configure an IP address for each interface and static routes to the peer on RouterA. This
example assumes that the next hop address in the route to the branch gateway is 60.1.1.2.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ip address 60.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/1] quit
[RouterA] interface gigabitethernet 0/0/2
[RouterA-GigabitEthernet0/0/2] ip address 192.168.1.2 255.255.255.0
[RouterA-GigabitEthernet0/0/2] quit
[RouterA] ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 192.168.2.0 255.255.255.0 60.1.1.2
# Configure an IP address for each interface and static routes to the peer on RouterB. This
example assumes that the next hop address in the route to the branch gateway is 60.1.2.2.
<Huawei> system-view
[Huawei] sysname RouterB
[RouterB] interface gigabitethernet 0/0/1
[RouterB-GigabitEthernet0/0/1] ip address 60.1.2.1 255.255.255.0
[RouterB-GigabitEthernet0/0/1] quit
[RouterB] interface gigabitethernet 0/0/2
[RouterB-GigabitEthernet0/0/2] ip address 192.168.1.2 255.255.255.0
[RouterB-GigabitEthernet0/0/2] quit
[RouterB] ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
[RouterB] ip route-static 192.168.2.0 255.255.255.0 60.1.2.2
# Configure an IP address for each interface and a static route to the peer on RouterC. This
example assumes that the next hop addresses in the route to the headquarters gateways A and
B are both 70.1.1.2.
<Huawei> system-view
[Huawei] sysname RouterC
[RouterC] interface gigabitethernet 0/0/1
[RouterC-GigabitEthernet0/0/1] ip address 70.1.1.1 255.255.255.0
[RouterC-GigabitEthernet0/0/1] quit
[RouterC] interface gigabitethernet 0/0/2
[RouterC-GigabitEthernet0/0/2] ip address 192.168.2.2 255.255.255.0
[RouterC-GigabitEthernet0/0/2] quit
[RouterC] ip route-static 0.0.0.0 0.0.0.0 70.1.1.2
# Configure an NQA test instance of ICMP type (administrator name admin and instance
name test) on RouterC to detect faults on the link 70.1.1.1/24 -> 60.1.1.1/24.
[RouterC] nqa test-instance admin test
[RouterC-nqa-admin-test] test-type icmp
[RouterC-nqa-admin-test] destination-address ipv4 60.1.1.1
[RouterC-nqa-admin-test] frequency 10
[RouterC-nqa-admin-test] probe-count 2
[RouterC-nqa-admin-test] start now
[RouterC-nqa-admin-test] quit
Step 3 Configure an ACL on RouterA, RouterB, and RouterC respectively to define the data flows to
be protected.
# Configure an ACL on RouterA to define the data flows from subnet 192.168.1.0/24 to
subnet 192.168.2.0/24. The configuration of RouterB is similar to that of RouterA, and is not
provided here.
[RouterA] acl number 3002
[RouterA-acl-adv-3002] rule permit ip source 192.168.1.0 0.0.0.255 destination
192.168.2.0 0.0.0.255
[RouterA-acl-adv-3002] quit
# Configure an ACL on RouterC to define the data flows from subnet 192.168.2.0/24 to
subnet 192.168.1.0/24.
# Create an IPSec proposal on RouterA. The configurations of RouterB and RouterC are
similar to that of RouterA, and are not provided here.
[RouterA] ipsec proposal tran1
[RouterA-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[RouterA-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[RouterA-ipsec-proposal-tran1] quit
Step 5 Configure an IKE proposal and an IKE peer on RouterA, RouterB, and RouterC respectively.
# Configure an IKE proposal and IKE peer rut1 on RouterC, and set the address 60.1.1.1 to
take effect when the status of the NQA test instance is Up and the address 60.1.2.1 to take
effect when the status of the NQA test instance is Down.
[RouterC] ike proposal 5
[RouterC-ike-proposal-5] encryption-algorithm aes-128
[RouterC-ike-proposal-5] authentication-algorithm sha2-256
[RouterC-ike-proposal-5] dh group14
[RouterC-ike-proposal-5] quit
[RouterC] ike peer rut1
[RouterC-ike-peer-rut1] undo version 2
[RouterC-ike-peer-rut1] ike-proposal 5
[RouterC-ike-peer-rut1] pre-shared-key cipher Huawei@123
[RouterC-ike-peer-rut1] remote-address 60.1.1.1 track nqa admin test up
[RouterC-ike-peer-rut1] remote-address 60.1.2.1 track nqa admin test down
[RouterC-ike-peer-rut1] switch-back enable
[RouterC-ike-peer-rut1] quit
[RouterA-ipsec-policy-templet-temp1-10] quit
[RouterA] ipsec policy policy1 10 isakmp template temp1
Step 7 Apply the IPSec policies to the corresponding interfaces on RouterA, RouterB, and RouterC
to make the interfaces able to protect traffic.
# Apply the IPSec policy to the interface of RouterA.
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ipsec policy policy1
[RouterA-GigabitEthernet0/0/1] quit
Number of IKE SA : 2
---------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
# Run the display ike sa command on RouterC. The command output is as follows:
[RouterC] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
937 60.1.1.1:500 RD|ST v1:2 IP 60.1.1.1
Number of IKE SA : 2
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
The command output shows that an IKE SA is successfully established between the
branch gateway and headquarters gateway A.
2. Disconnect the link from the Internet to the headquarters gateway A. The IP address of
the IKE peer changes to RouterB.
# After you disconnect the link from the Internet to the headquarters gateway A, run the
display nqa results test-instance admin test command on RouterC. The command
output is as follows:
[RouterC] display nqa results test-instance admin
test
The command output shows that the status of gateway A is failed in NQA test results,
and the status of the NQA test instance is Down.
# Run the display ike sa command on RouterC. The command output is as follows:
[RouterC] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
21576 60.1.2.1:500 RD v1:2 IP 60.1.2.1
21575 60.1.2.1:500 RD v1:1 IP 60.1.2.1
Number of IKE SA : 2
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
The command output shows that the IKE peer address is 60.1.2.1, indicating that traffic
is switched to gateway B.
3. Recover the link from the Internet to the headquarters gateway A. The IP address of the
IKE peer changes to RouterA.
# After you recover the link from the Internet to the headquarters gateway A, run the
display nqa results test-instance admin test command on RouterC. The command
output is as follows:
[RouterC] display nqa results test-instance admin
test
The command output shows that the status of gateway A is success in NQA test results,
and the status of the NQA test instance is Up.
# Run the display ike sa command on RouterC. The command output is as follows:
[RouterC] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------
21578 60.1.1.1:500 RD|ST v1:2 IP 60.1.1.1
21577 60.1.1.1:500 RD|ST v1:1 IP 60.1.1.1
Number of IKE SA : 2
--------------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
The command output shows that the IKE peer address is 60.1.1.1, indicating that traffic
is switched back to gateway A. Rapid switchover and revertive switching are
successfully configured.
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.2.0
0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %#%#u;3RGfy.^D2'oEC%wwnU](q"Y2O&b'L=,NI`-qWE%#%#
ike-proposal 5
#
ipsec policy-template temp1 10
ike-peer rut1
proposal tran1
#
ipsec policy policy1 10 isakmp template temp1
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.1.2 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
ip route-static 192.168.2.0 255.255.255.0 60.1.1.2
#
return
#
ipsec policy-template temp1 10
ike-peer rut1
proposal tran1
#
ipsec policy policy1 10 isakmp template temp1
#
interface GigabitEthernet0/0/1
ip address 60.1.2.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.1.2 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
ip route-static 192.168.2.0 255.255.255.0 60.1.2.2
#
return
l Configuration file of RouterC
#
sysname RouterC
#
acl number 3002
rule 5 permit ip source 192.168.2.0 0.0.0.255 destination 192.168.1.0
0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %#%#u;3RGfy.^D2'oEC%wwnU](q"Y2O&b'L=,NI`-qWE%#%#
ike-proposal 5
remote-address 60.1.1.1 track nqa admin test up
remote-address 60.1.2.1 track nqa admin test down
switch-back enable
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
#
interface GigabitEthernet0/0/1
ip address 70.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.2.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 70.1.1.2
#
probe-count
2
start now
#
return
Networking Requirements
As shown in Figure 4-55, the branch communicates with the headquarters over the public
network. To improve reliability, the headquarters uses two gateways RouterA and RouterB to
connect to the branch gateway RouterC. RouterC sets up IPSec Tunnel1 with RouterA
through GE0/0/1 and IPSec Tunnel2 with RouterB through GE0/0/2.
The enterprise wants to protect traffic exchanged between the headquarters and branch and
requires that traffic be switched to the other IPSec tunnel when one IPSec tunnel fails and
back to the faulty IPSec tunnel when the faulty IPSec tunnel recovers.
Figure 4-55 Networking diagram for configuring redundancy control of IPSec tunnels
RouterA
Headquarters
gateway A
GE0/0/1 GE0/0/2
l1
ne 192.168.1.1/24
RouterC 70.1.1.1/24 Tun VRRP
Branch ec VIP:192.168.1.2
IPS GE0/0/1
gateway 60.1.1.1/24
GE0/0/2 Headquarters
70.1.2.1/24 GE0/0/1
GE0/0/0
60.1.2.1/24
192.168.2.2/24 IPSe PC_2
c Tun 192.168.1.10/24
nel2 GE0/0/2
RouterB
192.168.1.3/24
Branch Headquarters
gateway B
PC_1
192.168.2.1/24
Configuration Roadmap
Since the branch and headquarters communicate over the public network, you can set up an
IPSec tunnel between them to provide security protection. The configuration roadmap is as
follows:
1. Configure the IP address on each interface and static routes to the peer to implement
communication between interfaces.
2. Configure an NQA group and an NQA test instance to monitor the link between the
branch gateway and headquarters gateway A.
3. Configure ACLs to define the data flows to be protected by the IPSec tunnel.
4. Configure IPSec proposals to define the traffic protection methods.
5. Configure IKE peers.
6. Configure IPSec policies to define the data protection methods. Configure the device to
control IPSec tunnel setup and teardown according to the NQA group status and enable
the device to switch traffic to the other IPSec tunnel when one IPSec tunnel becomes
faulty.
7. Apply the IPSec policies to interfaces so that the interfaces can protect traffic.
VRRP backup is configured on the two gateways in the headquarters. For detailed configuration, see VRRP
Configuration.
Procedure
Step 1 Configure an IP address for each interface and static routes to the peer on RouterA, RouterB,
and RouterC to ensure that there are reachable routes among them.
# Configure an IP address for each interface and static routes to the peer on RouterA. This
example assumes that the next hop address in the route to the branch gateway is 60.1.1.2.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ip address 60.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/1] quit
[RouterA] interface gigabitethernet 0/0/2
[RouterA-GigabitEthernet0/0/2] ip address 192.168.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/2] quit
[RouterA] ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 70.1.2.0 255.255.255.0 60.1.1.2
[RouterA] ip route-static 192.168.2.0 255.255.255.0 60.1.1.2
# Configure an IP address for each interface and static routes to the peer on RouterB. This
example assumes that the next hop address in the route to the branch gateway is 60.1.2.2.
<Huawei> system-view
[Huawei] sysname RouterB
[RouterB] interface gigabitethernet 0/0/1
[RouterB-GigabitEthernet0/0/1] ip address 60.1.2.1 255.255.255.0
[RouterB-GigabitEthernet0/0/1] quit
[RouterB] interface gigabitethernet 0/0/2
[RouterB-GigabitEthernet0/0/2] ip address 192.168.1.3 255.255.255.0
[RouterB-GigabitEthernet0/0/2] quit
[RouterB] ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
[RouterB] ip route-static 70.1.2.0 255.255.255.0 60.1.2.2
[RouterB] ip route-static 192.168.2.0 255.255.255.0 60.1.2.2
# Configure an IP address for each interface and static routes to the peer on RouterC. This
example assumes that the next hop addresses in the route to the headquarters gateways A and
B are 70.1.1.2 and 70.1.2.2, respectively.
<Huawei> system-view
[Huawei] sysname RouterC
[RouterC] interface gigabitethernet 0/0/1
[RouterC-GigabitEthernet0/0/1] ip address 70.1.1.1 255.255.255.0
[RouterC-GigabitEthernet0/0/1] quit
[RouterC] interface gigabitethernet 0/0/2
[RouterC-GigabitEthernet0/0/2] ip address 70.1.2.1 255.255.255.0
[RouterC-GigabitEthernet0/0/2] quit
[RouterC] interface gigabitethernet 0/0/0
An IPSec policy is created on RouterA and RouterB using the IPSec policy template; therefore, this step
is optional. If you configure an ACL on RouterA and RouterB, you must specify the destination address
in the ACL rule.
# Configure an ACL on RouterC to define the data flows from subnet 192.168.2.0/24 to
subnet 192.168.1.0/24.
[RouterC] acl number 3002
[RouterC-acl-adv-3002] rule permit ip source 192.168.2.0 0.0.0.255 destination
192.168.1.0 0.0.0.255
[RouterC-acl-adv-3002] quit
Step 5 Configure an IKE proposal and an IKE peer on RouterA, RouterB, and RouterC respectively.
RouterA and RouterB function as responders to respond to an IKE negotiation request; therefore, IPSec
policies are created on them through IPSec policy templates. You do not need to set remote-address.
# Configure an IKE proposal and IKE peer rut1 and rut2 on RouterC.
[RouterC] ike proposal 5
[RouterC-ike-proposal-5] encryption-algorithm aes-128
[RouterC-ike-proposal-5] authentication-algorithm sha2-256
[RouterC-ike-proposal-5] dh group14
[RouterC-ike-proposal-5] quit
[RouterC] ike peer rut1
[RouterC-ike-peer-rut1] undo version 2
[RouterC-ike-peer-rut1] ike-proposal 5
[RouterC-ike-peer-rut1] pre-shared-key cipher Huawei@123
[RouterC-ike-peer-rut1] remote-address 60.1.1.1
[RouterC-ike-peer-rut1] quit
[RouterC] ike peer rut2
[RouterC-ike-peer-rut2] undo version 2
[RouterC-ike-peer-rut2] ike-proposal 5
[RouterC-ike-peer-rut2] pre-shared-key cipher Huawei@123
[RouterC-ike-peer-rut2] remote-address 60.1.2.1
[RouterC-ike-peer-rut2] quit
Step 7 Apply the IPSec policies to the corresponding interfaces on RouterA, RouterB, and RouterC
to make the interfaces able to protect traffic.
# Apply the IPSec policy to the interface of RouterA.
1. PC_1 can ping PC_2 successfully and data transmitted between them is encrypted.
# Run the display ipsec sa command on RouterC to check the IPSec configuration.
[RouterC] display ipsec sa
===============================
Interface:
GigabitEthernet0/0/1
Path MTU:
1500
===============================
-----------------------------
IPSec policy name:
"policy1"
Sequence number :
10
Acl group :
3002
Acl rule :
5
Mode :
ISAKMP
-----------------------------
Connection ID :
21812
Encapsulation mode:
Tunnel
Tunnel local :
70.1.1.1
Tunnel remote :
60.1.1.1
Flow source : 192.168.2.0/255.255.255.0
0/0
Flow destination : 192.168.1.0/255.255.255.0
0/0
Qos pre-classify :
Disable
Qos group :
-
[Outbound ESP
SAs]
SPI: 870098030
(0x33dca46e)
Proposal: ESP-ENCRYPT-AES-128
SHA2-256-128
SA remaining key duration (bytes/sec):
1887436800/3395
Max sent sequence-number:
0
UDP encapsulation used for NAT traversal:
N
[Inbound ESP
SAs]
SPI: 2558349639
(0x987d5147)
Proposal: ESP-ENCRYPT-AES-128
SHA2-256-128
SA remaining key duration (bytes/sec):
1887436800/3395
Max received sequence-number:
0
Anti-replay window size:
32
UDP encapsulation used for NAT traversal: N
The command output shows that traffic from PC_1 to PC_2 is transmitted over IPSec
Tunnel1 (source IP address: 70.1.1.1, destination IP address: 60.1.1.1).
2. Disable GE0/0/1 of RouterC. Traffic is switched to IPSec Tunnel2 (source IP address:
70.1.2.1/24, destination IP address: 60.1.2.1/24).
# Run the shutdown command on GE0/0/1 of RouterC, and then run the display nqa
results test-instance admin test command. The command output is as follows:
[RouterC] display nqa results test-instance admin test
# Run the display ipsec sa command on RouterC to check the IPSec configuration.
[RouterC] display ipsec sa
===============================
Interface:
GigabitEthernet0/0/2
Path MTU:
1500
===============================
-----------------------------
IPSec policy name:
"policy2"
Sequence number :
20
Acl group :
3002
Acl rule :
5
Mode :
ISAKMP
-----------------------------
Connection ID :
21839
Encapsulation mode:
Tunnel
Tunnel local :
70.1.2.1
Tunnel remote :
60.1.2.1
Flow source : 192.168.2.0/255.255.255.0
0/0
Flow destination : 192.168.1.0/255.255.255.0
0/0
Qos pre-classify :
Disable
Qos group :
-
[Outbound ESP
SAs]
SPI: 437762941
(0x1a17bb7d)
Proposal: ESP-ENCRYPT-AES-128
SHA2-256-128
SA remaining key duration (bytes/sec):
1887436800/3575
Max sent sequence-number:
0
UDP encapsulation used for NAT traversal:
N
[Inbound ESP
SAs]
SPI: 1765690761
(0x693e4d89)
Proposal: ESP-ENCRYPT-AES-128
SHA2-256-128
SA remaining key duration (bytes/sec):
1887436800/3575
Max received sequence-number:
0
Anti-replay window size:
32
UDP encapsulation used for NAT traversal: N
The command output shows that traffic is switched to IPSec Tunnel2 (source IP address:
70.1.2.1, destination IP address: 60.1.2.1).
3. Enable GE0/0/1 of RouterC again. Traffic is switched back to IPSec Tunnel1 (source IP
address: 70.1.1.1, destination IP address: 60.1.1.1).
# Run the undo shutdown command on GE0/0/1 of RouterC, and then run the display
nqa results test-instance admin test command. The command output is as follows:
[RouterC] display nqa results test-instance admin test
===============================
Interface:
GigabitEthernet0/0/1
Path MTU:
1500
===============================
-----------------------------
IPSec policy name:
"policy1"
Sequence number :
10
Acl group :
3002
Acl rule :
5
Mode :
ISAKMP
-----------------------------
Connection ID :
21992
Encapsulation mode:
Tunnel
Tunnel local :
70.1.1.1
Tunnel remote :
60.1.1.1
Flow source : 192.168.2.0/255.255.255.0
0/0
Flow destination : 192.168.1.0/255.255.255.0
0/0
Qos pre-classify :
Disable
Qos group :
-
[Outbound ESP
SAs]
SPI: 2749069243
(0xa3db77bb)
Proposal: ESP-ENCRYPT-AES-128
SHA2-256-128
SA remaining key duration (bytes/sec):
1887436800/3583
Max sent sequence-number:
0
UDP encapsulation used for NAT traversal:
N
[Inbound ESP
SAs]
SPI: 21830677
(0x14d1c15)
Proposal: ESP-ENCRYPT-AES-128
SHA2-256-128
SA remaining key duration (bytes/sec):
1887436800/3583
Max received sequence-number:
0
Anti-replay window size:
32
UDP encapsulation used for NAT traversal: N
The command output shows that traffic is switched back to IPSec Tunnel1 (source IP
address: 70.1.1.1, destination IP address: 60.1.1.1). The configuration succeeds.
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %#%#u;3RGfy.^D2'oEC%wwnU](q"Y2O&b'L=,NI`-qWE%#%#
ike-proposal 5
#
ipsec policy-template temp1 10
ike-peer rut1
proposal tran1
#
ipsec policy policy1 10 isakmp template temp1
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.1.1 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
ip route-static 70.1.2.0 255.255.255.0 60.1.1.2
ip route-static 192.168.2.0 255.255.255.0 60.1.1.2
#
return
l Configuration file of RouterB
#
sysname RouterB
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %#%#u;3RGfy.^D2'oEC%wwnU](q"Y2O&b'L=,NI`-qWE%#%#
ike-proposal 5
#
ipsec policy-template temp1 10
ike-peer rut1
proposal tran1
#
ipsec policy policy1 10 isakmp template temp1
#
interface GigabitEthernet0/0/1
ip address 60.1.2.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 192.168.1.3 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
ip route-static 70.1.2.0 255.255.255.0 60.1.2.2
ip route-static 192.168.2.0 255.255.255.0 60.1.2.2
#
return
l Configuration file of RouterC
#
sysname RouterC
#
acl number 3002
rule 5 permit ip source 192.168.2.0 0.0.0.255 destination 192.168.1.0
0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 5
encryption-algorithm aes-128
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %#%#u;3RGfy.^D2'oEC%wwnU](q"Y2O&b'L=,NI`-qWE%#%#
ike-proposal 5
remote-address 60.1.1.1
#
ike peer rut2
undo version 2
pre-shared-key cipher %#%#u;3RGfy.^D2'oEC%wwnU](q"Y2O&b'L=,NI`-qWE%#%#
ike-proposal 5
remote-address 60.1.2.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
connect track nqa admin test up
disconnect track nqa admin test down
#
ipsec policy policy2 20 isakmp
security acl 3002
ike-peer rut2
proposal tran1
connect track nqa admin test down
disconnect track nqa admin test up
#
interface GigabitEthernet0/0/0
ip address 192.168.2.2 255.255.255.0
#
interface GigabitEthernet0/0/1
ip address 70.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 70.1.2.1 255.255.255.0
ipsec policy policy2
#
ip route-static 60.1.1.0 255.255.255.0 70.1.1.2
ip route-static 60.1.2.0 255.255.255.0 70.1.2.2
ip route-static 192.168.1.0 255.255.255.0 70.1.1.2
ip route-static 192.168.1.0 255.255.255.0 70.1.2.2
#
probe-count
2
start now
#
nqa-group group1
nqa admin test
#
return
Networking Requirements
In Figure 4-56, the branch communicates with the headquarters over the Internet. To improve
reliability, the branch connects to the headquarters gateway RouterC through two branch
gateways RouterA and RouterB, and the two branch gateways form a VRRP group to
implement gateway redundancy.
The enterprise wants traffic transmitted between the branch and headquarters to be protected.
If the master device RouterA is faulty, the backup device RouterB takes over as the master
device. After RouterA recovers from the failure, it becomes the master device again to act as
the gateway.
RouterA
Branch gateway
GE0/0/2 GE0/0/1
10.1.1.1/24 1.1.1.1/24
RouterC
Headquarters
IPSec tunnel gateway
Headquarters
Branch VRRP GE0/0/1 GE0/0/2
VIP:10.1.1.11 2.1.1.1/24 10.2.1.1/24
PC_2
GE0/0/2 GE0/0/1
PC_1 10.2.1.2/24
1.1.2.1/24
10.1.1.3/24 10.1.1.2/24
RouterB
Branch gateway
Configuration Roadmap
An IPSec tunnel can be established between the headquarters gateway and branch gateway to
protect traffic transmitted between the headquarters and branch over the Internet. The
configuration roadmap is as follows:
1. Configure IP addresses for interfaces and configure static routes to the remote end to
ensure that there are reachable routes between two ends.
2. Configure a VRRP group on RouterA and RouterB to implement gateway redundancy.
3. Configure an ACL on RouterA and RouterB to define IPSec-protected data flows.
4. Configure an IPSec proposal to define the traffic protection method.
Procedure
Step 1 Configure IP addresses for interfaces and configure static routes to the remote end to ensure
that there are reachable routes between RouterA, RouterB, and RouterC.
# On RouterA, configure IP addresses for interfaces and configure a static route to the remote
end. This example assumes that the next-hop address of the static route to the headquarters
gateway is 1.1.1.2.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 0/0/1
[RouterA-GigabitEthernet0/0/1] ip address 1.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/1] quit
[RouterA] interface gigabitethernet 0/0/2
[RouterA-GigabitEthernet0/0/2] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/2] quit
[RouterA] ip route-static 0.0.0.0 0 1.1.1.2
# On RouterB, configure IP addresses for interfaces and configure a static route to the remote
end. This example assumes that the next-hop address of the static route to the headquarters
gateway is 1.1.2.2.
<Huawei> system-view
[Huawei] sysname RouterB
[RouterB] interface gigabitethernet 0/0/1
[RouterB-GigabitEthernet0/0/1] ip address 1.1.2.1 255.255.255.0
[RouterB-GigabitEthernet0/0/1] quit
[RouterB] interface gigabitethernet 0/0/2
[RouterB-GigabitEthernet0/0/2] ip address 10.1.1.2 255.255.255.0
[RouterB-GigabitEthernet0/0/2] quit
[RouterB] ip route-static 0.0.0.0 0 1.1.2.2
# On RouterC, configure IP addresses for interfaces and configure a static route to the remote
end. This example assumes that the next-hop address of the static route to the branch gateway
is 2.1.1.2.
<Huawei> system-view
[Huawei] sysname RouterC
[RouterC] interface gigabitethernet 0/0/1
[RouterC-GigabitEthernet0/0/1] ip address 2.1.1.1 255.255.255.0
[RouterC-GigabitEthernet0/0/1] quit
[RouterC] interface gigabitethernet 0/0/2
[RouterC-GigabitEthernet0/0/2] ip address 10.2.1.1 255.255.255.0
[RouterC-GigabitEthernet0/0/2] quit
[RouterC] ip route-static 0.0.0.0 0 2.1.1.2
# Configure VRRP group 1 on RouterB, and set the VRRP priority of RouterB to 80.
[RouterB] interface gigabitethernet 0/0/2
[RouterB-GigabitEthernet0/0/2] vrrp vrid 1 virtual-ip 10.1.1.11
[RouterB-GigabitEthernet0/0/2] vrrp vrid 1 priority 80
[RouterB-GigabitEthernet0/0/2] quit
Step 3 Configure an ACL on RouterA and RouterB to define the data flows to be protected.
# Configure RouterA.
[RouterA] acl number 3002
[RouterA-acl-adv-3002] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.2.1.0 0.0.0.255
[RouterA-acl-adv-3002] quit
# Configure RouterB.
[RouterB] acl number 3002
[RouterB-acl-adv-3002] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.2.1.0 0.0.0.255
[RouterB-acl-adv-3002] quit
# Configure RouterB.
[RouterB] ipsec proposal tran1
[RouterB-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[RouterB-ipsec-proposal-tran1] esp encryption-algorithm aes-256
[RouterB-ipsec-proposal-tran1] quit
# Configure RouterC.
[RouterC] ipsec proposal tran1
[RouterC-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[RouterC-ipsec-proposal-tran1] esp encryption-algorithm aes-256
[RouterC-ipsec-proposal-tran1] quit
# Configure RouterB.
[RouterB] ike proposal 5
[RouterB-ike-proposal-5] encryption-algorithm aes-256
# Configure RouterC.
[RouterC] ike proposal 5
[RouterC-ike-proposal-5] encryption-algorithm aes-256
[RouterC-ike-proposal-5] authentication-algorithm sha2-256
[RouterC-ike-proposal-5] dh group14
[RouterC-ike-proposal-5] quit
[RouterC] ike peer rut1
[RouterC-ike-peer-rut1] undo version 2
[RouterC-ike-peer-rut1] ike-proposal 5
[RouterC-ike-peer-rut1] pre-shared-key cipher Huawei@123
[RouterC-ike-peer-rut1] quit
===============================
Interface: GigabitEthernet0/0/1
===============================
-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Acl group : 3002
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 2
Encapsulation mode: Tunnel
Holding time : 0d 0h 26m 12s
Tunnel local : 2.1.1.1:500
Tunnel remote : 1.1.1.1:500
Flow source : 10.2.1.0/255.255.255.0 0/0
Flow destination : 10.1.1.0/255.255.255.0 0/0
The preceding command output shows that traffic from PC_1 to PC_2 is transmitted by
RouterA.
2. Traffic is switched to RouterB for transmission after GE0/0/2 of RouterA is shut down.
# Run the shutdown command on GE0/0/2 of RouterA, and then run the display ipsec
sa command on RouterC to check the configuration.
[RouterC] display ipsec sa
ipsec sa information:
===============================
Interface: GigabitEthernet0/0/1
===============================
-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Acl group : 3002
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 2
Encapsulation mode: Tunnel
Holding time : 0d 0h 26m 12s
Tunnel local : 2.1.1.1:500
Tunnel remote : 1.1.2.1:500
Flow source : 10.2.1.0/255.255.255.0 0/0
Flow destination : 10.1.1.0/255.255.255.0 0/0
===============================
Interface: GigabitEthernet0/0/1
===============================
-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Acl group : 3002
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 2
Encapsulation mode: Tunnel
Holding time : 0d 0h 26m 12s
Tunnel local : 2.1.1.1:500
The preceding command output shows that traffic is transmitted by RouterA. This
indicates that the configurations are successful.
----End
Configuration Files
l Router A configuration file
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal 5
encryption-algorithm aes-256
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#oDRPE$1Da37|xCPSm+/5/-!{P3CaO/cdZ4EX"Sf"%^%#
ike-proposal 5
remote-address 2.1.1.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
connect track vrrp 1 interface GigabitEthernet0/0/2 master
disconnect track vrrp 1 interface GigabitEthernet0/0/2 backup
#
interface GigabitEthernet0/0/1
ip address 1.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 virtual-ip 10.1.1.11
vrrp vrid 1 priority 120
vrrp vrid 1 preempt-mode timer delay 20
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2
#
return
l RouterB configuration file
#
sysname RouterB
#
acl number 3002
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal 5
encryption-algorithm aes-256
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#oDRPE$1Da37|xCPSm+/5/-!{P3CaO/cdZ4EX"Sf"%^%#
ike-proposal 5
remote-address 2.1.1.1
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
connect track vrrp 1 interface GigabitEthernet0/0/2 master
disconnect track vrrp 1 interface GigabitEthernet0/0/2 backup
#
interface GigabitEthernet0/0/1
ip address 1.1.2.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 10.1.1.2 255.255.255.0
vrrp vrid 1 virtual-ip 10.1.1.11
vrrp vrid 1 priority 80
#
ip route-static 0.0.0.0 0.0.0.0 1.1.2.2
#
return
l RouterC configuration file
#
sysname RouterC
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal 5
encryption-algorithm aes-256
dh group14
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#oDRPE$1Da37|xCPSm+/5/-!{P3CaO/cdZ4EX"Sf"%^%#
ike-proposal 5
#
ipsec policy-template temp1 10
ike-peer rut1
proposal tran1
#
ipsec policy policy1 10 isakmp template temp1
#
interface GigabitEthernet0/0/1
ip address 2.1.1.1 255.255.255.0
ipsec policy policy1
#
interface GigabitEthernet0/0/2
ip address 10.2.1.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 2.1.1.2
#
return
Symptom
The IPSec service cannot be normally transmitted. The output of the display ike sa command
shows that IKE SA negotiation failed.
The following shows an example of the command output. If the Flag parameter is displayed
as RD or RD|ST, an SA is established successfully. ST indicates that the local end is the IKE
initiator.
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------------
13118 10.1.3.2 0 RD v1:2
12390 10.1.3.2 0 RD v1:1
Number of IKE SA : 2
---------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
If IKE SA negotiation fails, the Flag parameter is empty, the Peer parameter is 0.0.0.0, or the
command output contains no record.
Procedure
Step 1 Run the display ike proposal command to check whether the IKE peer uses the same IKE
proposal.
If not, change IKE proposals on the peer to be the same. If the authentication algorithms in the
IKE proposals are different, perform the following operations.
On the IKE initiator:
ike proposal 10
authentication-algorithm sha2-256
Step 2 Run the display ipsec proposal command to check whether the security protocol matches the
configured security algorithms.
For example, when you run the display ipsec proposal name tran1 command and find that
the security protocol is ah-esp-new, that is, both AH and ESP are used, IKE negotiation will
fail if the ESP authentication and encryption algorithms are not configured.
<Huawei> display ipsec proposal name tran1
IPSec proposal name: tran1
Encapsulation mode: Tunnel
Transform : ah-esp-new
ESP protocol : Authentication NULL
Encryption NULL
l If you only need to use the AH protocol, run the transform command to change the
configuration.
ipsec proposal tran1
transform ah
ah authentication-algorithm sha2-256
l If you need to use both the AH and ESP protocols, run the esp authentication-
algorithm and esp encryption-algorithm commands to configure the ESP
authentication and encryption algorithms.
ipsec proposal tran1
transform ah-esp
ah authentication-algorithm sha2-256
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
Step 3 Run the display ike peer command to check whether the configuration in the peer view is
correct.
l Check whether the remote IP address is configured.
When the ACL mode is used for IPSec tunnel establishment, the remote IP address must
be specified for the device in IKE main negotiation mode. In addition, the remote IP
addresses specified for the IKE peer must match each other.
If the IP addresses of the IKE initiator and responder are 10.1.1.2 and 10.2.1.2, the
configuration is as follows.
On the IKE initiator:
ike peer mypeer1
remote-address 10.2.1.2
If the IKE responder uses the policy template mode, you do not need to configure the
remote IP address for the responder.
l Check whether the pre-shared keys of the IKE peer are the same.
If the configurations in the IKE proposals are different, change the configurations to be
the same.
----End
Symptom
The IPSec service cannot be normally transmitted. The output of the display ike sa command
shows that IPSec SA negotiation failed.
The following shows an example of the command output. If the Flag parameter is displayed
as RD or RD|ST, an SA is established successfully. ST indicates that the local end is the IKE
initiator.
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------------
13118 10.1.3.2 0 RD v1:2
12390 10.1.3.2 0 RD v1:1
Number of IKE SA : 2
---------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
If IKE SA negotiation is successful, but IPSec SA negotiation fails, the command output
contains no information about phase 2 or the Flag parameter is empty.
Procedure
Step 1 Run the display ipsec proposal command to check whether the IKE peer uses the same IPSec
proposal.
If not, change IPSec proposals on the peer to be the same. If the ESP authentication
algorithms in the IPSec proposals are different, perform the following operations.
Step 2 Run the display ipsec policy command to check whether the configuration in the IPSec
policy view is correct.
l Check whether the ACLs referenced in the IPSec policies are the same.
If the ACLs referenced by IPSec policies at both ends of the IPSec tunnel mirror each
other, an IPSec SA can be successfully established when either party initiates the
negotiation. If the ACLs do not mirror each other, an IPSec SA can be established only
when the IP address range defined in the ACL on the initiator is included in the IP
address range defined in the ACL on the responder. Therefore, it is recommended that
the ACLs at both ends of the IPSec tunnel mirror each other. That is, the source and
destination addresses in the ACL at one end are the same as the destination and source
addresses in the ACL at the other end.
For example, if the source and destination addresses of the initiator are 10.1.1.2 and
10.2.1.2, the source and destination addresses of the responder are10.2.1.2 and 10.1.1.2.
On the IKE initiator:
acl number 3101
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
ipsec policy map1 10 isakmp
security acl 3101
l Check whether the IKE peer configurations referenced in the IPSec policies are the
same.
For example, the IKE initiator reference IKE proposal peer spub.
ipsec policy map1 10 isakmp
ike-peer spub
If the IPSec proposal configurations at two ends of the tunnel are different, change them
to be the same.
----End
Procedure
Step 1 Check whether security ACLs on both ends are correctly configured.
Run the display ipsec sa command to check whether the source and destination network
segments of the protected data flows matching security ACLs include actual service flows. If
not, run the display acl acl-number command to check whether ACLs are correctly
configured on both ends.
For details about configuring IPSec-protected data flows, see 4.7.1 Defining Data Flows to
Be Protected.
For example, run the display ipsec sa command to check the security ACL 3101.
<Huawei> system-view
[Huawei] display ipsec sa
ipsec sa information:
===============================
Interface: GigabitEthernet1/0/0
===============================
-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Acl group : 3101
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 67108879
Encapsulation mode: Tunnel
Holding time : 0d 0h 4m 29s
Tunnel local : 1.1.1.1:500
Tunnel remote : 2.1.1.1:500
Flow source : 10.1.1.0/255.255.255.0 17/1701
Flow destination : 10.2.1.0/255.255.255.0 17/39725
......
If the protected data flows matching the security ACL do not include actual service flows, run
the display acl 3101 command to check the ACL configuration.
[Huawei] display acl 3101
Advanced ACL 3101, 1 rule
Acl's step is 5
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
If the security ACLs on both ends do not match, modify the security ACL configurations to
make them match.
Step 2 Check whether the NAT policy configuration affects the IPSec-protected data flows.
Run the display ipsec interface brief command to check the interface to which an IPSec
policy is applied, and then run the display current-configuration interface interface-type
interface-number command to check whether a NAT policy is configured on the specified
IPSec interface.
If NAT is configured on the interface to which an IPSec policy is applied, IPSec does not take
effect because the device performs NAT first. In this case, you need to ensure:
l The destination IP address denied in the ACL rule referenced by NAT is the destination
IP address in the ACL rule referenced by IPSec. This prevents the device from
performing NAT on the IPSec-protected data flows.
l The ACL rule referenced by IPSec matches the post-NAT IP address.
For example, the following command output indicates that a NAT policy is configured on
GE1/0/0.
[Huawei] display current-configuration interface gigabitethernet 1/0/0
interface GigabitEthernet1/0/0
ip address 1.1.1.1 255.255.255.0
nat outbound 3000 //A NAT policy is configured for the interface.
ipsec policy policy1
You can modify the configuration using either of the following methods:
l If NAT needs to be performed on data flows to the peer need before IPSec encryption,
change the source IP address in the ACL 3101 to the post-NAT IP address.
acl number 3101
rule permit ip source 1.1.1.0 0.0.0.255 destination 2.1.1.0 0.0.0.255
l If NAT does not need to be performed on data flows to the peer need before IPSec
encryption, add a deny policy to the ACL.
acl number 3000
rule 1 deny ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
rule 5 permit ip
Step 3 Check whether NAT traversal is enabled on both ends if a NAT device exists between both
ends.
Run the display ike peer command to check whether NAT traversal is enabled on both ends.
If not, run the nat traversal command in the IKE peer view.
[Huawei] display ike peer
Number of IKE peers: 1
------------------------------------------
Peer name : pa
IKE version : v1v2
VPN instance : -
Remote IP : 2.1.1.1
Authentic IP address : -
Proposal : tran1
Pre-shared-key : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY
%^%#
Local ID type :
IP
Local ID : -
Remote ID type : -
Remote ID : -
certificate peer-name : -
PKI realm : -
......
NAT-traversal : Disable
.......
[Huawei] ike peer pa
[Huawei-ike-peer-pa] nat traversal
Step 4 Check whether the security protocol is AH when a NAT device exists between both ends and
NAT traversal is enabled.
Run the display ipsec proposal brief command to check the security protocol. The security
protocol can only be ESP during NAT traversal.
If the security protocol is AH, run the transform command to change the security protocol to
ESP.
[Huawei] display ipsec proposal brief
Current ipsec proposal number: 1
---------------------------------------------------------
Proposal Name Encapsulation mode Transform
---------------------------------------------------------
tran1 Tunnel ah-new
[Huawei] ipsec proposal tran1
[Huawei-ipsec-proposal-tran1] transform esp
Step 5 Check whether the encryption/decryption modes on both ends are consistent if the
authentication algorithm used in an IPSec proposal is SHA2.
Run the display ipsec proposal command to check whether the authentication algorithm is
SHA2-256, SHA2-384, or SHA2-512.
[Huawei] display ipsec proposal
Number of proposals: 1
When IPSec uses the SHA-2 algorithm, if the devices on both ends of an IPSec tunnel are
from different vendors or run different software versions, they may use different encryption/
decryption modes. In this situation, IPSec traffic between the devices will be interrupted.
To solve the problem, run the ipsec authentication sha2 compatible enable command in the
system view to enable the SHA-2 algorithm to be compatible with earlier versions.
[Huawei] ipsec authentication sha2 compatible enable
----End