locked
Can't get filters that work perfectly on Windows 7 to work on Windows 8 RRS feed

  • Question

  • Hi,

    We are approaching release of our firewall for Windows 7/8 and have been very happy with WFP.  However as always happens we find a potential issue at the last minute!

    It appears that filters that work perfectly on Windows 7 don't work on Windows 8.

    To show this behavior I wrote a little application that adds two filters at the ALE_RECV_ACCEPT layer, a default "block all" rule with a higher priority "allow to local address x.x.x.x or y.y.y.y" rule.  When connecting in remotely (to address y.y.y.y) everything works on Windows 7.  If I change the address in the filter so it doesn't match, the connection correctly hits the default block rule.

    However on Windows 8 it always hits the default block rule unless I split the filter into two (one for x.x.x.x and one for y.y.y.y).  I cannot  see any other explanation then a serious WFP bug.

    I hope someone can help because otherwise we see no alternative to splitting the filters for every permutation which is resorting to WFP as it was on Vista.  We have concerns over the performance implications of doing this.

    If this is a bug we would like to know when it will be fixed (which hotfix etc. and estimated date so we can make an informed decision about whether to release or not).

    All help greatly appreciated.

    Windows 8 Enterprise (9200.16384.amd64fre.win8_rtm.120725-1247)

    ------------------------------------------------

    #include "stdafx.h"
    #include <fwpmu.h>
    #include <conio.h>

    // {B78510F0-E16C-40e2-A966-8834CC50525B}
    static const GUID SubLayerGuid =
    { 0xb78510f0, 0xe16c, 0x40e2, { 0xa9, 0x66, 0x88, 0x34, 0xcc, 0x50, 0x52, 0x5b } };

    int _tmain(int argc, _TCHAR* argv[])
    {
        FWPM_SESSION0 session = { 0 };
        session.displayData.name = L"WFP Test";
        session.flags = FWPM_SESSION_FLAG_DYNAMIC;

        HANDLE engine = 0;
        DWORD result = FwpmEngineOpen0(NULL, RPC_C_AUTHN_DEFAULT, NULL, &session, &engine);
        if(result != ERROR_SUCCESS)
        {
            return 0;
        }

        FWPM_SUBLAYER0 sublayer = { 0 };
        sublayer.subLayerKey = SubLayerGuid;
        sublayer.displayData.name = L"WfpTest";
        sublayer.weight = 100;
        result = FwpmSubLayerAdd0(engine, &sublayer, NULL);
        if(result != ERROR_SUCCESS)
        {
            return 0;
        }

        // Add a default block rule.
        FWPM_FILTER0 filter = { 0 };
        filter.subLayerKey = SubLayerGuid;
        filter.layerKey = FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4;
        
        filter.displayData.name = L"Block All";
        filter.numFilterConditions = 0;
        filter.filterCondition = NULL;
        filter.action.type = FWP_ACTION_BLOCK;
        filter.weight.type = FWP_UINT8;
        filter.weight.uint8 = 0;

        UINT64 filterId = 0;
        result = FwpmFilterAdd(engine, &filter, NULL, &filterId);
        if(result != ERROR_SUCCESS)
        {
            return 0;
        }

        // Now add a higher priority rule with two local address conditions
        // which should be an OR (works on Windows 7 but not on 8)

        FWPM_FILTER_CONDITION0 conds[2];
        conds[0].fieldKey = FWPM_CONDITION_IP_LOCAL_ADDRESS;
        conds[0].matchType = FWP_MATCH_EQUAL;
        conds[0].conditionValue.type = FWP_UINT32;
        conds[0].conditionValue.uint32 = 0x01020304;

        conds[1].fieldKey = FWPM_CONDITION_IP_LOCAL_ADDRESS;
        conds[1].matchType = FWP_MATCH_EQUAL;
        conds[1].conditionValue.type = FWP_UINT32;
        conds[1].conditionValue.uint32 = 0xC0A8640A;        // 192.168.100.10

        filter.displayData.name = L"Allow address";
        filter.numFilterConditions = 2;
        filter.filterCondition = conds;
        filter.action.type = FWP_ACTION_PERMIT;
        filter.weight.uint8 = 1;

        result = FwpmFilterAdd(engine, &filter, NULL, &filterId);
        if(result != ERROR_SUCCESS)
        {
            return 0;
        }

        getch();
        return 0;
    }

    Monday, November 12, 2012 2:17 PM

All replies

  • I have been unable to repro your scenario using the WFP Sampler

    The following are the filters I have in place:

     
    		<item>
    			<filterKey>{fd916a62-20bf-47e6-9a17-d36d6d0ec57f}</filterKey>
    			<displayData>
    				<name>WFPSampler's Basic Action Permit Scenario Filter</name>
    				<description/>
    			</displayData>
    			<flags numItems="1">
    				<item>FWPM_FILTER_FLAG_INDEXED</item>
    			</flags>
    			<providerKey>{53504657-6d61-5f70-5072-6f7669646572}</providerKey>
    			<providerData/>
    			<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
    			<subLayerKey>{53504657-6d61-5f70-5375-624c61796572}</subLayerKey>
    			<weight>
    				<type>FWP_UINT8</type>
    				<uint8>15</uint8>
    			</weight>
    			<filterCondition numItems="4">
    				<item>
    					<fieldKey>FWPM_CONDITION_IP_LOCAL_ADDRESS</fieldKey>
    					<matchType>FWP_MATCH_EQUAL</matchType>
    					<conditionValue>
    						<type>FWP_UINT32</type>
    						<uint32>172.31.225.131</uint32>
    					</conditionValue>
    				</item>
    				<item>
    					<fieldKey>FWPM_CONDITION_IP_PROTOCOL</fieldKey>
    					<matchType>FWP_MATCH_EQUAL</matchType>
    					<conditionValue>
    						<type>FWP_UINT8</type>
    						<uint8>6</uint8>
    					</conditionValue>
    				</item>
    				<item>
    					<fieldKey>FWPM_CONDITION_IP_REMOTE_ADDRESS</fieldKey>
    					<matchType>FWP_MATCH_EQUAL</matchType>
    					<conditionValue>
    						<type>FWP_UINT32</type>
    						<uint32>172.31.225.51</uint32>
    					</conditionValue>
    				</item>
    				<item>
    					<fieldKey>FWPM_CONDITION_IP_REMOTE_ADDRESS</fieldKey>
    					<matchType>FWP_MATCH_EQUAL</matchType>
    					<conditionValue>
    						<type>FWP_UINT32</type>
    						<uint32>172.31.225.160</uint32>
    					</conditionValue>
    				</item>
    			</filterCondition>
    			<action>
    				<type>FWP_ACTION_PERMIT</type>
    				<filterType/>
    			</action>
    			<rawContext>0</rawContext>
    			<reserved/>
    			<filterId>84600</filterId>
    			<effectiveWeight>
    				<type>FWP_UINT64</type>
    				<uint64>18439707199291785216</uint64>
    			</effectiveWeight>
    		</item>
    		<item>
    			<filterKey>{400f6f8e-7eb1-4e0b-83d4-3f10c77af392}</filterKey>
    			<displayData>
    				<name>WFPSampler's Basic Action Block Scenario Filter</name>
    				<description/>
    			</displayData>
    			<flags/>
    			<providerKey>{53504657-6d61-5f70-5072-6f7669646572}</providerKey>
    			<providerData/>
    			<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
    			<subLayerKey>{53504657-6d61-5f70-5375-624c61796572}</subLayerKey>
    			<weight>
    				<type>FWP_UINT8</type>
    				<uint8>15</uint8>
    			</weight>
    			<filterCondition/>
    			<action>
    				<type>FWP_ACTION_BLOCK</type>
    				<filterType/>
    			</action>
    			<rawContext>0</rawContext>
    			<reserved/>
    			<filterId>84601</filterId>
    			<effectiveWeight>
    				<type>FWP_UINT64</type>
    				<uint64>17293822569102704640</uint64>
    			</effectiveWeight>
    		</item>

    This yields the desired results that both 172.31.225.160 and 172.31.225.51 can reach 172.31.225.131.  However 172.31.225.144 cannot.

    I would suggest running  "Netsh.exe WFP Capture Start", Repro the scenario, then run "NetSh.exe WFP Capture Stop".  Within the XML file, search for "CLASSIFY_DROP", and match the event with the traffic.  It should show you the filter causing the drop.

    Scenario questions:
       1) Does the machine have 2 nics?
          a) are you sending traffic on the appropriate subnet (i.e. 192 ->192, 1->1. etc)
             i) if not, then do you have forwarding / loose source mapping enabled?

    Hope this helps,

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


    Monday, November 12, 2012 10:08 PM
    Moderator
  • Hi Dusty,

    Thanks for the quick response.  I can confirm that the default block filter is being hit so I modified by test app to mimic your tests, i.e. a permit filter with 4 conditions - local address, protocol and two remote addresses, and this worked for me too.  However as soon as a second local address condition is added (the 1.2.3.4 dummy address) then the filter stopped working (the condition ordering is 2 local addresses, protocol, 2 remote addresses). 

    Therefore could you add a second local address condition to your tests and see if that works?

    In response to your other questions: the machine only has one nic, and the traffic is being sent from the same subnet (192.168.100.x).

    Thanks.


    • Edited by SpecWin Tuesday, November 13, 2012 1:25 PM
    Tuesday, November 13, 2012 1:23 PM
  • We saw the problem first when we were testing filtering on broadcast addresses, but we have also demonstrated it on machines with more than one nic so it is going to be relevant.

    Mary (Guitarboy's sidekick)

    Wednesday, November 14, 2012 8:32 AM
  • Further update:  If the first local address matches then the rule will trigger, but not for the second.
    Friday, November 16, 2012 5:29 PM
  • Hi Dusty,

    Have you had a chance to try multiple local addresses yet (see post above)?

    Thanks.

    Wednesday, November 21, 2012 3:19 PM
  • No I have not.  I have our Sustained Engineering team investigating, and I'll try to repro later today.

    Thanks,


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

    Wednesday, November 21, 2012 5:29 PM
    Moderator
  • Confirmed that this is a bug and regression from Windows 7.  Our Sustained engineering team is investigating a fix.

    Thanks,


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

    Tuesday, November 27, 2012 5:12 PM
    Moderator
  • Hi Dusty,

    Thanks for the confirmation. 

    We have also seen some issues with multiple addresses on Windows 7, although the scenario presented above does work.   We aren't initially targeting Windows 7 so haven't raised these, if I get a chance I'll add the repro steps if it helps.

    We would be grateful if you could update with an estimated date for the fix (and hotfix number) once known so we can decide whether to wait for the fix (and document the hotfix as being required) or implement a workaround.

    Many thanks.
    Wednesday, November 28, 2012 8:59 AM
  • Same issue when the condition fieldkey is FWPM_CONDITION_ALE_APP_ID.

    • Edited by Joke Huang Wednesday, February 20, 2019 6:34 PM
    Wednesday, February 20, 2019 6:09 PM