HTTPS proxy deny message

Dear all,

I have problems with Deny messages for HTTPS proxy policy. If a have the certificate installed on my computer. When my page is in WARN status, and inspection is turned on, I get a warning. but I can continue to site.
If I put DENY in weblocker, then nothing happens. DNS problem error.
Also OVERRIDE doesn't work. I've been spinning in circles for 16 hours. As the instructions say, yes, you can receive a message if your inspection is turned on and if you have a certificate installed. You can also enter an override password.
Ok, but I can't turn on the inspection if the override is turned on for the category and the status is deny..

How can I get a deny notification for https traffic and override message for denied sites in weblocker?
Everything is up to date. Firebox M290...

Thank you..

Comments

  • The deny needs to be from WebBlocker deny and not from something else such as from an Inspect domain name deny
  • Thank you. Yes, but I can't get deny message or override.. When I using only WebLocker and mark deny and override, I got only DNS problem in browser. Override is turned on and password is configured.. I see that there are questions about it, but I haven't found a solution. HTTP works, but HTTPS not..

  • Is the deny on the WebBlocker which is on the HTTP proxy action selected on your HTTPS proxy action?
    That is where it should be

  • Here's a picture, I really do not know.

  • I figure where is problem. I use the same webblocker policy on HTTPS and HTTP.. Very simple, but...

    Webblocker in HTTP and HTTPS needs to be different. One for inspect in HTTPS proxy policy, ono for deny in HTTP proxy policy..

    HTTP proxy

    • In webblocker deny everything if you want.

    HTTPS proxy

    • Put annother webblocker and turn on INSPECT for category that you wont to deny.
    • Proxy action must be with the same as in HTTP proxy (HTTP-Client.standard for me)

    And we need to have installed certificate on comp...

    Thank you Bruce one more time...

  • @Aantolkovic said:
    I figure where is problem. I use the same webblocker policy on HTTPS and HTTP.. Very simple, but...

    Webblocker in HTTP and HTTPS needs to be different. One for inspect in HTTPS proxy policy, ono for deny in HTTP proxy policy..

    HTTP proxy

    • In webblocker deny everything if you want.

    HTTPS proxy

    • Put annother webblocker and turn on INSPECT for category that you wont to deny.
    • Proxy action must be with the same as in HTTP proxy (HTTP-Client.standard for me)

    And we need to have installed certificate on comp...

    Thank you Bruce one more time...

    Hi, new WatchGuard user here. Any chance you can post screenshots of the working configuration? Everything else was pretty straightforward to setup on the FireBox, but this particular item has me stumped. I have done the following:

    -Setup two WebBlocker lists ("Default" with items denied and "AllowAll" with nothing denied)
    -HTTP-proxy --> Proxy Action --> Proxy Action or Content Action = "Default-HTTP-Client"
    -HTTP-proxy --> Proxy Action --> WebBlocker = "Default"
    -HTTPS-proxy --> Proxy Action --> Proxy Action or Content Action = "Default-HTTPS-Client"
    -HTTPS-proxy --> Proxy Action --> WebBlocker = "AllowAll" with items wishing to be blocked marked as "Inspect"
    -HTTPS-proxy --> Proxy Action --> WebBlocker --> Proxy Action = "Default-HTTP-Client" same as above

    All clients MacOS and IOS with proxy certificate installed and trusted.

  • What is not working as you desire here?

  • Hi Bruce. I have it partially working, but it isn't consistent. For example, I have "Proxy Avoidance" as deny in the Default WebBlocker list and marked inspect in the AllowAll list. Here are the results when visiting specific pages:

    https://protonvpn.com shows a DNS error so doesn't load
    https://mullvad.net shows block page as expected
    https://nordvpn.com loads page as normal so not blocked

    All 3 of these show as deny when using the test in the WebBlocker configuration under subscription services. I've tried flushing caches, reboots of both FB and clients to no avail. Any insight would be appreciated. Thanks for your help!

  • Some more information. It appears from the logs that in some caes, it's identifying the browser traffic as an application which makes no sense, but does explain why protonvpn.com simply wouldn't load. Even stranger is nordvpn.com loads even though the logs are saying it was denied.

  • I'm not seeing a reason why https://nordvpn.com is not being blocked.

    Some background:
    The HTTPS proxy can't see the URL being accessed unless Inspect is enabled, since the traffic from the web client to the web server is encrypted.
    For un-Inspected web site access, the HTTPS proxy will look at the SNI and the CN fields of the web site cert.

    For nordvpn.com, the cert shows: sni="nordvpn.com" cn="*.nordvpn.com"

    And checking here:
    https://securityportal.watchguard.com/UrlCategory

    nordvpn.com shows as "Proxy Avoidance".
    So I would expect nordvpn.com to be blocked with your settings.

    Consider opening a support case on this.
    Click on the SUPPORT CENTER link above, and create a new case.

    Let us know if there is any resolution to this.

  • re: " It appears from the logs that in some caes, it's identifying the browser traffic as an application which makes no sense"

    This is coming from Application Control being enabled on your HTTPS proxy.
    You can also use App Control to deny access

  • Thanks. Is there a reason why application control would see something like accessing protonvpn.com via a web browser as an application? It appears that's why it throws a DNS error rather than block page. If I turn off application control, it gets inspected and denied properly as a web page. As for NordVPN, I will reach out to support.

  • Off hand, no idea.

  • There's actually a simple solution. Clone the proxy firewall policy and activate application control on only one and place it below the other with it deactivated. This way, the rule with WebBlocker will get hit first and the one below will catch anything else.

  • The 1st HTTPS policy matching the From: & To: fields will be used.
    No following HTTPS policy will be checked for this traffic.

  • Ah, good point.

Sign In to comment.