Hm-m, finally get answers (I was thinking you are ignoring my messages advisedly).
adrien wrote:1. PureSight
The Puresight update issue should be solved with v3. I think it would be a lot more productive to debug issues relating to seeing PureSight 3 in your WWW proxy, than to try to debug issues with an older version not updating. Normally the refresh button in the plugins pane in the WWW proxy should make PureSight show up. There are a few steps we can go through to get it working - there aren't many links in the chain to break.
Ok, what do you want me to do?
I remind you, that from the beginning I installed PS v3 but it could not be picked up by proxies, and I had to replace it by PS v2 and it helped.
Should I try to upgrade PS v2 it to v3? If yes with or without uninstalling the previous version?
Do I need a new activation secrets for v3? (When in the past I used mine it activated ok, but just could not be picked up by proxies).
Instruct me.
adrien wrote:2. Download Managers / resume.
This is due to having Kaspersky AV installed. Because Kaspersky AV cannot guarantee the safety of any file that it doesn't see the whole of, it forbids files to be downloaded in parts. Downloading files in parts is what download managers do. If you create a whitelist entry in Kaspersky AV to bypass scanning for the particular site or URL, you can re-enable downloading in parts for that site/url.
Adrien, please read carefully what I have written:
2. Download managers do not support resume when downloading via proxy. Both KAV and PS have the required site (e.g. symantec.com) exclusion (site-wide, not single url)!
While downloading via pure NAT (no interception by proxy) everything works fine.
The issue is still unsolved.
I am downloading updates from here:
http://www.symantec.com/business/security_response/definitions/download/detail.jsp?gid=savce, the download url example is:
http://definitions.symantec.com/defs/20100322-004-x86.exe.
Meanwhile "symantec.com" is in site-wide exclusions for both KAV and PS!
adrien wrote:3. DNS avalanche.
Question - do you have the cache enabled in the DNS resolver? We've found problems with certain types of lookups (following CNAME records and delegation) if caching is disabled. It can cause a lot of lookups.
The DNS cache was
enabled from the first day and the option have never been changed.
I am drawing your attention again on the fact:
...the problem is appearing when ISP's DNS server ip is set in Wingate machine's WAN TCP\IP properties (OS settings)...
And it disappears as soon as I remove ISP's DNS server ip from the machine WAN interface TCP\IP properties (I still have it also specified in DNS resolver settings).
This is the general fact you should pay attention on!
adrien wrote:what's the IP of your ISP DNS server? We may need to try to test against it.
It is useless to know as it is from the ISP's local subnetwork and is private address (192.168.65.25). (And that's the reason I am not using antispoofing option).
adrien wrote:An alternative could be to use an intermediate DNS server (say that you host yourself) to buffer between WinGate DNS resolver and the DNS server of your ISP.
I have Wingate DNS server enabled and I have ISP's DNS, why should I add one more point of failure? I'll prefer to keep working without specifying ISP's DNS ip on WAN TCP\IP settings, this is not critical for us (just losing direct Internet connection possibility from the Wingate machine, but it is a server and not meant to be used that way).
However, I think the problem is critical for you as it totaly prevents Wingate from functioning and I would like to know why it becomes crazy...
adrien wrote:4. DNS service log vs DNS resolver log.
DNS service log only logs requests received from client machines that make DNS lookups. If they are set to use proxy, they won't use DNS for web surfing.
DNS resolver (DNS Client) logs everything to do with DNS for entire WinGate, so the WWW proxy looking up the site to connect to for the client. So the DNS client is always a lot more busy than the DNS server.
Clients will do DNS lookups if they think they need to resolve a name to an IP to connect to. If they are set to use proxy, and you specify the proxy by IP, then web browsers won't need to make any DNS lookups. Other apps may still want to look up names. For NAT, the client thinks it is connecting directly to the end server, so needs to resolve the name with DNS. This also is the case for SOCKS, and the WinGate client.
Ok, resuming:
in case of Wingate NAT, WGIC and SOCKS clients set up to use Wingate DNS server - the clients make DNS requests to Wingate DNS server (and the latter, in his turn, asks DNS Resolver to make request to ISP's DNS), while in case of Wingate proxy users only proxy server itself is making DNS requests and, as it is located on the same machine, it asks directly DNS Resolver to make DNS requests to ISP's DNS server.
Absolutely clear now. All is as I have supposed:
As 95% of my users use Proxy, I had a thought the DNS Resolver works always, while DNS service - only for NAT users!? (I mean DNS requests for site names requested via Wingate proxies are done directly by the resolver...). Is this the case?
But again, you should add such information to the help. It could be usefull to know how your stuff works when troubleshooting or setting up the product.