IP Routing & Static Route Steering (z40 Branch)

Objective

Prove that static routes on the zWAN/z40 can intentionally steer traffic—independent of defaults—by:

• Splitting Internet egress across WAN00 and WAN04 (5G) with two /1 routes,
• Pinning Microsoft Teams public ranges to WAN04,
• Backhauling a specific public prefix through the IPSEC tunnel to the vGR,
• Overriding a /24 with a single-host (/32) route to a backup WAN.

Prerequisites

• Admin access to zWAN Director.
• One z40 (branch) with dual WAN: WAN00 (wired), WAN04 (5G).
• One vGR (datacenter) with an active IPSEC tunnel to the z40 (e.g., IPSEC01).
• A Windows or Linux client on the z40 LAN for testing (ping, traceroute/tracert, curl).
• Baseline Internet working via the device’s existing default route/tunnels.

UI path used below: Edge Controllers → [z40] → Network → Router → Routes (IPv4).
Button used: NEW STATIC. In the dialog, choose Gateway (with next-hop IP or Interface like WAN00) or choose Interface (e.g., IPSEC01) as the next hop.

Test 1 — Half-Internet Split With Two /1 Routes

Goal: steer half of the Internet via WAN00 and the other half via WAN04 using only static routes.

Configure

1. Click NEW STATIC → Route Type: Network.
2. 0.0.0.0/1 → WAN00
   • Destination: 0.0.0.0
   • Netmask: 128.0.0.0
   • Next hop: Gateway (WAN00 gateway IP) or Interface → WAN00
   • Metric: 10 → CREATE
3. 128.0.0.0/1 → WAN04
   • Destination: 128.0.0.0
   • Netmask: 128.0.0.0
   • Next hop: Gateway (WAN04 gateway IP) or Interface → WAN04
   • Metric: 10 → CREATE

Validate

• From a LAN client:
  • traceroute 1.1.1.1 (or tracert 1.1.1.1) → should exit WAN04 (address falls in 128/1 half).
  • traceroute 8.8.8.8 → should exit WAN00 (falls in 0/1 half).
• Director: Analytics → Statistics → Interfaces → watch WAN00 and WAN04 TX/RX diverge when you run traffic to both targets.

Rollback

• Delete the two /1 routes.

Test 2 — Pin Microsoft Teams to WAN04 (5G)

Goal: force business SaaS (Teams) to use WAN04 regardless of defaults.

Configure

Create two static routes (one per published range):

• 52.112.0.0/14 → WAN04
  • Destination: 52.112.0.0, Netmask: 255.252.0.0
  • Next hop: Gateway (WAN04) or Interface → WAN04
  • Metric: 10 → CREATE
• 52.120.0.0/14 → WAN04
  • Destination: 52.120.0.0, Netmask: 255.252.0.0
  • Next hop: Gateway (WAN04) or Interface → WAN04
  • Metric: 10 → CREATE

Validate

• Start a Teams call/screen sharing on a LAN client.
• Director: Analytics → Statistics → Interfaces → WAN04 should show sustained traffic; WAN00 should drop for those flows.
• Optional: traceroute 52.112.0.1 and 52.120.0.1 → WAN04 path.

Rollback

• Remove the two /14 routes.

Test 3 — Backhaul a Public Prefix Via the Tunnel (Interface next hop = IPSEC)

Goal: override Internet breakout and send a selected public prefix through the IPSEC tunnel to the vGR.

Configure

1. Choose a safe public target prefix, e.g., 9.9.9.0/24 (Quad9).
2. NEW STATIC →
   • Destination: 9.9.9.0, Netmask: 255.255.255.0
   • Select Interface → IPSEC01 (or the active IPSEC interface)
   • Metric: 10 → CREATE

Validate

• From a LAN client: traceroute 9.9.9.9 → early hops should show tunnel/overlay path (not the WAN gateway).
• If your DC has distinct Internet egress, you’ll also see a different AS path/exit.

Rollback

• Delete the 9.9.9.0/24 route.

Test 4 — /32 Host Pinning to Backup WAN

Goal: demonstrate longest-prefix-match by steering a single host to WAN04 while the rest of its /24 stays on WAN00.

Configure

• NEW STATIC →
  • Destination: 1.1.1.1, Netmask: 255.255.255.255
  • Next hop: Gateway (WAN04) or Interface → WAN04
  • Metric: 10 → CREATE

Validate

• traceroute 1.1.1.1 → WAN04 path.
• traceroute 1.1.1.2 (same /24) → follows normal default (likely WAN00).
• This cleanly proves /32 beats broader routes.

Rollback

• Delete the /32.

Validation Criteria (for the whole test)

• Route table shows each new static route with correct Destination/Mask, Gateway/Interface, and Metric.
• Traceroutes from a LAN client follow the intended egress for each test target.
• Interface statistics (WAN00, WAN04, IPSEC0x) reflect the expected shifts in traffic.
• After rollback, paths return to baseline (default /0 and automatic IPSEC routes resume control).

Notes & Tips

• Precedence: Longest-prefix wins. The /1 entries in Test 1 will override the default /0; /32 overrides everything broader.
• Next-hop choice:
  • Use Gateway/IP or Interface→WANxx for Internet egress.
  • Use Interface→IPSEC0x when you want backhaul through the tunnel.
• Metrics: When two equally specific routes exist, the lower Metric is preferred. We used 10 for clarity; keep consistent unless you want deterministic tiebreaks.
• Scope: Avoid broad changes during production hours. The /1 split is powerful—keep the demo brief and roll back promptly.
• Troubleshooting quick hits:
  • If a static route appears but isn’t used, verify the selected next-hop Interface is UP and the gateway is reachable.
  • Confirm no conflicting more specific route already exists.
  • Use traceroute/tracert and Director Interface counters to verify real forwarding, not just table entries.
  • If Logs → Router tab is available in your build, you may filter for route-change syslog; otherwise, rely on path tests + counters.

Clean-up Checklist (after all tests)

• Remove: the two /1 routes, the two Teams /14 routes, the 9.9.9.0/24 tunnel route, and the 1.1.1.1/32 host route.
• Re-run traceroute to 1.1.1.1 / 8.8.8.8 to confirm baseline path restored.
• Snapshot/export the route table if you need an audit record.