Route Windows Update Traffic to specific WAN interface

Adam
Kind of a big deal

Route Windows Update Traffic to specific WAN interface

I can't seem to find a way to route Windows Update traffic download.windowsupdate.com to a specific WAN interface.  It looks like internet flow preferences require typing in the IP or subnet as a destination.  Any other ideas options?

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
7 Replies 7
jdsilva
Kind of a big deal

No ideas here. It does frustrate me that Internet flow preferences are limited to the old 5-tuple archaic classification when the MX clearly has application or hostname based abilities. 

mmmmmmark
Building a reputation

1. Use a WSUS then you can force all of it's traffic out over that WAN.

2. Grab the list from here and then enter all those IPs into the Traffic shaping section and have all traffic to any Microsoft site go through that WAN.

Adam
Kind of a big deal

Wouldn't really help.  Our WAN connection is private MPLS so the WSUS would still have to live at our colocation center.  In this case, I'm wanting to send the windows update traffic over the slow DSL connection at the site. 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
mmmmmmark
Building a reputation

So you've got a site that connects over MPLS to the colo and they also have a DSL connection. There's no infrastructure to put a WSUS at the site. Sounds like the MPLS is the primary uplink for the site. Any chance that the site could access the colo over the DSL connection and contact a WSUS there that way? I'd assume that the colo has a second connection? It would probably need a separate static IP as well due to WSUS going over 443. 

PhilipDAth
Kind of a big deal
Kind of a big deal

There is no good fix for this.  I don't think Windows Update uses a static set of IP addresses, as Microsoft tend to use additional CDNs at times of high load (aka when a new big patch is being released).

 

I'm not a fan of WSUS.  What you could do (if you like a lot of pain) is put a WSUS server somewhere that it can have a public IP address (could be in your colo, in Amazon AWS, etc), and then use the flow preferences to route that public IP address out the DSL interface.

If you enabled AutoVPN failover via the DSL you could also use flow preferences to route the WSUS private IP address over the AutoVPN over DSL.

 

Another thought (only slightly better than using WSUS) would be to configure a proxy server (such as squid) that is only accessible via the DSL circuit.  Then create a WPAD script that sends all requests directly out to the Internet except Windows Update URLs, which you send to your proxy server.  WSUS is (IMHO) a pig to administer and keep running, while a proxy server is pretty much automatic.

Adam
Kind of a big deal

You guys have given me some potential ideas.  In the meantime, I instituted some traffic shaping to minimize the amount of bandwidth the updates can consume.  But the whole thing got me thinking about the difficulty of this type of scenario.  

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
Happiman
Building a reputation

I found a couple of links to identify the public subnets but there are two many.

 

You can download the list of subnets from here . https://www.microsoft.com/en-us/download/details.aspx?id=53602

 

And these people were trying to identify the actual subnets that belong to the windows updates.

 

https://social.technet.microsoft.com/Forums/windows/en-US/b596aa81-2775-496c-b159-dcfc5c5bf22d/windo...

 

So I'm thinking these are the subnets for the window updates.

65.52.0.0/14

70.37.0.0/17
70.37.128.0/18

94.245.64.0/18


111.221.16.0/20
111.221.64.0/18

132.245.0.0/16

 

157.54.0.0/15
157.56.0.0/14
157.60.0.0/16

207.46.0.0/16
207.68.128.0/18

213.199.128.0/18

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels