Jump to content

Responder for url change


Manoj Rana

Recommended Posts

Hi All

 

I am using a responder for changing old url to new url. This seems working but the only issue is when the user load the webpage it shows error below.

 

The hostname in the website’s security certificate differs from the website you are trying to visit. 
Error Code: DLG_FLAGS_SEC_CERT_CN_INVALID

 

I can understand for new url we are using different domain and ssl cert. 

Does anyone know how to fix this?

 

Thanks

Manoj

 


 

Link to comment
Share on other sites

If you use responder to REDIRECT user from old name to new name, then the user is making a new connection using the NEW FQDN. The cert bound on the vserver will then need to be a wildcard cert OR a multi san cert to allow both the original OLD and the NEW FQDN to be trusted.  Or bind multiple certs through the SNI option.  Cert must match the name used by the user to reach the vserver, so if using both old and new names on the same vserver, then both cert fqdn's must be trusted.

 

If instead you wanted the HOST change to only be between ADC and backend services, without the user seeing the name/fqdn change, you would be doing rewrite instead.

 

 

Link to comment
Share on other sites

So, it comes down to are you only changing this SERVER side, then it is a rewrite and we need some idea of the examples of what you want changed.

If users need to make a new connection to a new name, then it has to be done with responder.

 

(You keep saying redirect, so it implies responder is the answer.)

 

So is the NEW name on the lb vserver or CS vserver or is the new name only on the backend services, but then rewrite needs to rewrite FQDNs in urls returned in responses (which may make this a URL transform example.)

 

 

Link to comment
Share on other sites

Thanks again.

sorry for not providing clear information 

 

External OLD URL: https://gateway.example.co.uk

Internal OLD URL  https://gateway.example.co.uk

 

External/Internal New URL        https://access.company.co.uk

 

We have an old external URL https://gateway.example.co.uk now the client has changed to new url https://access.company.co.uk. The new URL has a completely different name and different SSL cert. What I would like to achieve I don't want to change the embedded URL which https://gateway.example.co.uk but I want Netscaler to route the traffic to new URL. 

 

 

As I said responder policy working but getting ssl error 

image.thumb.png.2fbb346f86d99bb60ec2b58e47fece2b.png

 

Please let me know if you need more info

Thanks  

 

 

 

 

Link to comment
Share on other sites

So, since this is the Gateway FQDN and your changing the URL the users need to use, REWRITE doesn't apply at all. (Unless I'm missing something)

Therefore it has to be done as a RESPONDER redirect from old name to NEW name and you will need a CERT issued to the new FQDN and the OLD FQDN to be trusted.

 

When you say you don't want to change the "embedded URL", what context are you referring to the URL in a workspace app config, the browser the users's use or the gateway fqdn you provide to storefront?  Because, all of those have to reflect the name the user uses to get to Gateway which is the NEW FQDN. Otherwise, I don't understand this request.  Rewrite won't solve this at all.  If you meant something else, please clarify.

 

Option 1:  May be OLD FQDN to different VIP, who's sole job is to listen to the old FQDN and redirect all requests to the New Gateway FQDN which maps to the vpn vserver vip. This will mostly only work for the external user requests in browsers; existing users using the workspace app, may need the actual NEW FQDN (test to see if the redirect works here or not).

 

Option 2:  Map old fqdn and new fqdn to the same vpn vip. Responder will redirect OLD names to NEW FQDN to correct legacy issues. You'll have to bind it to the aaa bind point so it runs before the authentication attempt.  But the vpn vserver will need either a multi san cert for old and new names so both names are trusted, or two separate certs bound with an sni binding.

 

Basic responder policy to redirect hostnames:

add responder action rs_act_sendtonewgw redirect '"https://access.company.co.uk" + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE'
add responder policy rs_pol_sendtonewgw 'http.req.header("host").set_text_mode(ignorecase).eq('gatweay.example.co.uk') rs_act_sendtonewgw
 

Example of binding to gateway AAA_request (which runs responder policies before authentication) if not using an authentication vserver.

bind vpn vserver -policy <policyname> -pri 100 -type aaa_request

 

If gateway is integrated with an authe vserver, you can bind it this way instead:

bind authentication vserver <vserver name> -policy <policyname> -pri <priority -type aaa_request

Link to comment
Share on other sites

Hi Rhonda,

 

Thanks again for your help.

 

Please see my comments in the red

 

So, since this is the Gateway FQDN and your changing the URL the users need to use, REWRITE doesn't apply at all. (Unless I'm missing something)

Therefore it has to be done as a RESPONDER redirect from old name to NEW name and you will need a CERT issued to the new FQDN and the OLD FQDN to be trusted.

This is a simple load balancer not the Citrix gateway service. I was thinking the same. The client does not want to use the old cert because he has to maintain 2 ssl cert they are trying to get rid of. So for the RESPONDER redirect is there any way can we use the new cert without trusting the old  FQDN cert?  The old cert doesn't exist on the NetScaler 

 

When you say you don't want to change the "embedded URL", what context are you referring to the URL in a workspace app config, the browser the users's use or the gateway fqdn you provide to storefront?  Because, all of those have to reflect the name the user uses to get to Gateway which is the NEW FQDN. Otherwise, I don't understand this request.  Rewrite won't solve this at all.  If you meant something else, please clarify.

We have some applications all across the country. They are static devices and old load balance URL inserted into the application? Most of the places don't have qualified IT staff and it will be a pain and cost lots  of money if the application Supplier needs to update the URL. I am thinking if something can be done from the NetScaler side to save all hassle. I am happy to open any idea on how to implement this. 

 

Option 1:  May be OLD FQDN to different VIP, who's sole job is to listen to the old FQDN and redirect all requests to the New Gateway FQDN which maps to the vpn vserver vip. This will mostly only work for the external user requests in browsers; existing users using the workspace app, may need the actual NEW FQDN (test to see if the redirect works here or not).

If I understand correct old OLD FQDN ssl needs to install and trusted on the NetScaler and bind to VIP. Is that correct?

 

Option 2:  Map old fqdn and new fqdn to the same vpn vip. Responder will redirect OLD names to NEW FQDN to correct legacy issues. You'll have to bind it to the aaa bind point so it runs before the authentication attempt.  But the vpn vserver will need either a multi san cert for old and new names so both names are trusted, or two separate certs bound with an sni binding.

 

Basic responder policy to redirect hostnames:

add responder action rs_act_sendtonewgw redirect '"https://access.company.co.uk" + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE'
add responder policy rs_pol_sendtonewgw 'http.req.header("host").set_text_mode(ignorecase).eq('gatweay.example.co.uk') rs_act_sendtonewgw
 

Example of binding to gateway AAA_request (which runs responder policies before authentication) if not using an authentication vserver.

bind vpn vserver -policy <policyname> -pri 100 -type aaa_request

 

I tried this and during the first load same error message came up . The old url remains the same time all the time. As expected SSL error came because of cert mismatch.  

16 hours ago, Rhonda Rowland1709152125 said:

t_sendtonewgw redirect '"https://access.company.co.uk" + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE'
add responder policy rs_pol_sendtonewgw 'http.req.header("hos

 

image.thumb.png.60a8c049593aca9ef2b7de3c8aad81fa.png

If gateway is integrated with an authe vserver, you can bind it this way instead:

bind authentication vserver <vserver name> -policy <policyname> -pri <priority -type aaa_request

 

 

Thanks again for your help on this.

 

Kind regards

Manoj

 

Link to comment
Share on other sites

You keep calling this a gateway but describe it as a lb vserver?  I'm very confused about that, but will assume LB from this point on.

 

Rewrites or URL Transform** will be needed to change all embedded URLs in responses to the Public NEW FQDN to match the expected client side/request requirements.

There are some examples of host changes in url transforms but they will take me a little while to get together.

 

You may still need a responder to change old requests to new fqdn and then URL Transform to make sure all embedded URLs in responses are rewritten to NEW FQDN.

However, if a user uses OLD FQDN to talk to a vserver with the NEW FQDN, it will always appear as untrusted to that user until they say connect anyway and then a responder policy can redirect them to NEW FQDN.  By definition a user will not trust a cert issued to a name different than the one they try to access. 

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