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

The values are being zeroed on reauth during FwpsOperationComplete0. The initial indication appears to have been correct.

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.

Just a note -- a fix for this issue should be included in WS08 RC1 (and the corresponding SP1 release).

Biao.W.