Hi everyone. Still finding my way around networking, so apologies if this is a basic one.
I've been working with an SRX at my new job, and I'm getting the hang of committing configs. But I keep wondering: just because a policy commits without errors, how do I *really* know it's doing what I expect? Like, is traffic actually matching the rule I think it is?
In my old dev world, I'd just check a log or run a test. Is there a similar "show" command or a best practice to verify a policy is actively being applied to the traffic? I'm worried about having a false sense of security. Any tips would be awesome.
Totally fair question, and you're smart to be skeptical. A clean commit just means the config syntax is valid, not that it's intercepting the traffic you think it is.
For Juniper SRX specifically, the command you're looking for is `show security policies hit-count`. That will tell you how many sessions have matched each policy since the last counter reset. If you apply a new policy and the hit count stays at zero, either the traffic isn't hitting that zone pair or the match conditions are off.
Another handy one is `show security match-policies` which lets you feed in source/destination/port values and see what policy would match. It's like a dry run without needing real traffic. Combined with syslog logging for the policy (if you enable it), you can actually watch sessions appear in real time.
One pitfall I see a lot: people forget that policies are zone-based, not interface-based. So double-check that the source and destination zones are what you think they are, especially if you've got VLANs or tunnels in play. A policy can be committed and still be dead in the water if the traffic isn't entering the zone you assumed.
What kind of traffic are you trying to validate?
Keep it civil, keep it real.
Excellent points, especially the emphasis on zones being the linchpin. I'd add that the zone-to-interface binding is dynamic for logical interfaces, so a `show security zones` check is a prerequisite for any policy validation.
The `show security match-policies` command is invaluable, but treat it like a compiler, not a runtime. It uses the current session table for some lookups (like address books), so if your source is dynamic, the test might not reflect reality until after the first session is established. Always run it with `source-prefix` and `destination-prefix` explicitly defined to avoid that nuance.
For the logging suggestion, a caveat: enabling `session-close` logging for a policy on a busy gateway can be a fast track to filling your disk or SIEM quota. It's better to start with a targeted `session-init` log for the specific policy you're debugging, then disable it once verified.
Measure twice, cut once.
Good call on the logging caveat. I've seen teams get flooded in minutes by turning on session-close globally for a "quick look". session-init is the way to go.
You're also dead on about treating match-policies like a compiler. That dependency on the session table for resolved dynamic addresses is a classic trip wire. I'd add that if you're using FQDNs in address books, you need to run a `resolve` first, or your test is just using the last cached IP.
been there, migrated that
That's a solid point about FQDNs. It's easy to forget the test is using stale data if the cache hasn't been updated.
I'd also suggest making the logging distinction part of a formal review step for new policies. Something like "enable session-init logging for 24 hours, then disable." It creates a verification window without the operational risk.
Be kind, stay curious.
That hit-count tip is really helpful, thanks. I've been relying on commit messages and assuming it's working.
You mentioned the zone-based point. I think I might have gotten that wrong on our guest WiFi. If the source zone is set to the physical interface instead of the VLAN, would the policy just never match? I'm worried I've been blocking traffic I didn't mean to.
Is there a straightforward way to trace which zone a packet came in on?
You're spot on about treating it like a compiler. That's a great way to put it. I've been burned by that exact dynamic address lookup quirk, where a test passes because a previous session already resolved the hostname. I've made a habit now of specifying the actual IPs in my source-prefix and destination-prefix for the match-policies test, even if it's a bit more typing. It feels like writing a unit test for the policy itself.
Your point on starting with targeted session-init logging is the way to go. I learned the hard way once, turning on session-close for a policy I *thought* was low-traffic. It was not, and the alerts piled up fast. I've even seen cases where the logging overhead itself on a heavily used policy can impact performance. Starting small and targeted is the only sane approach.