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

Interfaces and Security Zones

To prevent communication failures between active and standby firewalls due to heartbeat interface faults, using an Eth-Trunk interface as the heartbeat interface is recommended. For devices on which multiple NICs can be installed (for the support situation, see the hardware guide), an inter-board Eth-Trunk interface is required. That is, the member interfaces of the Eth-Trunk interface are on different LPUs. The inter-board Eth-Trunk improves reliability and increases bandwidth. For devices that do not support interface expansion or inter-board Eth-Trunk, it is possible that a faulty LPU may cause all HRP backup channels to be unavailable and compromise services.

The upstream and downstream physical links must have the same bandwidth that is greater than the peak traffic. Otherwise, services are affected due to traffic congestion in case of traffic burst.

The following table describes the planning of interfaces and security zones on the FWs.

Table 7-1  Planning of interfaces and security zones
FW_A FW_B Description

Eth-Trunk0:

  • Member ports:

    1. GE2/0/0
    2. GE2/0/1
  • IP address: 192.168.3.1/24
  • Security zone: hrpzone

Eth-Trunk0:

  • Member ports:

    1. GE2/0/0
    2. GE2/0/1
  • IP address: 192.168.3.2/24
  • Security zone: hrpzone

HRP backup interface.

Eth-Trunk1:

  • Member ports:

    1. GE2/0/2
    2. GE2/0/3
  • IP address: 1.1.1.1/24
  • Security zone: untrust

Eth-Trunk1:

  • Member ports:

    1. GE2/0/2
    2. GE2/0/3
  • IP address: 1.1.2.1/24
  • Security zone: untrust

Interface connecting the Internet.

Eth-Trunk2:

  • Member ports:

    1. GE2/0/4
    2. GE2/0/5
    3. IP address: 10.14.1.1/24
    4. Security zone: trust

Eth-Trunk2:

  • Member ports:

    1. GE2/0/4
    2. GE2/0/5
    3. IP address: 10.14.2.1/24
    4. Security zone: trust
  • Eth-Trunk2 is the interface connecting to Gi/SGi services.

Security Policies

The following table describes the planning of security policies on the FW.

Table 7-2  Planning of security policies
Item Data Description

Local - Trust

Outbound

The security policy for access of the FW to the Trust zone, which may be set to permit all packets. If a fine-grained policy is required, note that OSPF packets should be permitted.

Inbound

The security policy for access from the Trust zone to the FW, which may be set to:

  • Permit packets for login and device management, including SSH and HTTPS packets.
  • Permit OSPF packets.

Local - Untrust

Outbound

The security policy for access of the FW to the Untrust zone, which may be set to permit all packets. If a fine-grained policy is required, note that OSPF packets should be permitted.

Inbound

The security policy for access from the Untrust zone to the FW, which may be set to:

  • Permit packets for login and device management, including SSH and HTTPS packets.
  • Permit OSPF packets.

Local - hrpzone

Outbound

Security policy between the backup interfaces of the active and standby firewalls, which can be used for the login switching between the firewalls.

Inbound

Security policy between the backup interfaces of the active and standby firewalls, which can be used for the login switching between the firewalls.

Trust - Untrust

Outbound

  • Configure a rule that permits packets whose source address is a private address of a mobile terminal, and configure NAT for the private address.
  • Configure packet filtering for the start GGSN and WAP-side end router of a GRE tunnel.

Inbound

Configure packet filtering for the start GGSN and WAP-side end router of a GRE tunnel.

Routes

The route planning is as follows:

  1. Black-hole routes are configured for NAT addresses, and static routes are advertised to avoid routing loops.
  2. The firewall learns the default route from the Internet-side device and advertises the default route to the core network-side device in the way of unforced delivery of OSPF routes. Routing policies also need to be configured. When the firewall and Internet-side device import static routes, only the routes to addresses in the NAT address pool are advertised, and the routes to the other private addresses are not advertised.
  3. The firewall learns the addresses of intranet servers and terminal IP addresses from the core network side device and advertises the routes of the servers to the Internet side device. Filtering policies are configured for the firewall and the core network side device, and the firewall does not need to learn the default route from the core network side device.

The following table describes the planning of routes on the FWs.

Table 7-3  Planning of routes

FW_A

FW_B

Description

  • Destination Address:

    0.0.0.0/0

  • Next hop:

    1.1.1.2 (IP address of RouterC)

  • Destination Address:

    0.0.0.0/0

  • Next hop:

    1.1.2.2 (IP address of RouterD)

Default routes learned through OSPF.

  • Destination Address:

    10.20.0.0/16

  • Next hop:

    10.14.1.2 (IP address of RouterA)

  • Destination Address:

    10.20.0.0/16

  • Next hop:

    10.14.2.2 (IP address of RouterB)

The route to the GGSN side learned through OSPF.

  • Destination Address:

    1.1.10.10

    1.1.10.11

    1.1.10.12

    1.1.10.13

    1.1.10.14

    1.1.10.15

  • Next hop:

    NULL0

  • Destination Address:

    1.1.10.10

    1.1.10.11

    1.1.10.12

    1.1.10.13

    1.1.10.14

    1.1.10.15

  • Next hop:

    NULL0

Black-hole routes to prevent route loops.

NAT

If the IP address obtained by a mobile terminal is a private address, NAT is required on the FW. The public address obtained through NAT is used for Internet access. NAT reduces the use of public addresses and improves the intranet security.

The usual NAT mode for FWs is NAT PAT. Empirically, one NAT address supports the NAT for 5,000 to 10,000 private IP addresses. Table 7-4 describes the planning of the NAT address pool. The configuration is the same for the active and standby firewalls.

Table 7-4  Planning of the NAT address pool

Item

FW_A

FW_B

ID

1

1

Mode

pat

pat

Addresses

1.1.10.10-1.1.10.15

1.1.10.10-1.1.10.15

The following table describes the planning of NAT policies.

Table 7-5  Planning of NAT policies

Item

FW_A

FW_B

Security zone

Trust - Untrust

Trust - Untrust

Direction

Outbound

Outbound

Match condition

All packets from the 10.14.0.0/16 network segment

All packets from the 10.14.0.0/16 network segment

Action

source-nat

source-nat

NAT address pool ID

1

1

NAT is performed by the FW for FTP, RTSP, and PPTP traffic from mobile terminals to the Internet. It is necessary to configure ASPF between the zone where the Gi/SGi interface resides and the Untrust zone to ensure normal functioning of these applications.

Attack Defense

Attack defense should be enabled on the FW for security defense. The recommended configuration is as follows:

firewall defend land enable

firewall defend smurf enable

firewall defend fraggle enable

firewall defend ip-fragment enable

firewall defend tcp-flag enable

firewall defend winnuke enable

firewall defend source-route enable

firewall defend teardrop enable

firewall defend route-record enable

firewall defend time-stamp enable

firewall defend ping-of-death enable

Network Management (SNMP)

The Simple Network Management Protocol (SNMP) is the most widely used network management protocol on TCP/IP networks. An SNMP proxy should be configured on the FW so that the FW can be managed through an NMS server.

Logs (LogCenter)

The LogCenter server is used to collect NAT session logs for source tracing. Configure the FW to output session logs to the LogCenter server, including the log output format, source address, and source port.

Translation
Download
Updated: 2019-01-26

Document ID: EDOC1100062972

Views: 19190

Downloads: 786

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