Traffic denied by one context is allowed in the other

[SrikanthSingireddy]

Hello All,

I have a strange situation and need some help.

I have 2 legs of my firewall implemented on Core and Edge level.

I have a host 10.1.1.10 behind my Core layer firewall trying to access an external FTP server.

On the core layer I have a policy to deny ftp traffic from inside to outside and the logs show the traffic is denied.

But on the Edge level i see one more traffic log saying allow for the same traffic. ( Edge has a rule to allow any type of traffic)

The default gateway of Core firewall is pointing towards the edge firewall.

Any help on this is much appreciated.

Thanks.

Srikanth

[hshah]

Hi Srikant,

Please upload both "Allow"ed and "Deny"ed traffic log in thread.

That will help me to determine root cause.

Regards,

Hardik Shah

[HULK]

Hello Srikanth,

If you enable packet capture on the PAN firewall, please verify, if any packet received or transmitted through PAN.

Also, you can check the real time session in the CLI by using 'show session all filter source IP_ADD_OF_THE_TESTING_PC destination IP_ADD_OF_THE_DESTINATION'.

>  If there is a session exist for the same traffic,  then please apply  CLI command PAN> show session id XYZ   >>>>>>>> to get detailed information about that session, i.e NAT rule, security rule, ingress/egress interface etc.

Hope  this helps.

Thanks

[reaper]

Hi Srikanth

If you enable packetcaptures you'll likely see that the edge firewall is receiving a tcp handshake (and is logging an accept action for that)

On your core firewall you are blocking based on application, but that application can only be determined after several packets have passed through that allow the forewall to positively identify ftp. In this case the tcp handshake will need to be allowed through before the first ftp packet is seen, identified and denied. by that time the edge firewall has also seen the handshake and has a session open pending the next packet, which will never arrive as the core firewall blocked it.

If you want a more strikt policy you can add service ports to your security policy which will block traffic before it requires identification. setting a block policy for port 21 will block normal ftp from the very first packet. on the other hand, using only the service port will not block an application if it is running on a different port (hence the power of appID), buit will require some packets (tcp handshake) to be trickled through for the process to function properly

hope this helps

Tom

[tshiv]

Hi Srikanth,

Agree with what tpiens had to say. Also wanted to mention that there are users who try to use application default service in the security policy blocking FTP traffic so that traffic only on tcp port 21 is blocked. But this is not recommended. If you are trying to block FTP traffic, it is better to block on all service ports instead of default ports only.

Thanks

[SrikanthSingireddy]

Hello All,

I was thinking about the same to determine the application  palo alto needs several packets to understand the behaviour.

But the same thing is not happening for other tcp traffic like http and https and we have verified this.

Also just in case if there are 2 contexts of firewalls used for 2 different companies then seeing one firewall log on the other is a serious concern.

Support team isn't able to help me in this as well.

Thanks,

[SrikanthSingireddy]

Please follow the logs from bottom to top

The host 172.17 is inside the core network and is being denied by the Core firewall.

The same traffic is reaching the Edge firewall and is being allowed according to a rule configured on the Edge firewall basically permitting ftp access outside.

Any help on this?

[kfindlen]

Are you expecting that the traffic will never reach the Edge firewall because of the deny policy on the Core, and therefore you should not even see a session on the Edge?

Are the Core and Edge firewalls different vsys on the same physical device?

[hshah]

Hi Srikant,

There is 40 second delay between similar traffic logs. If traffic log was generated because of same packet than log should have been generated immediately.

Regards,

Hardik Shah