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
Daniel Hoult
shared this idea
18 comments
-
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.
-
Anonymous
commented
Still confirmed to be an issue 19th of June 2019
-
Anonymous
commented
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
-
J
commented
Wasted a stack of time on this also
-
William
commented
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.
-
Martin Desmeules
commented
Just create my two rules for UDP 1812 and 1813 and start working perfectly!
Thank's a lot guys!!! -
Rob Hardman commented
Reproduced this issue from a clean build that was then fully patched. Wasted hours scratching my head until I saw this post. :\
-
Anonymous
commented
I actually discovered it was a firewall issue quite by accident. For me, it started as a network profile issue. So you might also want to review my thread about NLA and Radius at https://social.technet.microsoft.com/Forums/windowsserver/en-US/c2c51003-7763-4207-9250-17712c4fbc49/network-location-awareness-amp-radius?forum=ws2019
-
Will McEnaney
commented
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
Microsoft... why must you waste our time, get your act together...
-
Anonymous
commented
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
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
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
I had the same trouble, after disabling the firewall on DC, all clients where able to connect.
-
Don Pachniak
commented
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.