How can we improve the networking platform and management in Windows Server?

← Networking

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

100 votes
Sign in
(thinking…)
Sign in with: Facebook Google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Daniel Hoult shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

29 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Tony Pombo commented  ·   ·  Flag as inappropriate

    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.

    Undo actions:
    1) sc.exe sidtype IAS none
    2) Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service ias

  • Anonymous commented  ·   ·  Flag as inappropriate

    I tried

    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  ·   ·  Flag as inappropriate

    February 2020 and it's still an issue. So thankful that I found this forum. This fixed our RADIUS woes.

  • Jon D Rodder commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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?

  • Ismaël commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    Oh the hours I have wasted on this little bug... please fix it MS. Thanks to Chris Alton for the solution.

  • Dimarc67 commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    Why hasn't this issue been patched yet? Come on Microsoft Summer 2019 is less then 2 weeks away here in the UK...

  • Dan Jansson commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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

  • William commented  ·   ·  Flag as inappropriate

    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.

← Previous 1

Networking: Firewall

Categories

Feedback and Knowledge Base

(thinking…)