Enable Policy Tracing
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.
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:
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, google.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 10.1.1.10, and that the port
used to connect to the proxy was 8080.
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:
o http:// Regular web connection
o https:// Decrypted (SSL Intercepted) SSL web connection
o ssl:// Non-decrypted SSL connection
o tcp:// Tunneled 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.
CAUTION: Disable policy tracing after debugging is complete. Policy tracing is a resource
intensive operation on the Edge SWG.