Debug access denied errors or website accessibility issues with Policy tracing
search cancel

Debug access denied errors or website accessibility issues with Policy tracing

book

Article ID: 166514

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

Policy tracing is a tool on Edge SWG (formerly ProxySG) for debugging:

  • Access to a website is allowed when it should be denied
  • Access to a website is denied when it should be allowed

Enabling policy tracing and examining the output.

Policy tracing is for troubleshooting only. Policy tracing can effect Edge SWG (ProxySG) appliance performance. After troubleshooting, disable policy tracing.

Resolution

Enable policy tracing

Note: You can recreate the rule via CPL and add it to the local policy file via the command line, you cannot view the output of the debug file via CLI.

You can enable policy tracing via policy rules or via enabling the global option. The global option is easy to enable, but it can generate a lot of data very quickly. Therefore, the global option is recommended only for very little traffic or an isolated testing proxy.

Policy tracing as a rule (recommended)

WARNING: Follow these instructions carefully; mistakes could cause a service interruption. The policy tracing rule has to be in its own policy layer so that other rules are not bypassed. By default, creating a new web access rule sets the action for that rule to "Deny." If this is not changed to "None," the proxy will block all traffic. 

  1. Open the Visual Policy Manager.
  2. Click Add Layer > Web Access Layer.
  3. Click Add then enter the name and click OK
  4. Click the source, and then click Set.
  5. Click Add a new object, and then select Client IP Address/Subnet.
  6. Enter the IP Address of the computer you are testing from. As a subnet mask, enter 255.255.255.255, for a specific client.
  7. Click Apply > Set.
  8. In the Action column, click Deny and then click Delete. The action should now be "None."
  9. In the Track column, click None and then click Set.
  10. Click Add a new object > Trace.
  11. Tick the Set Trace Level box, the radio should default to Enabled
  12. Tick the Set Trace File box. Enter a name for the trace file
  13. Click Apply, then click Set.
  14. You should now have a layer with a single rule; the source is the IP address of the testing computer, and the track object is the object you just created.
  15. Click the Apply Policy at the top of the page.
  16. Reproduce the issue.
  17. Disable or delete the Web Access Layer you just created. Disabling the rule is recommended for future or repeated testing.

 The rule should look like this when done properly:

If the policy trace file is too large and the buffer overflows, it will overwrite the relevant transactions and only later transactions will be captured.

Limiting the destination address or URL will narrow the matching. Edit the policy tracing rule created:

  • Click the destination, and click Set.
  • Click Add a new object, and select Request URL.
  • In the URL field of the object, enter the URL in question (example.com). 
  • Click Apply > Set.

Policy tracing as a global option

CAUTION: Global policy tracking utilizes a high amount of CPU, and will also generate a large file. Symantec does not recommend this option for appliances that are in production.

  1. Navigate to Administration > Service Information > Policy Tracing.
  2. Adjust the slider for Enable Global Policy Tracing.
  3. Leave sub-selection at Proxy Traffic, unless otherwise directed.
  4. Click Save . . ., then Save Changes, then Close .
  5. Reproduce the issue as quickly as possible.
  6. Adjust the slider for Enable Global Policy Tracing.
  7. Click Save. . ., then Save Changes, then Close .
  8. See the section "Analyze the policy trace" for next steps.

Analyze the policy trace

  1. Open the policy trace file going to the advanced URL https://<ProxyIP>:port#/policy. You should see policy trace you named in Step 12 above.
    • If you enabled the global policy trace option, the file will be called default_trace.html.
    • If you used a rule, the file name will depend on the object you created.
  2. Click on the file to display it. The default extension is HTML, but the content of the file is plain text.
  3. A typical policy trace looks like:
start transaction ------------------- (1)
  <proxy> (2)
    miss :     time.utc=1800..2000
    miss :     category=(Alcohol, Auctions, Gambling) DENY (3)
    MATCH:     ALLOW (4)
  connection: service.name=HTTP client.address=127.0.01 proxy.port=#### (5)
  time: 2009-06-15 16:38:02 UTC
  GET http://www.example.com/ (6)
Referer: http://www.example.com/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (7)
  user: unauthenticated (8)
    url.category: Search Engines/Portals@Blue Coat (9)
  DSCP client outbound: 65
  DSCP server outbound: 65
stop transaction -------------------- (1)
  1. Start/Stop markers - These markers appear at the top and bottom of every transaction. A transaction is a single web request; for example, a "GET" request. Accessing one web site will generate many transactions since every object (html code, java, images, banners) is associated with a transaction.
  2. Layer markers -  A policy layer marker shows the evaluation for a policy layer. When a transaction is evaluated against the policy, every layer is part of that evaluation (unless it has a layer guard). Rules are evaluated from the top down, and once a rule matches, the proxy jumps to the next layer. If you have a layer with 30 rules, for example, but only the first 10 were evaluated, it's because the 10th rule was a match and the proxy didn't look at the rest of that layer
  3. Rule evaluated with a "miss" - The policy debug shows "miss" for this rule which means that this transaction did not match the condition. In this example, example.com did not match the BCWF categories "Alcohol", "Auctions," or "Gambling.
  4. Rule evaluated with a "MATCH" - This rule was a match so action was taken by the proxy. In this example, there are no conditions, it's simply a rule with an "Allow" action so everything would match that rule. Note that this is the last rule evaluated, which means that the proxy reached the end of the active policy.
  5. Connection information - This line shows connection details specific to that transaction. The service was HTTP, the source IP was 127.0.0.1, and that the port used to connect to the proxy was ####.
  6. The actual request - The most common type of requests are HTTP GET requests.  This example shows an HTTP GET request to www.google.com. A GET request are for object fetches, and "POST" requests are for browsers/applications sending data to the server.  The headers indicate the type of transaction:
    •   http://     HTTP web connection
    •   https://   Decrypted (SSL Intercepted) SSL web connection
    •   ssl://      Tunneled SSL connection
    •   tcp://      Tunneled TCP connection
  7. The user agent - This line is important when debugging a problem with a website. We can see that Firefox 3.0.11 made this request, which means it's the browser itself. Some user agents will make a request directly. Winamp, Microsoft Outlook, and iTunes are examples of user agents that go directly to the Internet. Those applications do not have full web support everything like a browser. Problems with applications can be found with policy tracing. Authentication is a big problem with many non-browser applications. The result is repeated requests to the proxy and users will see repeated pop-ups asking for authentication. 
  8. Authentication status - If an authenticated user was tied to the web request it would be seen in a policy trace as domain\username. Otherwise, it shows "unauthenticated".
  9. Category - url.category shows the matching category (or categories) for the URL accessed. If you see "unlicensed/unavailable," this means that the license for the content filtering database has expired. Unavailable can also mean that the site does not have a category or there was a communication error with the Webpulse service.

Proxy or network latency

Use policy checkpoint timing to discover possible proxy or network latency issues. For more information, see Understanding Policy Trace checkpoint timing.

Additional information

For some transactions, the policy trace will have "n/a" instead of "miss" or "MATCH".  "n/a" means the rule did not apply to that request type. Usually, the rule is specific to a protocol and the transaction was a different protocol. Another possibility for "n/a" is policy trying to match user or group specific rule but the transaction was unauthenticated.

CAUTION: Disable policy tracing after debugging is complete. Policy tracing is a resource intensive operation on the Edge SWG.

Additional Information

Powered by Wolken Software