I've seen this question pop up repeatedly, and most of the answers I find are either overly simplistic firewall filter examples or suggest using application identification without the crucial second step. Configuring rate-limiting for a specific application on an SRX isn't a single knob; it's a chain of policies that must be correctly linked. If you just slap a firewall filter on an interface, you're limiting all traffic on that port, not the specific app flow through a security policy. That's useless for application-level control.
You need to combine AppID with a scheduler and a traffic policer. Here's the correct, granular approach. First, ensure you have the application identified. Let's assume it's `junos:HTTP`.
**Step 1: Define a rate-limiting scheduler.** This sets your bandwidth and burst constraints.
```
set class-of-service schedulers APP-LIMIT-SCHEDULER transmit-rate 10m
set class-of-service schedulers APP-LIMIT-SCHEDULER buffer-size percent 10
set class-of-service schedulers APP-LIMIT-SCHEDULER priority low
```
**Step 2: Define a firewall policer that references that scheduler.** This is the actual policing entity.
```
set firewall policer APP-LIMIT-POLICER if-exceeding bandwidth-limit 10m
set firewall policer APP-LIMIT-POLICER if-exceeding burst-size-limit 1m
set firewall policer APP-LIMIT-POLICER then discard
```
**Step 3: Apply the policer within a security policy.** This is the critical link most people miss. You must apply it to the correct direction (`from-zone` to `to-zone`) of your policy matching the application.
```
set security policies from-zone TRUST to-zone UNTRUST policy LIMIT-APP-ACCESS match source-address any
set security policies from-zone TRUST to-zone UNTRUST policy LIMIT-APP-ACCESS match destination-address any
set security policies from-zone TRUST to-zone UNTRUST policy LIMIT-APP-ACCESS match application junos:HTTP
set security policies from-zone TRUST to-zone UNTRUST policy LIMIT-APP-ACCESS then permit
set security policies from-zone TRUST to-zone UNTRUST policy LIMIT-APP-ACCESS then log session-close
set security policies from-zone TRUST to-zone UNTRUST policy LIMIT-APP-ACCESS then count
# Here is the key line:
set security policies from-zone TRUST to-zone UNTRUST policy LIMIT-APP-ACCESS then police APP-LIMIT-POLICER
```
Common pitfalls I've had to debug for others:
* Applying the policer on the wrong zone-direction policy. The policer is applied per-direction. If you want to limit both upload and download for the app, you need two policies (and potentially two policers) for each zone pair direction.
* Forgetting that `burst-size-limit` is critical for TCP tolerance. Setting it too low will cause legitimate sessions to be dropped under normal throughput spikes.
* Not using the `count` action, which deprives you of the visibility to verify the policer is actually hitting and dropping packets in your `show security policies hit-count` output.
* Attempting to use `hierarchical-policer` for this without understanding the complexity. The flat policer attached to the policy is sufficient for 95% of per-application rate-limiting use cases.
If your goal is to limit total bandwidth for that app across all users, this is your method. If you need per-user or per-IP limiting within the app, that's a different beast requiring dynamic profiles or a RADIUS integration. Start with this structure, verify with hit-counts and `show security flow session application junos:HTTP`, and then adjust your bandwidth figures.
—davidr
—davidr