zpa-create-forwarding-policy-rule

What this skill does

# 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:

```text
# 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:**

```text
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 co