question

Ben-5881 avatar image
0 Votes"
Ben-5881 asked ScottPendleton-4699 answered

Problem with fragmentation? NPS won't authenticate clients

Hi all I have the following setup

2x RRAS servers running Windows Server 2019 Using EAP-TLS for SSTP and IKEv2 authentication
1x NPS Server ( Server 2016) on prem for the RADIUS authentication (working)
1x NPS Server (Server 2016) in Azure for backup RADIUS authentications (broken)

I am trying to create a backup NPS server in Azure (we have a VPN connection to Azure) but im having problems with the authentication.

The client's connection times out and I get the following error in the client's event viewer:
CoId={E4FD7873-208A-0000-4B26-00E58A20D701}: The user SYSTEM dialed a connection named Always On VPN - User which has failed. The error code returned on failure is 812.

On the RRAS side I get the following: }:

The user user@company.com connected from 1.2.3.4 but failed an authentication attempt due to the following reason: The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error. and CoId={E4FD7873-208A-0002-CA27-FFE48A20D701}: The following error occurred in the Point to Point Protocol module on port: VPN1-499, UserName: user@company.com. The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

Both NPS servers have identical configuration but on prem one works and Azure doesn't.

I ran wireshark on the broekn NPS server and saw a lot of fragmentation:

81153-broken-radius.png

A capture on the working server shows no fragmentation, and then I see the "Access-Accept" and the client gets connected:

81201-working-radius.png

I never see "Access-Accept" on the broken server.

I tried adjusting the MTU on the NPS server and using the "Framed-MTU" setting inside the NPS network policy set to 1344 but neither helped.

Does anyone have any ideas?

I read online that EAP-TLS doens't work properly with fragmentation and this is really the only clue of the solution I have...


azure-virtual-machineswindows-server-2016
broken-radius.png (67.7 KiB)
working-radius.png (41.1 KiB)
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Ben-5881 avatar image
0 Votes"
Ben-5881 answered

I looked through the packet captures again and found that the Framed MTU was still coming through as 1500 not 1344, so either I dont understand that setting or it doesnt work properly,

I changed the MTU on the network card that connects to the NPS server and it fixed the issue:

netsh interface ipv4 set subinterface "Ethernet 3" mtu=1400 store=persistent

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SunnyQi-MSFT avatar image
0 Votes"
SunnyQi-MSFT answered

Thank you very much for your posting here and sharing the resolution in the forum as it would be helpful to anyone who encounters similar issues.

If there is anything else we can do for you, please feel free to post in the forum.

Best Regards,
Sunny

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

ScottPendleton-4699 avatar image
0 Votes"
ScottPendleton-4699 answered

Its not the fragmentation so to speak but rather that Azure purposefully won't reassemble out of order fragmented packets. The answer from Microsoft is that they do this to prevent denial of service by an attacker that floods the endpoint with out of order packet fragments. TCP would recover, but UDP doesn't have that capability so the whole packet would get dropped by Azure before it reaches the service. We have noticed this on other RADIUS systems. It is however a general UDP issue with Azure. Setting the MTU is not always an option if you are using a 3rd party RADIUS server. One solution, if the RADIUS Server supports it, is to use RADSec which encapsulates inside a TLS tunnel. TLS will recover from a dropped packet.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.