Huawei HCIA-Security (H12-711 V4.0) common mistakes
Huawei HCIA-Security (H12-711 V4.0) · Understand the traps and how to avoid them.
When configuring a firewall zone, the candidate assigns an interface to a zone but forgets to set the interface to 'allow' or 'enable' the zone, so traffic is dropped even though policies look correct.
Candidates focus on security policies and NAT rules but overlook the prerequisite that the interface must be added to a zone and the zone must be activated (e.g., 'firewall zone trust' then 'add interface GigabitEthernet1/0/1'). They assume zone membership alone is sufficient.
What to do instead
Always verify interface-to-zone binding and that the zone is enabled. Use display commands like 'display zone' and 'display interface brief' to confirm the interface is up and assigned. In lab practice, create a checklist: 1) interface IP, 2) zone assignment, 3) zone activation, 4) policy.
In an IPsec VPN configuration, the candidate mismatches the proposal parameters (encryption algorithm, authentication algorithm, DH group) between peers, causing phase 1 to fail, but they only check the pre-shared key.
Candidates memorize that the pre-shared key must match and stop there. They forget that IKE proposal parameters must also match exactly, and they don't know how to read the IKE debug output to see which parameter mismatched.
What to do instead
When troubleshooting IPsec, always compare the full IKE proposal on both peers: encryption (e.g., AES-256), authentication (e.g., SHA-256), DH group (e.g., group14), and lifetime. Use 'display ike sa' and 'display ipsec sa' to see phase status. Enable 'debugging ike' to identify the exact mismatch.
The candidate writes a security policy that permits traffic from trust to untrust but forgets that NAT (source NAT) must be configured separately, so internal hosts cannot access the Internet even though the policy allows it.
Candidates conflate security policy with NAT. They think allowing the traffic in the policy is enough, but NAT is a separate configuration (NAT policy or NAT server). They also forget that the NAT policy must be matched before or in conjunction with the security policy.
What to do instead
Remember the order: security policy permits the traffic, and NAT translates the source address. Configure a NAT policy (source NAT) with the correct source zone, destination zone, and NAT address pool. Verify with 'display firewall session table' to see if NAT is applied. In labs, always test with both policy and NAT configured.
When configuring an SSL VPN, the candidate creates a virtual gateway and assigns an IP pool but forgets to bind the virtual gateway to the interface or to configure the authentication policy, so users cannot connect.
Candidates focus on the virtual gateway and user authentication but miss the binding step. They also forget that the SSL VPN requires a security policy allowing traffic from the untrust zone to the virtual gateway's IP.
What to do instead
After creating the virtual gateway, bind it to the interface with 'binding interface' under the virtual gateway view. Ensure a security policy permits traffic from untrust to the virtual gateway IP (or to local zone). Verify with 'display v-gateway' and check user connectivity using the SSL VPN client.
The candidate misidentifies the default action of a security policy when no rule matches, assuming it is permit, and designs policies that inadvertently allow traffic.
Candidates come from a background where ACLs often have an implicit deny, but on Huawei firewalls the default action between zones is deny, yet they may confuse it with the default action of a policy rule or the default of the firewall. They also forget that the default packet filtering action can be configured but is deny by default.
What to do instead
Memorize: on Huawei USG/eNGFW, the default inter-zone action is deny. Always explicitly configure a deny rule at the end of the policy list or rely on the default deny. Use 'display security-policy rule all' to review rules and their order. In labs, test by sending traffic that matches no rule and confirm it is dropped.
When configuring a NAT Server (port forwarding), the candidate specifies the external IP and port but forgets to configure a security policy allowing traffic from the untrust zone to the internal server's real IP, so the connection fails.
Candidates think NAT Server alone is sufficient. They don't realize that after NAT translation, the security policy is evaluated on the translated address (the internal server IP), so a policy permitting untrust-to-trust for that IP is required.
What to do instead
Always pair NAT Server with a security policy that permits traffic from the untrust zone to the trust zone, with the destination being the internal server's private IP and the service port. Verify with 'display firewall session table' to see the NAT translation and policy match.
The candidate confuses the order of IPSec VPN negotiation phases and misconfigures the ACL for interesting traffic, causing traffic not to be encrypted.
Candidates set up the IPSec policy but use an ACL that doesn't match the actual traffic (e.g., wrong source/destination or wildcard mask). They also forget that the ACL for IPSec must be a mirror image on both peers and that the traffic must be routed through the IPSec tunnel interface.
What to do instead
Use 'display acl' to verify the ACL matches the intended traffic. Ensure the ACL on both peers is mirrored (source and destination swapped). For route-based VPN, ensure traffic is routed to the tunnel interface. Test with 'ping' and check 'display ipsec sa' for encrypted packet counts.
When configuring URL filtering, the candidate selects a predefined category but forgets to apply the profile to the security policy, so filtering does not take effect.
Candidates create the URL filtering profile and assume it is globally active. They don't realize that content security profiles (URL filtering, anti-virus, IPS) must be referenced in a security policy rule to be enforced.
What to do instead
After creating the URL filtering profile, edit the relevant security policy rule and apply the profile under 'profile' in the rule. Verify with 'display security-policy rule' that the profile is attached. Test by accessing a blocked URL and checking logs.
The candidate misconfigures the PKI certificate enrollment, using the wrong certificate request method or forgetting to import the CA certificate, so the firewall cannot establish an SSL VPN or IPsec connection using certificates.
Candidates are unfamiliar with the PKI workflow: generate key pair, create certificate request, submit to CA, retrieve certificate, and import CA certificate. They skip importing the CA certificate or use the wrong enrollment method (e.g., offline vs. online).
What to do instead
Follow the PKI steps: 1) generate RSA key pair, 2) create PKI entity, 3) create certificate request (online or offline), 4) obtain certificate from CA, 5) import CA certificate. Use 'display pki certificate' to verify. In labs, practice with a local CA server (e.g., Windows Server) to understand the flow.
The candidate ignores log analysis during troubleshooting, relying only on show commands, and misses that the firewall is dropping packets due to a session limit or a content security profile action.
Candidates focus on configuration commands and forget that logs (buffer logs, syslog) provide the exact drop reason. They also don't know how to enable logging for security policies or content security profiles.
What to do instead
Enable logging on security policies and content security profiles. Use 'display logbuffer' to view recent logs and look for drop reasons (e.g., 'denied by policy', 'virus detected'). Also use 'display firewall session table verbose' to see session details. Practice reading logs to identify policy drops vs. content inspection drops.