Objective

Verify that the branch z40 routes:

• Non-SaaS internet traffic through the tunnels (backhauled to the concentrator), and
• SaaS applications directly out the branch WAN (no backhaul),

using the Net Balancer’s Branches and SAAS APPS tabs, and validate via interface counters and syslog.

Prerequisites

• Admin access to zWAN Director.
• A z40 (“branch”) onboarded and online.
• At least one WAN interface up (e.g., WAN00) and at least one IPSEC tunnel up (e.g., IPSEC01, IPSEC03).
• A Windows or Linux client on the z40 LAN.
• You can reach a few common SaaS sites (choose any that exist in your SAAS APPS list—e.g., Microsoft 365/Teams, Zoom, Google Workspace).

Baseline (5 min)

1. In Director, open: Edge Controllers > [Your Device] > Analytics > Statistics > Interfaces.
2. Note current Tx/Rx for:
   • IPSECxx (your tunnel interface, e.g., IPSEC01)
   • WANxx (your internet uplink, e.g., WAN00)
3. From the client, open any non-SaaS site (e.g., example.com) just to see normal traffic counters increment.

Configure Branch Gateways (Branches tab)

Path: Edge Controllers > [Your Device] > Network > Net Balancer > BRANCHES
Button: ADD GATEWAY (uses the dialog you showed)

You will create three gateway types (as needed in your environment):

A) Internet Breakout (backhaul default via tunnels)

This tells the branch to route normal internet traffic through the tunnels to the concentrator by default.

1. Click ADD GATEWAY.
2. Type: select Internet Breakout.
3. In Link Configuration:
   • Gateway IP Address: pick your IPSEC gateway (e.g., IPSEC01).
   • Local Interface: select the appropriate local interface used with that path (choose per your deployment).
   • Weight: leave default or set per policy.
   • Timeout Coefficient: leave default (e.g., x1 (Fast)).
4. Click ADD, then ensure the Configured Status toggle is ON for this gateway.

Notes from your guidance: choosing IPSEC00/IPSEC01 here causes “regular” (non-SaaS) internet traffic to be backhauled to the concentrator by default.

B) Tunnel (define which WANs build/maintain the tunnels)

This tells the branch which local WANs are used to establish/maintain tunnel heartbeat.

1. ADD GATEWAY → Type: Tunnel.
2. Gateway IP Address / Local Interface: select your WANxx (e.g., WAN00, optionally add another for redundancy with its own weight).
3. Set Weight / Timeout Coefficient as desired.
4. ADD and enable it.

C) SAAS (direct internet breakout for selected SaaS apps)

This tells the branch which local path to use for SaaS traffic (direct to internet, no tunnel backhaul).

1. ADD GATEWAY → Type: SAAS.
2. Gateway IP Address / Local Interface: select WANxx interface(s) to use for SaaS (e.g., WAN00, optionally WAN01 with its own weight).
3. Set Weight / Timeout Coefficient as desired.
4. ADD and enable it.

All three gateway types use the same fields (Gateway IP Address, Local Interface, Weight, Timeout Coefficient) in the dialog you shared.

Select SaaS Applications (SAAS APPS tab)

Path: Edge Controllers > [Your Device] > Network > Net Balancer > SAAS APPS

1. In the SAAS APPS tab, select (check) a few well-known apps that appear in your list (e.g., Microsoft 365/Teams, Zoom, Google).
2. Save/Apply (if a control is present).

Per your note: simply selecting apps here makes those apps bypass the tunnels and use the SAAS gateway (i.e., WAN breakout).

(Optional) Additional steering with Balancing Rules

Path: Net Balancer > BALANCING RULES

If you need steering beyond the built-in SaaS list, you can create rules using the Flow Classification matchers you’ve already provided (e.g., FQDN, Web Category, DPI, IP/Port).

• Example: route a specific FQDN (e.g., a software update domain) to SAAS (WAN), while leaving everything else backhauled.

(If you want me to write the exact clicks for each matcher, send a screenshot of the “New Rule” dialog and I’ll mirror its fields exactly.)

Validation

1) Non-SaaS traffic should backhaul (tunnel path)

1. From the client, browse a non-SaaS site (anything not selected in SAAS APPS).
2. In Director, open Analytics > Statistics > Interfaces for the device.
3. Expect:
   • IPSECxx counters climb (Tx/Rx).
   • WANxx may show uplink activity (since the tunnel rides WAN), but the distinguishing increase should be on IPSECxx versus SAAS test below.

(Optional) On the client, run tracert/mtr to observe a path consistent with backhaul (exact hops depend on your ISP and concentrator visibility).

2) SaaS traffic should break out locally (WAN path)

1. From the client, actively use one of the SaaS apps you enabled—e.g., open office.com/teams.microsoft.com, start/join a Zoom meeting, or use Google Drive.
2. In Interfaces stats:
   • WANxx (e.g., WAN00) shows a clear increase while IPSECxx does not climb in proportion to this SaaS usage.
3. Repeat with a second SaaS app to confirm consistent behavior.

3) (Optional) Failover / Weight bias checks

• If you’ve added more than one WAN to the SAAS gateway with different Weights, you should see usage skew toward the higher weight.
• If you physically/safely down WAN00, SaaS should flow out the remaining WAN you added to the SAAS gateway (if present).
  You stated re-convergence is immediate; no hold-down timer is configurable.

4) Logs

• Check Edge Controllers > [Device] > System > Logs > Syslog.
  • If your build emits “Net Balancer”/load-balancer messages, you can filter on them; otherwise rely on the interface counters + observable app behavior as the primary proof (per your note).

Rollback / Cleanup

• SAAS APPS: unselect the apps you enabled (SaaS will resume the default path).
• BRANCHES: toggle Configured Status OFF (or delete) for the SAAS gateway if you want to disable SaaS breakout entirely.
• Leave Tunnel and Internet Breakout gateways in place for your normal policy, or disable per your lab plan.

Notes & Tips

• The BRANCHES tab is where you declare the four gateway types (Branch, Internet Breakout, SAAS, Tunnel) via ADD GATEWAY; each uses the same “Link Configuration” fields you showed (Gateway IP Address, Local Interface, Weight, Timeout Coefficient).
• Per your mapping:
  • Internet Breakout: point to IPSECxx so non-SaaS traffic backhauls to the concentrator by default.
  • Tunnel: use WANxx to define which WANs keep the tunnels/heartbeat up.
  • SAAS: use WANxx so selected SaaS apps go direct to internet.
• You asked to avoid Global Applications for this POC; interface counters (WANxx vs IPSECxx) and Syslog are the recommended proof points here.