ZPA Client Forwarding Policy allows you to control which application segment definitions get downloaded to the client, and how the client behaves.
When you define a client forwarding policy, you have 3 actions that can be applied to an application segment :-
Forward to ZPA - Allows the the application segment to be downloaded to the client. The client will forward the application to ZPA cloud, where policy will be applied.
e.g. application segment = centos.welshgeek.net:80 - user will DNS resolve this, ZAPP will intercept the DNS request and resolve it to 100.64.0.0/16 address. Client would connect to IP address on port 80 and traffic forwarded to the ZPA cloud for policy to be applied.
Bypass ZPA - Allows the the application segment to be downloaded to the client. The client will bypass the ZPA cloud entirely for the application.
e.g. application segment = centos.welshgeek.net:80 - user will DNS resolve this, ZAPP will implicitly bypass the DNS to the local DNS server, which will resolve against Internet DNS
Only Forward Allowed Applications - The Access Policy is evaluated for the application segments. Only Allowed application segments are downloaded in the client policy for interception.
e.g. application segment = centos.welshgeek.net:80 .
user firstname.lastname@example.org is denied access in access policy
user email@example.com is allowed access in access policy
When user firstname.lastname@example.org requests the application, they will not have a definition for the application, so would attempt to “go direct”
When user email@example.com requests the application, they ZAPP will intercept the DNS request and resolve it to 100.64.0.0/16 address. Client would connect to IP address on port 80 and traffic forwarded to the ZPA cloud for policy to be applied.
However - there is are two important considerations to this “Only Forward Allowed Applications” to plan in your application segment policy.
- In the above example user firstname.lastname@example.org is denied access to the application, so does not download the application segment. However, if there is a wildcard application segment (*.welshgeek.net) which is defined for the user to download - when the user attempts to access centos.welshgeek.net:80, this would “match” against the *.welshgeek.net wildcard discovery application segment. The traffic would then be intercepted and forwarded to the ZPA cloud, where policy would apply and deny access to the application. If the expectation is for this application to “bypass” ZPA, then this would not be the outcome.
- DNS SRV records - similar to #1, however DNS SRV records return pointers to services (e.g. _ldap._tcp.welshgeek.net returns a pointer to domain-controller.welshgeek.net:389). DNS would still match the wildcard discovery and return the answer to the user. In some cases (e.g. MS Teams/Skype uses _sip._tls.welshgeek.net.) you might explicitly want this to bypass and resolve to the internet. You should use a “bypass” policy rather than a “Only Forward Allowed Applications”
Careful consideration is necessary to get the desired outcome when using “Only Forward Allowed Applications” policy when combined with a “wildcard discovery” application segment.
This video https://youtu.be/0GFLvltznTE provides working examples of the behaviours and the outcomes of different policies.