locked
Windows Server 2019 - Default NPS Firewall rules (Port 1812 UDP) Not working RRS feed

  • Question

  • 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

    Sunday, October 14, 2018 8:37 PM

Answers

  • Hi All,

    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


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, August 20, 2019 4:45 PM

All replies

  • Definitely would be worth mentioning over here on uservoice.

    https://windowsserver.uservoice.com/forums/295059-networking

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Sunday, October 14, 2018 9:24 PM
    Owner
  • Definitely would be worth mentioning over here on uservoice.

    Done, hopefully they should let us know if this is a bug or something else 
    Monday, October 15, 2018 6:30 PM
  • I voted up your post on uservoice.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Monday, October 15, 2018 6:34 PM
    Owner
  • Thank you, hopefully they will fix it ready for 2019's re-release :)
    Saturday, October 20, 2018 7:53 PM
  • Hi,

    unfortunatly they did not fix it. I just stumbled across this bug while updating one our RADIUS servers from 2016 to 2019. :(

    I opened a support case, maybe that helps.

    Regards

    Norbert

    Tuesday, November 20, 2018 9:29 PM
  • I am having the same trouble with NPS after test upgrade to 2019

    clients are not able to authenticate 

    Wednesday, December 5, 2018 1:06 PM
  • strange, after disabling DC firewall, clients where able to connect.

    So, something to do with the firewall and NPS

    Wednesday, December 5, 2018 1:15 PM
  • strange, after disabling DC firewall, clients where able to connect.

    So, something to do with the firewall and NPS

    Maybe you can capture it.

     

     

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Wednesday, December 5, 2018 3:13 PM
    Owner
  • strange, after disabling DC firewall, clients where able to connect.

    So, something to do with the firewall and NPS

    Well, thats what stated in the opening post. ;)

    "I have confirmed that with an exception allowing port 1812 through or disabling the firewall".

    I too have disabled the firewall (although I'd like to turn it on as soon as a permanent solution is available). Opening Port udp 1812 did not work for me though. I opened a support case, but have not been able to provide the requested network traces because I'm lacking the time right now.

    I'm hoping that maybe december's CU will fix this.

    Regards

    Norbert

    Wednesday, December 5, 2018 11:40 PM
  • Hi Dave,

    I can see requests to port 1813 (udp) being droped.

    2018-12-06 00:51:09 DROP UDP 10.101.8.7 10.101.10.13 1646 1813 266 - - - - - - - RECEIVE

    10.101.8.7 being a random RADIUS client (in this case a Cisco switch) and 10.101.10.13 being my 2019 NPS server. After configuring a static port rule for udp 1813 and 1812 I'm able to login. If I disable my rule and try just the default rules for the NPS login fails again. I can live with that, but surely this isn't what I would expect from a new server build with NPS not being touched for years I'D say. :|

    Regards

    Norbert

    Thursday, December 6, 2018 12:20 AM
  • Hi Dave,

    I can see requests to port 1813 (udp) being droped.

    2018-12-06 00:51:09 DROP UDP 10.101.8.7 10.101.10.13 1646 1813 266 - - - - - - - RECEIVE

    10.101.8.7 being a random RADIUS client (in this case a Cisco switch) and 10.101.10.13 being my 2019 NPS server. After configuring a static port rule for udp 1813 and 1812 I'm able to login. If I disable my rule and try just the default rules for the NPS login fails again. I can live with that, but surely this isn't what I would expect from a new server build with NPS not being touched for years I'D say. :|

    Regards

    Norbert

    Sounds like you have confirmed they lied about default ports being open. Maybe you can add this info to your open ticket.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Thursday, December 6, 2018 12:54 AM
    Owner
  • Hi Dave,

    already did this. We'll see if it helps.

    Regards

    Norbert

    Thursday, December 6, 2018 10:23 PM
  • HI,

    I have the same problem with my WiFi Radius Authentication

    I create a rule for 1812 UDP and is working for me.

    Thursday, December 20, 2018 9:20 AM
  • I have exactly the same issue, the default firewall rules allow UDP 1812, UDP 1813, UDP 1645 and UDP 1646 through the firewall for process, %systemroot%\system32\svchost.exe.

    With this default rule enabled the NPS server (RADIUS) is not reachable from a RADIUS client.

    When I enable (as a workaround) a specific inbound rule on Windows 2019 where the UDP ports above are allowed for any process,user, etc.  the NPS server is reachable.

    So there is definitely somewhere not completely working correctly with the Windows 2019 when role NPS is installed and default firewall rules are in place.


    Tuesday, January 1, 2019 1:27 PM
  • thanks. confirming that a custom rule for port 1812 udp fixes wifi radius auth.

    disabling the firewall did not help.

    the entire situation is very strange, because in wireshark i could see the packets coming in.... yet unless the custom rule was in place, radius auth did not work.

    Wednesday, January 16, 2019 11:03 AM
  • I too just dealt with this problem.  Couldn't figure out why NPS RADIUS wasn't working for the clients after migrating from a 2008R2 server.  Once I manually added the default ports to the inbound side, everything started working.  The default rules definitely do not work.
    Wednesday, January 16, 2019 9:47 PM
  • Even with a fresh build the problem is still there if you don't create a rule it wont authenticate :( MS should fix this..
    Tuesday, January 29, 2019 9:46 AM
  • I can confirm I have the exact same problem.   Just created a new firewall rule for ports 1812 and 1813 UDP and all is good.   The default ports that say are enabled are obviously NOT enabled.   Nice confidence in the firewall...


    • Proposed as answer by KH987 Wednesday, April 17, 2019 9:13 PM
    Friday, February 8, 2019 4:14 AM
  • Confirmed this here as well.

    This bug has been public knowledge for 4 months, what a joke server 2019 is turning out to be.

    Wednesday, February 13, 2019 10:06 AM
  • Just to add that I also reproduced this issue from a clean build. Indeed, what a joke. :\
    Thursday, March 21, 2019 4:14 PM
  • For the record everyone, it's been nearly 6 months since Server 2019 was released and we still have no fix

    Saturday, May 18, 2019 10:49 AM
  • Yeah confirmed it today on my environment too.  Glad this thread exists otherwise I'd have been scratching my head for ages nutting out a work around.
    Wednesday, May 22, 2019 6:45 AM
  • Hello,

    I can also confirm that NPS does not create a default firewall rule that works for RADIUS.  I created an inbound port rule for for the default RADIUS ports (1812, 1813, 1645, 1646) and everything is working as expected.  I do not know if this is a bug or a security enhancement.  Could be a new requirement to manually configure the access - could be a bug.

    Thursday, June 6, 2019 2:31 PM
  • Confirming this is still an issue.  I probably wasted the best part of a day trying to figure out why my newly built NPS server on Server 2019 couldnt communicate with RADIUS clients.  After manually creating the firewall rules its working OK
    • Edited by dpfnz Wednesday, July 31, 2019 12:32 AM
    Wednesday, July 31, 2019 12:32 AM
  • I just had the exact same problem on Server 2019.

    Spent a long time trying to find out why NPS did not produce any logs, finally captured the traffic with wireshark and saw that there were no replies. With a manual firewall rule it works.


    • Edited by mrfrenzy Friday, August 2, 2019 1:11 PM
    Friday, August 2, 2019 1:11 PM
  • I had the same problem and the problem seems to be isolated to when you specify a service on a rule (on the programs and services tab). If IAS is selected the rule doesn't work and if you allow any service (but still have specified the program) it works.

    So in this case it looks like the windows firewall rule matching functionality is buggy in regards to IAS - but there is a risk that it might affect other firewall rules if they use the services.

    Thursday, August 8, 2019 11:35 AM
  • Hi All,

    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


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, August 20, 2019 4:45 PM