Running WSUS Behind a SonicWALL Firewall

[Charlie Savage]

Here is how to fix a SonicWALL PRO firewall so that a Microsoft Windows
Server Update Services (WSUS) server can download its update files.

We experienced a problem setting up Microsoft Windows Server Update Services
(WSUS) behind a SonicWALL PRO 5060 router/firewall running firmware 3.1.0.8
enhanced. Everything worked fine except that all attempts by the WSUS server
to download patches failed. Events seen in the server's Application Log were
like this...

Event Type: Error
Event Source: Windows Server Update Services
Event Category: Synchronization
Event ID: 364
Description:
Content file download failed. Reason: The server does not support the
necessary HTTP protocol. Background Intelligent Transfer Service (BITS)
requires that the server support the Range protocol header.

Here is how we fixed the SonicWALL.

Two of the SonicWALL's security services were interfering with the HTTP 1.1
Range protocol header. These services are "Gateway Anti-Virus" and
"Anti-Spyware." With either one of those two SonicWALL services enabled,
downloads by the WSUS server failed. The "Intrusion Prevention" service and
other SonicWALL security services did not affect this one way or the other.

The cure was to create client exclusions for the WSUS server for the Gateway
Anti-Virus and Anti-Spyware services. (See page 30 of the SonicWALL
Anti-Spyware Administrator's Guide.)

On the Anti-Spyware configuration page:

* Click "Configure Anti-Spyware Settings".

* In the Anti-Spyware Exclusion List, click "Add."

* In the To and From addresses, add the internal (LAN) IP address of the
WSUS server. Enter the same address on both lines (unless you really want to
exclude a range of addresses.)

* OK your way out of the dialog boxes.

The setup for the Gateway Anti-Virus section is the same, starting from the
"Configure gateway AV Settings" button.

--
Charlie Savage
Atkinson-Baker, Inc.

[Jeff Centimano [MVP - Windows Server]]

Nice post, Charlie. Can't say I run into too many SonicWALL devices - but
I'm sure there are plenty out there. You might want to consider adding this
to the WSUS Wiki if you have time (www.wsuswiki.com). That way
Google/MSN/Yahoo will pick it up and future "hair-pulling" will be minimized
for people in your situation. If I don't see this on the Wiki in a couple
weeks I'll prop it for you with credit, of course.

Thanks again,

--
Jeff Centimano
MVP - Windows Server
http://cgenius.blogspot.com

"Charlie Savage" <csa...@depo.com(nonspam)> wrote in message
news:396D72A2-7975-4A7A...@microsoft.com...

[Charlie Savage]

Jeff,

Thank you for the suggestion. I did not think of that -- my dial-up, BBS
roots showing.

It turns out that there is more to the story. Not only do the SonicWALL
security services affect the download of patches from the Internet
(Microsoft) to our WSUS server, but they may also affect the transfer of
patches across our own VPNs, from the WSUS server to computers located in
branch offices.

We have site-to-site VPNs linking six offices. All locations are using
SonicWALL firewalls running version 3.1.0.x enhanced firmware. Each Windows
XP computer is set through group policy to download and apply patches
provided by the WSUS server located in the main office. We found that only
computers in the same subnet with the WSUS server were successfully applying
patches. All others showed as "failed" in WSUS. The detail line for any of
these failures shows "Error: Download failed. -- Result code: 0x80246001."
The culprit again appears to be two of the SonicWALL security services
somehow interfering with the transfer. Note that these services are not
specifically blocking the file transfer -- there are no alerts in the
firewall's logs, for instance -- they just seem to interfere with it somehow,
perhaps by altering or corrupting the HHTP 1.1 range protocol header.

We are not totally finished testing this assumption yet, but initial results
are encouraging.

The fix seems to be to add the IP address of the WSUS server to the
exclusions list for the Gateway Anti-Spyware and Gateway Anti-Virus services
on each and every SonicWALL firewall. The procedure is the same as in my
original posting, but instead of applying it to the one firewall through
which the WSUS server pulls its updates from the Internet, I am now applying
the same setting to all firewalls through which Windows computers are pulling
their updates from the WSUS server. Basically, that is every SonicWALL
device we have. Although only the one IP address of the WSUS server seemed
to be necessary, on some I have broadened the exclusion to include the IP
address range in which we locate all servers in the main office, on the
theory that the firewall could be messing with communication to any of the
others as well, and I do not want the firewall to alter these communications.

I will provide a more coherent write-up when I see where all this settles
out at, probably in a week or so.

Charlie Savage
Atkinson-Baker, Inc.

--
Charlie Savage
Atkinson-Baker, Inc.

[Lawrence Garvin (MVP)]

Jeff, we've seen several instances of SonicWall boxes interfering with BITS.
The original issue surfaced during the beta, but the actual 'fix' from
SonicWall didn't become known to this forum until sometime in August, as I
recall. I've re-posted a couple of times in the past few months similar
information to Charlie's.

It was about time for a 'repost', and I'm happy to see it here again.

"Jeff Centimano [MVP - Windows Server]" <nos...@msn.com> wrote in message
news:Oc2DDoN%23FHA...@TK2MSFTNGP12.phx.gbl...