[gmt]

Thanks for your thoughts SerpentFly.

[gmt]

Any ideas anybody ?

The facts were presented in my last post. I can reproduce the behavior with the piece of code posted. Is there a way to handle some packets with PACKET_REDIRECT (based on some filters) and for the rest to have a default rule that says PACKET_PASS, so that I don’t receive in user mode traffic I’m not interested in ?

-Ghita

[gmt]

“What I find strange is that even if I have set as priority rules, a rule that blocks all tcp and one all udp traffic I still “catch” netbios(port 137, broadcast) and link local multicast resolution (port 5355) traffic on my last filter rule (the rule that says to inspect – FILTER_PACKET_REDIRECT)”

I come with new information about my findings. I simplified my used filters and have following conclusions:

1. In our application packets that don’t have to be allowed/blocked/intercepted by using our custom nt kernel filters have to be allowed to pass without interception (we **don’t** need them to be passed into user mode at all)

2. what I’ve observed is that any packet that doesn’t match a specific filter seem to be intercepted by default by ntkernel (passed to user mode). Is this true ?

3. In case 2 is true how do I define a “default” filter rule so that all non matched (by more priority filters) traffic gets allowed(FILTER_PACKET_PASS) and not intercepted(FILTER_PACKET_REDIRECT) ? We use now what’s bellow but seems to not match all (remaining) traffic:

        STATIC_FILTER result = {0};

result.m_Adapter.QuadPart = 0;

result.m_ValidFields = 0;

result.m_FilterAction = FILTER_PACKET_PASS;

result.m_dwDirectionFlags = PACKET_FLAG_ON_SEND | PACKET_FLAG_ON_RECEIVE;

return result;

As you can see I use m_Adapter set to 0 in hope that default will be allow traffic for all network interfaces.

Any hints are appreciated.
Thanks
-Ghita

[gmt]

Thanks for the response SerpentFly.
I’ll have to evaluate in this case what rule we apply exactly, because the intent was in the manifesting case for all Tcp/Udp packets regardless of IP-s to be applied (allowed, FILTER_PACKET_PASS) but instead the same rule (same fields, except action field) applied only for FILTER_PACKET_REDIRECT

Regards
-Ghita

[gmt]

Hi, I am one of the “guys” involved in the original issue described here. One of the problems why dns traffic was being affected (blocked) was because we tried adding first some blocking rules that were supposed to affect only a certain types of traffic (say it only tcp or udp) but the FILTER_TABLE filters were not configured corectly for tcp/udp (they were catching other non tcp/udp protocols – arp… etc.)

[Author]

Posts