Fix default NPS firewall rules for Server 2019
Hi all,
I understand there is an issue with Windows Server 2019/Windows 10 1809 however I was wondering if Microsoft are aware of any problems regarding the Firewall rather than the systems handling of user files.
Recently I setup a Server 2019 VM (1.5GB Dynamic RAM, 2 Allocated Cores, 36GB Drive space, 3GB NIC Team) and installed the NPS and RDS Gateway role onto it however I noticed that despite the NPS role adding the standard firewall rules for port 1813 and 1812 they do not seem to be working.
I have confirmed that with an exception allowing port 1812 through or disabling the firewall allows authentication requests to reach the NPS server however when these are removed and the default rules are left they are blocked.
I have performed an SFC scan and DISM scan/repair however no issues have been detected
I have also spun up a new Server 2019 and Server 2016 server to compare and the 2019 server has the same issue whilst the 2016 server has no problems with just the default rules and no exceptions/extra.
If anyone has any suggestions or information I would be extremely great-full as currently I'm not sure what seems to be the cause
Daniel Hoult
shared this idea
22 comments
-
Dimarc67
commented
Encountered same issue. Windows Defender Firewall on WinSrv2019 blocked RADIUS auth and acct ports UDP/1812-1813 despite the Inbound rules being enabled (default).
Resolved this by changing the Edge Traversal setting for existing Network Policy Server rule from "Block edge traversal" (default) to "Allow edge traversal". (In my case, the traffic is coming from a different subnet, so "edge traversal" could be in play.)
RADIUS authentication now successful.
-
Chris Alton
commented
Hi All,
EDIT: I confused NPS with NAP in this statement, sorry about the confusion.
I just had a customer hit this same issue and found that this a known issue. Unfortunately, since NPS is deprecated there will not be a fix coming out for it.
There is a way to fix it on any systems that do have this problem.
The root cause was a Service SID associated with the IAS service didn't allow the Firewall Service to target the IAS service. This prevented the rules from properly taking effect.
All you need to do is run the following command on the affected systems:
sc sidtype IAS unrestricted
Sorry about the long delay getting a reply on this.
Thanks,
Chris
-
Cory
commented
Ran into this issue on 8/3/2019. The built-in Server 2019 NPS firewall rules do not work. Added my own custom UDP port 1812, 1813, 1645, 1646 rules and it works.
-
Yoan Schinck
commented
Just encountered this issue today, and wasted a good hour on it before coming across various posts online describing it. Can't believe that a "User Voice" suggestion is needed to fix a known bug...
-
Paul Reynolds
commented
Why hasn't this issue been patched yet? Come on Microsoft Summer 2019 is less then 2 weeks away here in the UK...
-
Davit Kandleki
commented
Recently upgraded 2 servers from Windows Server 2016 to 2019. Both have this issue till this date.
-
Anonymous
commented
Still confirmed to be an issue 19th of June 2019
-
Anonymous
commented
Wasted a ton of time on this, sure wish it was fixed or better advertised...
-
Dan Jansson
commented
In older versions of Windows, the default RADIUS rules are not bound to any services. In Windows Server 2019, they are bound to svchost.exe when they should rather be bound to iashost.exe.
-
Daniel Hoult
commented
6 months on and we still have no resolution of even a clear acknowledgement of this issue. It's a shame as overall Server 2019 has some great features that are being masked by silly bugs like this
-
J
commented
Wasted a stack of time on this also
-
William
commented
Definitely a bug with Windows Server 2019. I upgraded a Windows Server 2016 server hosting the NPS role which worked perfectly fine pre-upgrade. After the upgrade completed, NPS stopped processing authentication requests.
I checked the NPS event log and noticed a conspicuous lack of entries for connection attempts. After confirming the service was running, I tried turning the Windows Firewall off and watched it spring to life. I turned it back on and noticed it stopped. After checking the rules, I discovered the default rules exist but they didn't appear to be working. After turning on failure logging, you can clearly see the Windows Firewall dropping the packets on port 1812 from the RADIUS clients, despite the rule existing to allow it.
As others have said, creating a manual rule to allow port 1812 fixes the problem but it shouldn't be necessary.
The rule appears to have been created properly as it is bound to the service host and configured to allow traffic for the IAS Windows service, but for some reason, it's not working.
-
Martin Desmeules
commented
Just create my two rules for UDP 1812 and 1813 and start working perfectly!
Thank's a lot guys!!! -
Rob Hardman commented
Reproduced this issue from a clean build that was then fully patched. Wasted hours scratching my head until I saw this post. :\
-
Anonymous
commented
I actually discovered it was a firewall issue quite by accident. For me, it started as a network profile issue. So you might also want to review my thread about NLA and Radius at https://social.technet.microsoft.com/Forums/windowsserver/en-US/c2c51003-7763-4207-9250-17712c4fbc49/network-location-awareness-amp-radius?forum=ws2019
-
Will McEnaney
commented
Windows Firewall logs the traffic as allowed but the packets do not reach the RADIUS server - presumably they are just getting dropped by accident?
Quite concerning -
Anonymous
commented
Microsoft... why must you waste our time, get your act together...
-
Anonymous
commented
I did also experience this bug.... Lot of time wasted for a little thing; please fix this.
Make sure to open port 1812 & 1813
-
Brandon Penglase
commented
I just ran into this myself after spinning up 2019 on a new server, which served as one of our NPS Servers. Same as others, if I add UDP 1812/1813 as it's own rule, it works as expected. Latest media downloaded from VLSC, fully up to date.
-
Joel Linn
commented
This is absolutely ridiculous.
You would think there is some kind of automated testing setting up a NPS server and client and do some valid/invalid authentications.