- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-07-2025 12:54 PM
I've come across the most odd issue that I can't figure it out for the life of me. I am only hopping it's some silly "tick box" or something I have missed. Long story short...
I have created a very simple top security rule with IP address as a source (any zone/user/device) towards any destination (any zone/application/service) and set it to deny. Sadly it doesn't work fully. Example below - how can that even be?
Furthermore, looking at the traffic log there is no signs of any RDP traffic, pings, etc. Nothing is recognised.
Any idea?
Thanks
03-08-2025 06:44 PM
Hi Can you share you policy config to look into it.
However here the possible reasons for the issue.
it sounds like your top security rule should be blocking all traffic from the specified source IP, but some traffic types (ICMP for ping, RDP) are still passing through.
1. Ensure the Traffic is Routed Through the Firewall
If you don’t see any logs for RDP or ICMP traffic, the firewall might not be processing these packets.
Verify that the traffic is actually passing through the firewall and not taking an alternate route (e.g., direct L2 switching or a different gateway).
2. Check for Security Policy Matching
Use the Test Security Policy Match tool in PAN-OS to see if the traffic is hitting the expected rule.
If the traffic is not matching your deny rule, it might be getting permitted by another rule lower in the rulebase.
3. ICMP and Ping Handling
By default, ICMP (ping) is often handled by a separate setting under Network > Network Profiles > Security Profiles > Zone Protection Profiles rather than the security policy.
Ensure your Zone Protection Profile is configured to block ICMP if needed.
4. Application Identification and Session Setup
Some protocols like RDP (mstsc) might not be identified immediately in the first few packets.
Ensure your rule is not limited to a specific application but instead set to "any" in the application field.
If using application-based security policies, try switching to a service (port-based) rule instead.
5. Check for Asymmetric Routing
If the firewall sees only one side of the communication, it may not properly detect or log the traffic.
Run Session Browser under Monitor > Session Browser to check if the sessions are established as expected.
6. Security Rule Logging and Logging at Session End
Ensure your deny rule has "Log at Session End" enabled so that all blocked attempts are visible in the traffic logs.
Would you be able to provide a screenshot of your security rule or clarify if NAT is involved? That could help narrow down the issue further.
03-11-2025 08:38 AM
Hi, Suresh,
Many thanks for your detailed help - while it didn't help I got to the solution at the end 😀
For some reason, when reading number 5., I got an idea from your number 1. where mentioning if it's actually passing through the firewall - and then it hit me! And I am not ashamed to admit that I am still learning PA and the networking so I haven't thought of the "intrazone" rule and scenario straight away. Both hosts were on the same subnet/zone. Hence the traffic was not traversing firewall if it didn't go out of the zone, and of course hitting the rules. So anything in the same zone was working all the time, while anything going one was hitting the correct rules - hence discrepency.
Regardless, you gave me the idea and it's still kind of "accepted" solution, so thank you 🙂
G
03-08-2025 06:44 PM
Hi Can you share you policy config to look into it.
However here the possible reasons for the issue.
it sounds like your top security rule should be blocking all traffic from the specified source IP, but some traffic types (ICMP for ping, RDP) are still passing through.
1. Ensure the Traffic is Routed Through the Firewall
If you don’t see any logs for RDP or ICMP traffic, the firewall might not be processing these packets.
Verify that the traffic is actually passing through the firewall and not taking an alternate route (e.g., direct L2 switching or a different gateway).
2. Check for Security Policy Matching
Use the Test Security Policy Match tool in PAN-OS to see if the traffic is hitting the expected rule.
If the traffic is not matching your deny rule, it might be getting permitted by another rule lower in the rulebase.
3. ICMP and Ping Handling
By default, ICMP (ping) is often handled by a separate setting under Network > Network Profiles > Security Profiles > Zone Protection Profiles rather than the security policy.
Ensure your Zone Protection Profile is configured to block ICMP if needed.
4. Application Identification and Session Setup
Some protocols like RDP (mstsc) might not be identified immediately in the first few packets.
Ensure your rule is not limited to a specific application but instead set to "any" in the application field.
If using application-based security policies, try switching to a service (port-based) rule instead.
5. Check for Asymmetric Routing
If the firewall sees only one side of the communication, it may not properly detect or log the traffic.
Run Session Browser under Monitor > Session Browser to check if the sessions are established as expected.
6. Security Rule Logging and Logging at Session End
Ensure your deny rule has "Log at Session End" enabled so that all blocked attempts are visible in the traffic logs.
Would you be able to provide a screenshot of your security rule or clarify if NAT is involved? That could help narrow down the issue further.
03-11-2025 08:38 AM
Hi, Suresh,
Many thanks for your detailed help - while it didn't help I got to the solution at the end 😀
For some reason, when reading number 5., I got an idea from your number 1. where mentioning if it's actually passing through the firewall - and then it hit me! And I am not ashamed to admit that I am still learning PA and the networking so I haven't thought of the "intrazone" rule and scenario straight away. Both hosts were on the same subnet/zone. Hence the traffic was not traversing firewall if it didn't go out of the zone, and of course hitting the rules. So anything in the same zone was working all the time, while anything going one was hitting the correct rules - hence discrepency.
Regardless, you gave me the idea and it's still kind of "accepted" solution, so thank you 🙂
G
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!