Okay, I've been neck-deep in infrastructure-as-code and cloud-native networking for years, but I'm currently having to get my hands dirty with some on-prem Juniper SRX gear for a legacy environment. I'm coming at this from a perspective of someone who thinks in terms of Kubernetes NetworkPolicies, AWS Security Groups, and Terraform security modules.
I'm trying to map the SRX concepts to what I know, and the distinction between a **security policy** and a **firewall filter** is throwing me. They both seem to filter traffic, but the documentation is dense with jargon.
From my lab tinkering and reading, here's my working understanding. Please correct me if I'm wrong.
**Security Policies** are the stateful firewall rules. They're the main event for traffic passing through security zones (like `trust` to `untrust`). They track connections, allow return traffic automatically, and are evaluated in a sequence from top to bottom within a context (from-zone -> to-zone).
You apply them at the zone level. Example structure:
```junos
set security policies from-zone trust to-zone untrust policy PERMIT-WEB match source-address any
set security policies from-zone trust to-zone untrust policy PERMIT-WEB match destination-address WEB-SERVERS
set security policies from-zone trust to-zone untrust policy PERMIT-WEB match application junos-http
set security policies from-zone trust to-zone untrust policy PERMIT-WEB then permit
```
**Firewall Filters** are stateless ACLs. They operate at a lower level, more like raw packet filters on individual interfaces or routing instances. They don't do stateful inspection. They are often used for:
* Denial-of-service (DoS) protection (limiting packet rates)
* Filtering traffic destined to the SRX itself (loopback/management)
* Controlling traffic within a single zone or within a routing instance
* Basic packet filtering based on standard header fields (IP, port, protocol) without application awareness.
Example of a filter to protect the control plane:
```junos
set firewall filter PROTECT-MGMT term ALLOW-SSH from source-address 10.0.0.0/24
set firewall filter PROTECT-MGMT term ALLOW-SSH from protocol tcp
set firewall filter PROTECT-MGMT term ALLOW-SSH from destination-port 22
set firewall filter PROTECT-MGMT term ALLOW-SSH then accept
set firewall filter PROTECT-MGMT term DENY-ALL then discard
```
So, the crude analogy I'm building is:
* **Security Policy** = Stateful firewall rule (like an AWS Security Group or a cloud firewall rule). Operates on the "session."
* **Firewall Filter** = Stateless ACL (like an old-school Cisco extended ACL or a Linux iptables rule without connection tracking). Operates on the individual packet.
Is this the core of it? Where do people typically use firewall filters *instead of* or *in addition to* security policies in real deployments? I'm specifically thinking about scenarios where you might apply a filter on an internal zone interface, or if there's a performance implication.
Automate everything. Twice.
You're on the right track! I'd add that **firewall filters** (aka ACLs) are stateless and work at a different layer - usually for traffic to/from the device itself (loopback, management) or for basic rate-limiting/DoS protection on interfaces.
Think of it like this: security policies control traffic *between* zones (your workloads). Firewall filters often control traffic *to* the control plane. So you might use a firewall filter to only allow SSH from a management subnet to the SRX's management interface, while your security policies handle web traffic from trust to untrust.
A quick example snippet for a filter protecting the RE:
```junos
set firewall filter PROTECT-RE term ALLOW-MGMT from source-address 10.0.0.0/24
set firewall filter PROTECT-RE term ALLOW-MGMT from protocol tcp
set firewall filter PROTECT-RE term ALLOW-MGMT from destination-port ssh
set firewall filter PROTECT-RE term ALLOW-MGMT then accept
set firewall filter PROTECT-RE term DENY-ALL then discard
```
Mixing them up can cause some head-scratching "why is this blocked?" moments 😅
Clean code, happy life
Great point about control plane protection, that's crucial. I've seen so many bills skyrocket from cryptojacking because someone skipped that filter on a public-facing management interface. Your SSH example is perfect.
But mixing them up gets even worse in hybrid scenarios. Imagine applying a stateful security policy meant for inter-zone traffic directly to your loopback - you'll murder performance and maybe even lock yourself out. The stateless filter is cheap and fast for that job.
One more nuance: in AWS terms, a firewall filter is closer to a Network ACL (stateless, attached to a subnet), while a security policy is your stateful Security Group. Helps bridge the mental model.
You're spot on with the stateful nature and the zone-based application. That's exactly the core of it. The part I often have to explain to folks coming from cloud environments is the *granularity* of that statefulness.
In AWS or GCP, a stateful rule in a security group is essentially a single, atomic permit for a connection. On an SRX, a security policy is more like a tiny, self-contained stateful firewall rulebook *for that specific traffic flow*. It can have its own logging, its own session-timeout tweaks, and even its own application-layer services like ALGs baked right into that single policy entry. So when you think "stateful rule," think of it as a richer, more configurable object than its cloud counterpart.
Also, your point about evaluation order is so key, because unlike some cloud environments where rule priority is numeric, you're at the mercy of that top-down list within each from-zone/to-zone pair. Mess that order up and you'll have a bad time.
hannah
Your point about the granularity of the SRX security policy as a self-contained rulebook is excellent and brings up another key architectural difference. In cloud Security Groups, the stateful connection tracking is a global service provided by the hypervisor layer. On the SRX, that stateful inspection engine and its associated parameters are invoked and configured *per policy*. This means you can have one policy for your database traffic with a 30-minute TCP idle timeout, and another for DNS traffic with a 60-second UDP timeout, all within the same zone pair. This isn't just richer, it's a fundamentally different delegation of control.
That top-down evaluation order you mentioned also impacts that granularity. Because you can't reorder via priority numbers, you must sequence these "mini rulebooks" in the correct logical flow, placing more specific policies above broader ones. This makes the policy set a procedural script of sorts, where each entry's configuration of ALGs and timeouts applies only if traffic matches and the session is created there. A misordered list doesn't just permit unintended traffic, it can apply the wrong stateful inspection profile entirely.
—BJ
That's a good start for the mapping. But when you work with billing or subscription SaaS traffic, the difference gets even sharper. In a Stripe or Recurly integration, the security policy tracks the whole payment session's state, just like your cloud security groups would. A firewall filter could be used to just drop malformed API packets heading to the management plane before they're even inspected, which can help avoid resource exhaustion during an attack.