Implementation recipe
Remote access for a small office: FortiGate IPsec VPN with FortiClient and Entra ID sign-in
People working away from the office reach the office network only through an encrypted IPsec tunnel to the office FortiGate, after signing in to Microsoft Entra ID with multifactor authentication, with their IPv4 traffic sent through the tunnel, IPv6 blocked outside it, and every connection logged; the tests at the end show what a connected laptop can still reach directly. One worked example: other VPN products can do the same job, and naming this one is not a ranking.
From vendor documentation, not run by Expert CMMC.
Each setting below quotes the vendor’s own page with the date it was read. Expert CMMC has not run this configuration. Run the tests at the end on your own systems before you rely on it.
Last reviewed November 12, 2026.
Before you choose this example
What this recipe was written against, what it needs, and whether its cryptography is established for CUI. Read this before the configuration: it decides whether the example fits you.
Written against
- FortiOS 7.6.1 or later on the office FortiGate (external-browser sign-in for dial-up IPsec starts at 7.6.1; SSL VPN tunnel mode is gone from 7.6.3).
- FortiClient for Windows or macOS 7.2.5 or later, or 7.4.1 or later except 7.4.4 and 7.4.5, IKE version 2 only. FortiClient for Linux is not covered: Block IPv6 does not support it.
- Microsoft Entra ID in Microsoft's global service, with the FortiGate SSL VPN gallery application and Conditional Access authentication strengths. Entra ID for US Government was not checked.
- Fortinet's FortiOS 7.6.6 and 7.6.7 administration guides and the FortiEndpoint (EMS) IPsec VPN profile page, latest version, read 2026-11-11 and 2026-11-12.
Licences and management components
- FortiClient EMS (FortiEndpoint) to push the IPsec profile: Use External Browser as User-Agent and Block IPv6 are documented only as EMS profile settings. Whether a FortiClient installed without EMS offers them was not established; without EMS, run the IPv6 test below and decide from what you see.
- Which FortiClient licence includes EMS management, and whether your FortiGate support contract covers it, was not established here: ask Fortinet or your reseller before you buy.
- Microsoft Entra ID with Conditional Access for the authentication strength. The licences are under Before you start, from the product catalog.
- A public certificate for the VPN gateway's DNS name on the FortiGate.
Cryptography, end by end
The FortiGate (FortiOS), the office end of the tunnel: not established
- Module and certificate
- Fortinet's FIPS page, read 2026-11-12, lists FortiOS 7.2/7.4 (Level 1) and FortiGate 7.2/7.4 (Level 2) under FIPS 140-3. It lists no FortiOS 7.6 validation, and this recipe needs 7.6.1 or later.
- Operating environment
- Fortinet: a Level 1 certificate covers effectively all models that run the certified build; a Level 2 certificate covers the exact build and hardware model. Your FortiOS 7.6 build is not among them on Fortinet's page.
- Required configuration
- Not read: the security policy, which Fortinet says tells how to deploy the product in a FIPS-compliant manner and which configurations are validated.
- Look up before relying on it for CUI
- On NIST's CMVP search, a certificate for your FortiOS version (and, for Level 2, your model), its status, and its security policy's required configuration. Until one covers the version you run, record the gap for SC.L2-3.13.11 and AC.L2-3.1.13.
“A Level 1 certificate applies to effectively all the models supported by the certified build(s). … A Level 2 certificate applies to the exact combination of the certified build(s) and hardware model(s). … The SP describes the product and includes instructions for deploying the product in a FIPS-compliant manner. The SP also states exactly what configuration(s) of the product are validated such as hardware versions, firmware/software versions. FIPS 140-3 Validation List FortiGate/FortiOS Certification FortiOS 7.2/7.4 Level 1 FortiOS 7.2/7.4 VM Level 1 FortiGate 7.2/7.4 Level 2 FortiClient Certification FortiClient Crypto Module v1.0 FortiClient 7.0”
FortiClient, the laptop end of the tunnel: not established
- Module and certificate
- Fortinet's FIPS page lists "FortiClient Crypto Module v1.0" and "FortiClient 7.0" under FIPS 140-3. On NIST's pages (read 2026-11-12), FortiClient Crypto Module v1.0 (#5493) is FIPS 140-3 and Active, sunset 8/16/2031, and FortiClient Crypto Library (#4931) is FIPS 140-3, Active as an interim validation, sunset 12/19/2026. Which of these the FortiClient 7.2 or 7.4 you install uses, and whether it runs in its approved mode, was not established.
- Operating environment
- NIST lists #4931 as tested on Microsoft Windows 10; the tested environments of #5493 were not shown on the page read. macOS was not checked.
- Required configuration
- Not read: each certificate's security policy (NIST's caveat for #4931: "When installed, initialized and configured as specified in Section 11.1 of the Security Policy").
- Look up before relying on it for CUI
- From Fortinet: the module and certificate inside the FortiClient version you deploy, the operating systems it was tested on, and the configuration its security policy requires. Until then, record the gap for SC.L2-3.13.11 and AC.L2-3.1.13. Do not cite #4931 in your records: it is an interim validation whose sunset date, 12/19/2026, is five weeks after it was read here.
“Certificate #5493 Details Module Name FortiClient Crypto Module v1.0 Standard FIPS 140-3 Status Active Sunset Date 8/16/2031”
“Certificate #4931 Details Module Name FortiClient Crypto Library Standard FIPS 140-3 Status Active Sunset Date 12/19/2026 … Caveat Interim Validation. When installed, initialized and configured as specified in Section 11.1 of the Security Policy. … The module provides cryptographic support for FortiClient, Fortinet’s endpoint security application. … Tested Configuration(s) Microsoft Windows 10 running on a Dell XPS 8700 with a Intel Core i7-4770”
Not suitable when
- A FortiGate that cannot run FortiOS 7.6.1 or later, or a fleet that must keep FortiClient 7.4.4 or 7.4.5.
- Laptops running Linux, or FortiClient without EMS where the IPv6 test shows IPv6 leaving outside the tunnel.
- An Entra ID tenant in Microsoft's US Government cloud until the gallery app, the authentication strength and the sign-in host are checked there.
- Where a FIPS-validated module is required at both ends today: neither end is established for the versions this recipe needs.
- Users whose second factor does not complete in the browser FortiClient opens (the pilot shows this).
- Laptops whose browser cannot pass device identity to Entra ID, where the compliant-devices recipe's policy (All users, All resources) also covers the VPN sign-in: on Windows, an Edge profile not signed in with the work account, Chrome without the Microsoft Single Sign On extension or CloudAPAuthEnabled, Firefox without "Allow Windows single sign-on for Microsoft, work, and school accounts", a private window, or cookies turned off. Whether FortiClient's internal browser passes device identity is not established: this recipe uses the external browser.
Stays with you, whichever product you use
- Who may connect and to what, and the group and firewall destinations that enforce it.
- The FortiOS and FortiClient versions, their patches, and the certificate record or gap for each end.
- Keeping the emergency access accounts out of the VPN group, and the pre-shared key secret.
- Reviewing the remote access and sign-in logs.
“Dialup IPsec VPN with SAML using an external browser for authentication is supported starting from FortiOS 7.6.1, FortiClient (Windows) and (macOS) 7.2.5 and 7.4.1 and FortiClient (Linux) 7.4.3.”
“Windows 10 + Microsoft Edge, Chrome, Firefox 91+ … These browsers support device authentication, allowing the device to be identified and validated against a policy. The device check fails if the browser is running in private mode or if cookies are disabled. Note Microsoft Edge 85+ requires the user to be signed in to the browser to properly pass device identity. Otherwise, it behaves like Chrome without the Microsoft Single Sign On extension. … Firefox 91+ is supported for device-based Conditional Access, but "Allow Windows single sign-on for Microsoft, work, and school accounts" needs to be enabled. … For Chrome support in Windows 10 Creators Update (version 1703) or later, install the Microsoft Single Sign On extension or enable Chrome's CloudAPAuthEnabled.”
“FortiClient 7.4.4 and later versions do not support IPsec VPN IKEv1. … Block IPv6 Blocks IPv6 traffic sent outside of VPN interface when connected to an IPv4 full tunnel. This option does not support the following: FortiClient (Linux) FortiClient 7.4.4 and 7.4.5 (due to lack of IPv6 support for IPsec VPN)”
“All the national clouds authenticate users separately in each environment and have separate authentication endpoints. … Microsoft Entra ID for US Government https://login.microsoftonline.us … Microsoft Entra ID (global service) https://login.microsoftonline.com”
“This following tables list Microsoft Entra feature availability in Azure for US Government. … SaaS apps with modern authentication (Microsoft Entra application gallery apps, SAML, and OAUTH 2.0) ✅ … Conditional Access ✅”
Practices this supports
Following this recipe supports these practices and objectives. It does not by itself meet any of them: each practice also needs what its page lists (policy, procedure, evidence and the parts this recipe leaves to you).
- AC.L2-3.1.12[a] [b] [c] [d]One permitted type of remote access, controlled by group and firewall policy and monitored through the sign-in and traffic logs.
- AC.L2-3.1.13[a] [b]The tunnel's IPsec proposals are the cryptographic mechanism protecting remote sessions. FIPS validation is a separate check (see limits).
- AC.L2-3.1.14[a] [b]The FortiGate is the one managed access point, and remote traffic reaches the office only through it.
- IA.L2-3.5.3[d]Every remote network connection requires Entra ID sign-in with the authentication strength you set.
- SC.L2-3.13.7[a]The IPv4 split tunnel is off and IPv6 is blocked outside the tunnel; the four bypass tests (IPv4, IPv6, DNS, local network) show what a connected laptop can still reach directly.
Applies to
- Information
- FCI and CUI
- Systems
- A FortiGate at the office on FortiOS 7.6.1 or later
- Company Windows or macOS laptops with FortiClient 7.2.5 or later, or 7.4.1 or later but not 7.4.4 or 7.4.5 (external-browser sign-in starts at 7.2.5 and 7.4.1; Block IPv6 is not supported on 7.4.4 and 7.4.5), managed by FortiClient EMS for the two settings Fortinet documents only in the EMS profile
- Users in Microsoft Entra ID
- Tenant
- A Microsoft Entra ID tenant in Microsoft's global (commercial) service as the identity provider: the pages this recipe quotes are for it. Not checked for Entra ID for US Government (GCC High and DoD): Microsoft gives it a separate sign-in host, and its feature table, read 2026-11-12, lists gallery apps, SAML and Conditional Access but not authentication strengths; whether the FortiGate SSL VPN gallery app is offered there was not checked. Which cloud a GCC tenant signs in to was not checked either. The FortiGate is your own equipment in your office.
- Versions
- Fortinet's FortiOS 7.6 Administration Guide (the dial-up IPsec SAML page at 7.6.7 and the Entra ID page at 7.6.6, and the FortiGate as dialup client page at 7.6.7), the FortiOS 7.6.3 release notes and the FortiEndpoint guide's IPsec VPN profile page, read 2026-11-11 and again 2026-11-12, and Fortinet's FIPS page, read 2026-11-12; Microsoft Learn's authentication strengths (updated 2025-03-04), enterprise application properties (2026-10-20), report-only (Conditional Access policy impact), Conditional Access conditions (2026-09-28, read 2026-11-12), national cloud endpoints and US Government feature availability pages, read 2026-11-11 and 2026-11-12; NIST CMVP certificates #4931 and #5493, read 2026-11-12.
Before you start
Licences
FortiGate · FortiGate firewalls on FortiOS, with FortiClient for remote access
The office firewall that ends the tunnels, and FortiClient on each laptop.
Microsoft Entra ID · Microsoft Entra ID Free, P1 and P2, and Microsoft Entra ID Governance
Sign-in to the VPN through Entra ID, and the Conditional Access policy that sets which second factor is accepted.
Microsoft's multifactor authentication licensing table marks Conditional Access for Entra ID P1 and P2 (not for the free tiers or Office 365), and risk-based Conditional Access for P2 only. Source, checked November 11, 2026. Plans change; confirm before buying.
Administrator roles
- FortiGate administrator with write access to VPN, user and authentication, and firewall policy: The SAML server, the tunnel and the firewall policies.
- Entra ID: Cloud Application Administrator (or Application Administrator): The enterprise application that the FortiGate trusts for sign-in.
- Entra ID: Conditional Access Administrator: The policy that sets the accepted second factor for the VPN.
Devices
- Company laptops, preferably the compliant laptops of the first recipe.
- A public certificate for the VPN gateway's DNS name (for example vpn.example.com) installed on the FortiGate.
Already in place
- A remote access policy that says who may connect, from which devices, and to which internal systems (AC.L2-3.1.12).
- Two emergency access accounts excluded from Conditional Access policies that block or restrict sign-in, as Microsoft advises, and kept out of the VPN group.
- If the FortiGate still runs SSL VPN tunnel mode, a plan to move every user to IPsec before upgrading to FortiOS 7.6.3.
Do first, or alongside: Company Windows laptops reach company data only when they are compliant.
Configuration
Before you start: the FortiOS version and SSL VPN
FortiOS version
FortiGate: the firmware version (get system status in the CLI)
Value7.6.1 or later. If users connect with FortiClient's SSL VPN today, move them to the IPsec tunnel below before upgrading to 7.6.3: SSL VPN tunnel mode is gone from 7.6.3 and its settings are not carried over.
WhyExternal-browser sign-in for dial-up IPsec starts at FortiOS 7.6.1, and SSL VPN tunnel mode is not a remote access option on current FortiOS.
“customers must migrate their SSL VPN tunnel mode configuration to IPsec VPN before upgrading to FortiOS 7.6.3.”
“Dialup IPsec VPN with SAML using an external browser for authentication is supported starting from FortiOS 7.6.1, FortiClient (Windows) and (macOS) 7.2.5 and 7.4.1 and FortiClient (Linux) 7.4.3.”
Entra ID: the VPN as an enterprise application
Fortinet's page "Configuring Microsoft Entra ID as SAML IdP and FortiGate as SAML SP" gives these steps. The FortiGate's SAML addresses use your gateway's DNS name and the SAML port you choose below.
Enterprise application
Entra admin center > Enterprise applications > New application
ValueAdd the gallery application FortiGate SSL VPN and rename it FortiGate IPsec VPN. Assign only the security group of people allowed remote access.
WhyThe FortiGate trusts this application's sign-in. Fortinet's own wording is that the gallery application is named for SSL VPN and should still work with IPsec: the pilot is where you confirm it does.
“Click on New application and search for FortiGate SSL VPN. The application is named for "SSL VPN" but should still work with the IPsec VPN configuration.”
Assignment required?
Enterprise application > Properties
ValueYes
WhyOnly the assigned group can sign in to the VPN application, with one exception: Microsoft says a Global Administrator signs in to applications whatever this setting says. For a Global Administrator, the FortiGate's firewall policy, which lets only the VPN user group through (below), is what stops the connection; the refused tests check both.
“If this option is set to Yes, then users and other applications or services must first be assigned this application before being able to access it. If this option is set to No, then all users are able to sign in … Users with a Global Administrator role can sign in to applications, regardless of the assignment required settings.”
Identifier, Reply URL, Sign on URL, Logout URL
Enterprise application > Single sign-on > SAML > Basic SAML Configuration
Valuehttps://<gateway DNS name>:<SAML port>/remote/saml/metadata for the Identifier; /remote/saml/login for Reply and Sign on; /remote/saml/logout for Logout. Copy them from the FortiGate's Single Sign-On page.
WhyEntra ID sends the signed sign-in response only to the FortiGate's own address.
“In Identifier, enter a URL in the pattern https://<FortiGate IP or FQDN address>:<Custom SAML-IKE port>/remote/saml/metadata”
Claims
Enterprise application > Single sign-on > Attributes & Claims
ValueAdd new claim: Name username, Source attribute user.userprincipalname. Add a group claim: All groups, with the group claim's name customised (Advanced options) to group.
WhyThe FortiGate matches the group claim to the user group allowed through the firewall policy. Fortinet's steps select All groups; the claim then carries the groups the person belongs to, and the FortiGate looks for the VPN group's Object ID among them.
“Select Add new claim. For Name, enter username. For Source attribute, select user.userprincipalname. Select Save. Select Add a group claim. Select All groups. Under Advanced options, select the Customize the name of the group claim. For Name, enter group. Select Save.”
Signing Option
Enterprise application > Single sign-on > SAML Signing Certificate
ValueSign SAML response and assertion. Download the Certificate (Base64) for the FortiGate.
WhyThe FortiGate checks Entra ID's signature before it accepts a sign-in.
“In the SAML Signing Certificate section, click Edit, set Signing Option to Sign SAML response and assertion, then click Save.”
Grant: Require authentication strength
Entra admin center > Conditional Access > New policy (Users: All users, excluding the emergency access accounts; Target resources: the FortiGate IPsec VPN application)
ValuePhishing-resistant MFA strength (Windows Hello for Business or platform credential, a FIDO2 security key, or certificate-based authentication). If a method your users hold does not complete in the browser FortiClient opens during the pilot, use the Multifactor authentication strength for those users and record the decision and the date you will revisit it. Enable policy: Report-only when you create it; switched to On in Rolling it out, once the pilot's report-only results are read.
WhyMultifactor authentication for each VPN sign-in by the people the policy includes, with the phishing-resistant methods preferred; the emergency access accounts are excluded, and the firewall policy's group match stops them instead. Microsoft describes the phishing-resistant methods as methods that need an interaction between the method and the sign-in surface, which is why the pilot must show they work in FortiClient's browser.
ThenThe policy's Enable policy set from Report-only to On, once the pilot's report-only results show every pilot user meeting the strength (Rolling it out).
Microsoft's multifactor authentication licensing table marks Conditional Access for Entra ID P1 and P2 (not for the free tiers or Office 365), and risk-based Conditional Access for P2 only. Source, read November 11, 2026.
“They can choose from three built-in authentication strengths: Multifactor authentication strength, Passwordless MFA strength, and Phishing-resistant MFA strength. … Phishing-resistant MFA strength: Includes methods that require an interaction between the authentication method and the sign-in surface.”
“Confirm your settings and set Enable policy to Report-only. Select Create to enable your policy. After confirming your settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.”
FortiGate: the SAML server and the dial-up IPsec tunnel
Fortinet's page "SAML-based authentication for FortiClient remote access VPNs" (FortiOS 7.6.7 Administration Guide) gives these steps for FortiOS 7.6. Where it does not give a FortiGate-side path or value, the setting says so.
auth-ike-saml-port
FortiGate CLI: config system global
ValueA TCP port of your choice for sign-in (Fortinet's example uses 9443). If you run the VPN over TCP, Fortinet says the ike-tcp-port then takes precedence: use the ike-tcp-port wherever this recipe says the SAML port (the SAML server's address and the Entra URLs), and give auth-ike-saml-port a different port.
WhyFortiClient starts each connection by fetching the sign-in from this port.
“Configure a suitable TCP port number for SAML authentication (auth-ike-saml-port) used by FortiGate. This example uses port 9443 and the setting is configurable using the CLI. … The FortiGate authd daemon can support SAML authentication by listening for authentication messages from the FortiClient on the TCP port number configured in the auth-ike-saml-port setting (0 - 65535, default = 1001). … If VPN over TCP is used, then the port defined in ike-tcp-port takes precedence … Use the ike-tcp-port in your user.saml definitions. Do not assign the same port to ike-tcp-port and auth-ike-saml-port when VPN over TCP is used.”
Certificate
FortiGate: User & Authentication > Authentication Settings > Certificate
ValueThe public certificate whose common name is the VPN gateway's DNS name.
WhyFortiClient checks this certificate when it first connects; a mismatch produces a warning users learn to click through.
“To prevent an invalid server certificate prompt on FortiClient, the certificate's common name (CN) should match the IPsec VPN remote gateway's FQDN.”
SAML server
FortiGate: User & Authentication > Single Sign-On > Create new
ValueName it (for example saml-entra-id); Address <gateway DNS name>:<SAML port>; Identity Provider Details Type Custom, with the Entra Login URL, Microsoft Entra Identifier and Logout URL; Entra's signing certificate imported under System > Certificates as a Remote Certificate; Additional SAML Attributes: username to identify users and group to identify groups (the claim names above). Then a user group (User & Authentication > User Groups) with this SAML server as its remote server, matched to the Entra group's Object Id.
WhyThis is the FortiGate's side of the trust with Entra ID, and the group that decides who gets through. Without the group attribute, the FortiGate cannot match the Entra group to the user group.
“On the FortiGate, go to User & Authentication > Single Sign-On > Create new. … In Identity Provider Details, set the Type as Custom. … In the Additional SAML Attributes section, enter the following attributes: Attribute used to identify users username Attribute used to identify groups group … Go to User & Authentication > User Groups > Create New. Enter Name as SAML-ENTRA-ID-Group. In Remote Groups, click Add. From the Remote Server dropdown, select saml-entra-id SAML server. In Groups, click Specify and paste the Object ID”
ike-saml-server
FortiGate CLI: config system interface > edit <the interface the VPN traffic arrives on>
ValueThe SAML server above, set on the interface that first receives FortiClient's traffic (usually the WAN interface; for a tunnel on a loopback, on both the loopback and the WAN interface).
WhySet on the wrong interface, the sign-in request never reaches the listener and the tunnel fails in phase 1.
“The ike-saml-server setting must be configured on the interface that is the first point of contact for FortiClient traffic.”
Remote Gateway, IKE version, EAP
FortiGate: VPN > VPN Tunnels > Create New > Custom IPsec Tunnel
ValueIP Version: IPv4. Remote Gateway: Dialup User. Interface: the IPsec tunnel gateway interface (the WAN interface FortiClient connects to). Mode Config: Enable, IPv4. Assign client IP: Enable, with an address object holding the range of client addresses (Fortinet's example: 10.212.134.1 to 10.212.134.200) and Subnet Mask 255.255.255.255: the tunnel carries IPv4 only (IPv6 is blocked outside it on the laptop, below). IKE version 2. EAP: Enable, EAP identity request. User group: Inherit from policy (the group is set in the firewall policy only, below). Phase 2 selectors: Create New, named for the tunnel.
WhySign-in through Entra ID works only on IKE version 2; the user is authenticated over EAP inside it. Fortinet's example tunnel is IPv4; carrying IPv6 inside the tunnel (FortiClient's IPv4 and IPv6 dual stack mode) is another path this recipe does not cover.
“FortiClient 7.2.4 GA and above supports only IKEv2 for SAML authentication. … Network IP Version IPv4 Remote Gateway Dialup User Interface port1 Select the IPsec tunnel gateway interface. Mode Config Enable Select IPv4. Assign client IP Enable Select Address/Address Group from the dropdown list. IPv4 client IP range VPN_Client_IP_Range VPN_Client_IP_Range is configured from 10.212.134.1 to 10.212.134.200. … Subnet Mask 255.255.255.255 … IKE version 2 EAP Enable Select EAP identity request … User group Inherit from policy … In the Phase 2 selectors table click Create New: Set Name to FCT_SAML.”
“When Mode Config is selected, select from one of following mode configuration types: IPv4 only (default) IPv6 only IPv4 & IPv6 dual stack”
IPv4 split tunnel
The same tunnel > Network
ValueDisable (full tunnel for IPv4). DNS: Specify, with the DNS server remote users should use (an office server if they need internal names; Fortinet's example gives a public resolver, 8.8.8.8).
WhyWith the IPv4 split tunnel off, a connected laptop's IPv4 traffic is meant to go through the office (SC.L2-3.13.7). This setting says nothing about IPv6, DNS or the laptop's local network: Block IPv6 and Enable Local LAN below, and the four bypass tests, cover those.
“The example discussed uses full-tunnel IPsec VPN. … DNS Specify IPv4 DNS 8.8.8.8 IPv4 split tunnel Disable”
Encryption, authentication and Diffie-Hellman groups
FortiClient > the connection > Advanced Settings > Phase 1 IKE Proposal and Phase 2 IKE Proposal (or the same in the EMS profile); on the FortiGate, the same tunnel's Phase 1 and Phase 2 proposals. Fortinet's page gives the FortiClient values only: its FortiGate tunnel steps list no proposals, so the FortiGate-side path and values are not established by the page.
ValuePhase 1: AES 256 with SHA 256, Diffie-Hellman groups 20 and 21. Phase 2: AES 256 with SHA 256, Diffie-Hellman group 20. In FortiClient as above; on the FortiGate, set the tunnel's proposals to the same, because Fortinet says the two must match exactly. Fortinet's example also offers AES 128 with SHA 256 in both phases; this recipe leaves it out (Expert CMMC's choice, not Fortinet's). Confirm on the FortiGate with diagnose vpn ike gateway list for a live connection: Fortinet's sample output shows proposal: aes256-sha256.
WhyThese settings protect the session's confidentiality; a mismatch stops the tunnel coming up. Whether these algorithms run in a FIPS-validated module at each end is a separate question (Before you choose this example).
“Advanced Settings > Phase 1 IKE Proposal Encryption: AES 128, Authentication: SHA 256 Encryption: AES 256, Authentication: SHA 256 DH Group 20, 21 Advanced Settings > Phase 2 IKE Proposal Encryption: AES 128, Authentication: SHA 256 Encryption: AES 256, Authentication: SHA 256 DH Group 20 Make sure that the Phase 1 and Phase 2 settings, including encryption algorithms, authentication methods, Diffie-Hellman (DH) groups, and other parameters, that are configured on FortiClient exactly match the corresponding Phase 1 and Phase 2 settings defined on the FortiGate IPsec tunnel. A mismatch in any of these parameters will cause the tunnel negotiation to fail.”
“Verify the IKE gateway list: # diagnose vpn ike gateway list … eap-user: testuser … status: established … proposal: aes256-sha256”
Pre-shared key
The same tunnel > Authentication
ValueA long random key used only for this tunnel, delivered to laptops by your device management or FortiClient EMS rather than by email, and changed when a laptop is lost or a person leaves.
WhyThe laptops share this one key (Fortinet: the same key on FortiClient): it lets a laptop start the tunnel, and the person is then signed in by Entra ID. Treat it as a secret; changing it means giving the new key to the laptops you keep (the lost-laptop test below).
“Enter the unique pre-shared key. Use the same key on FortiClient.”
Where the SAML user group is set
The tunnel's Phase 1 (authusrgrp) or the firewall policy (groups)
ValueIn the firewall policy only.
WhySet in both places, traffic stops flowing through the tunnel. The group match is also what stops a Global Administrator who is not in the VPN group: Entra ID signs such an account in whatever Assignment required says, and Fortinet says the group must match for traffic to flow. Fortinet does not say whether the tunnel itself comes up for such a user; the refused test checks that no traffic reaches the office.
“The SAML group configured, <group-name>, must be either configured inside the IPsec Phase 1 setting, set authusrgrp <group-name>, or in the firewall policy, set groups <group-name>, to allow the traffic to flow through the IPsec tunnel. If the SAML group is configured in both IPsec Phase 1 and firewall policy, the traffic stops to flow through the IPsec tunnel.”
FortiGate: firewall policies from the tunnel
Policy from the tunnel to the office network
FortiGate: Policy & Objects > Firewall Policy > Create New
ValueIncoming interface: the tunnel. Outgoing: only the internal networks remote users need. Source: the client address range and the SAML user group. Service: only the services they need (Fortinet's example allows ALL; narrow it). Because the tunnel is full, a second policy from the tunnel to the internet. Whether that second policy needs NAT is not on Fortinet's page (not established): set it as your FortiGate's other internet policies are set, and let the IPv4 test below, which expects the office's public address, confirm it.
WhyRemote users reach the destinations and services your remote access policy names, through one managed access point.
“As IPsec tunnel configured as full-tunnel, create another policy to allow traffic from IPsec to Internet, to allow FortiClient to access Internet through IPsec tunnel.”
Log Allowed Traffic
Each policy from the tunnel > Logging Options (CLI: set logtraffic all)
ValueAll Sessions, with logs sent to where you keep audit records.
WhyEvery remote session is recorded, so remote access can be monitored.
“To make sure that the logs are collected and shown under Forward Traffic, set Log Allowed Traffic to All Sessions in the corresponding firewall policy configured under Policy & Objects > Firewall Policy.”
FortiClient on each laptop
IPsec VPN connection
FortiClient > Remote Access > Add a new connection (or the same profile pushed by FortiClient EMS)
ValueRemote Gateway: the gateway's DNS name. Authentication Method: Pre-shared key with Enable Single Sign On (SSO) for VPN Tunnel. Customize port: the SAML port. Advanced Settings > VPN Settings: IKE Version 2; Options: Mode Config. Proposals matching the FortiGate (below).
WhyThe profile that sends the person to Entra ID before the tunnel comes up. Mode Config here matches Mode Config on the FortiGate's tunnel (above).
“Remote Gateway <VPN Gateway FQDN> or <VPN Gateway IP> Authentication Method Pre-shared key with Enable Single Sign On (SSO) for VPN Tunnel enabled. Customize port 9443 Advanced Settings > VPN Settings IKE Version 2 Options Mode Config”
Use External Browser as User-Agent
FortiClient EMS (FortiEndpoint): the Remote Access profile > the IPsec VPN tunnel, with Enable Single Sign On (SSO) for VPN Tunnel on
ValueOn (FortiOS 7.6.1 or later, FortiClient 7.2.5 or 7.4.1 or later; IKE version 2 only).
WhySign-in runs in the laptop's own browser rather than FortiClient's embedded window. Check during the pilot that the second factor you require completes there. On Macs, Fortinet notes that the connection may fail if Safari's setting to warn before connecting to a website over HTTP is on.
“Use External Browser as User-Agent: Select whether to use the FortiClient internal browser or an external browser to authenticate the user. Using an external browser is only available for IKEv2 tunnels. … Available if you enable Enable Single Sign On (SSO) for VPN Tunnel. … On FortiClient (macOS), if Non-Secure site connections > Warn before connecting to a website over HTTP is enabled in Safari and using an external browser for SAML authentication is configured, VPN connection may fail.”
Block IPv6
FortiClient EMS (FortiEndpoint): the Remote Access profile > IPsec VPN > Block IPv6
ValueOn. FortiClient for Windows or macOS other than 7.4.4 and 7.4.5; not available for Linux. Without EMS, Fortinet's pages read here do not show how to set it: run the IPv6 bypass test, and if IPv6 reaches the internet outside the tunnel, do not rely on this recipe for SC.L2-3.13.7 until it is fixed.
WhyThe tunnel carries IPv4 only. On a network that gives the laptop IPv6, IPv6 traffic would otherwise have a path outside the tunnel; Fortinet describes this option as blocking IPv6 sent outside the VPN interface when connected to an IPv4 full tunnel.
“Block IPv6 Blocks IPv6 traffic sent outside of VPN interface when connected to an IPv4 full tunnel. This option does not support the following: FortiClient (Linux) FortiClient 7.4.4 and 7.4.5 (due to lack of IPv6 support for IPsec VPN)”
Enable Local LAN
FortiClient EMS (FortiEndpoint): the Remote Access profile > the IPsec VPN tunnel > Phase 1 (the option after NAT Traversal) > Enable Local LAN
ValueOff.
WhyFortinet's page describes this option only as "Enable local LAN" and does not say what traffic it allows. Leave it off and let the local-network bypass test show what a connected laptop can reach on the network it sits on (a home printer or router).
“Phase 1 Select the encryption and authentication algorithms used to generate keys for protecting negotiations … NAT Traversal Select the checkbox if a NAT device exists between the client and the local FortiGate. The client and the local FortiGate must have the same NAT traversal setting (both selected or both cleared) to connect reliably. Enable Local LAN Enable local LAN.”
Disable Default Route
FortiClient EMS (FortiEndpoint): the Remote Access profile > IPsec VPN > Disable Default Route
ValueOff.
WhyFortinet describes the option only as "Disable default route to gateway". For a full tunnel the laptop's default route should go through the tunnel, so leave it off; the IPv4 test below checks the route.
“Disable Default Route Disable default route to gateway.”
Do Not Accept Invalid Server Certificate for SAML auth
FortiClient EMS (FortiEndpoint): the Remote Access profile > IPsec VPN > Do Not Accept Invalid Server Certificate for SAML auth
ValueOn.
WhyWith the gateway's certificate matching its DNS name (above), there is no warning for users to click through; this makes FortiClient refuse the connection when the certificate is invalid instead of leaving the choice to the user.
“Do Not Accept Invalid Server Certificate for SAML auth FortiClient does not complete the requested VPN connection when an invalid VPN server certificate is used for SAML authentication.”
Rolling it out
Pilot first
- Build the tunnel beside any VPN you run today, with a pilot Entra group of two or three people, and keep the old path until the pilot has run through a normal working week.
- Create the Conditional Access policy for the VPN application in Report-only first and read the sign-in log entries for the pilot users: they show the method each person used and whether the phishing-resistant strength would have been met.
- On each laptop model and operating system you use, confirm that the second factor you require completes in the browser FortiClient opens.
- If the compliant-devices recipe is in place, its Conditional Access policy (All users, All resources) also covers the VPN application, so the VPN sign-in in FortiClient's browser must pass the laptop's device identity. Microsoft: the device check fails in a private window or with cookies off; on Windows, Edge passes it only when the user is signed in to the browser, Chrome needs the Microsoft Single Sign On extension or CloudAPAuthEnabled, and Firefox needs Allow Windows single sign-on for Microsoft, work, and school accounts. Set the laptops' default browser accordingly, and check in each pilot user's sign-in log entry for FortiGate IPsec VPN that the compliant-device policy shows the device as compliant. Whether FortiClient's internal browser passes device identity is not established.
“The device check fails if the browser is running in private mode or if cookies are disabled. Note Microsoft Edge 85+ requires the user to be signed in to the browser to properly pass device identity. Otherwise, it behaves like Chrome without the Microsoft Single Sign On extension. … Firefox 91+ is supported for device-based Conditional Access, but "Allow Windows single sign-on for Microsoft, work, and school accounts" needs to be enabled. … For Chrome support in Windows 10 Creators Update (version 1703) or later, install the Microsoft Single Sign On extension or enable Chrome's CloudAPAuthEnabled.”
- When the report-only results show every pilot user meeting the strength with a method that works in FortiClient's browser, set the VPN policy's Enable policy to On. Report-only refuses nobody, so the refused tests below mean nothing until this step: run the passing and refused tests now, and again after any change to the policy.
“During sign-in, the system evaluates policies in report-only mode but doesn't enforce them. Results are logged in the Conditional Access and Report-only tabs of the Sign-in log details. … After confirming your settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On. … Report-only mode evaluates policies but doesn't enforce grant controls or session controls.”
Not locking yourself out
- Make every change to the FortiGate from inside the office (or over its management network), not over the tunnel you are changing.
- Keep a configuration backup of the FortiGate from before the change.
- Exclude the emergency access accounts from the VPN's Conditional Access policy as Microsoft advises, and keep them out of the VPN group. They are Global Administrators, so they pass Assignment required and, being excluded, skip the authentication strength: for them, only the firewall policy's group match stops a VPN connection. The refused test with a Global Administrator checks it.
Rolling back
- Disable the new firewall policies, or remove the pilot group from the Entra application, and users fall back to the old path while it still exists.
- Restore the configuration backup if the change touched more than the new tunnel.
- Once the old SSL VPN or other path is retired, rollback means fixing forward: keep the pilot users until the new tunnel has passed every test below.
Tests
Run these on your own systems and keep the dated results. Each says what you should see.
Should pass
DoFrom a pilot laptop outside the office network, connect FortiClient and complete the Entra ID sign-in with the required second factor.
ExpectThe tunnel comes up. On the FortiGate, diagnose vpn ike gateway list shows the connection with the user as eap-user, the SAML group under groups, and the proposal you set (Fortinet's sample shows aes256-sha256). The Entra sign-in log entry for FortiGate IPsec VPN shows the method used and the Conditional Access policy satisfied.
Should be refused
DoWith the policy On, connect with an ordinary account that is not in the assigned group.
ExpectEntra ID refuses the sign-in and no tunnel comes up.
DoWith the policy On, connect with a Global Administrator account that is not in the VPN group: an emergency access account as your break-glass procedure allows a test sign-in, or a test account given Global Administrator for the test and removed afterwards. Try to reach an office address.
ExpectEntra ID may sign it in, since Microsoft says a Global Administrator signs in regardless of Assignment required. No office address answers: the firewall policy's source is the SAML user group, and this account is not in it. Record whether the tunnel itself came up and what diagnose vpn ike gateway list shows under groups; Fortinet does not say which to expect.
DoWith the policy On, connect with a pilot account that has only a password, or only a method outside the required strength.
ExpectRefused by the authentication strength; the sign-in log entry's Conditional Access tab (not Report-only) names the policy as the reason.
DoConnect with a FortiClient profile holding a wrong pre-shared key or different proposals.
ExpectThe tunnel negotiation fails.
A way around that should fail
DoFrom outside, try the old SSL VPN address and port, and any web portal the FortiGate used to answer on.
ExpectNothing answers. If your FortiGate still offers SSL VPN web mode (Fortinet's FortiOS 7.6.3 release notes call it Agentless VPN, formerly SSL VPN web mode), it is disabled on every interface unless you have decided to use it.
“On the following FortiGate models, the Agentless VPN (formerly SSL VPN web mode) feature is no longer available from the GUI or CLI. Settings will not be upgraded from previous versions.”
DoIPv4: while connected, check the laptop's public IPv4 address (a what-is-my-IP site that reports IPv4) and its routes.
ExpectThe public IPv4 address is the office's, and the default route is through the tunnel.
DoIPv6: connect from a network that gives the laptop an IPv6 address, then open a site that reports your IPv6 address.
ExpectNo IPv6 address is reported and the IPv6 test fails to connect: Block IPv6 stops IPv6 outside the tunnel. If an IPv6 address is reported, IPv6 is leaving outside the tunnel.
DoDNS: while connected, check the DNS server listed for the tunnel adapter (ipconfig /all on Windows, scutil --dns on macOS) and look up a public name; if you chose an office DNS server for the tunnel, look up an internal name too. Then, to see where the queries actually go, capture DNS traffic (port 53) on the laptop's physical network adapter, not the tunnel, while you browse (for example with Wireshark).
ExpectThe tunnel adapter lists the DNS server the tunnel assigns, and the names resolve (the internal name only if that server is an office server). Once the tunnel is up, the capture on the physical adapter shows no DNS queries (start it after connecting: FortiClient looks up the gateway's own name before the tunnel exists). The adapter listing shows only what is configured, and Fortinet's pages read here do not say how FortiClient handles DNS outside the tunnel, so the capture is what establishes it.
DoLocal network: while connected, try to reach a device on the network the laptop sits on (the home router's admin page or a printer).
ExpectRecord what happens. With Enable Local LAN off it should not answer; Fortinet does not say so, so this test is what establishes it.
DoFrom outside the office, try Remote Desktop, file sharing or the FortiGate's admin page on the office's public address without the VPN.
ExpectRefused: no inbound policy allows them, so remote access goes only through the tunnel.
When the service is unreachable
ChangesA hosts-file entry stops the pilot laptop reaching Microsoft's sign-in service until it is removed.
BeforeKeep a copy of the hosts file.
DoOn a pilot laptop, block Microsoft's sign-in service with a hosts-file entry for login.microsoftonline.com, and connect.
AfterwardsRemove the entry, flush the DNS cache, and connect once more.
ExpectWhile blocked: the sign-in page does not load and no tunnel comes up, and FortiClient offers no other way in. This test, with the recovery test that lists the FortiGate's local users, is how you establish that there is no password-only path; the recipe has no vendor statement that says so. Afterwards: the laptop connects normally again.
Recovery
DoWrite down, in the remote access policy, what people do when Entra ID or the office internet link is down (wait, or work from the office) and test that nobody has a local VPN account with a password only as a back door: list the FortiGate's local users.
ExpectNo local user can bring up a remote access tunnel.
ChangesChanges the tunnel's pre-shared key, which every laptop holds: until the new key reaches a laptop, it cannot connect. Also removes the test user from the VPN group and ends the test user's tunnel.
BeforeUse a test user and a test laptop, not a real person's. Pick a time when nobody needs the VPN, have the new key ready to push to the other laptops from FortiClient EMS, and connect the test laptop so it has a live tunnel.
DoSimulate a lost laptop with the test laptop: remove the test user from the Entra group and revoke the test user's sessions; then end the test user's live tunnel on the FortiGate, because revoking sessions acts on Entra ID sign-ins and nothing on the pages read says it ends a tunnel that is already up (the Fortinet pages read for this recipe give no command or GUI step for ending one user's tunnel: not established, so find it in your FortiOS version's documentation); then change the tunnel's pre-shared key on the FortiGate and push the new key to the remaining laptops.
AfterwardsPush the new key to every remaining laptop and connect each (diagnose vpn ike gateway list shows them). Keep the test laptop out of use until it has the new key, and put the test user back in the group only if you keep it for later tests. Record the key change and the date.
ExpectAfter the tunnel is ended, diagnose vpn ike gateway list no longer shows the test user, and the test laptop cannot connect again (with the old key the negotiation fails; signed in, the test user is refused by Entra ID). The other laptops reconnect with the new key.
Evidence package: what to keep
Each record to keep once the recipe is in place: where it comes from in this recipe, what an assessor should see in it, the practices it supports, when to take it again and what it does not show. Written from the vendors' documentation: Expert CMMC has not run this configuration, and nothing here is a capture of a real system. A layout marked Illustration uses placeholder values.
The FortiGate configuration for the tunnel, the SAML server and the policies from the tunnel
ev-remote-access-configEvidence register: Remote access configuration
- Taken from
FortiGate configuration backup (the relevant sections) or screenshots of each page
- FortiOS version: FortiGate: the firmware version (get system status in the CLI)
- SAML server: FortiGate: User & Authentication > Single Sign-On > Create new
- ike-saml-server: FortiGate CLI: config system interface > edit <the interface the VPN traffic arrives on>
- Remote Gateway, IKE version, EAP: FortiGate: VPN > VPN Tunnels > Create New > Custom IPsec Tunnel
- IPv4 split tunnel: The same tunnel > Network
- Where the SAML user group is set: The tunnel's Phase 1 (authusrgrp) or the firewall policy (groups)
- Policy from the tunnel to the office network: FortiGate: Policy & Objects > Firewall Policy > Create New
- Log Allowed Traffic: Each policy from the tunnel > Logging Options (CLI: set logtraffic all)
- IPsec VPN connection: FortiClient > Remote Access > Add a new connection (or the same profile pushed by FortiClient EMS)
- Use External Browser as User-Agent: FortiClient EMS (FortiEndpoint): the Remote Access profile > the IPsec VPN tunnel, with Enable Single Sign On (SSO) for VPN Tunnel on
- Block IPv6: FortiClient EMS (FortiEndpoint): the Remote Access profile > IPsec VPN > Block IPv6
- Enable Local LAN: FortiClient EMS (FortiEndpoint): the Remote Access profile > the IPsec VPN tunnel > Phase 1 (the option after NAT Traversal) > Enable Local LAN
- Disable Default Route: FortiClient EMS (FortiEndpoint): the Remote Access profile > IPsec VPN > Disable Default Route
- Do Not Accept Invalid Server Certificate for SAML auth: FortiClient EMS (FortiEndpoint): the Remote Access profile > IPsec VPN > Do Not Accept Invalid Server Certificate for SAML auth
- It must show
- FortiOS version; IKE version 2 and EAP; Mode Config IPv4; Phase 1 and 2 proposals; Split tunnel disabled; The SAML server and user group; The policies from the tunnel: source group, destinations, services, logtraffic all; The FortiClient EMS profile: Block IPv6 on, Enable Local LAN off, Disable Default Route off, Do Not Accept Invalid Server Certificate for SAML auth on, and the FortiClient versions deployed.
- An assessor should see
- get system status: FortiOS 7.6.1 or later.
- The tunnel (VPN > VPN Tunnels): Remote Gateway Dialup User, IKE version 2, EAP enabled, Mode Config with the IPv4 client address range, and User group Inherit from policy.
- The tunnel's Network page: IPv4 split tunnel Disable, and the DNS server you specified.
- The SAML server (User & Authentication > Single Sign-On), the user group matched to the Entra group's Object Id, and ike-saml-server on the interface FortiClient's traffic arrives on.
- The policies from the tunnel: source the client range and the SAML user group (set in the firewall policy only), only the destinations and services remote users need, the second policy to the internet, and logtraffic all.
- The FortiClient EMS Remote Access profile: Block IPv6 On, Enable Local LAN Off, Disable Default Route Off, Do Not Accept Invalid Server Certificate for SAML auth On, Use External Browser as User-Agent On, and the FortiClient versions deployed (none on 7.4.4 or 7.4.5).
- Supports
- AC.L2-3.1.12 [b] [c]; AC.L2-3.1.14 [a] [b]; SC.L2-3.13.7 [a]
- Taken again
- After each change to the FortiGate or the EMS profile (with the configuration backup the lockout step takes first), after each FortiOS or FortiClient upgrade, and at each configuration review on the schedule you set.
- Does not show
- Where a connected laptop's traffic goes: the settings say split tunnel is off and IPv6 is blocked, and only the four bypass tests (IPv4, IPv6, DNS, local network) show what it still reaches directly. Nor Block IPv6 on a laptop without EMS, nor FIPS validation at either end (not established: Before you choose this example), nor session time limits, which this recipe leaves to you.
The tunnel's cryptographic settings
ev-boundary-encryptionEvidence register: Boundary encryption settings
- Taken from
FortiGate: the tunnel's Phase 1 and Phase 2 pages, and diagnose vpn ike gateway list for a live connection
- Encryption, authentication and Diffie-Hellman groups: FortiClient > the connection > Advanced Settings > Phase 1 IKE Proposal and Phase 2 IKE Proposal (or the same in the EMS profile); on the FortiGate, the same tunnel's Phase 1 and Phase 2 proposals. Fortinet's page gives the FortiClient values only: its FortiGate tunnel steps list no proposals, so the FortiGate-side path and values are not established by the page.
- Test, should pass: From a pilot laptop outside the office network, connect FortiClient and complete the…
- Test, should be refused: Connect with a FortiClient profile holding a wrong pre-shared key or different proposals.
- It must show
- Encryption and authentication proposals; Diffie-Hellman groups; The proposal a live connection uses.
- An assessor should see
- Phase 1: AES 256 with SHA 256, Diffie-Hellman groups 20 and 21. Phase 2: AES 256 with SHA 256, Diffie-Hellman group 20. The same in FortiClient (or the EMS profile) and on the FortiGate.
- diagnose vpn ike gateway list for a live connection, dated: the proposal in use (Fortinet's sample shows aes256-sha256).
- The refused test with a wrong pre-shared key or different proposals: the tunnel negotiation fails.
- Supports
- AC.L2-3.1.13 [a] [b]
- Taken again
- After each change to the proposals and after each FortiOS or FortiClient upgrade, with a new dated capture of a live connection.
- Does not show
- FIPS validation (SC.L2-3.13.11): the proposals name algorithms, not a validated module, and the module is not established for either end. Nor that the FortiGate-side path is right for your version: Fortinet's page gives the FortiClient values only.
The Conditional Access policy for the VPN application
ev-authentication-configEvidence register: Authentication configuration
- Taken from
Microsoft Entra admin center > Conditional Access > the policy (screenshot of each tab, or its JSON from the policy list)
- Grant: Require authentication strength: Entra admin center > Conditional Access > New policy (Users: All users, excluding the emergency access accounts; Target resources: the FortiGate IPsec VPN application)
- Test, should be refused: With the policy On, connect with a pilot account that has only a password, or only a…
- It must show
- State: On (not Report-only); Users included, and the emergency access accounts excluded; Target resource: FortiGate IPsec VPN; Grant: the authentication strength required; Date the state was set to On.
- An assessor should see
- Enable policy: On, not Report-only, and the date it was switched On (the pilot's last step).
- Users: All users, excluding the emergency access accounts. Target resources: FortiGate IPsec VPN.
- Grant: Require authentication strength, Phishing-resistant MFA, or Multifactor authentication for the users you recorded, with the decision and the date you will revisit it.
- The password-only test: refused by the authentication strength, with the Conditional Access tab (not Report-only) naming the policy.
- Supports
- IA.L2-3.5.3 [d]; AC.L2-3.1.12 [c]
- Taken again
- After each change to the policy, and on the revisit date you recorded for any user left on the Multifactor authentication strength.
- Does not show
- Multifactor authentication for privileged accounts or for local access (IA.L2-3.5.3 [a] to [c]), which this recipe does not set. Nor that the emergency access accounts are held to the strength: they are excluded from the policy.
Sign-in log entries for the VPN application, including the refused tests
ev-identity-signin-logsEvidence register: Sign-in and authentication logs
- Taken from
Entra admin center > Sign-in logs, filtered to FortiGate IPsec VPN
- Test, should pass: From a pilot laptop outside the office network, connect FortiClient and complete the…
- Test, should be refused: With the policy On, connect with an ordinary account that is not in the assigned group.
- Test, should be refused: With the policy On, connect with a pilot account that has only a password, or only a…
- It must show
- User; Date and time; Authentication method; Conditional Access result from the enforced policy (the Conditional Access tab, not Report-only); Failure reason for refused attempts.
- An assessor should see
- The passing test's entry for FortiGate IPsec VPN: the user, the authentication method used and the Conditional Access policy satisfied.
- The refused tests' entries: the failure reason, and for the password-only test the Conditional Access tab (not Report-only) naming the policy.
- The pilot's Report-only results for each pilot user, kept with the date the policy was switched On.
- Supports
- IA.L2-3.5.3 [d]; AC.L2-3.1.12 [d]
- Taken again
- Exported for each remote access review, at the frequency you set: the assessment guide asks of manual monitoring "does it occur at a frequency commensurate with the level of risk" (L2 guide p.50). The tests' entries each time the tests are run.
- Does not show
- Whether a tunnel came up or what it reached: the sign-in log records the Entra sign-in, not the tunnel (the FortiGate's traffic log and diagnose vpn ike gateway list do). Nor that anyone looked at it: keep the dated review.
Traffic logs of remote sessions
ev-remote-access-logsEvidence register: Remote access logs
- Taken from
FortiGate traffic logs (or the log store they are sent to), filtered to the tunnel interface
- Log Allowed Traffic: Each policy from the tunnel > Logging Options (CLI: set logtraffic all)
- Test, recovery: Simulate a lost laptop with the test laptop: remove the test user from the Entra group…
- It must show
- User; Source address in the tunnel range; Destination and service; Start time and duration.
- An assessor should see
- Traffic log entries on the tunnel interface: the user, a source address in the client range, the destination and service, the start time and duration.
- Each policy from the tunnel logging all sessions (Log Allowed Traffic: All Sessions), sent to where you keep audit records.
- The lost-laptop test: once the test user's tunnel is ended, diagnose vpn ike gateway list no longer shows the user.
- Supports
- AC.L2-3.1.12 [d]
- Taken again
- Reviewed at the frequency you set, with the date and what each review followed up: the assessment guide asks of manual monitoring "does it occur at a frequency commensurate with the level of risk" (L2 guide p.50).
- Does not show
- That anyone reviews them: an export shows sessions were recorded, not monitored; keep the dated review, or an alert that reached its owner. Nor traffic a laptop sends outside the tunnel, which the FortiGate never sees (the bypass tests).
The dated record of each test in Tests
ev-control-test-recordEvidence register: Control test record
- Taken from
Your test notes, one per test, each with the command output, screen or capture it refers to
- Test, a way around that should fail: IPv4: while connected, check the laptop's public IPv4 address (a what-is-my-IP site that…
- Test, a way around that should fail: IPv6: connect from a network that gives the laptop an IPv6 address, then open a site that…
- Test, a way around that should fail: DNS: while connected, check the DNS server listed for the tunnel adapter (ipconfig /all…
- Test, a way around that should fail: Local network: while connected, try to reach a device on the network the laptop sits on…
- Test, a way around that should fail: From outside, try the old SSL VPN address and port, and any web portal the FortiGate used…
- Test, a way around that should fail: From outside the office, try Remote Desktop, file sharing or the FortiGate's admin page…
- Test, should be refused: With the policy On, connect with a Global Administrator account that is not in the VPN…
- Test, when the service is unreachable: On a pilot laptop, block Microsoft's sign-in service with a hosts-file entry for…
- Test, recovery: Write down, in the remote access policy, what people do when Entra ID or the office…
- It must show
- Date and who ran it; The test, and the laptop, network and FortiClient version used; The result seen, and whether it is what the recipe expects; The output or capture that shows it (diagnose vpn ike gateway list, ipconfig /all or scutil --dns, the DNS capture); What was put back afterwards.
- An assessor should see
- IPv4: the public IPv4 address is the office's, and the default route is through the tunnel.
- IPv6: no IPv6 address reported, and the IPv6 test fails to connect.
- DNS: the tunnel adapter lists the DNS server the tunnel assigns, and a capture on the physical adapter, started after connecting, shows no DNS queries.
- Local network: what happened when the home router or a printer was tried, as seen (Fortinet does not say what to expect).
- From outside without the VPN: nothing answers on the old SSL VPN address, and Remote Desktop, file sharing and the FortiGate's admin page are refused.
- The Global Administrator outside the VPN group: no office address answers, with whether the tunnel came up and what diagnose vpn ike gateway list showed under groups.
- Microsoft's sign-in service blocked: no tunnel and no other way in, the hosts-file entry removed afterwards; the FortiGate's local users, none able to bring up a remote access tunnel.
- Supports
- SC.L2-3.13.7 [a]; AC.L2-3.1.14 [b]; AC.L2-3.1.12 [c]; IA.L2-3.5.3 [d]
- Taken again
- After each change to the tunnel or the EMS profile, after each FortiOS or FortiClient upgrade (Block IPv6 depends on the FortiClient version), and on the test schedule you set.
- Does not show
- Laptops, networks and FortiClient versions nobody tested: a network without IPv6 does not test Block IPv6. Nor what a laptop sends before the tunnel is up.
IllustrationA layout for this record with placeholder values in angle brackets. Not a capture of a real system. Date Test Laptop, network, FortiClient version Result seen As the recipe expects Kept <date> A way around: IPv4 <laptop>, <home network>, <version> Public IPv4 address is the office's; default route through the tunnel Yes <screenshot of the address check and the route table> <date> A way around: IPv6 <laptop>, <network with IPv6>, <version> No IPv6 address reported; the IPv6 test did not connect Yes <screenshot of the address check>
What this does not cover
Not covered by this recipe
- FIPS validation at either end of the tunnel, the FortiGate and FortiClient (SC.L2-3.13.11): not established for the versions this recipe needs; see Before you choose this example.
- Access to cloud services such as email and file storage, which Conditional Access governs rather than the VPN.
- Privileged commands over remote access (AC.L2-3.1.15) and remote maintenance by outside parties (MA.L2-3.7.5), beyond deciding who can connect.
- Phones and tablets, and computers outside the company.
- Older FortiOS with SSL VPN: not covered here; migrate as Fortinet's release notes say.
- Fortinet's guide uses a gallery application named for SSL VPN and says it should still work with IPsec; the pilot is the check.
Still yours (or your provider's)
- Deciding who may connect and to what, and keeping the group and the firewall destinations to that.
- Reviewing the remote access logs and following up what they show.
- Keeping FortiOS and FortiClient patched, and reading Fortinet's release notes before every upgrade.
- Keeping the pre-shared key secret and changing it when a laptop is lost.
- Session time limits and inactivity disconnects, which you set and record (AC.L2-3.1.11).
Cost and effort
- Licences
- The FortiGate and whatever Fortinet support contract you hold for it; FortiClient with EMS management on each laptop (which licence covers it is not established here: see Before you choose this example); Conditional Access per user in Entra ID (the catalog fact under Prerequisites).
- Hardware
- A FortiGate sized for your internet link and the number of people connecting at once. Nothing extra on the laptops.
- Setup
- Expert CMMC's estimate: one to two days for someone who has configured a FortiGate before, plus a pilot week.
- Upkeep
- Patch FortiOS and FortiClient, review the group and the logs, repeat the refused and bypass tests after any change, and change the pre-shared key when a laptop is lost.
No prices: they change and depend on what you already hold.
Vendor statements this rests on
The product catalog records this recipe cites, with the date each was checked. When one is reworded, the recipe is marked for review; when one is only re-checked and still says the same, the new date shows here.
- From FortiOS 7.6.3, SSL VPN tunnel mode is replaced by IPsec VPN (which can use TCP port 443) on every FortiGate model, and its settings are not carried over on upgrade. Source, checked November 11, 2026.
- Fortinet says to migrate SSL VPN tunnel mode to IPsec VPN before upgrading to FortiOS 7.6.3, to keep remote access working. Source, checked November 11, 2026.
- Microsoft's multifactor authentication licensing table marks Conditional Access for Entra ID P1 and P2 (not for the free tiers or Office 365), and risk-based Conditional Access for P2 only. Source, checked November 11, 2026.
Expert CMMC's editorial guidance, not official text and not an endorsement of any product. Vendors change their products and pages; confirm each setting on the vendor's current page.