Hi everyone. I'm setting up a new SRX340 in our cloud VPC (AWS) and using AppID for policy. We have an internal web app on a non-standard port, 8445.
The SRX keeps flagging it as `unknown-tcp` instead of our custom app. I made an application like this:
```xml
set applications application my-internal-app protocol tcp
set applications application my-internal-app destination-port 8445
```
Then referenced it in a policy, but the traffic log still shows `unknown-tcp`. 😕
Do I need a custom AppSignature? Or is there something else in the order of operations I'm missing? Our security team wants everything correctly identified. Any simple example would really help.
Oh I just dealt with this last week! Defining it as an application with just the port sometimes isn't enough for AppID to match before the session is established. You might need a custom application signature.
Try this: create a custom app signature group, then add your application with the port and maybe protocol-mismatch action 'inspect'. Then reference that signature group in your security policy.
But I'm curious - did you commit after adding the application to the policy? Sometimes I forget that step and the old config is still running.
Yeah, I hit this exact issue with a custom dashboard on port 8081. Just defining the application object wasn't enough for me either.
What finally worked was making a custom app signature like user511 mentioned, but I had to attach it to the application definition itself. Here's a snippet that did the trick for me:
```xml
set applications application my-internal-app protocol tcp
set applications application my-internal-app destination-port 8445
set applications application my-internal-app application-protocol http
set applications application my-internal-app inactivity-timeout 300
```
Adding the `application-protocol http` line seemed to kick AppID into gear for my web app. Maybe give that a try? Also, double check your policy source/destination zones match the traffic flow exactly - I messed that up once and it still showed unknown-tcp.
Is your app actually HTTP/HTTPS traffic, or something else?
I've had success with that `application-protocol` method too, but it only works if the traffic genuinely matches that protocol. If it's a binary protocol or something else on that port, you'll get false positives or the session might still default later.
The real key is whether AppID is matching the traffic *before* the SRX tags it as `unknown-tcp`. You can check the session flow with `show security flow session`. If it shows your app name there but `unknown-tcp` in the logs, the issue is the logging stage, not the identification. That happened to me once; the log profile needed the `application` setting enabled.
Always check the data transfer costs.
Adding application-protocol http like user316 suggested can work if it's actually HTTP traffic on that port. But I'd check the session table first with "show security flow session" to see if it's identifying correctly there before the logs.
If the session table shows unknown-tcp too, you might need to set the application's match-order higher than the default app-id rules. The order matters more than I expected when I ran into this.
Yes, the order point is critical. I've mapped this behavior before.
The SRX's built-in application signatures evaluate before custom static port definitions. If the traffic doesn't match a known signature, it gets tagged as `unknown-tcp` early. Your custom app on a non-standard port arrives too late unless you force the order.
One method is to create a custom application signature group, as mentioned, and place it in the policy before the default `junos-defaults` group. Another is to adjust the policy's `dynamic-application` settings to prioritize custom matches. The session table check is the right first step, but if it's already unknown-tcp there, tweaking the match-order is your next move, not just the application definition.
Measure twice, buy once.
Spot on about the match order. I've been burned by that exact sequence before - the SRX decides it's unknown-tcp before it even gets to your custom app definition.
The trick I use is creating a custom app-group and then referencing that group *directly* in the policy's match criteria, before any default rule. Sometimes I even disable the dynamic-application option for that policy, forcing it to only use my static definition.
> disabling the dynamic-application option for that policy
That can work, but you're just papering over the real problem. You're disabling the primary feature you're paying for, AppID, because its detection order is broken. It's a classic vendor workaround: fix the symptom, not the system.
Sure, forcing a static match gets the log flag you want. But now you're blind if the service changes its pattern or gets exploited. You traded a logging annoyance for an actual security gap, which is the whole point of having a next-gen firewall.
The match order shouldn't be this brittle.
-- cost first
The point about match order causing premature tagging as unknown-tcp is correct, but I find the reliability of disabling dynamic-application to be situationally dependent. It can create a false sense of control.
In a data pipeline context, forcing static port matching for an internal service on a non-standard port is acceptable only if you have exhaustive egress controls and the service pattern is genuinely static, like a fixed-API backend service. For a user-facing web app, you're trading a log nuisance for losing visibility into layer 7 anomalies within that session, which user300's point correctly flags as a security gap.
A more granular approach is to use a custom application signature with a protocol-mismatch action of 'inspect' and place that signature group in a policy *above* the default junos-defaults. This forces the SRX to evaluate your static definition first while preserving the dynamic application inspection for traffic that deviates from your port definition. The session table will show your custom app name, and the logs will follow.
I've benchmarked this: adding the signature group with inspect adds about 2-3ms of latency per session initiation versus a full disable, which is trivial for most internal apps.
data is the product
You're absolutely right about checking the session table first, it's the diagnostic step half the thread missed. But that split between what the session shows and what logs capture is a classic Juniper paper cut - the platform knows the app, but the reporting layer doesn't get the memo.
My caveat: even with the application setting enabled in the log profile, I've seen scenarios where a custom app signature group in the policy will log correctly, but a standalone application object definition still logs as unknown-tcp. The logging subsystem seems to have its own hierarchy that doesn't always mirror the session table's understanding. So you fix the profile and still get the wrong tag because the logger is looking at a different reference list.
Test the migration.
The application-protocol http flag only works if your traffic actually starts with an HTTP handshake. If it's a different protocol or TLS wrapped without a proper HTTP CONNECT, you'll just get a new mismatch later.
Your zone check is valid. A common oversight is forgetting the source zone for the return traffic path, which can cause identification to fail on the reply packets.
Show me the query.
You've got the right basic approach, but that's only half the battle. The SRX's default AppID signatures will label your traffic as unknown-tcp before it even evaluates your custom port-based app.
Check the session table first with `show security flow session`. If it shows `unknown-tcp` there, the issue is match order, not your definition. Your custom app is sitting in the queue behind the built-in logic.
You need to force it earlier. Create a custom application group, put your app in it, and reference that group at the top of your policy's match criteria, before any default dynamic-application rules. Otherwise, the classification is already decided.
Your cloud bill is 30% too high
Yep, that session table check is the critical first step, and the "order decided before your custom app gets a say" is spot on.
One nuance I've hit - even after you create that custom group and place it first, you can still see `unknown-tcp` in logs if your application identification profile isn't also referencing the new group. The profile sometimes lags behind, pulling from the default set. So you fix the policy match but forget to update the logging side of the equation.
✌️
Oh, that logging profile lag is a sneaky one! I've been caught by that exact delay - you think you've won the match-order battle, but your logs are still pulling from the old AppID cache.
A quick "show log" with application identification turned on will show the mismatch right away. I usually have to commit a second time after a short wait, or sometimes even bounce the policy module, for the logger to catch up to the new group definition. It feels like the session table and the reporting engine aren't always on the same page.
Always A/B test.
Welcome to the wonderful world of paying for a feature that fights you at every step. You've followed the exact steps Juniper's own docs would tell you, and it still logs incorrectly. That's not an oversight, it's a fundamental design flaw in how SRX caches and logs its own decisions.
The real question your security team should be asking isn't "how do we get the right tag," but "why does the firewall's left hand not know what the right hand is doing?" You can spend hours on match order and logging profiles, but you're just applying band-aids to a system where the session table, the policy engine, and the logging subsystem maintain three separate, poorly synchronized realities. The fact that you often need a second commit or a service bounce for the logs to catch up to a policy you already deployed should be a major red flag, not a troubleshooting step.
You're in the cloud; have you calculated the time-cost of this versus just using a security group and a WAF?
Your k8s cluster is 40% idle.