Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 40 subscribers
  • Views 10315 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Authentication with Radius blocked by server 2019 firewall

Sergio Renes

Hello, 

So I performed an in place upgrade on one of our domain controllers from 2012 to 2019, so that I don't have to worry about demoting and promoting blah blah blah. Before I upgraded the second DC I wanted to make sure our users can still authenticate when they VPN in using ipsec. So I removed the 2012 server from the authentication list in the XG firewall and noticed they won't authenticate. I RDPd in to both DCs to compare the Network Policy and it's pretty much identical. So I contacted support and they had me disable the server firewall and it worked. We then compared the rules and noticed they were the same on both 2012 and 2019, both allowing port 1812 to pass, but it works on 2012 and not on 2019. Has anyone else had the same issue? Not really understanding if both servers have the same firewall rule to allow that port, that it should work on both servers. 



This thread was automatically locked due to age.
  • 0

    Hi,

    please check, one might be tcp and the newer one udp.

    ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk

    Both set the same. Default rules created by the OS.

  • 0

    Have you checked that the 2019 server recognises it is in the 'domain' network (not 'private' or 'public')?

    Alternatively, have you applied your rule to all those network profiles?

  • 0 in reply to JasP

    Yep, it's in a domain network. And yes the default is to apply to all network profiles. 

  • 0 in reply to Sergio Renes

    Have you checked the logs on whatever you are using for RADIUS (probably NPS)? Is your RADIUS server receiving the requests at all or is the problem with the Windows authentication? At least by narrowing down where the problem is it will help focus your troubleshooting. You only mention the RADIUS firewall rule in your original post but that may not be the cause of your failure. For example, your 2019 server may be trying to do the Windows authentication against the 2012 server, and something on your 2019 firewall may be interfering with that process. You can always Wireshark it but that isn't for the feint hearted if you don't have much experience using it.

    We have done a few in-place upgrades of both 2012 R2 and 2016 with NPS and haven't had any issues but they were single DC environments.

  • +1

    Hi.

    Yes I have run in to the same issue using server 2019.  There is a bug in Windows server 2019 firewall for Radius.

    I was not allowed to post links in the replay but there are a coupled of ways resolve the issue.

    Windows Server 2019 Bug

    It appears that Microsoft’s recently released Windows Server 2019 has a bug that prevents NPS from working correctly out of the box. Specifically, it looks like the default Windows firewall rules to allow inbound UDP port 1812 (RADIUS authentication) and inbound UDP port 1813 (RADIUS accounting) do not work.

    Resolution

    To resolve this issue, open an elevated command window and enter the following command.

    sc.exe sidtype IAS unrestricted

    Once complete, restart the server and the default Windows Firewall rules for NPS traffic will work correctly.

    Or you can create your own firewall rules or modify the existing one.

    Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

    And just in case you need to undo it:

    Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service ias

    //Rickard

  • 0 in reply to JasP

    I know it was only going to the server 2019 for auth because I clicked on Test connection while on the DC within Sophos under Authentication>Servers. 

  • 0 in reply to RickardNordahl

    That was it! Thanks Rickard!  

Unfiltered HTML