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
This command: Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any
Totally fixed my issue
I've found the fix, delete the NPS rules created by Windows and recreate your own with required ports (1812 and 1813 or 1645 and 1646 )
Daniel Hoult commented
@Steve Sadly this has not been acknowledged by MS and even though we have passed the two year aniversary of this suggestion no efforts appear to have been made (As of yet) to resolve it. My only hope is that it is fixed in the next feature release of Windows Server
Issue with the October release of Windows Server 2019. Is this acknowledged by MS?
Talia Dias commented
Well this was very annoying, and apparently has been annoying people for a while. I just added UDP 1812 Allowed and it fixed it in my situation.
Daniel Hoult commented
I'd just like to provide a little update as this bug still hasn't been fixed, hopefully the next feature release of Windows Server will fix it
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...