Order of Operations

Hello,
Is there an order of operations I need to be aware of when considering Access Policies and Client Forwarding Policies? Both allow me to specify segment groups and additional criteria such as users or groups, but which one processes first? For example, if an access policy is set to deny an application for a specific user group, will the a client forwarding profile with the same app included ever even be hit? Or…lets say I want to include an app into a client forwarding profile but that same app is not included into an access policy, what would the result be of that?

Hi jo-76,
The client forwarding policy defines the conditions under which the Zscaler client connector will process application traffic through ZPA or bypass ZPA. Access policies apply only to traffic that is being processed through ZPA and are used to control the conditions under which a connection attempt is allowed. So in that sense, the forwarding policy is evaluated first.

In your first example, if a client forwarding policy rule is configured to bypass ZPA for an app segment, the fact that there is deny rule for the same app segment in the access policy is irrelevant because the connection is never considered by ZPA. In your second example, if you create a forwarding policy rule to explicitly forward an app segment to ZPA (or just don’t have a rule to bypass ZPA since the default rule will forward to ZPA) and there is no access policy to allow the connection, the connection will be dropped at the client connector.

Bypassing ZPA with a client forwarding policy rule would allow a user to potentially still connect to the application via another network path (e.g. if they are connected to the corporate network and can reach the app directly). However, if the application is defined in ZPA and not bypassed by segment configuration or client forwarding policy, then ZPA access policies will control whether or not a user can connect to the app even if the app is reachable outside of ZPA.

Thank you Delmar for providing that feedback.

To dig in further though, I realize my first example may seem irrelevant in the sense that it wont be going through ZPA, but I would like to know which mechanism stops that flow through ZPA. Is it the access policy deny function or the client forwarding profile bypass function. It is important to know the order of operations to understand the ordering of the logic processing.

It sounds like from your explanation above that the access policy deny rule would have no effect due to the bypass on CFP, so in that sense I suppose the client forwarding profile comes first (just want to be double sure)?

I guess what I’m really trying to understand is, do we need an access policy in place to enable it to move to client forwarding logic? Or, can we create a client forwarding bypass rule without having the that app allowed in an access policy?

The forwarding decision is made on the client. Relevant forwarding policies are pushed to the client so it can make the decision to (not) forward traffic to ZPA. You don’t need an access policy in order to have the forwarding policy active

If you have an “only forward allowed” forwarding policy, the cloud will evaluate the access policy (based on the current client condition) and make the proper adjustments. Note that this doesn’t create a “bypass this AppSegment” rule; it completely removes the AppSegment for that client, which can lead to very unexpected behavior. Long story short: avoid using “only forward allowed” policies and use explicit bypasses instead. Especially if you don’t understand why :wink:

1 Like

My plan is to create a hierarchical Client Forwarding Profile map where the first CFP entry has more specific apps defined and is set to “forward to ZPA” and the second CFP entry has wildcard apps defined and is set to “Bypass ZPA”.

This will allow workstations (when on-net) access to a small subset of apps over ZPA while the majority of apps can be bypassed. That small subset is in remote M&A market that are non-routable.

I do not intend to use the “Only Forward Allowed Apps” option.

So if I understand the feedback so far, if there is a CFP match which results in a “Forward to ZPA” action, the traffic is still subject to Access Policy processing? (Question 1)

And if there is a CFP match that results in a “Bypass ZPA” action, then then Access Polices are irrelevant as the traffic is not tunneled? (Question two)

And if there is no CFP match at all, then the traffic remains tunneled and is subject to Access Policy processing? (Question 3)

Does this sound correct, no unexpected behavior as long as all criteria is built correctly?

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.