Fix default NPS firewall rules for Server 2019
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
Michael Joseph commented
OMG - Can't believe this. Thanks for wasting my time Microsoft
J. Shields commented
Ugh, lost 3 precious hours today, thanks to this bug!
Thanks Microsoft for wasting my time on this too
Tony Pombo commented
I found two ways to fix this:
1) Grant the IAS service a higher "security clearance", so that the default rules will match:
sc.exe sidtype IAS unrestricted
2) Modify the built-in firewall rules to work:
Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any
Once done, the rules will more closely match the Windows Server 2016 rules.
I don't know the ramifications of changing security settings on the IAS service, so I recommend simply updating the rules.
1) sc.exe sidtype IAS none
2) Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service ias
Allowing edge traversal
Manually adding allow rules for for UDP 1645-1646 on all profiles
sc sidtype IAS unrestricted
Had to resort to allowing all traffic on the Domain profile
Very weird issue, its like its doesn't want to process rules for RADIUS
Ryan F commented
February 2020 and it's still an issue. So thankful that I found this forum. This fixed our RADIUS woes.
Jon D Rodder commented
Just had same issue. "sc sidtype IAS unrestricted" from administrator cmd window, then stop and restart IAS. The firewall rule didn't kick in for me until I bounced the IAS/NPS service.
Robert Larson commented
October 30, 2019 and this issue still exists. I too wasted many (MANY) hours trying to solve this before I finally just had the bright idea of turning the Windows firewall off. Voila, fixed. Then I turned it on, made my 1812,1813 rule and all was well.
I tried the "sc sidtype IAS unrestricted" fix mentioned below and I can report that that command didn't fix things for me. Anyone have a more permanent fix? Is Microsoft going to patch this?
What's really weird also is that I deployed 5 NPS servers for this project globally. It worked fine on two of them. And failed on 2 of them. The fifth one hasn't been tested just yet. So it works 50% of the time? That's really strange. All were identical clean builds of Windows 2019. The only major difference is that on the sites that work the hypervisor used is Hyper-V and where it doesn't work it was ESXi. But I can't imagine that has anything to do with this problem. Could it?
Adding 1645-1646; 1812-1813 as udp port in my firewall rule and it worked perfectly. I hope Microsoft will solve this issue
Rob Hardman commented
Oh the hours I have wasted on this little bug... please fix it MS. Thanks to Chris Alton for the solution.
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
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.
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.
Still confirmed to be an issue 19th of June 2019
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