locked
filtering closed UDP ports RRS feed

  • Question

  • Hello,

     sorry to open new thread where similar threads already exist, but nobody is answering my questions there.

     I need to filter incoming TCP and UDP connections to ports where no local application is listening (filtering here means to not send TCP RST or ICMP Port Unreachable responses), and also to log these filtered connections. For TCP I can use an INBOUND_TRANSPORT_DISCARD callout to do this, and it works well. For UDP however, I have to use an INBOUND_IPPACKET_DISCARD callout, and here comes the problem. I need to know the UDP ports, but the layer is too low-level (IPPACKET), so I need to parse the UDP header myself. This would be easy, but the problem is that the data offset is said to be variable in this callout. I am only interested in the case when discard reason is IpDiscardPortUnreachable. From my experiments it seems that in this case the data offset position is always at the beginning of UDP header (after the IP header). But it is not documented (or is it?). So can I rely on this? Or is it possible to handle the variable offset in some reliable way? Iow, how can I reliably find the UDP header, when the offset is not known?

    Thanks in advance for Your answer,

    Ron
    Friday, November 6, 2009 9:41 AM

Answers

  • No -- no reliable way to achieve this on Vista/WS08.

    Anyway to answer your original question -- yes for IpDiscardPortUnreachable you can assume the the packet begins with Transport Header (e.g. UDP header).

    I'll request our doc writer to document this (as well as the doc issue you mentioned above).

    Thanks,
    Biao.W.

    Wednesday, December 2, 2009 7:35 PM

All replies

  • Yes you can assume the UDP header (8 bytes) is available after the IP header at  INBOUND_IPPACKET_DISCARD when the discard reason is IpDiscardPortUnreachable.

    thanks,
    Biao.W.
    Saturday, November 7, 2009 5:35 AM
  • Thanks, but this was not exactly what I was asking. I know that the UDP header is after the IP header. The problem is the current data offset at the time when the callout is called.
    Monday, November 9, 2009 7:34 AM
  • HI Ron,

    Can you please explain why INBOUND_TRANSPORT_DISCARD (w/ InetDiscardEndpointNotFound) didn't work for you for UDP?

    thanks,
    Biao.W.
    Friday, November 13, 2009 11:03 PM
  • Hi Biao,

    sorry for the delay, I have been away from internet for the last two weeks.

    The INBOUND_TRANSPORT _DISCARD callout is not used for UDP according to documentation, see here:

      http://msdn.microsoft.com/en-us/library/bb451831%28VS.85%29.aspx

    Also, it was confirmed by You in the forum, see here:

      http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/c53e6121-443d-4e67-ad51-2d240186fd7b

    Ron
    Monday, November 30, 2009 11:06 AM
  • Hi, my comments were meant to point out one cannot use INBOUND_TRANSPORT _DISCARD to effect whether ICMP errors are being sent or not -- discarded packets should still be classified there (e.g. for error logging). 

    Do you need to control whether ICMP errors gets sent?

    Thanks,
    Biao.W. 
    Monday, November 30, 2009 8:03 PM
  • Yes, exactly. What I need exactly, is to allow or drop the outgoing ICMP error, and do the decision based on the UDP ports. Sorry for not stating this clearly before.

    Btw, if INBOUND_TRANSPORT _DISCARD is really used also for UDP packets, the documentation which I linked (UDP packet flows) should be updated to mention it, shouldn't it?

    Ron
    Tuesday, December 1, 2009 9:07 AM
  • Ok in that case you will have to register at the INBOUND_IPPACKET_DISCARD layer.

    However in Windows 7 it will still be useful to register at INBOUND_TRANSPORT_DISCARD as well. From there you could "tag" the port number to the packet using the new packet tagging api and retrieve it back from INBOUND_IPPACKET_DISCARD layer -- that way you don't need to parse packets to retrieve the port.

    Does your project need to run on Vista/WS08?

    Thanks,
    Biao.W. 

    Wednesday, December 2, 2009 2:02 AM
  • Does your project need to run on Vista/WS08?

    Yes, it does, unfortunately. Is there some reasonable way to do it for these systems too?
    Wednesday, December 2, 2009 10:07 AM
  • No -- no reliable way to achieve this on Vista/WS08.

    Anyway to answer your original question -- yes for IpDiscardPortUnreachable you can assume the the packet begins with Transport Header (e.g. UDP header).

    I'll request our doc writer to document this (as well as the doc issue you mentioned above).

    Thanks,
    Biao.W.

    Wednesday, December 2, 2009 7:35 PM
  • No -- no reliable way to achieve this on Vista/WS08.

    Anyway to answer your original question -- yes for IpDiscardPortUnreachable you can assume the the packet begins with Transport Header (e.g. UDP header).

    Thanks. If I understand correctly, "packet begins with Transport Header" means that the data offset is set to the beginning of the Transport Header (THAT was my original question), doesn't it?.  If that's the case, then I can parse the headers manually (UDP header directly, and also IP header using NdisRetreatNetBufferDataStart). And I think thats a good and reliable way to achieve my goal, isn't it?

    Thanks,
    Ron
    Thursday, December 3, 2009 7:57 AM
  • Yes.
    Friday, December 4, 2009 2:03 AM
  • OK, thank You very much for Your help, Biao.
    Friday, December 4, 2009 7:49 AM