Variables

Variables allow you to parameterize snippet content so the same snippet can produce different configurations for different devices or OUs. Inside a snippet’s JSON content, you can use ${variable_name} placeholders that are resolved at sync time.

Variable Scopes

Variables are defined at multiple levels, and more specific scopes override broader ones:

Priority	Scope	Meaning
1 (lowest)	Organization	The default value for all devices in the organization.
2	OU	Overrides the organization value for all devices in a specific OU.
3	Template	Overrides the value for all snippets within a specific template.
4 (highest)	Device	Overrides all other values for a specific device.

Tip

Define your defaults at the organization level first, then override at narrower scopes only where needed. This keeps your variable definitions minimal and makes it easy to see what’s actually different per-device or per-OU.

For example, if you define ${listen_port} at the organization level as 51820, you could override it to 52830 for a specific OU’s devices, or to 53840 for one particular device — all while using the same snippet definition.

Parameterizing a Snippet

Consider a snippet that allows DNS queries. Instead of hardcoding the DNS server addresses, you can use a variable:

{
  "uuid": "221f3268-0003-4abc-9000-000000000001",
  "enabled": true,
  "action": "pass",
  "interface": "lan",
  "direction": "in",
  "ipprotocol": "inet",
  "protocol": "TCP/UDP",
  "source_net": "any",
  "destination_net": "${dns_server}",
  "destination_port": "53",
  "description": "Allow DNS to ${dns_server}"
}

Then define the variable at different scopes:

ndcli variable org create dns_server 8.8.8.8

This sets the default DNS server for all devices in the organization. Now override it for the production OU to use an internal resolver:

ndcli variable ou create production dns_server 10.0.1.53

And for a specific branch device that needs a local DNS:

ndcli variable device create fw-branch-austin dns_server 10.50.1.53

At sync time, the variable is substituted before the configuration reaches the device:

• fw-hq-primary (production OU) resolves ${dns_server} to 10.0.1.53
• fw-branch-austin (branch-offices OU, device override) resolves to 10.50.1.53
• fw-guest-lobby (guest-networks OU, no override) resolves to 8.8.8.8 (org default)

Secret Variables

Some variables carry sensitive content — API tokens, shared secrets, anything you want substituted into snippets but never read back. Add --secret when creating the variable at the organization scope:

ndcli variable org create syslog_token "..." --secret

At sync time a secret behaves exactly like a regular variable: its value is substituted into every snippet that references it, and the rendered configuration reaches the device unchanged. The difference is on the read path — the web UI, ndcli variable org describe, and every API response return a redacted placeholder instead of the cleartext. Once written, the value cannot be retrieved.

To rotate a secret, set a new value at the same name with ndcli variable org set <name> --value <new>. The --secret flag is only available at the organization scope.

Conflict Detection

If a device belongs to multiple OUs that define the same variable with different values, NetDefense detects the conflict and prevents the sync.

Caution

A variable conflict blocks sync entirely for the affected device until resolved. Fix it by removing one of the conflicting OU-level definitions or by adding a device-level override, which always takes highest priority.

View in NDWeb

Managing Variables

# List all variables across scopes
ndcli variable overview

# Create variables at each scope
ndcli variable org create <name> <value>
ndcli variable ou create <ou-name> <name> <value>
ndcli variable template create <template-name> <name> <value>
ndcli variable device create <device-name> <name> <value>