cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
358
Views
2
Helpful
7
Replies

Cisco SWA request sometimes hitting default policy when it should not.

aaron.nice
Level 1
Level 1

Hello,

maybe someone can help me with this issue.  From time to time it happens that user requests that should hit the user access policy are instead matching the default policy and are dropped. If the user refreshed the page, the correct policy is hit.

When this happens the user is correctly identified and all other matching conditions match. Its a S395 running 14.5
I have attached a screenshot where the blocked request can be seen because it matches the default-policy. Next request hitting the correct policy. Same user, same source IP. 

I had this happening in the past when users went via google sponsored links that the first initial request hit the default policy dispite all conditions matched for the user access policy. Now I have reports it is also happening when the users go the webpage directly and I am unable to reproduce it because it happens so randomly and not ver often. (1000 requests are fine matching the user policy, then suddenly one request hits default policy and user gets block page)

default.PNG
Any help is appreciated. 

 

7 Replies 7

Konstantinos9
Cisco Employee
Cisco Employee

Hello Aaron.nice,

In the example shared above, it seems that the allowed request is matching a custom URL category "OnPrem Routing Domains" while the blocked request is matching "Business and Industry" and in both we can see that there is a WBRS score: 3.0. We can see that the decision for blocking is the URL category.

It seems like the URL matching in the allowed request is part of a custom URL and you are matching a different policy because of that. You may want  to review the conditions for matching policies and review as well what is included in that customer URL category and any regular expressions that are configured and could be possibly matching that URL.

Hope this helps.

Kind regards,

Konstantinos

 

Hello Konstantinos,

 

this is correct. This URL is indeed part of Custom URL list "OnPrem Routing Domains". 
But the problem is both requests are to the same domain www.gw-world.com which is inside that list. All other conditions like source network and the user is the same. Thats why this request should never hit default policy (used to block more or less everything) but instead the the access Rule AP_Proxy_chaining_TSE like the request that is permited. But for some reason it does not match the correct policy in some cases and is then blocked because it hits default policy when it should not.

Edit: No regex used in the Custom URL. Just the domain www.gw-world.com 

Regards

aaron.nice
Level 1
Level 1

I should add as a note this is just an example and same issue i see with domains that are not part of any custom URL list. Even if its a content category, like in this case "Business and Industry" and not inside a custom list, it should match a access policy above the default policy because all conditions do match but for some reason sometimes they do not. 

In this example, user is successfully authenticated. That happens in the global Identification profile.
It should match this policy since user is authenticated in Global Idenfitication Profile and "Computers and Internet" is allowed in this Access Policy.

default-2.PNG

Instead of matching this policy it matches Default policy. Hitting refresh in the user browser it suddently matches to the correct Access Policy.

 

default-1.PNG

Konstantinos9
Cisco Employee
Cisco Employee

Hi aaron.nice,

In that case, I would also try to check your current authentication settings and identification profiles. Verify any conditions configured there.
Also check what kind of authentication surrogates are used and if the users should be matching the Identification profile that is part of your policy. A couple more things to take into account: Is this explicit or transparent deployment and if re-authentication is enabled.
If there's a problem with authentication, it could easily be an indication for matching another policy.

Hope this helps.

 

 

amojarra
Cisco Employee
Cisco Employee

Hello @aaron.nice 

 

As Konstantinos mentioned, it is best to check your ID profile and double check

[1] If you have some Custom CAT in the ID profile 

[2] Also please check the Surrogate type 

kindly check these 2 defect's conditions, 

CSCwb41795 : Bug Search Tool (cisco.com)

CSCwe63258 : Bug Search Tool (cisco.com)

the type of proxy deployment is important. 

Also I would say it is best to check which Decryption policy you are hitting and what is the URL CAT there. you can check them from CLI> grep > choose acesspolicy > filter for URL / or client IP.

 

In WSA, HTTPS traffic first hits Decryption policy then if it is set to Decrypt, it will match go Access Policy. 

 

Regards,

Amirhossein Mojarrad

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++     If you find this answer helpful, please rate it as such    ++++

+++++++++++++++++++++++++++++++++++++++++++++++++++

 

 

aaron.nice
Level 1
Level 1

Thanks a lot to both of you,

There is only one Identification Profile the user can match and thats the default one. Using explicit proxy. 
All other profiles above are noAuth Rules with IP + URL matching conditions. The user hits the correct "Global Group" for Authentication, otherwise user would not get authenticated because all other profiles are no Auth.

Auth Profile looks like this:

glob.PNG


 @amojarra I assume the first bug refers to having multiple Identification Profiles using an Auth Realm and using different Surrogates there. In my case I only use the global Group. All other profiles are no auth exceptions. 

Also second bug seems something else since in my case if the user trys to access the exact same URL again it will work on the second try and hitting correct policy. Also does not matter if its custom URL or a content category. 
My issue is that for example user opens webpage www.xyz.com it works in 99% of the time and matches the User policy. Then suddently one user receives block page because his request hit default policy instead of user. If he clicks the same link again it will work. 

Here is another example. Same user, same source IP accessing the exact same URL. One request hits the correct AP_Proxy_Chaining Policy, the other one hits Default Access Policy.

 

defaultp.PNG

amojarra
Cisco Employee
Cisco Employee

Thanks @aaron.nice 

I would say it is best to open a TAC case, we might need you to change some logging levels to Debug and review them. ( such as Proxy logs and Auth logs, ... ) , this will help us to see, what is the trigger.

Regards,

Amirhossein Mojarrad

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++     If you find this answer helpful, please rate it as such    ++++

+++++++++++++++++++++++++++++++++++++++++++++++++++