none
Windows firewall blocks outbound connection that is allowed by a rule RRS feed

  • Question

  • I have configured Windows Firewall to block all outbound connections. I have then created "allow" rules to enable certains applications to create outbound connections. Unfortunately it seems that some connections that should be allowed are still blocked and I don't understand why.

    I have a simple rule to allow Windows Problem Reporting:

    • Enabled: Yes
    • Action: Allow the connection
    • Programs: C:\windows\system32\wermgr.exe
    • Protocol type: TCP (6)
    • Local port: All Ports
    • Remote port: All Ports
    • Local IP address: Any IP address
    • Remote IP address: Any IP address
    • Profiles: Domain, Private, Public

    Nevertheless, after creating this rule, a connection was blocked and logged in the event log (event ID 5157):

    The Windows Filtering Platform has blocked a connection.
    
    Application Information:
        Process ID:          7440
        Application Name:    \device\harddiskvolume3\windows\system32\wermgr.exe
    
    Network Information:
        Direction:           Outbound
        Source Address:      192.168.1.23
        Source Port:         31532
        Destination Address: 65.55.53.190
        Destination Port:    80
        Protocol:            6
    
    Filter Information:
        Filter Run-Time ID:  184645
        Layer Name:          Connect
        Layer Run-Time ID:   48
    

    Given the rule that was created specifically to allow wermgr.exe to connect I don't understand why the connection was blocked. How can I modify the rule to allow the connection to succeed?

    By the way, this is not an issue isolated to wermgr.exe. Once in a while I see blocked connections for other applications even though I have created rules for them also. Luckily most of the time the rules work as expected.


    Monday, July 23, 2012 4:23 PM

Answers

  • To assist with this, the best thing to do is run the following
       "NetSh.exe WFP capture start"
       Repro the scenario
       "NetSh.exe WFP capture stop"

    You can then send the resultant .cab file to DHarper<AT>Microsoft<DOT>com

    If you wish to dig into it yourself, you can search for the net event for the block, and correlate it with the actual filter id.  this should give you an indication of why the traffic was blocked.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Monday, July 23, 2012 4:34 PM
    Moderator
  • Thanks a lot for the information about how to perform a capture. It has taken me a while to reproduce the problem, and instead of taking advantage of your very generous offer I took a deep dive into the XML myself.

    The wermgr.exe blocking events are attributed to the filter "WSH Default Outbound Block" with the description "Blocks all outbound traffic for services who have been network hardened". Apparently this filter comes into effect at a higher priority than my custom "allow" filter.

    As far as I can see wermgr.exe is not running a service but it seems the that "WSH Default Outbound Block" triggers for a selection of S-1-5-80 SID's (NT_SERVICE well-known SID's). I'm speculating here, but perhaps one of the services listed executes wermgr.exe which then gets blocked based on the SID of the process. The connection attempt is to 65.55.53.190 which is a Microsoft IP address so I assume that the connection is legitimate and perfectly safe. I hope that I'm not missing out on an important feature of Windows Problem Reporting because of this hardening rule.

    The remaining "unexpected" blocks I found in the logs were either from System or svchost.exe and were all blocked by "WSH Default Outbound Block" which probably is a good thing.


    Friday, July 27, 2012 11:40 AM

All replies

  • To assist with this, the best thing to do is run the following
       "NetSh.exe WFP capture start"
       Repro the scenario
       "NetSh.exe WFP capture stop"

    You can then send the resultant .cab file to DHarper<AT>Microsoft<DOT>com

    If you wish to dig into it yourself, you can search for the net event for the block, and correlate it with the actual filter id.  this should give you an indication of why the traffic was blocked.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Monday, July 23, 2012 4:34 PM
    Moderator
  • Thanks a lot for the information about how to perform a capture. It has taken me a while to reproduce the problem, and instead of taking advantage of your very generous offer I took a deep dive into the XML myself.

    The wermgr.exe blocking events are attributed to the filter "WSH Default Outbound Block" with the description "Blocks all outbound traffic for services who have been network hardened". Apparently this filter comes into effect at a higher priority than my custom "allow" filter.

    As far as I can see wermgr.exe is not running a service but it seems the that "WSH Default Outbound Block" triggers for a selection of S-1-5-80 SID's (NT_SERVICE well-known SID's). I'm speculating here, but perhaps one of the services listed executes wermgr.exe which then gets blocked based on the SID of the process. The connection attempt is to 65.55.53.190 which is a Microsoft IP address so I assume that the connection is legitimate and perfectly safe. I hope that I'm not missing out on an important feature of Windows Problem Reporting because of this hardening rule.

    The remaining "unexpected" blocks I found in the logs were either from System or svchost.exe and were all blocked by "WSH Default Outbound Block" which probably is a good thing.


    Friday, July 27, 2012 11:40 AM
  • Did you solved the probem?

    I have same problem enabling chrome in outbound rules...

    Wednesday, December 26, 2012 9:56 PM