Troubleshooting

Multi-Factor Authentication (MFA) is not working as I expect

In addition to the client side supplicant limitations, the Microsoft Entra ID integration also has its own limitations when used with RADIUS that you should consult.

Changes have not taken effect

Usually changes are picked up instantly upon the change being made but in the event of a temporary error, the service checks for any missed changes every fifteen (15) minutes.

RADNAC uses an old Shared Secret for Devices

RADNAC uses a cache for RADIUS over UDP and TCP that remains valid for ten (10) seconds after a configuration reload has been picked up.

For RadSec using PSK no caching is used and changes are immediately applied upon a configuration reload.

My device authentications are being treated as network access requests

RADNAC considers the request to be for network connectivity (eg. wireless network access) where the value of the Service-Type attribute is set to Framed-User (or when not present) in the RADIUS Access-Request whilst any other value is considered a device (eg. managed switch) request.

Unreliable EAP-TLS Authentications

Azure is unreliable for EAP-TLS authentications when using RADIUS over UDP due to it dropping out-of-order IP fragments, and as such the only practical solution, and strongly recommended, is to use RadSec where possible (or TCP where not) to avoid this issue completely.

For those interested in the why, this occurs as there is no provision in EAP to control the size of messages sent from the ‘supplicant’ (client, such as Microsoft Windows, macOS, …) to the authenticator (server, where RADNAC fits in this picture). The issue is EAP-TLS requires the client to send large messages to the server which leads to IP packet fragmentation due to the transition from EAPOL-over-Ethernet to EAP-over-RADIUS. These packets tend to arrive out of order when traversing the Internet as routers will send the first packet down one link and the subsequent down potentially different links (as there is no Layer 4 tuple to pin to). This is not a problem for EAP-TTLS as the server does not deal with EAPOL and can administratively set the message size to a lower value (at the cost of more round trips and a slower authentication); also helping here the an unofficial standard where the RADIUS client includes a Framed-MTU attribute to suggest dynamically to server a maximum EAP-Message size it knows will work locally to avoid the issue though only for messages flowing in the direction from the server to the client.

This is made worse if you use an Azure VPN Gateway as it further lowers the MTU of the connection which increases fragmentation.

It is rumoured you may open a ticket with Azure to attempt to resolve this though it comes with a long list of caveats. Currently RADNAC does not support being installed to an existing VNet though if you require this do get in touch and we will should be able to work something out.