locked
Need help with flags at FWPM_LAYER_INBOUND_IPPACKET_V4 RRS feed

  • Question

  • I have a callout to inspect packets at FWPM_LAYER_INBOUND_IPPACKET_V{4|6}.
    I want to inspect all packets exept :

    - The loopback traffic.

    - The packets presented a second time as "fragmented" or a third time as "reassembled". I only need all raw packets, only once.

    So I Have  this filter :

    FWPM_FILTER0 filter = {0};
    FWPM_FILTER_CONDITION0 filterConditions[3] = {0}; 
    UINT conditionIndex;
    
    filter.layerKey = *layerKey;
    filter.displayData.name = (wchar_t*)filterName;
    filter.displayData.description = (wchar_t*)filterDesc;
    
    filter.action.type = FWP_ACTION_CALLOUT_TERMINATING;
    filter.action.calloutKey = *calloutKey;
    filter.filterCondition = filterConditions;
    filter.subLayerKey = TL_INSPECT_SUBLAYER;
    filter.weight.type = FWP_EMPTY; // auto-weight.
    filter.rawContext = context;
    
    conditionIndex = 0;
    
    filterConditions[conditionIndex].fieldKey = FWPM_CONDITION_FLAGS;
    filterConditions[conditionIndex].matchType             = FWP_MATCH_FLAGS_NONE_SET;
    filterConditions[conditionIndex].conditionValue.type   = FWP_UINT32;
    filterConditions[conditionIndex].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_FRAGMENT | FWP_CONDITION_FLAG_IS_REASSEMBLED | FWP_CONDITION_FLAG_IS_LOOPBACK;
    conditionIndex++;
    
    filter.numFilterConditions = conditionIndex;
    
    status = FwpmFilterAdd0(gEngineHandle, &filter,	NULL, NULL);
    			

    Instead of FWP_MATCH_FLAGS_NONE_SET, I have also tried FWP_MATCH_FLAGS_ALL_SET, FWP_MATCH_FLAGS_ANY_SET without success.




    • Edited by OlivierMSDN Tuesday, September 11, 2012 7:31 PM
    Tuesday, September 11, 2012 6:36 PM

Answers

  • This sounds like a service hardening rule.  just because you are allowing a packet (returning FWP_ACTION_PERMIT for CALLOUT_TERMINATING, or FWP_ACTION_CONTINUE for CALLOUT_INSPECTION) doesn't mean that action will necessarily be the final action.  In this case the traffic is blocked by the Windows Firewall Service hardening rule.  Your callout got it's say, but the BLOCK won the final decision.  You should read on the filter arbitration http://msdn.microsoft.com/en-us/library/windows/desktop/aa364008(v=vs.85).aspx.

    Hope this helps,


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

    • Marked as answer by OlivierMSDN Friday, September 14, 2012 11:42 AM
    Thursday, September 13, 2012 4:25 PM
    Moderator

All replies

  • When you say without success, what exactly isn't meeting your expectation?  Is your callout being invoked for packets indicated with those flags?  only a subset of those?  What OS are you using?


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

    Wednesday, September 12, 2012 3:22 PM
    Moderator
  • Thanks for your reply. Currently I have 2 callouts, one for inbound and another for outbound :

    if (IsEqualGUID(layerKey, &FWPM_LAYER_INBOUND_IPPACKET_V4) || IsEqualGUID(layerKey, &FWPM_LAYER_INBOUND_IPPACKET_V6))
    {
    	filterConditions[conditionIndex].fieldKey		= FWPM_CONDITION_FLAGS;
    	filterConditions[conditionIndex].matchType             = FWP_MATCH_FLAGS_NONE_SET;
    	filterConditions[conditionIndex].conditionValue.type   = FWP_UINT32;
    	filterConditions[conditionIndex].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_FRAGMENT | FWP_CONDITION_FLAG_IS_REASSEMBLED | FWP_CONDITION_FLAG_IS_LOOPBACK;
    }
    else
    {
    	filterConditions[conditionIndex].fieldKey	 = FWPM_CONDITION_FLAGS;
    	filterConditions[conditionIndex].matchType             = FWP_MATCH_FLAGS_NONE_SET;
    	filterConditions[conditionIndex].conditionValue.type   = FWP_UINT32;
    	filterConditions[conditionIndex].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_LOOPBACK;				
    }
    

    I have a huge packets lost at outbound, with many retransmissions, the outbound traffic is working but very slow. Its useable with web and pop3 but not with smtp, ftp, smb2, etc... No wfp api error. I use Win7 64.

    I have additional questions:

    - What is the more lower layer that "see" loopbacks? Is it useful to check it at network?

    - What is the default behavior for the packets that don't pass the callout filter therefore are not proceeded by the callout: is it BLOCK ou PERMIT?

    - Is it required to add an another filter with a higher priority and PERMIT action for the packets which are not proceeded by the callout?

    Wednesday, September 12, 2012 4:08 PM
  • 1) The first place outbound loopback traffic is seen will be FWPM_LAYER_ALE_AUTH_CONNECT_V{4 | 6}.  For inbound loopback traffic, it is indicated first at FWPM_LAYER_INBOUND_IPPACKET_V{4 | 6}.

    2) Packets that don't match any filter are allowed by default.  If you have any filter that matches the traffic, then the filters are arbitrated (Note that other filters can exist in other sublayers, and they get a say in the decision as well).

    3) No. By default, if traffic does not match any filter, it will be unhindered within the TCP/IP stack.

    To repro your scenario, I used the WFPSampler (http://code.msdn.microsoft.com/Windows-Filtering-Platform-27553baa).  I issued the following command to create the filter :
       WFPSampler.exe -s BASIC_ACTION_PERMIT -l FWPM_LAYER_INBOUND_IPPACKET_V4 -f != 0x421 -c -v

    I then used a debugger and sent traffic, verifying the expected outcome. 

    In the WFPSampler, I chose the BASIC_ACTION_PERMIT scenario (-s BASIC_ACTION_PERMIT) which essentially just returns FWP_ACTION_PERMIT.
    I forced it to use a callout (-c) so I could debug the classifies to verify the traffic being indicated.
    I used FWPM_LAYER_INBOUND_IPPACKET_V4 (-l FWPM_LAYER_INBOUND_IPPACKET_V4) as the layer to create the filter.
    The filter consisted of a single condition FWPM_CONDITION_FLAGS (-f) with the matchType of FWP_MATCH_FLAGS_NONE_SET (!=) and the 3 flags you mentioned (0x421).

    I can't tell much from the code you've posted.  I don't know off hand how much smtp, ftp, smb2, etc rely on loopback, or what you are doing in your callout.  Can you elaborate on what it is you are trying to accomplish?  Is it safe to say that the original issue you were asking about has been solved?


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

    Wednesday, September 12, 2012 4:54 PM
    Moderator
  • My initial issue is still here, I currently investigate the interaction between inbound and outbound. My driver has a worker thread which communicates with a service. The service inspects and sometimes modifies the inbound and outbound packets. But the packet loss is the same in a simplified configuration, where all packets are directly reinjected by the worker thread with no communication with the service and no modification.

    From your previous post I deduced the flag FWP_CONDITION_FLAG_IS_LOOPBACK is useless at FWPM_LAYER_OUTBOUND_IPPACKET. So I removed this condition, but now the traffic is completely blocked. A filter without any condition is not valid?

    Wednesday, September 12, 2012 7:08 PM
  • If I install the callout only at outbound I have the issue, if I install the callout only at inbound there is no issue. So the problem is at outbound, not inbound, sorry for the confusion. The blocking when the condition with FWP_CONDITION_FLAG_IS_LOOPBACK is removed is still mysterious.


    • Edited by OlivierMSDN Wednesday, September 12, 2012 7:30 PM
    Wednesday, September 12, 2012 7:22 PM
  • The doc is not clear:

    Here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549942%28v=vs.85%29.aspx

    FWP_CONDITION_FLAG_IS_LOOPBACK is set at FWPM_LAYER_OUTBOUND_IPPACKET_V

    Here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364002%28v=vs.85%29.aspx

    it is not.



    • Edited by OlivierMSDN Wednesday, September 12, 2012 8:11 PM
    Wednesday, September 12, 2012 8:09 PM
  • IS_LOOPBACK is available to both INBOUND and OUTBOUND IPPACKET.

    A filter with no condition matches everything.

    Hope this helps,


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

    Wednesday, September 12, 2012 9:20 PM
    Moderator
  • - I keep IS_LOOPBACK in inbound and outbound filters and it works as expected, no issue here.

    - The packets loss at outbound is solved if the outbound callout is registered with FWP_ACTION_CALLOUT_INSPECTION instead of FWP_ACTION_CALLOUT_TERMINATING. So I suspect a missing a FWP_ACTION_PERMIT somewhere outside the ClassifyFn, but I don't know where/when. The differences between FWP_ACTION_CALLOUT_INSPECTION and FWP_ACTION_CALLOUT_TERMINATING are not clear to me. No issue at inbound with FWP_ACTION_CALLOUT_TERMINATING.

    Thursday, September 13, 2012 1:41 PM
  • CALLOUT_INSPECTION means you will not be blocking the traffic.  if the callout does return block, the action is ignored and the traffic is allowed anyhow (acts as a FWP_ACTION_CONTINUE).  CALLOUT_TERMINATING means that the callout will make a decision (BLOCK or PERMIT), and that action will take part in the final decision.  CALLOUT_UNKNOWN means the callout can do pretty much anything.

    To figure out what is dropping the traffic, you should run "NetSh.exe WFP Capture Start" from an elevated command prompt, repro the scenario, run "NetSh.exe WFP Capture Stop" from an elevated command prompt.  In the resultant cab will be an .XML file.  open this with notepad and search for CLASSIFY_DROP.  You will be taken to the first drop NetEvent.  From here, you can search for the specific traffic (I.e. search for the remote port of the connection that was dropped).  Once found, you will see the filterID of the filter which caused the drop.  You can then search from the beginning of the file for that filterID.

    Hope this helps,


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

    Thursday, September 13, 2012 2:22 PM
    Moderator
  • filterId = 82612, its description translated in English could be "protection again ports scanning", at FWPM_LAYER_INBOUND_TRANSPORT_V4_DISCARD. In the test I don't perform any ports scanning...

    I still don't understand why the behavior is different with FWP_ACTION_CALLOUT_INSPECTION and FWP_ACTION_CALLOUT_TERMINATING.
    In both cases, the classifyFn is ending with the same sequence:

        classifyOut->actionType = FWP_ACTION_BLOCK;
        classifyOut->rights &= ~FWPS_RIGHT_ACTION_WRITE;
        classifyOut->flags |= FWPS_CLASSIFY_OUT_FLAG_ABSORB;

    So in the specific case of FWP_ACTION_CALLOUT_TERMINATING, when BLOCK / PERMIT is set?

    Thursday, September 13, 2012 4:04 PM
  • This sounds like a service hardening rule.  just because you are allowing a packet (returning FWP_ACTION_PERMIT for CALLOUT_TERMINATING, or FWP_ACTION_CONTINUE for CALLOUT_INSPECTION) doesn't mean that action will necessarily be the final action.  In this case the traffic is blocked by the Windows Firewall Service hardening rule.  Your callout got it's say, but the BLOCK won the final decision.  You should read on the filter arbitration http://msdn.microsoft.com/en-us/library/windows/desktop/aa364008(v=vs.85).aspx.

    Hope this helps,


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

    • Marked as answer by OlivierMSDN Friday, September 14, 2012 11:42 AM
    Thursday, September 13, 2012 4:25 PM
    Moderator