I am using Windows 7 firewall with outbound filtering enabled. Windows Firewall does not provide an UI for new outbound connection prompts, it just blocks them. Windows Firewall Control solves this using a workaround - it enables audit logging of packet/connection drop failures, monitors the Security log for new entries, and brings up prompts as needed.

I have spent time crafting a list of outbound Allow rules for all system services and applications that need to make outbound connections. Windows Firewall is able to target specific services within svchost.exe, allowing pretty fine-grained control. I have come across only two things where this doesn't work - Network Discovery, and Cryptographic Services.

I have the following rule enabled:

netsh advfirewall firewall add rule name="Windows Cryptographic Services"
  program="%SystemRoot%\System32\svchost.exe" service=CryptSvc 
  protocol=tcp remoteport=80,443 dir=out action=allow

However, I still keep getting blocks originating from the svchost.exe hosting CryptSvc, trying to make outbound http connections to verify certificates and such. I even used sc config CryptSvc type=own to isolate the service into its own container, to confirm that it's indeed CryptSvc making these requests. And even then, the rule would still not match. There are many other rules with the same structure, just different target service, where everything works just fine.

So far I could not find a satisfactory workaround. Allowing 'everything' for CryptSvc still won't make it match. The scope needs to be at least 'all services' for it to match, and this is too broad. I can add an ignore rule for svchost.exe in WFC, but that, again, is too broad for my liking. I'd prefer a systematic solution.

EDIT: Trying to edit my firewall rule pops up the a warning box:

Windows services have been restricted with rules that allow expected behavior only. Rules that specify host processes, such as svchost.exe, might not work as expected because they can conflict with Windows service-hardening rules.

Are you sure that you want to create a rule referencing this process?

Could be that this 'hardening' is interfering with the firewall's mechanism for identifying the originating service.

  • 1
    Hm, I will try, not sure what this'll achieve though since the logs clearly say it's tripping on connection attempts to ms servers on port 80. Jul 15, 2018 at 10:46
  • Goal is to have proper outbound filtering, with all core services that need network access be covered by appropriately constrained firewall rules. The built-in Windows Firewall product does not provide an UI for new outbound connection prompts. If you enable default-to-deny, you won't even know what's trying to connect (and when) unless you use auditpol.exe to turn on logging. And even then, you have to sift through all the junk in the Security log. That's where WFC comes in, it does that for you. I stay away from driver-based third party firewall products, I've been burned in the past. Jul 15, 2018 at 16:39
  • 1
    The problem is that the CryptSvc allow rule does not get matched, no matter how I define it, so everytime something tries to do CRL/OCSP, it still gets blocked, and I get spammed with prompts. My current workaround is to keep blocking them (bad for security!) and silence svchost.exe in WFC. Jul 15, 2018 at 17:02
  • 1
    I had this exact issue. I found what was the rule that blocked it WSH Default Outbound Block internally to Windows Firewall with the description Blocks all outbound traffic for services who have been network hardened. There seems to be some mystery regarding this "hardening". But taking into account this service is normally restricted by firewall I don't think you should worry. Just allow it and anything above its intended access will be taken care of by firewall. Aug 12, 2020 at 18:39
  • 1
    @sergiureznicencu @ theultramage Were you guys ever able to figure this out? I'm also using WFC and have some svchost.exe services that aren't able to connect out despite having allow-rules set for them. They can connect if I lower the filtering profile to Low-Filtering, which means it's an issue it not getting matched to an allow-rule vs. being blocked by some larger scale block-rule. Nov 12, 2020 at 1:31

1 Answer 1


Long ago, but still a valid question. Since the problem persists here is my Solution

  1. Open a CMD Window and get the SID of the cryptsvc service: sc showsid cryptsvc
  2. Create an advanced outbound firewall rule for some program (arbitrary)
  3. EDIT the properties of this rule: Programs and Services, Programs ALL, Application Packages use last option to apply following Application-SID and paste your SID from the CMD Window in here
  4. Ports and Protocols TCP 80, 443 instead Allow TCP ALL
  • Thank you for researching this. Win7 doesn't have "Application Packages" afaik, so I'm using a Win11 VM to try this. Maybe it's just an UI limitation and could be hacked in via registry. I'm curious if netsh has a parameter to input this SID. I'm also realizing that I didn't note down any test cases that cause CryptSvc itself to act. Viewing stack traces in ProcMon seems to do it every now and then. I'm seeing that using CryptSvc service name still doesn't match, but your SID method does work. Oct 17, 2023 at 13:22
  • Cryptsvc will always be triggered from a wakeup after standby. I figured it's more robust to allow all Protocols and Ports for some reason (changed the solution in that manner).
    – WildTbag
    Oct 17, 2023 at 17:54

You must log in to answer this question.

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