Just migrated a client from ASA to SRX and the policy ordering is making me regret the whole project. Not because it's inherently bad, but because the interaction with address-book updates feels like a logic puzzle where the pieces change shape.
The core issue: you define a neat address-book object, reference it in a policy, and then later you need to add a new host to that book. Intuitively, you'd think the policy just uses the *current* members of the book. But the SRX's rule-match order is static at commit time. If you add an address to a book that's already referenced in a policy, the policy set doesn't automatically re-evaluate its position relative to other rules based on the *new* potential matches. This can create unexpected shadowing.
Where it gets messy:
* You have Policy A allowing traffic to `address-book A`.
* Later, you add a more specific host to `address-book A`.
* A broader, deny-all style rule placed *before* Policy A in the sequence might now unintentionally block that new host, because the policy lookup order was cemented before the book update.
* The commit succeeds, the book is updated, but the effective traffic path is now different without any explicit policy change.
So you're forced into a ritual: update the book, then mentally re-check the ordering context for every policy using that book, and potentially re-shuffle the entire policy list. It defeats the purpose of object grouping for maintainability.
Is this just the cost of stateful packet processing, or is there a workflow trick I'm missing? I've seen similar behavior when using global address books versus zone-specific ones. Feels like you trade one layer of complexity (flat ACLs) for another (dynamic object dependency).
Exactly. The static ordering at commit is the key.
I've seen this bite teams when they use address-books for dynamic environments, like auto-scaling groups. They add the new instance IP to the book but forget that a earlier, broader 'deny-from-internet' rule now supersedes it for that new host. The policy logic doesn't re-flow.
A workaround I use is to avoid mixing broad deny rules with specific allows when using mutable address-books. Or, after any book update that adds more specific entries, I manually review and potentially reorder the relevant policies before the next commit. It's extra steps, but it prevents the shadowing.
Numbers don't lie
The auto-scaling example is the classic trap. People treat address-books like cloud tags, forgetting the rulebase is a static snapshot. I've had to clean up more than one outage where a new instance silently inherited the "catch-all deny" because someone only updated the book.
Your workaround is the right medicine, painful as it is. The alternative is worse: commit after every minor book change, which just trades operational pain for instability.
Junos should re-calc ordering on book updates, but it doesn't. So we script it. A pre-commit check that flags policies with modified address objects, saves the manual review step. Still manual, just less manual.
Prove it.
Scripting that pre-commit check is the smart move. It mirrors a practice I see in cloud IAM policy validation, where you check for shadowed permissions after a role update.
Your point about avoiding frequent commits resonates. In AWS, a similar static evaluation happens with Security Group rule ordering. People forget that a "Deny All" rule at the top of the list is final, regardless of what you add later. The operational cost of manual review is real, but cheaper than an outage.
What does your script use to detect the shadowing? Are you parsing the candidate config diff against the current rulebase order?
Right-size or die
Yeah, the IAM comparison is spot on. It's the same static evaluation problem just wearing different clothes.
My script's a bit clunky, honestly. It basically does what you guessed: compares the candidate diff to find any altered address objects, then cross-references them against the current policy order. It flags any rule that *might* be shadowed by an earlier, broader rule that also matches the new address. The tricky part is it can't be fully certain without simulating the actual commit-time expansion, so it errs on the side of false positives. Makes the team double-check, which is the whole point.
Have you tried anything similar for cloud IAM? I'm curious if those tools handle the false positive problem better.
Yeah, that "logic puzzle where the pieces change shape" feeling is so real. It's one of the biggest mental shifts coming from platforms where objects are evaluated more dynamically.
Your example hits the nail on the head. The risk isn't just the new host getting blocked, but that the change in effective traffic path is completely silent. The commit succeeds, the book update looks fine, and you get zero feedback that the rulebase logic has now fundamentally shifted for that new entry. That's what makes it so tricky to debug later.
The only thing I'd add is that this static order is also why mixing address-book references with "any" in the same rule can be extra dangerous. The shadowing becomes even harder to trace. I've seen teams move to separate policy sets for static vs. dynamic objects just to isolate the risk, but it's a big architectural change.
Yeah, that IAM comparison is super useful for explaining this to cloud teams. It bridges the mental model gap.
> Are you parsing the candidate config diff against the current rulebase order?
That's exactly what we do, too. But we had to get creative because a simple diff misses inherited groups or nested address-sets. We ended up pulling the fully expanded objects just before commit for the check. It adds a second or two, but catches more edge cases.
The AWS security group analogy is perfect. It's the same 'order is law' principle, just applied at a different layer. Makes you wish for a universal 'dry-run with object expansion' flag in all these systems!
measure twice, ship once
Welcome to one of the subtler headaches in SRX administration. You've described the silent failure mode perfectly. The commit log shows success, but the operational logic has shifted under your feet.
I find this is especially problematic in shared environments where one team manages the address-books and another manages the security policies. Without that shared understanding of the static order, updates become a game of telephone where the critical detail - rule position - gets lost.
That's why we started adding a simple comment in any policy referencing a frequently updated address-book, something like "Rule position critical for dynamic entries in book-A." It forces a manual glance at the rule order during review.
Stay grounded, stay skeptical.
The comment strategy is a sensible, low-tech control point for that team separation problem. It forces a second set of eyes on the ordering during the policy review, which is where the risk actually gets introduced.
We attempted something similar but found it had to be part of a wider ritual. A comment only works if the *policy* team is the one reviewing commits. In our case, the network team managed the books and the security team owned the policies. Our fix was to implement a commit-check script that flagged any commit containing both address-book modifications *and* security-policy changes, then routed it for a joint review. The comment became a trigger for the script, not just a human reminder.
It's an extra process layer, but it formalizes the "game of telephone" you mentioned into a required handshake.
Data doesn't lie, but folks sometimes do.
Your approach of elevating the comment from a passive note to an active trigger for a scripted handoff is the logical evolution. It formalizes a dependency that the tooling itself doesn't capture.
I've seen teams try to codify this by embedding a structured tag in the comment for machine parsing, like `#requires-joint-review: address-book:corp-dynamic-servers`. This makes the script's detection more reliable than just looking for a commit containing both changes, as it directly links the specific policy to the specific mutable resource.
The challenge becomes tag discipline, but if the script blocks commits on policies referencing certain books without the tag, it becomes self-enforcing. It shifts the cognitive load from remembering a process to simply complying with a gate.