Branch Connector war-room — first tool + proof field

1. Why a branch ticket is five commands

Operators collapse five Branch Connector failures into one sentence. The VM never registered. The Location is blank so ZIA never sees the site. A Traffic Forwarding rule sent Salesforce Direct. A ZIA URL rule blocked only this Location. The HA pair is INIT because the two configuration templates do not share a Location Name. Those are five first clicks, not one “restart both VMs.”

Official Help: Zscaler Branch Connector is a virtual machine that forwards branch traffic to the Zero Trust Exchange for Internet & SaaS (ZIA) and Private Access (ZPA). It is not an App Connector. It is not Cloud Connector (the public-cloud VM). It is not Zscaler Client Connector on a laptop. Name the product before you name the reboot.

Hero · five tiles, one ticket

2. Concept — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you reboot a healthy Active node at 02:00.

3. Path — ticket → first tool

Flowchart first. Do not open the ZIA policy editor, and do not reboot the hypervisor, until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the Cloud & Branch Connector Admin Portal. If you cannot recite the proof field, you are not ready to change anything.

5. Do — Side A → B → C

Side A proves the VM and the Location/tunnel. Side B proves where the packet was steered, then whether ZIA logged that Location. Side C proves the HA pair. On a messy Sev-2, do them in this order until a field lights up.

Side A — Connector Status, then tunnel / Location

1. Open Branch Connector Monitoring, not the hypervisor

   Path: Infrastructure → Connectors → Edge → Branch Connector Monitoring. Official: Accessing Cloud & Branch Connector Monitoring. The table lists Name, Group, Location, Geolocation, and Status. Filter the lab name you think is Pune — not a Cloud Connector in another region, not an App Connector.

2. Quote Status before you say “it’s down”

   Official Details article: operational Status is Active or Inactive. Inactive means stop. There is no Web Insights policy to chase. Help on sibling Cloud Connector deployments: an inactive connector after a correct-looking registration / policy fetch is a Support ticket — not a ZIA URL Allow. Quote Name + Status + Last Upgrade / First Deployed Time from Details if the node looks “new.”

3. Open Details and read Location + Configured Mode

   Path: click the Branch Connector in the Monitoring table → Details (official: Analyzing Branch Connector Details). Quote Location, Geo Location, Provisioning Template Name, Configured Mode, and the Routing section. A VM that is Active with a blank or unexpected Location will not produce ZIA Web rows for the site you named on the ticket.

4. If Location is set and the site is still dark, open Branch Connector Tunnel Insights

   Path: Logs → Insights → Branch and Cloud Connectors → Tunnel Insights → Logs. Official columns: Location, Tunnel Status, Tunnel Type, Tunnel Source IP. Filter Location + the UTC window. This is not ZIA Logs → Insights → Tunnel Insights (GRE / IPSec from a router). Wrong Insights family is a false “tunnel is fine.”

Path:            Infrastructure → Connectors → Edge → Branch Connector Monitoring
Name (lab):      Pune-BC-01
Status:          Active | Inactive
Location:        Pune-Branch          (Details + Monitoring)
Configured Mode: Gateway | Non-Gateway (One-Arm)
Then:            Logs → Insights → Branch and Cloud Connectors → Tunnel Insights
Quote:           Location + Tunnel Status + Tunnel Type + Tunnel Source IP
If Inactive:     do not hunt Web Insights Policy Action — prove registration first

Side B — Forwarding Method, then ZIA logs for the Location

1. Open Traffic Forwarding, not a new ZIA URL Allow

   Path: Infrastructure → Connectors → Edge → Forwarding Policy. Official: About Traffic Forwarding; Configuring Traffic Forwarding Rules. Read Rule Order, Rule Name, Rule Status, Location / Sublocation, Cloud & Branch Connector Groups, and Forwarding Method. Official methods: Direct, ZIA, ZPA, Drop, Local. ZIA forwards internet-bound traffic to Internet & SaaS. ZPA forwards application traffic to Private Access.

2. Prove the session, not only the rule

   Path: Logs → Insights → Branch and Cloud Connectors → Session Insights → Logs. Official columns include Location and Forwarding Type. Filter Location + the destination you care about. A rule that says ZIA while Session Insights Forwarding Type is Direct is the ticket — the packet never entered ZIA, so Web Insights will stay empty.

3. Only then open ZIA Web Insights for that Location

   Path: ZIA Logs → Insights → Web Insights → Logs. Filter Location = the Branch Connector Location (locations created in the Cloud & Branch Connector Admin Portal appear under ZIA Location Management; you can add sublocations there). Quote Policy Action (Allowed / Blocked / Cautioned) and Blocked Policy Name. Source: Web Insights Logs: Columns.

4. If Web is empty after Status Active + tunnel up + Forwarding Method ZIA

   You still do not Activate a Cloud App rule. Confirm the ZIA Location name matches Details Location character-for-character. Confirm you did not filter a sibling sublocation. Desk-side, ip.zscaler.com on one failing PC only proves that browser hit a Public Service Edge — it does not prove the Location object. Empty Web + Method Direct is forwarding. Empty Web + Method ZIA + down Tunnel Status is the tunnel.

Path:            Infrastructure → Connectors → Edge → Forwarding Policy
Rule Name:       Pune-Internet-ZIA
Rule Status:     Enabled
Forwarding Method: Direct | ZIA | ZPA | Drop | Local
Then:            Logs → Insights → Branch and Cloud Connectors → Session Insights
Quote:           Location + Forwarding Type + Rule Name
Then ZIA:        Logs → Insights → Web Insights → Logs
Filter:          Location = Pune-Branch
Quote:           Policy Action + Blocked Policy Name
If empty Web:    do not add a URL Allow — re-read Status, Location, Tunnel Status, Method

Side C — HA pair

1. Read HA Status on both nodes before you “fail over”

   Official Details: HA Status is Active, Standby, or INIT. A working pair is one Active + one Standby, same Location, same Group. Two Active with different Locations is two singles. Both INIT is not a pair yet — do not tell the floor “failover is ready.”

2. Prove the templates share a Location Name

   Path: Infrastructure → Connectors → Edge → Management → Branch Provisioning. Official: Configuring a Branch Connector Configuration Template. For high availability, configure each Branch Connector with separate configuration templates that use the same Location Name. HA Deployment Status is Active-Standby by default. Mismatched Location Name is the classic “we built HA and nothing failed over” ticket.

3. After a real failover, re-read Side A then Side B

   The new Active node must show Monitoring Status Active, Details Location still Pune-Branch, Tunnel Insights Tunnel Status healthy for that Location, and the first ZIA Web row on Location = Pune-Branch. Event logs (NSS Event feed) fire when a status change occurs — use them as a timestamp, not as a substitute for HA Status.

Path:            Infrastructure → Connectors → Edge → Branch Connector Monitoring
Pune-BC-01 HA Status:  Active
Pune-BC-02 HA Status:  Standby   (or INIT — say so)
Location both:   Pune-Branch
Templates:       Infrastructure → Connectors → Edge → Management → Branch Provisioning
Prove:           separate templates + same Location Name
HA Deployment Status: Active-Standby
After failover:  new Active + Tunnel Status + first Web Insights Location row

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

ZBC-01 — Prove connector Status

01:42 · P1. Pune branch: every desk lost internet. Hypervisor vCenter is green. L1 drafted a reboot of Pune-BC-01 and Pune-BC-02 “to be safe.”

First tool: Infrastructure → Connectors → Edge → Branch Connector Monitoring. Filter Name Pune-BC.

Proof field: Status. If both rows are Inactive, quote Inactive + time. That is registration / policy-fetch / connectivity to the Zero Trust Exchange — not a URL category. If one row is Active, you do not reboot the Active node to “match” the Inactive one. Next diamond is Location + tunnel, not a URL Allow.

ZBC-02 — Prove tunnel + Location

02:05 · P1. Monitoring Status = Active on Pune-BC-01. ZIA Web Insights filtered to Location Pune-Branch is empty. Someone pasted a ZIA GRE Tunnel Insights screenshot from the Mumbai router and said “tunnels are fine.”

First tool: Details Location, then Logs → Insights → Branch and Cloud Connectors → Tunnel Insights.

Proof field: Details Location must be Pune-Branch (or you just found the miss). Then quote Tunnel Status, Tunnel Type, Tunnel Source IP for that Location in the ticket minute. ZIA GRE / IPSec Insights is the router-tunnel lesson. Wrong family is a false healthy.

ZBC-03 — Prove Forwarding Method

02:22 · P2. Outlook on the Web works from Pune. Salesforce spins. L1 wants “another Allow for salesforce.com.” Monitoring Status is Active. Tunnel Insights for Pune-Branch looks healthy.

First tool: Infrastructure → Connectors → Edge → Forwarding Policy, then Session Insights.

Proof field: a higher Rule Order sending *.salesforce.com with Forwarding Method = Direct (or Drop). Session Insights Forwarding Type for that Location must agree. Direct means ZIA never saw the transaction — Web Insights cannot name a Blocked Policy Name that does not exist. Flip the method only under change-control after you quote the rule.

ZBC-04 — Prove ZIA logs for the site

02:40 · P2. A URL Filtering change shipped at 02:10. Only Pune complains. Other Branch Connector Locations still reach the same SaaS. Someone wants to reboot Pune-BC-01 “because it is this site.”

First tool: ZIA Logs → Insights → Web Insights → Logs. Filter Location = Pune-Branch, last hour.

Proof field: Policy Action = Blocked and Blocked Policy Name = the rule that shipped at 02:10. That name is the ticket. Change that one rule — or exclude this Location / Location Group — Activate, then re-read the same two columns on the same Location. A reboot will not rewrite Blocked Policy Name.

ZBC-05 — Prove the HA pair

03:05 · P1. Facilities powered off Pune-BC-01. Users stayed dark. The runbook said “Active-Standby, it will fail over.” Both templates exist.

First tool: Monitoring + Details on both VMs, then Branch Provisioning templates.

Proof field: Pune-BC-02 HA Status still INIT (or Active on a different Location). Templates use Pune-Branch vs Pune-Branch-02. Official HA requires separate templates with the same Location Name. Until that string matches, you do not have a pair. Fix the Location Name under change-control; then watch HA Status become Active / Standby and wait for Tunnel Status + the first Web row.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• Zscaler Help — What Is Zscaler Branch Connector? (VM that forwards branch traffic to ZIA / ZPA via the Zero Trust Exchange)
• Zscaler Help — Step-by-Step Configuration Guide for Zscaler Branch Connector
• Zscaler Help — Accessing Cloud & Branch Connector Monitoring (Name, Group, Location, Geolocation, Status, HA Status; path under Infrastructure → Connectors → Edge)
• Zscaler Help — Analyzing Branch Connector Details (Status Active / Inactive; HA Status Active / Standby / INIT; Location; Geo Location; Provisioning Template Name; Configured Mode; gateway vs non-gateway / one-arm; Routing)
• Zscaler Help — About Insights (Logs → Insights → Branch and Cloud Connectors: Session, DNS, Tunnel)
• Zscaler Help — About Insights Logs
• Zscaler Help — Analyzing Traffic Using Insights
• Zscaler Help — Tunnel Insights Logs: Columns (Location, Tunnel Status, Tunnel Type, Tunnel Source IP)
• Zscaler Help — Tunnel Insights Logs: Filters (Location filter)
• Zscaler Help — Session Insights Logs: Columns (Location, Forwarding Type)
• Zscaler Help — Session Insights Logs: Filters
• Zscaler Help — About Traffic Forwarding (Infrastructure → Connectors → Edge → Forwarding Policy; Forwarding Method Direct / ZIA / ZPA / Drop / Local; Rule Status)
• Zscaler Help — Configuring Traffic Forwarding Rules (Rule Order, Rule Name, Rule Status; Forwarding Method ZIA / ZPA; gateway-mode group / location scoping)
• Zscaler Help — Configuring a Branch Connector Configuration Template (Infrastructure → Connectors → Edge → Management → Branch Provisioning; HA = separate templates, same Location Name; HA Deployment Status Active-Standby)
• Zscaler Help — About Branch Configuration Templates
• Zscaler Help — NSS Feed Output Format: Event Logs (Event logs when a Cloud Connector or Branch Connector status change occurs)
• Zscaler Help — Understanding Zero Trust SD-WAN Devices (gateway vs non-gateway / one-arm language used with branch edge devices)
• Zscaler Help — About Insights (ZIA) (Logs → Insights)
• Zscaler Help — Web Insights Logs: Columns (Location, Policy Action, Blocked Policy Name)
• Zscaler Help — Web Insights Logs: Filters
• Zscaler Help — About Locations (Location objects created in the Cloud & Branch Connector Admin Portal)
• Zscaler Help — Configuring Sublocations (sublocations on a Cloud & Branch Connector parent Location)
• Zscaler Help — About Branch Connectors (ZPA) (VM images that forward to ZIA and ZPA; not App Connectors)
• Zscaler Help — About Branch Connector Groups

Related: Lesson 10 · ZPA App, Branch & Cloud Connectors · ZIA GRE + IPSec tunnels · Evidence desk — first tool + proof field · ZIA command center · Zscaler practice dashboard