No relevant resource is found in the selected language.
Enterprise
Worldwide
Search
Support Documentation
Application of Firewalls in the LTE IPSec Solution
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Application of Firewalls in the LTE IPSec Solution

Application of Firewalls in the LTE IPSec Solution

Introduction

This section describes the applications of IPSec in the LTE and the IPSec configuration in the networking where hot standby devices are deployed in off-line mode.

This document is based on Eudemon200E-N&Eudemon1000E-N&Eudemon8000E-X V500R005C00 and can be used as a reference for Eudemon200E-N&Eudemon1000E-N&Eudemon8000E-X V500R005C00, Eudemon200E-G&Eudemon1000E-G V600R006C00, and later versions. Document content may vary according to version.

Solution Overview

Introduction to LTE

Long Term Evolution (LTE) is a project initiated by Third Generation Partnership Project (3GPP) in December 2004 for the long term evolution of the Universal Mobile Telecommunications System (UMTS). The objective of the project is to increase the data rate of mobile communications systems, reduce network nodes and the system complexity, and therefore cut down the CapEx and OpEx of networks. Since the analog technology was adopted in the 1G system, mobile communications networks have been through the revolution of 2G and 3G technologies and stepped into the 4G era. LTE has become a major 4G standard. Strictly, LTE does not meet the 4G definition of the ITU. It is only a quasi-4G technology. This, however, does not hold carriers back from setting LTE as the mainstream 4G standard.

Network Architecture of LTE

The network architecture of LTE is flatter and more IP-based than that of 3G networks, as shown in Figure 1-1.

Figure 1-1 Network architecture of LTE

An LTE network consists of the following parts:

  • User Equipment (UE): the general term for mobile terminals, such as mobile phones, smart phones, and multimedia devices, used on the LTE network
  • Evolved NodeB (eNodeB): wireless base station that provides wireless access services for users
  • IP-Radio Access Network (RAN): IP-based wireless access network. It is the access network of the entire LTE network.
  • Evolved Packet Core (EPC): the core network of LTE
    • Mobility Management Entity (MME): responsible for the control function of the core network. Traffic from the eNodeB to the EPC includes signaling flows and service flows, and the MME processes signaling traffic.
    • Serving Gateway (S-GW): processes the service traffic from the eNodeB to the EPC.
    • Operation and Maintenance Center (OMC): includes the M2000, CME, and LMT. The administrator manages the NEs on the LTE network in a centralized manner through the OMC. For the ease of management, some certificate servers, such as the CA server and RA server, are also deployed in the OMC area.

Interfaces of the eNodeB

The eNodeB provides two interfaces, S1 and X2:

  • S1 interface

    The S1 interface is between the MME/S-GW and the eNodeB. Based on the service plane, the S1 interface is further split to the S1 user plane interface and the S1 control plane interface.

    • S1 user plane interface (S1-U)

      The S1-U interface is between the eNodeB and the S-GW. It carries user data, also called service data, between the eNodeB and the S-GW. The S1-U works on the simple GTP over UDP/IP transport protocol. This protocol encapsulates user data. There is no mechanism for traffic control, error control, or other data transfer assurance on the S1-U interface.

    • S1 control plane interface (S1-C)

      The S1-C interface is between the eNodeB and the MME for controlling the signaling interaction between the eNodeB and the MME. For reliable transfer of signaling messages, the S1-C works on SCTP above the IP layer.

  • X2 interface

    The X2 interface is an interface for communication between eNodeBs. The X2 is a new interface defined by LTE. It is a mesh interface and enables inter-eNodeB packet forwarding when the terminal moves. This helps to reduce the packet loss rate.

    • X2 user plane interface (X2-U)

      The X2-U interface carries user data between eNodeBs. It is used for data forwarding only when a terminal moves from one eNodeB to another. The X2-U also works on GTP over UDP/IP.

    • X2 control plane interface (X2-C)

      The X2-C is a signaling interface between eNodeBs. It enables signaling interaction between the eNodeBs. The X2-C is related to user movement. It transfers the user context between eNodeBs. Like the S1-C, the X2-C also uses SCTP to ensure transmission.

Solution Design

Networking Requirements

On a 3G network, access authentication and data encryption mechanisms are available on the control and user planes from the UE to the RNC, and therefore, data transmission is secured. On an LTE network, although access authentication and data encryption mechanisms still work from the UE to the EPC, S1-U, on the user plane, has only authentication mechanisms but no encryption mechanisms. Therefore, compared with the 3G network, the LTE network requires additional security devices to eliminate security risks.

In the LTE IPSec solution, an IPSec tunnel is set up between the eNodeB and the security gateway (the FW, also referred to as the SeMG in LTE) to encrypt S1 data streams, preventing user data from being intruded on the IP-RAN and thereby ensuring the security of the LTE network. Generally, the FW is attached to both sides of a router in the EPC in off-path mode and serves as the IPSec gateway for the eNodeB to access the MME and S-GW. Two FWs are deployed in hot standby mode to improve the network stability. Figure 1-2 shows the network topology.

Figure 1-2 Network topology for off-path deployment of the FW

In the LTE IPSec solution, traffic on the eNodeB includes S1 traffic, X2 traffic, and OM traffic and PKI traffic for communication with the NMS. Considering the security and real-time performance, the carrier has different requirements for the processing of different types of traffic:

  • S1 traffic

    The S1 traffic is classified into user plane (S1 UP) traffic for voices and control plane (S1 CP) traffic for signaling. This traffic requires high security and therefore is transmitted over the IPSec tunnel.

  • X2 traffic

    The X2 traffic is burst traffic and does not require high security. This traffic can be either encrypted or not encrypted. In the present case, the X2 traffic is not IPSec-encrypted because the IPSec tunnel encapsulation increases its transmission delay.

  • OM traffic

    Network devices, including the eNodeB and FW are managed by the OM server in a centralized manner. This management traffic does not require protection of the IPSec tunnel. For example, a small jitter is required for the clock synchronization between the NTP server of the OM and the eNodeB, and therefore, IPSec encryption is inappropriate.

  • PKI traffic

    The PKI server issues certificates to the eNodeB and the IPSec gateway. When the eNodeB and the IPSec gateway establish an IPSec tunnel, they exchange certificates to verify the identity of each other. This traffic does not require IPSec protection either. It is sent by the eNodeB directly to the PKI server.

Figure 1-3 shows the transmission paths of different traffic.

Figure 1-3 Transmission of different eNodeB traffic in the LTE IPSec solution

Service Planning

IPSec Service Planning

In this solution, templates are used to establish IPSec tunnels. Table 1-1 describes IPSec service planning.

Table 1-1 IPSec service planning

Scheme

Strength and Weakness

Policy template

1. Allows simultaneous establishment of IPSec tunnels with multiple eNodeBs without the need to specify the remote IP address of the tunnel.

2. Requires a small amount of network configuration, easy to maintain.

In the case of a large quantity of eNodeBs, you may need to extend the address range in the ACL. When the ACL is being modified, the tunnel is interrupted for a short time. This can be overcome through reasonable data planning.

Certificate authentication

The eNodeB and security gateway use certificates for authentication to establish an IPSec tunnel. After hot standby is enabled, the active device needs to generate a key pair to apply for a device certificate. After the active device generates a key pair, the key pair is automatically backed up to the standby device. In addition, the devices share the same device certificate. When the active device loads the certificate, the certificate file will be automatically backed up to the standby device.

Availability Planning

The FW serves as the IPSec gateway to process all traffic from the eNodeB to the MME and the S-GW. It is a traffic forwarding hub in a critical position of the network. Therefore, two FWs are generally deployed in hot standby mode for active/standby backup. Besides the device backup solution, link backup is also used. For example, the Eth-Trunk link is adopted on the heartbeat interface between the two firewalls, which can not only improve the link bandwidth but also ensure data backup between the two firewalls when some links are faulty.

Figure 1-4 shows the networking of off-path deployment of the NGFW. Table 1-2 describes the availability planning.

Figure 1-4 Networking of off-path deployment
Table 1-2 Hot standby planning

Scheme

Strength

Implementation

Hot standby in active/standby mode

Dual-node deployment is more reliable than standalone deployment.

-

Link bundling

Multiple links are more reliable than a single link.

The Eth-Trunk increases the link bandwidth. The multiple member interfaces of the Eth-Trunk also implement link backup. When one member interface fails, traffic can still be carried over other member interfaces.

Eth-Trunk bundling is applied between FW_A/FW_B and Router3/Router 4. Link bundling is applied on the heartbeat line between the FWs.

Remote disaster recovery

Remote backup is more reliable than only local backup.

When a large disaster takes place in one location, the disaster recovery device deployed in another location can take over to provide services.

(Optional)

Remote disaster recovery means multiple FWs are deployed in dual-node mode in different geographical locations.

Data Planning

For the networking shown in Figure 1-5, the data planning for the network devices is described in Table 1-3.

When the FW uses a common physical interface to establish an IPSec tunnel with the eNodeB, if the active NGFW fails, an active/standby switchover is triggered. When the eNodeB learns that the active NGFW has failed, it tears down the IPSec tunnel with the active NGFW and sends an IPSec negotiation request to the new active NGFW (the originally standby one). In this process, the administrator needs to modify the remote address of the IPSec tunnel on the eNodeB to the IP address of the new active NGFW. However, modifying the configuration of the eNodeB manually is not easy. It seems feasible when there are only a small number of eNodeBs, but in practice, there are usually hundreds and even thousands of eNodeBs, modifying their configuration one by one is not practical.

Therefore, in the present case, the FW uses the Tunnel interface to establish an IPSec tunnel with the eNodeB. The Tunnel interfaces of FW_A and FW_B share the same IP address. When the Tunnel interface is used, even if an active/standby switchover happens, because the Tunnel interfaces of the two firewalls have the same IP address, it is not necessary to modify the remote IP address of the IPSec tunnel on the eNodeB.

Figure 1-5 IP address planning for off-path deployment of the NGFW
Table 1-3 Data planning of the LTE network

Device

Interface

IP Address

Security Zone

FW_A

Eth-trunk1

Member interfaces of Eth-Trunk1: GigabitEthernet1/0/1 and GigabitEthernet1/0/2

IP address of Eth-Trunk1.1: 1.1.1.1/30

VLAN:100

Eth-Trunk1.1 processes encrypted IPSec traffic sent by the eNodeB to the EPC.

Eth-Trunk1.1: Untrust

Eth-Trunk1.2: Trust

Eth-Trunk1.3: Trust

Eth-Trunk1.4: Trust

IP address of Eth-Trunk1.2: 1.1.2.1/30

VLAN:200

Eth-Trunk1.2 processes decrypted service traffic sent by the eNodeB to the S-GW.

IP address of Eth-Trunk1.3: 1.1.3.1/30

VLAN:300

Eth-Trunk1.3 processes decrypted signaling traffic sent by the eNodeB to the MME.

IP address of Eth-Trunk1.4: 1.1.4.1/30

VLAN:400

Eth-Trunk1.4 processes the management traffic exchanged between FW_A and the OM server.

Eth-trunk2

Member interfaces of Eth-Trunk2: GigabitEthernet1/0/8 and GigabitEthernet2/0/8

2.1.1.1/30

DMZ

Tunnel interface

Used for setting up an IPSec tunnel with the eNodeB.

3.1.1.1/30

Untrust

FW_B

Eth-trunk1

Member interfaces of Eth-Trunk2: GigabitEthernet1/0/1 and GigabitEthernet1/0/2

IP address of Eth-Trunk1.1: 5.1.1.1/30

VLAN: 100

Eth-Trunk1.1 processes encrypted IPSec traffic sent by the eNodeB to the EPC after the active/standby device switchover.

Eth-Trunk1.1: Untrust

Eth-Trunk1.2: Trust

Eth-Trunk1.3: Trust

Eth-Trunk1.4: Trust

IP address of Eth-Trunk1.2: 5.1.2.1/30

VLAN: 200

Eth-Trunk1.2 processes decrypted service traffic sent by the eNodeB to the S-GW after the active/standby device switchover.

IP address of Eth-Trunk1.3: 5.1.3.1/30

VLAN: 300

Eth-Trunk1.3 processes decrypted signaling traffic sent by the eNodeB to the MME after the active/standby device switchover.

IP address of Eth-Trunk1.4: 5.1.4.1/30

VLAN: 400

Eth-Trunk1.4 processes the management traffic exchanged between FW_B and the OM server.

Eth-Trunk2

Member interfaces of Eth-Trunk2: GigabitEthernet1/0/8 and GigabitEthernet2/0/8

2.1.1.2/30

DMZ

Tunnel interface

Used for setting up an IPSec tunnel with the eNodeB.

3.1.1.1/30

Untrust

eNodeB-1

1 Tunnel interface + 3 service interfaces

Tunnel IP: 6.1.1.1/30

UP service IP: 6.1.2.1/32

CP service IP: 6.1.3.1/32

OM service IP: 6.1.4.1/30

Tunnel interface: Untrust

Service interfaces: Trust

eNodeB-2

1 Tunnel interface + 3 service interfaces

Tunnel IP: 7.1.1.1/30

UP service IP: 7.1.2.1/32

CP service IP: 7.1.3.1/32

OM service IP: 7.1.4.1/30

Tunnel interface: Untrust

Service interfaces: Trust

S-GW

S1-U interface

8.1.1.1/30

-

MME

S1-C interface

8.1.1.2/30

-

OM

U2000

9.1.1.1/30

-

NTP Server

9.1.1.2/30

-

Log Server

9.1.1.3/30

-

PKI

CA

9.1.2.4/30

-

Route Planning

After two FWs are deployed on the LTE network in hot standby in off-line mode, the encrypted traffic from the eNodeB to the MME and S-GW (the EPC) should first be routed to the FW, and then the FW decrypts the traffic and sends the decrypted traffic back to the EPC. Routing decides the direction of the traffic. To route the traffic along an expected line, it is necessary to plan the routes on the FW and the RSG as shown in Figure 1-6.

Create two OSPF processes, OSPF1 and OSPF2, on the FW. OSPF1 advertises the IPSec gateway route of the FW to the IP-RAN so that the eNodeB acquires the route to the FW. OSPF2 is used for route exchange between the FW and the EPC. The FW forwards decrypted traffic to the EPC according to this route. The Eth-Trunk sub-interfaces between the NGFW and the RSG differentiate IPSec encrypted traffic, decrypted traffic to the S-GW, and decrypted traffic to the MME.

Figure 1-6 Route planning

  • Uplink traffic

    The uplink traffic from the eNodeB to the EPC relies on the following route exchange process. The process here is based on the line from eNodeB-1 through the IP-RAN, FW_A, and RSG-1 to the EPC.

    1. FW_A advertises the IPSec gateway route to OSPF1.
    2. RSG-1 imports the OSPF1 route to the BGP.
    3. RSG-1 advertises the IPSec gateway route to the AGG through the IBGP.
    4. The AGG receives the IPSec gateway route and advertises it on the IP-RAN.

      When the eNodeB forwards IPSec traffic to the IP-RAN through a static route, the IP-RAN learns the IPSec gateway route and routes the IPSec traffic all the way to FW_A.

      FW_A learns the route to the EPC through OSPF2. The uplink IPSec traffic is decrypted and is forwarded to the EPC along the route learnt through OSPF2.

  • Downlink traffic

    The downlink response traffic from the EPC to the eNodeB relies on the following route exchange process. The process here is based on the line from the EPC through RSG-1, FW_A, and the IP-RAN to eNodeB-1.

    1. After importing direct routes from the AN, the IP-RAN can learn the IPSec tunnel route to eNodeB-1.
    2. RSG-1 learns the IPSec tunnel route to eNodeB-1 from the IP-RAN through IBGP.
    3. RSG-1 imports the IPSec tunnel route to eNodeB-1 learnt by the IBGP to OSPF1. FW_A learns the IPSec tunnel route to eNodeB-1.

      The response traffic from the EPC to eNodeB-1 is forwarded to FW_A along the route learnt in OSPF2. The traffic enters the IPSec tunnel along the route learnt during reverse route injection of FW_A. NGFW_A forwards the encapsulated traffic to the IP-RAN along the route to eNodeB-1 learnt in OSPF1. The IP-RAN then forwards the traffic all the way to eNodeB-1.

In the hot standby scenario, the cost of the OSPF route advertised by the active IPSec gateway (FW_A) is the original one and is configurable, and the cost of the OSPF route advertised by the standby IPSec gateway (FW_B) is 65500. Therefore, the original cost of the OSPF route is generally smaller than 65500. When the traffic from the eNodeB to the EPC arrives at the RSG, the RSG selects a link with a smaller route cost to forward the traffic to FW_A. Because the Eth-Trunk sub-interface Trunk2.1 of RSG-1 and RSG-2 is added to OSPF1, the cost of OSPF1 is transferred among FW_A, RSG-1, RSG-2, and FW_B. Therefore, no matter whether the traffic from the eNodeB to the EPC arrives at RSG-1 or RSG-2, the RSG selects a link with a smaller cost to forward the traffic to FW_A. When FW_A fails, an active/standby switchover takes place, and the route costs are switched simultaneously. The traffic is still forwarded by the link with a smaller cost. The difference is that the traffic is forwarded to FW_B instead of FW_A.

Precautions

  • IPSec configuration
    • The tunnel address and service address of the eNodeB must be different.
    • If remote disaster recovery is not implemented, when you configure the tunnel route to the eNodeB for the FW, IPSec reverse route injection is no longer mandatory, and static routes can be used.
  • Networking

    In the current LTE IPSec solution, most FWs are deployed in hot standby in off-path mode while very few are deployed in in-path mode. This is because off-path deployment has less impact on the original network topology.

  • MTU

    IPSec encryption increases the packet length. Therefore, you must adjust the MTU of the entire path after the IPSec gateway is deployed. There are specifically two MTU adjustment schemes:

    • Reduce the MTU on the EPC side and the eNodeB side without changing it on other nodes. The strength of this scheme is that it involves only a small number of devices.
    • Increase the MTU on the intermediate IPCore, IP-RAN and transmission nodes. This scheme is advantageous in a high transmission efficiency and a small IPSec header per packet.

      Transmission efficiency = 1 - IPSec header/packet length. The IPSec header length is fixed. Therefore, a greater packet length indicates a higher transmission efficiency. The selection of an MTU adjustment scheme depends on the live network environment.

      The following figure shows the IPSec-encapsulated packet length.

      AES + MD5/SHA1: 20 (New IPHeader) + 4 (SPI) + 4 (SeqNum) + 16 (IV) + 16 (ESP Auth) + 2 to 17 (Padding) = 62 to 77 Bytes

      The ESP Auth length varies according to the integrity verification algorithm. The preceding calculation result is based on SHA2-256. SHA2-256 is the recommended integrity verification algorithm. The ESP Auth values in other encapsulation modes are MD5=12, SHA1=12, SHA2-256=16, SHA2-384=24, and SHA2-512=32. SHA2-384 and SHA2-512 are not recommended because they can cause the device running the current version to be unable to properly interwork with third-party devices.

      Packets are tagged with two layers of labels (eight bytes in all) when being transmitted over the IP-RAN. Therefore, after the packets encrypted by the IPSec gateway enter the IP-RAN, the packet lengths are increased to 70 to 85 bytes (calculated based on SHA2-256).

      For a new IP-RAN and IPCore project, you are advised to reserve 100 bytes more when designing the MTU. Therefore, if an IPSec gateway is deployed, you do not need to adjust the configuration of the IP-RAN and IPCore devices.

  • QoS

    In an end-to-end LTE solution, when uplink packets are decrypted from the IPSec tunnel, the DSCP of outer layer packets is mapped to the IP header of the decrypted packet. When downlink packets arrive at the IPSec gateway and are encapsulated with an IPSec header, the DSCP of inner layer packets is mapped to the outer layer packets. Therefore, it is not necessary for the IPSec gateway to change the QoS of the packets.

Solution Configuration

Configuring Interfaces and Security Zones

Context

Configure interfaces and security zones.

Figure 1-7 Interface IP addresses and security zones

Procedure

  1. Configure IP addresses for the interfaces of FW_A. 

    <FW_A> system-view 
[FW_A] sysname FW_A 
[FW_A] interface Eth-Trunk 1 
[FW_A-Eth-Trunk1] quit 
[FW_A] interface GigabitEthernet 1/0/1 
[FW_A-GigabitEthernet1/0/1] description eth-trunk1 
[FW_A-GigabitEthernet1/0/1] Eth-Trunk 1 
[FW_A] interface GigabitEthernet 1/0/2 
[FW_A-GigabitEthernet1/0/2] description eth-trunk1 
[FW_A-GigabitEthernet1/0/2] Eth-Trunk 1 
[FW_A-GigabitEthernet1/0/2] quit 
[FW_A] interface Eth-Trunk 2 
[FW_A-Eth-Trunk2] quit 
[FW_A] interface GigabitEthernet 1/0/8 
[FW_A-GigabitEthernet1/0/8] description eth-trunk2 
[FW_A-GigabitEthernet1/0/8] Eth-Trunk 2 
[FW_A-GigabitEthernet1/0/8] quit 
[FW_A] interface GigabitEthernet 2/0/8 
[FW_A-GigabitEthernet2/0/8] description eth-trunk2 
[FW_A-GigabitEthernet2/0/8] Eth-Trunk 2 
[FW_A-GigabitEthernet2/0/8] quit 
[FW_A] interface Eth-Trunk 1.1 
[FW_A-Eth-Trunk1.1] ip address 1.1.1.1 30 
[FW_A-Eth-Trunk1.1] vlan-type dot1q 100 
[FW_A-Eth-Trunk1.1] quit 
[FW_A] interface Eth-Trunk 1.2 
[FW_A-Eth-Trunk1.2] ip address 1.1.2.1 30 
[FW_A-Eth-Trunk1.2] vlan-type dot1q 200 
[FW_A-Eth-Trunk1.2] quit 
[FW_A] interface Eth-Trunk 1.3 
[FW_A-Eth-Trunk1.3] ip address 1.1.3.1 30 
[FW_A-Eth-Trunk1.3] vlan-type dot1q 300 
[FW_A-Eth-Trunk1.3] quit 
[FW_A] interface Eth-Trunk 1.4 
[FW_A-Eth-Trunk1.4] ip address 1.1.4.1 30 
[FW_A-Eth-Trunk1.4] vlan-type dot1q 400 
[FW_A-Eth-Trunk1.4] quit 
[FW_A] interface Eth-Trunk 2 
[FW_A-Eth-Trunk2] ip address 2.1.1.1 30 
[FW_A-Eth-Trunk2] quit 
[FW_A] interface Tunnel 1 
[FW_A-Tunnel1] ip address 3.1.1.1 30 
[FW_A-Tunnel1] tunnel-protocol ipsec 
[FW_A-Tunnel1] quit

  2. Assign the interfaces of FW_A to security zones. 

    [FW_A] firewall zone trust 
[FW_A-zone-trust] add interface Eth-Trunk 1.2 
[FW_A-zone-trust] add interface Eth-Trunk 1.3 
[FW_A-zone-trust] add interface Eth-Trunk 1.4 
[FW_A-zone-trust] quit 
[FW_A] firewall zone untrust 
[FW_A-zone-untrust] add interface Eth-Trunk 1.1 
[FW_A-zone-untrust] add interface Tunnel 1 
[FW_A-zone-untrust] quit 
[FW_A] firewall zone dmz 
[FW_A-zone-dmz] add interface Eth-Trunk 2 
[FW_A-zone-dmz] quit

  3. Configure the IP addresses and security zones of the interfaces of FW_B according to the above procedure. Note that the IP addresses of the interfaces are different.

Configuring Hot Standby

Context

Complete the hot standby configuration according to the figure below.

Figure 1-8 Hot standby networking

Procedure

  1. Configure hot standby.

    # Configure hot standby on FW_A.

    1. Configure a VGMP group to monitor Eth-Trunk1.
      [FW_A] hrp track interface Eth-Trunk 1
    2. Enable the VGMP group state-based OSPF cost adjustment function. 
      [FW_A] hrp adjust ospf-cost enable
    3. Specify Eth-Trunk2 as the heartbeat interface and enable hot standby. 
      [FW_A] hrp interface Eth-Trunk 2 remote 2.1.1.2 
HRP_M[FW_A] hrp enable

    # Configure hot standby on FW_B.

    1. Configure a VGMP group to monitor Eth-Trunk1.
      [FW_B] hrp track interface Eth-Trunk 1
    2. Specify FW_B as the standby firewall. 
      [FW_B] hrp standby-device
    3. Enable the VGMP group state-based OSPF cost adjustment function. 
      [FW_B] hrp adjust ospf-cost enable
    4. Specify Eth-Trunk2 as the heartbeat interface and enable hot standby. 
      [FW_B] hrp interface Eth-Trunk 2 remote 2.1.1.1 
HRP_S[FW_B] hrp enable

  2. Configure OSPF.

    # Configure OSPF on FW_A.

    HRP_M[FW_A] router id 1.1.1.1 
HRP_M[FW_A] ospf 1 
HRP_M[FW_A-ospf-1] area 1.1.1.1 
HRP_M[FW_A-ospf-1-area-1.1.1.1] network 1.1.1.1 0.0.0.3 
HRP_M[FW_A-ospf-1-area-1.1.1.1] network 3.1.1.1 0.0.0.3 
HRP_M[FW_A-ospf-1-area-1.1.1.1] quit 
HRP_M[FW_A-ospf-1] quit

    # Configure OSPF on FW_B.

    HRP_S[FW_A] router id 5.5.5.1 
HRP_S[FW_A] ospf 1 
HRP_S[FW_A-ospf-1] area 1.1.1.1 
HRP_S[FW_A-ospf-1-area-1.1.1.1] network 5.1.1.1 0.0.0.3 
HRP_S[FW_A-ospf-1-area-1.1.1.1] network 3.1.1.1 0.0.0.3 
HRP_S[FW_A-ospf-1-area-1.1.1.1] quit 
HRP_S[FW_A-ospf-1] quit

Configuring IPSec

Procedure

  1. Configure IPSec on FW_A.

    1. Apply for certificates online for FW_A using CMPv2.
      1. Create a 2048-bit RSA key pair rsa_cmp, and set it to be exportable from the device.
        HRP_M[FW_A] pki rsa local-key-pair create rsa_cmp exportable
 Info: The name of the new key-pair will be: rsa_cmp                            
 The size of the public key ranges from 2048 to 4096.                             
 Input the bits in the modules:2048                                              
 Generating key-pairs...                                                         
...........+++                                                                   
...........+++
      2. Configure entity information. 
        HRP_M[FW_A] pki entity ngfwa 
HRP_M[FW_A-pki-entity-ngfwa] common-name hello 
HRP_M[FW_A-pki-entity-ngfwa] country cn 
HRP_M[FW_A-pki-entity-ngfwa] email test@user.com 
HRP_M[FW_A-pki-entity-ngfwa] fqdn test.abc.com 
HRP_M[FW_A-pki-entity-ngfwa] ip-address 3.1.1.1 
HRP_M[FW_A-pki-entity-ngfwa] state jiangsu 
HRP_M[FW_A-pki-entity-ngfwa] organization huawei 
HRP_M[FW_A-pki-entity-ngfwa] organization-unit info 
HRP_M[FW_A-pki-entity-ngfwa] quit

      3. Configure a CMP session.

        The field order in the CA name must be the same as that in the CA certificate; otherwise, the server considers the CA name invalid.

        # Create a CMP session named cmp.
HRP_M[FW_A] pki cmp session ngfwa
# Specify the PKI entity name referenced by the CMP session.
HRP_M[FW_A-pki-cmp-session-ngfwa] cmp-request entity ngfwa
# Configure a CA name, for example, C=cn,ST=jiangsu,L=SD,O=BB,OU=BB,CN=BB.
HRP_M[FW_A-pki-cmp-session-ngfwa] cmp-request ca-name "C=cn,ST=jiangsu,L=SD,O=BB,OU=BB,CN=BB"
# Configure the URL for certificate application.
HRP_M[FW_A-pki-cmp-session-ngfwa] cmp-request server url http://9.1.2.4:8080
# Specify the RSA key pair used for certificate application and configure the device to update the RSA key pair together with the certificate.
HRP_M[FW_A-pki-cmp-session-ngfwa] cmp-request rsa local-key-pair rsa_cmp regenerate
# When applying for a certificate for the first time, use the message authentication code for authentication. Set the reference value and secret value of the message authentication code, for example, 1234 and 123456.
HRP_M[FW_A-pki-cmp-session-ngfwa] cmp-request message-authentication-code 1234 123456
HRP_M[FW_A-pki-cmp-session-ngfwa] quit
# Submit an initial certificate request to the CMPv2 server based on the CMP session configuration.
HRP_M[FW_A] pki cmp initial-request session ngfwa
HRP_M[FW_A]                   
 Info: Initializing configuration.                                              
 Info: Creatting initial request packet.                                        
 Info: Connectting to CMPv2 server.                                             
 Info: Sending initial request packet.                                          
 Info: Waitting for initial response packet.                                    
 Info: Creatting confirm packet.                                                
 Info: Connectting to CMPv2 server.                                             
 Info: Sending confirm packet.                                                  
 Info: Waitting for confirm packet from server.                                 
 Info: CMPv2 operation finish.

        The obtained CA, RA and local certificates are named ngfwa_ca.cer, ngfw_ra.cer, and ngfwa_local.cer respectively and stored in the CF card.

      4. Install the certificates.

        # Import the CA and RA certificates to the memory.

        HRP_M[FW_A] pki import-certificate ca filename ngfwa_ca.cer 
HRP_M[FW_A] pki import-certificate ca filename ngfw_ra.cer

        # Import the local certificate to the memory.

        HRP_M[FW_A] pki import-certificate local filename ngfwa_local.cer
    2. Configure an IPSec policy on FW_A, and apply the IPSec policy to the interfaces.
      1. Define the protected data streams.

        There may be hundreds or even thousands of eNodeBs serving on the live network. During ACL rule definition, the destination network segment must include the Service IP addresses of all eNodeBs to ensure all UP and CP traffic returned by the EPC to the eNodeB enters the IPSec tunnel. Two eNodeBs are used to illustrate the configuration.

        HRP_M[FW_A] acl 3000 
HRP_M[FW_A-acl-adv-3000] rule permit ip source 8.1.1.0 0.0.0.255 destination 6.1.0.0 0.0.255.255 
HRP_M[FW_A-acl-adv-3000] rule permit ip source 8.1.1.0 0.0.0.255 destination 7.1.0.0 0.0.255.255 
HRP_M[FW_A-acl-adv-3000] quit
      2. Configure the IPSec proposal. 
        HRP_M[FW_A] ipsec proposal tran1 
HRP_M[FW_A-ipsec-proposal-tran1] transform esp 
HRP_M[FW_A-ipsec-proposal-tran1] esp authentication-algorithm sha2-256 
HRP_M[FW_A-ipsec-proposal-tran1] esp encryption-algorithm aes-256 
HRP_M[FW_A-ipsec-proposal-tran1] encapsulation-mode tunnel 
HRP_M[FW_A-ipsec-proposal-tran1] quit
      3. Configure the IKE proposal. 
        HRP_M[FW_A] ike proposal 10 
HRP_M[FW_A-ike-proposal-10] authentication-method rsa-signature 
HRP_M[FW_A-ike-proposal-10] encryption-algorithm aes-256 
HRP_M[FW_A-ike-proposal-10] dh group2 
HRP_M[FW_A-ike-proposal-10] integrity-algorithm hmac-sha2-256 
HRP_M[FW_A-ike-proposal-10] quit
      4. Configure the IKE peer. 
        HRP_M[FW_A] ike peer eNodeB 
HRP_M[FW_A-ike-peer-eNodeB] ike-proposal 10 
HRP_M[FW_A-ike-peer-eNodeB] local-id-type ip 
HRP_M[FW_A-ike-peer-eNodeB] remote-id-type dn 
HRP_M[FW_A-ike-peer-eNodeB] certificate local-filename ngfwa_local.cer 
HRP_M[FW_A-ike-peer-eNodeB] remote-id /CN=eNodeB //CN=eNodeB is the subject field value of the device certificate of the eNodeB. 
HRP_M[FW_A-ike-peer-eNodeB] undo version 1 
HRP_M[FW_A-ike-peer-eNodeB] quit
      5. Configure policy template policy1, and reference the policy template in IPSec policy group map1.

        The FW is capable of IPSec dynamic reverse route injection to automatically generate the route to the Service IP address of the eNodeB. When the IPSec tunnel functions normally, the route is generated automatically; when the IPSec tunnel fails, the route is deleted automatically. Dynamic reverse route injection associates the generated static route with the IPSec tunnel state, so that the peer does not send traffic to the IPSec tunnel when the IPSec tunnel is Down.

        HRP_M[FW_A] ipsec policy-template policy1 1 
HRP_M[FW_A-ipsec-policy-template-policy1-1] security acl 3000 
HRP_M[FW_A-ipsec-policy-template-policy1-1] proposal tran1 
HRP_M[FW_A-ipsec-policy-template-policy1-1] ike-peer eNodeB 
HRP_M[FW_A-ipsec-policy-template-policy1-1] route inject dynamic 
HRP_M[FW_A-ipsec-policy-template-policy1-1] quit 
HRP_M[FW_A] ipsec policy map1 10 isakmp template policy1
      6. Configure the OSPF dynamic route to the EPC.

        Import the route generated during IPSec dynamic reverse route injection to OSPF2 to guide the forwarding of the response traffic of the EPC to the eNodeB. Set the next hop of the route to the Tunnel interface of the IPSec tunnel.

        HRP_M[FW_A] ospf 2 
HRP_M[FW_A-ospf-2] import-route unr 
HRP_M[FW_A-ospf-2] area 1.1.1.1 
HRP_M[FW_A-ospf-2-area-1.1.1.1] network 1.1.2.0 0.0.0.3 
HRP_M[FW_A-ospf-2-area-1.1.1.1] quit 
HRP_M[FW_A-ospf-2] area 1.1.2.1 
HRP_M[FW_A-ospf-2-area-1.1.2.1] network 1.1.3.0 0.0.0.3 
HRP_M[FW_A-ospf-2-area-1.1.2.1] quit 
HRP_M[FW_A-ospf-2] area 1.1.3.1 
HRP_M[FW_A-ospf-2-area-1.1.3.1] network 1.1.4.0 0.0.0.3 
HRP_M[FW_A-ospf-2-area-1.1.3.1] quit 
HRP_M[FW_A-ospf-2] quit
      7. Apply the security policy group map1 to the Tunnel interface. 
        HRP_M[FW_A] interface Tunnel 1 
HRP_M[FW_A-Tunnel1] ipsec policy map1 
HRP_M[FW_A-Tunnel1] quit

  2. Configure IPSec on FW_B.

    After hot standby is enabled, all configuration information of FW_A except the route configuration is synchronized to FW_B automatically.

    Import the route generated during IPSec dynamic reverse route injection to OSPF2 to guide the forwarding of the response traffic of the EPC to the eNodeB. Set the next hop of the route to the Tunnel interface of the IPSec tunnel.

    HRP_M[FW_B] ospf 2 
HRP_M[FW_B-ospf-2] import-route unr 
HRP_M[FW_B-ospf-2] area 1.1.1.1 
HRP_M[FW_B-ospf-2-area-1.1.1.1] network 5.1.2.0 0.0.0.3 
HRP_M[FW_B-ospf-2-area-1.1.1.1] quit 
HRP_M[FW_B-ospf-2] area 1.1.2.1 
HRP_M[FW_B-ospf-2-area-1.1.2.1] network 5.1.3.0 0.0.0.3 
HRP_M[FW_B-ospf-2-area-1.1.2.1] quit 
HRP_M[FW_B-ospf-2] area 1.1.3.1 
HRP_M[FW_B-ospf-2-area-1.1.3.1] network 5.1.4.0 0.0.0.3 
HRP_M[FW_B-ospf-2-area-1.1.3.1] quit 
HRP_M[FW_B-ospf-2] quit

Configuring Security Policies

Procedure

  1. Configure security policies.

    1. Configure a security policy among the Trust, Untrust and Local zones, allowing OSPF packets to pass through FW_A. 
      HRP_M[FW_A] security-policy 
HRP_M[FW_A-policy-security] rule name 1 
HRP_M[FW_A-policy-security-rule-1] source-zone trust 
HRP_M[FW_A-policy-security-rule-1] source-zone untrust 
HRP_M[FW_A-policy-security-rule-1] destination-zone local 
HRP_M[FW_A-policy-security-rule-1] service ospf 
HRP_M[FW_A-policy-security-rule-1] action permit 
HRP_M[FW_A-policy-security-rule-1] quit 
HRP_M[FW_A-policy-security] rule name 2 
HRP_M[FW_A-policy-security-rule-2] source-zone local 
HRP_M[FW_A-policy-security-rule-2] destination-zone trust 
HRP_M[FW_A-policy-security-rule-2] destination-zone untrust 
HRP_M[FW_A-policy-security-rule-2] service ospf 
HRP_M[FW_A-policy-security-rule-2] action permit 
HRP_M[FW_A-policy-security-rule-2] quit
    2. Configure a security policy between the Untrust and Local zones, allowing IPSec negotiation packets to pass through FW_A. 
      HRP_M[FW_A] security-policy 
HRP_M[FW_A-policy-security] rule name 3 
HRP_M[FW_A-policy-security-rule-3] source-zone local 
HRP_M[FW_A-policy-security-rule-3] destination-zone untrust 
HRP_M[FW_A-policy-security-rule-3] source-address 3.1.1.1 32 
HRP_M[FW_A-policy-security-rule-3] destination-address 6.1.1.1 30 
HRP_M[FW_A-policy-security-rule-3] destination-address 7.1.1.1 30 
HRP_M[FW_A-policy-security-rule-3] action permit 
HRP_M[FW_A-policy-security-rule-3] quit 
HRP_M[FW_A-policy-security] rule name 4 
HRP_M[FW_A-policy-security-rule-4] source-zone untrust 
HRP_M[FW_A-policy-security-rule-4] destination-zone local 
HRP_M[FW_A-policy-security-rule-4] source-address 6.1.1.1 30 
HRP_M[FW_A-policy-security-rule-4] source-address 7.1.1.1 30 
HRP_M[FW_A-policy-security-rule-4] destination-address 3.1.1.1 32 
HRP_M[FW_A-policy-security-rule-4] action permit 
HRP_M[FW_A-policy-security-rule-4] quit
    3. Configure a security policy between the Untrust and Trust zones, allowing decapsulated IPSec traffic to pass through FW_A. 
      HRP_M[FW_A] security-policy 
HRP_M[FW_A-policy-security] rule name 5 
HRP_M[FW_A-policy-security-rule-5] source-zone untrust 
HRP_M[FW_A-policy-security-rule-5] destination-zone trust 
HRP_M[FW_A-policy-security-rule-5] source-address 6.1.0.0 16 
HRP_M[FW_A-policy-security-rule-5] source-address 7.1.0.0 16 
HRP_M[FW_A-policy-security-rule-5] destination-address 8.1.1.1 30 
HRP_M[FW_A-policy-security-rule-5] action permit 
HRP_M[FW_A-policy-security-rule-5] quit 
HRP_M[FW_A-policy-security] rule name 6 
HRP_M[FW_A-policy-security-rule-6] source-zone trust 
HRP_M[FW_A-policy-security-rule-6] destination-zone untrust 
HRP_M[FW_A-policy-security-rule-6] source-address 8.1.1.1 30 
HRP_M[FW_A-policy-security-rule-6] destination-address 6.1.0.0 16 
HRP_M[FW_A-policy-security-rule-6] destination-address 7.1.0.0 16 
HRP_M[FW_A-policy-security-rule-6] action permit 
HRP_M[FW_A-policy-security-rule-6] quit

Configuring the Interworking with Servers

Procedure

  1. Configure the interworking with the NTP server. 

    HRP_M[FW_A] ntp-service unicast-server 9.1.1.2

  2. Configure the interworking with the log server. 

    HRP_M[FW_A] log type traffic enable 
HRP_M[FW_A] firewall log host 1 9.1.1.3 9002

Verification

  1. After the configuration is complete, the IPSec tunnel between the eNodeB and FW_A is successfully established, and the MME and S-GW can be accessed.
  2. Check the setup of the IKE SA on FW_A. 
    <FW_A> display ike sa       
Spu board slot 1, cpu 0 ike sa information :   
    Conn-ID      Peer           VPN   Flag(s)                Phase
  ---------------------------------------------------------------  
    16792025    6.1.1.1               RD|ST|M                v2:2
    16792024    6.1.1.1               RD|ST|M                v2:1
    83887864    7.1.1.1               RD|ST|M                v2:2 
    83887652    7.1.1.1               RD|ST|M                v2:1
      
  Number of SA entries  : 4  
  Number of SA entries of all cpu : 4
  3. Check the setup of the IPSec SA on FW_A. 
    <FW_A> display ipsec sa brief 
Current ipsec sa num:4 
 
 Spu board slot 1, cpu 1 ipsec sa information: 
Number of SAs:2       
    Src address   Dst address     SPI      VPN  Protocol     Algorithm 
-------------------------------------------------------------------------------  
     3.1.1.1        6.1.1.1    3923280450        ESP       E:AES-256 A:SHA2-256-128 
     6.1.1.1        3.1.1.1    787858613         ESP       E:AES-256 A:SHA2-256-128 
     3.1.1.1        7.1.1.1    3923280452        ESP       E:AES-256 A:SHA2-256-128 
     7.1.1.1        3.1.1.1    787858611         ESP       E:AES-256 A:SHA2-256-128
  4. Run the display hrp state command on FW_A to check the current HRP state. 
    HRP_M[FW_A] display hrp state 
 Role: active, peer: active    
 Running priority: 49012, peer: 49012     
 Backup channel usage: 3%    
 Stable time: 0 days, 5 hours, 1 minutes

Configuration Scripts

FW_A

FW_B

 
#
sysname FW_A
#
hrp enable
hrp interface Eth-Trunk 2 remote 2.1.1.2
hrp track interface Eth-Trunk 1

hrp adjust ospf-cost enable
#
pki entity ngfwa
 country CN
 state jiangsu
 organization huawei
 organization-unit info
 common-name hello
 fqdn test.abc.com
 ip-address 3.1.1.1
 email test@user.com
#
pki cmp session ngfwa
 cmp-request entity ngfwa
 cmp-request ca-name  "C=cn,ST=jiangsu,L=SD,O=BB,OU=BB,CN=BB"
 cmp-request server url http://9.1.2.4:8080
 cmp-request rsa local-key-pair rsa_cmp regenerate
 cmp-request message-authentication-code 1234 123456
#
pki cmp initial-request session ngfwa
#
pki import-certificate ca filename ngfwa_ca.cer
pki import-certificate ca filename ngfw_ra.cer
pki import-certificate local filename ngfwa_local.cer
#
acl number 3000
 rule 5 permit ip source 8.1.1.0 0.0.0.255  destination 6.1.0.0 0.0.255.255
 rule 10 permit ip source 8.1.1.0 0.0.0.255 destination 7.1.0.0 0.0.255.255
#
ipsec proposal tran1
 esp authentication-algorithm sha2-256
 esp encryption-algorithm aes-256
#
ike proposal 10
 encryption-algorithm aes-256
 dh group2
 authentication-algorithm sha2-256
 authentication-method rsa-signature
 integrity-algorithm hmac-sha2-256
 prf hmac-sha2-256
#
ike peer eNodeB
 undo version 1
 ike-proposal 10
 local-id-type ip
 remote-id-type dn
 remote-id /CN=eNodeB
 certificate local-filename ngfwa_local.cer
#
ipsec policy-template policy1 1
 security acl 3000
 ike-peer eNodeB
 proposal tran1
 route inject dynamic
#
ipsec policy map1 10 isakmp template policy1
#
interface Eth-Trunk 1
#
interface GigabitEthernet 1/0/1
 description eth-trunk1
 Eth-Trunk 1
#
interface GigabitEthernet 1/0/2
 description eth-trunk1
 Eth-Trunk 1
#
interface Eth-Trunk 2
 ip address 2.1.1.1 255.255.255.252
#
interface GigabitEthernet 1/0/8
 description eth-trunk2
 Eth-Trunk 2
#
interface GigabitEthernet 2/0/8
 description eth-trunk2
 Eth-Trunk 2
#
interface Eth-Trunk 1.1
 vlan-type dot1q 100
 ip address 1.1.1.1 255.255.255.252
#
interface Eth-Trunk 1.2
 vlan-type dot1q 200
 ip address 1.1.2.1 255.255.255.252
#
interface Eth-Trunk 1.3
 vlan-type dot1q 300
 ip address 1.1.3.1 255.255.255.252
#
interface Eth-Trunk 1.4
 vlan-type dot1q 400
 ip address 1.1.4.1 255.255.255.252
#
interface Tunnel 1
 ip address 3.1.1.1 255.255.255.252
 tunnel-protocol ipsec
 ipsec policy map1
#
router id 1.1.1.1
#
ospf 1
 area 1.1.1.1
 network 1.1.1.0 0.0.0.3
 network 3.1.1.0 0.0.0.3
#
ospf 2
 import-route unr
 area 1.1.1.1
 network 1.1.2.0 0.0.0.3
 area 1.1.2.1
 network 1.1.3.0 0.0.0.3
 area 1.1.3.1
 network 1.1.4.0 0.0.0.3
#
ntp-service unicast-server 9.1.1.2
#
log type traffic enable
firewall log host 1 9.1.1.3 9002
#
info-center enable
snmp-agent
snmp-agent sys-info version v2c
snmp-agent target-host inform address udp-domain 9.1.1.1 params securitynam e private@123 v2c
#
firewall zone trust
 set priority 85
 add interface Eth-Trunk1.2
 add interface Eth-Trunk1.3
 add interface Eth-Trunk1.4
#
firewall zone untrust
 set priority 85
 add interface Eth-Trunk1.1
 add interface Tunnel1
#
firewall zone dmz
 set priority 50
 add interface Eth-Trunk2
#
security-policy
 rule name 1
  source-zone trust
  source-zone untrust
  destination-zone local
  service ospf
  action permit
 rule name 2
  source-zone local
  destination-zone trust
  destination-zone untrust
  service ospf
  action permit
 rule name 3
  source-zone local
  destination-zone untrust
  source-address 3.1.1.1 32
  destination-address 6.1.1.1 30
  destination-address 7.1.1.1 30
  action permit
  rule name 4
  source-zone untrust
  destination-zone local
  source-address 6.1.1.1 30
  source-address 7.1.1.1 30
  destination-address 3.1.1.1 32
  action permit
 rule name 5
  source-zone untrust
  destination-zone trust
  source-address 6.1.0.0 16
  source-address 7.1.0.0 16
  destination-address 8.1.1.1 30
  action permit
 rule name 6
  source-zone trust
  destination-zone untrust
  source-address 8.1.1.1 30
  destination-address 6.1.0.0 16
  destination-address 7.1.0.0 16
  action permit
#
return
 
#
sysname FW_B
#
hrp enable
hrp interface Eth-Trunk 2 remote 2.1.1.1
hrp track interface Eth-Trunk 1
hrp standby-device
hrp adjust ospf-cost enable
#
pki entity ngfwa
 country CN
 state jiangsu
 organization huawei
 organization huaweiorganization-unit info
 common-name hello
 fqdn test.abc.com
 ip-address 3.1.1.1
 email test@user.com
#
pki cmp session ngfwa
 cmp-request entity ngfwa
 cmp-request ca-name  "C=cn,ST=jiangsu,L=SD,O=BB,OU=BB,CN=BB"
 cmp-request server url http://9.1.2.4:8080
 cmp-request rsa local-key-pair rsa_cmp regenerate
 cmp-request message-authentication-code 1234 123456
#
pki cmp initial-request session ngfwa
#
pki import-certificate ca filename ngfwa_ca.cer
pki import-certificate ca filename ngfw_ra.cer
pki import-certificate local filename ngfwa_local.cer
#
acl number 3000
 rule 5 permit ip source 8.1.1.0 0.0.0.255 destination 6.1.0.0 0.0.255.255
 rule 10 permit ip source 8.1.1.0 0.0.0.255 destination 7.1.0.0 0.0.255.255
#
ipsec proposal tran1
 esp authentication-algorithm sha2-256
 esp encryption-algorithm aes-256
#
ike proposal 10
 encryption-algorithm aes-256
 dh group2
 authentication-algorithm sha2-256
 authentication-method rsa-signature
 integrity-algorithm hmac-sha2-256
 prf hmac-sha2-256
#
ike peer eNodeB
 undo version 1
 ike-proposal 10
 local-id-type ip
 remote-id-type dn
 remote-id /CN=eNodeB
 certificate local-filename ngfwa_local.cer
#
ipsec policy-template policy1 1
 security acl 3000
 ike-peer eNodeB
 proposal tran1
 route inject dynamic
#
ipsec policy map1 10 isakmp template policy1
#
interface Eth-Trunk 1
#
interface GigabitEthernet 1/0/1
 description eth-trunk1
 Eth-Trunk 1
#
interface GigabitEthernet 1/0/2
 description eth-trunk1
 Eth-Trunk 1
#
interface Eth-Trunk 2
 ip address 2.1.1.2 255.255.255.252
#
interface GigabitEthernet 1/0/8
 description eth-trunk2
 Eth-Trunk 2
#
interface GigabitEthernet 2/0/8
 description eth-trunk2
 Eth-Trunk 2
#
interface Eth-Trunk 1.1
 vlan-type dot1q 1
 ip address 5.1.1.1 255.255.255.252
#
interface Eth-Trunk 1.2
 vlan-type dot1q 2
 ip address 5.1.2.1 255.255.255.252
#
interface Eth-Trunk 1.3
 vlan-type dot1q 3
 ip address 5.1.3.1 255.255.255.252
#
interface Eth-Trunk 1.4
 vlan-type dot1q 4
 ip address 5.1.4.1 255.255.255.252
#
interface Tunnel 1
 ip address 3.1.1.1 255.255.255.252
 tunnel-protocol ipsec
 ipsec policy map1
#
router id 5.1.1.1
#
ospf 1
 area 1.1.1.1
 network 5.1.1.0 0.0.0.3
 network 3.1.1.0 0.0.0.3
#
ospf 2
import-route unr
 area 1.1.1.1
 network 5.1.2.0 0.0.0.3
 area 1.1.2.1
 network 5.1.3.0 0.0.0.3
 area 1.1.3.1
 network 5.1.4.0 0.0.0.3
#
ntp-service unicast-server 9.1.1.2
#
log type traffic enable
firewall log host 1 9.1.1.3 9002
#
info-center enable
snmp-agent
snmp-agent sys-info version v2c
snmp-agent target-host inform address udp-domain 9.1.1.1 params securitynam e private@123 v2c
#
firewall zone trust
 set priority 85
 add interface Eth-Trunk1.2
 add interface Eth-Trunk1.3
 add interface Eth-Trunk1.4
#
firewall zone untrust
 set priority 85
 add interface Eth-Trunk1.1
 add interface Tunnel1
#
firewall zone dmz
 set priority 50
 add interface Eth-Trunk2
#
security-policy
 rule name 1
  source-zone trust
  source-zone untrust
  destination-zone local
  service ospf
  action permit
 rule name 2
  source-zone local
  destination-zone trust
  destination-zone untrust
  service ospf
  action permit
 rule name 3
  source-zone local
  destination-zone untrust
  source-address 3.1.1.1 32
  destination-address 6.1.1.1 30
  destination-address 7.1.1.1 30
  action permit
 rule name 4
  source-zone untrust
  destination-zone local
  source-address 6.1.1.1 30
  source-address 7.1.1.1 30
  destination-address 3.1.1.1 32
  action permit
 rule name 5
  source-zone untrust
  destination-zone trust
  source-address 6.1.0.0 16
  source-address 7.1.0.0 16
  destination-address 8.1.1.1 30
  action permit
 rule name 6
  source-zone trust
  destination-zone untrust
  source-address 8.1.1.1 30
  destination-address 6.1.0.0 16
  destination-address 7.1.0.0 16
  action permit
#
return

Availability Solution

To prepare for possible failures, disaster recovery is deployed for key areas of the LTE network. The design principles for disaster recovery schemes in different positions are as follows:

Disaster Recovery for Link Failure Between the MME/S-GW and RSG

As shown in Figure 1-9, when the link between RSG-1 and the S-GW fails, traffic from FW_A to the S-GW cannot be transferred along this link. Instead, the traffic has to be routed to RSG-2 and then forwarded to the S-GW. Adding Eth Trunk2.3 and Eth Trunk2.2 to OSPF2 ensures the change of the route cost of OSPF2 when this link fails, so that decapsulated IPSec traffic is routed to RSG-2 for forwarding.

Figure 1-9 Disaster recovery for link failure between the MME/S-GW and RSG

Disaster Recovery for Link Failure Between the AGG and RSG

As shown in Figure 1-10, when the link between AGG-1 and RSG-1 fails, the cost of the route in the IP-RAN area changes, and IPSec traffic from the eNodeB to FW_A is no longer carried on this link. Instead, the traffic is routed to AGG-2 and then forwarded to RSG-2. Because Eth Trunk2.1 is added to OSPF1, when the IPSec traffic arrives at RSG-2, the traffic is forwarded by RSG-2 to RSG-1 and then forwarded to FW_A. Here, the cost of the route from RSG-2 to FW_B (standby) is greater than the cost of the route from RSG-2 to FW_A (active). Therefore, it is no need worrying that RSG-2 forwards the IPSec traffic to FW_B.

Figure 1-10 Disaster recovery for link failure between the AGG and RSG

Remote Disaster Recovery for the IPSec Gateway

Remote disaster recovery is considered in network planning to ensure normal operation of the communication network during large disasters, such as earthquake, tsunami, and hurricane. As shown in Figure 1-11, the IPSec gateway in the remote site and the IPSec gateway in the local site are mutual remote disaster recovery systems. It is assumed that the local site is impacted by a disaster, that both local IPSec gateways, FW_A and FW_B, fail, and that the EPC area is not impacted. Then, the IPSec traffic sent from the eNodeB has to be forwarded to the remote IPSec gateway. The remote IPSec gateway decapsulates the traffic and forwards it through the RSG to the MME and S-GW in the EPC area of the local site. In order that the traffic is forwarded along the expected route, it is necessary to add the local IPSec gateway, RSG and the remote IPSec gateway to the specified route process to realize route interworking. When the local IPSec gateway fails, the IPSec traffic can be routed to the remote IPSec gateway. In addition, it is necessary to enable the interworking between the route in the local EPC and the route of the remote IPSec gateway, so that the decrypted traffic can be forwarded to the local EPC.

Figure 1-11 Remote disaster recovery for the IPSec gateway

Translation
简体中文
Download
Updated: 2019-06-17

Document ID: EDOC1100087919

Views: 19074

Downloads: 451

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next

Copyright © 2023 Huawei Technologies Co., Ltd. All rights reserved.

You are going to visit :