ICMP gets dropped by DEFAULT DENY ANY ANY

[mcjyrnn]

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 😞

[BrianRa]

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

Brian

[mcjyrnn]

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]

@mcjyrnn

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

[BrianRa]

@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]

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

[mcjyrnn]

Sounds risky as it this is a production firewall. 😞

[mcjyrnn]

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]

@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]

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. 😞

[BrianRa]

@mcjyrnnwould you try this rule for me.  You should not actually need two rules.  By adding both to the source and destination it allows any of the networks to ping eachother.

You can even copy one of the rules and modify it below the two existing.  Please also use just the applications I had.  RDP is something I would not allow both directions on all IPs.  However ICMP, PING, and TraceRoute should not be a problem for testing.

(Yes I did paint hack it ; )

The reasoning for traceroute, like previously mentioned, is to check to make sure the traffic is symetrical and not returning a different route (ping often doesn't mind this) or that it isn't trying to go out a different gateway and getting lost in space.

Brian

[mcjyrnn]

@brian, yes this is what you have mentioned above. Somehow this is a production firewall. Will have to secure approval on this one. But I really am consideting this suggestion. Will let you know oncw I have a feedback