locked
Unable to add simple filter for specific IP Remote Address RRS feed

  • Question

  • I have a question about adding a simple Filter while not in Kernel mode. The goal is to filter on a specific IP address.

     

    The code that I have so far, correctly adds the Filter to the BFE. (I am using the example application

    ms-help://MS.MSSDK.1033/MS.WinSDK.1033/FWP/fwp/using_windows_filtering_platform.htm

    as a basis)

     

    - The filter is applied to the 'FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4' layer

    - The match type is set to 'FWP_MATCH_EQUAL'

    - The Field Key is set to 'FWPM_CONDITION_IP_REMOTE_ADDRESS'

    - The action type is set to 'FWP_ACTION_BLOCK'

     

    The Filter Condition has been set to:

    - tcpCondition.conditionValue.type = FWP_V4_ADDR_MASK;

    - tcpCondition.conditionValue.v4AddrMask = &ipV4Mask;  where ipV4Mask represents the FWP_V4_ADDR_AND_MASK struct

     

    When the ipV4Mask.addr and ipV4Mask.mask are both set to 0x00 (catch all), everything appears to work as expected and all traffic is being filtered out.

     

    However, when I try to set the properties to a specific IP / Mask combination, the filter does not appear to be working. The filter is added to the BFE without any complaints, but traffic from the Remote Host is not filtered out.

     

    I have tried pretty much every concievable format for the IP address and Mask (realizing that the documentation says host order), ensuring that the IP - Mask pair is valid.

     

    What am I missing here?

     

    Thanks,

     

    Inq

     

     

     

     

    Friday, August 3, 2007 5:00 PM

Answers

  • Yes the REMOTE_ADDDRESS is the right condition to filter on for inbound traffic (i.e. the source address of the IP packet).

     

    So with REMOTE_ADDDRESS condition set to 192.168.0.0/255.255.255.0, an inbound packet with a source address say, 192.168.0.10, will be blocked.

     

    Biao.W.

     

    Friday, August 3, 2007 10:58 PM

All replies

  • Can you please print out the hex values of ipV4Mask.addr and ipV4Mask.mask here? Also please print out the IP header of the packet that came thru (as seen from a network sniff)?

     

    Also was the filter added with your own sublayer?

     

    Biao.W.

     

    Friday, August 3, 2007 7:23 PM
  •  

    I generated my own Sublayer, using an arbitrary Guid (UuidCreate). Does that matter in any way? The Sublayer and Filter are added without problems. I can filter protocols fine and when I use 0x00 for the subnet mask, the filter does block traffic as well.

     

    I have used both 'FWPM_LAYER_INBOUND_IPPACKET_V4' and 'FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4' as layers to apply the filter. Both work as expected when 0x00 is used.

     

     

    The IP Addresses that I have used are build up as follows:

     

    127.0.0.1  =>  0x0100007F and 0x7F000001 (I tried both ways, just in case...)

     

    I have installed a loopback adapter (192.168.0.50) and tried some internet addresses as well this way.

     

    The subnet masks I have used are build up as follows:

     

    255.255.255.0  =>  0xFFFFFF00  (a reversed order, as expected per documentation is not accepted).

     

     

    Friday, August 3, 2007 7:47 PM
  • You address/mask will need to match the source address of an IP packet, which would not be 127.0.0.x. It would be 192.168.0.x in your case. You can verify this from a network sniff (e.g. netmon).

     

    Thanks,

    Biao.W.

    Friday, August 3, 2007 9:34 PM
  •  

    The 127.0.0.1 address was merely for illustrative purposes. Anyways... with a little fiddling with Netmon 3.1, and some more experimenting I have the following:

     

    I changed my fieldkey to:

     

    blockFilter.layerkey = FWPM_LAYER_INBOUND_IPPACKET_V4

    tcpCondition.fieldKey = FWPM_CONDITION_IP_LOCAL_ADDRESS;

     

    ipV4Mask.addr = 0xC0A80014;  (Which translates to 192.168.0.20, which is my network adapter)

    ipV4Mask.mask = 0xFFFFFF00;  (Which is the appropriate subnet mask)

     

     

    With these settings, the filter successfully blocks traffic. This is not really how I initially envisioned this to work. I guess I overlooked the fact that I (192.168.0.20) established the connection from my PC, so my IP address is the source on inbound packages?

     

     

    The ultimate goal is to block a request coming from 192.168.0.21 / 255.255.255.0. I assume that this can then be done using the 'FWPM_CONDITION_IP_REMOTE_ADDRESS' in combination with that address / subnet mask? At that point the other PC must establish the connection, for it to be effectively blocked. Correct?

     

    Inq.

     

     

    Friday, August 3, 2007 10:11 PM
  • Yes the REMOTE_ADDDRESS is the right condition to filter on for inbound traffic (i.e. the source address of the IP packet).

     

    So with REMOTE_ADDDRESS condition set to 192.168.0.0/255.255.255.0, an inbound packet with a source address say, 192.168.0.10, will be blocked.

     

    Biao.W.

     

    Friday, August 3, 2007 10:58 PM