Jump to content
Welcome to our new Citrix community!

Responder redirect not working


Manoj Rana

Recommended Posts

Hi All,

 

I am trying to redirect users based on source ip. 

 

I tried with VIP 443 bind 2 responder pol.

 

add responder action Site1 redirect "\"https://www.site1.com\"" -responseStatusCode 301

add responder action Site2 redirect "\"https://www.site2.com\"" -responseStatusCode 301

 

add responder policy sendtoSite1  client.ip.source.in_subnet(192.168.0.0/24) Site1

add responder policy sendtoSite2  client.ip.source.in_subnet(10.10.0.0/24)' Site2

 

bind lb vserver lb_rd_443 -policyName Site1 -priority 100

bind lb vserver lb_rd_443 -policyName Site2 -priority 110

 

But this is not working 

can you please help?

thanks

 

Link to comment
Share on other sites

 

10 minutes ago, Carl Stalhood1709151912 said:

Is traffic reaching that LB vserver?

 

Is the client software a web browser that can do the redirect?

Hi Carl,

 

I am not seeing any hits to VIP.

 

I want to share some info current my VIP is down because no Services and Service Groups bind. If i bind Services and Service Groups i can see hits and it is service connection to bind Services and Service Groups. but not checking Responder policy and VIP is available form both IP's subnet.

 

Thanks

Manoj

 

Link to comment
Share on other sites

6 minutes ago, Carl Stalhood1709151912 said:

Responder won't work unless the vServer is UP.

 

Thanks Carl.

 

I tried with  bind the up service and it only redirecting to the service page application. not to responder pol URL like www.site1.com & www.site2.com

 

This is not looking my responder pol. 

 

Thanks

Manoj

Link to comment
Share on other sites

5 hours ago, Manoj Rana said:

I tried with VIP 443 bind 2 responder pol.

 

add responder action Site1 redirect "\"https://www.site1.com\"" -responseStatusCode 301

add responder action Site2 redirect "\"https://www.site2.com\"" -responseStatusCode 301

 

add responder policy sendtoSite1  client.ip.source.in_subnet(192.168.0.0/24) Site1

add responder policy sendtoSite2  client.ip.source.in_subnet(10.10.0.0/24)' Site2

 

bind lb vserver lb_rd_443 -policyName Site1 -priority 100

bind lb vserver lb_rd_443 -policyName Site2 -priority 110

 

 

Manoj,

So, your vserver that you have your policies bound to is also on 443?  are you redirecting from one https://<fqdn> to another and the new fqdns will direct to new vips?

Just to make sure you are not creating a redirect loop.  Do the new FQDNs resolve to new VIP destinations or same VIP but different fqdn?

 

And are you trying to preserve any of the original path or just need a one time redirect to a new fqdn/vip?

 

Finally, is the client's source IP visible to the adc or is there a vpn or proxy involved interfering with the source IP being seen?

 

 

 

 

 

Link to comment
Share on other sites

2 minutes ago, Rhonda Rowland1709152125 said:

 

Manoj,

So, your vserver that you have your policies bound to is also on 443?  are you redirecting from one https://<fqdn> to another and the new fqdns will direct to new vips?

Just to make sure you are not creating a redirect loop.  Do the new FQDNs resolve to new VIP destinations or same VIP but different fqdn?

 

And are you trying to preserve any of the original path or just need a one time redirect to a new fqdn/vip?

 

Finally, is the client's source IP visible to the adc or is there a vpn or proxy involved interfering with the source IP being seen?

 

 

 

 

 

Hi Rhonda,

 

Yes vserver is also on 443.

Yes I am trying to redirect user from https://<fqdn> to another and the new https://fqdns.

We have two storefront server and i want redirect site1 user to storefront 1 and site2 user to  storefront 2.

 

Both site have common URL but i want netscler to redirect to site 1 or site2 based on IP.

I am not preserving any part of the URL.

 

On the services group i enabled the Insert Client IP Header im not sure do i need to do anything else.

 

Thanks again.

 

Manoj

 

 

 

 

Link to comment
Share on other sites

Are users hitting the original storefront load balancer directly and then being redirected to their new storefront location OR are they external users connecting through gateway and then you are redirecting them?

Once we clarify this, we can probably fix your scenario.

 

If the former, then this should work unless there is a proxy in which case we need the proxy to insert the x-forwarded-for client ip header and then we can load balance.  The service doing client ip header insertion is "after the fact" the device between the users and the storefront lb vserver should be doing the client ip header insertion. And then instead of source ip your policies should be based on the header insertion instead.

 

If the latter, and the user is being directed to different storefront servers after hitting the gatway, then you should NOT be doing a redirect for that and instead different session policies should be assigned and direct users to storefront1 or storefront2 based on their source IP which the gateway can see.

Gatway has to know which storefront to hit and should use the session policies to direct users to different storefronts; a responder policy redirect will not work for this scenario. IT will work for users who hit storefront directly.

 

 

Link to comment
Share on other sites

16 hours ago, Rhonda Rowland1709152125 said:

Are users hitting the original storefront load balancer directly and then being redirected to their new storefront location OR are they external users connecting through gateway and then you are redirecting them?

Once we clarify this, we can probably fix your scenario.

 

If the former, then this should work unless there is a proxy in which case we need the proxy to insert the x-forwarded-for client ip header and then we can load balance.  The service doing client ip header insertion is "after the fact" the device between the users and the storefront lb vserver should be doing the client ip header insertion. And then instead of source ip your policies should be based on the header insertion instead.

 

If the latter, and the user is being directed to different storefront servers after hitting the gatway, then you should NOT be doing a redirect for that and instead different session policies should be assigned and direct users to storefront1 or storefront2 based on their source IP which the gateway can see.

Gatway has to know which storefront to hit and should use the session policies to direct users to different storefronts; a responder policy redirect will not work for this scenario. IT will work for users who hit storefront directly.

 

 


Hi Rhonda,

 

There is no issue when user directly trying to hit the  storefront load balancer from both sites. All of my users are internal. We are not using gateway for this. just Internal storefront URL.

 

We have no proxy in between. I tried George config to check the IP and I can see the correct client IP.
https://www.jgspiers.com/insert-client-ips-into-storefront-logon-page/

 

I am not sure if we can use rewrite for this.

Thanks in advance.

Manoj

 

Link to comment
Share on other sites

I would use a header viewer utility to see what happens during the user requests to see if the responder policy is or isn't hitting.  And if there  are multiple requests not being redirected.

 

But my guess is that when you redirect your users from STorefront fqdn1 to storefront fqdn2 or fqdn3 you are missing the necessary store path (as probably a default path is not set).

Since you are redirecting your users to https://storefront2.demo.com/ and not https://storefront2.demo.com/Citrix/<StoreNameWeb> is why you are seeing the default IIS service page and not a store to continue the traffic flow.

 

Find out what your store names are on the target storefront servers and make sure you know the web url name for each store which is usually /Citrix/<StoreName>Web and change the responder redirect to the exact store name path you need in the redirect.

 

Then go back to testing with your source ips. You can also add an audit log message to the policy to log the policy hit base don client subnet.

 

Otherwise you can switch the policy test to something other than IP for testing purposes and then we can figure out why the ip is not being seen as expected.

Link to comment
Share on other sites

  • 1 month later...

For some reason widely open sub net not working i have to do like this CLIENT.IP.SRC.IN_SUBNET(192.168.0.0/24)

 

add responder policy sendtoSite1  CLIENT.IP.SRC.IN_SUBNET(192.168.0.0/24) Site1

 

It is working after this. Not sure if any issue with firmware. We are on NS 13.0.67.39

 

Thanks anyway for your help.

Manoj

 

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