So, the upgrade checklist said "review security policies post-update" and you thought it was just CYA boilerplate. Welcome to the club. I've just spent the better part of a night watching a perfectly functional set of policies turn into digital ghosts after an upgrade from 21.4R3 to 22.2R1 on an SRX cluster. The kicker? The packet capture shows the traffic hitting the interface, the policies *look* fine in the config, but the session table remains empty and the traffic dies. No `deny` log entries, no `session-close` logs, nothing. It's as if the packets are being politely shown a door that doesn't exist.
Of course, the immediate assumption is "you messed up the policy order" or "there's an implicit deny." Please. This is a controlled, versioned config. The policies in question are for a specific non-standard service (a custom TCP port for an internal tool). The generic HTTP/HTTPS policies work fine. The logs are set with `session-close` and `session-init`. Yet, silence.
The config snippet looks clean:
```
set security policies from-zone trust to-zone untrust policy internal-app match source-address app-servers
set security policies from-zone trust to-zone untrust policy internal-app match destination-address external-api-host
set security policies from-zone trust to-zone untrust policy internal-app match application custom-tcp-app
set security policies from-zone trust to-zone untrust policy internal-app then permit
set security policies from-zone trust to-zone untrust policy internal-app then log session-close
set applications application custom-tcp-app protocol tcp
set applications application custom-tcp-app destination-port 8500-8550
```
The upgrade path was supported, the commit was clean, and the only changes were Juniper's. The "best practice" of checking logs shows nothing. This feels like one of those delightful edge cases where a new default behavior or a hidden change in the application firewall or ALG processing gets introduced. Anyone else seen policies that pass the visual sanity check but go functionally dormant after an upgrade? Specifically around custom application definitions or non-RFC standard ports? I'm about to start digging through the release notes with a fine-tooth comb for the phrase "changed default behavior of..."
You've hit on a classic post-upgrade symptom where the config looks intact but the runtime behavior changes. The fact that generic HTTP/HTTPS works while your custom TCP port policy doesn't is a major clue. Juniper has been tightening security policy processing order and session helper behavior between those major releases.
I'd suggest checking two specific areas that often go silent. First, verify the application identification settings. In 22.2, there's a stronger push toward AppID, and a custom port might not be recognized if the default application is now set to "any" with stricter inspection. Second, and more likely, look at the TCP session helper or ALG configuration for that custom port. An upgrade can reset or alter the `application-identification` settings silently, causing the packet to be dropped pre-policy because it's seen as malformed.
Run `show security flow status` and `show security alg tcp` to see if the ALG state changed. A quick test is to temporarily add `set applications application your-custom-app protocol tcp destination-port your-port` and reference that in the policy instead of `application any`.
null
Your config snippet cuts off, but I'm betting the custom TCP port is defined under `destination-port`. That's where the runtime behavior can diverge silently after an upgrade. Juniper has been moving more logic into the session manager for non-standard ports.
Check this: the default application for your custom port might have changed from `junos-tcp-` to `any`. You can verify by running `show security match-policies` with a simulated packet from your app-servers to that destination port. If it hits a different application than expected, the policy won't match, and it'll fall through without logging.
Also, run `show security flow status` and look at the ALG section. If the TCP ALG for that port got disabled or its inspection profile changed, it can drop sessions quietly.
sub-100ms or bust