No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

HUAWEI Firewall Comprehensive Configuration Examples

This document describes the application scenarios and configuration methods in typical projects of the firewall.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Service Planning

Service Planning

IPSec Service Planning

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

Table 9-1  IPSec service planning
Scheme Strength and Weakness
policy template

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

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

In the case of a large quantity of eNodeBs, you may need to extend the address range in the ACL. When the ACL is being modified, the tunnel is interrupted for a short time. This can be overcome through reasonable data planning.
Certificate authentication The eNodeB and security gateway use certificates for authentication to establish an IPSec tunnel. After hot standby is enabled, the active device needs to generate a key pair to apply for a device certificate. After the active device generates a key pair, the key pair is automatically backed up to the standby device. In addition, the devices share the same device certificate. When the active device loads the certificate, the certificate file will be automatically backed up to the standby device.

Availability Planning

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

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

Figure 9-4  Networking of off-path deployment
Table 9-2  Hot standby planning
Scheme Strength Implementation
Hot standby in active/standby mode Dual-node deployment is more reliable than standalone deployment. -
Link bundling

Multiple links are more reliable than a single link.

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

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

Remote disaster recovery

Remote backup is more reliable than only local backup.

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

(Optional)

Remote disaster recovery means multiple FWs are deployed in different geographical locations.

Data Planning

For the networking shown in Figure 9-4, the data planning for the network devices is described in Figure 9-5.

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

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

Figure 9-5  IP address planning for off-path deployment of the NGFW
Table 9-3  Data planning of the LTE network
Device Interface IP Address Security Zone
FW_A

Eth-trunk1

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

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

VLAN: 100

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

Eth-trunk1.1: Untrust

Eth-trunk1.2: Trust

Eth-trunk1.3: Trust

Eth-trunk1.4: Trust

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

VLAN: 200

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

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

VLAN: 300

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

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

VLAN: 400

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

Eth-trunk2

Member interfaces of Eth-trunk2: GigabitEthernet1/0/8 and GigabitEthernet1/0/9

2.1.1.1/30 DMZ
Tunnel interface

Used for setting up an IPSec tunnel with the eNodeB.

3.1.1.1/30 Untrust
FW_B

Eth-trunk1

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

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

VLAN: 100

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

Eth-trunk1.1: Untrust

Eth-trunk1.2: Trust

Eth-trunk1.3: Trust

Eth-trunk1.4: Trust

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

VLAN: 200

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

IP address of Eth-trunk1.3: 3.1.3.1/30

VLAN: 300

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

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

VLAN: 400

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

Eth-trunk2

Member interfaces of Eth-trunk2: GigabitEthernet1/0/8 and GigabitEthernet1/0/9

2.1.1.2/30 DMZ
Tunnel interface

Used for setting up an IPSec tunnel with the eNodeB.

3.1.1.1/30 Untrust
eNodeB-1

1 Tunnel interface + 3 service interfaces

Tunnel IP: 6.1.1.1/30

UP service IP: 6.1.2.1/32

CP service IP: 6.1.3.1/32

OM service IP: 6.1.4.1/30

Tunnel interface: Untrust

Service interfaces: Trust

eNodeB-2

1 Tunnel interface + 3 service interfaces

Tunnel IP: 7.1.1.1/30

UP service IP: 7.1.2.1/32

CP service IP: 7.1.3.1/32

OM service IP: 7.1.4.1/30

Tunnel interface: Untrust

Service interfaces: Trust

S-GW

S1-U interface

8.1.1.1/30

-
MME

S1-C interface

8.1.1.2/30

-
OM U2000

9.1.1.1/30

-
NTP Server

9.1.1.2/30

-
Log Server

9.1.1.3/30

-
PKI CA

9.1.2.4/30

-

Route Planning

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

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

Figure 9-6  Route planning
  • Uplink traffic
    The uplink traffic from the eNodeB to the EPC relies on the following route exchange process. The process here is based on the line from eNodeB-1 through the IP-RAN, FW_A, and RSG-1 to the EPC.
    1. FW_A advertises the IPSec gateway route to OSPF1.
    2. RSG-1 imports the OSPF1 route to the BGP.
    3. RSG-1 advertises the IPSec gateway route to the AGG through the IBGP.
    4. The AGG receives the IPSec gateway route and advertises it on the IP-RAN.

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

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

  • Downlink traffic
    The downlink response traffic from the EPC to eNodeB relies on the following route exchange process. The process here is based on the line from the EPC through RSG-1, FW_A, and the IP-RAN to eNodeB-1.
    1. After importing direct routes from the AN, the IP-RAN can learn the IPSec tunnel route to the eNodeB.
    2. RSG-1 learns the IPSec tunnel route to eNodeB-1 from the IP-RAN through IBGP.
    3. RSG-1 imports the IPSec tunnel route to eNodeB-1 learnt by the IBGP to OSPF1. FW_A learns the IPSec tunnel route to eNodeB-1.
    The response traffic from the EPC to eNodeB-1 is forwarded to FW_A along the route learnt in OSPF2. The traffic enters the IPSec tunnel along the route learnt during reverse route injection of FW_A. NGFW_A forwards the encapsulated traffic to the IP-RAN along the route to eNodeB-1 learnt in OSPF1. The IP-RAN then forwards the traffic all the way to eNodeB-1.

In the hot standby scenario, the cost of the OSPF route advertised by the active IPSec gateway (FW_A) is the original one and is configurable, and the cost of the OSPF route advertised by the standby IPSec gateway (FW_B) is 65500. Therefore, the original cost of the OSPF route is generally smaller than 65500. When the traffic from the eNodeB to the EPC arrives at the RSG, the RSG selects a link with a smaller route cost to forward the traffic to FW_A. Because the Eth-Trunk sub-interface Trunk3.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, 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.

Translation
Download
Updated: 2019-01-26

Document ID: EDOC1100062972

Views: 16784

Downloads: 721

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next