NSE4 Firewall Policies and NAT Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The policy order is incorrect

  Why it's wrong here

  Policy order determines which firewall rule matches first based on source, destination, and service, but it does not control how NAT translates addresses or ports. Even if you reorder policies so this traffic is matched earlier, the NAT IP pool configuration still defines port behavior. Since the policy references an IP pool that changes source ports, reordering cannot prevent the port translation that breaks SIP. The failure originates in NAT, not in policy sequence.

• ✗

  The IP pool is configured with one-to-one NAT

  Why it's wrong here

  A one-to-one NAT IP pool statically maps a single internal IP to a single external IP, leaving source ports untouched. With one-to-one NAT, the original SIP source port (e.g., 5060) would be preserved, so signaling and media would continue to work correctly. Because the symptom is a port change, this configuration cannot be the cause—in fact, it would avoid the problem entirely. Thus, this answer incorrectly identifies a NAT mode that does not modify ports.

• ✗

  The IP pool uses fixed port range, which should work

  Why it's wrong here

  Fixed port range (also known as static PAT) maps a specific internal port to a specific external port from a predefined pool, preserving the original source port as long as it is within the range. For SIP, which relies on well-known ports for signaling, a fixed port range would keep the source port intact, allowing the protocol to function. The issue described arises only when ports are dynamically changed, not when they are fixed. Therefore, this configuration would not cause the failure.

• ✓

  The IP pool is configured with overload (PAT), which changes source ports

  Why this is correct

  Overload (PAT) translates many internal IPs to a single external IP by dynamically assigning unique source ports for each session. This changes the original SIP source port (e.g., 5060) to some random high port, breaking protocol expectations because SIP and RTP require consistent port mapping. The FortiGate's overload mode is exactly the condition that alters ports, leading to call setup and media failures. Thus, this is the correct explanation for the reported symptom.

Go deeper

Related to this question