Blocking outside-to-outside blocks ping from outside interface. Is that ok?

[mr_almeida]

Hi Gang,

First, thanks for having a look and a big thank you for taking the time to respond.

I recently created a security policy rule that blocked outside-outside zone traffic. I did this due to outside traffic that did not match any NAT rules, for some reason, ended up matching the intrazone-default rule. Although this effectively allowed such traffic, such traffic simply aged-out since we have nothing on those public IP addresses (it is all NATed after all). This is improves insight, statistics and so on since this traffic was no longer being allowed.  

I did however notice that, when attempting to ping from the public interface of the firewall, it was hitting the same outside-outside deny rule. This is expected since the ping from public interface is after all outside-to-outside zone. Disabling the rule of course means the ping now works.

I am wondering what you all have done in this circumstance? Though we can ping from the inside but are you happy that you can't ping from your outside interface? I was worried it would potentially break path monitoring etc. but that works from the inside so that's fine.

Thank you kindly!

Daniel

[SutareMayur]

Hi@mr_almeida 

Initially when i started working on Palo Alto devices, i had also came across same situation. I was concerned about traffic which was matching between (outside to  outside) zone due to intrazone default rule. As rightly said by you, although there is nothing behind those matching public IPs (as no NAT rule defined) still i had blocked it by adding security policy which will block traffic from outside-to-outside zone and yes, it also blocked internet traffic from external interface. So to avoid this, i did below things.

1. I had added new security policy before existing outside-to-outside zones blocked security policy and allowed any internet from my external public IP address. I had to add this security policy as there were internet dependencies as given below from my external interface.

a. I had few tunnels from my same firewall, so due to outside-to-outside zones security policy, it may have brake my communication between  my external interface and the remote end peer public IP.

b. I had some path monitoring enabled on my external interface so this also may have brake that path monitoring.

So to avoid this, i had added one more security policy mentioned in point 1 before outside-to-outside zones blocked security policy.

With this, i was all set. It didnt broke my internet communication from external interface, also it stopped matching intrazone default policy for traffic outside-to-outside zone.

I will also recommend you to allow internet if you really need it from external interface. Otherwise, if in future you have requirement of tunnel (just an example), you will have to add policy at that time to allow communication with remote end peer. Currently if you do not have any dependencies on internet reachability from external interface, you should be good then. But you should remember to make necessary changes if you got any such requirement in future.

Hope it helps!

[mr_almeida]

Good morning and thanks for your response @SutareMayur  !

Yes I was thinking of having a security policy rule (but placed before the outside-to-outside block) that allows:

• zones: outside to outside 
• source: Our Public IP address scopes 
• Destination: any

This should fix the issue of our outside source traffic being blocked while still blocking the not NATed default-intrazone outside traffic. This seems to be inline with what you mentioned in point 1. 

The issue is we have quite a large block of public address. Is it possible to use a range or scope? We have of course created address objects for the current addresses we use but seems tedious to add n number of IP address to a address group. 

Thank you for pointing out the future issues. We don't need them at this time but definitely taken note of. 

Thanks,

Daniel

[SutareMayur]

@mr_almeida  If you have large block of public IP address which will send internet request traffic as a source, then yes  you can add security policy for allowing whole range/scope as a source or you can also add address group under security policy. You should be good with any of the two ways.

[tommyschoemans]

Any idea why the source NAT'ed traffic is subject to being dropped by the untrust-to-untrus drop rule? As this doesn't make sense to me becasue snat is done on egress stage of the traffic flow so no policy lookup/check should be done here.