> oextreme wrote:
>
>> I am looking for the CIDR of the addresses needed for WSUS to work.
My first impression is that we have a disconnect caused by a
misunderstanding of the term 'CIDR'.
CIRD = "Classless Inter-Domain Routing" and is the description of a
*methodology* for allocating IP Addresses more efficiently than the original
"Class" based methodologies.
http://en.wikipedia.org/wiki/Classle...Domain_Routing
>> Currently I have my main WSUS01 server set to full internet access. I
>> want to
>> have a rule on my firewall that will allow access to only the IP address
>> needed for WSUS.
This should have been your first sentence. It describes ever so much better
what you're trying to do. However, as Robear has already pointed out quite
accurately -- no such list exists, nor is any such list likely to be
accurate for any period of time. IP Addresses change -- that's why the
Domain Name Service exists; and that's why the hostnames and domain names of
the services that WSUS needs are listed in the documentation -- that's the
part that won't change.
>> I want to segment the bandwidth off one internet connection and have it
>> pull from a second internet connection. If the WSUS sites are not part of
>> a CIDR then I would accept the CIDR for Microsoft.com.
Although, here, I'm starting to see why you might be thinking in terms of
CIDR, but you're still beyond the scope of the term. Let's just make it
simple and call them IP Networks or IP Subnetworks. In fact, we really don't
know if Microsoft, or their hosting vendor (which is a more appropriate
consideration), has implemented CIDR on those resources -- it's more likely
in a large datacenter that they have not. CIDR was created to allow =ISPs=
to more efficiently manage routing tables from multiple downstream clients
using small subnets, and to allow the Internet backbone to more efficiently
manage routing tables from multiple ISPs. It's a rare scenario indeed where
an end-user has implemented any features defined in CIDR.
Now, back to the real question: The fact is that the IP Network that WSUS
traffic is routed to is entirely REGIONAL -- based on the query responses
from DNS lookups on the specific destination hostnames
(update.microsoft.com; download.microsoft.com).
>> Below are the needed URLs
>> http://windowsupdate.microsoft.com http://*.windowsupdate.microsoft.com
>> https://*.windowsupdate.microsoft.com http://*.update.microsoft.com
>> https://*.update.microsoft.com http://*.windowsupdate.com
>> http://download.windowsupdate.com
>> http://download.microsoft.com http://*.download.windowsupdate.com
>> http://wustat.windows.com http://ntservicepack.microsoft.com
Many of the above URLs are still contained in the documentation, but are
functionally dead. That's the good news.
The closest thing to a solution to your stated objective is to execute
appropriate and sufficient queries against the Domain Name Service to
determine what your regional IP Networks are that support the current
functionality. The primary "hostnames" are update.microsoft.com and
download.microsoft.com -- but those are identifiers for multi-server
load-balanced environments, thus the requirement to also configure the
firewall to support ANY machine contained within the update.microsoft.com
and download.microsoft.com domains -- as well as the variations that also
may exist in the domain windowsupdate.com.
Simple fact is, you can determine that list of IP Addreses today -- but if
you enumerate it in your firewall, tomorrow something may try to hit a new
machine in that domain and fail because it's on a new IP network.
Furthermore, Microsoft is not the only customer of the vendor who actually
provides these hosted environments, so you'll not only be routing WSUS/WU/MU
traffic, but also traffic for any other vendor who hosts their download
services at nsatc.net, et.al.
In addition, merely configuring rules in your firewall won't be sufficient.
You'll also need to tell each and every machine in your network which
firewall to route traffic to, depending on destination subnet(s). You'll
also need to maintain that routing table, and have some methodology for
distributing it on a regular basis -- this might involve enabling a routing
protocol to distribute/update those route table entries as they get changed.
Simply stated == while I believe I understand what you're trying to do ==
it's not practical to try to implement it.
Not to mention that the actual volume of traffic that will come down that
pipeline is a miniscule percentage of the total traffic that will pass
through your pipe. Frankly, I'm not even sure the expense of a second
firewall or second connection is justified by this plan.
Perhaps we should back up and discuss the *PROBLEM* that you are trying to
solve, and discuss appropriate solutions to that problem, rather than
discussing one solution (to an unidentified problem), which will only create
more problems.
--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website:
http://www.microsoft.com/wsus
My Websites:
http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile:
http://mvp.support.microsoft.com/pro...awrence.Garvin
Similar Threads
Linear Mode
