Skip to main content

 none
Troubleshooting WFP problem - Network error: Permission denied RRS feed

  • Question

  • Hi,

    I am trying to troubleshoot a problem with Windows Filter Platform (wfp).

    I have created a filter and callout based on the Windows Filtering Platform Sample defined here: https://github.com/microsoft/Windows-driver-samples/blob/master/network/trans/WFPSampler/README.md

    I am having a couple of issues with this filter and sample filters has the same issues.

    First a couple of questions.

    1. Do all of the Fwpm*CreateEnumHandle() calls require high access rights?

       Specifically calls for FwpmFilterCreateEnumHandle(), FwpmCalloutCreateEnumHandle() and FwpmProviderContextCreateEnumHandle() requires FWPM_ACTRL_ENUM access, is this correct?

    2. When creating an enum handle, what is required for the filter enum template to return a list of matching filters? Does it vary depending on the enum handle(Filter,Callout,Provider Context)?

    Issue One

    When I deploy my filter and try to un-deploy it, I get errors from the above calls. This requires I run un-deploy as Administrator in Windows 10.

    When I run as administrator, I can get EnumHandles but I get filters, callouts and provider contexts for everything.

    I wanted to verify that I need to use a template (filter template, callout template and provider context template) with match criteria.

    I also want to verify I need elevated privileges to create enum handles.

    Issue Two

    When I deploy the filter and callout, I get "Network error: Permission denied".

    Example: I have a filter that is of type FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 with two conditions (Remote Address and Remote Port - 10.17.47.135 and 22)

    I get no information in the Event Viewer, no network events. I have filter dumps and filter state dumps from netsh wfp calls and there is no indication of an issue.

    At this point I run a cleanup program as administrator that deletes all the filters and callouts (I know this is a bad idea).

    Re-deploy my filter and it runs fine.

    It feels like there is filter or callout conflict here. 

    In my case there is another FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 filter from Symantec that gets deleted during cleanup but that filter does not have the same conditions.

    I have someone else testing this and they have the same issue but I'm not sure what their end node protection is.

    Is there a way to troubleshoot this issue?

    If permission is being denied, is there a way to see why? Is it a packet filter? Or some other rule?

    After a fresh reboot and all Symantec filters are back and I do NOT deploy my filter, I have access to this device without issue?

    Thanks

    -brad


    Tuesday, July 16, 2019 6:59 PM

All replies

  • Hello bradski37,

    The answer for first question is YES. Please refer to Access Right Identifiers.

    "FWPM_ACTRL_ENUM: Enumerate. This access right is needed in order to call Fwpm*CreateEnumHandle0 functions. To enumerate an object, the caller also needs FWPM_ACTRL_READ access to the object."

    For second question, it depends what you want to enumerate. For example, specify different flag you will get different filters. For more information you can refer to "FWPM_FILTER_ENUM_TEMPLATE0 structure".

    And about deploying issue, there seems missing a package project for Automatic deployment. So do you use Automatic deployment or Manual deployment?

    Best regards,

    Rita


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, July 17, 2019 7:20 AM
  • Hi Rita,

    Thanks for the feedback. Your answers are confirmation.

    The problem that remains is the deployment. I will follow the deployment steps for debugging the driver and post the results.

    Thanks

    bradski37

    Thursday, July 18, 2019 1:50 AM