TDI packet redirect driver conflict Anti-vir web filter driver

Hi!

Why is it that if I have a TDI package redirector driver which redirect TCP and UDP traffic in local proxy. When I install a anti-virus software (AVG, Avast etc?) and turn on the ?Web Filter? function no longer receive packages from my driver. Is it possible that my drivers and drivers of the anti-virus can operate at the same time? If not then how to solve that my drivers works and drivers of the antivirus can not work?

Thanks!

TDI filters do not work on Vista+, since lots of TCP/IP traffic is done by means other then TDI.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi!
>
> Why is it that if I have a TDI package redirector driver which redirect TCP and UDP traffic in local proxy. When I install a anti-virus software (AVG, Avast etc?) and turn on the ?Web Filter? function no longer receive packages from my driver. Is it possible that my drivers and drivers of the anti-virus can operate at the same time? If not then how to solve that my drivers works and drivers of the antivirus can not work?
>
> Thanks!
>
>

The only thing I can say here is “Where is Chris”…

Anton Bassov

Although this phenomenon also for XP. There are literally Netfilter SDK driver. If there is no anti-virus Web filter driver is perfectly work on all Windows. Both of the driver is under the PNP-TDI group. What determines which driver performs the redirect?

Hi!

Getting a TDI driver that does ‘proxy redirection’ to work correctly with FW
vendors that are doing the same thing is very challenging. It requires a
significant investment in figuring out what the ‘other guy’ is doing and
finessing the filtering order and processing scheme so that your proxy does
not get confused by or confuse the proxy setup by the FW screen.

There is no ‘answer’ to your problem. Only rather heuristic and often
limited solutions.

The first thing to try is to move your driver in the load order so that it
is the last to load before TCPIP (in other words, you get the IRP first and
then the modified IRP goes to the FW). See if that works. Keep in mind
then that the FW will see all traffic you proxy as if it came from your
proxy service not from the original application. So the FW will not be able
to apply policy correctly. Often this is a big deal for customers whom
have decided to use such a FW configuration. Depending on the purpose of
your proxy, you may or may not win the argument that your proxy should get
the first crack at the TDI_CONNECT.

Good Luck,
Dave Cattley

anton bassov wrote:

The only thing I can say here is “Where is Chris”…

Seems as though, one who sticks one’s fingers in his ears, should not expect to hear anything afterward…