Differences between URL category and address object?

[TLineberry]

We are doing some testing with a user that is running a client and needs to get out to the internet.

1. We have a policy for testing and added the required FQDN address objects to the destination. This was successful.

2. Next, we removed the address objects from the destination (replaced that with "any") and moved them to be part of an existing URL category group. We then added this URL category group to the testing policy. This has worked for us when testing in the past, but does not work now. 

Why would something work when added as an address object but not when it's part of a URL category group? Am I missing something? 

Thank you!

[Chacko42]

@TLineberry Which L7-Applications are you using in that policy?

[TLineberry]

SSL 

[OtakarKlier]

Hello,

Are you decrypting the traffic? If yes and you are not running version 9.0.x, the nyou will also need to add web-browsing and set the service ports to 443 and 80 for web-browsing. Also check the logs to see why its getting blocked. Could be a new application blocking the traffic.

Regards,

[TLineberry]

Hi, 

We are not decrypting the traffic. Checked the logs and we don't see anything, no other apps, etc. It's very odd! 

I just don't know why it would work when using destination address objects but not when using objects in a URL category...

[OtakarKlier]

Also check the URL logs to see if its blocking on the catagory the URL is in.

[Chacko42 · Accepted solution]

@TLineberry: That's expected behavior. The system needs to see the URL to match it agains your URL filter.

In TLS, the URL is part of the encrypted payload, if you're lucky and the server hosts multiple websites, it may use TLS-SNI. So you need to decrypt the traffic, to see the URL. When you use a FQDN address object, the palo simply does a dns forward lookup and whitelists the IP - that's independent from any URLs and works e.g. for CIFS traffic, which doesn't use URLs as well.

[RizwanJamil]

Hi @Chacko42 ,

I have observed Palo Alto PANOS 10.2.1 dropping the traffic even when it sees the same domain in the SNI field of the Client Hello packet, that is configured in the security policy allow rule, under URL Category field. And thus the website does not open at client's end. It is still unclear as to why the firewall is not able to match the two exactly same domains.

Please note that it is different from seeing in your browser "Your connection is not private" kind of message. In such case, the problem is that the SSL certificate offered by the server in response to the Client Hello packet, does not match the name of the domain initially requested by the client. While, my scenario is different, where the website does not open at the first place and we see the traffic blocked by the interzone-default rule of Palo Alto firewall.

Any idea why does it happen?

[RizwanJamil]

@Chacko42 please also note that I don't have URL filtering or SSL inspection enabled. So firewall is relying solely on the SNI information contained in the packet which is exactly the same as the one configured in the allow rule, however the firewall is still unable to match one with the other.