Fortinet NSE4_FGT_AD-7.6: Cloud FortiGate and FortiSASE Boundaries

A FortiGate protecting a data center, a FortiGate-VM in a public cloud, FortiGate Cloud-Native Firewall (CNF), and FortiSASE do not all sit on the same path or authenticate traffic in the same way. That difference matters on the Fortinet NSE 4 FortiOS 7.6 Administrator exam, whose deployment objectives specifically ask candidates to describe cloud firewalls and explain FortiSASE administration and onboarding. The challenge is to choose a control boundary from the architecture rather than treating every Fortinet name as another interface on a branch appliance.

Imagine a fictional retailer with a headquarters FortiGate, customer-facing cloud workloads in two public cloud regions, and employees connecting from home. Some customer data never crosses the branch, while some users need secure internet access and controlled access to private applications. The retailer is evaluating a virtual firewall in the cloud, FortiGate CNF for certain cloud networks, and FortiSASE for remote access. Each option can improve security, but only if traffic is steered into the right service and the identities and policies are tested separately.

A branch FortiGate can make a route and SD-WAN steering decision because it owns the relevant egress interfaces. A FortiGate-VM in AWS or Azure instead depends on cloud route tables, NICs and security boundaries as well as its own policies; FortiGate CNF and FortiSASE introduce still different control planes. Identify which component actually chooses the path before attributing a cloud connectivity fault to an on-box firewall rule.

Three security controls, three paths

Start by naming the resource that needs protection. A FortiGate-VM is a virtual appliance placed into cloud networking, typically between networks or traffic flows that can be routed through it. FortiGate CNF is a cloud-native firewall offering with its own service onboarding, cloud account integration and policy sets. FortiSASE delivers security functions through a service edge for remote and other supported user access models. It is misleading to compare the three solely on whether their interfaces display firewall policy objects.

Cloud firewalls must integrate with the public cloud’s virtual networks, subnets, route tables and identity permissions. Even an accurate FortiGate firewall policy cannot inspect traffic that bypasses its interface or a CNF service endpoint. FortiSASE has a different first-mile problem: a user’s FortiClient or other supported access method must actually steer traffic to the service, associate the endpoint with the correct profile, and authenticate the person under the intended identity policy. Visibility begins with that journey, not with a security license being active.

The meaningful choice is based on where the packets originate, which entity owns the route and identity, what needs inspecting, and what the operations team can maintain. The three can be complementary; one is not automatically an upgrade path from another.

Place FortiGate-VM where cloud routes can reach it

Fortinet’s public-cloud 7.6 documentation describes FortiGate-VM deployed as a virtual appliance on AWS and Azure. A simplified AWS example places different network interfaces toward public-facing and private subnets. Protected workloads use the intended forwarding path through the FortiGate-VM instead of sending traffic through a route that bypasses it. The cloud route table chooses the next hop before a FortiGate policy can allow or deny a session, so you must confirm both layers.

On Azure, public IP behavior and virtual network interface assignment introduce a separate question: Azure’s network layer can provide address translation between a public address and the FortiGate’s private interface address. A DNAT or VIP configuration that assumes the firewall directly owns that externally visible public IP can be wrong for the chosen deployment. The exam-level insight is not to memorize one marketplace template but to recognize which layer performs which translation. The FortiOS policy and NAT lab explains the on-box policy and VIP side of the decision.

In the fictional retailer, an AWS test instance in a private subnet is unexpectedly reachable through a cloud-managed egress route that does not traverse the virtual firewall. An administrator could tighten every FortiGate policy and still see no change. The correct investigation begins with the cloud route table and the relevant source and destination subnet associations, then with network ACL/security-group controls, NIC attachment and FortiGate sessions. A firewall cannot log packets that never arrive.

Cloud identities control deployment, not user authorization

The identity used to create a firewall service in an AWS or Azure account should not be confused with the application user’s identity passing through that service. Cloud administrator roles and service permissions let deployment tools create interfaces, endpoints and log destinations. FortiGate traffic policies, in turn, decide whether a particular session is permitted and inspected after the cloud delivers it to the enforcement path. Granting an overly broad cloud role to fix a failed deployment can create a management security problem while leaving the data-plane routing issue unresolved.

Think about four independent questions: Who may provision or change the cloud resource? Which network routes or endpoint associations direct traffic to it? What security policy is deployed in the Fortinet control plane? Where do logs and change events go? If an endpoint cannot be created because the cloud service identity lacks permissions, that is not evidence that the application firewall’s deny rule is too restrictive. If endpoint creation succeeds but requests bypass the new service, recheck forwarding and associations rather than IAM permissions alone.

Keep separate records for the cloud subscription/account, deployment region, network identity, policy owner and maintenance window. These are especially useful when multiple teams own infrastructure, security and cloud networking. A successful cloud-console deploy should not be signed off as successful security enforcement until both a legitimate allowed request and a deliberately denied request have been observed at the intended point.

Understand FortiGate CNF onboarding

FortiGate CNF is a different operational model from placing a self-managed VM next to an application server. Fortinet documents an onboarding wizard that begins by adding the cloud account or accounts to be protected, moves through a policy set, and creates a CNF instance with an endpoint in a selected subnet. The cloud-account integration needs permissions to create endpoints, resolve protected resources and send logs to supported cloud storage destinations. That is why the onboarding process has both cloud-side and policy-side steps.

For a fictional application spanning three subnets, a CNF policy that says “inspect all traffic” is not sufficient. Identify which subnets or traffic paths actually have a CNF endpoint, which account the service is authorized to manage, and where the applicable policy set is attached. If two subnets are covered and the third is omitted, a request originating in the third may not take the expected inspection path. A troubleshooting timeline should distinguish failure to add the account, failure to deploy the endpoint, failure to attach the intended policy set, and failure of a protected request under a working deployment.

Do not describe CNF as merely a FortiGate-VM with a different logo. The deployment, ownership, and location of policy enforcement are different enough that the first corrective step changes. On a cloud-network question, look for the network’s actual next hop and protected subnet association before deciding which Fortinet console screen to inspect.

FortiSASE begins with the remote user’s access mode

FortiSASE adds a user and endpoint onboarding process absent from an ordinary cloud firewall deployment. Some users connect with an agent-based FortiClient flow, while supported secure web gateway (SWG) modes can use proxy settings or a proxy autoconfiguration file. An endpoint with a correctly installed application is not automatically an authorized user, and an identity with a valid directory password is not automatically associated with the intended FortiSASE security policy.

Fortinet’s administration guidance describes user/group configuration, supported SSO integrations and invitation-code workflows. In an agent-based flow, a user may receive an invitation or a managed installer, enroll FortiClient, and be assigned an endpoint group and profile. A custom invitation code can assign particular endpoints to a designated profile; a default code may map devices to a default profile. An enrollment failure could involve the invite code, the endpoint’s connectivity to the service, supported client version, identity-provider authentication or a user-group mismatch.

Test identity enrollment and traffic permission separately. A user may authenticate to the identity provider but fail FortiSASE endpoint onboarding, or a connected device may land in a profile that blocks a private application. Appliance-based FortiGate LDAP, RADIUS and FSSO controls answer a different access question from service-edge device registration and policy assignment. Broadening the user’s group until the application works can hide which stage was actually misconfigured.

Proxy mode has a different failure signature

In SWG/proxy mode, FortiSASE can supply a hosted PAC file or explicit proxy server and port values. Those values need to reach the actual browser or operating-system proxy configuration on the endpoint. A user who authenticates to an application but whose browser never sends web traffic to the specified proxy will not demonstrate that FortiSASE inspected the session. Similarly, a proxy configured only for one browser does not prove that every application on the device uses that proxy.

When testing proxy users, document the selected access mode, the PAC or manual proxy configuration, certificate trust requirements for supported inspection and the observed service destination. Distinguish a certificate warning during authorized TLS inspection from failure to enroll FortiClient in agent mode. Both can be described by a user as “FortiSASE is broken,” but they imply very different starting points. Do not assume that the client, browser and service use identical software and profile behavior for all managed and unmanaged endpoints.

FortiSASE’s live features and navigation can change with service releases. Verify the current Fortinet documentation for the target tenant and access mode before following any GUI instructions. Exam-style questions usually supply enough description of an identity provider, invitation flow or SWG configuration to determine whether the missing component is enrollment, group assignment, policy, proxy steering or certificate trust.

A case study: the same application fails three ways

The fictional retailer tests its ordering application from a protected cloud VM, an employee laptop with FortiClient, and an unmanaged consultant laptop configured for web proxy. The cloud VM times out on the private service, the employee logs in but is denied the application, and the consultant’s browser goes directly to the public internet. The application team’s first proposal is to change the FortiGate policy to allow all sources. That change cannot plausibly solve all three problems because the sessions have different start points and inspection paths.

The safe remediation changes the narrowest layer shown by evidence. If the cloud route is bypassing the firewall, correct the forwarding design through the authorized infrastructure change process and retest. If a SASE user is enrolled to the wrong endpoint profile, correct the profile/group assignment and test both positive and denied destinations. If SWG steering is absent, correct the supported proxy or PAC configuration. Treat broad “allow all” rules and open management ports as signs that diagnosis has skipped a boundary.

Translate cloud and SASE architecture into NSE 4 reasoning

When a question mentions FortiGate-VM, identify the cloud network and its route/NIC security layers. When it mentions CNF, identify the cloud account integration, endpoint/policy-set deployment and protected subnet. When it mentions FortiSASE, identify whether a remote user is enrolling an agent, authenticating through an IdP, receiving a profile, or steering browser traffic through SWG. These are not three names for the same FortiGate CLI feature.

End with two verification outcomes: a known legitimate request should reach the intended destination under the correct profile, and a separate denied request should fail at the intended enforcement point with useful logs. A correct architecture explains both results without depending on unrestricted cloud roles, a public management plane or indiscriminate policy exceptions. This lab uses illustrative network/identity cases and does not claim that an AWS, Azure, CNF or FortiSASE tenant was provisioned or live-tested.