0

Windows firewall on multiple domain controllers (2016 & 2019) has suddenly stopped blocking RDP access to port 3389.

There was a GPO firewall rule to restrict access to the RDP port based on IP that worked fine. The GPO was initially filtered on AD group membership during testing. The AD group filter was then removed from the policy so it then applied to all DCs in the OU.

Suddenly the IP block just stopped working and connections from any IP could get through to RDP. The policy is getting applied and the restrict IP rule still gets added to the firewall, but now has no effect.

Nothing else was changed and I've scoured every possible setting but there is nothing allowing full access on the RDP port.

As a test I added a block rule for all ports and protocols. This seemed to block everything except the RDP port.

Firewall is turned on and enabled on all profiles (Domain, Private & Public) and set to block if no incoming allow rule exists.

I've tried removing the GPO, reset the firewall to defaults, deleted ALL incoming rules, set the firewall to block ALL connections and still port 3389 is open.

As another test, I changed the RDP listening port to a random port and this was blocked. Set it back to 3389 and RDP connected again.

Has anyone ever seen anything like this?

Improve this question

2 Answers 2

Reset to default
0

You can try enabling the WFP audit logging and check the allow events for 3389. Then grab the filterID from the events and look up the matching firewall rule. See How to tell which windows firewall rule is blocking traffic for steps. This is the best method to find which rule is too permissive/restrictive.

You can also search for existing rules on a machine using powershell. Rules that filter by the port or service are the most common. Here's the built-in RDP rules for example:

# Search for rules allowing the RDP service to listen:
Get-NetFirewallServiceFilter -Service TermService -PolicyStore ActiveStore | 
  Select InstanceID,Service

InstanceID                    Service    
----------                    -------    
RemoteDesktop-UserMode-In-TCP termservice
RemoteDesktop-UserMode-In-UDP termservice

# Search for rules allowing port 3389:
Get-NetFirewallPortFilter -All -PolicyStore ActiveStore | 
  Where LocalPort -EQ 3389 | 
  Select InstanceID,Protocol,LocalPort

InstanceID                    Protocol LocalPort
----------                    -------- ---------
RemoteDesktop-UserMode-In-TCP TCP      3389     
RemoteDesktop-UserMode-In-UDP UDP      3389

You may not see all the active rules depending on how you're viewing them and where the rules were configured. Windows applies from multiple policy stores, and some of the weird ones tend to not show in the graphical viewer

Improve this answer
5
  • Thanks, I tried the WFP logging and the FilterID that shows up as accepting the connection relates to the "Interface Un-quarantine filter". It doesn't trigger any other rules. As I understand it, block rules take precedence, so if I have the firewall on and enabled for all interfaces and add a rule that blocks all connections to port 3389, both TCP and UDP, then there should be no scenario where the port should still be open?
    – Turbo_Ap
    Nov 1 at 14:49
  • @Turbo_Ap That's normal behavior - the quarantine rules apply before the rest of the actual firewall rules. Block rules do take precedence, but you can't easily exclude specific IPs that way. Are you using default-block or default-allow when no rules match?
    – Cpt.Whale
    Nov 1 at 15:21
  • We are using default-block. But during the process of troubleshooting, I've even created a test block rule to block port 3389 for ALL IPs on both TCP and UDP, but the port was still open. I've even switched the firewall to block all incoming connections - everything else gets blocked except port 3389.
    – Turbo_Ap
    Nov 1 at 16:25
  • Do you have "Allow Local Firewall Rule Policy Merge" enabled, and are you testing with local or GPO firewall rules? The only way for blocked traffic to pass through a firewall block rule should be when the connection is already established (like you have an RDP session open while adding the rule), or the rules are not applied/getting reverted by gpo.
    – Cpt.Whale
    Nov 1 at 17:16
  • Thank you Cpt.Whale for your attempts to help. I eventually got to the bottom of it and have posted the answer.
    – Turbo_Ap
    Nov 8 at 12:56
0

It turns out this problem was being caused by the Crowdstrike Windows Sensor. When installed on a Windows domain controller it uses RDP inspection to validate connecting hosts. Problem is, there is at present a quietly acknowledged bug which causes it to conflict with host-based firewalls. They are working on a fix, but no date for delivery as yet.

This only affects servers with the DC role.

Thankfully, the RDP inspection component can be disabled. The firewall then works as expected.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .