Yes, more NetScaler….please remember that this blog serves as a memory dump and repository for myself. Things which I believe I may forget soon are placed here so that when I do forget them, I can come back here and find them…assuming I’ve placed them here before I have indeed forgotten them. I had almost forgotten this issue until I saw a screenshot that reminded me of it and I’ve got to put it down quick.
We were implementing a NetScaler for several reasons, one of which was to replace the old (and dying) computer which hosted the Citrix Secure Gateway. There are two methods of completing this switch:
This method (the method Citrix prefers/recommends) you build the NetScaler alongside the Secure Gateway but assign it a new FQDN, obtain a new SSL certificate with that name, and then direct users to the new FQDN once testing is complete. This method makes it easy to test the NetScaler without hosts file manipulation and since it will have a new IP and new name, you can add those into DNS at the beginning of the project and by the time you are ready to switchover, the DNS replication has taken place. You can maintain both devices for a time and then easily decommission the Secure Gateway with no service interruption.
Using this method, the NetScaler replaces the Secure Gateway using the same certificate, same name, and same IP. When performing an in-place migration, the NetScaler is assigned a “test” IP and an existing certificate is imported on the NetScaler and used for the Access Gateway virtual server. This method requires that testing be performed using the externally accessible test IP, which will result in a certificate error, or by manipulating name resolution using a HOSTS file. When testing is completed and the NetScaler is ready to be placed in production, there is downtime as the Secure Gateway must be powered off or its network cable unplugged so that the test IP can be changed to the production IP and any HOSTS files which have been changed must be changed back. Additional troubleshooting may be required unless testing uncovered all potential connectivity issues and could affect uptime further as there is no Secure Gateway to fallback on as is the case with the Migration method.
In this case, in-place was the method chosen to move from the Secure Gateway to the NetScaler/Access Gateway.
Once testing was completed, the Secure Gateway was powered off and the Access Gateway’s VIP (Virtual IP) was changed from the test to the production IP. Changing the VIP was easy enough. Once the VIP was changed to the production IP and the configuration saved, the Access Gateway logon page came up instantly and I could login without issue, however, the browser than displayed a “blank” page as shown below:
Naturally, there are a couple things to be mindful of when changing the VIP of an Access Gateway virtual server.
If you open the NetScaler GUI and expand Network and then click Routes, you’ll see the route table of the appliance. Turns out, there was a route pointing to my test IP. I removed this entry.
2. DNS Address Records
In the NetScaler GUI, expand DNS, then Records, and click on the Address Records selection. In this list, I saw a host record for my FQDN still pointed to my test IP address. I changed this record to point to the production IP address.
After making these changes, the configuration was saved and the problem of the “blank” page was resolved.