Access denied messages downloading software package due to IP address blocks
Article ID: 263250
Updated On:
Products
Issue/Introduction
WSS Agent running on MacOS devices.
SSL interception is completely disabled for tenant on the Cloud SWG Portal.
A developer tries to install some "qemu" packages on his MAC laptop but often sees download errors. If these errors are dependencies for the package needed, the installation fails as shown below.
Application seems to return a 403 status when error occurs.
Could not get HAR file from terminal console, but used HTTP logs to track user requests instead and found corresponding 403 policy_denied errors for the above objects.
Environment
Cloud SWG managed via UPE.
WSS Agent.
Cause
Force deny blocking uncategorised content for IP address destinations.
Resolution
Added regex policy entry allowing requests with TCP scheme within main access rule to address issue.
With UPE configurations, TCP requests into Cloud SWG for uncategorised IP addresses were blocked with a force deny rule. Ideally we wanted to allow the TCP requests through this layer of processing to get to the SSL and HTTPS layer (if SSL inspection is enabled) where categorization is available on domains and requests would be allowed through. To do this, we needed to create an exception to the force_deny rule that allowed the request be handed off to SSL layer IF
- category is NONE AND
- Request URL scheme is TCP AND
- Destination host is numeric …
Creating the following combined rule allowed us to do this which merges the TCP scheme and IP address checks into one regex entry which we called TCP_Exception.
- Category NONE AND
- Request URL of tcp://\b(?:(?:2(?:[0-4][0-9]|5[0-5])|[0-1]?[0-9]?[0-9])\.){3}(?:(?:2([0-4][0-9]|5[0-5])|[0-1]?[0-9]?[0-9]))\b
Now, we could apply the matching force deny rule to previous case with exception of the numeric TCP scheme above. This allowed the processing to continue to SSL layer where the block rules kicked in whenever a match found for uncategorised domains.
Additional Information
Prior to the change, the DENIED HTTP request would look like the following:
2023-01-13 15:19:39 "DP2-GGBLO99_proxysg3" 7 185.64.247.21 "[email protected]" "Lg82g+mFnXRxhgu8QGj1eUaLGg/jLXQYB1qv9LacpGg=" - - content_filter_denied DENIED "Uncategorized" - 0 TCP_ACCELERATED TUNNEL - tcp 54.149.73.9 443 / - - - 192.168.2.86 0 0 - - - - - - - - 0 "client" client_connector "none" "none" 54.149.73.9 "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - - "United States" - "United States" 5 - wss-agent architecture=x86_64%20name=Windows%2010%20Enterprise%20N%20version=10.0.19044 9.0.62.18698 10.0.200.1 dcd8dcbc-79b9-4425-aec8-443c6aa80e96 WIN10-PAC PC - - - - - - - - - 2ee2420f3b36a442-000000000019bbfc-0000000063c1768b - - "Invalid" "Invalid" - - -
After making the change, the status was allowed and passed to the SSL layer for additional processing.
2023-01-13 15:29:04 "DP2-GGBLO99_proxysg3" 5 185.64.247.21 "[email protected]" "Lg82g+mFnXRxhgu8QGj1eUaLGg/jLXQYB1qv9LacpGg=" - - - OBSERVED "Uncategorized" - 0 TCP_ACCELERATED TUNNEL - tcp 130.211.12.55 443 / - - - 192.168.2.86 0 0 - - - - - - - - 0 "client" client_connector "none" "none" 130.211.12.55 "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - - "United States" - "United States" 5 - wss-agent architecture=x86_64%20name=Windows%2010%20Enterprise%20N%20version=10.0.19044 9.0.62.18698 10.0.200.1 dcd8dcbc-79b9-4425-aec8-443c6aa80e96 WIN10-PAC PC - - - - - - - - - 2ee2420f3b36a442-000000000019c1ed-0000000063c178c0 - - "Invalid" "Invalid" - - -
Once the tcp:// scheme is allowed through, it will be passed to the SSL stack after protocol detection and be blocked there is matching policy is found. At the SSL layer, we have access to the cert SNI and can do categorisation based on domain.
Feedback
