Traffic being incorrectly dropped on their Juniper SRX firewall. This issue was particularly related to the security policies, where legitimate traffic was not allowed through even though the firewall rules seemed correct. The error message seen in the logs was:
May 7 09:45:21 srx-firewall junos: %SECURITY-3: Deny traffic for policy ‘from_LAN_to_DMZ’ src 192.168.1.10/5000 dst 10.10.10.20/80
May 7 09:45:21 srx-firewall junos: %SECURITY-3: Deny traffic for policy ‘from_LAN_to_DMZ’ src 192.168.1.10/5000 dst 10.10.10.20/80
The logs were showing that the traffic was being denied by the firewall policy 'from_LAN_to_DMZ', even though the source and destination IP addresses and ports were clearly defined in the policy. This led the customer to believe that the firewall was misbehaving or incorrectly interpreting the policy.
Cause of the Issue:
After examining the configuration, Juniper support found that the security policies themselves were correctly defined. However, the firewall was mistakenly matching the incorrect policy for the traffic, despite it being allowed under the intended policy. This typically happens when the firewall’s session handling or policy ordering is misconfigured, or if there is an issue with policy inheritance.
In this case, the root cause was found to be policy mismatch due to overlapping policies, and the firewall was hitting an older, more general policy that denied the traffic, instead of the more specific policy that allowed it.
Solution and Commands Suggested by Juniper Support:
1. Check the Policy Order:
Juniper support recommended checking the order of the security policies. SRX firewalls process policies in the order they are listed, meaning that more general policies are evaluated before specific ones, and if a general policy denies the traffic, the more specific one may never be matched.
The customer could check the policy order using:
show security policies from-zone <source-zone> to-zone <destination-zone>
This would display the list of policies, and it would be important to verify that the more specific allow policy was listed above the more general deny policy.
2. Rearrange Policies to Ensure Correct Matching:
Juniper support advised the customer to rearrange the policy order so that the more specific policy, which allowed the traffic, came before the general deny policy. The following command was used to adjust the policy order:
edit security policies from-zone <source-zone> to-zone <destination-zone>
move <policy-number> before <policy-number>
For example, if the “allow” policy was policy number 2, and the “deny” policy was policy number 1, the customer could use:
move 2 before 1
This ensured that the firewall evaluated the “allow” policy before the “deny” policy.
3. Verify Policy Configuration:
Once the policies were reordered, Juniper support suggested verifying that the policy actions were correctly set. The action for the ‘from_LAN_to_DMZ’ policy should be set to permit, and the log action should be enabled to capture any future issues.
To check and correct the policy configuration, the following commands were used:
show security policies from-zone <source-zone> to-zone <destination-zone> policy <policy-name>
If needed, the command to set the policy action to “permit” would be:
set security policies from-zone <source-zone> to-zone <destination-zone> policy <policy-name> then permit
4. Check Session Handling:
The support team also recommended verifying that there were no stale sessions or session table issues that might have caused the traffic to be denied despite the policy configuration. To check the session table, the customer could run:
show security flow session
If stale sessions were found, they could be cleared by:
clear security flow session
his ensured that any old sessions did not interfere with new traffic.
5. Commit the Changes:
After making the changes to the policy order and verifying the session configuration, the customer was instructed to commit the changes:
commit
This applied the policy changes and session adjustments.
Final Outcome:
After rearranging the policies and ensuring the “allow” policy was evaluated before the “deny” policy, the legitimate traffic started passing through correctly. The error messages in the logs stopped appearing, and the firewall was now correctly matching the intended policy for the traffic.