RDP inbound blocked on Windows 11 after boot but before first login

Firewall version:

I’m setting up a new machine, with Windows 11. After I reboot, I can’t remote into it via RDP. Once I go to the machine and log in locally, remoting in works fine. If I then log out, I can remote in again fine. Disabling CFW makes the problem go away. Adding a global rule to allow incoming packets destined for port 3389 doesn’t help.

Is there a way I can configure this problem away, or is it a bug?

Hi Atario,

Thank you for reporting.
From the above statement we understand that you are using two machines A & B.
Machine A has CFW installed and you are trying to take remote of machine B from machine A isn’t it ? if we missed something else to understand kindly let us know.
Sharing steps to reproduce the issue would be helpful for us to analyze.


Mmm, no. Everything I’ve said so far is about that one machine — it has CFW on it, which prevents remoting in prior to the first login after reboot.

I tried against a VM and I had no issues connecting, you can try disabling the Windows firewall for all three profiles, as CIS does not turn it off on Windows 8 or later. Also create an application rule for svchost with the same allow incoming rule.

I had tried that with Windows Firewall, before I discovered that disabling CFW lets me in.

However, that svchost rule did the trick! In fact it works even without the global rule.

But now I’m wondering why it acts the other way without a svchost rule. I’d like to understand the mechanics of the firewall here. What would make it allow these inbound connections after first login, but not before, in the absence of any svchost rule at all?

You were trying too soon to connect before CIS was fully loaded in the background, particularly the file rating system which determines whether to allow the connection for trusted applications, or to show an alert if unknown. But application rules go into effect very early, which allows CIS to make the decision quicker, and therefore you can connect as soon as possible.

So, you really don’t NEED the application rule, but it does make it easier to establish connections as soon as possible compared to without app rules in place. As for your global rules, you probably already have a rule in place that allows all incoming connections from source addresses that are on the same subnet.

This sounded plausible to me, so I just now tried waiting 15 minutes before attempting the connection. Still no dice, though.

Hi Atario,

We are checking on this issue.
We will keep you posted.