Application traffic matches the implicit deny policy despite an allow policy

1. Identify the destination port used by the application.
   • Review traffic logs for the dropped session and destination-port details.
   • Capture traffic to or from the server:

diagnose sniffer packet any 'host <server_IP>' 4

• Review the application vendor's documentation.
• Use debug flow to obtain the destination port and policy lookup result. A failed lookup can include no matching policy, drop.
• Enabling logging on the implicit deny policy is an easy way to identify blocked ports or services.

2. Create a custom service for the required port in Policy & Objects -> Services -> Create New. Configure the service name, protocol (TCP or UDP), and destination port or port range.

   CLI example for a TCP service:

config firewall service custom
    edit "<custom_service>"
        set tcp-portrange <port_number>
    next
end

3. Add the custom service to the applicable firewall policy. In the GUI, go to Policy & Objects -> Firewall Policy -> Edit Policy -> Services, then add the new service to the allowed services list.

   CLI example:

config firewall policy
    edit <policy_id>
        append service "<custom_service>"
    next
end

4. Generate new application traffic so that new sessions are evaluated against the updated policy. The sessions should now match the intended allow policy rather than policy 0.

Confirm that forward traffic logs show the expected firewall policy and an Accept action instead of Deny. Check active sessions with:

diagnose sys session list

Use a packet capture if additional confirmation is required. Verify that the application can communicate with its server normally.