Application of Firewalls in the LTE IPSec Solution Issue 01 Date 2019-06-15 HUAWEI TECHNOLOGIES CO., LTD. Copyright © Huawei Technologies Co., Ltd. 2019. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd. Trademarks and Permissions and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders. Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied. Huawei Technologies Co., Ltd. Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: https://e.huawei.com Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. i Application of Firewalls in the LTE IPSec Solution Contents Contents 1 Introduction.............................................................................................................................. 1 2 Solution Overview................................................................................................................... 2 3 Solution Design........................................................................................................................ 5 3.1 Networking Requirements................................................................................................................................................... 5 3.2 Service Planning.......................................................................................................................................................................7 3.2.1 IPSec Service Planning........................................................................................................................................................7 3.2.2 Availability Planning........................................................................................................................................................... 8 3.2.3 Data Planning....................................................................................................................................................................... 9 3.2.4 Route Planning................................................................................................................................................................... 13 4 Precautions............................................................................................................................. 16 5 Solution Configuration........................................................................................................ 18 5.1 Configuring Interfaces and Security Zones.................................................................................................................. 18 5.2 Configuring Hot Standby................................................................................................................................................... 19 5.3 Configuring IPSec.................................................................................................................................................................. 21 5.4 Configuring Security Policies.............................................................................................................................................24 5.5 Configuring the Interworking with Servers..................................................................................................................25 5.6 Verification.............................................................................................................................................................................. 25 5.7 Configuration Scripts........................................................................................................................................................... 26 6 Availability Solution............................................................................................................. 30 Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. ii Application of Firewalls in the LTE IPSec Solution 1 Introduction 1 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 offline mode. This document is based on Eudemon200E-N&Eudemon1000E-N&Eudemon8000EX V500R005C00 and can be used as a reference for Eudemon200EN&Eudemon1000E-N&Eudemon8000E-X V500R005C00, Eudemon200EG&Eudemon1000E-G V600R006C00, and later versions. Document content may vary according to version. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 1 Application of Firewalls in the LTE IPSec Solution 2 Solution Overview 2 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 2-1. Figure 2-1 Network architecture of LTE An LTE network consists of the following parts: Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 2 Application of Firewalls in the LTE IPSec Solution 2 Solution Overview ● 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 intereNodeB 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 3 Application of Firewalls in the LTE IPSec Solution – 2 Solution Overview 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 4 Application of Firewalls in the LTE IPSec Solution 3 Solution Design 3 Solution Design 3.1 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 3-1 shows the network topology. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 5 Application of Firewalls in the LTE IPSec Solution 3 Solution Design Figure 3-1 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 3-2 shows the transmission paths of different traffic. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 6 Application of Firewalls in the LTE IPSec Solution 3 Solution Design Figure 3-2 Transmission of different eNodeB traffic in the LTE IPSec solution 3.2 Service Planning 3.2.1 IPSec Service Planning In this solution, templates are used to establish IPSec tunnels. Table 3-1 describes IPSec service planning. Table 3-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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 7 Application of Firewalls in the LTE IPSec Solution 3 Solution Design Scheme Strength and Weakness Certificate authenticatio n 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. 3.2.2 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 3-3 shows the networking of off-path deployment of the NGFW. Table 3-2 describes the availability planning. Figure 3-3 Networking of off-path deployment Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 8 Application of Firewalls in the LTE IPSec Solution 3 Solution Design Table 3-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. 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. The Eth-Trunk increases the link bandwidth. The multiple member interfaces of the EthTrunk also implement link backup. When one member interface fails, traffic can still be carried over other member interfaces. 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. 3.2.3 Data Planning For the networking shown in Figure 3-4, the data planning for the network devices is described in Table 3-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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 9 Application of Firewalls in the LTE IPSec Solution 3 Solution Design Figure 3-4 IP address planning for off-path deployment of the NGFW Table 3-3 Data planning of the LTE network Device Interface IP Address Security Zone FW_A Eth-trunk1 IP address of EthTrunk1.1: 1.1.1.1/30 Eth-Trunk1.1: Untrust VLAN:100 Eth-Trunk1.3: Trust Member interfaces of Eth-Trunk1: GigabitEthernet1/0/1 and GigabitEthernet1/0/2 Eth-Trunk1.1 processes encrypted IPSec traffic sent by the eNodeB to the EPC. Eth-Trunk1.2: Trust Eth-Trunk1.4: Trust IP address of EthTrunk1.2: 1.1.2.1/30 VLAN:200 Eth-Trunk1.2 processes decrypted service traffic sent by the eNodeB to the SGW. IP address of EthTrunk1.3: 1.1.3.1/30 VLAN:300 Eth-Trunk1.3 processes decrypted signaling traffic sent by the eNodeB to the MME. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 10 Application of Firewalls in the LTE IPSec Solution Device Interface 3 Solution Design IP Address Security Zone IP address of EthTrunk1.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 2.1.1.1/30 DMZ 3.1.1.1/30 Untrust IP address of EthTrunk1.1: 5.1.1.1/30 Eth-Trunk1.1: Untrust VLAN: 100 Eth-Trunk1.3: Trust Member interfaces of Eth-Trunk2: GigabitEthernet1/0/8 and GigabitEthernet2/0/8 Tunnel interface Used for setting up an IPSec tunnel with the eNodeB. FW_B Eth-trunk1 Member interfaces of Eth-Trunk2: GigabitEthernet1/0/1 and GigabitEthernet1/0/2 Eth-Trunk1.1 processes encrypted IPSec traffic sent by the eNodeB to the EPC after the active/ standby device switchover. Eth-Trunk1.2: Trust Eth-Trunk1.4: Trust IP address of EthTrunk1.2: 5.1.2.1/30 VLAN: 200 Eth-Trunk1.2 processes decrypted service traffic sent by the eNodeB to the SGW after the active/ standby device switchover. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 11 Application of Firewalls in the LTE IPSec Solution Device Interface 3 Solution Design IP Address Security Zone IP address of EthTrunk1.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 EthTrunk1.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 2.1.1.2/30 DMZ 3.1.1.1/30 Untrust Tunnel IP: 6.1.1.1/30 Tunnel interface: Untrust Member interfaces of Eth-Trunk2: GigabitEthernet1/0/8 and GigabitEthernet2/0/8 Tunnel interface Used for setting up an IPSec tunnel with the eNodeB. eNode B-1 1 Tunnel interface + 3 service interfaces UP service IP: 6.1.2.1/32 CP service IP: 6.1.3.1/32 Service interfaces: Trust OM service IP: 6.1.4.1/30 eNode B-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 Tunnel interface: Untrust Service interfaces: Trust OM service IP: 7.1.4.1/30 Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 12 Application of Firewalls in the LTE IPSec Solution 3 Solution Design Device Interface IP Address Security Zone 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 - CA 9.1.2.4/30 - PKI 3.2.4 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 3-5. 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 EthTrunk sub-interfaces between the NGFW and the RSG differentiate IPSec encrypted traffic, decrypted traffic to the S-GW, and decrypted traffic to the MME. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 13 Application of Firewalls in the LTE IPSec Solution 3 Solution Design Figure 3-5 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. a. FW_A advertises the IPSec gateway route to OSPF1. b. RSG-1 imports the OSPF1 route to the BGP. c. RSG-1 advertises the IPSec gateway route to the AGG through the IBGP. d. The AGG receives the IPSec gateway route and advertises it on the IPRAN. 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 14 Application of Firewalls in the LTE IPSec Solution 3 Solution Design a. After importing direct routes from the AN, the IP-RAN can learn the IPSec tunnel route to eNodeB-1. b. RSG-1 learns the IPSec tunnel route to eNodeB-1 from the IP-RAN through IBGP. c. 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 subinterface 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 15 Application of Firewalls in the LTE IPSec Solution 4 Precautions 4 ● ● 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, Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 16 Application of Firewalls in the LTE IPSec Solution 4 Precautions 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 thirdparty 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 17 Application of Firewalls in the LTE IPSec Solution 5 5 Solution Configuration Solution Configuration 5.1 Configuring Interfaces and Security Zones Context Configure interfaces and security zones. Figure 5-1 Interface IP addresses and security zones Procedure Step 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 Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 18 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration [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 Step 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 Step 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. ----End 5.2 Configuring Hot Standby Context Complete the hot standby configuration according to the figure below. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 19 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration Figure 5-2 Hot standby networking Procedure Step 1 Configure hot standby. # Configure hot standby on FW_A. 1. 2. 3. Configure a VGMP group to monitor Eth-Trunk1. [FW_A] hrp track interface Eth-Trunk 1 Enable the VGMP group state-based OSPF cost adjustment function. [FW_A] hrp adjust ospf-cost enable 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. 2. 3. 4. Configure a VGMP group to monitor Eth-Trunk1. [FW_B] hrp track interface Eth-Trunk 1 Specify FW_B as the standby firewall. [FW_B] hrp standby-device Enable the VGMP group state-based OSPF cost adjustment function. [FW_B] hrp adjust ospf-cost enable 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 Step 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 Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 20 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration HRP_S[FW_A-ospf-1-area-1.1.1.1] quit HRP_S[FW_A-ospf-1] quit ----End 5.3 Configuring IPSec Procedure Step 1 Configure IPSec on FW_A. 1. Apply for certificates online for FW_A using CMPv2. a. 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... ...........+++ ...........+++ b. Configure entity information. c. Configure a CMP session. 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 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 21 Application of Firewalls in the LTE IPSec Solution Info: Info: Info: Info: Info: Info: Info: 5 Solution Configuration Sending initial request packet. Waitting for initial response packet. Creatting confirm packet. Connectting to CMPv2 server. Sending confirm packet. Waitting for confirm packet from server. 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. d. 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. a. 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 b. c. d. e. 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 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 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 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 22 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration 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 f. 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 g. 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 Step 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 ----End Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 23 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration 5.4 Configuring Security Policies Procedure Step 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 ----End Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 24 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration 5.5 Configuring the Interworking with Servers Procedure Step 1 Configure the interworking with the NTP server. HRP_M[FW_A] ntp-service unicast-server 9.1.1.2 Step 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 ----End 5.6 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. Issue 01 (2019-06-15) 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 Copyright © Huawei Technologies Co., Ltd. 25 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration 5.7 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 # 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 # 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 # Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 26 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration FW_A FW_B 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 # 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 # Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 27 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration FW_A FW_B 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 udpdomain 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 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 udpdomain 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 Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 28 Application of Firewalls in the LTE IPSec Solution 5 Solution Configuration FW_A FW_B destination-address 7.1.0.0 16 action permit # return destination-address 7.1.0.0 16 action permit # return Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 29 Application of Firewalls in the LTE IPSec Solution 6 6 Availability Solution 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 6-1, 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 6-1 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 6-2, 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 Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 30 Application of Firewalls in the LTE IPSec Solution 6 Availability Solution 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 6-2 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 6-3, 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. Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 31 Application of Firewalls in the LTE IPSec Solution 6 Availability Solution Figure 6-3 Remote disaster recovery for the IPSec gateway Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 32