Differences between URL category and address object?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

Differences between URL category and address object?

L2 Linker

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!

 

 

1 accepted solution

Accepted Solutions

@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.

Best Regards
Chacko

View solution in original post

8 REPLIES 8

L4 Transporter

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

Best Regards
Chacko

SSL 

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,

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...

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

@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.

Best Regards
Chacko

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?

@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.

  • 1 accepted solution
  • 9559 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!