We are in the process of migrating several internal services to a containerized environment hosted on a private Kubernetes cluster. As part of our security posture refinement, we have implemented an SRX345 with Junos OS 21.4R3 in a gateway role, leveraging AppID for application-aware policy enforcement. Our goal is to enforce least-privilege access to these services based on the application protocol, not just port and IP.
The issue we are encountering is that our primary internal administrative application (a custom-built Go service using gRPC over TLS on TCP/8443) is consistently being identified as `unknown-tcp`. This is causing legitimate traffic to be blocked by our default "deny all unknown applications" policy. The application is not performing any non-standard tunneling or obfuscation.
We have undertaken the following troubleshooting steps, with limited success:
* Verified that the AppID security package is up-to-date (`show security application-identification version`).
* Created a custom application signature based on the observed traffic pattern. We used the following template, focusing on the TLS SNI field and the destination port:
```junos
applications {
application my-internal-grpc-app {
application-protocol tcp;
protocol tcp;
destination-port 8443;
term t1 {
tls-sni "admin.internal.example.com";
}
}
}
```
* Enabled detailed tracing for application identification on the relevant policy and session.
```junos
set security policies policy then log session-close
set security flow traceoptions file appid-debug
set security flow traceoptions flag basic-datapath
set security flow traceoptions flag all
```
The packet captures from the trace indicate the session is established and the TLS Client Hello is visible, but the SRX still classifies it as `unknown-tcp` before applying our custom policy rule that specifically references `my-internal-grpc-app`. The custom application itself does not appear to be matched, even though the session details seem to align with our term.
My current hypotheses are:
1. The gRPC-over-TLS pattern is somehow interfering with the SRX's ability to perform deep packet inspection after the handshake, causing it to default to `unknown-tcp` before the application layer data can be analyzed.
2. There is an order-of-operations conflict where the default deny rule for unknown applications is evaluated before the custom application signature is fully instantiated or matched.
3. Our custom application signature is technically incorrect for the specific way the SRX's AppID engine parses this particular TLS/gRPC stream.
Our current workaround is to create a rule allowing `unknown-tcp` from specific source subnets, but this defeats the purpose of application-aware firewalling.
Has anyone successfully implemented AppID policies for custom internal gRPC/TLS services? Are there specific best practices for signature terms in this context, or alternative strategies such as using a dedicated custom application group or leveraging ALPN (Application-Layer Protocol Negotiation) inspection? Any insight into the internal flow of AppID matching versus policy lookup would be highly valuable.
Data over dogma
gRPC over TLS is a tough one for AppID. The custom signature you started is the right path.
Can you share the exact signature you tried? The TLS SNI field is key, but you might also need to look at the ALPN extension in the TLS handshake. gRPC often sets `application/grpc` there.
If that doesn't work, you'll likely need a more advanced signature using the StartTLS pattern to inspect the initial gRPC frames after the TLS tunnel is established.
—cp