Internal Users Cannot Reach a Published Web Portal After NAT Server Configuration

This is a classic NAT hairpin (NAT loopback) problem. A packet from 10.10.10.x to 203.0.113.10 arrives at the firewall destined for its own Untrust interface address. The NAT Server rule translates the destination to 172.16.10.50, but the source remains 10.10.10.x. The return packet from 172.16.10.50 goes to 10.10.10.x directly through the internal routing table, bypassing the firewall, so the firewall never sees the return traffic and the session never completes. Externally sourced traffic works because the return path is through the firewall.

The fix has two parts. First, ensure the NAT Server rule is applied so that traffic arriving on the Untrust interface with destination 203.0.113.10:443 is translated to 172.16.10.50:443. Second, add source NAT for the hairpin flow, typically a NAT policy or nat outbound on the same Untrust interface matching Trust-sourced traffic destined to 203.0.113.10, so the source is translated to the firewall's Untrust address (or a pool address). The server then replies to the firewall, and the firewall reverses both translations. Also confirm the interzone policy permits Trust to DMZ (or Trust to Untrust depending on implementation order); the existing Trust to DMZ rule covers the translated flow. Test with session table display to confirm both forward and return translations exist.

IPsec Phase 1 and Phase 2 only prove that the peers agree on IKE and IPsec parameters; they do not validate that the traffic selectors or routing are usable. With both sites using 10.10.10.0/24, the branch's interesting traffic and HQ's local subnet overlap. The firewall cannot distinguish a packet destined for the local 10.10.10.x from one that should be encrypted to the branch, and routing prefers the directly connected Trust interface. The branch router's NAT to 192.168.50.0/24 may help only if the IPsec traffic selector and HQ routing use 192.168.50.0/24, but the branch still needs a source NAT rule that applies before encryption, and HQ needs a route and policy for 192.168.50.0/24. Otherwise packets are dropped or sent to the wrong interface.

Remedies, in order of preference: re-address one site (cleanest, avoids all overlap and future merge problems); or apply source NAT on the branch LAN to a unique range such as 192.168.50.0/24 before IPsec, with HQ routing and policies referencing that range. Ensure the IPsec traffic selectors on both peers match the translated addresses, not the original 10.10.10.0/24. Verify with display ike sa, display ipsec sa, and session tables. Avoid assuming NAT traversal solves overlap - NAT-T handles NAT devices in the path, not duplicate private subnets.

On Huawei USG devices, the general order is: packet arrives, session lookup, then security policy check and NAT processing are coordinated through the first-packet path. In practice, for a new flow the firewall evaluates the security policy against the original addresses and zones, then applies NAT Server destination translation and source NAT as configured, creates the session, and forwards. Return traffic matches the existing session and is reverse-translated without a new policy lookup. This is why the Trust to DMZ policy can permit the hairpin flow even though the user typed the public address: the policy must allow the pre- or post-NAT addresses depending on the platform's order, so both directions must be checked.

For troubleshooting, this order means you should inspect the session table rather than only the policy. If a session exists with only destination translation and no source translation, the return path will bypass the firewall. If no session exists, check policy hit counters and NAT Server matching. Also verify that the NAT Server rule is bound to the correct interface and that the source NAT rule matches the Trust source and public destination. Understanding the order prevents the common mistake of adding a broad Trust to Untrust permit when the real issue is missing source NAT.