The same traffic is getting allowed by one rule and blocked in firewall by another (please refer scrnshot)

[JubairJunaid]

So we have a explicit Deny all rule at the bottom most, and there is another rule by which the same traffic is also getting allowed.

The allowed rule has dest as any and has URL category in it with service as https.

So if u can see the screenshot same traffic is getting blocked by bottom most Deny ALL and allowed by the <Int prod to lambda URL> rule

Only difference is the Action source, for denied traffic it is "from application" and for allowed traffic "from-policy"

Kindly let me know why the same traffic is getting allowed by 1 rule and blocked by other. 

[JubairJunaid]

[Raido_Rattameister]

You are logging session beginning and end.

First firewall needs to let through TCP 3way handshake.

After that it identifies real application and if that application is not in the policy then Palo starts looking for following rules below.

Usually you want to enable logging at session beginning only during troubleshooting sessions.

[JubairJunaid]

Thanks, I will try that, but will it resolve the issue or just give me the correct logs ?
Wont enabling Log at session start cause more load to cpu for the explicit Deny rule.

[Raido_Rattameister]

"Thanks, I will try that, but will it resolve the issue or just give me the correct logs ?"

In initial post you mentioned that rule that permits traffic has URL category in it.

Thing is that Palo can't identify URL category based on first packet.

Assuming that traffic is pure HTTP then Palo can identify application based on 5th packet (in case of HTTPS URL is retrieved from SNI on the cert).

SYN (client to server)
SYN ACK (server to client)
ACK (client to server)
HTTP GET (client to server)

WEBSITE DATA BACK TO THE CLIENT <<< this is where Palo identifies traffic as web-browsing. (server to client)

So initial 4 packets need to be permitted through by some rule and in your case you see it in logs because you have log at session start checked.

If you don't want initial TCP 3way handshake to match some random rule you can add before any outgoing rule this nonsense rule that in reality would never permit pings (because ping is ICMP protocol) but it would log all TCP 3way handshakes under single rule name so you can run reports against it etc as needed.

Adjust it according to your needs as it is very broad permitting outgoing SYN sent on any port (you might want to limit it to 80 and 443).

"Wont enabling Log at session start cause more load to cpu for the explicit Deny rule."

You already have log at session start checked. You need to uncheck it to see logs  correctly.

I assume it based on session end reason being "n/a" for those logs.