Options
Cant Save Changes to HTTP Client Standard Proxy Body Content Types
So all of my clients are receiving errors with windows updates specific to the HTTP Client Proxy - Body Content Type. I'm unable to save any changes I make here (it is unlocked). How do I disable this rule to allow the Windows EXE/DLL body content type, as the documentation below doesn't work (can't save any changes)? Again I've attempted this on 2 Watchguard T80 Firewalls and one M270. Is this because it's a predefined rule? If so what is the solution? Why allow changes to take place at all in here if you are not going to allow a save?
0
Sign In to comment.
Comments
Here is the exact error I need to resolve for Windows Updates.
2020-09-10 09:49:36 Deny 192.168.0.20 151.205.27.19 http/tcp 57755 80 Trusted External ProxyDeny: HTTP Body Content Type match (HTTP-proxy-00) proc_id="http-proxy" rc="595" msg_id="1AFF-0012" proxy_act="Default-HTTP-Client" geo_dst="USA" rule_name="Windows EXE/DLL"
I use WSM Policy Manager to make changes to my config.
In Policy Manager, one needs to save changes made to the default proxy action as a new proxy action name.
Presumably one needs to do the same using the Web UI. Also make sure that your proxy uses the new proxy action name.
As I was doing exactly what you said. Made a clone, made the change; I went to apply it inside the Firewall Policy for HTTP-proxy... I didn't realize you can modify the Body Content rules in there AND save. Very interesting. That worked. So edit the Firewall policy , click proxy action, and go to HTTP response and body content types.
Thanks!
"How do I disable this rule to allow the Windows EXE/DLL body content type" is a bad way to do it, UNLESS that particular HTTP proxy is specific to Microsoft sites. If it is a policy that applies to any web site, you should NOT disable the Windows EXE\DLL rule because that is a HUGE protection feature.
Instead, you should disable HTTPS DPI on sites used by Windows Updates, which will make the policy not check for Windows EXE\DLL files. Also, that 151.205.27.19 IP address is listed as owned by Verizon. Are you SURE that it is for Windows Update?
I always set up an unrestricted packet filter going From any Trusted or Optional interface and To an "FQDN-TrustedSites" alias that contains the domains needed by Windows Update.
Gregg Hill
Its funny you ask that question. Yes, 100% certain clicking windows update triggered the Windows EXE/DLL rule. The thing is the reverse IP is of a Verizon IP address and not a Microsoft IP address. What I did was I disabled it, did my updates and re-enabled it. Totally agree that disabling default rules like that can be harmful. I just don't know of an easy way to do this seeing that the IP address is not Microsoft's.
There were problems downloading some updates, but we'll try again later. If you keep seeing this, try searching the web or contacting support for help. This error code might help: (0x80244018)
Anyone know a better way to handle this?
Now all of my clients are having issues with the Windows EXE/DLL rule. This time with itunes updates. Is there no real fix but to disable this?
There are only a few options:
1) have a policy which allows Windows EXE/DLLs from desired sites
2) have a HTTP download override - of course, unless you change the password regularly, this option won't give you much security
3) don't deny Windows EXE/DLLs