the best method to debug such issues is to take a NetMon trace at the ISA internal interface. Analyzing those traces and match them with the ISA logs should reveal what is the cause of your problems with Windows Update.
What happens if you create an all open protocol (all IP traffic, any request) and site&content (all destinations, any content, any request) rule?
According to my and Jim's testing it should work as long as no authenticated rules are used for the Windows Update sites.
Posts: 49
Joined: 7.May2001
From: US
Status: offline
Stefaan,
Did your testing include a default gateway on the client? If I put the default gateway on a client that has the firewall client - it will run but without it - it will fail.
Jason
[ September 13, 2004, 10:20 PM: Message edited by: Jason ]
If the Firewall client is working correctly, it doesn't matter at all for UDP/TCP based protocols if the client is also a SecureNAT. To understand why, reread my post on September 04, 2004 11:16 AM in this topic.
The Firewall client will not redirect a TCP/UDP request if: - the destination is on the LAT on ISA. - the destination is on the 'locallat.txt' file in the Firewall client directory on the client. - the application is disabled in the Firewall client settings on ISA.
Posts: 49
Joined: 7.May2001
From: US
Status: offline
Hey Stefaan,
Its definitely possible that its in one of those but I really dont see anything wrong. I presume the firewall client is working as thats all thats on these machines - the proxy info is not in IE, there is no default gateway, and the firewall client is installed. So I presume it has to be working correctly as this is really the only problem I have been seeing.
For the LAT on ISA I have these: 10.0.0.0 - 10.255.255.255, 169.254.0.0 - 169.254.255.255, 172.16.0.0 - 172.31.255.255, and my local subnet 192.168.0.0 - 192.168.0.255
LOCALLAT.TXT file is not present on my system.
I dont see anything related to Windows Update being disabled in the firewall client settings on ISA but not exactly sure on the executable name?
the LAT on ISA should only contain your internal IP range; nothing more, nothing less! Assuming your internal network is 192.168.0.0/24 then the LAT should only contain the single entry '192.168.0.0 - 192.168.0.255'.
OK, I suggest you do the following: - go to http://www.isatools.org and download the script 'ISAInfo for ISA 2000' - run it on your ISA server - post here the URL where we can view the result
Posts: 49
Joined: 7.May2001
From: US
Status: offline
Hey Stefaan,
How bout I give you some directions to reproduce it? Microsoft called me today and I was able to get them to reproduce it and then a little bit later they called back and basically said that their work arounds will not fix it the way I have ISA deployed - which is just the firewall client with no default gateway and no web proxy info set.
To reproduce it - take away the default gateway, have the firewall client deployed, and have no proxy info set. Then for whatever reason, you have to reboot to see the error (MS guy would try it after taking out the default gateway but it would still work until the reboot). Once rebooted you should get the error on Windows Update.
On a worse note, they basically said to either deploy an SUS server or pass out the default gateway. They also said that they are not considering this high priority and thus a fix will not be coming for a long while. Gotta love that!
Anyways, since I could get them to reproduce it - I dont think its my config but if that is not reproducable on your end - let me know and I will get the config to you.
Nevertheless, I made another test and saw something unexpected. In IE I disabled all proxy settings and rebooted the workstation. Then I started Ethereal (excellent network sniffer) and Windows Update. As expected, all IE requests are properly handled by the Firewall client. So far so good. However, at a certain point I saw the Web Proxy Autodiscovery procedure happening. Why?
After further analyzing, it seems that the Microsoft WU client v2.0 uses his own methods to discover a Web Proxy server. Because wpad is defined at my end, those requests were send to the Web Proxy service. I expected that the WU client would pick-up the proxy settings from IE but that's clearly not the case.
Therefore, it could well be that the Microsoft WU client v2.0 doesn't use the normal WinSock API. In that case I suspect that the Firewall client never see those requests and then the client must be a SecureNAT client too.
BTW --- why do you not configure all the clients as Web Proxy *and* Firewall clients?
Posts: 49
Joined: 7.May2001
From: US
Status: offline
Stefaan,
Thanks for looking into it further - I believe what you are describing is essentially what is happening.
My problem with making the clients both web and firewall clients is teaching the users another thing to shut off when on the road. Its not a huge operation but one that would cause some problems for users until they got used to it.
Really it should work and since they have admitted that its a bug - they should fix it. They say they plan on it but no specific time frame and they dont consider it a high priority so it probably wont be very quick.
So I guess in my case - besides changing either the clients or installing a WUS server - it just wont work until they fix it. My main reason for posting was that everyone else seemed to be getting by with the workarounds but I never could but it looks like its the clients not the config of the server.
I was also told by them that ISA 2004 with only the firewall client installed and no other client installed it will work - which I find odd as they say the problem isnt with ISA but the windows update control - so im kind of wondering why 04 will work but 00 wont?
Anyways - I appreciate all the help - you da man! J
I work always with autodiscovery (wpad DNS method) for Firewall and Web Proxy client. In that case nothing should be changed or disabled when off-site.
quote:I was also told by them that ISA 2004 with only the firewall client installed and no other client installed it will work.