Product documentation
Citrix SecurSpaces™
View PDF

Monitor and troubleshoot network policies

September 18, 2026
Contributed by: 
T

Every network policy behavior feeds the Audit dashboard, which is your primary tool for understanding and fixing policy effects.

  • Monitored traffic generates log events for all outgoing connections.
  • Restricted traffic logs every blocked request, so you can see exactly which destination was denied.
  • Inspected traffic reports inspected TCP content and dropped UDP traffic.

Find the traffic logs

Network events appear in the Audit dashboard for the project, in the Live system event log.

  1. Open Audit for the project. You need the Security permission set to Access or Manage.
  2. Find the network events, for example DNS requests showing the domain a workspace tried to reach.
  3. Select Filter to narrow the log by event type, severity, workspace, user, or date, or use the search bar to find a specific destination.
  4. Expand a row to see the event’s full details, including the description of what triggered it.

Use a monitor policy to build an allow list

A monitor-only policy is the recommended way to discover what a workspace needs before you lock it down.

  1. Apply the Monitor Traffic (default) policy, or any policy with restriction turned off, to the workspace.
  2. Use the workspace normally so its tools generate their usual network calls.
  3. In the audit log, review the network events to see which domains and IP addresses the workspace actually reached.
  4. Create a restrict policy and add those destinations to the allow list. See Build the allow list.
  5. Switch the workspace to the restrict policy. Any destination you missed now appears as a blocked request in the same audit log, so you can refine the allow list and repeat.

Tip:

Attached resources, such as repositories, SSH services, and HTTP services, are always reachable under a restrict policy. You do not need to add them to the allow list.

Common issues

An application cannot reach a service it needs

The destination is probably missing from the allow list. Check the Audit dashboard for the blocked request, then add the domain or IP address to the policy. If the service uses subdomains, turn on Include subdomains.

A tool that uses UDP stops working after a policy is applied

Any attached network policy — monitor, restrict, or inspect — drops non-DNS UDP traffic by design. DNS still works, but other UDP-based protocols do not. If a workload depends on UDP, it cannot run in a workspace that has a network policy attached.

See What happens when a policy is attached.

A workspace ignores the policy you selected

A parent scope is probably enforcing a different policy, or the policy was applied automatically from project settings. Check the network policy overview to see which scope enforces the inherited policy. Only security officers, organization owners, and project owners can change a workspace’s policy.

Monitor and troubleshoot network policies
September 18, 2026
Contributed by: 
T
September 18, 2026
Contributed by: 
T

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.