Jump to content
Welcome to our new Citrix community!

SSL LB VS Redirect From Port question

Recommended Posts



From what I understand, the Redirect From Port option allows you to redirect any traffic to the configured Load Balancing VS that is using the port specified in the Redirect From Port section. In most cases I presume it will be a port 80 (http) to port 443 (https) redirect. When configuring this option, the ADC will auto-populate the redirect URL to https://<LB IP Address>. My question is this. Does this redirect preserve the URI path when it redirects the clients browser? Example:


Client makes a request for http://my.domain.com/resource1

Redirect changes the path to https://<LB IP Address>


Will the /resource1 be preserved after the redirect? if so, should all we have to do is enter https://my.domain.com in the HTTPS Redirect URL section and the rest of the resource path will be preserved?


Thank you. 


Link to comment
Share on other sites

Yes, if you have no trailing path elements. Works same as protection methods redirect url>

If you redirect target is just https://<fqdn> existing path/query is tacked on.

If your redirect target is https://<fqdn>/<somepath>

or just trailiing "/":  https://<fqdn>/

then you replace original path/query with new path even if it is just "/" only.



The redirect from port (under basic settings), is only for lb vservers of type SSL to do the usual HTTP:80 to SSL:443 redirect

without needing a separate lb vserver on port 80 in a down state with the redirect url method or an UP vserver with a responder policy.

For anything more complex, use a separate vserver and a responder policy.






  • Like 2
Link to comment
Share on other sites

Thanks again Rhonda! Sounds like I can ditch the existing HTTP LB VS that has the responder policy on it. Unfortunately I don't have a different environment where I can test these kinds of things yet so I have to ask questions. I really appreciate you taking the time to help!

Link to comment
Share on other sites

Not a problem.  You won't be able to create the port 80 sidecar if the VIP:80 is still tied up elsewhere.

But the behavior is as you expect. leave the trailing slash off and you will preserver you original path and query on new redirect.

If you multiple conditional responder policies, then better to stick with the other vserver for it.  But you're good.

  • Like 1
Link to comment
Share on other sites

  • 2 years later...
  • 3 weeks later...

Sorry, haven't been on the forums and was delayed responding.


If you have a vserver on VIP1 ( then you can't create a separate vserver also using the same VIP:Port:


Same thing happens with the "sidecar".

You can create two vservers on the same VIP but different ports:

a) add lb vserver lb_vsrv_demo1 http 80 ...

b) add lb vserver lb_vsrv_demo2 ssl 443 ...


This is fine for the scenario (a) and (b) in the second example.

But if you go back to (b) lb_vsrv_demo2 and try to assign the sidecar for port 80, you are effectively trying to create a "hidden" listener (like a vserver) on the VIP:80 that is now in conflict with the existing HTTP:80 vserver (a) lb_vsrv_demo1.


c) set lb vserver lb_vsrv_demo2 -httpredirectport 80 -httpredirecturl ""

You will get the same message that a "vserver" already exists on that ip/port.  


Or the opposite problem, if you created the port 80 sidecar on lb_vsrV_demo2 first and you later tried to create a separate a) lb_vsrv_demo1 on the same vip and port 80, it would say 80 is already in use, and you would have to figure out where. Does that make more sense?


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