WinDivert passthru problem

[gilgil1973]

Hi, basil. I am gilgil. ;)
While making use of WinDivert dll, I met something unknown. Here is a test.

[Test Case 1]

While calling netdump command, I can see SYN/RST packets when I try to connect to 127.0.0.1:23.
netdump "tcp.SrcPort==23 tcp.DstPort==23"

While calling passthru command, I can not see any packets.
passthru "tcp.SrcPort==23 tcp.DstPort==23"

[Test Case 2]

Firefox application communicates with loopback(127.0.0.1) interface while application launches.

I can see the packets with netdump command.
netdump true

But I can not see any packets with passthru command.
passthru true 1

[Test Enviromnent]

Windows 7 Ultimate K
RAM 8G
Both WinDivert 1.1.2-rc and 1.1.1 has been tested.

[gilgil1973]

For more information, see the following urls.

http://www.gilgil.net/573380
http://www.youtube.com/watch?v=Vy7KV87qvn8

Thank you in advance. :)

[basil00]

Thanks for the report. I can reproduce the problem and will try to find the exact cause.

[hobwekiva]

Uhm, I know I might have missed something, but is passthru supposed to write anything to the stdout? I added a small printf("packet"); between the Recv and Send in passthru.c and was able to see the packets.

[ffalcinelli]

I think the passthru.c code is just an example of how to intercept and reinject a packet with no modification in between, so if you make it print, well it prints :-)

[basil00]

"passthru" means do absolutely nothing other than divert the packets. It is useful for performance testing.

[basil00]

Also, I don't think gilgil means "see the packets" in the sense that passthru is not printing anything to the console.
(I've yet to find time to make progress on this issue. I think it may be caused by some subtleties regarding WFP and injecting loopback packets, but yet to confirm).

[TechnikEmpire]

I'm noticing issues when firefox starts up, getting 592 errors on WinDivertSend which causes firefox to have a very long startup. I have yet to dump information about the rejected packets but feel this might be a related issue. Only happens with FF.

[TechnikEmpire]

Not related after all, was brought here through search by the fact that firefox was involved. Something to watch out for, since WinDivert can grab loopback packets, is to make sure you're not diverting those packets somewhere else. My proxy application was taking those loopback packets generated by firefox and trying to send them out on the network, which isn't allowed, hence 592 and firefox long startup.

[basil00]

I never really figured out the cause of this issue anyway...
For a while I suspected it is related to this (although that is for the transport, not network, layer), but never found anything conclusive. It seems to suggest that you need to replace the 127.x.x.x IP address with a real interface address for some reason.

But otherwise @TechnikEmpire is right, WinDivert will capture loopback packets unless the filter explicitly forbids it.

[basil00]

WinDivert now considers loopback packets to be "outbound only", thus inbound loopback packets will be ignored. This should still be sufficient for filtering/modifiying loopback traffic, since each packet can still be captured on the outbound path. Previously the packet would be captured "twice", once for outbound then once for inbound.

This helps workaround this bug. For some reason, injecting loopback packets on the inbound path never really works, which appears to be a limitation of WFP and/or the Windows TCP/IP stack.