ICMP gets dropped by DEFAULT DENY ANY ANY

Reply
mcjyrnn
L1 Bithead

ICMP gets dropped by DEFAULT DENY ANY ANY

Source IP: x.x.172.230

Source Zone: int-fw

 

Destination IP: x.x.20.50

Destination Zone: DMZ

 

Requirements: SRC and DST IPs should be pinged bi-directionally.

 

Scenario:

- I've allowed the traffic using ICMP, ICMP-0, ICMP-8, PING bi-directionally but still unsuccessful

- Upon checking the logs, I can see that from SRC ----> DST is allowed using the RULE that I just entered

- Upon seeing the return traffic, it falls to the DENY ANY rule. 

- Also in the return traffic, the src zone is int-fw and the dst zone is int-fw also

 

**My rule is above the DENY ANY rule. Please help :(

 

Tags (2)
BrianRa
L3 Networker

Here is our global ICMP rule.  We specifically had to add traceroute as well.

icmp_global.jpg

 

Brian

mcjyrnn
L1 Bithead

Hi Brian, actually I've tried to change the application to ANY. But still no good, it still falls on DENY ANY ANY rule. :(

reaper
L7 Applicator

@mcjyrnn

could you provide a screenshot of your security policy and logs ?

Tom Piens - PANgurus.com
Like my answer? check out my book! amazon.com/dp/1789956374
BrianRa
L3 Networker

@mcjyrnn, we have found that the destination side doesn't really matter (as far as being allowed back, it is a solicited response at that point) as it is all based on the source User, Zone, IP.  Something you are filtering on does not match what the rule is configured for.  You can pull the rule from the CLI as well (I had to pull from Panorama as I push my rules).

 

Panorama> set cli config-output-format set
Panorama> configure
Panorama# show device-group MY_FIREWALL pre-rulebase security rules Global_ICMP
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP profile-setting group MY_Strict_NO_URL
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP target negate no
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP to any
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP from [ MY_ZONES ]
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP source any
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP destination any
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP source-user any
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP category any
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP application [ icmp ipv6-icmp ping traceroute ]
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP service application-default
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP hip-profiles any
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP action allow
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP rule-type universal
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP description "ICMP, Ping, Traceroute"
set device-group MY_FIREWALL pre-rulebase security rules Global_ICMP log-setting MY_TRAFFIC_LOGS

 

A test you could do is set both source and destination Users, Zones, IPs to ANY.  Obviously this is not a long term fix but as a test it would let you know if ICMP in general is being caught by your rule.

 

Brian

mcjyrnn
L1 Bithead

Hi Reaper, those were the logs that I was able get. Attaching the screenshots of my security policies.

rule.png

mcjyrnn
L1 Bithead

Sounds risky as it this is a production firewall. :(

mcjyrnn
L1 Bithead

What confuses me a lot is the following:

 

1. I believe the first rule should be fine, as Palo Alto is using stateful inspection. However, still I'm getting RTO.

2. Based from the logs that I've gathered.

 

From src IP to dst IP is being allowed, but still RTO. :(

I tried to check if I will be able to see the echo reply, then I found these logs which falls to the deny any any & also:

 

The logs shows that the traffic is interzoning. But it shouldnt be. :(

BPry
Cyber Elite

@mcjyrnn,

It looks like your security policy should be fine but I've ran into this a few times in the past when the following happens. 

I've ran into a thing in the past where the security rule was working as intended, but the return traffic wasn't registering as returning on the same zone due to some routing funk they had going on at the time. So even though the policy was set to allow the traffic from the 'trust' zone to the 'SfB' zone, the return traffic as the firewall saw it was actually coming back on the 'DZM' zone. Since this wouldn't match the session as return traffic it would fail since we didn't have a rule that allowed traffic in the other position. 

I'm wondering if potentially this isn't your issue; that would explain why it isn't working even with the security policies you've tried. 

mcjyrnn
L1 Bithead

There are policies that are being allowed going to the samw subnet of the DMZ network but those were servces that were allowed. This one still not working. :(
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!