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