I’m setting up a Fortigate remote access VPN(IPSec) using Microsoft Network Policy Server(NPS RADIUS) and MFA.
The VPN is properly configured and Forticlient(free) connects witout issue when using Fortigate local user accounts.
NPS and RADIUS seem to be properly configured. Performing a user login test from the Fortigate GUI or with the CLI diag test authserv radius "FG RADIUS Server" pap [email protected] mYpAsSwOrD succeeds. It succeeds with MFA enabled and with MFA disabled. Perfect.
But Forticlient(free) using the NPS credentials refuses to connect! It sometimes says “Wrong Credentials”, but most times it just silently fails and shuts down.
Debugging on the Fortigate with diagnose debug application fnbamd 255 shows
fnbamd_auth_handle_radius_result-->Result for radius svr 'FG RADIUS Server' 192.168.1.99(1) is 0
indicating successful authentication even though the FortiClient fails.
Any help is greatly appreciated.
Edit: It turns out that the Fortigate was not sending the NAS-IP, but only when authenticating from the FortiClient. It did send NAS-IP when authenticating from the Fortigate CLI. The solution was to enable “Include in every user group” under RADIUS user config.
config user radius
edit "FG RADIUS Server"
set server "192.168.1.99"
set secret shhhhhhhhhhh
set timeout 60
set all-usergroup enable
set nas-ip 192.168.1.1
set auth-type pap
next
end
That looks like the default ip for admin access when you first start a new fortigate.
Is that ip set as your radius or do you try to connect with it to the radius?
On cli you can set a source interface and a source ip for radius traffic. Maybe there is the issue.
Default is set to automatic and fortigate uses whatever interface with the configured ip of the interface as a source.
You’ve already resolved it, but here’s one unsolicited piece of advice:
set all-usergroup enable
Remove this, and never use it again. This options makes this RADIUS server a member of ALL configured groups on the FortiGate, even non-RADIUS ones. Nobody needs this, ever. (it’s just a weird debug option, mostly)
I would start looking at event viewer of the NPS server.
Event viewer → Custom Views → Server Roles → Network Policy And Access Services
If there are no logs being generated there at the time you try to login, then there might be problem with the radisu communication between fortigate and NPS. You could set up wireshark on the NPS server and capture the traffic from the fortigate to verify if you are receiving the radius messages
Oh, I thought the main problem was fixed with the nas-ip option? Did I misread that?
By the way, NPS doesn’t by default require a NAS-IP attribute to be present in requests. I assume you set that up as an additional restriction in the CRP or NP?
Ok. I did it with Duo for L2TP using ISE and had issue group not properly propogating and even though I was getting success prompt on Duo yet my connection was disconnecting and the reason was thar I was not using the radius attribute in ISE policy correctly.
The problem exists until I add set all-usergroup enable.
When enabled, everything works.
When disabled, I can successfully perform diag test authserv..., but login from Forticlient fails after MFA approval. The connection is never established.
I recall having issues with “include in every user group”. The radius server was checked for all authentication requests. If you have multiple radius servers with different policies, you might end up with users being in a different group than expected
set all-usergroup enable implicitly adds this RADIUS server into all user groups on the FortiGate, even non-RADIUS groups (local, LDAP, etc.). It’s a very weird config option, which honestly shouldn’t be used outside testing scenarios, or some weird disaster-recovery edge-cases.
The option “solving anything” could be pointing to many potential issues, starting from misconfiguration related to the group name strings (sent in wrong attribute, sending wrong content, etc.).
