Follow-up on my journey to pivot from on-prem Gate...
# citrix-cloud
j
Follow-up on my journey to pivot from on-prem Gateway to GW Service. Last week I thought just doing a DNS repoint from on-prem GW jonsgateway.jonsdomain.com to CNAME of GW service would work... but thought of all the users that only know how to get to our NS via a bookmark that likely have a bookmark post auth..ie /logon/LogonPoint/index.html. Considering all my users on this specific NS Gateway are accessing via Browser and not CWA, would the better approach be a communications/E-mail + 302 to GW service?
j
Why not doing the redirect on the on-prems gateway directly? so you catch all the bookmarks.
👍 1
j
Yeah sorry if I dropped the ball on the 2nd part. Just doing a redirect at the old gateway, to the new one I think is the solution. That'll work for all users that either use bookmarks or type in old jonsgateway.jonsdomain.com. Then help desk can write up docs for CWA to new custom domain.
j
Yes it sounds good!
j
I usually will make a static landing page that states the resource has been moved and then provide details on going to the new site and creating a new bookmark. Because you know users are going to keep using that old bookmark, and when you retire the redirect in the future they will call and complain.
j
Static page was my pitch...but got pushback "we want to make it as easy as possible". My pitch was internal comms re: upcoming change, "new app" campaign by training team w/ 1 sheets, then static page on "cut" day.
c
302 Responder redirects work well the only problem i had with a responder 302 redirect in past is you got to have the old/new name as a SAN in the certificate bound to the new GW VS for the new URL 🙂 This is because the user types in remote.corp.com and gets redirected to newremote.corp.com so the cert doesnt match and the user gets a certificate Common name mismatch error
j
Sounds like I should do a metarefresh vs a 302
j
One GW is on-prems and other Cloud so no need of SAN here or do I miss something?
j
Correct, NSGW is on prem, other is Cloud.
c
You would still get the cert common name mismatch issue tho ? user types in onpremgw.gateway.corp and then gets a 302 redirect to cloudgw.clould.com the cloud GW's cert wouldnt have the old name in its SAN
i will test it on my lab netscaler later and let you know
j
It's a redirect, new SSL handshake on the Cloud URL. I've done load of 302, I never needed a SAN.
c
swear i used to get SSL cert errors when doing 302's without adding the old name to a SAN on the new cert 😂😂 i just tested a 302 redirect in my lab from my NS GW to my citrix workspace service url and it worked fine with no SSL errors so i must be going mad 😂 https://www.jasonsamuel.com/2011/03/07/how-to-properly-use-ssl-redirects-without-getting-certificate-error-messages/
ahh i think the use case i had when i got the cert error's was the old url fqdn / new url fqdn would both point to a single NS GW VIP with a responder policy bound that did the 302 redirect from old URL to new URL hence the cert error and me adding the old name into the SAN on the new cert
the 302 redirect from my lab NS to GW service works perfectly
j
thanks for taking care of all my pre- legwork John!
j
Yes it makes sense if you had the 2 FQDN on the same VIP :)
👍 1