Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
New Contributor

Issue: RADIUS authentication forwarding UDP-packets (1645, 1646, 1812, 1813) to NPS server

Server: Windows 2016 Standard with NPS installed and configured Hardware: Fortigate 60D with FortiOS 6.0.4 (LAN IP: Scenario: Switched to a Fortigate 60D from an old DrayTek 2120 router. After the change, RADIUS authentication doesn’t work externally, but works fine on the local network. RADIUS is used to connect to a service called eduroam to get WiFi access on campuses etc and authenticate users on the local AD.


IPv4 Policies has been created and I am able to see traffic passing through the policy and receive data to the NPS server. When a user tries to connect, following error messages appear on the NPS server:


Configuration 1: Fortigate forwards UDP traffic and generates the following error on the NPS server:

Error: “A RADIUS message was received from the invalid RADIUS client IP address”

I don’t know why the Fortigate is regarded as a RADIUS client.


Configuration 2: Fortigate forwards UDP traffic and is configured as a RADIUS client with a shared secret on the NPS server. Following error is generated: “An Access-Request message was received from RADIUS client with a Message-Authenticator attribute that is not valid.”

Seems to me like a mismatch of the shared secret. I haven’t found anywhere where I can enter the shared secret on the Fortigate, except on User & Device \ RADIUS Servers. Afaik, RADIUS Servers section on the device are not used for this scenario.


What am I missing here? Are the UDP packets manipulated on the Fortigate device before being passed on to the NPS server? I’m out of ideas. Any advice is greatly appreciated!


Kind regards,




Contributor III
Esteemed Contributor III

The FGT is always acting as a RADIUS client, it does not have the functionality to serve as a RADIUS server (alas). As it is forwarding a client's request to the NPS, it's acting as a client (kind of proxy, if you like).

As clients have to be authorized, you specify the username and password for RADIUS access in the 'RADIUS server' setup.

Jirka's link really shows all that there is to this.


"Kernel panic: Aiee, killing interrupt handler!"

Thank you for your help. The solution was very simple: turn off NAT.