Jump to content
Welcome to our new Citrix community!

Rule Creation1 > FtoN

Sudhir Bhagat

Recommended Posts

Thanks Carl !


We had some clue that Content switching will involve here. But in second condition....i.e. When primary condition would not match with traffic then traffic should route to other  Service Group/ Virtual Server (Here in our case Insurance-RM-https)  is bit confusing. 

Link to comment
Share on other sites

The http to https will likely be a responder redirect from http to https in the URL.


The Responder policy with a REDIRECT action includes the necessary https://<fqdn> and any necessary path.  Usually the target redirect expression in the action is something like:

"https://hardcodefqdn" + http.req.url.path_and_query


"https://" + http.req.header("host") + http.req.url.path_and_query

You might need the policy bound to the http vserver with an expression of !http.req.url.path.starts_with("/insurance-rm")

Traffic with this path, will not match and will stay http.

Traffic with this path, will match expression and the responder policy with redirect to https://...


You would need an lb vserver OR cs vserver on HTTPS:<vip>:443 and one for your HTTP:<VIP>:80

If your decision is just between http destinations vs. https destinations, you wouldn't necessarily need content switching if there is only one set of services.

If you still have different services for different paths, then you would likely need content switching.


So, have a vserver (lb or cs, depending) for both client-side entry points HTTP vs. HTTPS.

Traffic that is correctly going to http://<fqdn>/<path> will be handled by the http vserver.

Traffic that needs to redirect to https://<fqdn>/<path> will be handled by the RESPONDER policy to redirect to new client-side vserver.

LB will distribute traffic to appropriate services for each lb vserver.

CS can sort traffic to different banks of lb vservers.



Link to comment
Share on other sites

Thanks Rhonda ! Hope You are doing Great !


Can we achieve this by Content Switching. Like that ....if any request coming for xy.com/insurance-rm  (match with /insurance-rm ) should direct to Service Group or Virtual Server name "Insurance-RM" .


And, If request is for some other path i.e.  xyy.com/<other then insurance-rm>   then traffic should be route to Service Group / Virtual Server name "Insurance-RM-https".



Link to comment
Share on other sites

I'm assuming that you still want the user to make a client-to-adc connection over HTTPS for some of this traffic while the rest is http, if so a redirect at some point will be needed.

If that means HTTP for some traffic and HTTPS for others (client-side), then you need two vservers (either cs or lb for the different protocols).


Next, If the traffic is going to the same bank of services, and you are just deciding whether to use HTTP or HTTPS, but same server destinations, then CS is fine.  IF there will be different destinations, you might need a little more complex set up.


So, before I mock this up, let's confirm If I understand what you are trying to do:


###Basics I think:

# You're basic premis if URL starts with /insurance-rm send to the HTTP bank; otherwise send everything else to HTTPS.

# "/insurance-rm" --> to HTTP

# everythign else to HTTPS...but again, if users are on HTTP, you have to redirect to HTTPS (because frontend HTTP to backend HTTPS doesn't really make sense)

# If you weren't crossing protocols, this is easy, so this will be close but if clarify the traffic flow there may be a better way to do this.


>>If I've misunderstood, then none of this applies, of course.  <<

# What you really have are two scenarios:

# 1) For client http://<fqdn>/ requests, 

#     1a) if http://<fqdn>/insurance-rm, continue to keep this on HTTP backend

#     1b) else http://<fqdn>/<everythingelse> redirect to https://<fqdn>/<everythingelse>    --> this is a redirect to a different cs vserver.

# 2) For client requests going to https://<fqdn>/ (whether client originated or coming from the other redirect, so we don't want a redirect loop)

#    2a) if https://<fqdn>/insurance-rm, we can still send this to HTTP backend while keeping the user on HTTPS frontend (or we can redirect them to the HTTP entry).

#    2b) else https://<fqdn>/<everythingelse>, send to the https backend.... (while staying on this https vserver)


This means you will need services and lb vservers for the HTTP flow and the HTTPS flow. Whether we use content switching or LB, you will need both an HTTP entry point and an HTTPS entrypoint and you will need responder policies to redirect HTTP to HTTPS for the affected flows.









Link to comment
Share on other sites

Hi Rhonda, 


Let me explain the requirement again..


If any request coming for xy.com/insurance-rm  (match with /insurance-rm ) should direct to Service Group or Virtual Server name "Insurance-RM" .


And, If request is for some other path i.e.  xyy.com/<other then insurance-rm>   then traffic should be route to Service Group or Virtual Server name "Insurance-RM1".


Probably confusion was related to https word in Service Group. I changed it to Insurance-RM1 simply ? .






Link to comment
Share on other sites

Yes, if no protocol change this is a simple content switch if policy expression 1 to the one service group and the default group will match for anything else.

Carl's answer is correct and if you need an example, its fairly straightforward.  (Sorry for making it more complicated than it appeared.)


# Create destination services/lb vservers ; you can easily make everything http 80 or ssl 443 below..

add service svc_demo1 <ip1> http 80 

add service svc_demo2 <ip2> http 80

add lb vserver lb_vs_insurancestuff http   ## non-addressable vserver behind cs vserver; doesn't require vip or port

bind lb vserver lb_vs_insurancestuff svc_demo1

add lb vserver lb_vs_otherstuff http

bind lb vserver lb_vs_otherstuff svc_demo2


# Create cs vserver policy to direct traffic to necessary lb tier

add cs action cs_act_toinsurancestuff -targetlbvserver lb_vs_insurancestuff

add cs policy cs_pol_toinsurancestuff -rule 'http.req.url.path.set_text_mode(ignorecase).starts_with("/insurance-rm")' -action cs_act_toinsurancestuff


# Create cs vserver with policy and default destination for non-matched traffic...

add cs vserver cs_vsrv_demo HTTP <VIP1> 80

bind cs vserver cs_vsrv_demo -policy cs_pol_toinsurancestuff -priority 100

bind cs vserver cs_vsrv_demo -lbvserver lb_vs_otherstuff



When you create a cs vserver (either in gui or via cli), the -lbvserver <destination> without a policy criteria is a default destination and it will match last for any traffic not handled by the bound policies. In this case your first policy is higher priority and any traffic with the /insurance-rm path will go to the lb_vs_insurancestuff based on the cs_pol listed.  All other traffic will be caught by the default destination. Though additional policies can be created if necessary.


The example destination lb vservers have a single service, but they can easily account for multiples with usual lb methods and persistence as needed.  Can easily be flipped to SSL.


Link to comment
Share on other sites

  • 2 weeks later...

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