Common Causes of IP Pool Bypass in FortiGate NAT
A FortiGate admin is troubleshooting an issue where traffic from VLAN 10 to the internet is not being NATed even though a policy-based NAT rule is configured. The admin verifies that the firewall policy uses the correct IP Pool. Which THREE steps should the admin take to diagnose the problem? (Choose three.)
⚠ Common exam trap
Many candidates assume a firewall policy with NAT enabled will always work, overlooking that the IP Pool itself must be correctly bound to the egress interface and not exhausted, and that rebooting or disabling policies are not valid diagnostic steps.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Examine the IP Pool configuration for correct interface binding or port exhaustion
Option B is correct because an IP Pool must be bound to the correct egress interface and must have available ports/addresses; if the pool is bound to the wrong interface or its ports are exhausted, NAT translation will not occur even though the policy references the pool. Option C is correct because the admin must confirm the policy is actually matching the traffic, which can be done with 'diagnose firewall fwpolicy list' or by reviewing policy logs; if the policy is not hit, NAT will never be applied. Option D is correct because 'diagnose sys session list' shows the live session table and whether NAT is applied, including the translated source IP and port, which directly reveals if NAT is failing. Option A is not appropriate because rebooting is disruptive and does not diagnose the root cause of a NAT failure. Option E is not appropriate because disabling all other policies is a risky, non-diagnostic action that could cause an outage and does not isolate the NAT issue in a controlled way.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Reboot the FortiGate to clear any session table issues
Why it's wrong here
Rebooting the FortiGate is not a diagnostic step; it indiscriminately flushes the entire session table, including any NAT translation entries. While this may temporarily allow new sessions to be created if the issue was transient port exhaustion, the misconfiguration in the IP pool or the offending firewall policy remains untouched, so the fault will reappear once sessions rebuild. A reboot also causes unnecessary downtime and does not provide a packet-level or config-level insight into why NAT failed in the first place.
- ✓
Examine the IP Pool configuration for correct interface binding or port exhaustion
Why this is correct
The IP pool is where FortiGate defines the translated source IP(s) for NAT, so a misconfiguration here directly breaks translation. If the pool is bound to the wrong outgoing interface, traffic egressing the actual interface will not match the pool and will either be untranslated or dropped. Additionally, even with correct binding, an overloaded pool that runs out of available source ports (exhausted port range) will fail to allocate a translation for new sessions, producing a NAT failure that does not appear in policy checks.
- ✓
Verify that the firewall policy is being hit using 'diagnose firewall fwpolicy list' or logs
Why this is correct
Since NAT is performed as part of the firewall policy's action on a per-policy basis, a policy that is not hit means no address translation is ever attempted. Using 'diagnose firewall fwpolicy list' displays hit counters for each policy, and checking system logs reveals session setup events, allowing you to confirm whether the relevant policy matched the traffic. If the traffic is being matched by a different policy earlier in the order—one without NAT enabled—that would explain the absence of translation despite the intended policy existing.
- ✓
Check the session table using 'diagnose sys session list' to see if NAT is applied
Why this is correct
The session table, queried via 'diagnose sys session list', captures the live state of every session, including the original source address and the actually translated source address. By inspecting the 'src' field for a known session, you can see whether the source IP shown is the original internal address or the IP pool address, which empirically verifies if NAT is being applied. This step is more direct than checking configurations because it shows the actual outcome, but it only reveals symptoms after the fact and does not itself identify the configuration error causing the failure.
- ✗
Disable all other firewall policies to isolate the issue
Why it's wrong here
Disabling all other firewall policies is a destructive and overly broad measure that is neither a diagnostic nor a privileged troubleshooting step. It removes legitimate security controls and can expose the network to unintended traffic while causing widespread service disruption, all without isolating the specific misconfiguration. A better approach is to use policy ordering, hit counters, and packet flow debugging to identify whether a shadowing policy is interfering, rather than disabling all rules.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 773 original NSE4 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.