I85PREP
⌘ K
WatchGuard Essentials study materials
WatchGuard Essentials study resources

Voice Pinned to One ISP and a Partner Subnet That Already Exists

WatchGuard Essentials · Put your knowledge to work in context.

All case studies

Voice Pinned to One ISP and a Partner Subnet That Already Exists

A retail chain's HQ runs a Firebox M390 with three interfaces: eth0 external, static 203.0.113.10/29 on ISP-A; eth1 external, DHCP from ISP-B handing out a 100.64.x.x carrier-grade address; eth2 trusted, carrying VLAN 10 corporate 10.10.10.0/24, VLAN 20 guest 10.10.20.0/24 and VLAN 30 voice 10.10.30.0/24. The SIP provider accepts registrations only from 203.0.113.10. Guest traffic must never leave via ISP-A. A new BOVPN to a logistics partner must reach the partner's 10.20.30.0/24, but the chain's own warehouse already uses 10.20.30.0/24 across a different tunnel. Current load: ISP-A 40/100 Mbps, ISP-B 300/300 Mbps. A broad Any-Trusted to Any-External policy sits at the top of the policy list.

1. Design the multi-WAN behaviour so voice always uses ISP-A and guest never does. What objects do you configure, what breaks the naive design, and what do you test?

Read the worked answer

Use policy-based multi-WAN via SD-WAN actions rather than relying on the global multi-WAN setting, and remember that a policy's SD-WAN action overrides the global interface order for that traffic.

Objects:

  1. Multi-WAN configured on eth0 and eth1 with link monitors (ping/DNS targets reachable from each ISP).
  2. SD-WAN action 'Voice-A-Only': eth0 selected, eth1 not in the list (fail closed).
  3. SD-WAN action 'Guest-B-Only': eth1 selected, eth0 excluded.
  4. Policies: Voice VLAN (10.10.30.0/24) to External using Voice-A-Only; Guest VLAN (10.10.20.0/24) to External using Guest-B-Only.

What breaks the naive design:

  • Policy order. The existing Any-Trusted to Any-External policy sits above everything and will match voice and guest traffic first, silently ignoring your new policies. Move the specific policies above it, or convert the broad rule to cover only the corporate VLAN.
  • Failover is meaningless for voice. If you include eth1 as a secondary in the voice action, an ISP-A outage moves SIP to 100.64.x.x, which the provider will reject - users get silent one-way audio or failed registrations instead of a clean outage. Excluding eth1 makes the failure honest.
  • Guest isolation. Also confirm guest cannot reach trusted VLANs; SD-WAN choice does not imply a segmentation rule.

Tests: physically drop eth0 and confirm voice registrations fail cleanly rather than half-registering; run a guest client and watch the traffic monitor to prove the SNAT source is the ISP-B address; verify link-monitor failback does not flap by checking the multi-WAN status after a 10-minute outage.

2. The partner tunnel needs 10.20.30.0/24 and the warehouse tunnel already uses it. Why can't a static route solve this, and what addressing scheme do you propose? What must the partner change?

Read the worked answer

Forwarding is destination-based. Two tunnels claiming the same prefix produce one route entry; the firewall cannot tell which packet belongs to which tunnel, so whichever route wins blackholes half your traffic. Adding a second static route for the same prefix is either rejected or simply overwrites the first - it does not create a second path.

Options, in order of preference:

  1. Renumber one side (best). Ask the partner to present a dedicated /24 for this interconnect, or move the warehouse to a new range during a maintenance window. Clean, no ongoing translation debt, no DNS surprises.
  2. 1-to-1 NAT for the overlapping block. Map the partner's 10.20.30.0/24 to a spare block HQ owns, e.g. 172.31.30.0/24:
    • Create 1-to-1 NAT entries translating 172.31.30.0/24 to 10.20.30.0/24 across the partner tunnel.
    • Add a static route for 172.31.30.0/24 pointing at the partner tunnel (with a virtual-interface BOVPN, the route and NAT are still required for the translated block).
    • Publish the 172.31.30.x addresses internally via DNS so users never see the translated range.
    • Anything that hardcodes IPs (copiers, ERP connectors, certificates with IP SANs) must be updated.

What the partner must do: accept the translated source range HQ will present (HQ's own 10.x sources must also be 1-to-1 NATed if they collide with partner space), and route return traffic for those translated addresses back over the tunnel. Without that, the tunnel comes up and nothing passes - a classic 'Phase 2 is up, pings fail' symptom.

Verify with tunnel diagnostics plus a traffic monitor filter on the translated addresses before declaring success.