Secure Access Help Center

Troubleshoot Private Access Rules

To troubleshoot private access rules:

General Troubleshooting Tips

  • Navigate to the Overview page for possible status notifications
  • Use Activity Search to look for logged events

Problems While Creating a Rule

Next button is not available

The Next button is not available until you give the rule a name and then click out of the Rule name field.

Problems After Creating a Rule

Traffic is unexpectedly blocked

A few things to try, either to temporarily suspend problematic blocks, or to narrow down the cause:

  • Verify that any existing rule allowing the traffic is enabled.
  • To allow immediate access to a necessary destination that is being blocked, you can create a new access rule allowing the traffic (using the "Enter manually" option for source and/or destination if necessary).
  • You can disable intrusion prevention (IPS) for a rule.
  • You can disable intrusion prevention (IPS) on the Rule Defaults page, which disables it for all rules that are configured to use the default setting for IPS.
  • You can disable decryption for intrusion prevention (IPS) for all rules in Global Settings, which effectively disables intrusion prevention.
  • If a Zero Trust connection is unsuccessful:
    • Make sure that zero trust connections are enabled for the resource.
    • Check the Traffic Steering page (Connect > End User Connectivity > Zero Trust) for absence of, exceptions to, or conflicts with the applicable Private Resource configuration.
    • Endpoint requirements as specified in the applicable zero trust posture profile.
    • Posture profiles are rule-matching criteria, not security criteria. Try specifying posture profile(s) that have no requirements and see if the traffic matches.
    • For browser-based connections, you may need to configure a custom host header for the resource in order to forward traffic correctly. See Add a Private Resource.
  • If a VPN connection is unsuccessful, ensure that:
    • There is a VPN traffic steering rule for the applicable network address space
    • There is an access rule allowing the traffic (either for a configured private resource or for the applicable network address space)
    • If a Private Resource is configured for the resource, it must permit VPN connections.
  • Assess whether the following situation applies: App A is dependent on App B, but App B is not included in the private resource or access rule configurations.
  • If your organization is using Resource Connectors, see Troubleshoot Resource Connectors and Connector Groups.
  • If all traffic is blocked, make sure you have not inadvertently blocked traffic to a destination that is required infrastructure for managing access. For example, make sure there is no Geolocation rule that blocks traffic to your identity services (IdP) provider.

Traffic is unexpectedly allowed

A few things to try, either to block problematic traffic, or to narrow down the cause:

  • Because traffic to private destinations is blocked by default, this means there is one or more existing rules that explicitly allows this traffic. You will need to find any such rules.
  • Make sure the applicable rule is enabled (toggle at top of rule page)
  • Make sure IPS is not disabled in the rule default or in the rule. Any rule tagged to use the default setting continues to use the default setting even if the default setting has changed.
  • Make sure IPS Decryption is not disabled in Global Settings.
  • Check each rule component (rule action and each posture and security control) to be sure each specifies the behavior you expect.
  • Check to see that an expected exception to connect to the private resource appears as expected on the Traffic Steering page (Connect > End User Connectivity > Zero Trust.)
  • To immediately block access to a problem destination that is unexpectedly being allowed, you can create a new access rule (using the "Enter manually" option for source and/or destination if necessary) and put this rule at or near the top of the rule list on the Policy page so it hits before more general rules that would otherwise apply to the traffic.

Rule does not match traffic as expected

Some things to try:

  • Check the private resource configuration.
  • Make sure that the internal address for the private resource does not duplicate or overlap with any other private resource or IP address or CIDR block typed directly into the destination in an access rule. For example, if Private Resource A is defined with a CIDR block as the internal address, and Private Resource B is defined with an IP address that is included in the same CIDR block.
  • Check the sources and destinations configured in the rule to be sure they include the problematic source and destination.
  • Endpoint requirements as specified in posture profiles are matching criteria, not security criteria. Try specifying posture profile(s) that have no requirements and see if the traffic matches.
  • Check other rules in the rule order; traffic may be hitting a different rule than the one you expect.
  • If you have deployed the client on iOS devices, see unique matching information in the "Guidelines and Limitations" section of the Set up the Zero Trust Access App for iOS Devices topic.
  • If you have configured a Private Resource, then modified the automatically created entry on the Traffic Steering page (for example, to exclude subdomains from zero-trust access), then modified addresses on the Private Resource configuration page, the resource addresses are not updated for traffic steering purposes. You must manually update the address(es) on the Traffic Steering page.

Global Settings for Private Access Rules < Troubleshoot Private Access Rules > Get Started with the Cisco Assistant

Updated 2 days ago