FortiGate VPN MFA: Local Token, RADIUS or SAML?

Every FortiGate VPN MFA design answers one question first: who verifies the second factor? The gateway itself can do it with a local token or an emailed code, a RADIUS backend can enforce it and hand back a challenge, or a SAML identity provider can own the whole ceremony in a browser. Each of those produces a different login sequence, a different failure signature and a different recovery procedure, and copying a command block between them produces a configuration that looks plausible and authenticates nobody. This is a mechanism article: what each design actually does during a login, and where it breaks.

The login ceremony decides who owns the factor

In the first two designs, the FortiGate is the relying party. It collects the credential, decides whether a second factor is required, and verifies it locally or by prompting through a challenge. In the third design the gateway stops being the verifier and becomes a relay: it redirects the client to the identity provider, receives an assertion, and maps the asserted identity to a user and group. In the RADIUS design it is in between, driving a request-response exchange with a backend that holds the policy.

That difference decides what evidence you can collect. When the gateway verifies, its own debug output tells you what happened. When an identity provider verifies, the gateway only knows that an assertion arrived, and the answer to "was MFA actually required" lives in the provider's logs, not in the firewall's. Reading the wrong log is the most common way to misdiagnose a rollout that is behaving exactly as designed. The service itself bounds the ceremony as well: FortiOS 7.6.3 removes SSL VPN tunnel mode in favour of IPsec, while web mode continues as Agentless VPN on supported models, so a ceremony proven on one service is not automatically available on another.

Local verification: tokens and emailed codes

FortiGate-managed factors attach to the user object. A FortiToken or a documented token integration needs enrollment, the supported verification ceremony, licensing where it applies, and a replacement procedure. An emailed code needs a working SMTP path and a mailbox the user can reach before the tunnel exists, which is a dependency that has nothing to do with cryptography and everything to do with whether anyone can log in.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

Email delivery is part of authentication availability. A mailbox reachable only through the VPN creates a loop that resolves itself for nobody, and delivery delay, code validity and the remote authentication timeout are three separate constraints. Raising one does not repair an unreachable mailbox, and a design that has never tested the loop will discover it during the first password reset after a holiday.

Assurance requirements belong here too, before the product choice. NIST SP 800-63B treats email as unacceptable for out-of-band authentication, so a deployment claiming conformance cannot use an emailed code as its second factor no matter how convenient it is. A feature existing on the appliance is not a statement that the feature satisfies a given standard.

RADIUS: the gateway asks, the backend decides

With RADIUS, the FortiGate sends the credential to a backend that owns the factor policy. The exchange may be a plain accept or reject, or it may involve a challenge the client has to answer, which means the VPN service and the client both have to support that challenge shape. A backend that enforces a push approval and a client that only knows how to append a six-digit code to a password will not meet in the middle.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Test the backend independently before blaming the tunnel. If the authserver test succeeds and a VPN login does not, the difference is in the challenge handling rather than in the credential, and the gateway's authentication daemon debug is where that shows up:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: the browser leaves the gateway

In a SAML design the client is redirected to the identity provider, authenticates there, and returns with an assertion the gateway validates against a trust relationship and a group mapping. The gateway never sees the password or the second factor, which is a security improvement and an operational complication at the same time: the failure now happens in a browser session the firewall cannot inspect.

Accepting an assertion does not prove the provider required MFA for that sign-in. A provider policy that applies MFA to some applications and not others will produce exactly the login you asked for and none of the assurance you assumed. Check the provider's policy for this specific application, and check that the group claims mapping to FortiGate groups still match after any rename on either side.

Client support matters here more than anywhere else. Some VPN clients handle the browser hand-off natively, some open the system browser, and headless or command-line clients may not complete the flow at all. Test with the client the users actually run, on the platforms they actually use, before you publish the profile.

Recovery is part of the mechanism

Every design above has a dependency that can fail for one user at a time: an unreachable mailbox, a lost token, a backend that rejects a challenge, an identity provider account that is locked. Decide now who can restore access, through which supported procedure, and with what verification of the person asking. An emergency local administrator account kept separate from the VPN path is a control; an unexplained password-only bypass is an incident waiting to be discovered.

Then test three logins before rollout: the normal one, a rejected or expired factor, and the approved lost-authenticator recovery. Record which log each one appears in. That record is what turns "MFA is enabled" into a design someone else can operate.