slackhq/nebula · error

config `%s` contains both true and false rules, but no defau

Error message

config `%s` contains both true and false rules, but no default set for 0.0.0.0/0

What it means

An IPv4 allow list that mixes allow (true) and deny (false) rules is ambiguous without a default rule for 0.0.0.0/0, because the library cannot infer the fallback decision for unmatched IPs. If no explicit default IPv4 rule is present and the rules contain both true and false values, newAllowList rejects the config.

Source

Thrown at allow_list.go:156

			rules.allValues = value
			rules.firstValue = false
		} else {
			if value != rules.allValues {
				rules.allValuesMatch = false
			}
		}

		// Check if this is 0.0.0.0/0 or ::/0
		if maskBits == 0 {
			rules.defaultSet = true
		}
	}

	if !rules4.defaultSet {
		if rules4.allValuesMatch {
			tree.Insert(netip.PrefixFrom(netip.IPv4Unspecified(), 0), !rules4.allValues)
		} else {
			return nil, fmt.Errorf("config `%s` contains both true and false rules, but no default set for 0.0.0.0/0", k)
		}
	}

	if !rules6.defaultSet {
		if rules6.allValuesMatch {
			tree.Insert(netip.PrefixFrom(netip.IPv6Unspecified(), 0), !rules6.allValues)
		} else {
			return nil, fmt.Errorf("config `%s` contains both true and false rules, but no default set for ::/0", k)
		}
	}

	return &AllowList{cidrTree: tree}, nil
}

func getAllowListInterfaces(k string, v any) ([]AllowListNameRule, error) {
	var nameRules []AllowListNameRule

	rawRules, ok := v.(map[string]any)

View on GitHub (pinned to dd8f660c0a)

Solutions

  1. Add an explicit 0.0.0.0/0: true or 0.0.0.0/0: false entry as the default policy
  2. Or make all IPv4 rules the same value so the default can be inferred

Example fix

// before
remote_allow_ranges:
  10.0.0.0/8: true
  192.168.0.0/16: false
// after
remote_allow_ranges:
  0.0.0.0/0: false
  10.0.0.0/8: true
  192.168.0.0/16: false
Defensive patterns

Strategy: validation

Validate before calling

func hasV4Default(m map[string]any) bool {
	_, ok := m["0.0.0.0/0"]
	return ok
}

Prevention

When it happens

Trigger: newAllowListFromConfig / getRemoteAllowRanges where a 0.0.0.0/0 entry is absent and at least one rule is true and at least one is false among the IPv4 CIDRs.

Common situations: Users adding a deny rule for one range and an allow rule for another but forgetting to state the default policy with 0.0.0.0/0.

Related errors


AI-assisted analysis of slackhq/nebula@dd8f660c0a (2026-09-03). Data as JSON: /api/errors/9728cb30525ecf4b. Report an issue: GitHub.