URL category not effecting to all traffic passing through security policy

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.

URL category not effecting to all traffic passing through security policy

L3 Networker

we are facing problem with PA 7.0.7 version , custom url category is mapped to security and certain URLS are allowed . when traffic passes the policy some of the traffics are allowed and then it hits the deny rule . The size of the packet becomes less when it is hitting the deny policy 

 

if we create a security policy only for one url it is working fine , which is work around for now , 

not able to use custom url category option 

 

this kind of issue was addressed in 7.0.1 version , please adivise what can be the troubleshooting steps to analyze and fix the issue 

 

this was working fine and started giving issues without any changes to the FW 

 

5 REPLIES 5

L7 Applicator

This was posted in the wrong area. 

I am moving this topic to the General Topics area.

LIVEcommunity team member
Stay Secure,
Joe
Don't forget to Like items if a post is helpful to you!

Cyber Elite
Cyber Elite

@Rameshwar,

Can I make the suggestion to update your software and address it if you are still running into the issue when you are on a current software release? You are 10 minor revisions out of date, many which have fixes addressing URL category issues. I would update to a current minor revision and see if the issue goes away. 

 

FYI,

7.0 is hitting EoL early December so I would start planning the migration to 8.0, or 7.1. 

EoL Dates

7.0: December 4, 2017

7.1: March 29, 2020

8.0: January 29, 2019

 

hi BPry 

 

thank you for the suggestion , can you please advise is there any issue ID created which was addressed in known issues to the specific issue so i will be sure to recomend the same to client 

 

appreciate your support 

L7 Applicator

Hi @Rameshwar

 

You could simply read the release notes here ( https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os-release-notes ) to check if you find something that matched your issue.

But the advise was meant as precaution ( @BPry please correct me if I'm wrong). If the update is done and the issue is gone -> good. If not you can open a TAC case to have them analyze the issue, because in the TAC case you probably also get the recommendation to update. And also if it is an issue that gets fixed, you will have to install the update. But the situation could then be even worse (at least for your customer), because if the issue is already presesent in 7.1 or even 8.0, the fix will may be only be applied there and not to 7.0 as the EoL date is already in 4 months.

 

But there still is the possibility that there is a totally different problem: are the connections that do not hit your custom category rule encrypted? If yes and you do not decrypt traffic, is the SNI attribute in the TLS handshake present? Did you test all the URLs in your category if you add all of them into seperate categories or does this sorkarouny only for some of the urls?

@Remo,

Yes and no. You'll need to update to really get TAC to look at it as it'll be one of the first things they do seeing your version number, but the 7.0.x code was a major issue with URL filtering and the URL cache in particular running into issues. Multiple fixes for issues with URL were released with 7.0.10 and pretty much every release to date for that version has addressed URL issues of varying degree. 

  • 2012 Views
  • 5 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!