Underlay, Overlay, and Fabric Configuration
Underlay configuration
Each WAN interface is bound to a transport (for example, public internet or MPLS) and given a label so policy can reference it. Interfaces need correct WAN-side addressing (static or DHCP), next-hop/gateway, and often NAT behavior. The appliance uses health checks (probes such as ICMP or synthetic traffic) to determine link and tunnel state; probe target selection matters because a probe to an unreachable host falsely marks a healthy link down.
Overlay and fabric
Overlay tunnels are established between appliances, often using IPsec with automatic key exchange managed by the fabric. Fabric membership determines which appliances can form tunnels; a misconfigured fabric or missing peer means no tunnel. NAT traversal is required when appliances sit behind NAT, and tunnel-less or pass-through designs exist for specific cases. Segmentation within the fabric (zones/VPNs) keeps tenant or department traffic separate across the same tunnels.
Traps
- Health-check probe pointing at a public target that blocks ICMP, causing false failover.
- Forgetting NAT-Traversal when a spoke is behind a firewall doing NAT.
- Assuming tunnel up equals path good; tunnel state and measured quality are separate signals.
- Mixing up interface labels/transports so policy matches the wrong link.
Worked example
A spoke has ISP-A (primary) and LTE (backup). Bind each to a distinct transport label, set health checks to a reachable hub loopback rather than a public DNS server, and verify the fabric shows the spoke as a member with both tunnels up. If only one tunnel forms, check NAT-T and firewall UDP permissions before touching policy.