|
Symptoms:
Administrators may observe the following in the traffic logs:
- Action: Deny.
- Policy: 0 (Implicit Deny).
- Destination port not listed in any allow policy.
- Application traffic is failing to reach the server.
Even though an allow policy exists for the source and destination addresses, the traffic continues to match the implicit deny rule.
Applicable to both IPv4 and IPv6 policies, including policy-based and zone-based deployments.
Cause: This issue typically occurs when the application uses non-standard, dynamic, or vendor-specific ports that administrators may not be aware of.
As a result:
- The traffic did not match any existing allow policy.
- It was forwarded to the implicit deny rule, which drops all unmatched traffic.
- Logs displayed Deny actions for the affected sessions.
Identifying Unknown/Unlisted Ports:
Use the following methods to find the exact port required by the application:
- Check traffic logs for dropped session details.
- Use sniffer/capture:
diagnose sniffer packet any 'host <server_IP>' 4
- Vendor application documentation.
- Debug flow to extract the destination port.
- Debug flow output will explicitly show the destination port and the policy lookup result, including:
no matching policy, drop
Example: A third-party application uses TCP port 9005 for agent communication. Since this port was not included in any service group within the firewall rule, traffic failed and hit the implicit deny policy.
Solution:
- Create a custom service for the required port.
Navigate to: Policy & Objects -> Services -> Create New.
Specify:
- Service Name.
- Protocol (TCP/UDP).
- Destination port or port range.
CLI example:
config firewall service custom
edit "<custom_service>"
set tcp-portrange <port_number>
next
end
- Add the Service to the Relevant Firewall Policy.
Navigate to: Policy & Objects -> Firewall Policy -> Edit Policy -> Services. Add the newly created service to the allowed services list.
CLI example:
config firewall policy
edit <policy_id>
append service "<custom_service>"
next
end
- Verify Traffic Flow.
After updating the policy:
- New sessions should match the correct firewall policy.
- Logs should show Accept rather than Deny.
- The application should operate normally.
Verification:
Use the following methods to confirm the fix:
- Forward traffic logs to verify policy match and action.
- Session list ('diagnose sys session list') to validate active sessions
- Packet capture if further confirmation is needed.
Note: One easy way to identify the port getting blocked is to enable logging on the implicit deny policy. This will give more insight into the ports or services being blocked. Accordingly, the Firewall policy can be modified.
Technical Reference: FortiGate processes traffic based on strict service port matching, and any port not explicitly defined in a firewall policy defaults to the implicit deny rule.
Conclusion:
Traffic may be denied by the implicit deny rule when the application uses a port that is not included in any firewall policy. Creating the required custom service and adding it to the appropriate allow policy resolves the issue and ensures the traffic is correctly matched and permitted.
|
