Need Help With IPs to Authorize Windows Update

[Will]

I'm having some problems with firewall authorizations for Windows Update
access in a DMZ. In general, I have had good luck getting access to
Windows Update when you authorize passage of HTTP, HTTPS, and FTP to these
networks:

131.107.0.0 / 16
207.46.0.0 / 16
64.4.0.0 / 18
65.52.0.0 / 14

In addition, I normally authorize these URLs for both http: and https:

*.microsoft.com
windowsupdate.microsoft.com
*.windowsupdate.microsoft.com
download.windowsupdate.com

The problem I am having is that occasionally the DNS name
"download.windowsupdate.com" resolves to some IPs on a huge network from the
Limelight load balancing farm. When the client behind the firewall
resolves that DNS to an IP, it then connects to the IP and the IP does NOT
reverse back to the DNS name download.windowsupdate.com. Instead it
resolves to some arbitrary name at the Limelight Network. So the firewall
has no way of knowing that the connection is authorized. Further
complicating all of this, download.windowsupdate.com does not always resolve
to the Limelight load balancers. Microsoft appears to have these IPs
pointing to load balancers all over the world. Some of the IPs I saw the
download.windowsupdate.com domain name resolve to:

208.111.148.50
8.12.217.124
192.78.223.126
209.84.2.124
etc

Microsoft provides a set of DNS names to use with the ISA firewall, and
naturally that doesn't work for the IPs above because they don't reverse to
Microsoft domain names.

No way do I want to authorize the entire Limelight load balancing network
into my DMZ. There are a huge number of IPs, and those are probably
associated with many hundreds of different organizations. When I do a
whois on the IPs Microsoft is using, nothing in the huge range of IPs
returned suggests which subset of the range is reserved for Microsoft use.

It would be really really nice for those of us who actually think about
security if Microsoft would publish openly the range of IPs it is using for
Windows Update. Failing that, I am open to ideas here about how can one
set up a reasonable set of firewall rules to securely connect to this
wideranging set of IPs.

--
Will

 

[S. Pidgorny]

I don't agree with the IP-based approach. There is no guarrantee that the IP
ranges won't change. Which is why Microsoft is using DNS names. If your
firewall isn't smart enough to deal with DNS names and initiating
processes - configure the Windows Update client as a bastion host and allow
connectivity to any IP address from it.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

"Will" wrote in message
news:bY2dnRgRl4YmmnvanZ2dnUVZ_qainZ2d@giganews.com...
> I'm having some problems with firewall authorizations for Windows Update
> access in a DMZ. In general, I have had good luck getting access to
> Windows Update when you authorize passage of HTTP, HTTPS, and FTP to these
> networks:
>
> 131.107.0.0 / 16
> 207.46.0.0 / 16
> 64.4.0.0 / 18
> 65.52.0.0 / 14
>
> In addition, I normally authorize these URLs for both http: and https:
>
> *.microsoft.com
> windowsupdate.microsoft.com
> *.windowsupdate.microsoft.com
> download.windowsupdate.com
>
> The problem I am having is that occasionally the DNS name
> "download.windowsupdate.com" resolves to some IPs on a huge network from
> the Limelight load balancing farm. When the client behind the firewall
> resolves that DNS to an IP, it then connects to the IP and the IP does NOT
> reverse back to the DNS name download.windowsupdate.com. Instead it
> resolves to some arbitrary name at the Limelight Network. So the
> firewall has no way of knowing that the connection is authorized.
> Further complicating all of this, download.windowsupdate.com does not
> always resolve to the Limelight load balancers. Microsoft appears to
> have these IPs pointing to load balancers all over the world. Some of
> the IPs I saw the download.windowsupdate.com domain name resolve to:
>
> 208.111.148.50
> 8.12.217.124
> 192.78.223.126
> 209.84.2.124
> etc
>
> Microsoft provides a set of DNS names to use with the ISA firewall, and
> naturally that doesn't work for the IPs above because they don't reverse
> to Microsoft domain names.
>
> No way do I want to authorize the entire Limelight load balancing network
> into my DMZ. There are a huge number of IPs, and those are probably
> associated with many hundreds of different organizations. When I do a
> whois on the IPs Microsoft is using, nothing in the huge range of IPs
> returned suggests which subset of the range is reserved for Microsoft use.
>
> It would be really really nice for those of us who actually think about
> security if Microsoft would publish openly the range of IPs it is using
> for Windows Update. Failing that, I am open to ideas here about how can
> one set up a reasonable set of firewall rules to securely connect to this
> wideranging set of IPs.
>
> --
> Will
>

 

[Will]

"S. Pidgorny " wrote in message
news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...
> I don't agree with the IP-based approach. There is no guarrantee that the
IP
> ranges won't change. Which is why Microsoft is using DNS names. If your
> firewall isn't smart enough to deal with DNS names and initiating
> processes - configure the Windows Update client as a bastion host and
allow
> connectivity to any IP address from it.

I agree to use DNS names, but this does not help me for many reasons:

1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names.

2) The point I am trying to make here is that Microsoft handed the
download.windowsupdate.com "host" to a bunch of different ISPs. When you
do the reverse DNS lookup on those IP addresses, they do NOT identify
themselves as being Microsoft related hosts.

The better solution might be to filter on the URL being passed by the
browser looking for download.windowsupdate.com. Some of our computers
that do not have firewall clients installed are passing the URL intact and
others are passing just the IP.

--
Will


> "Will" wrote in message
> news:bY2dnRgRl4YmmnvanZ2dnUVZ_qainZ2d@giganews.com...
> > I'm having some problems with firewall authorizations for Windows Update
> > access in a DMZ. In general, I have had good luck getting access to
> > Windows Update when you authorize passage of HTTP, HTTPS, and FTP to
these
> > networks:
> >
> > 131.107.0.0 / 16
> > 207.46.0.0 / 16
> > 64.4.0.0 / 18
> > 65.52.0.0 / 14
> >
> > In addition, I normally authorize these URLs for both http: and https:
> >
> > *.microsoft.com
> > windowsupdate.microsoft.com
> > *.windowsupdate.microsoft.com
> > download.windowsupdate.com
> >
> > The problem I am having is that occasionally the DNS name
> > "download.windowsupdate.com" resolves to some IPs on a huge network from
> > the Limelight load balancing farm. When the client behind the firewall
> > resolves that DNS to an IP, it then connects to the IP and the IP does
NOT
> > reverse back to the DNS name download.windowsupdate.com. Instead it
> > resolves to some arbitrary name at the Limelight Network. So the
> > firewall has no way of knowing that the connection is authorized.
> > Further complicating all of this, download.windowsupdate.com does not
> > always resolve to the Limelight load balancers. Microsoft appears to
> > have these IPs pointing to load balancers all over the world. Some of
> > the IPs I saw the download.windowsupdate.com domain name resolve to:
> >
> > 208.111.148.50
> > 8.12.217.124
> > 192.78.223.126
> > 209.84.2.124
> > etc
> >
> > Microsoft provides a set of DNS names to use with the ISA firewall, and
> > naturally that doesn't work for the IPs above because they don't reverse
> > to Microsoft domain names.
> >
> > No way do I want to authorize the entire Limelight load balancing
network
> > into my DMZ. There are a huge number of IPs, and those are probably
> > associated with many hundreds of different organizations. When I do a
> > whois on the IPs Microsoft is using, nothing in the huge range of IPs
> > returned suggests which subset of the range is reserved for Microsoft
use.
> >
> > It would be really really nice for those of us who actually think about
> > security if Microsoft would publish openly the range of IPs it is using
> > for Windows Update. Failing that, I am open to ideas here about how
can
> > one set up a reasonable set of firewall rules to securely connect to
this
> > wideranging set of IPs.
> >
> > --
> > Will
> >
>
>

 

[S. Pidgorny]

G'day,

One more reason to implement an internal update server:

http://technet.microsoft.com/en-us/wsus/

And the Windows Update hosts shouldn't identify themselves as Microsoft
hosts in rDNS, because they are not. The SSL cert is the ultimate
identifier.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

"Will" wrote in message
news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...
> "S. Pidgorny " wrote in message
> news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...
>> I don't agree with the IP-based approach. There is no guarrantee that the
> IP
>> ranges won't change. Which is why Microsoft is using DNS names. If your
>> firewall isn't smart enough to deal with DNS names and initiating
>> processes - configure the Windows Update client as a bastion host and
> allow
>> connectivity to any IP address from it.
>
> I agree to use DNS names, but this does not help me for many reasons:
>
> 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names.

>
> 2) The point I am trying to make here is that Microsoft handed the
> download.windowsupdate.com "host" to a bunch of different ISPs. When you
> do the reverse DNS lookup on those IP addresses, they do NOT identify
> themselves as being Microsoft related hosts.
>
> The better solution might be to filter on the URL being passed by the
> browser looking for download.windowsupdate.com. Some of our computers
> that do not have firewall clients installed are passing the URL intact and
> others are passing just the IP.
>
> --
> Will
>

 

[Phillip Windell]

"Will" wrote in message
news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...
> "S. Pidgorny " wrote in message
> news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...
>> I don't agree with the IP-based approach. There is no guarrantee that the
> IP
>> ranges won't change. Which is why Microsoft is using DNS names. If your
>> firewall isn't smart enough to deal with DNS names and initiating
>> processes - configure the Windows Update client as a bastion host and
> allow
>> connectivity to any IP address from it.
>
> I agree to use DNS names, but this does not help me for many reasons:
>
> 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names.

Is use ISA2006.
I use DNS Names.
I do not use IP#s.

I run Windows Updates and Microsoft Updates all the time to "catch up"
machines before I turn them over to WSUS.

>
> 2) The point I am trying to make here is that Microsoft handed the
> download.windowsupdate.com "host" to a bunch of different ISPs. When you
> do the reverse DNS lookup on those IP addresses, they do NOT identify
> themselves as being Microsoft related hosts.

Nothing does reverse lookups appearantly, so it wouldn't matter. I use it
all the time,...my Access Rule uses a Domain Name Set. The following Domain
will cover it all:
*.microsoft.com
*.windowsupdate.com
*. windows.com

There is a longer more detailed list if you want to be more picky and use
higher-level domain names (like "windowsupdate.microsoft.com"). I don't
have a link to the list.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1...07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesec...repartners.mspx
-----------------------------------------------------

 

[Will]

"S. Pidgorny " wrote in message
news:uQMMF$kjIHA.1744@TK2MSFTNGP05.phx.gbl...
> One more reason to implement an internal update server:
>
> http://technet.microsoft.com/en-us/wsus/
>
> And the Windows Update hosts shouldn't identify themselves as Microsoft
> hosts in rDNS, because they are not. The SSL cert is the ultimate
> identifier.

How do you implement a rule based on SSL in ISA 2006?

--
Will


> "Will" wrote in message
> news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...
> > "S. Pidgorny " wrote in message
> > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...
> >> I don't agree with the IP-based approach. There is no guarrantee that
the
> > IP
> >> ranges won't change. Which is why Microsoft is using DNS names. If your
> >> firewall isn't smart enough to deal with DNS names and initiating
> >> processes - configure the Windows Update client as a bastion host and
> > allow
> >> connectivity to any IP address from it.
> >
> > I agree to use DNS names, but this does not help me for many reasons:
> >
> > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names.

> >
> > 2) The point I am trying to make here is that Microsoft handed the
> > download.windowsupdate.com "host" to a bunch of different ISPs. When
you
> > do the reverse DNS lookup on those IP addresses, they do NOT identify
> > themselves as being Microsoft related hosts.
> >
> > The better solution might be to filter on the URL being passed by the
> > browser looking for download.windowsupdate.com. Some of our
computers
> > that do not have firewall clients installed are passing the URL intact
and
> > others are passing just the IP.
> >
> > --
> > Will

 

[Will]

"Phillip Windell" wrote in message
news:e%232w01ojIHA.4356@TK2MSFTNGP02.phx.gbl...
> "Will" wrote in message
> news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...
> > "S. Pidgorny " wrote in message
> > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...
> >> I don't agree with the IP-based approach. There is no guarrantee that
the
> > IP
> >> ranges won't change. Which is why Microsoft is using DNS names. If your
> >> firewall isn't smart enough to deal with DNS names and initiating
> >> processes - configure the Windows Update client as a bastion host and
> > allow
> >> connectivity to any IP address from it.
> >
> > I agree to use DNS names, but this does not help me for many reasons:
> >
> > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names.

>
> Is use ISA2006.
> I use DNS Names.
> I do not use IP#s.
>
> > 2) The point I am trying to make here is that Microsoft handed the
> > download.windowsupdate.com "host" to a bunch of different ISPs. When
you
> > do the reverse DNS lookup on those IP addresses, they do NOT identify
> > themselves as being Microsoft related hosts.
>
> Nothing does reverse lookups appearantly, so it wouldn't matter. I use it
> all the time,...my Access Rule uses a Domain Name Set. The following
Domain
> will cover it all:
> *.microsoft.com
> *.windowsupdate.com
> *. windows.com

I have that as well. For the affected firewall, the URLs are coming
across without domain names and only as IPs. So there is no DNS to compare
against. A reverse lookup on the IP won't get back to a Microsoft domain
for download.windowsupdate.com.

I guess I will have to force updates through web proxy in order to get it to
work.

--
Will

 

[Phillip Windell]

> I guess I will have to force updates through web proxy in order to get it
> to
> work.

I always use Web Proxy and Firewall [winsock] Service together. My LAN is
configured for auto-detection via WPAD and always has the Firewall Client
installed (except for some servers that are only Web Proxy/SecureNAT).

Once machines are caught up, it is all handled by WSUS. With the number of
machines on the LAN I don't want the same patches/SPs downloading over and
over and over again for every client. It would kill our bandwidth.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1...07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesec...repartners.mspx
-----------------------------------------------------

 

[Will]

"Phillip Windell" wrote in message
news:eQIYMTqjIHA.3780@TK2MSFTNGP06.phx.gbl...
> > I guess I will have to force updates through web proxy in order to get
it
> > to
> > work.
>
> I always use Web Proxy and Firewall [winsock] Service together. My LAN is
> configured for auto-detection via WPAD and always has the Firewall Client
> installed (except for some servers that are only Web Proxy/SecureNAT).

I have never been able to get WPAD to work. I point our DNS with an A DNS
host record for WPAD to the ISA Server IP on the Internal network. But
the browsers on clients never seem to autoconfigure.

Is there a firewall rule required on ISA in order to have autoconfigure
functionality work?

--
Will

> The views expressed, are my own and not those of my employer, or
Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/ISA2004_AccessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
>
http://download.microsoft.com/download/9/1...07/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.mspx
>
> Microsoft ISA Server Partners: Partner Hardware Solutions
>
http://www.microsoft.com/forefront/edgesec...repartners.mspx
> -----------------------------------------------------
>
>

 

[S. Pidgorny]

I really don't know. I have become a firewall sceptic a while ago.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

"Will" wrote in message
newsbadnWhiFJQGp3TanZ2dnUVZ_ternZ2d@giganews.com...
> "S. Pidgorny " wrote in message
> news:uQMMF$kjIHA.1744@TK2MSFTNGP05.phx.gbl...
>> One more reason to implement an internal update server:
>>
>> http://technet.microsoft.com/en-us/wsus/
>>
>> And the Windows Update hosts shouldn't identify themselves as Microsoft
>> hosts in rDNS, because they are not. The SSL cert is the ultimate
>> identifier.
>
> How do you implement a rule based on SSL in ISA 2006?
>
> --
> Will
>
>
>> "Will" wrote in message
>> news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...
>> > "S. Pidgorny " wrote in message
>> > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...
>> >> I don't agree with the IP-based approach. There is no guarrantee that
> the
>> > IP
>> >> ranges won't change. Which is why Microsoft is using DNS names. If
>> >> your
>> >> firewall isn't smart enough to deal with DNS names and initiating
>> >> processes - configure the Windows Update client as a bastion host and
>> > allow
>> >> connectivity to any IP address from it.
>> >
>> > I agree to use DNS names, but this does not help me for many reasons:
>> >
>> > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names.

>> >
>> > 2) The point I am trying to make here is that Microsoft handed the
>> > download.windowsupdate.com "host" to a bunch of different ISPs. When
> you
>> > do the reverse DNS lookup on those IP addresses, they do NOT identify
>> > themselves as being Microsoft related hosts.
>> >
>> > The better solution might be to filter on the URL being passed by the
>> > browser looking for download.windowsupdate.com. Some of our
> computers
>> > that do not have firewall clients installed are passing the URL intact
> and
>> > others are passing just the IP.
>> >
>> > --
>> > Will
>
>

 

[Phillip Windell]

You'll want to do it in both DNS and DHCP. Some client will receive it
better with DHCP others will receive it better with DNS,...so you want both.

Start with DNS, remove the A Record from your earlier attempt and create a
CNAME entry for "wpad" that points to the "A" Record of the ISA that would
already exist. Maybe not all documents will tell you to do it with the
CNAME like that,...but I am. One reason for that is that you can easily
move uses from one proxy to another by simply changing what A Record the
CNAME points to and you will litterally have no other configuration to
change. It is also the "clean" way to work with DNS because it eliminates
having more than one record pointing to the same IP#.

Then in DHCP create the "Option 252 wpad".
When you create the URL value you will use the earlier CNAME from the DNS to
build it
(http://wpad.ad-domain.local/wpad.dat)

On the ISA go to the Properties of the Internal Network Definition
1. Then to the Auto Discovery Tab,... check the box,...leave the port at 80
2. Firewall Client Tab,...Check all boxes except last one,..enter ISA
Netbios Name in upper box, choose "use default url". Leave last checkbox and
the last "servername" box empty.

Verify the ISA is properly "publishing" the auto-configuration by going to
the URL I mentioned above. (http://wpad.ad-domain.local/wpad.dat) You
should get a prompt to "Open" or to "Save". If you choose Open you will see
the contents of the configuration script.

In the user's browsers which do not use the Firewall Client, go to the proxy
settings and enable to top two checkboxes. Add the URL http://:8080/array.dll?Get.Routing.Script

On the machines that use the Firewall Client install the Firewall Client
using the Defaults which is to autodetect the proxy. The Firewall Client
software should automatically configure the browser and will continue to do
so every 30 minutes if I'm not mistaken.

Using autodiscovery will also help eliminate the problems that can arise
with browser requests for internal sites being incorrectly sent to the proxy
when they are supposed to go direct to the site.

Here are links to verify my details above.

Configuring WPAD Support for ISA Firewall Web Proxy and Firewall Clients
http://www.isaserver.org/tutorials/Configu...ll-Clients.html

ISA Server: Troubleshooting Automatic Detection
http://www.microsoft.com/technet/isa/2004/ts_wpad.mspx

Automatic Discovery for Firewall and Web Proxy Clients
http://www.microsoft.com/technet/isa/2004/...cdiscovery.mspx


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1...07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesec...repartners.mspx
-----------------------------------------------------


"Will" wrote in message
news:54WdneDdRt2L7HTanZ2dnUVZ_tKinZ2d@giganews.com...
> "Phillip Windell" wrote in message
> news:eQIYMTqjIHA.3780@TK2MSFTNGP06.phx.gbl...
>> > I guess I will have to force updates through web proxy in order to get
> it
>> > to
>> > work.
>>
>> I always use Web Proxy and Firewall [winsock] Service together. My LAN
>> is
>> configured for auto-detection via WPAD and always has the Firewall Client
>> installed (except for some servers that are only Web Proxy/SecureNAT).
>
> I have never been able to get WPAD to work. I point our DNS with an A
> DNS
> host record for WPAD to the ISA Server IP on the Internal network. But
> the browsers on clients never seem to autoconfigure.
>
> Is there a firewall rule required on ISA in order to have autoconfigure
> functionality work?
>
> --
> Will
>
>> The views expressed, are my own and not those of my employer, or
> Microsoft,
>> or anyone else associated with me, including my cats.
>> -----------------------------------------------------
>> Understanding the ISA 2004 Access Rule Processing
>> http://www.isaserver.org/articles/ISA2004_AccessRules.html
>>
>> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
>>
> http://download.microsoft.com/download/9/1...07/ts_rules.doc
>>
>> Microsoft Internet Security & Acceleration Server: Partners
>> http://www.microsoft.com/isaserver/partners/default.mspx
>>
>> Microsoft ISA Server Partners: Partner Hardware Solutions
>>
> http://www.microsoft.com/forefront/edgesec...repartners.mspx
>> -----------------------------------------------------
>>
>>
>
>

 

[Will]

This was all helpful and thanks. It turns out I had already set up the
CNAME for WPAD earlier and had reasoned similarly to you for maintenance.

For now I'm trying to use just web proxy and am avoiding Firewall client.
We tried Firewall client once and I really hated it because of the noise it
created in the monitor. It made it much more difficult to follow the
browsing patterns from the computer in ISA Monitor

Something I really don't get: When I do an explicit attempt to access
http://wpad.mydomain.com/wpad.dat I get the file and I can see that access
in the firewall Monitor. But during normal activity, I never see any
attempts to get this file by the browsers in autoconfigure mode. Is there
some way that behavior might be kept silent by ISA?

We configured the selection of autoconfigure in the browsers through group
policy, and the only really tricky part was how to get the services that run
in SYSTEM context to use the proxy. We came up with a hack that if you
login as administrator, configure the browser with not only autoconfigure
but also explicitly set the proxy values, then from command line run
proxycfg -u, then reverse out the changes in the user's browser, that will
force use of the proxy by automatic updates.

--
Will

"Phillip Windell" wrote in message
news:e$RkU50jIHA.536@TK2MSFTNGP06.phx.gbl...
> You'll want to do it in both DNS and DHCP. Some client will receive it
> better with DHCP others will receive it better with DNS,...so you want
> both.
>
> Start with DNS, remove the A Record from your earlier attempt and create a
> CNAME entry for "wpad" that points to the "A" Record of the ISA that would
> already exist. Maybe not all documents will tell you to do it with the
> CNAME like that,...but I am. One reason for that is that you can easily
> move uses from one proxy to another by simply changing what A Record the
> CNAME points to and you will litterally have no other configuration to
> change. It is also the "clean" way to work with DNS because it eliminates
> having more than one record pointing to the same IP#.
>
> Then in DHCP create the "Option 252 wpad".
> When you create the URL value you will use the earlier CNAME from the DNS
> to build it
> (http://wpad.ad-domain.local/wpad.dat)
>
> On the ISA go to the Properties of the Internal Network Definition
> 1. Then to the Auto Discovery Tab,... check the box,...leave the port at
> 80
> 2. Firewall Client Tab,...Check all boxes except last one,..enter ISA
> Netbios Name in upper box, choose "use default url". Leave last checkbox
> and the last "servername" box empty.
>
> Verify the ISA is properly "publishing" the auto-configuration by going to
> the URL I mentioned above. (http://wpad.ad-domain.local/wpad.dat) You
> should get a prompt to "Open" or to "Save". If you choose Open you will
> see the contents of the configuration script.
>
> In the user's browsers which do not use the Firewall Client, go to the
> proxy settings and enable to top two checkboxes. Add the URL http:// netbios name>:8080/array.dll?Get.Routing.Script
>
> On the machines that use the Firewall Client install the Firewall Client
> using the Defaults which is to autodetect the proxy. The Firewall Client
> software should automatically configure the browser and will continue to
> do so every 30 minutes if I'm not mistaken.
>
> Using autodiscovery will also help eliminate the problems that can arise
> with browser requests for internal sites being incorrectly sent to the
> proxy when they are supposed to go direct to the site.
>
> Here are links to verify my details above.
>
> Configuring WPAD Support for ISA Firewall Web Proxy and Firewall Clients
> http://www.isaserver.org/tutorials/Configu...ll-Clients.html
>
> ISA Server: Troubleshooting Automatic Detection
> http://www.microsoft.com/technet/isa/2004/ts_wpad.mspx
>
> Automatic Discovery for Firewall and Web Proxy Clients
> http://www.microsoft.com/technet/isa/2004/...cdiscovery.mspx
>
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/ISA2004_AccessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> http://download.microsoft.com/download/9/1...07/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.mspx
>
> Microsoft ISA Server Partners: Partner Hardware Solutions
> http://www.microsoft.com/forefront/edgesec...repartners.mspx
> -----------------------------------------------------
>
>
> "Will" wrote in message
> news:54WdneDdRt2L7HTanZ2dnUVZ_tKinZ2d@giganews.com...
>> "Phillip Windell" wrote in message
>> news:eQIYMTqjIHA.3780@TK2MSFTNGP06.phx.gbl...
>>> > I guess I will have to force updates through web proxy in order to get
>> it
>>> > to
>>> > work.
>>>
>>> I always use Web Proxy and Firewall [winsock] Service together. My LAN
>>> is
>>> configured for auto-detection via WPAD and always has the Firewall
>>> Client
>>> installed (except for some servers that are only Web Proxy/SecureNAT).
>>
>> I have never been able to get WPAD to work. I point our DNS with an A
>> DNS
>> host record for WPAD to the ISA Server IP on the Internal network. But
>> the browsers on clients never seem to autoconfigure.
>>
>> Is there a firewall rule required on ISA in order to have autoconfigure
>> functionality work?
>>
>> --
>> Will
>>
>>> The views expressed, are my own and not those of my employer, or
>> Microsoft,
>>> or anyone else associated with me, including my cats.
>>> -----------------------------------------------------
>>> Understanding the ISA 2004 Access Rule Processing
>>> http://www.isaserver.org/articles/ISA2004_AccessRules.html
>>>
>>> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
>>>
>> http://download.microsoft.com/download/9/1...07/ts_rules.doc
>>>
>>> Microsoft Internet Security & Acceleration Server: Partners
>>> http://www.microsoft.com/isaserver/partners/default.mspx
>>>
>>> Microsoft ISA Server Partners: Partner Hardware Solutions
>>>
>> http://www.microsoft.com/forefront/edgesec...repartners.mspx
>>> -----------------------------------------------------
>>>
>>>
>>
>>
>
>

 

[Phillip Windell]

"Will" wrote in message
news:uaKdna7MzMGxu3banZ2dnUVZ_tWtnZ2d@giganews.com...
> Something I really don't get: When I do an explicit attempt to access
> http://wpad.mydomain.com/wpad.dat I get the file and I can see that access
> in the firewall Monitor. But during normal activity, I never see any
> attempts to get this file by the browsers in autoconfigure mode. Is
> there some way that behavior might be kept silent by ISA?

I don't know.

> We configured the selection of autoconfigure in the browsers through group
> policy, and the only really tricky part was how to get the services that
> run in SYSTEM context to use the proxy.

That will never happen. Those things cannot use the Web Proxy Service. That
can only be used by CERN Compliant Applications (like web browsers).

Running services must either operated as SecureNAT or Firewall Clients. The
Firewall Client is the best choice. In either case the Rules for the
process must be set to anonymous (All Users). I don't know what "noise" the
Firewall Client was alleged to create in the monitoring log,...but when
using the monitoring log you should always use the Filtering to weed out the
noise in any situation.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1...07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesec...repartners.mspx
-----------------------------------------------------

 

[Will]

"Phillip Windell" wrote in message
news:O3HBhFBkIHA.5724@TK2MSFTNGP03.phx.gbl...
> "Will" wrote in message
> news:uaKdna7MzMGxu3banZ2dnUVZ_tWtnZ2d@giganews.com...
>> Something I really don't get: When I do an explicit attempt to access
>> http://wpad.mydomain.com/wpad.dat I get the file and I can see that
>> access in the firewall Monitor. But during normal activity, I never see
>> any attempts to get this file by the browsers in autoconfigure mode. Is
>> there some way that behavior might be kept silent by ISA?
>
> I don't know.
>
>> We configured the selection of autoconfigure in the browsers through
>> group policy, and the only really tricky part was how to get the services
>> that run in SYSTEM context to use the proxy.
>
> That will never happen. Those things cannot use the Web Proxy Service.
> That can only be used by CERN Compliant Applications (like web browsers).
>
> Running services must either operated as SecureNAT or Firewall Clients.
> The Firewall Client is the best choice. In either case the Rules for the

I am with you on this, but I would request that you please try the following
sequence under Windows 2003 and see if you don't get the same result:

1) Logon as administrator.

2) Open MSIE 7 and set the web proxy server value by selecting "Use a proxy
server" checkbox, then providing correct values for Address and Port.

3) Verify that browser is able to get to Internet and that the URL field in
ISA monitor is showing DNS names.

4) Go to command line on the server and issue command:

proxycfg -u

This grabs the currently logged in user's settings and uses them to
establish a proxy default. Default for what I do not fully understand.

5) Go back to MSIE and change back proxy settings to your preferred default
setting for the user.

From this point on, Windows Updates running in the background through
Automatic Updates on that computer will show DNS names in the ISA Monitor
URL field.

I don't claim to understand why. I agree with you that a background
service shouldn't be using a browser connected setting. I'm just reporting
what I see in the monitor log. Try it and you might like it, without
necessarily understanding why it happens.


> process must be set to anonymous (All Users). I don't know what "noise"
> the Firewall Client was alleged to create in the monitoring log,...but
> when using the monitoring log you should always use the Filtering to weed
> out the noise in any situation.

It has been a while, but what we were seeing were what looked like encrypted
sessions between the client and the proxy, with no distinct details about
what each client was actually doing . Reading the monitor I was losing
all sense about what actions were happening on the client computers.

--
Will

 

[Phillip Windell]

"Will" wrote in message
news:LcSdnSFrg_Zj33HanZ2dnUVZ_uyinZ2d@giganews.com...

> I am with you on this, but I would request that you please try the
> following sequence under Windows 2003 and see if you don't get the same
> result:

I really don't see the point. Windows Updates runs in a browser so it can
use the Web Proxy Service. Automatic Updates, although it works together
with Windows Updates and/or Microsoft Update, is not the same thing. Maybe
AU is cable of "borrowing" the browsers proxy settings and running with the
Web Proxy Service,...I don't know. My point about things running as
"services" needing the Winsock or Securenat services was more "general" and
"generic",...if Windows Updates or Microsoft Updates or Automatic Updates
does something a little different that doesn't change the main principles.

>> process must be set to anonymous (All Users). I don't know what "noise"
>> the Firewall Client was alleged to create in the monitoring log,...but
>> when using the monitoring log you should always use the Filtering to weed
>> out the noise in any situation.
>
> It has been a while, but what we were seeing were what looked like
> encrypted sessions between the client and the proxy, with no distinct
> details about what each client was actually doing . Reading the monitor
> I was losing all sense about what actions were happening on the client
> computers.

Communication between the Firewall Client and the ISA is encrypted and takes
place over some type of "secure channel". Sorry, I don't have all the
specific details, but it is not supposed to be human readable and not
supposed to give you details that you can read in the logs. You can't expect
all the Domain Authentication details and such between the Client and the
ISA to be "readable" in the firewall logs. This has nothing to do with the
fact that the logging will still show the details of the "resulting"
internet traffic generated by user. Sounds like it was just doing what it
was supposed to be doing to me. You'd have to ask someone like Jim harrison
for the specifics on that,...but there is no way that it is doing anything
"wrong" or anything "bad",...after 6 years of producing ISA, I am sure MS
has the communication between ISA and the Winsock Clients over the Layered
Service Provider (Firewall Client) figured out. The old MS Proxy2 used the
same thing and the Firewall Client and the Winsock Proxy Client are even
cross-compatible up to a point,...so MS has been doing it since about 1995.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1...07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesec...repartners.mspx
-----------------------------------------------------

 

[Will]

"Phillip Windell" wrote in message
news:OPkDMmNkIHA.5396@TK2MSFTNGP06.phx.gbl...
> "Will" wrote in message
> news:LcSdnSFrg_Zj33HanZ2dnUVZ_uyinZ2d@giganews.com...
>
> > I am with you on this, but I would request that you please try the
> > following sequence under Windows 2003 and see if you don't get the same
> > result:
>
> I really don't see the point. Windows Updates runs in a browser so it can
> use the Web Proxy Service. Automatic Updates, although it works together
> with Windows Updates and/or Microsoft Update, is not the same thing.
Maybe
> AU is cable of "borrowing" the browsers proxy settings and running with
the

Exactly. And since seeing automatic updates using DNS names is all I
wanted in the first place, that solves my problem.


> Web Proxy Service,...I don't know. My point about things running as
> "services" needing the Winsock or Securenat services was more "general"
and
> "generic",...if Windows Updates or Microsoft Updates or Automatic Updates
> does something a little different that doesn't change the main principles.

Understood, but as the subject of the thread implies, I was focused on
Automatic Updates .


> >> process must be set to anonymous (All Users). I don't know what "noise"
> >> the Firewall Client was alleged to create in the monitoring log,...but
> >> when using the monitoring log you should always use the Filtering to
weed
> >> out the noise in any situation.
> >
> > It has been a while, but what we were seeing were what looked like
> > encrypted sessions between the client and the proxy, with no distinct
> > details about what each client was actually doing . Reading the
monitor
> > I was losing all sense about what actions were happening on the client
> > computers.
>
> Communication between the Firewall Client and the ISA is encrypted and
takes
> place over some type of "secure channel". Sorry, I don't have all the
> specific details, but it is not supposed to be human readable and not
> supposed to give you details that you can read in the logs. You can't
expect
> all the Domain Authentication details and such between the Client and the
> ISA to be "readable" in the firewall logs. This has nothing to do with the
> fact that the logging will still show the details of the "resulting"
> internet traffic generated by user. Sounds like it was just doing what it
> was supposed to be doing to me. You'd have to ask someone like Jim
harrison
> for the specifics on that,...but there is no way that it is doing anything
> "wrong" or anything "bad",...after 6 years of producing ISA, I am sure MS
> has the communication between ISA and the Winsock Clients over the Layered
> Service Provider (Firewall Client) figured out. The old MS Proxy2 used
the
> same thing and the Firewall Client and the Winsock Proxy Client are even
> cross-compatible up to a point,...so MS has been doing it since about
1995.

To me this reads like an overly defensive response that is too protectionist
of status quo without a reason.

There might be very good technical reasons why using Firewall Client
requires the output of information about connections in the ISA Monitor log
to be so obscure. That doesn't mean it is a good usability design. And
it is not inherently good just because it is was the technically easiest
design to implement.

As a user of the product, what I would like to see in the Monitor log is a
clear sense of the endpoints in the connection. If you want to attribute a
given connection to indicate it is going through web proxy or firewall
client, that is great and useful. But ultimately those are lower level
details and not the core data of interest to most users.

--
Will

 

[Phillip Windell]

"Will" wrote in message
news:-J6dnYAaV_FdpnDanZ2dnUVZ_jKdnZ2d@giganews.com...
>> for the specifics on that,...but there is no way that it is doing
>> anything
>> "wrong" or anything "bad",...after 6 years of producing ISA, I am sure MS
>> has the communication between ISA and the Winsock Clients over the
>> Layered
>> Service Provider (Firewall Client) figured out. The old MS Proxy2 used
>> the
>> same thing and the Firewall Client and the Winsock Proxy Client are even
>> cross-compatible up to a point,...so MS has been doing it since about
> 1995.
>
> To me this reads like an overly defensive response that is too
> protectionist
> of status quo without a reason.

....or it just reads like me just getting tired and impatient yesterday. I
deal with this group every day pretty much all day. I see people complain
about this, that , and the other thing about ISA. If it is about something
"big" then fine, but if it is some little thing about some function not
giving the admin all the little details they think they might need for
whaterver they think they need it for I'm not that interested. We've had a
few "hardware firewalls" around here along with ISA and it was most
certainly much more difficult to get meaningful troubleshooting information
out of them than it is with ISA.

I'd rather focus my effort on giving someone guidance on accomplishing what
they want to do with ISA. I don't really feel like getting into little
nitty gritty details deep down in the gory guts of ISA and why it does some
particualry obscure thing in a particular way. I don't work for MS and I
don't have the "inside track" on that kind of information.

The Firewall Client (aka Winsock Proxy Client) does pretty much the same
thing, in the same why, since the 1990's with the old MS Proxy2 product.
There have been some improvements in it, but over all it has not changed
much. So whatever it is doing, it has been doing it since back when many of
todays younger "upstart" Admins were in pre-school.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1...07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesec...repartners.mspx
-----------------------------------------------------

 

[Phillip Windell]

Here isa link to an articl listing the various free diagnostic tools for
ISA. The ISAInfo Tool, DNSCache Tool, and the Firewall Engine Monitor
seemed liek something you might be interested in.

If you have questions about them,....don't ask me,... I won't know

ISA Server Tools
http://www.isaserver.org/tutorials/ISA-Server-Tools.html

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------





"Phillip Windell" wrote in message
news:%23JMq3jQkIHA.536@TK2MSFTNGP06.phx.gbl...
> "Will" wrote in message
> news:-J6dnYAaV_FdpnDanZ2dnUVZ_jKdnZ2d@giganews.com...
>>> for the specifics on that,...but there is no way that it is doing
>>> anything
>>> "wrong" or anything "bad",...after 6 years of producing ISA, I am sure
>>> MS
>>> has the communication between ISA and the Winsock Clients over the
>>> Layered
>>> Service Provider (Firewall Client) figured out. The old MS Proxy2 used
>>> the
>>> same thing and the Firewall Client and the Winsock Proxy Client are even
>>> cross-compatible up to a point,...so MS has been doing it since about
>> 1995.
>>
>> To me this reads like an overly defensive response that is too
>> protectionist
>> of status quo without a reason.
>
> ...or it just reads like me just getting tired and impatient yesterday. I
> deal with this group every day pretty much all day. I see people complain
> about this, that , and the other thing about ISA. If it is about
> something "big" then fine, but if it is some little thing about some
> function not giving the admin all the little details they think they might
> need for whaterver they think they need it for I'm not that interested.
> We've had a few "hardware firewalls" around here along with ISA and it was
> most certainly much more difficult to get meaningful troubleshooting
> information out of them than it is with ISA.
>
> I'd rather focus my effort on giving someone guidance on accomplishing
> what they want to do with ISA. I don't really feel like getting into
> little nitty gritty details deep down in the gory guts of ISA and why it
> does some particualry obscure thing in a particular way. I don't work for
> MS and I don't have the "inside track" on that kind of information.
>
> The Firewall Client (aka Winsock Proxy Client) does pretty much the same
> thing, in the same why, since the 1990's with the old MS Proxy2 product.
> There have been some improvements in it, but over all it has not changed
> much. So whatever it is doing, it has been doing it since back when many
> of todays younger "upstart" Admins were in pre-school.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/ISA2004_AccessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> http://download.microsoft.com/download/9/1...07/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.mspx
>
> Microsoft ISA Server Partners: Partner Hardware Solutions
> http://www.microsoft.com/forefront/edgesec...repartners.mspx
> -----------------------------------------------------
>