Jump to content
Welcome to our new Citrix community!

Binding Policy to a VIP with no services


Recommended Posts

I've been watching a video on responders and rewrite policies within App Expert.  But what I'm not getting

is how do I draw the initial traffic to the load balancer. Would I create a LB VIP with no services - and then,

although the VIP is down, the policies associated with that VIP do the redirection specified in the policies?

 

The issue is I get requests to rewrite URL requests for our company's domain to those of partners or

vendors. I could create a VIP in a down state and add a redirect URL. That works and I use that mostly

for the http to https redirection for whatever I'm balancing. But for these redirects to whole other

domains I don't want to burn an address every time someone asks for it.

 

Example: Client requests http://gold.nugget.info or https://gold.nugget.info - either of these 

redirect to https://gold.mountain.info. 

 

So the first thing is - would I add a LB Virtual Server to the Netscaler but with no service and add polices to the Virtual 

Server? How do I get the Netscaler to responsd at the IP?

 

Then what method would be best such that multiple redirects can all be run from the same IP address?

 

Say that gold.nugget.info is 10.5.5.100 and sliver.nugget.info is also at 10.5.5.100

 

http://gold.nugget.info or https://gold.nugget.info - either of these redirect to https://gold.mountain.info. 

http://silver.nugget.info or https://silver.nugget.info - either of these redirect to https://silver.mountain.info. 

 

Thank you.

 

Link to comment
Share on other sites

In brief, some basics:

First:

Traffic arrives at an lb vserver (or cs vserver) because the request goes to a specific IP:PORT (and protocol) combination.

For policy processing the lb vserver has to be UP, but there are ways to make it UP with fake services for purposes of allowing it to be a listener on one IP:PORT in order to redirect to another.

The redirect url that you are using under protection methods is only in effect when the vserver is DOWN and it doesn't have the ability to do more complicated/nuanced scenarios.

 

 

Second:

Now in your example of FQDN1 (gold.nugget.info) redirecting to FQDN2 (gold.mountain.info).

There are two potential scenarios (big picture).

Scenario 1: Traffic goes to FQDN1 (VIP1) and you want to redirect to another FQDN2/VIP2.  So, old vserver is needed to get traffic to new one.  

Scenario 2: Or FQDN1 needs to be redirected to FQDN2, but they are both on the same VIP.  This is also possible, but the policy will have to take into account the HOST Name (FQDN) in use.  You have one vserver with two possible names.

 

Third:

You say rewrite and redirect. I'm assuming you mean redirect (aka responder policies). 

A redirect (responder policy) is used when a client makes a request to X and you want the ADC to respond with a redirect to a new location and the client will then make a new request to the new destination. Client sees the change.

A rewrite is used when the client makes a request to X on the vserver (client-to-vserver/client side) and the ADC rewrites the request from the ADC-to-server and asks the server for Y.  Client is not aware of the request change. But the ADC fetches something different from the backend.  Usually not used for FQDN changes, but maybe path modifications.

 

Solution for Scenario 1:   Redirect from FQDN1/VIP1 to alternate FQDN2 (whether a VIP2 on this system or elsewhere)

#  1 -  Configure an LB vserver for the FQDN1 VIP:PORT 

#     -  Remember, DNS gets FQDN1 to the vserver. If multiples will be redirected, you can map multiple FQDNs to the same VIP and policies can trigger based on hostname in the request.  

# Create a dummy service that is always UP; policies do not apply to DOWN vservers.; Use any non-existent IP for this.

add service svc_alwaysup 1.2.3.4 http 80 -healthmon disabled

 

# Create the lb vserver with the destinations (services) on the VIP:PORT that you expect the request to come in on. You can listen for both HTTP and HTTPS if you need to redirect both

add lb vserver lb_vsrv_oldfqdns HTTP <VIP1> 80

bind lb vserver lb_vsrv_oldfqdns svc_alwaysup

add lb vserver lb_vsrv_oldfqdns_ssl SSL <VIP1> 443

bind lb vserver lb_vsrv_oldfqdns svc_alwaysup

bind ssl vserver lb_vsrv_oldfqdns -certkey <certkey name>  # if multiple fqdns, a wildcard cert might be needed or a multisan cert for trust...

 

# 2 - Create the necessary responder polic(ies) to redirect a given FQDN to the new destination...

#     - OLD FQDNs:  gold.nugget.info, silver.nugget.info  redirect to gold.mountain.info / silver.mountain.info

#     -  You just need to decide if gold/silver nuggets will be on a single VIP or separate VIPS....

#     - Gold.mountain.info (FQDN2) can then be on a different VIP/IP elsewhere...wherever the name redirects to.

add responder action rs_act_sendto_goldmountain_https REDIRECT '"https://gold.mountain.info" + http.req.url.path_and_query.http_url_safe

add responder policy rs_pol_sendto_goldmountain_https 'http.req.header("host").set_text_mode(ignorecase).eq("gold.nugget.info")'

 

add responder action rs_act_sendto_silvermountain_https REDIRECT '"https://silver.mountain.info" + http.req.url.path_and_query.http_url_safe

add responder policy rs_pol_sendto_silvermountain_https 'http.req.header("host").set_text_mode(ignorecase).eq("silver.nugget.info")'

 

#     -  Bind policy to either the HTTP or HTTPS vservers to redirect

bind lb vserver lb_vsrv_oldfqdns -policyName rs_pol_sendtogoldmountain_https

bind lb vserver lb_vsrv_oldfqdns_ssl -policyName rs_pol_sendtogoldmountain_https

 

# 2b - If you will also have requests to silver.nugget go to the same placeholder vip <VIP1>, then you can bind those here to. Or they can have their own entrypoint/vserver...

bind lb vserver lb_vsrv_oldfqdns -policyName rs_pol_sendtosilvermountain_https

bind lb vserver lb_vsrv_oldfqdns_ssl -policyName rs_pol_sendtosilvermountain_https

 

 

This should at least help you get in the ballpark or you can ask more questions for your scenario.

 

 

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

I got the always-up service running and the vServer listening at 443 is up as well. 

I went to App Expert/Responder and added a Responder Action and Responder so that it would listen for https://gold.nugget.info and redirect to https://gold.mountain.info. Then I was able to bind it to the service. I added the certificate to the vServer *.nugget.info. But when I went to test it out

I got a 400 Bad Request after that warning screen that chrome gives you when unhappy. Getting closer it seems.

 

We have the certificate for *.nugget.info. But *.mountain.info would be owned by another company. Redirecting back out of the enterprise is perhaps the trick.

Link to comment
Share on other sites

Can you share your responder policy that you are using to spot the problem (I was freehanding above and may have created a typo that was unexpected).

Redirecting to another domain is straightforward as long as the dns resolves.

 

The redirect needs to be on the http:// vserver for the old fqdn (for http to https redirects) and the https:// vserver for the old fqdn to https:// on new.  The cert for the new destination is than handled on the new vserver (which would be not yours).

Be sure the vserver is UP.

 

Updated note because I left a few details out.

When you got the 400 was it on the http://<old fqdn> or the https://<old fqdn> test?  

 

 

 

 

Link to comment
Share on other sites

Fixed some typos in the command line.  The policies I gave you preserves any original path and query in the original request and redirects this to the new destination, so if the path his not valid on the new fqdn you would possibly get a 404 issue as well.  

 

The following demo worked for me in my test environment with some dns resolutions.

I have http on http://gold.nugget.info<stuff> (my vip1) redirecting to https://gold.mountain.info<stuff>

I also have https://gold.nugget.info<stuff> going to https://gold.mountain.info<stuff>

The path and query will tack on the "/" and path elements if present.

 

In case this example helps you spot the issue.

Also, view your responder policy response in a header viewer like the browser's web developer tools to see if there is an issue with the redirect destination being created.

And we can tweak from there:

 

Apologies for typos in original example.

 

### LB VSERVERS (lb_vsrv_demo1 is for OLD fqdn)

add lb vserver lb_vsrv_demo1 HTTP <VIP1> 80
add lb vserver lb_vsrv_demo1_ssl SSL <VIP1> 443
bind lb vserver lb_vsrv_demo1 svc_alwaysup
bind lb vserver lb_vsrv_demo1_ssl svc_alwaysup
bind ssl vserver lb_vsrv_demo1_ssl -certkeyName colors.workspacelab.com
 

# NEW destination will be handled by the DNS resolution of the NEW FQDN to the new VIP2 and whoever hosts it...

add responder action rs_act_sendto_goldmountain_https redirect "\"https://gold.mountain.info\" + http.req.url.path_and_query.http_url_safe"
add responder policy rs_pol_sendto_goldmountain_https "http.req.header(\"host\").set_text_mode(ignorecase).eq(\"gold.nugget.info\")" rs_act_sendto_goldmountain_https
bind lb vserver lb_vsrv_demo1 -policyName rs_pol_sendto_goldmountain_https -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver lb_vsrv_demo1_ssl -policyName rs_pol_sendto_goldmountain_https -priority 100 -gotoPriorityExpression END -type REQUEST
 

# Examples:

http://gold.nugget.info  redirects to https://gold.moutain.info

http://gold.nugget.info/dir/subdir/page1.cgi?a1=b1 redirects to https://gold.moutain.info/dir/subdir/page1.cgi?a1=b1

https://gold.nugget.info/ redirects to https://gold.mountain.info/

etc...

 

See if this helps any.

 

 

  • Like 2
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...