Understanding and Configuring Bidirectional NAT (Source NAT + NAT Server) on Huawei Firewalls

This article explains how to combine source NAT and NAT Server to implement bidirectional NAT on Huawei firewalls, classifies inter‑zone and intra‑zone NAT types, provides detailed configuration examples, and discusses the benefits and packet flow of each scenario.

Practical DevOps Architecture
Practical DevOps Architecture
Practical DevOps Architecture
Understanding and Configuring Bidirectional NAT (Source NAT + NAT Server) on Huawei Firewalls

After the previous posts that introduced source NAT and NAT Server, readers are familiar with the basic NAT functions. On Huawei firewalls, source NAT and NAT Server can be used together to achieve "bidirectional NAT". This is not a separate feature; it is simply the combination of source NAT and NAT Server applied to the same traffic flow.

According to the security zones of the source and destination addresses, NAT can be divided into two categories:

1. Inter‑zone NAT – the source and destination belong to different security zones. It is further split into:

(1) NAT Inbound (external to internal) – traffic moves from a lower‑security zone to a higher‑security zone and the source address is translated. NAT Inbound is usually paired with NAT Server.

(2) NAT Outbound (internal to external) – traffic moves from a higher‑security zone to a lower‑security zone and the source address is translated. The typical "internal users accessing external resources" scenario uses NAT Outbound.

2. Intra‑zone NAT – the source and destination are in the same security zone. Intra‑zone NAT is generally used together with NAT Server, and it is less common to configure it alone.

When either inter‑zone NAT or intra‑zone NAT is combined with NAT Server, the result is bidirectional NAT. The prerequisite is a proper security‑zone hierarchy (e.g., Trust > DMZ > Untrust) and appropriate address planning.

Scenario 1: NAT Inbound + NAT Server

This is the most common case: an external PC accesses an internal server, and the firewall acts as the server's gateway. The configuration uses a private address pool that is in the same subnet as the server’s private IP.

#<br/>nat address-group 1 10.1.1.20 10.1.1.25  // private IP pool, same subnet as server<br/>nat server 0 global 210.1.1.15 inside 10.1.1.3<br/>#<br/>nat-policy interzone dmz untrust inbound<br/>policy 1<br/>action source-nat<br/>policy destination 10.1.1.3 0  // destination IP is the one after NAT Server translation<br/>address-group 1

During traffic flow, the destination address (the server’s public IP) is first translated by NAT Server to a private IP, then the source address (the PC’s public IP) is translated by NAT Inbound to another private IP in the same subnet as the server. This achieves simultaneous source‑ and destination‑address translation – the essence of bidirectional NAT. The return traffic undergoes the reverse translation, restoring both addresses to their original public values.

The main benefit of enabling NAT Inbound is that the server does not need to configure a default gateway. Because the server’s address and the destination address are in the same subnet, the server sends an ARP request for the destination; the firewall replies with its own MAC address, causing the reply packet to be forwarded back through the firewall. This greatly simplifies management when many servers are involved.

If the PC resides in the Trust zone instead of Untrust, the same principle applies but the direction changes to NAT Outbound + NAT Server.

Scenario 2: Intra‑zone NAT + NAT Server

This scenario is typical in small networks where the PC and server are placed in the same security zone and share the same subnet. To allow the PC to reach the server via a public address, NAT Server is configured first. However, without intra‑zone NAT, the server’s reply would be sent directly to the PC at layer 2, bypassing the firewall.

#<br/>nat address-group 1 210.1.1.20 210.1.1.20<br/>nat server 0 global 210.1.1.15 inside 10.1.1.3<br/>#<br/>nat-policy zone trust  // note: intra‑zone NAT<br/>policy 1<br/>action source-nat<br/>policy destination 10.1.1.3 0  // destination IP is the one after NAT Server translation<br/>address-group 1

With intra‑zone NAT, the PC’s address is translated to a public IP, while the server’s address is translated to a private IP by the NAT Server. Because the server’s source and destination are now in different subnets, the server must route the reply packet, which forces the traffic to pass through the firewall again, ensuring that both directions are inspected.

In all cases, the principle of bidirectional NAT is straightforward: understand the direction of address translation and the role of the resulting addresses. While bidirectional NAT is not mandatory—sometimes source NAT or NAT Server alone suffices—its flexible use can simplify network configuration and improve manageability, achieving a result greater than the sum of its parts.

NATBidirectional NATHuawei FirewallNAT ServerSource NAT
Practical DevOps Architecture
Written by

Practical DevOps Architecture

Hands‑on DevOps operations using Docker, K8s, Jenkins, and Ansible—empowering ops professionals to grow together through sharing, discussion, knowledge consolidation, and continuous improvement.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.