CCNA Nse4 Firewall Policy NAT Questions

Option C is correct because the External IP Range must be set to 203.0.113.20-203.0.113.30 to define the pool of public IPs that will be mapped one-to-one to the internal servers. Option D is correct because Type: One-to-One ensures each internal IP is permanently mapped to a unique external IP, without port address translation (PAT), meeting the requirement of fixed one-to-one mapping.

Policy-based routing (PBR) allows you to override the default routing table by matching traffic based on source/destination addresses and directing it to a specific egress interface (port2). This is the correct feature because the requirement is to force traffic from 10.0.0.0/8 to 10.10.0.0/16 out port2, bypassing the default route.

Policy 1 (ID 1) matches first because FortiGate evaluates firewall policies in sequential order from top to bottom (lowest ID to highest ID) until a match is found. The source IP 192.168.1.10 falls within the 'any' source of Policy 1, and the destination 10.0.0.5 is within 10.0.0.0/8, with HTTP (port 80) matching the service. Since Policy 1 matches, it is applied and the traffic is accepted, even though Policy 2 would also match if reached.

FortiGate matches firewall policies from top to bottom. Policy 5 is higher in the policy list order than policy 10, so traffic matches policy 5 first and never reaches policy 10.

Firewall policies are matched from top to bottom. If a higher-priority policy (with a lower policy ID) matches the traffic and denies or applies different NAT, it will be processed before the intended allow policy. In this case, an FQDN-based policy above the allow policy matches the destination IP, causing the traffic to be handled by that policy instead.

Geography address objects allow matching based on country (or region) using the IP geolocation database. This is useful for geo-blocking.

Traffic shaping requires a shaping policy (or shaping rule) that matches the traffic, a traffic shaper that defines bandwidth limits, and optionally a per-IP shaper for per-user limiting.

Schedule objects define time ranges during which the policy is active. This allows time-based access control.

An address group is the correct object type to group multiple internal subnets into a single source in a firewall policy. In FortiGate, address groups allow you to combine multiple IP addresses or subnets (IPv4 or IPv6) into a logical group, which can then be referenced as the source in a single firewall policy. This simplifies administration by reducing the number of policies needed to allow outbound DNS traffic from multiple subnets.

The output shows `proto=6`, which indicates TCP, and `proto_state=01`, which corresponds to the TCP state SYN_SENT (0x01). This means the session has sent a SYN but has not yet received a SYN-ACK, so the three-way handshake is incomplete. The `duration=3600` and `expire=3599` indicate the session has been tracked for 3600 seconds and will expire in 3599 seconds, but the state confirms it is not yet established.

Option A is correct because 'diagnose firewall iprope list' displays the kernel's internal firewall rule chains, allowing the admin to verify whether the policy lookup is matching the expected rule for TCP/443 traffic. This command helps confirm that the policy is installed and active in the kernel, which is essential for troubleshooting policy-based access issues.

Option A is correct because the firewall policy must explicitly permit the SSH service (TCP port 22) from the WAN to the internal server. Without a policy allowing the traffic, the FortiGate will drop the packets even if the VIP is configured correctly. The policy acts as the security gatekeeper, and the service object for SSH ensures only port 22 traffic is allowed.

Overload NAT (Port Address Translation) allows many internal IPs to share one public IP by using unique source ports.

Application control profiles identify applications by signature. After identification, traffic shapers can be applied to limit bandwidth.

The output shows a TCP session (proto=6) with proto_state=01, which in Fortinet's session table indicates the session is in the SYN-SENT state (TCP state 1). This means the initial SYN has been sent but the SYN-ACK has not yet been received, so the TCP three-way handshake is incomplete. The duration and expire values reflect the session's age and remaining lifetime, not its establishment status.

Policy-based routing (PBR) allows you to override the routing table for specific traffic based on criteria such as source IP, destination, or application. By enabling PBR on the firewall policy for server 10.0.1.100 and specifying port2 as the egress interface, the admin ensures that all traffic from that server exits via port2, while the routing table continues to direct all other traffic via port1. This is the correct approach because PBR operates at the policy level, not the routing table level, giving granular control over traffic path selection.

Central SNAT rules are only used when the firewall policy has NAT enabled but no specific IP pool configured. If the policy uses Policy-based NAT (i.e., an IP pool is attached), Central SNAT is bypassed. Also, Central SNAT can be overridden by policy-based NAT.

The VIP (Virtual IP) configuration on a FortiGate maps a public IP and port to a private IP and port. If the VIP is configured only for port forwarding on TCP 80 (HTTP), it will not translate traffic for TCP 443 (HTTPS). This is the most likely cause because external users can reach HTTP but not HTTPS, indicating the VIP itself is not handling HTTPS traffic.

A Virtual IP (VIP) is required to map the public IP (203.0.113.5) to the internal server IP (192.168.1.10) for destination NAT. This allows inbound HTTPS traffic to be translated to the private server. Additionally, a firewall policy from WAN to DMZ must reference the VIP as the destination and allow HTTPS to permit the traffic and apply the NAT translation.

FTP uses separate control and data connections. FortiGate's FTP ALG (application layer gateway) or session helper is needed to inspect FTP traffic and handle dynamic data ports. Additionally, for VIP, the policy must allow the appropriate services, and the ALG must be enabled.

The policy only permits HTTP (TCP/80). HTTPS uses TCP/443, which is not allowed unless a separate service is defined.

The traffic shaping policy must be associated with the firewall policy. If the same traffic shaper is applied to both policies, they will get the same markings. The question implies different markings are desired, so the admin likely used the same shaper.

The service object 'HTTP' is defined as TCP/80, but HTTPS uses TCP/443. The web server is likely expecting HTTPS on TCP/443. The policy should allow TCP/443.

In a one-to-one IP Pool NAT configuration, the mapping is based on the subnet offset. The internal subnet 10.0.1.0/28 has 16 addresses (10.0.1.0–10.0.1.15), and the external pool 203.0.113.16/28 also has 16 addresses (203.0.113.16–203.0.113.31). The host 10.0.1.5 is the 6th usable IP (offset 5 from the network address), so it maps to the 6th IP in the external pool: 203.0.113.16 + 5 = 203.0.113.21.

Option A is correct because a One-to-One IP Pool maps each internal IP to a unique public IP from the range 203.0.113.1-203.0.113.10, preserving the original source port for each session. This meets the requirement to translate all internal IPs while keeping the source port unchanged for specific applications. The pool size (10 IPs) must be sufficient for the number of concurrent internal hosts.

The 'session helper' warnings indicate that the firewall is struggling to allocate NAT sessions for the dynamic IP pool. When the IP pool uses a fixed port range, the number of available source ports per IP is limited, leading to port exhaustion under heavy HTTP/HTTPS traffic. This causes intermittent failures and slow loads as new connections are dropped or queued.

These products are part of the Fortinet Security Fabric.

Wildcard FQDN objects can match domain names (fully qualified domain names) even with wildcards, and FortiGate can use SNI to match HTTPS traffic.

FortiGate evaluates policies from top to bottom in the policy list, and the first match is applied.

Schedule objects define time ranges (recurring or one-time) during which a policy is effective. They are applied directly in the firewall policy.

Option C is correct because even though the FortiGate is receiving FSSO login events, the firewall policy also includes a source address restriction. If the user's IP address falls outside the defined source address range, the policy will not match, and the user will be denied access despite being authenticated via FSSO. The FSSO group membership is only one condition; the source IP must also satisfy the policy's source address criteria.

Option A is correct because a traffic shaper object must first be defined with the desired bandwidth limits (e.g., maximum rate, burst size) before it can be applied to a firewall policy. Without this object, the shaper cannot be referenced or enforced.

Disabling NPU offloading per policy can be done by configuring the policy to use 'Proxy-Based' inspection or by disabling 'capwap' and 'offload' options in the firewall policy advanced settings. Also, enabling SSL inspection forces software processing.

A VIP group with multiple VIPs each having a different port mapping allows this. Alternatively, separate VIPs with different public ports can be used. Option A and C are correct.

FortiGate address objects support Subnet, Wildcard FQDN, and Geography types, but MAC addresses are not a valid address object type. MAC addresses are used in other contexts like static ARP entries or DHCP reservations, not as firewall address objects.

'diagnose firewall policy list' shows the policy list with IDs. 'diagnose firewall iprope' shows the lookup order and matching policy. 'get firewall policy' is a config command, not for real-time traffic. 'execute' commands are for pinging, not policy lookup.

Policy-based NAT allows specifying a fixed IP address or IP pool for source NAT. The admin should configure the policy's NAT settings to use a specific IP pool or IP address.

The FSSO collector agent listens on 192.168.1.1, which is the IP of the interface connected to ISP1. SD-WAN rules send traffic from 10.0.1.0/24 via ISP2, so authentication packets from these users (e.g., to the collector agent) may be routed through ISP2 and never reach the collector agent at 192.168.1.1, causing repeated authentication prompts. This is a classic SD-WAN routing asymmetry issue where FSSO traffic does not follow the expected path.

Option A is correct because an IP Pool of type Overload (Port Block Allocation) allows you to specify a single public IP address (203.0.113.10) as the translated source IP for all traffic from 10.0.1.0/24, with port address translation (PAT) enabled. This ensures that all outbound traffic uses that specific IP as the source, regardless of which WAN interface the traffic egresses, and the 'Overload' type automatically performs port translation to multiplex multiple internal hosts behind that single IP.

Using diagnose debug flow to trace the packet and diagnose firewall iprope list to see policy hit counts are effective ways to identify traffic matching.

Option C is correct because a traffic shaping policy with guaranteed bandwidth allocation and high priority ensures that VoIP traffic (UDP ports 5060-5061) receives the necessary bandwidth and is prioritized over other traffic during WAN congestion. Traffic shaping policies on FortiGate allow you to set guaranteed bandwidth, maximum bandwidth, and priority levels, which directly address congestion by reserving resources for critical traffic like VoIP.

Different logging and monitoring options on FortiGate.

Policy-based NAT is evaluated before Central SNAT because it is directly tied to the firewall policy that matches the traffic. When a policy-based NAT rule exists for the same traffic, it takes precedence over Central SNAT rules, regardless of any global settings or rule IDs. Therefore, the source IPs from 192.168.1.0/24 will be translated to 203.0.113.10.

With overload enabled (Port Address Translation), the firewall translates multiple internal IPs to a single public IP by using unique source ports. Each public IP can handle up to 65,535 ports, but the actual usable port range is often smaller due to reserved ports and system limits. When all ports on all IPs in the pool are consumed, new connections are dropped because no port can be allocated for the translation.

In FortiGate, 'proto_state=01' for TCP (proto=6) indicates the session is in the SYN_SENT phase, meaning the initial SYN packet has been sent but the three-way handshake is not yet complete. For HTTPS traffic, this shows the session is still in the connection setup stage, not fully established. The 'duration' and 'expire' values reflect the time since the session was created and the remaining timeout, which is typical for an incomplete handshake.

The hit count of zero indicates the policy is not being matched. Policy order matters; if a policy above this one matches the traffic, this policy will never be used. The administrator should check if a policy above is matching the traffic first.

The most likely cause is that the firewall does not have a route to the 10.0.0.0/8 network. Even though the policy is enabled and correctly positioned, the firewall must have a return route to the source network (10.0.0.0/8) for the web server's response traffic to reach the users. Without this route, the firewall drops the return packets, causing connectivity failure for those specific users.

FortiGate supports geography-based address objects that allow or deny traffic based on the source IP's country. These are configured using geography objects.

Overload NAT (also known as PAT) allows many internal hosts to share a single public IP by using different source ports.

Option A is correct because FortiGate firewall policies are evaluated sequentially from top to bottom based on their policy ID. Since policy ID 5 (deny for 192.168.0.0/16) appears before policy ID 10 (allow for 192.168.10.0/24), traffic from 192.168.10.0/24 is matched by the broader deny policy first, and the allow policy is never reached. This is a fundamental behavior of FortiGate's policy lookup order.

FortiGate uses first-match logic for firewall policies. The deny-all policy is placed before the allow policy, so all traffic hits the deny policy first and is dropped. The allow policy never gets evaluated.

Possible causes: The policy may not have the IP Pool selected in the NAT settings; the policy order might be incorrect if another policy matches first; the IP Pool might be assigned to the wrong interface or contain a different IP range; or the traffic might be matching a different policy that doesn't use NAT. Central SNAT rules could also override, but the question specifies policy-based NAT.

The implicit deny policy is a built-in policy at the end of the policy list that denies all traffic not matching any explicit policy. It cannot be removed or modified.

Option A is correct because adding a policy before the central SNAT policy with `set nat disable` explicitly exempts specific traffic from NAT translation. This ensures that applications using non-standard ports are not affected by the overload behavior of the IP pool, which could otherwise cause port conflicts or session failures. The policy-based NAT (central SNAT) processes policies sequentially, so a higher-priority match with NAT disabled overrides any subsequent NAT rules.

SYN_SENT indicates that the FortiGate has sent a SYN but not received a SYN-ACK, suggesting the server is not responding, possibly due to a missing DNAT or VIP configuration for inbound traffic.

Option A is correct because SD-WAN rules allow you to define application-based routing policies. By creating an SD-WAN rule that matches HTTP traffic and sets WAN1 as the preferred interface, the FortiGate will automatically steer HTTP sessions out through WAN1 while using the default routing table (which points to WAN2) for all other traffic. This leverages the SD-WAN feature's ability to perform per-application load balancing and failover without requiring policy-based routing.

Policy-based NAT uses the 'set nat' command in a firewall policy to enable source NAT, while Central NAT uses a separate NAT policy table.

The 'implicit deny' policy on a FortiGate is a built-in, last-resort rule that automatically denies any traffic not matching an explicit firewall policy. It is not visible in the policy list and cannot be moved, modified, or deleted; it is always applied as the final rule to ensure that only explicitly permitted traffic is allowed through the FortiGate.

Traffic shaping is the correct mechanism to enforce fair bandwidth distribution for HTTPS traffic. By creating a traffic shaping policy and applying it to the firewall policy, the admin can allocate a specific bandwidth guarantee or limit for HTTPS sessions, preventing them from starving other traffic. Without shaping, HTTPS traffic can consume all available bandwidth, causing slow performance for other users.

The policy explicitly allows HTTP (TCP port 80), but modern web traffic predominantly uses HTTPS (TCP port 443). Since the service object does not include HTTPS, the firewall will drop HTTPS packets by default unless a separate policy or rule permits them. This is the most likely reason users cannot access websites, as most sites redirect HTTP to HTTPS or require HTTPS for secure connections.

Option B is correct because a firewall policy must be created to allow SMTP traffic from the internal network (10.0.0.0/8) to the DMZ mail server (172.16.0.10) on TCP port 25. The policy must specify the source, destination, service (SMTP), and action (ACCEPT) to permit the traffic. Without this policy, the traffic would be blocked by default.

Option A is correct because an IP Pool with type Overload allows multiple internal hosts to share a single public IP (203.0.113.10) for source NAT when traffic goes to the internet. This is the standard method for PAT (Port Address Translation) in FortiGate, enabling many-to-one NAT.

To apply traffic shaping, a traffic shaper must be created and then referenced in the firewall policy. Option A is correct.

Option C is correct because a Geography address object allows the FortiGate to match traffic based on the source IP's country of origin, using the built-in GeoIP database. This is the only address object type that can restrict access by country without requiring manual IP range updates.

To allow inbound HTTPS and preserve the source IP, you need a VIP to translate destination, a firewall policy allowing the traffic, and no source NAT (or use a policy that does not SNAT). SNAT would hide the original source IP.

An IP pool for the specific server, a traffic shaper for HTTP, and firewall policies to apply them. Option B, C, and D are correct.

IP Pool with Overload (PAT) allows many private IPs to be translated to a single public IP using port address translation. This is the most common configuration for internet access.

Policy 1 is an implicit allow-all rule that matches all traffic before policy 2 is evaluated. Since FortiGate processes policies in sequential order from top to bottom, the SSH connection to 203.0.113.10 matches policy 1 first, which permits all services, including SSH. Therefore, the connection succeeds without ever reaching policy 2.

Option D is correct because policy-based NAT with an IP pool type 'Overload' (PAT) allows multiple internal hosts to share the single public IP 203.0.113.10 for outbound traffic. This meets the requirement to translate RFC 1918 source addresses to a specific source IP when accessing an external FTP server, while preserving port multiplexing.