locked
Windows Server 2008 Bridged WFP filters only traffic generated locally - will not filter traffic running across the bridge RRS feed

  • Question

  • I have a Server 2008 setup with two nic's bridged.  I have a test pc plugged into one nic and the other goes to the rest of the network (and the internet).

    Here's what I think are the application code snippets -

    //Essentially an empty layer to put our filters in
    SubLayer.displayData.name = FIREWALL_SUBLAYER_NAMEW;
    SubLayer.displayData.description = FIREWALL_SUBLAYER_NAMEW;
    SubLayer.flags = 0;
    SubLayer.weight = 0x100;

    result = ::FwpmSubLayerAdd0( m_hEngineHandle,&SubLayer,NULL );

    //IP address and mask to block
    FWP_V4_ADDR_AND_MASK AddrAndMask = {0};
    AddrAndMask.addr = itFilters->AddrToBlock.addr;
    AddrAndMask.mask = itFilters->AddrToBlock.mask;

    FWPM_FILTER_CONDITION0 Condition = {0};
    Condition.fieldKey = FWPM_CONDITION_IP_REMOTE_ADDRESS;
    Condition.matchType = FWP_MATCH_EQUAL;
    Condition.conditionValue.type = FWP_V4_ADDR_MASK;
    Condition.conditionValue.v4AddrMask = &AddrAndMask;

    //Put the filter in our sublayer.  Filter the Stream (Traffic generated by URL is also filterered)
    FWPM_FILTER0 Filter = {0};
    Filter.subLayerKey = m_subLayerGUID;
    Filter.displayData.name = FIREWALL_SERVICE_NAMEW;
    Filter.layerKey = FWPM_LAYER_STREAM_V4;
    Filter.action.type = FWP_ACTION_BLOCK;
    Filter.weight.type = FWP_EMPTY;
    Filter.filterCondition = &Condition;
    Filter.numFilterConditions = 1;
    result = ::FwpmFilterAdd0( m_hEngineHandle, &Filter,NULL, &(itFilters->FilterId) );

    What happens after starting the firewall is - any traffic I generate using IE on the server to the blocked IP is blocked.
    Traffic generated on the test PC is completely unaffected.
    Why isn't WFP filtering ALL of the traffic?

    Tuesday, February 9, 2010 7:01 PM

Answers

  • The traffic from the test machine will not hit the stream layer of the server on its way to the internet destination.

    The reason for this is that bridging is an OSI Model Layer 2 function.  The bridging machine knows from the MAC addressing that the frame is not meant for it, so it doesn't need to parse any further headers, and just bridges the packet out it's other interface.

    If you moved to a routing mechanism (OSI Model Layer 3), then you will definately be invoked at the IP_FORWARD layer.  Again though the machine realizes the packet is not destined for it, so it will not parse any further headers.  It would consult it's route table, create a new MAC header, and send the packet out the determined interface.

    In the OSI Model, Stream would relate most to layers 5-7.

    Hope this helps




    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, February 10, 2010 6:12 PM
    Moderator