NGFW Engineer common mistakes
NGFW Engineer · Understand the traps and how to avoid them.
Editing an interface's security zone or virtual router assignment, then testing traffic before committing the candidate configuration.
The NGFW separates candidate configuration from the running configuration; the change looks present in the editor but is not active until a commit succeeds.
What to do instead
After zone, interface, and virtual-router changes, run a commit, confirm the commit status is successful, and verify the interface is up and assigned to the expected zone before testing traffic.
Creating a destination NAT rule and expecting it to also permit the inbound connection.
NAT and security policy are separate rule sets; translation does not imply permission, so the session can be translated and then dropped by policy.
What to do instead
Add an explicit security policy rule that matches the original pre-NAT source/destination and required application/service, then verify the session is allowed and translated in the session table.
Placing a broad allow rule above a more specific deny rule and expecting the deny to take effect.
Security policy is evaluated top-down with first-match semantics, so the earlier broad allow shadows later rules.
What to do instead
Order rules from most specific to most general, move the deny above the broad allow, and confirm hit counts show the intended rule is being matched.
Leaving a default route on an untrusted interface and assuming a more specific route will always be used without checking the forwarding table.
Route selection depends on prefix length plus metrics and other route attributes; a default route can still capture traffic if the specific route is inactive or less preferred.
What to do instead
Inspect the actual forwarding table, confirm the specific route is active and preferred, and use a traceroute or packet-flow test from the correct source zone to verify egress path.
Configuring policy-based forwarding or source NAT but forgetting that return traffic must be routed symmetrically back through the same device.
Asymmetric routing can cause stateful inspection to drop return packets because the returning segment does not match an existing session on the same firewall.
What to do instead
Verify return-path routing, use symmetric-return enforcement where supported, and test with session lookup from both directions before declaring the design complete.
Building an IPsec tunnel with phase-2 selectors that do not mirror the peer's local and remote subnets, then troubleshooting only IKE phase 1.
Phase 1 can be up while phase 2 fails or installs no usable SA because the traffic selectors/proxy IDs do not match on both sides.
What to do instead
Compare local and remote subnet definitions on both peers, correct the phase-2 selectors, clear the tunnel, and verify phase 2 SAs are installed before testing traffic.
Establishing a VPN tunnel but omitting security policy and NAT-exemption rules for traffic entering or leaving the tunnel zone.
Tunnel traffic still passes through normal policy and NAT processing; a successful IKE/IPsec negotiation does not bypass those checks.
What to do instead
Add policy rules allowing the required VPN source/destination pairs and, where needed, a no-NAT rule for tunnel-bound traffic; then confirm the session is allowed and not translated unexpectedly.
Building an HA pair without verifying that both devices have matching configuration and that HA heartbeat/control links are operational.
HA election, synchronization, and failover depend on consistent configuration and healthy control/heartbeat paths; a mismatch or broken link can prevent proper failover or cause sync failures.
What to do instead
Confirm HA state on both devices, verify configuration synchronization, check heartbeat/control link status, and correct any configuration mismatch before testing failover.
Testing HA failover by disconnecting only a data link while leaving link-monitoring or path-monitoring conditions untested.
Failover behavior depends on which interfaces and paths are monitored; unplugging an unmonitored link may not trigger failover, while a control-link failure can create split-brain if not handled.
What to do instead
Review HA link and path monitoring settings, test the specific monitored failure condition, and verify both devices return to the expected active/passive or active/active state without split-brain.
Assuming traffic is being logged because a security rule exists, without confirming logging is enabled and log forwarding is configured.
A policy rule can allow traffic without generating the desired session logs unless log-at-start/log-at-end or a log-forwarding profile is applied and active.
What to do instead
Enable logging on the relevant rules, attach the required log-forwarding profile, generate a test session, and verify the event appears in the local log and at the external destination.