HTTP proxy exception seems to be ignored

I have HTTPS and HTTP proxies enabled in my environment. I have one particular instance where a proxy exception seems to be ignored (or I'm just not looking in the right spot). In my HTTP proxy I have chosen to deny several body content types - ZIP Archive being one of them. I have one particular site where I wish to allow users to download ZIP files, and I have added the site URL to the proxy exception list, however I still receive a denied message. It has always been my understanding that proxy exceptions apply to body content types. Has this changed? I have created exceptions in the HTTPS proxy, HTTP proxy and Web Blocker policies just for good measure, yet nothing I do seems to allow ZIP files from this site. What am I missing?

Comments

  • Also - the appliance is a M500 running 12.2.1.B572649

  • edited August 2019

    Please post a sample deny message from Traffic Monitor

  • @Bruce_Briggs said:
    Please post a sample deny message from Traffic Monitor

    Here you go:

    2019-08-23 15:18:26 Deny 172.16.90.100 52.216.21.61 https/tcp 56213 443 1-Trusted 0-Corp-External ProxyDeny: HTTP Body Content Type match (HTTPS-proxy.Corp-00) HTTP-Client.Standard.Corp proc_id="http-proxy" rc="595" msg_id="1AFF-0012" proxy_act="HTTP-Client.Standard.Corp" rule_name="ZIP archive" geo_dst="USA" Traffic

  • edited August 2019

    Can you verify that the domain being accessed matches your HTTP proxy exception domain name?

    On your HTTP proxy action -> URL Paths, you can select Log on the Default Allow entry. Then you should see the domain name being accessed in Traffic Monitor

  • According to this article https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/http/http_proxy_exceptions_c.html, it does appear to make an exception for "HTTP response — Idle timeout, response headers, content types, cookies, body content types." In my testing I just did, adding my web site to the HTTP exception list allows a download of a test EXE file I have on my site for demo purposes. So, yes, the exceptions work for body content types.

    HOWEVER, when I first tried it, I used "*.mypublicdomain.net" in the exception and it did not work, then I remember that my web site is just "mypublicdomain.net", and that worked to allow the previously blocked EXE from my site. Check the exact domain name that hosts the ZIP you need.

    Gregg Hill

  • Is there a reason I can't seem to post a response to this? I keep getting a message that my comments will be added once they have been approved, but its been around two and half hours and still nothing...

  • No idea.
    I did have an issue posting on a different topic - so perhaps there was some admin maintenance going on

  • I narrowed this down to an issue with a wildcard in the URL in my exception list. I have no idea why that's an issue, but apparently in this instance it was.

  • @blabarbera said:
    I narrowed this down to an issue with a wildcard in the URL in my exception list. I have no idea why that's an issue, but apparently in this instance it was.

    That sounds like what I mentioned: I used "*.mypublicdomain.net" in the exception and it did not work, then I remember that my web site is just "mypublicdomain.net".

    The exception has to match the domain name, and *.domain.com does not match domain.com without the prefix.

    Gregg

    Gregg Hill

  • Post the URL being accessed and the exceptions that you have, and we should be able to help sort this out.

  • These wonderful new forums won't let me post URL's, and it appears the admins are on permanent vacation because none of my previous posts have been approved or denied.

  • I'll try my best to give an example of what's happening without using any trigger words.

    I have a site that is hosted on AWS. The site includes a document library that let's users download docs/files. The download URL is an AWS address. Something like sub.amzdomain.com/sub.useraliasdomain.com/etcetcetc.

    I created exceptions for:

    .amzdomain.com/sub.useraliasdomain.com/
    .amzdomain.com/

    The only one that worked is:

    sub.amzdomain.com

  • There should be wildcards (*) at both ends of those first two. Love these new forums.

  • edited August 2019

    You will never see a domain that starts with a dot, and that is the problem with your exceptions. For example, if the site you are trying to reach is https://amzdomain.com/whatever, then your .amzdomain.com/ exception fails because of the leading dot. An exception of .amzdomain.com/ also would fail, because the example https://amzdomain.com/whatever domain has no subdomain.

    Gregg Hill

  • I'm aware of that. Read the next post. The forum stripped out my wildcards when I clicked submit, that's not how they were entered in the Firebox.

  • Yup the * are there in an edited post but not shown.
    Must be some sort of very annoying markdown effect.

    WG - please tell us how to deal with the disappearing * characters when not separated with a space

  • edited August 2019

    I also just got "Failed to find discussion for commenting." when I tried to edit the 2nd post up..... which was:

    The HTTP proxy exception is for a domain name.
    Not sure why a * is needed at the end of a domain name entry.
    * .amzdomain.com *

    When posting on this forum, you need a space in the 1st column before an * and a space between an * and any other character. Most annoying !!!!!

  • Ricardo_ArroyoRicardo_Arroyo WatchGuard Representative
    edited August 2019

    The Proxy Exclusions should be FQDN's not URL patterns. You should get rid of the trailing slash(/) and trailing asterisks(*) and it should work.

    Ricardo Arroyo | Principal Product Manager / ThreatSync Guru
    WatchGuard Technologies, Inc.

Sign In to comment.