I've seen this pattern before. You need to isolate a single user's traffic for debugging, but enabling `debug` system-wide on the SRX floods the logs, impacts performance, and is a security audit nightmare. The global setting is a blunt instrument.
The correct method is a firewall filter with a `log` action applied to a loopback interface or a specific zone. This gives you session-init and session-close logging for that traffic only. First, identify the user. Use their source IP, or if it's dynamic, you'll need to tie it to an authentication source (like a RADIUS attribute). For this example, let's assume a static IP.
You create a filter matching their traffic and apply it to the `loopback` zone. This catches traffic after routing, which is key.
```
set firewall family inet filter USER-DEBUG term CATCH-USER from source-address 192.168.1.100/32
set firewall family inet filter USER-DEBUG term CATCH-USER then log
set firewall family inet filter USER-DEBUG term CATCH-USER then accept
set firewall family inet filter USER-DEBUG term DEFAULT then accept
set security zones security-zone LOOPBACK host-inbound-traffic system-services all
set security zones security-zone LOOPBACK host-inbound-traffic protocols all
set interfaces lo0 unit 0 family inet filter input USER-DEBUG
```
Then, configure your `syslog` to capture these messages. The log entries will appear with `FWF` prefix. You can increase the detail level for these logs specifically without touching global debug flags.
The advantage over `security flow traceoptions` is granularity and less overhead. Flow debugging is session-based and can be targeted, but the filter-log method is often simpler for pure packet tracing. If you need L7 application identification details, you may still need a targeted flow debug, but start with the firewall filter.
Monitor your log volume regardless. Even a single user can generate significant data.
-- ow
Loopback zone with `host-inbound-traffic all`? That's a sledgehammer. You're opening up every system service, which kinda defeats the purpose of a targeted security audit, doesn't it?
A tighter approach is to apply that filter to the inbound direction of a specific zone, like `trust`, if that's where their traffic ingresses. Or, just apply it directly to the loopback interface without enabling all host services. You only need to allow the traffic you're logging.
Also, don't forget the syslog configuration to actually see those filter logs. They won't show up in the standard traffic log by default. You need to set something like `set system syslog file messages firewall info`. Otherwise, you'll just have a perfectly good filter logging to the void.
Open source is the answer