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

123 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 →

32 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
  • 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.

  • Rob Hardman commented  ·   ·  Flag as inappropriate

    Reproduced this issue from a clean build that was then fully patched. Wasted hours scratching my head until I saw this post. :\

  • Will McEnaney commented  ·   ·  Flag as inappropriate

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

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

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

    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.

  • James commented  ·   ·  Flag as inappropriate

    I had the same trouble, after disabling the firewall on DC, all clients where able to connect.

  • Don Pachniak commented  ·   ·  Flag as inappropriate

    Thought you'd like to know I experienced the same issue.
    I created a new rule that allowed port 1812 and NPS began working.
    Disable the rule, NPS stopped responding to authentication.
    Enable the rule and NPS resumed responding.

    Something is definitely wrong with the default firewall rule.
    In comparing it to the one I created, the only difference I see is that the default rule is tied to the NPS service.

2 Next →

Networking: Firewall

Categories

Feedback and Knowledge Base

(thinking…)