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.