zpa-create-forwarding-policy-rule

name

zpa-create-forwarding-policy-rule

description

Create ZPA client forwarding policy rules that control how traffic is routed from the Zscaler Client Connector. Supports actions: BYPASS (direct internet), INTERCEPT (route through ZPA), INTERCEPT_ACCESSIBLE (route only if reachable). Conditions support APP, APP_GROUP, SAML, SCIM, SCIM_GROUP, PLATFORM, COUNTRY_CODE, POSTURE, TRUSTED_NETWORK, and CLIENT_TYPE. Use when an administrator asks: 'Bypass ZPA for specific apps', 'Route traffic directly', or 'Create a forwarding exception.'

ZPA: Create Forwarding Policy Rule

Keywords

forwarding policy, forwarding rule, bypass zpa, intercept traffic, direct access, client forwarding, traffic routing, bypass rule, split tunnel, forwarding exception, zpa bypass

Overview

Create ZPA client forwarding policy rules that control how the Zscaler Client Connector routes traffic. Forwarding policies determine whether traffic for specific applications is intercepted by ZPA (tunneled through the Zscaler cloud), bypassed (sent directly to the internet), or conditionally intercepted.

Use this skill when: An administrator asks to bypass ZPA for certain applications, create split-tunnel exceptions, route traffic directly for specific users or platforms, or configure conditional forwarding rules.

---

Action Types

Action	Description	Use Case
BYPASS	Traffic goes directly to the destination, skipping ZPA entirely	Apps that don't need ZPA tunneling (e.g., video conferencing, local printers)
INTERCEPT	Traffic is routed through ZPA (tunneled via the Zscaler cloud)	Default for private applications that need ZPA access
INTERCEPT_ACCESSIBLE	Traffic is intercepted only if the destination is reachable through ZPA	Hybrid apps that may or may not be behind ZPA depending on the user's location

---

Forwarding Policy Design Rules (baseline alignment)

Reference: ZPA Baseline Recommendations v1.0 §Client Forwarding Policy Recommendations.

1. Always use "Only Forward Allowed Applications" — never the default "Forward to ZPA". The default exposes the entire ZPA application list to every ZCC-enrolled device, regardless of access-policy permissions.
2. Prefer FQDN segments to IP/CIDR. Use IP only when DNS-based discovery is not feasible (legacy apps).
3. Reject overly broad scope. Never use *.* wildcards or CIDRs ≥ /16 (e.g. 10.0.0.0/8) in forwarding INTERCEPT rules — break them into smaller FQDN or per-subnet segments.
4. Pair forwarding rules with SCIM_GROUP scoping so users only see and intercept apps they're authorized for.
5. Order rules from most specific to least specific. Place private-app INTERCEPT rules above BYPASS and discovery rules.

Canonical Bypass List (recommended)

Reference: doc page 36. These destinations should be bypassed (not intercepted) in every ZPA tenant to avoid breaking ZCC operation, OS updates, IdP/SSO sign-in, and certificate validation:

# Microsoft 365 / Entra ID / Intune / Windows Update
*.office365.com
*.microsoft.com
login.microsoftonline.com
*.windowsupdate.microsoft.com

# Apple / iCloud / macOS updates
*.apple.com
*.icloud.com

# Certificate revocation
ocsp.*
crl.*

# Optional — only if Workspace traffic isn't intentionally tunneled
*.google.com

# EDR / AV vendor update endpoints
# (CrowdStrike Falcon, SentinelOne, Microsoft Defender, etc. — confirm with the vendor list)

When creating bypass rules for these, use one rule per logical group (Microsoft, Apple, CRL/OCSP, EDR) so they're easy to audit and update.

---

Condition Object Type Reference

Forwarding policies support the same condition object types as access policies. Each condition block must contain a single object type. Multiple condition blocks are ANDed together.

Value-Based Object Types (use values)

Object Type	Description	Values
APP	Application segments	Application segment IDs
APP_GROUP	Segment groups	Segment group IDs
CLIENT_TYPE	Client connector type	zpn_client_type_zapp, zpn_client_type_exporter, zpn_client_type_browser_isolation, zpn_client_type_ip_anchoring, zpn_client_type_edge_connector, zpn_client_type_branch_connector, zpn_client_type_zapp_partner
MACHINE_GRP	Machine groups	Machine group IDs
LOCATION	Locations	Location IDs

Entry-Values Object Types (use entry_values with lhs/rhs)

Object Type	LHS	RHS
SAML	SAML attribute ID	Attribute value to match
SCIM	SCIM attribute header ID	Attribute value to match
SCIM_GROUP	Identity Provider ID	SCIM group ID
PLATFORM	linux, android, ios, mac, windows	"true" or "false"
COUNTRY_CODE	ISO 3166 Alpha-2 code (US, CA, GB)	"true" or "false"
POSTURE	Posture profile posture_udid	"true" or "false"
TRUSTED_NETWORK	Trusted network network_id	"true" or "false"

---

Workflow

Step 1: Gather Requirements

Ask the administrator:

Required:

• Rule name
• Action: BYPASS, INTERCEPT, or INTERCEPT_ACCESSIBLE
• Which applications or application groups should this rule apply to?

Optional:

• Description
• Who should this apply to? (specific users/groups or everyone)
• Platform restrictions (e.g., only bypass on Windows)
• Location or network conditions

Common scenarios:

• "Bypass ZPA for Zoom/Teams traffic" -> BYPASS with specific APP or APP_GROUP
• "Route all traffic through ZPA for contractors" -> INTERCEPT with SCIM_GROUP condition
• "Direct access when on corporate network" -> BYPASS with TRUSTED_NETWORK condition

---

Step 2: Look Up Required IDs

For application scoping:

zpa_list_application_segments()
zpa_list_segment_groups()
```text

**For identity conditions:**

```text
get_zpa_scim_group(search="<group_name>")
get_zpa_saml_attribute(search="<attribute_name>")
```text

**For trusted networks:**

```text
get_zpa_trusted_network(search="<network_name>")
```text

**For posture profiles:**

```text
get_zpa_posture_profile(search="<profile_name>")
```text

---

### Step 3: Build Conditions and Create the Rule

```text
zpa_create_forwarding_policy_rule(
  name="<rule_name>",
  action_type="BYPASS",
  description="<description>",
  conditions=<conditions_payload>
)
```text

The conditions format is identical to access policy rules. See the examples below.

---

### Step 4: Verify

```text
zpa_get_forwarding_policy_rule(rule_id="<returned_rule_id>")
```text

Present the rule summary including action, conditions, and scope.

---

## Ready-to-Use Examples

### Example 1: Bypass ZPA for a Segment Group

Bypass ZPA tunneling for all applications in a segment group (e.g., video conferencing apps).

**Step 1: Find the segment group**

```text
zpa_list_segment_groups()
```text

**Step 2: Create rule**

```text
zpa_create_forwarding_policy_rule(
  name="Bypass Video Conferencing",
  action_type="BYPASS",
  description="Send video conferencing traffic directly, bypassing ZPA tunnel",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "APP_GROUP",
          "values": ["<video_conferencing_segment_group_id>"]
        }
      ]
    }
  ]
)
```text

---

### Example 2: Bypass for Specific Users on Trusted Network

When users are on the corporate trusted network, bypass ZPA and go direct.

**Step 1: Look up IDs**

```text
get_zpa_trusted_network(search="Corporate_WiFi")
get_zpa_scim_group(search="Office_Workers")
```text

**Step 2: Create rule**

```text
zpa_create_forwarding_policy_rule(
  name="Direct Access on Corporate Network",
  action_type="BYPASS",
  description="Bypass ZPA when on corporate trusted network",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "TRUSTED_NETWORK",
          "entry_values": [
            {"lhs": "<corporate_wifi_network_id>", "rhs": "true"}
          ]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "SCIM_GROUP",
          "entry_values": [
            {"lhs": "<idp_id>", "rhs": "<office_workers_group_id>"}
          ]
        }
      ]
    }
  ]
)
```text

**Logic:** User must be on the corporate trusted network AND be in the Office_Workers group.

---

### Example 3: Intercept All Traffic for Contractors

Force all contractor traffic through ZPA regardless of application.

**Step 1: Look up contractor group**

```text
get_zpa_scim_group(search="Contractors")
```text

**Step 2: Create rule**

```text
zpa_create_forwarding_policy_rule(
  name="Intercept Contractor Traffic",
  action_type="INTERCEPT",
  description="Route all contractor traffic through ZPA for security",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "SCIM_GROUP",
          "entry_values": [
            {"lhs": "<idp_id>", "rhs": "<contractors_group_id>"}
          ]
        }
      ]
    }
  ]
)
```text

---

### Example 4: Platform-Specific Bypass

Bypass ZPA for specific applications only on Linux and Android devices.

```text
zpa_create_forwarding_policy_rule(
  name="Bypass Dev Tools on Linux/Android",
  action_type="BYPASS",
  description="Development tools bypass ZPA on Linux and Android",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "APP_GROUP",
          "values": ["<dev_tools_segment_group_id>"]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "PLATFORM",
          "entry_values": [
            {"lhs": "linux", "rhs": "true"},
            {"lhs": "android", "rhs": "true"}
          ]
        }
      ]
    }
  ]
)
```text

---

### Example 5: INTERCEPT_ACCESSIBLE for Hybrid Apps

Use `INTERCEPT_ACCESSIBLE` for applications that may or may not be reachable through ZPA depending on the user's location.

```text
zpa_create_forwarding_policy_rule(
  name="Conditional Intercept for Hybrid Apps",
  action_type="INTERCEPT_ACCESSIBLE",
  description="Route through ZPA only if destination is reachable via ZPA connectors",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "APP_GROUP",
          "values": ["<hybrid_apps_segment_group_id>"]
        }
      ]
    }
  ]
)
```text

**When to use:** The application exists both on the corporate network (reachable via ZPA) and on the public internet. `INTERCEPT_ACCESSIBLE` routes through ZPA if connectors can reach it, otherwise falls back to direct access.

---

### Example 6: Combined SAML + Platform + Country

Bypass ZPA for a SAML-identified group, only on Windows, only from the US.

```text
zpa_create_forwarding_policy_rule(
  name="US Windows Bypass for Finance",
  action_type="BYPASS",
  description="Finance team on Windows in the US bypasses ZPA for specific apps",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "APP_GROUP",
          "values": ["<finance_apps_segment_group_id>"]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "SAML",
          "entry_values": [
            {"lhs": "<saml_group_attr_id>", "rhs": "Finance"}
          ]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "PLATFORM",
          "entry_values": [
            {"lhs": "windows", "rhs": "true"}
          ]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "COUNTRY_CODE",
          "entry_values": [
            {"lhs": "US", "rhs": "true"}
          ]
        }
      ]
    }
  ]
)
```text

**Logic:** App must be in the Finance segment group AND user has SAML group "Finance" AND platform is Windows AND country is US.

---

## Forwarding vs Access Policy Comparison

| Aspect | Access Policy | Forwarding Policy |
|---|---|---|
| **Purpose** | Who can access apps | How traffic reaches apps |
| **Actions** | `ALLOW`, `DENY`, `REQUIRE_APPROVAL` | `BYPASS`, `INTERCEPT`, `INTERCEPT_ACCESSIBLE` |
| **Evaluated when** | After forwarding decision | Before access decision |
| **Tool** | `zpa_create_access_policy_rule` | `zpa_create_forwarding_policy_rule` |
| **Condition types** | Same | Same |

**Evaluation order:** Forwarding policy is evaluated first (determines routing), then access policy is evaluated (determines authorization).

---

## Edge Cases

### Bypass with No Conditions

A forwarding rule with no conditions applies globally:

```text
zpa_create_forwarding_policy_rule(
  name="Global Bypass",
  action_type="BYPASS",
  conditions=[]
)
```text

This bypasses ZPA for ALL traffic, which is almost never desired. Always scope with conditions.

### Conflicting Forwarding and Access Rules

If traffic is bypassed by a forwarding rule, the access policy rule is never evaluated for that traffic. Be careful not to bypass traffic that requires access policy enforcement.

### Listing Existing Forwarding Rules (opt-in)

Do **not** pre-list forwarding rules before every create. New ZPA
forwarding rules are appended at the end of the policy by default;
pre-listing adds a round trip, gives no useful information for the
typical case, and invites fan-out retries when the list comes back
empty on a fresh tenant.

Run the listing **only** when the admin explicitly asks about ordering,
duplicate names, or wants to inspect existing rules:

```text
zpa_list_forwarding_policy_rules()
```text

---

## Quick Reference

**Tools used:**

- `zpa_list_application_segments()` -- find application segments
- `zpa_list_segment_groups()` -- find segment groups
- `get_zpa_scim_group(search)` -- look up SCIM group IDs
- `get_zpa_saml_attribute(search)` -- look up SAML attribute IDs
- `get_zpa_trusted_network(search)` -- look up trusted network IDs
- `get_zpa_posture_profile(search)` -- look up posture profile UDIDs
- `zpa_create_forwarding_policy_rule(name, action_type, conditions)` -- create the rule (no pre-flight needed)
- `zpa_list_forwarding_policy_rules()` -- **only** when the admin explicitly asks about ordering or wants to inspect existing rules
- `zpa_get_forwarding_policy_rule(rule_id)` -- verify the rule

**Condition logic:**

- Multiple condition blocks = AND (all must match)
- Multiple entry_values within a block = OR (any can match)
- Separate condition blocks per object type

**Actions:** `BYPASS`, `INTERCEPT`, `INTERCEPT_ACCESSIBLE`