SDWSCS Part 7: Umbrella SIG — Deployment & DNS Policies

Part 6 made the argument for cloud-delivered enforcement; this part deploys it. Two layers, deliberately in this order: DNS security — the control you can turn on this afternoon — and the Secure Internet Gateway tunnels that send full traffic flows to Umbrella for SWG/CBFW/CASB treatment.

Layer 1: DNS security

DNS is the cheapest enforcement point in existence: nearly every connection starts with a lookup, and blocking the lookup costs no bandwidth and no tunnel. The Catalyst integration is a DNS security policy (vManage → Security) that intercepts DNS from selected service VPNs and redirects it to Umbrella’s resolvers, with the site identified by API-registered token — so per-site policies apply even behind NAT. EDNS client-subnet options carry enough context for per-network policy, and DNSCrypt protects the redirected queries.

In Umbrella, DNS policies then match identities (network, internal network, roaming client) against destination lists and the category/security settings: malware, C2, phishing, DNS tunnelling, newly-seen domains. Blocked lookups answer with Umbrella’s block-page IP.

Edge# show sdwan umbrella config
Edge# show sdwan umbrella dnscrypt
Token: 8A1C...   DNSCrypt: enabled   Resolver: 208.67.222.222

Two operational notes that earn their keep: local domain bypass — a regex/local-domain list keeps internal zones pointed at your own resolvers, and forgetting it breaks AD in interesting ways; and hosts running DoH to a third party bypass the whole layer — pair the policy with a ZBFW rule blocking outbound 853/known-DoH endpoints, or accept the gap knowingly.

Layer 2: SIG tunnels

The SIG integration sends actual traffic — not just lookups — to Umbrella’s PoPs through IPsec tunnels that vManage builds automatically:

1. API credentials. Generate a SIG API key/secret in Umbrella, enter them once in vManage (Administration → Settings → Umbrella). Everything after this is workflow, not per-site engineering.
2. SIG credentials + SIG feature template (or the config-group equivalent): pick tunnel type (IPsec; GRE exists for specific cases), source interface, and the tunnel pairs — each edge builds tunnels to a primary and secondary Umbrella data centre, selected by proximity.
3. High availability model:
   • Active/backup — one tunnel carries traffic, failover on liveness loss. Simple, deterministic.
   • Active/active (ECMP) — up to 4 active tunnel pairs; per-flow load-share, with weighted distribution if transports differ. More aggregate bandwidth per site (each IPsec tunnel to Umbrella has a documented per-tunnel throughput ceiling — high-bandwidth sites need multiple active tunnels purely for capacity).
4. Steering traffic in. Two mechanisms, same as DIA: the service-side route ip sdwan route vpn 1 0.0.0.0/0 service sig, or centralized data policy with action set sig (with sig-action fallback-to-routing deciding what happens when all tunnels are down — the same fail-open/fail-closed conversation as Part 5, and it deserves the same explicit decision).

Edge# show sdwan secure-internet-gateway tunnels
TUNNEL IF  DEST DC              STATE   TRACKER
Tunnel100001  146.112.x.x (LON)  up      green
Tunnel100002  146.112.y.y (FRA)  up      green
Edge# show endpoint-tracker

The tracker matters: tunnel state alone doesn’t prove the PoP is serving traffic, so an HTTP probe through each tunnel (to a service-availability URL) gates whether the tunnel is usable. Tracker red with tunnel up means the PoP path is unhealthy — traffic shifts to the other DC.

What enforces what (the demarcation)

Once traffic lands in the SIG, Umbrella’s dashboard owns the policy: the web policy (SWG — full URL, category, file-type control, AV scanning), the cloud-delivered firewall policy (L3/L4 + application, IPS in the CDFW), HTTPS inspection (Umbrella’s CA cert distributed to clients — Part 4’s PKI conversation relocated to the cloud), and the CASB/DLP layer that Part 8 covers. vManage owns which traffic gets there and how the tunnels behave. When something breaks, that demarcation is the triage fork: tunnel/tracker/steering problems live in vManage and the CLI above; verdict problems live in Umbrella’s reporting.

Design defaults worth stealing

Question	Default
DNS security everywhere?	Yes — including sites with full SIG (defence in depth, and roaming parity)
A/A or A/B tunnels?	A/B for small sites; A/A weighted where bandwidth demands it
All ports to SIG, or web only?	Start web (80/443) via data policy; widen once CDFW policy is mature
Fallback to routing?	Explicitly decided per VPN — guest fails open, corporate fails closed is a common split

Next up, Part 8: securing the cloud applications themselves — CASB, tenant controls, DLP, and the Microsoft 365-specific machinery that stops “we moved to M365” meaning “anyone can log into any tenant from our network”.