Some Windows firewall troubleshooting …

Obvious in retrospect, but today I picked up something new with Windows firewall.

I have a work laptop and I had been trying to RDP into from one of my home machines. Easier, you know, when I am not necessarily in front of the laptop but on some other machine and want to quickly RDP to check email or do some work. Thing is, try what I may I couldn’t ping or RDP this laptop. I could connect from the laptop to my home network, but the reverse seemed to be blocked.

Initially I suspected the VPN client might be doing something, but that didn’t make sense. Usually a VPN client blocks outgoing and that was working fine here. I took a look at the laptop firewall and that had RDP allowed on the public profile with no restrictions to source IP etc. The RDP services were running, my account was in the correct groups etc. I even added a catch all allow rule to the firewall to see if that’d make a difference – but nope! I couldn’t disable the firewall unfortunately as that was controlled via GPOs.

From the Windows Firewall console you can get the log files:

… and that showed me the RDP connections were definitely being dropped. This made no sense considering I had an allow rule.

Next I followed this helpful post to identify which rule was blocking it (I am reproducing the steps here just in case).

- - Open a Windows console (with Administration rights) to enter commands
  - Enable the audit for Windows Filtering Platform (WFP) by running the following commands:
    - auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
    - auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
  - Reproduce the issue
  - Run command: netsh wfp show state (this creates a XML file in the current folder)
  - Open the event viewer: Run (Windows+R) > eventvwr.msc
  - Go to “Windows logs” > “Security”
  - In the list, identify the dropping packet log (hint: use the Search feature on the right menu, searching for items (source IP, destination port, etc.) specific to your issue)
  - In the log details, scroll down and note the filter ID used to block the packet
  - Open the generated XML file:
  - Aearch for the noted filterID, and check out the rule name (element “displayData > name” on the corresponding XML node)
  - —
  - When you’re done, don’t forget to turn off the audit:
    - auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable
    - auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:disable

In my case I had the following:

<item>
    <filterKey>{437be0f0-cb8e-4cc4-b183-6085825d3120}</filterKey>
    <displayData>
        <name>Query User</name>
        <description>Prompt the User for a decision corresponding this Inbound Traffic</description>
    </displayData>
    <flags/>
    <providerKey>{decc16ca-3f33-4346-be1e-8fb4ae0f3d62}</providerKey>
    <providerData>
        <data>fb03000000000000</data>
        <asString>........</asString>
    </providerData>
    <layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
    <subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2301}</subLayerKey>
    <weight>
        <type>FWP_UINT8</type>
        <uint8>8</uint8>
    </weight>
    <filterCondition numItems="1">
        <item>
            <fieldKey>FWPM_CONDITION_ORIGINAL_PROFILE_ID</fieldKey>
            <matchType>FWP_MATCH_EQUAL</matchType>
            <conditionValue>
                <type>FWP_UINT32</type>
                <uint32>1</uint32>
            </conditionValue>
        </item>
    </filterCondition>
    <action>
        <type>FWP_ACTION_BLOCK</type>
        <filterType/>
    </action>
    <rawContext>0</rawContext>
    <reserved/>
    <filterId>71629</filterId>
    <effectiveWeight>
        <type>FWP_UINT64</type>
        <uint64>9223372036854791168</uint64>
    </effectiveWeight>
</item>

<item>

<name>Query User</name>

<description>Prompt the User for a decision corresponding this Inbound Traffic</description>

</displayData>

</providerData>

<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>

</weight>

<item>

<fieldKey>FWPM_CONDITION_ORIGINAL_PROFILE_ID</fieldKey>

<matchType>FWP_MATCH_EQUAL</matchType>

</conditionValue>

</item>

</filterCondition>

<type>FWP_ACTION_BLOCK</type>

</action>

</effectiveWeight>

</item>

So it was being blocked by a rule called “Prompt the User for a decision corresponding this Inbound Traffic”? Made no sense.

Some more Googling on that brought me to this thread from which I realized that of course there’s a setting to merge or override the local firewall rules, and even though it appeared to be the case that the local rules were active (I could edit them, add new rules, disable etc.) they were in fact being ignored because the GPO settings were overriding them. Once I modified the GPO to allow local rules, I was then able to RDP to my laptop.