Security policies not working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Security policies not working

L1 Bithead

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?

 

  • web browsing is blocked
  • ping is NOT blocked
  • RDP (mstsc) is also NOT blocked

Furthermore, looking at the traffic log there is no signs of any RDP traffic, pings, etc. Nothing is recognised.

 

Any idea?
Thanks

2 accepted solutions

Accepted Solutions

L4 Transporter

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.

Best Regards,
Suresh

View solution in original post

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

View solution in original post

2 REPLIES 2

L4 Transporter

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.

Best Regards,
Suresh

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

  • 2 accepted solutions
  • 340 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!