NOD32 v3 + CPF v3 = No firewall warning (sorta)[HELP]

I have CPF3 alert frequency [ at ] very high. I also have defense+ in paranoid mode. I’m running the latest 268 build.

NOD32 monitors web traffic (port 80, 8080, etc…) for viruses, trojans, and other malware. Here is where the problem is:

When an application attempts to contact the Internet, D+ first reports that the application is attempting to access the DNS Client Service directly. After allowing that, when the application attempts to reach an Internet IP address on the web ports, the firewall reports that ekrn.exe (a NOD32 service) is the application wanting access to the internet.

This makes it very hard to set up rules because they are all under ekrn.exe. Whereas I would like a web browser to reach pretty much any IP, I wouldn’t want my mail client to. Since both Thunderbird and Firefox show up through ekrn.exe, I can’t customize these applications individual access rules.

I’d rather not loose my bad guy detection system available through NOD32, and I didn’t have this problem with CPF v2. Suggestions?

Even if you allow ekrn.exe, won’t CFP ask again for the email client or such? CFP will use different rules for each app. I don’t think a program with narrow access will be able to bypass it just because it’s preceded by another app with wide access. (?)

No, CFP will not ask again for the email client (or any other application) if it uses any of the NOD32 monitored ports. It appears as if ekrn.exe acts as a type of proxy server that lies below the visibility of CFP. Any application which uses any of the NOD32 monitored ports appears to CPF as ekrn.exe.

Again, I didn’t have this problem with v.2.

If you really mean NOD32 v3 and NOT ESS v3, then ESET must have changed something here.
Running NOD32 v2.7, and no problems here.

Maybe allowing NOD32 Loopback and DNS Server in D+ rules would fix the problem?

Yes, NOD32 Antivirus v3.0.566.0.

I can confirm that disabling the HTTP filter in NOD32 stops the problem from happening, but then I loose realtime virus monitoring on Internet traffic. Comodo needs to monitor the applications before NOD32 does.

Eset added an Internal Proxi to NOD’s Web filtering, thus all HTTP and POP3 traffic is routed thru that internal proxi, I had the same problem during the betatesting of Comodo V3 and had to switch back to V2.7 of NOD, the problem persist with V3 Final of Comodo.