Huawei HCIP-Security (H12-721/722/723) common mistakes
Huawei HCIP-Security (H12-721/722/723) · Understand the traps and how to avoid them.
Treating the USG security policy as a first-match-wins ACL and expecting a later 'permit' rule to override an earlier 'deny', then being unable to explain why an allowed flow is still dropped.
Candidates carry over Cisco-style implicit-deny thinking or assume rule order is irrelevant because of the 'any' zone defaults. USG policies are evaluated top-down and the first matching rule is enforced, with the default interzone action applied when nothing matches.
What to do instead
Before answering, sketch the policy table in evaluation order, mark the first match for the specific five-tuple (source zone, destination zone, source/destination address, service, and application), and state explicitly what the default action is. Practise reordering rules so the specific permit precedes the generic deny, and verify with the policy-matching hit count concept.
Confusing source NAT, server NAT, and bidirectional/NAT Server with the wrong direction of translation, so the candidate predicts the wrong address in the session table or the wrong return path.
NAT and security policy are configured in separate places on the USG, and the direction (pre- versus post-policy) determines which address the policy must match. Candidates memorise 'NAT changes the address' without fixing which side sees the translated value.
What to do instead
For each scenario write four boxes: original source/destination, translated source/destination, and note whether policy sees pre-NAT or post-NAT addresses. Remember that policy is matched on the pre-NAT (original) address for destination NAT scenarios and drill the difference between NAT Server (inbound destination translation) and source NAT (outbound source translation, including easy-IP/pat).
Assuming IPsec will come up as soon as the proposal, IKE peer, and ACL are configured, without checking whether the interesting traffic actually matches the ACL and is routed out the correct interface.
IPsec has two independent planes: IKE (phase 1) and IPsec (phase 2). A phase-1 SA can establish while phase-2 never triggers because no packet matched the data-flow ACL, or because the return route bypasses the tunnel. Candidates conflate 'IKE up' with 'tunnel passing traffic'.
What to do instead
Diagnose in layers: confirm IKE SA state, confirm IPsec SA exists, then verify the ACL counters increment when pinging from behind the gateway. Check that the crypto ACL is symmetric between peers and that a route or policy-based forwarding sends the traffic into the tunnel. Practise reading the SA output for inbound/outbound SPI and encrypt/decrypt counters.
Treating HRP dual-system hot standby as simple VRRP and expecting both firewalls to forward traffic simultaneously, or forgetting that session tables and configuration must be synchronised before failover preserves existing connections.
HRP (Huawei Redundancy Protocol) handles state and configuration synchronisation, while VRRP handles virtual-IP ownership. Candidates merge the two and cannot explain why a failover drops long-lived sessions or why the standby rejects traffic.
What to do instead
Separate the roles: VRRP elects the active device and owns the virtual gateway; HRP replicates sessions, server mappings, and configuration to the peer. Memorise the preconditions for HRP (heartbeat link reachable, same software version, HRP enable on both, matching VRRP groups) and the active/standby versus load-balancing modes, then trace a failover step by step.
Reading an IPS signature alert as proof that the packet was dropped, or assuming a signature in 'alert' action blocks the flow.
Signature action (alert/block) and profile binding are separate decisions. A signature may fire and log while the profile action is set to alert only, so the traffic continues. Candidates equate detection with prevention.
What to do instead
Always state the profile action alongside the signature match: alert logs only, block drops the matching packet. Confirm the profile is actually applied to the security policy rule, and check whether the signature is enabled in the current signature set and whether the traffic even reaches the IPS engine after NAT and decryption.
Assuming application identification (App-ID) will classify every flow immediately, then mis-diagnosing a bandwidth-policy miss as a QoS bug when the flow was still in the 'unknown' application state.
App-ID needs several packets to fingerprint a flow; encrypted or custom applications may stay unidentified. Candidates design a bandwidth policy keyed to a specific application and expect it to match from the first packet.
What to do instead
Explain the identification lifecycle: initial packets fall under the default/unknown category, then reclassify once the signature matches. Design policies with an explicit fallback for unknown traffic, and verify with the application identification cache or session display that the flow reached the intended application before blaming the bandwidth policy.
Configuring an SSL VPN and then failing to explain why an authenticated user cannot reach an internal resource, because the candidate never checked the virtual gateway address pool, the route back to the pool, or the policy covering the SSL VPN zone.
SSL VPN introduces its own zone and address pool that must be routed and permitted like any other network. Candidates stop once the user authenticates and treat reachability as automatic.
What to do instead
Walk the full path: virtual gateway and address pool assignment, the route on the gateway and on internal routers back to the pool, and a security policy from the SSL VPN zone to the destination zone. Also confirm the user's role/authorisation grants the resource, since authentication and authorisation are distinct steps.
Answering troubleshooting questions by listing every possible cause instead of interpreting the specific log or display output given in the scenario.
Candidates lack fluency with Huawei diagnostic commands and outputs, so they hedge. They cannot distinguish a session-table entry in a given state, a discarded-packet counter, or an HRP status field.
What to do instead
Build a command-to-question map: session table for forwarding state, policy hit counters for match confirmation, HRP status for synchronisation, IKE/IPsec SA output for tunnel state, and log buffer for drop reasons. Practise reading a short output and naming the single next command you would run, rather than enumerating possibilities.
Mixing up GRE, L2TP, and DSVPN roles, for example expecting GRE to provide encryption or expecting DSVPN to work without a hub-and-spoke topology and NHRP-style address resolution.
These tunnel technologies overlap in purpose but differ in layer and control plane. Candidates group them as 'VPN' and lose the distinctions that exam scenarios hinge on.
What to do instead
Tabulate each: GRE encapsulates arbitrary protocols but has no confidentiality; L2TP tunnels PPP and is usually paired with IPsec for security; DSVPN builds dynamic spoke-to-spoke tunnels through a hub using NHRP and mGRE. For each, state what it encapsulates, whether it encrypts, and what topology it assumes.
Treating the threat landscape as a list of malware names to memorise, so the candidate cannot map an attack technique to the control that mitigates it in a campus or HiSec scenario.
Threat questions are often framed as architecture decisions (where to place a control, which zone terminates what), but candidates revise vocabulary instead of the attack path and the placement logic.
What to do instead
For each major threat class, practise drawing the attack path and naming the enforcement point that stops it: edge firewall policy, IPS profile, antivirus/content filtering, endpoint agent, or network access control. Anchor answers in zone design and control placement rather than in definitions, and justify why a given control sits at that point in the path.