It seems Windows Updates doesn’t play nice with Palo Alto best practices; specifically when it comes to range headers.
Palo Alto best practices state that you should block the HTTP range option for the following reason:
“The HTTP Range option allows a client to fetch part of a file only. When a next-generation firewall in the path of a transfer identifies and drops a malicious file, it terminates the TCP session with a RST packet. If the web browser implements the HTTP Range option, it can start a new session to fetch only the remaining part of the file. This prevents the firewall from triggering the same signature again due to the lack of context into the initial session, while at the same time allowing the web browser to reassemble the file and deliver the malicious content”
Unfortunately it seems that some legitimate applications probably require the HTTP range option – I discovered this today when I was scratching my head wondering why some of our servers hadn’t received patches from February. Turns out WSUS uses the HTTP range option and was failing to download updates.
The event logs would show errors such as:
Event ID 364 – Content file download failed. Reason: The job is not making progress. The server may be misconfigured. Background Intelligent Transfer Service (BITS) will try again later
Event ID 10032 – The server is failing to download some updates.
As soon as I turned off the HTTP range header block on the Palo’s, WSUS was happily downloading updates again.
If you are seeing the errors above and have ruled out other connectivity issues (proxies, web filters, etc) and do have a Palo Alto then you should check if you have range-header blocking in place by running the following in configure mode:
show deviceconfig setting ctd
If you see skip-block-http-range no then the headers are being blocked. To stop blocking the HTTP range header option then run the following:
set deviceconfig setting ctd skip-block-http-range yes
I’ll probably raise a case with PAN as the justification for enabling the range header block makes sense however it’s not feasible to leave it in blocking mode if it breaks WSUS. Perhaps they can create a signature exception for WSUS in the future…