Can't see what WebBlocker blocks
I'm trying to allow a VoIP application (Elevate app, derived from Intermedia's service) through the Firebox but WebBlocker prevents it. I have added the URLs for the service as exceptions in WebBlocker, both global and under the WebBlocker action. I have turned on Alarm and Log for the exceptions. The trouble I'm running into is that I cannot see in the traffic monitor what is being blocked. I know the block occurs inside WebBlocker because if I turn WebBlocker off the Elevate application works fine. What am I missing in order to see the blocked traffic? Once I find the traffic I can add the appropriate exceptions.
Thanks!!
0
Sign In to comment.
Comments
What makes you think that this is WB that is blocking this?
There are other HTTP proxy action check which could be blocking it.
If I turn WebBlocker off the Elevate application works fine. I don't change any other proxy actions when I turn off WB. Is there something else that would indicate a proxy? I can't see any of the blocked traffic when WB is either on or off.
I just downloaded that app on my iPad, and it uses HTTPS.
There are lots of URLs that are being accessed.
Do you have Inspect enabled on your HTTPS proxy action?
Do you have App Control enabled on it?
If you have some things set to deny, but not to log, then you won't see what you need in Traffic Monitor.
You can turn on Logging in WB.
Is WB enabled on your HTTPS proxy action or on a HTTP proxy action which is specified for Inspect?
In either case, there is a "Log this action" check box you can select.
Inspect is enabled, I have Alarm and Logging on. App control is not enabled. WB is enabled on the HTTPS proxy action. Logging is enabled for reports in the proxy action and I have enabled Logging and Alarm for the WB action but still see no blocked traffic.
I do see lines like this:
ProxyDeny: HTTP Invalid Request-Line format (HTTPS-proxy-00) proc_id="http-proxy" rc="595" msg_id="1AFF-0005" proxy_act="HTTP-Client.2.1" geo_dst="USA" line="\x81\xb9X\x0c\xde\xa8\x03.\xed\x91o>\xfc\x84z?\xe7\x9fj.\xf2\x8a-\x7f\xbb\xdab=\xea\x91o=\xeb\x9bu4\xed\x9fk8\xec\x9fj5\xe8\x85l.\xf2\x8a(d\xa6\xf72c\xb7\xc6z \xa5\xd5\x05\x81\xba\xdc\x8b\xc9\xd5\x87\xa9\xfa\xec\xeb\xb9\xeb\xf9\xfe\xb8\xf0\xe2\xef\xa9\xe5\xf7\xa9\xf8\xac\xa7\xe6\xba\xfd\xec\xeb\xba\xfc\xe6\xf1\xb3\xfa\xe2\xef\xbf\xfb\xe2\xee\xb2\xff\xf8\xe8\xa9\xe5\xf7\xac\xe3\xb1\x8a\xb0\xee\xa8\xa3\xb9\xa9\xe5\xae\xa1\xd6\x81\xb96a\xba\xe9mC\x89\xd0\x01U\x98\xc5\x14R\x83\xde\x02C\x96\xcbC\x12\xdf\x9b\x0cP\x8e\xd0\x01P\x8f\xda\x1bY\x89\xde\x05U\x88\xde\x04X\x8c\xc4\x02C\x96\xcbF\x09\xc2\xb6\x5c\x0e\xd3\x87\x14M\xc1\x94k\x81\xba+\x15\x1a\xa7p7)\x9e\x1c!8\x8b\x09&#\x90\x1e76\x85^f\x7f\xd5\x11$.\x9e\x1c$/\x94\x06-)\x90\x18!(\x90\x19,,\x8a\x1f76\x85[}b\xf8Gp{\xd1N76\xdcVH\x81\xb9F?\x10\xfa\x1d\x1d#\xc3q\x092\xd6d\x0c)\xcdp\x1d<\xd83Lu\x88|\x0e$\xc3q\x0e%\xc9k\x07#\xcdu\x0b"\xcdt\x06&\xd7r\x1d<\xd86Wh\xa5,Py\x94d\x13k\x87\x1b\x81\xa6Vn\xbe\x90\x0d\x00\xcb\xfc:B\x9c\xa3oY\x89\xb2zL\xce\xf89\x0b\xd0\xf9.L\x92\xb2>"
that are being blocked. Could that be where the block is occurring? That's on the HTTP proxy action, not the WB. The source of that traffic is the IP of my test machine.
When Inspect is enabled for a domain name, the WB profile used is the one from the HTTP proxy action.
HTTPS-Proxy: WebBlocker
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/https/https_webblocker_settings_c.html
Make sure that you have the Log check box selected for all of the WB categories which are set to Deny on your WB profile on your HTTP proxy action specified on your HTTPS proxy action.
The Alarm and Log check boxes on the "When a URL is uncategorized" line are only for uncategorized websites.
"HTTP Invalid Request-Line format" is not likely the cause since when you disable WB, you don't have the issue.
Okay- I'll give it all a good review and see what I can find. I surely appreciate the help!
WooHoo! I can now see traffic that is blocked by the WB! I'll start adding exceptions and hopefully solve the issue. Once again, thank you!
I have found that when I enter in the exceptions as a pattern match I did not get alarm/log notices but when I enter them in as regular expressions I do get alarm/log notices.
Please post examples of the Domain name/URL that you are trying to allow and what you entered as an allow exception.
If you're seeing invalid line request format errors, the best way to get around them will be to make a packet filter for that traffic -- if you can determine the FQDNs or IPs that the traffic goes to.
(Error: ProxyDeny: HTTP Invalid Request-Line Format, in the log message)
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA10H000000g3GiSAI&lang=en_US
Even if you can eventually get it to work in the proxy, it's basically going to be slamming traffic that isn't proxy-able into the proxy, and chewing up CPU time to spit that error message out. Making a packet filter will keep that from happening.
-James Carson
WatchGuard Customer Support
Or you can add an Allow entry for the domain name of the site which causes the "HTTP Invalid Request-Line format" deny.
Additional logging may be needed to see the domain names involved.
Thanks for the advice, James! I'll work on that as well. Bruce, here's an example of the regular expression version: api.elevate.services/
Try api.elevate.services/* non-RegEx for WB exception
Hmm...pasting didn't come through correctly. The regular expression version is:
api\.elevate\.services/
but I'll give your version a try and see if it makes a difference.
Hi Bruce,
I tried your version of the exception to WB and I saw no difference - either rule (your version or the RegExp version) allow the app to work. Should I notice a difference?
Thanks!
On which WB profile location are you entering this?
If the domain is being Inspected by the HTTPS proxy, then the HTTP proxy action WB is the location where this entry needs to be added.
Or, you can add an Allow entry on your HTTPS proxy action for the SNI or CN for this site.
This explains the various circumstances on which WB profile is used on the HTTPS proxy.
"For HTTPS requests that match a domain name rule with the Inspect action, the proxy uses the WebBlocker profile in the HTTP proxy action to filter the content."
HTTPS-Proxy: WebBlocker
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/https/https_webblocker_settings_c.html
Okay - I'll do some further testing. Also, I'm entering the exceptions in the WB global exceptions list.
Care to post the URL which is causing your issue?
My access attempt to api.elevate.services results in
"{ "statusCode": 404, "message": "Resource not found" }
So to help more, I need something better to test than just api.elevate.services
The WB category for api.elevate.services is Information Technology
To see this I have Logging enabled on my HTTP proxy action which is listed in my HTTPS proxy.
2021-02-25 21:53:37 Allow 10.0.1.2 40.77.103.17 http/tcp 54150 80 Trust-VLAN External ProxyAllow: HTTP Request categories (HTTP-proxy_for_Bruce-PC-00) HTTP-Client_bruce proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client_bruce" cats="Information Technology" op="GET" dstname="api.elevate.services" arg="/" action="WebBlocker_Bruce" geo_dst="USA" Traffic