Jump to content
Welcome to our new Citrix community!

Responder policy with forwarding action


Amin al-herbawi

Recommended Posts

So forwarding this in this context sounds like you want the load balancing to work if on whitelist and the traffic to be blocked if not.  Meaning traffic hits vserver and then reaches the service.  Responder is used to prevent this behavior, typically.   If by forwarding the user is making a connection to a new destination directly, then use RESPONDER to REDIRECT (you have to create a custom action for this one.)

 

If you mean something else by the "forward" behavior, please clarify.  But in general, RESPONDER responds so the servers don't have to and can filter traffic hitting an lb or cs vserver (among others).  Content Switching can also be use to allow specific traffic to be sent to specific lb vservers/services.  

 

1. Create lb vserver and services for backend destination.

2. Create a responder policy to DROP, RESET, or REDIRECT traffic if NOT on whitelist.   Depending on how you want the non-whitelist traffic handled.  If the REDIRECT type is used, specify the redirect url you want to display the "error" if not permitted.

3. Depending on the size of your whitelist, you could create the responder policy expression with an explicit list of allowed IPs as an OR clause, a pattern set/data set of a much longer list of IPS, or if constantly changing list you could use a callout.  Expressions can also be used based on subnets or client ip headers.

 

Responder expressions to apply for traffic NOT on whitelist:

Example 1:  list of IPS

!(client.ip.src.eq("192.168.10.10") || client.ip.src.eq("192.168.10.11") || client.ip.src.eq("192.168.20.30")|| <more allowed whitelist ips...>)

 

Example 2:  with pattern sets (can be built under AppExpert; can also work with datasets)

add policy patset ps_whitelistIPs

bind policy pateset ps_whitelist IPS 192.168.10.10

bind policy pateset ps_whitelist IPS 192.168.10.11

bind policy pateset ps_whitelist IPS 192.168.20.30

bind policy pateset ps_whitelist IPS 192.168.20.35

 

Expression with pattern sets:

!client.ip.src.eq_any("ps_whitelistIPS")

 

 

  • Like 1
Link to comment
Share on other sites

thank you for your response,

 

my case in specfic is as follow,

 

rule#1 if from this IP subnet --> action: allow to backend ( normal lb) 

rule#2 if  NOT from this IP subnet --> then DROP 

 

if rule number one is true and IP is from range, I dont want to evaluate the second one.

I guess the best way is to merge them into the second responder rule i believe.

 

Best Regards

Link to comment
Share on other sites

[1] First, Normal load balancing:

add service svc_1 <ip1> http 80   # or ssl 443 etc...

add service svc_2 <ip2> http 80 

add lb vserver lb_vsrv_demo http <VIP> 80

bind lb vserver lb_vsrV_demo svc_[1-2]

 

[2] Next, how responder policies are processed.

  • Responder policies are your filtering feature and they run before MOST other features on the system (exceptions being appfw and AAA authentication, but not relevant to this conversation).
  • Responder policies also operate in a "first match, then out" behavior.  Because the typical responder policy action is stop the transaction by either DROP, RESET, REDIRECT (or some other custom RESPONSE).  Any policy hit usually terminates the transaction.
    • So IF two policies were applied and they BOTH match, the first hit is the one that takes the action and the second policy is never evaluated.  If policyA is DROP and policyB is redirect, then the DROP wins. The second policy doesn't matter. You can only DROP this transaction once. You can't both drop and reset it at the same time. Etc..
    • If two policies are bound, and the first policy only affects traffic from SUBNETA (DROP) and the second policy only affects traffic from SUBNET B (RESET).  Then....
      • Traffic from SUBNETA is compared against policy1 in this example. It hits, traffic is DROPPED. This transaction is now stopped and no more responder policies are evaluated or any other feature on this transaction.  We dropped it. (Same if you make the action reset or redirect, just redirect responds and client is forced to connect to new location indicated by redirect).
      • If Traffic is from SUBNETB hits the vserver, then when it is compared with policy1, there is no match, so no action applies. Then the evaluation compares to Policy2, which in this case IS a MATCH and so Policy2's RESET is performed. And transaction is stopped.
      • If Traffic comes from SUBNETC which doesn't match any policy, then the traffic continues to vserver.
  • For policies to stop processing after first matching policy hit occurs, the GOTO expression is set to END when binding policies.  For some features, this behavior can be changed to "find all matching policies" such as in REWRITE.  For this, the GOTO expression is set to NEXT. However, because Responder policy actions stop the transactions, NEXT isn't allowed (unless using the NOOP action; which isn't needed here.).  So REsponder DROP/RESET/REDIRECT/Custom Response (import) are all "END" mode and stop after first hit; if no hit, the feature doesn't apply.

[3] So now, how resopnder works: While you could have two policies in our example, you don't need them.

Your requirements:

  • Traffic from SUBNET1 (whitelist) IS ALLOWED to be load balanced.
  • Traffic from anywhere else (not on whitelist) IS BLOCKED.

Example 1: single policy only drops when not in whitelist...

Traffic hitting the lb vserver will be allowed UNLESS a responder policy stops it. Technically, you only need one policy. 

The "!" is a NOT indicator.   For expression:  !client.ip.src.in_subnet("x.x.x.x/yy"),

  • any IP in Whiteilst subnet is TRUE on the in_subnet comparison, therefore the expression is !True == FALSE. Policy does not stop whitelist traffic.
  • any IP not in Whitelist subnet is FALSE on hte in_subnet comparison, therefore the expression !(in_subnet) is !(FALSE) == TRUE.  Responder policy will drop everyting NOT in whitelist.
  • If the policy hits, traffic is blocked (not in whitelist). Policy doesn't apply to any traffic in whitelist, and load balancing occurs.

add responder policy rs_pol_drop_nonwhitelist '!client.ip.src.in_subnet("x.x.x.x/yy")' DROP

bind lb vserver lb_vsrv_demo -policyName rs_pol_drop_nonwhitelist -priority 100 -goto END

 

Note: if you had multiple subnets the expression would be:  !(cient.ip.src.in_subnet("x.x.x.x/yy") || client.ip.src.in_subnet("a.a.a.a/bb") || ...)

 

Example 2:  Even if we had a allow on whitelist and block other behavior, even if two policies were bound. They would both bet setup with GoTo END so if either matched only one action applies.  The difference is for the 'allow' traffic you would use the NOOP; but its not recommended as NO RESPONDER POLICY means traffic continues normally per load balancing.

 

 

 

 

 

  • Like 2
Link to comment
Share on other sites

On 10/3/2022 at 12:26 AM, Rhonda Rowland1709152125 said:

[1] First, Normal load balancing:

add service svc_1 <ip1> http 80   # or ssl 443 etc...

add service svc_2 <ip2> http 80 

add lb vserver lb_vsrv_demo http <VIP> 80

bind lb vserver lb_vsrV_demo svc_[1-2]

 

[2] Next, how responder policies are processed.

  • Responder policies are your filtering feature and they run before MOST other features on the system (exceptions being appfw and AAA authentication, but not relevant to this conversation).
  • Responder policies also operate in a "first match, then out" behavior.  Because the typical responder policy action is stop the transaction by either DROP, RESET, REDIRECT (or some other custom RESPONSE).  Any policy hit usually terminates the transaction.
    • So IF two policies were applied and they BOTH match, the first hit is the one that takes the action and the second policy is never evaluated.  If policyA is DROP and policyB is redirect, then the DROP wins. The second policy doesn't matter. You can only DROP this transaction once. You can't both drop and reset it at the same time. Etc..
    • If two policies are bound, and the first policy only affects traffic from SUBNETA (DROP) and the second policy only affects traffic from SUBNET B (RESET).  Then....
      • Traffic from SUBNETA is compared against policy1 in this example. It hits, traffic is DROPPED. This transaction is now stopped and no more responder policies are evaluated or any other feature on this transaction.  We dropped it. (Same if you make the action reset or redirect, just redirect responds and client is forced to connect to new location indicated by redirect).
      • If Traffic is from SUBNETB hits the vserver, then when it is compared with policy1, there is no match, so no action applies. Then the evaluation compares to Policy2, which in this case IS a MATCH and so Policy2's RESET is performed. And transaction is stopped.
      • If Traffic comes from SUBNETC which doesn't match any policy, then the traffic continues to vserver.
  • For policies to stop processing after first matching policy hit occurs, the GOTO expression is set to END when binding policies.  For some features, this behavior can be changed to "find all matching policies" such as in REWRITE.  For this, the GOTO expression is set to NEXT. However, because Responder policy actions stop the transactions, NEXT isn't allowed (unless using the NOOP action; which isn't needed here.).  So REsponder DROP/RESET/REDIRECT/Custom Response (import) are all "END" mode and stop after first hit; if no hit, the feature doesn't apply.

[3] So now, how resopnder works: While you could have two policies in our example, you don't need them.

Your requirements:

  • Traffic from SUBNET1 (whitelist) IS ALLOWED to be load balanced.
  • Traffic from anywhere else (not on whitelist) IS BLOCKED.

Example 1: single policy only drops when not in whitelist...

Traffic hitting the lb vserver will be allowed UNLESS a responder policy stops it. Technically, you only need one policy. 

The "!" is a NOT indicator.   For expression:  !client.ip.src.in_subnet("x.x.x.x/yy"),

  • any IP in Whiteilst subnet is TRUE on the in_subnet comparison, therefore the expression is !True == FALSE. Policy does not stop whitelist traffic.
  • any IP not in Whitelist subnet is FALSE on hte in_subnet comparison, therefore the expression !(in_subnet) is !(FALSE) == TRUE.  Responder policy will drop everyting NOT in whitelist.
  • If the policy hits, traffic is blocked (not in whitelist). Policy doesn't apply to any traffic in whitelist, and load balancing occurs.

add responder policy rs_pol_drop_nonwhitelist '!client.ip.src.in_subnet("x.x.x.x/yy")' DROP

bind lb vserver lb_vsrv_demo -policyName rs_pol_drop_nonwhitelist -priority 100 -goto END

 

Note: if you had multiple subnets the expression would be:  !(cient.ip.src.in_subnet("x.x.x.x/yy") || client.ip.src.in_subnet("a.a.a.a/bb") || ...)

 

Example 2:  Even if we had a allow on whitelist and block other behavior, even if two policies were bound. They would both bet setup with GoTo END so if either matched only one action applies.  The difference is for the 'allow' traffic you would use the NOOP; but its not recommended as NO RESPONDER POLICY means traffic continues normally per load balancing.

 

 

 

 

 

i have two policies since maximum length of 1499i is used

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