Jump to content
Welcome to our new Citrix community!

Content Switch to LB VIP with URL Modification


Joseph Schulte

Recommended Posts

What I am trying to accomplish here shouldn't really be all that difficult, but I can't seem to find the magic combination to make it work. I have an ADC setup in my DMZ that is internet accessible. 

 

What is currently functional is this:

 

https://nonprd.myplace.org is my primary CS VIP. That CS VIP is supposed to trigger off of the URL path, and various paths lead all lead to the same non-addressable LB VIP. The back end servers on that LB VIP then process the request and do what needs to be done. 

 

What I am trying to do is this:

 

Add some more actions and policies to the CS VIP that go to a different non-addressable LB VIP from the above. However, I am also trying to perform a URL conversion, so that https://nonprd.myplace.org/mc-poc ends up being rewritten so that the  URL retrieved from the back end would be https://backendserver/MC-PROOF-OF-CONCEPT.  

 

The idea is that the client will be communicating with the CS VIP on the ADC, and the ADC will be communicating with the back end servers. But, the back end servers are listening on a different URL path than the CS VIP. 

 

I've tried rewrite policies, and I've tried response policies, and none of them seem to be able to accomplish this successfully. I HAVE been able to successfully rewrite so that https://nonprd.myplace.org/mc-poc is rewritten to https://nonprd.myplace.org/MC-PROOF-OF-CONCEPT, but that URL doesn't actually work. I assume it's because that rewritten URL doesn't actually exist on the CS VIP. It exists in the LB VIP, and the LB VIP isn't reached by that rewritten URL. 

 

So...I'm kind of stuck and could use some advice on how to accomplish this because I seem to just be going in circles here. 

Link to comment
Share on other sites

1) The policies on your CS vserver should "sort" traffic to the appropriate destination LB vserver, based on the original client side path (and not the soon to be rewritten one).  CS is processed first.

 

2) Then create your rewrite policy to apply at the LB vserver level and rewrite the path from the "client" side URL to the actua/"server" side URL.  Usually you can omit rewriting the host header unless there is a dependency.

 

But to help you troubleshoot more, you might need a couple of examples of what you are trying to do and then some details of the policies you have tried to untangle what might be going wrong.

Link to comment
Share on other sites

1. OK, been doing that the whole time, and that seems to be going as expected. 

 

2. You've suggested the most basic setup, and I'm pretty sure that's where I started. So I went and recreated it and I'm still getting a http/1.1 Service Unavailable. 
 

When I was writing the original post, I ended up being a bit loose with my paths and such. What we are looking for is:

 

Front end: https://nonprd.myorganization.com/mc-poc

Back end servers are expecting the URL path to be /MyChartPOC

 

Here's the CS, which I'm fairly certain is working:

 

add cs vserver DMZCSEPCAPP500-443-CS SSL 10.99.94.79 443 -cltTimeout 180
bind cs vserver DMZCSEPCAPP500-443-CS -policyName CS-Policy-FHIR -priority 100
bind cs vserver DMZCSEPCAPP500-443-CS -policyName CS-Policy-ACR -priority 110
bind cs vserver DMZCSEPCAPP500-443-CS -policyName CS-Policy-VirtualCare -priority 120
bind cs vserver DMZCSEPCAPP500-443-CS -policyName CS-Policy-Payment -priority 130
bind cs vserver DMZCSEPCAPP500-443-CS -policyName CS-Policy-Surescripts -priority 140
bind cs vserver DMZCSEPCAPP500-443-CS -policyName CS-Policy-Haiku -priority 150
bind cs vserver DMZCSEPCAPP500-443-CS -policyName CS-Policy-MC-POC2 -priority 170
 

add cs policy CS-Policy-MC-POC2 -rule "HTTP.REQ.URL.TO_LOWER.CONTAINS(\"/mc-poc\")" -action CS-Action-MC-POC
add cs action CS-Action-MC-POC -targetLBVserver REDIRECTEST-443
 

And then looking at the LB VIP:

 

add lb vserver REDIRECTEST-443 SSL 0.0.0.0 0 -persistenceType NONE -cltTimeout 180
add rewrite action MYCHART-POC-REWRITE-ACTION replace "HTTP.REQ.URL.PATH.GET(1)" "\"/MyChartPOC\""
add rewrite policy MYCHART-POC-REWRITE-POLICY "HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).STARTSWITH(\"/mc-poc\")" MYCHART-POC-REWRITE-ACTION
bind lb vserver REDIRECTEST-443 -policyName MYCHART-POC-REWRITE-POLICY -priority 100 -gotoPriorityExpression END -type REQUEST
 

 

I didn't include everything, but I think I included everything necessary. 

 

Let me know if you see anything wrong, please! 

Link to comment
Share on other sites

anytime you get service unavailable, it means there is not destination for the traffic usually at the CS vserver level.

 

You need a default destination for your CS vserver for any traffic that doesn't match any of the specified policies.

 

My guess is you have requests that aren't in one of your existing categories that is failing.  Use a trace or a browser developer tool that can let you see all requests per object being made.  OR set a default destination with some policies bound that can help you log which requests are hitting the default vserver.

Link to comment
Share on other sites

1) I would add a default destination on CS vserver, for traffic that falls into a none-of-the-above category, just in case.

(Skip this initially, but if you still have issues, give it a try.)

 

2) your rewrite action is a little incorrect:

add rewrite action MYCHART-POC-REWRITE-ACTION replace "HTTP.REQ.URL.PATH.GET(1)" "\"/MyChartPOC\""

 

If you give it sample url:

http://demo.domain.com/mc-poc/

Then, http.req.url.path.get(1) matches this:

mc-poc

 

But you are replacing it with a phrase that includes "/MyChartPOC"

So you're before REWRITE:

http://demo.domain.com/mc-poc/<stuff>

Becomes:

http://demo.domain.com//MyCharPOC/<stuff>

with an extra included "/"

 

Try changing your rewrite action to:  

add rewrite action MYCHART-POC-REWRITE-ACTION replace "HTTP.REQ.URL.PATH.GET(1)" "\"MyChartPOC\""

 

3) If you need multiple rewrites, you may need to change your policy binding from GoTo END to GoTo NEXT. But I think the "/" in the previous step is a bigger issue.

Link to comment
Share on other sites

Alright, so I went ahead and tried modifying the rewrite policy, but I got the exact same output. So then I reverted it.

 

I'm not sure whether or not I'm supposed to be able to see the double-// on the rewritten URL in a browser when I do hit that rewrite, but I don't, if that tells you anything useful.

 

As a test I went ahead and changed my default vserver on the CS VIP to point to the REDIRECTEST-443. And it works. If I throw garbage into there, I still get sent to that vserver, it's just a 404.

 

And then I try it with /mc-poc, and it rewrites to /MyChartPOC, and it works correctly. 

 

I've gone through and double-checked everything, and the ONLY difference right now, with it working correctly, and what it was at the beginning of this process is adding the one particular LB VIP as a failthrough at the end of my CS VIP policies. So, naturally, Further investigation shows me that I'm now not hitting the /mc-poc CS policy, but am instead hitting the failthrough policy at the end.

 

Since I am most definitely putting a /mc-poc at the end of my URL, I am really not comprehending how this line is not hitting:

 

add cs policy CS-Policy-MC-POC -rule "HTTP.REQ.URL.TO_LOWER.CONTAINS(\"/mc-poc\")" -action CS-Action-MC-POC
 

 

Link to comment
Share on other sites

...and even better, I did some messing around, thinking that maybe the "-" in the URL was a problem, and maybe I needed to just change it to /mcpoc or something.

 

And it worked.

 

Then I went ahead and changed it back to /mc-poc, to see if the "-" was the problem.

 

And it worked.

 

Check the CLI and I see: add cs policy CS-Policy-MC-POC -rule "HTTP.REQ.URL.TO_LOWER.CONTAINS(\"/mc-poc\")" -action CS-Action-MC-POC

 

Which I've checked, and it is identical to what was already there.

 

To cap things off, I go ahead and remove the failthrough, just in case.

 

And it works.

 

So as near as I can tell, everything is back to the way it was when I started, but now everything works.

 

From an outside perspective (my browser) what I would see when it didn't work was:

 

Typed in: https://www.myorg.com/mc-poc

Browser showed after hitting enter: https://www.myorg.com/MyChartPOC

 

But now, after going around the world and landing in the same spot, I get:

 

Typed in: https://www.myorg.com/mc-poc

Browser showed after hitting enter: https://www.myorg.com/mc-poc

 

And now, about 10 minutes later, after attending to another issue, I'm back to the failure state:

 

 

Typed in: https://www.myorg.com/mc-poc

Browser showed after hitting enter: https://www.myorg.com/MyChartPOC

 

So, back to baffled.


 

Link to comment
Share on other sites

1) When you use a rewrite to change the URL (instead of responder), then the URL change happens from NS to Server and is not reflected client side.  

So in the initial request you will still see /mc-poc/<stuff> but the server is seeing the request for /MyChartPOC/<stuff>.

 

Now, if responses from the server include links that use the new URL /MyChartPOC, then this will result in the browser changing client-side for the next object you are requesting.

 

2) The fact that this goes from working to not, probably means you have a mixture of content and not all of it contains /MyChartPOC or it includes references to other objects that have incorrect paths. So some of your requests are working and some of them aren't.

 

This might mean you need some response time policies too to rewrite relative paths OR not all of your paths are what you think, so your request time rewrites are still missing content.

You really should keep the default destination in place and see how many times it is being hit to help gauge how much it is being used.  If its increasing, then it is being hit.

 

You will then need some sort of browser inspection tool that can let you see per request which path is int use and whether you are getting a 200 Ok or 301/302 or 403/404 or other error. Now, you can see which paths are and aren't working per object. As you probably still have some unhandled content or unexpected paths.

 

Browser or other caching:

Make sure your browser isn't giving you cached content. And if caching is enabled on your NS, you may need to disable or flush cache as you work on these rewrite rules.

You might need additional rewrites. Or you lb vserver/persistence isn't correct.

 

 

Finally, the mc-poc might be html encoded in some instances, so you are only hitting the query part of the time; or the hyphen/en-dash might actually be an em-dash or some other character.  Maybe some of your user URLs aren't using an en-dash but an em-dash,

 

Maybe change your cs policy trigger for the rewrite to any of these variations instead of using the To_Lower function:

http.req.url.path.set_text_mode(ignorecase).contains("/mc-poc")

http.req.url.path.get(1).set_text_mode(ignorecase).eq("mc-poc")

 

Reviewing the policy hits and the list of paths where the policy applies and where it doesn't is the only way to really see what is happening.  

A trace could help. NSWL web transaction logs might help, but a browser tool see your client-side requests and responses is still the best place to start.

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...