Jump to content

IP reputation not working on Citrix Gateway Virtual Server via responder policy


Josh Slaney

Recommended Posts

Hello,

I have some responder policies that utilize IP reputation categories to display an HTTP block page for anything coming from a source IP that matches on the categories.   I have this policy applied at the override global HTTP request level.  These policies work for regular http/ssl VIP.  However, it does not work for the Gateway Virtual servers.  I have a case open with Citrix, but haven't seemed to make any progress.    I have tried applying the responder policy at the Gateway VIP level as well with no success.  I am running 13.0-85.19 code.   Is there a different way I should be applying this policy for the Gateway level VIPs?

Link to comment
Share on other sites

By default, responder runs after authentication if you bind it to the vpn vserver.

If your gateway is integrated with an authentication vserver (AAA), then there is a responder bind point on the Authentication vserver that processes responder policies BEFORE the authentication attempt.  (Your on 13.0, so I think this is present there as well.)

 

Not sure if you are have an issue with responder and gateway specifically, but changing where responder runs in the flow may help.

Link to comment
Share on other sites

Here's more details (with a rate limiting example), but you are looking for the AAA_request bind point on the authentication vserver (or see if it is available on the vpn vserver on 13.1). Example if you are on the authentication vserver and try to bind the responder policy in this vserver properties of the GUI,  you would see a specific extra bind point called "AAA Request".  This article mentions it exists for the vpn vserver too (I don't know if new in 13.1 or if previously it was only in cli and not exposed in GUI). But you could try binding from the CLI with your responder policy.

https://docs.citrix.com/en-us/citrix-adc/current-release/aaa-tm/citrix-adc-aaa-session-and-traffic-management/rate-limiting-with-gateway.html

Example:

bind authentication vserver <vserver name> -policy rs_pol_denylogin –pri 1 –type aaa_request

bind vpn vserver -policy rs_pol_denylogin –pri 1 –type aaa_request

 

If the issue is actually something with IPREP, you can try just a simple responder policy to drop a "test IP" and if it works on the exact client.ip.src test, but doesn't work on the IPREP, then you know it might be an IPREP issue.   You may also want a trace to confirm the user IP is the IP you expect and are comparing to IPREP and not coming through an unexpected proxy and so it doesn't match the range you are looking for.

 

Finally, share the policy expression you are using (or an obscured one) to see if the problem is in the expression.

Link to comment
Share on other sites

This is great information.   I have yet to try binding it on the AAA Vserver point.  I suspected it had to do with order of processing of policies, but I assumed anything at the override global level for HTTP would hit.   I will give it a test.  I do also have content switching I could try this at.  

Link to comment
Share on other sites

The GW has an Authentication profile attached to it that points to an AAA_VIP.  The AAA_VIP configuration has a policy that says do ldap and a next factor of radius for authentication.  I have applied a responder policy on the AAA_VIP with a policy that matches on source ip. Example: CLIENT.IP.SRC.EQ(10.0.0.1) Assume that 10.0.0.1 is my workstation IP.   When i attempt to connect to the gateway that has this AAA_VIP configured in the Auth profile, I do not get a match on the responder policy applied to the AAA_VIP.   When I apply this policy at the regular VIP level it is matching.

 

I did confirm when i applied the policy at the AAA_VIP level it had me set it as an AAA_Request type like is mentioned in the article.  Here's a sample of the config that's applied.

 

add responder policy IP_Reputation_Network_NoCallout "CLIENT.IP.SRC.EQ(10.0.0.1)||CLIENT.IP.SRC.IPREP_THREAT_CATEGORY(NETWORK))" DROP -logAction IP_Reputation_Network
bind lb vserver HTTPVIP_HTTP_Redirect -policyName IP_Reputation_Network_NoCallout -priority 90 -gotoPriorityExpression END -type REQUEST
bind authentication vserver AAA_VIP -policy IP_Reputation_Network_NoCallout -priority 100 -gotoPriorityExpression END

 

vserver HTTPVIP_HTTP_Redirect = Results in a match on the policy and a drop

authentication vserver AAA_VIP = Results in a non-match of the policy and I'm allowed through to the auth page.

 

Update: I believe this to related to the Auditing Message action  i have applied to these responder policies.  When I remove the logging aspect the policy appears to work correctly without logging enabled.   My message actions look like this:
"Netscaler Webroot IP Reputation Block - VIP:"+HTTP.REQ.LB_VSERVER.NAME+" Client IP:"+CLIENT.IP.SRC+" X-forwarded-For:"+HTTP.REQ.HEADER("X-Forwarded-For")+" issued a "+HTTP.REQ.METHOD+" for "+HTTP.REQ.HEADER("Host")+""+HTTP.REQ.URL.HTTP_URL_SAFE+" for category NETWORK"

 

I have confirmed the issue was with this portion of the logging:  "+HTTP.REQ.LB_VSERVER.NAME+" .  My guess is that because it was hitting a gateway instead of a VIP it wasn't actually completing the logging and the HTTP response action.  I will have to reach out to Citrix to determine why it wouldn't complete the blocking action due to the logging variables.

 

 

Link to comment
Share on other sites

Good job on figuring this out on your own.  As I wasn't thinking of an undefined in the logging action yet, just the policy expression.

Undefined results in policy expressions, policy actions, or the logging action usually result in a "do nothing" results which means it can't apply this policy.

You can insert VIP or extract hostname from user request, but logging needs to be kept simple to avoid a "violation".  You could try seeing if the Responder policy action is set to override global and drop or reset on undefined would catch this, but it may catch other things too (I would set at policy and not change global behavior.)

 

If you had a policy with a request that is undefined, then the feature "default undefined result" is usually NOOP or NORESPONDER or some "do nothing" equivalent.  Its tricker when it is a policy dependency like the action or the log action as the ADC just cannot do the thing you want so it abandons the primary action.

 

Here are some other times, I've seen it in discussions (one may just be about potential of undefined result):

https://discussions.citrix.com/topic/415953-citrix-adc-content-switching-policy-default-load-balancing-virtual-server/#comment-2089659

https://discussions.citrix.com/topic/415518-customized-syslog-messages/#comment-2088139  (< this one may be more relevant.)

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...