0% found this document useful (0 votes)
19 views4 pages

Enable Policy Tracing

Uploaded by

ankit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views4 pages

Enable Policy Tracing

Uploaded by

ankit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

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 wlll block all traffic.

1. Open the Visual Policy Manager.


2. Click Policy > Add Web Access Layer.
3. Enter a name and click OK.
4. Right-click the source, and then click Set.
5. Click New, 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 host.
7. Click Add > Close > OK.
8. In the Action column, right-click Deny, and then click Delete. The action should now
be "None."
9. in the Track column, right-click None, and then click Set.
10. Click New > Trace.
11. Choose Verbose tracking, enable Trace file, and enter a file name.
12. Click OK, and click OK again.
13. 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.
14. Click the Install policy tab.
15. Reproduce the issue.
16. 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:

 Right-click the destination, and click Set.


 Click New, and select Request URL.
 In the domain field of the object, enter the domain of the URL in question
(example.com).
 Click Add > Close > OK.

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 Configuration > Policy > Policy Options.


2. Select Trace all policy execution.
3. Click Apply.
4. Reproduce the issue as quickly as possible.
5. Disable policy tracing.
6. Click Apply.
7. 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>:8082/policy.
You should see policy trace you named in Step 11 above.
o If you enabled the global policy trace option, the file will be called
default_trace.html.
o 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=10.1.1.10 proxy.port=8080 (5)
time: 2009-06-15 16:38:02 UTC
GET http://www.google.com/ (6)
Referer: http://www.google.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, 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.

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.

You might also like