Fortinet NSE 4 Network Security Professional NSE4 (NSE4) — Questions 376–450

Even after an IPsec tunnel reaches Phase 2, traffic is still subject to the firewall policy database on each FortiGate. If no policy with action ACCEPT exists that matches the source/destination subnets and the incoming/outgoing interface (e.g., the IPsec virtual interface), the firewall silently drops the packets. A common misconfiguration is creating a policy for the WAN interface instead of the tunnel interface, or setting the wrong local/remote addresses in the policy.

A traffic shaping policy is the only mechanism in FortiGate that can enforce both bandwidth reservations and queue priority for VoIP. By configuring a shaping profile with guaranteed bandwidth (e.g., 512 kbps) and setting priority to High, you instruct the traffic scheduler to service SIP/RTP UDP packets ahead of lower-priority flows and reserve capacity so that congestion does not starve voice. Guaranteed bandwidth ensures a minimum threshold, while high priority reduces jitter and latency, making this the correct choice for real-time traffic.

Each Phase2 selector defines exactly one local subnet and one remote subnet pair for a given security association. Creating multiple Phase2 entries under the same Phase1 lets you assign different subnet pairs to the same tunnel, allowing the FortiGate to pick the matching SA for each traffic flow. This is the standard, granular method for supporting multiple subnets across a single IPsec tunnel.

This command queries the HA daemon's internal statistics and specifically reports the number of consecutive sent and received heartbeat packets as well as the computed packet loss rate. It is the only command in this list that directly measures the reliability of the heartbeat link, which is essential for diagnosing intermittent failovers or a split-brain condition. A non-zero loss percentage here indicates a degraded heartbeat path, pointing to physical-layer issues such as bad cables, duplex mismatches, or congested interfaces.

Enabling UDP session synchronization directly instructs the FGCP cluster to replicate UDP session table entries from the primary unit to the standby. Because UDP is connectionless, the standby cannot infer active flows from handshake packets, so without this explicit setting, return traffic for existing UDP conversations will be dropped after failover. This setting is protocol-specific and works alongside session pickup to ensure NAT bindings and idle timers are preserved on the new primary.

Phase 2 (Quick Mode) negotiates the IPsec SA parameters, including the encryption algorithm (e.g., AES-256, 3DES) and authentication algorithm (e.g., SHA-1, SHA-256) for the ESP/AH protocol. If the local and remote firewalls do not offer a common proposal for these algorithms and the Diffie-Hellman group, the Phase 2 negotiation will fail with an error such as 'no proposal chosen.' Since Phase 1 has already formed a secure IKE SA, the problem isolates specifically to a Phase 2 proposal mismatch, preventing the tunnel from establishing even though both gateways are reachable and authenticated.

FortiGate's NAT decision pipeline always evaluates policy-based NAT before Central NAT. When a session matches a firewall policy with an explicit NAT translation, that translation is applied immediately; Central SNAT rules are consulted only after no policy-based NAT rule matched. This design makes the more specific, policy-scoped translation authoritative, which is why traffic flows through the policy-based NAT rule.

This is a mandatory step because the FortiGate signs every session certificate it sends to clients using its own CA. Without adding that CA certificate to the Trusted Root Certification Authorities store, clients will reject the presented certificate as untrusted and display SSL errors or refuse the connection. This trust installation must be performed on every client that will have its traffic inspected, typically via Group Policy or MDM.

If the application is not covered by any built-in FortiGuard signature, the administrator should create a custom application signature based on the traffic's unique pattern. On FortiGate, this is done by defining a custom signature using attributes such as protocol, port, IP, or content-matching criteria in the application control profile. This directly adds detection capability for the unrecognized application, allowing it to be identified and controlled. Without a signature, the application remains invisible to the security inspection.

With overload, each pool IP has a finite port range; once all ports on all ten addresses are consumed by concurrent sessions, new connections cannot be translated and are dropped. Exhaustion of that port range is the likely cause.

The 'diagnose vpn ike config' command in FortiOS prints the Phase 2 proposal, which lists the exact ESP (Encapsulating Security Payload) transforms: the encryption algorithm (e.g., AES-GCM, AES-CBC) and the authentication/integrity algorithm (e.g., SHA-256, SHA-1). This is precisely what the administrator sees in the output, making it the correct answer. It reflects the algorithms that will be used for the actual IPsec data tunnel.

The proto_state value 0x01 in the output of 'diagnose sys session list' corresponds to the TCP SYN_SENT state, which occurs during the initial connection setup phase. In this phase, the initiator has transmitted a SYN packet and is awaiting the peer's SYN-ACK response, meaning the three-way handshake is incomplete. This is precisely why the session is not fully established and why this is the correct answer.

FortiGate incorporates an automatic rollback mechanism that activates when the newly upgraded firmware fails to boot, fails self-integrity checks, or encounters an incompatible configuration during startup. In such cases, the bootloader automatically falls back to the previously known-good partition and reboots the system using the prior firmware, ensuring availability. The observed reboot followed by a return to the previous version is the textbook signature of this controlled rollback after a failed upgrade attempt.

HTTPS management requires two things: administrative access enabled on the WAN interface itself, plus an explicit firewall policy permitting inbound TCP 443 to the FortiGate's IP. Without the policy, the implicit deny drops the traffic even when HTTPS access is enabled.

This is the correct function: the ZTNA access proxy acts as a reverse proxy that terminates client requests to internal applications, enforcing authentication (often via SAML/OIDC) and device verification (via FortiClient EMS) before proxying the connection to the actual application server. This creates a zero-trust access model where access is granted per application, per user, and per device, rather than allowing broad network-level connectivity.

IKEv2 replaces the 6-message main mode exchange with a compact 4-message exchange by combining SA negotiation and key derivation, and then performing authentication with the same two messages. This halves the round-trip time in the common no-NAT case and also reduces the number of packets that must be processed in parallel. Additionally, IKEv2 supports built-in NAT traversal, and is more resilient to errors because each pair of messages is cryptographically tied together, providing a faster and more robust negotiation than IKEv1 main mode.

This is correct because with an 'Overload' IP pool, multiple sessions can be mapped to the same IP address, but each session requires a unique source port. The FortiGate has a limited number of ports per IP (approximately 64,000). If the number of concurrent sessions exceeds the available ports, new connections will fail. The administrator should consider adding more IP addresses to the pool or using a different NAT type.

The correct interpretation of the 'proposal mismatch' error is that the Phase 2 encryption and authentication algorithms, or other transform parameters like the PFS Diffie-Hellman group, differ between the two FortiGates. During IKE Phase 2, the initiator sends a list of SA proposals containing encryption algorithms (e.g., AES128/256), integrity algorithms (e.g., SHA1/256), and optionally DH groups for PFS. If none of the responder's configured Phase 2 proposals match any of the initiator's proposals, the responder sends the 'no proposal chosen' or 'proposal mismatch' notification. To resolve this, the Phase 2 transform sets (encryption, authentication, and PFS) must be aligned on both endpoints.

The correct workflow in FortiOS for inspecting the session table is to first set a filter with 'diagnose sys session filter dport 443', which configures the current CLI session to show only sessions with a destination port of 443. Then 'diagnose sys session list' prints the matching entries from the kernel session table. This two-step approach lets you combine multiple filter criteria without passing them as command arguments.

Emergency (severity 0) is the highest syslog severity level and specifically denotes that the system is unusable. On FortiGate, this log is generated when a fatal condition halts operations, such as a kernel panic or a catastrophic disk failure that prevents booting. Unlike lower severities, Emergency means the device cannot perform its security functions or be administered until it is restarted or repaired.

With central NAT enabled, SNAT is handled by central SNAT rules that are evaluated independently of firewall policies. The firewall policy itself must not have NAT enabled; it simply allows the traffic. The central SNAT rule matches source and destination criteria and performs the translation. This is the correct configuration for policy-based NAT in FortiOS.

Inline Scan mode on FortiGate's FortiSandbox integration causes the firewall to submit a file to the sandbox and temporarily buffer the client's request until a verdict is returned. Only a 'clean' verdict releases the file to the end user; malicious or suspicious files are blocked and quarantined. This is the only mode that guarantees the file is not delivered before analysis completes, making it essential for preventing zero-day infections in real time.

FortiGate firewall policies are evaluated top-down and the first policy that matches all configured criteria (source, destination, interface, and service) is executed; lower policies are never reached if a higher policy matches the same traffic. This means a broader policy placed above this specific rule—for example, an any-to-any policy—will shadow it, causing this rule's hit count to remain zero. Since FortiGate uses first-match rather than best-match, rule ordering is critical, and moving this rule above the broad policy would restore its visibility and hit count.

FortiAnalyzer is Fortinet's dedicated log management and analysis appliance, purpose-built to aggregate logs from FortiGate and other Fortinet devices to a central location. It provides high-capacity storage, real-time search, reporting, and event correlation, making it the standard for enterprise centralized logging. Configuring FortiGate to send logs to FortiAnalyzer via the FortiGate's log settings or Security Fabric fully meets the organization's central log collection need.

The SSL/SSH inspection profile is where you choose between certificate inspection (which looks only at the server certificate) and full SSL inspection (which decrypts, inspects, and re-encrypts traffic). It also lets you configure actions for invalid certificates, expired ones, and whether to inspect specific protocols like HTTPS or SMTPS. Without creating such a profile, there is no definition of how deep inspection should behave, making it a necessary first step.

IKEv2 natively integrates NAT traversal and MOBIKE, letting a tunnel survive IP address changes when a device roams between networks. IKEv1 requires separate NAT-T negotiation and lacks MOBIKE entirely, so sessions break on address change. This directly satisfies the stem's demand for IKEv2's primary advantage over IKEv1.

A policy-based IPsec VPN relies on phase2 selectors (proxy IDs) to define exactly which source and destination subnet pairs are protected by a given SA. When the hub receives traffic from Spoke A destined for Spoke B, the hub performs a route lookup and then matches the traffic against its phase2 selectors to determine which IPsec tunnel and SA to use. Without a selector covering the Spoke-A-to-Spoke-B pair—or a broad selector like 0.0.0.0/0 for all subnets—the hub has no matching SA and will drop the traffic or send it unencrypted, depending on the firewall policy. This is the root requirement for hub-and-spoke spoke-to-spoke connectivity.

This is the standard and correct method: in the System > Admin > Administrators settings, define a trusted host as 10.0.1.0/24 for that administrator, and ensure SSH is enabled in the administrative access for the interface the admin connects to. Trusted hosts explicitly allowlist the source IP ranges that can initiate management sessions, so only devices from 10.0.1.0/24 can SSH to the FortiGate. Additionally, SSH administrative access must be enabled on the relevant interface for the login to be accepted.

In transparent mode, the FortiGate acts as a transparent bridge (bump in the wire) and does not route IP traffic, so all traffic control must occur at Layer 2. A layer 2 firewall policy inspects and forwards frames based on MAC addresses, VLANs, and other Layer 2 attributes, making it the only policy type that can effectively filter traffic in this deployment. This policy type is required because there is no Layer 3 routing table or IP-based decision-making in transparent mode.

Importing the CA certificate allows the FortiGate to validate the LDAP server's certificate. Using LDAPS ensures encryption. This maintains security by verifying the server's identity. The FortiGate must trust the CA that signed the LDAP server's certificate. This is the correct approach to resolve certificate validation errors while keeping the connection secure.

This is the correct method to enable HTTPS administrative access on a specific interface. The `config system interface` block enters the interface configuration context, `edit port2` selects the target interface, and `set allowaccess https` adds HTTPS to the list of management protocols permitted on that interface. Without this setting, even if the HTTPS daemon is globally enabled, FortiGate will ignore HTTPS connection attempts on port2 and the administrator would be locked out of that interface.

Offloading new logs to FortiAnalyzer frees local disk space while retaining compliance evidence, and archiving existing logs before clearing preserves them. This satisfies the stem's dual constraint: continue logging and keep the current logs, which simply deleting or disabling logging would violate.

TCP, or Transmission Control Protocol, is indeed assigned IP protocol number 6, which is what the session filter output indicates. This is standard across all IP networks, as defined by the IANA protocol numbers. A FortiGate session for applications such as HTTP, SSH, or SMTP would show 'Proto=6' to represent TCP. Therefore, the correct interpretation of the protocol numeral in the diagnostic output is that the session is using TCP as its transport layer protocol.

The administrator wants to apply security profiles. At a minimum, attaching one security profile (e.g., antivirus, web filter, IPS) is necessary to meet that requirement. This ensures that the traffic is inspected and protected according to the organization's security policy. This is a required action.

The failover threshold (often called the missed-heartbeat threshold) specifies how many consecutive heartbeat packets from the primary must be lost before the secondary unit declares a failover. Increasing this threshold from the default of 3 to a larger value allows the cluster to tolerate small bursts of packet loss or a momentary HA link issue without triggering a failover. This directly reduces spurious failovers while still detecting a true primary outage if the primary remains silent for a longer period, making it the correct corrective action.

To allow Skype for Business while blocking other Skype variants, you must first identify the exact application signatures that match Skype for Business traffic. The FortiGate application control database includes multiple signatures under the 'Skype' family, such as 'Skype.For.Business' and 'Skype.For.Business.Client', each with specific protocol and port definitions. Choosing the wrong signature could result in inadvertently blocking legitimate business traffic or allowing unauthorized peer-to-peer Skype connections. This step is foundational because the subsequent policy rule and blocking actions depend entirely on precisely matching the intended application.

An automation stitch is the correct approach because it creates an event-triggered workflow: a local-in policy log entry (e.g., 'local-in denial') fires an automation trigger, which then executes a CLI script to add the offending source IP to a configured blocked address list. This provides immediate, autonomous enforcement without waiting for human intervention, and it directly addresses the source IP at the device level.

In FortiOS, SSL VPN traffic is de-encapsulated onto the ssl.root virtual interface, and a firewall policy must explicitly permit traffic from that interface to the internal network with the correct source address (derived from the tunnel IP pool), destination, and service. Without such a policy, even if the tunnel is established and authentication succeeds, packets will be silently dropped by the FortiGate's security engine. Therefore, verifying the existence and correctness of that policy is the first logical step in troubleshooting connectivity.

FortiGate evaluates interface-to-interface traffic against firewall policies, so a policy permitting HTTPS from the internal subnet to the FortiGate interface IP is required for GUI access. This satisfies the stem's constraint alongside enabling HTTPS administrative access.

A valid FortiCloud subscription is mandatory because FortiCloud logging is a licensed cloud service. The FortiGate must authenticate to FortiCloud's servers using the registered account's credentials and entitlement; without an active subscription, log upload attempts will be rejected even if local disk storage is available. This subscription is a hard prerequisite that cannot be bypassed by configuration alone.

To correctly enable user overrides, you must turn on 'Override' in the Web Filter profile and configure an authentication scheme (e.g., local password or LDAP username/password) so the FortiGate can validate the user who submits the override request. You also need to define an authentication rule that lists which users or groups are allowed to override, and you can optionally set a duration for each override session. Once these are in place, users encountering a blocked page are prompted to enter credentials, and a successful authentication creates a temporary, logged exception that is visible in the override history.

This is the exact FortiOS syntax for a static route. 'config router static' enters the static routing table, 'edit 1' creates or edits the route with sequence number 1, and 'set dst' accepts the destination address followed by subnet mask. 'set gateway' defines the next-hop IP, then 'next' commits the entry and 'end' exits configuration mode. This block is valid and works as intended.

Event logs are the correct FortiGate log type for authentication records, as they capture administrative login/logout, user authentication attempts, and enforcement of authentication policies. They also log configuration changes and system policy events, making them the central repository for user-access accountability. For example, both successful and failed logins via the web GUI or SSH are written to the event log with timestamps and source IPs.

A policy route is evaluated before the routing table, so matching the specific destination and setting the output interface to port2 overrides the default route for only that traffic. You can specify source, destination, and optionally protocol or port criteria, while all other traffic continues to follow the normal administrative-distance-selected default route. This gives exact policy-based control without affecting other destinations.

After DNAT, the destination IP changes to the internal server. The firewall policy must allow traffic to that internal IP. If the policy's destination is set to the VIP's public IP, it may not match post-DNAT. The correct approach is to set the destination to the mapped IP address.

A geography object in FortiGate is the correct mechanism for country-based access control. It references entries in the built-in geolocation database that classifies IP addresses by country, and when used as a source address in a firewall policy, FortiGate extracts the source IP's country and matches it against the object. This enables the admin to create a policy whose source is a specific country object, thereby restricting traffic to that geographic origin.

Setting the trusted host for the admin account to 10.0.0.100 is the correct method because FortiGate's trusted-host feature restricts administrative logins to traffic originating from that exact source IP address. When configured, the SSH management daemon will reject authentication attempts from any other IP, regardless of which interfaces have SSH enabled. This provides a precise, per-admin source-IP allowlist that directly matches the requirement to permit only one specific management host.

Overload NAT, also known as Port Address Translation (PAT), allows many internal hosts to share one public IP by rewriting not only the source IP but also the source port to a unique, dynamically assigned value. The NAT engine maintains a translation table keyed by the public IP and the new source port, so return traffic is correctly forwarded back to the original internal host. This session multiplexing is what makes a single public IP sufficient for the entire internal network, with a theoretical maximum of about 65,536 concurrent sessions per public IP.

Transparent mode places the FortiGate as a layer 2 bridge, forwarding frames between interfaces without routing or NAT, so existing IP addressing remains unchanged. NAT/route mode performs routing and address translation, which the scenario explicitly excludes.

The HA heartbeat interface is the dedicated link used by both units to exchange state and health information. If this interface is not configured correctly or is down, the secondary cannot reliably monitor the primary's heartbeat; in this scenario, the cluster may not even form, or if it did form, the secondary will not detect the primary's failure and will not initiate a failover. In some cases, a failed heartbeat with a still-functioning management plane can lead to split-brain, but a correctly working heartbeat is fundamental to failover detection and to avoid the cluster being stuck with an inactive primary.

In aggressive mode, the initiator sends its identification (IDi) along with the Diffie-Hellman values in the first packet, and the responder returns its identification (IDr) in the second packet. Because the shared secret is not yet computed when these packets are exchanged, no encryption keys exist, so the ID payloads are transmitted in plaintext. A passive attacker on the network path can capture these packets and directly read the identities of the VPN peers. This is the primary reason aggressive mode is considered insecure for identity protection.

Because FortiGate evaluates firewall policies in ascending order of policy ID, the deny at ID 5 is checked before the allow at ID 10. The source 192.168.10.0/24 is entirely within the broader 192.168.0.0/16 object used by the deny policy, so the traffic satisfies all matching criteria of ID 5 and is denied immediately, never reaching ID 10.

Email filtering for SMTP on FortiGate is performed by the antivirus/email filter proxy engine, which only operates in proxy-based inspection mode. When a firewall policy is set to flow-based inspection, the FortiGate uses a streamlined forwarding path that does not support SMTP proxy functionality, so the email filter profile is silently ignored for that traffic. To enforce email filtering, the policy must use proxy-based inspection (or configure a transparent proxy), allowing the FortiGate to buffer and scan SMTP messages before forwarding them.

In the Web Filter profile, 'Log All Blocked Sites' is the switch that generates a log entry whenever the FortiGate denies access to a URL based on a blocked category or explicit URL. This profile-level toggle is required for the blocked request to appear in the traffic log along with the relevant URL filter category and action. Without it, even a matching firewall policy with logging enabled will not create a web-filter-specific blocked-site log record.

FortiGate processes traffic through firewall policies, not merely routing. Although the static route directs packets to the tunnel interface, no policy permits the subnet-to-subnet flow, so traffic is dropped. Adding a policy allowing the local and remote subnets across the tunnel interfaces satisfies this requirement.

FortiOS performs first-match evaluation, checking rules top-down and enforcing the first rule whose all conditions (source, destination, service, schedule, etc.) are satisfied. If a broad deny-all is positioned above the specific allow policy, every packet that would otherwise match the allow rule hits the deny-all first and is dropped. That is the classic misordering mistake, and it cannot be compensated for by policy IDs or other attributes.

Enabling session pickup is essential for stateful failover in a FortiGate HA cluster. It synchronizes the session table, including NAT translations, TCP/UDP state, and even application-layer protocol states, between the primary and standby units. This ensures that when a failover occurs, existing connections are not dropped and can continue seamlessly on the new primary. Without session pickup, even if the interface goes down and failover is triggered, all active sessions would be lost, causing disruption to users.

Application control can identify the cloud storage application and apply per-application actions. With SSL deep inspection enabled, it can see inside HTTPS and block only the upload action for that application while allowing download. This meets the requirement precisely without affecting other traffic.

DNS resolution for the Domain Controller is failing. In FSSO polling mode, the FortiGate or collector agent must resolve the Domain Controller's fully qualified domain name to an IP address so it can query the DC's security event logs for user logon events. If DNS resolution fails, the polling connection cannot be established, the FortiGate receives no logon information, and thus no FSSO user sessions are generated in the firewall's session table or user list.

Session synchronization's core purpose is to ensure stateful high availability: if one firewall unit fails or is taken out of service, the cluster's other unit(s) already possess the full session information—including NAT mappings, TCP sequence state, and application-level data—required to continue forwarding traffic without resetting connections. This is achieved by continuously transmitting session updates over the HA heartbeat link from the unit that owns each session to its standby or peer units. By doing so, the cluster can fail over in milliseconds, and existing sessions survive the failure. This is fundamental to delivering uninterrupted connectivity in an enterprise network.

Emergency (severity 0) is the highest log severity level and is reserved for situations where the FortiGate system is completely unusable, such as a kernel panic, total configuration failure, or unrecoverable hardware fault. This level indicates that the firewall cannot perform any of its security functions, and immediate intervention is required, which is exactly what the question asks to identify.

Skype uses transport-layer encryption (TLS) to protect its signaling and media traffic. Without SSL deep inspection enabled in the firewall policy, the FortiGate cannot decrypt the SSL/TLS session to read the application-layer payload where the application signature resides. Consequently, the FortiGate sees only encrypted packets that do not match Skype's signature, so the block rule never triggers. To block Skype effectively, the administrator must enable SSL deep inspection with a valid CA certificate, allowing the FortiGate to proxy and inspect the traffic.

Data Leak Prevention (DLP) is the security profile specifically engineered to detect and prevent the unauthorized transmission of sensitive data. It uses deep content inspection techniques such as exact data matching, regex patterns, and file fingerprinting to identify regulated data elements like PCI-DSS card numbers, HIPAA-protected health records, and PII. DLP also considers contextual factors—source, destination, protocol, and direction—to enforce policies that block, quarantine, or log risky transmissions across SMTP, HTTP, FTP, and cloud apps.

'diagnose sys session list' is the correct command to view the current session table. It reads the kernel session table and outputs every active connection, including source/destination IP addresses, ports, protocol, session state, and timers. This is the standard tool for troubleshooting NAT, policy, and asymmetric routing because it shows exactly what the firewall is tracking in real time.

This command displays the kernel routing table, including the route dynamically inserted for the SSL VPN tunnel interface. By checking it, an administrator can verify that the expected destination routes (or the default route) are present and bound to the SSL-VPN interface, which is essential for diagnosing why client traffic may not be forwarded after a successful SSL VPN handshake.

Proxy-based inspection is the correct mode because it fully buffers the file, forwards it to FortiSandbox, and pauses the session until a verdict is returned. This allows FortiGate to block the file before it reaches the client if FortiSandbox determines it is malicious. The connection-holding behavior is essential for quarantine and real-time enforcement. In contrast, flow-based inspection lacks this holding capability and therefore cannot provide the same level of blocking.

Enabling FortiGuard spam filtering within the Email Filter profile activates the cloud-based spam signature and reputation service. This satisfies the requirement to block spam, since the FortiGate must query FortiGuard to classify and reject unsolicited mail before it reaches the protected mail server.

Both units in a FortiGate HA cluster must run the exact same FortiOS firmware version and build. Mismatched versions can cause the HA protocol to behave unpredictably, leading to split-brain scenarios or failed failovers. Fortinet only supports HA when all cluster members share identical firmware, so this is a hard prerequisite before configuring HA.

In FortiGate policy-based NAT, an IP Pool is only applied when the firewall policy explicitly references it via the 'NAT' section and the 'Use IP Pool' dropdown. Merely creating an IP Pool does not cause it to be used; the pool must be tied to the specific policy that binds the source and destination. Without that selection, the firewall falls back to using the outgoing interface address or no NAT, which would leave the original source IP visible.

FortiGate supports the creation of multiple loopback interfaces, each with its own unique IP address and routing table entries. This allows administrators to deploy several logical endpoints for different services—such as OSPF router IDs, BGP update sources, or management gateways—without consuming physical interface resources. The number of loopbacks is not limited by hardware ports, giving flexibility in network design.

The IPS engine (ipsengine) is the process that actually inspects packets against the signature database; if it is not running or has crashed, no IPS detection can occur. Additionally, the FortiGuard IPS package must be current, as outdated signatures will fail to match recently disclosed vulnerabilities. Running the command 'get ips status' verifies engine status and signature version, and 'execute update now' forces an update, making this the correct and direct remedy.

Installing the FortiGate's CA certificate into the trusted root store of every client establishes the FortiGate as a trusted certificate authority within the organization. When the FortiGate generates a per-session certificate signed by this CA, the client's browser accepts it without warnings because the CA is in its trust store. This directly addresses the root cause of the warning and is the recommended enterprise deployment practice for deep inspection.

The SSL inspection exemption only controls whether the FortiGate decrypts the TLS stream; it does not disable URL/web filtering. FortiGuard can still classify the destination based on the SNI, IP address, or FQDN from the ClientHello, so if the web filter profile blocks the 'Financial Services' category, the session is denied regardless of the decryption bypass. The exemption is the wrong place to expect 'allow' semantics when the web filter policy explicitly says block.

execute backup config is the correct FortiGate CLI command to back up the full configuration. It captures all system, network, and firewall policy settings into a single plain-text file. This command can be run interactively to save to local disk or with parameters like tftp, ftp, or scp for remote transfer. It is the standard, intended method for creating a complete configuration backup.