Tunnel Failover (z40 ↔ vGR) — WAN00 (wired) primary, WAN03 (4G) & WAN04 (5G) backups

Objective

Demonstrate that when the primary wired WAN (WAN00) at the branch fails, the z40 automatically fails over its VPN connectivity to cellular WANs (WAN03 = 4G, WAN04 = 5G), and then fails back to WAN00 when restored—without manual intervention.

Topology & Mappings

• Branch: 1× z40 with three uplinks
  • WAN00 = wired Ethernet (primary) → IPSEC00
  • WAN03 = 4G (backup) → IPSEC01
  • WAN04 = 5G (backup) → IPSEC02
• Datacenter: 1× vGR concentrator.
• One tunnel per WAN; tunnels are used by Net Balancer (Tunnel gateways) for aggregation/failover.
• Client: Windows system on z40 LAN (LAN00 or Wi-Fi LAN05).

Prerequisites

• Admin access to zWAN Director.
• z40 and vGR already onboarded; tunnels pre-configured (POC default).
• Ability to physically disconnect WAN00; and (for optional test) enable/disable which cellular backup you want to demonstrate.
• No Dynamic Path/steering rules enabled for this test (pure failover).

Pre-Checks (no changes—verify only)

1. Confirm tunnel status
   Path: Edge Controllers > [z40] > Network > Tunnels
   • Verify the following rows show Status = ESTABLISHED (green):
     • IPSEC00 (bound to WAN00)
     • IPSEC01 (bound to WAN03/4G)
     • IPSEC02 (bound to WAN04/5G)
   • Screenshot for evidence.
2. Confirm Net Balancer tunnel preference (weights)
   Path: Edge Controllers > [z40] > Network > Net Balancer > BRANCHES
   • Ensure you have Tunnel gateways for each WAN with Configured Status = ON and weights that prefer WAN00. Example:
     • Tunnel (WAN00/IPSEC00) = weight 100 (highest)
     • Tunnel (WAN04/IPSEC02) = weight 20
     • Tunnel (WAN03/IPSEC01) = weight 10
3. Open per-tunnel stats for the primary
   Path: Edge Controllers > [z40] > Network > Tunnels → click the Statistics (bar-chart) icon on IPSEC00.
   • You’ll land in Analytics > Statistics filtered for IPSEC00.
   • Keep Interfaces and Logs & Events tabs handy.

Baseline (show traffic over primary)

1. Generate modest WAN traffic from the LAN client (60–90 seconds)
   • Browse a couple of public sites and/or run:
     ping -n 50 1.1.1.1
   • In Analytics > Statistics > Interfaces (for IPSEC00), confirm TX/RX and packet counters increase.
   • Screenshot: “Before failover (IPSEC00 over WAN00)”.

Failover A — Wired → 5G (WAN00 → WAN04/IPSEC02)

1. Drop the primary wired link
   • Physically disconnect WAN00 (or drop its upstream handoff).
2. Observe continuity and path shift
   • IPSEC00 counters should stop rising; IPSEC02 (5G) should begin carrying traffic (rising TX/RX).
   • In Analytics > Statistics for IPSEC00, check Logs & Events around the moment of failure; you should see tunnel/link change entries.
   • Keep client traffic running; the user experience should continue with minimal impact.
   • Screenshot(s): Interfaces view showing IPSEC02 active; Logs & Events around the failover time.
3. Confirm tunnel health overview
   Path: Network > Tunnels
   • Verify IPSEC02 is ESTABLISHED and active; other tunnels should also show ESTABLISHED.

Fail-Back A — 5G → Wired (WAN04/IPSEC02 → WAN00/IPSEC00)

1. Restore WAN00
   • Reconnect WAN00 and allow link health to recover.
2. Verify return to preferred
   • Net Balancer immediately prefers the higher-weight tunnel (IPSEC00).
   • In Analytics > Statistics > Interfaces for IPSEC00, watch counters resume rising for new flows; IPSEC02 should stabilize.
   • Screenshot: “After fail-back (IPSEC00 preferred again)”.

(Optional) Failover B — Wired → 4G (WAN00 → WAN03/IPSEC01)

Use this if you want to demonstrate 4G independently of 5G.

1. Prepare the test
   • Temporarily disable the Tunnel gateway for WAN04/IPSEC02 (or physically down WAN04) so the system will fail to WAN03/IPSEC01.
2. Repeat failover steps
   • Drop WAN00 again.
   • Verify IPSEC01 counters rise while traffic continues.
   • Restore WAN00; confirm preference returns to IPSEC00.

Validation Criteria

• Before failure:
  • IPSEC00 (WAN00) ESTABLISHED and carrying traffic (Interfaces counters rising).
• During failure of WAN00:
  • Traffic continues on cellular backup per weights; IPSEC02 (5G) or IPSEC01 (4G) ESTABLISHED and carrying traffic.
  • Logs & Events record the link/tunnel change.
• After restore:
  • Preference returns to IPSEC00 (WAN00) automatically; new flows use the wired path.
• User impact minimal (pings continue, browsing/downloads proceed).

Evidence to Capture

• Tunnels page (pre-test, during failover, post-fail-back) with statuses.
• Analytics > Statistics > Interfaces for:
  • IPSEC00 before failover
  • IPSEC02 (or IPSEC01) during failover
  • IPSEC00 after fail-back
• Logs & Events around the failover window.

Notes & Tips

• No DPS/steering: Make sure Balancing Rules are off for this test (we’re validating default tunnel failover only).
• Watch the right tunnel: Always click the Statistics icon from the tunnel row you’re validating so the Analytics view is correctly filtered.
• Traffic level: Keep it modest so you don’t saturate cellular; just enough to make counters move clearly.
• If counters don’t move:
  • Confirm your client traffic is WAN-bound (not cached/local).
  • Verify which tunnel’s Analytics page you’re viewing.
  • Ensure the intended backup tunnel (IPSEC02 or IPSEC01) is ESTABLISHED and its Tunnel gateway is Enabled under Net Balancer > BRANCHES.