The most secure and effective practice is to start with a default-deny posture. By initially blocking traffic and collaborating with the application team to generate test traffic, you can observe exactly which specific App-IDs (e.g., ‘ssl’, ‘web-browsing’, or a specific server application) are generated for the legitimate service. This ensures the final policy is precise, allowing only the necessary application, not just any traffic on port 443.

Palo Alto Networks firewalls use App-ID to classify traffic. A new or uncommon website might not yet be categorized as ‘web-browsing’ and may initially be identified only as the broader ‘ssl’ application. Since the policy only allows ‘web-browsing’, the ‘ssl’ traffic is denied. Updating the App-ID database ensures the firewall has the latest signatures to correctly classify the traffic, allowing the rule to function as intended.

DNS Security goes beyond port/protocol filtering. It inspects the DNS payloads themselves. It can detect and block DNS tunneling attacks, where data is encoded in DNS queries and responses. While a standard rule allows all DNS traffic, DNS Security enforces policy based on the content and behavior of the DNS transactions, preventing misuse of the allowed protocol for malicious purposes.

For an unrecognized proprietary application, you must first define what it is. This is done by creating a Custom Application Signature based on an analysis of the protocol’s characteristics (e.g., specific patterns, ports, or behaviors). Once defined, the firewall’s App-ID engine can then identify this custom application, allowing you to create a secure policy rule using the App-ID (e.g., allow ‘Custom-VoIP-App’) instead of relying on insecure, static port definitions.

Many critical sites, especially banks, use HTTP Public Key Pinning (HPKP) or similar techniques to bind their identity to a specific certificate authority. When the firewall performs SSL decryption, it presents its own certificate, which the pinned site rejects, causing a warning. The correct solution is to exclude such sensitive domains from decryption. A key consideration is maintaining a well-managed exclusion list to balance security inspection with user experience and compliance.

The log clearly shows the action was taken by a ‘security policy’. The application is ‘unknown-tcp’, and the action is ‘reset-both’. This indicates a security policy rule (likely a final explicit rule or the implicit intrazone rule) is configured to deny the ‘unknown-tcp’ application and to reset the connection. Threat Prevention blocks would show the action as ‘block’ or ‘alert’ with a different log type, not attribute the block to the security policy.

User-ID is the feature that maps IP addresses to user names by integrating with directory services (e.g., Active Directory via the User-ID agent, Windows Security Log monitoring, or LDAP). Without User-ID being correctly configured and sourcing data, the firewall logs would only contain IP addresses, making it impossible to generate a report filtered by specific admin user identities.

Security policy rules are zone-based. If the administrator created the rule from ‘trust’ zone to ‘untrust’, but the users’ traffic is originating from a different zone (e.g., a ‘guest’ zone or a separate ‘branch’ zone), the rule will not match. The source zone is a fundamental match criterion. The administrator must verify the path of the traffic and ensure the rule’s zone parameters encompass the actual source and destination zones of the denied sessions.

While allowing specific apps like ‘web-browsing’ is good, using a pre-defined or custom Application Group like ‘outbound-internet-access’ that bundles only the necessary, vetted applications (e.g., web-browsing, ssl, email, dns) is the best practice for least privilege. It is more manageable than dozens of separate rules and more secure than allowing ‘any’ application. It leverages App-ID’s intelligence to permit a known-good set of behaviors without opening the door to unknown or risky applications that might also use the same ports.

The most secure and effective practice is to start with a default-deny posture. By initially blocking traffic and collaborating with the application team to generate test traffic, you can observe exactly which specific App-IDs (e.g., ‘ssl’, ‘web-browsing’, or a specific server application) are generated for the legitimate service. This ensures the final policy is precise, allowing only the necessary application, not just any traffic on port 443.0