ALE_AUTH_CONNECT UDP indications with remote address/port of 0.0.0.0:0
I am testing my WFP-based firewall code on Windows Server 2008 RC0, to test the code paths I added while working around bugs in Vista RTM, for the case where a bug is fixed in SP1 there is a code path which will only happen on SP1.
One of the bugs that I had to work around related to out-of-band inspection of UDP packets at the ALE_AUTH_CONNECT and/or ALE_AUTH_RECV_ACCEPT layers. This seems to be working properly on Windows Server 2008 RC0, as it did on Beta 3, which is good.
However, now that I can see the UDP information in usermode, I am beginning to notice some odd behavior. Some outgoing UDP packets (which are indicated to the ALE_AUTH_CONNECT layer) have the remote ip address and port zeroed out. So far, I have only seen this on packets originating from svchost.exe, which have a proper local ip address and port, and they either have a local port of 68 (which is bootpc, which means it is from the DHCP client), or a high-port which appears dynamically assigned (41219, 41221, 49225, 49228).
Is there some known reason why these fields would be zero sometimes? Is this a bug? Is there any additional information I can give to help you diagnose this?
Thanks,
Jeremy
Can you double check your are indexing into these fields?
FWPS_FIELD_ALE_AUTH_CONNECT_V4_IP_REMOTE_ADDRESS (6)
FWPS_FIELD_ALE_AUTH_CONNECT_V4_IP_REMOTE_PORT (7)
DHCP broadcasts should have local address 0.0.0.0 (i.e. unspecified address) and local port 68. It is odd to have 0.0.0.0:0 as dest addr/port.
Can you also use netmon to see if there are packets being sent like that?
Biao.W.
I am seeing this same information in two different callouts, which return proper information both for other UDP and for TCP packets.
I checked using netmon, and the packets are not showing up there.
I would expect that you could just write a simple callout that uses KdPrint to log the fields, boot up the machine (the packets are most prolific at boot), and see them. I have not tried it, but I would expect that to show it. Is there a sample like this in the WDK?
I can confirm that this is a bug. Thanks for reporting.
The bug manifests in the following condidtions --
1) Global broadcast or subnet broadcast traffic being indicated to ALE_AUTH_CONNECT
2) classifyFn is pended/completed via FwpsPendOperation0/FwpsCompleteOperation0
3) During FwpsCompleteOperation0- triggered re-auth the remote address/port is incorrectly set to 0.0.0.0:0 for IPv4 and [::]:0 for IPv6.
We are investigating a fix to this issue.
Biao.W.
