locked
Filtering on IP Protocol at FWPM_LAYER_OUTBOUND_IPPACKET_V4/V6 RRS feed

  • Question

  • I want to inspect outbound TCP packets. At first, I thought I could do this

    by adding a callout  for FWPM_LAYER_OUTBOUND_TRANSPORT_Vx and add a filter

    for FWPM_CONDITION_IP_PROTOCOL == IPPROTO_TCP. Unfortunately, I also need to
    inspect the IP header for the outbound TCP packet and that is not available

    at that layer (FWPS_INCOMING_METADATA_VALUES0.ipHeaderSize always is
    0).

    So, I set up my callback to be at FWPM_LAYER_OUTBOUND_IPPACKET_V4 but
    the
    FWPM_CONDITION_IP_PROTOCOL condition is not allowed at that layer. So,
    it
    looks like I'll need to walk the packet to determine the IP protocol (and

    the TCP SPORT/DPORT values, which I also need to inspect).

    I don't
    understand why FWPM_CONDITION_IP_PROTOCOL is not allowed at the
    network
    layer, but that's moot. Does anyone have a better solution than
    walking the
    packet to get the IP protocol value?

    Thanks!
    Wednesday, January 30, 2013 6:37 PM

Answers

  • Not sure why you need to inspect the IP Header as well.  most of that information is also available @ TRANSPORT ( in the incoming Values).  Anyhow, the protocol is an L4 concept, so it is readily available @ TRANSPORT and not @ IPPACKET and IPFORWARD.  Parsing the packet is the best way to get this information, unless you put in the extra effort of something like associating a flow context.  By associating a flow context, you can easily identify the packets you wish to deeply inspect.

    Hope this helps,


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

    Thursday, January 31, 2013 6:48 PM
    Moderator

All replies

  • Not sure why you need to inspect the IP Header as well.  most of that information is also available @ TRANSPORT ( in the incoming Values).  Anyhow, the protocol is an L4 concept, so it is readily available @ TRANSPORT and not @ IPPACKET and IPFORWARD.  Parsing the packet is the best way to get this information, unless you put in the extra effort of something like associating a flow context.  By associating a flow context, you can easily identify the packets you wish to deeply inspect.

    Hope this helps,


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

    Thursday, January 31, 2013 6:48 PM
    Moderator
  • Thanks, Dusty!

    Associating a flow context is a great idea and I'll look into it. The reason I need the IP header is that I need under certain situations to return the L3/L4 data to my service.

    Thursday, January 31, 2013 9:14 PM