In Part 2 of this 3-part article, you learned how to:
- Generate an SSL certificate request
- Purchase a Wildcard SSL Certificate from GoDaddy
- Complete the certificate request
- Test secure access to published applications
- Export the SSL Certificate’s Private Key for use on additional servers
In Part 3, you will learn to install and configure Citrix Secure Gateway 3.1 and test external and internal secure access to published applications.
When you completed Part 2, you were at the server’s desktop (Figure 1).
Double-click the CSG_GWY.msi file and click Next (Figure 2).
Select I accept the license agreement and then click Next (Figure 3).
Select Secure Gateway and then click Next (Figure 4).
Click Next to accept the default installation folder (Figure 5).
Citrix Best Practice is to place the Secure Gateway/Web Interface server in the DMZ and the server should not be a domain member. Since this server is an Internet facing server it should be protected by all means possible. This includes using an account that has the least possible privileges and not putting the server on your internal network.
On the Service Account page you have the option of running the Secure Gateway service under Local System or Network Service accounts. What is the difference and which one should be chosen? According to http://msdn.microsoft.com/en-us/library/ms684190(VS.85).aspx, the Local System account runs at a very high privilege level. The article recommends using the Network Service account if a high privilege level is not needed. The Secure Gateway service does not need, and should not be given, such a high privilege level. According to http://msdn.microsoft.com/en-us/library/ms684272(VS.85).aspx, the Network Service account has very few privileges. You should seriously consider using the Network Service account for the Secure Gateway service. It is very odd that this important decision is not mentioned in the Secure Gateway for Windows Administrator’s Guide or any Citrix Support Tech Notes.
Using the Network Service account reduces the attack surface should your Secure Gateway/Web Interface server be hacked. Since this account has no domain privileges it will make it harder for an attacker to compromise your domain.
If you do decide to place the Secure Gateway/Web Interface server on your internal network, then you must use the Network Service account.
Select NETWORK SERVICE from the dropdown list and then click Next (Figure 6).
Verify the install options (Figure 7). If any corrections need to be made, click Back and make the necessary corrections. If everything is correct, click Next.
Click Finish (Figure 8).
Click OK to start the Secure Gateway Configuration wizard (Figure 9).
Click OK to start configuring Secure Gateway (Figure 10).
The Standard configuration does not allow us to set, or verify, all the necessary options. Select Advanced and then click Next (Figure 11).
Select your wildcard certificate and click Next (Figure 12). Click View… to view the information about your certificate. This is the same information that was seen in Part 2, Figures 77, 78 and 79.
For “Select secure protocol“, select Secure Sockets Layer (SSLv3) and TLSv1. For “Select cipher suite“, select All and then click Next (Figure 13).
If you have a single network card with a single IP address, you can select Monitor all IPv4 addresses (Figure 14). If you have multiple network cards and or multiple IP addresses on this server, unselect Monitor all IPv4 addresses, click Add and add the network interface(s) you wish to monitor for TCP port 443 traffic.
Secure Gateway will handle all TCP port 443 traffic and IIS handles SSL traffic on TCP port 444 (or whatever you selected in Part 2). Enter 443 for the TCP port and then click Next.
Note: IPv6 is only supported under Windows Server 2008.
Select No outbound traffic restrictions and then click Next (Figure 15).
You can restrict outbound traffic by pointing to another Secure Gateway server configured as a Secure Gateway Proxy (Figure 16) or by restricting traffic by IP Address (Figure 17).
The Secure Ticket Authority (STA) is installed on every XenApp server. If you have multiple XenApp servers enter as many XenApp servers as you like to provide failover.
Click Add (Figure 18).
Enter the Fully Qualified Domain Name (FQDN) of a XenApp server and then click OK (Figure 19).
If you get an error about The Secure Ticket Authority specified cannot be contacted (Figure 20), there is a name resolution error.
Two possibilities are to add entries for the XenApp servers into the Hosts file on the Secure Gateway server (Figure 21) or to enter the IP address of the XenApp server(s) for the FQDN (Figures 22 and 23).
Once all the XenApp servers IP addresses or FQDNs have been entered then click Next (Figure 24).
By default, Secure Gateway is limited to 250 concurrent connections. I would not recommend increasing this limit. If you need more than 250 concurrent connections then you should seriously consider Citrix’s hardware solution the Citrix Access Gateway.
Accept the defaults and click Next (Figure 25).
If you have any hardware load balancing appliances in front of your Secure Gateway/Web Interface server, enter the IP addresses here to exclude them from generating even log entries and then click Next (Figure 26).
Since the Secure Gateway and Web Interface are installed on the same server, select Indirect:…, check Installed on this computer and then click Next (Figure 27).
Select the level of logging you wish to receive from the Secure gateway service and click Next (Figure 28).
Check to Start the Secure Gateway service and then click Finish (Figure 29).
To verify the configuration and status of the Secure Gateway click Start, All Programs, Citrix, Management Consoles and then click Secure Gateway Management Console (Figure 30).
The Secure Gateway Diagnostics runs (Figure 31).
Expand each of the 5 sections to see the information for each (Figures 32 through 36).
Exit the Secure Gateway Diagnostics.
To test external access to published applications, you will need a public DNS name for the server. Mine is citrix.websterslab.com. I use DynDNS to allow the use of a dynamic Public IP address for my lab server. In your router or firewall TCP port 443 must be routed from the Public IP address to the internal IP address of the Citrix Secure Gateway/Web Interface server.
Internet -> Public IP address -> Router/Firewall -> TCP Port 443 -> Private IP address
Internet -> 68.x.y.z -> Router/Firewall -> TCP Port 443 -> 192.168.1.105
Start the Access Management Console. Click Start, All Programs, Citrix, Management Consoles, Access Management Console, expand Web Interface and then click your Web Interface site (Figure 37).
In the middle column under Common Tasks, click Manage secure client access and then select Edit Gateway settings (Figure 38).
Enter the FQDN that users will use to access the Secure Gateway/Web Interface server, enter the URLs for the XenApp server(s) and then click OK (Figure 39).
Again under Common Tasks, click Manage secure client access and then select Edit DMZ settings (Figure 40).
Click the Default line and then click Edit… (Figure 41).
Select Gateway Direct from the dropdown list and then click OK (Figure 42).
Selecting Gateway Direct will send to the client the external Public IP address of the Secure Gateway/Web Interface server instead of the internal Private IP address of the XenApp server hosting the published application.
Click OK (Figure 43).
From a computer that is external to your network, go to https://FQDN. For me, this is https://citrix.websterslab.com (Figure 44). Notice the SSL padlock appears.
Log in to the Web Interface and your published applications are shown (Figure 45).
Test running your published applications to verify they run successfully.
To verify the connection is using 256-bit SSL, right-click the Citrix Connection Center icon in the systray and select Open Connection Center (Figure 46).
Click the XenApp server and then click Properties (Figure 47).
The Client Connection Status dialog shows that 256-bit SSL is in use (Figure 48).
Exit the Client Connection Center, your published application, log off the Web Interface site and exit your Internet browser.
Repeat the tests from inside your network.
You have now successfully tested secure access to published application from both inside and outside your network.
In this final part, you learned to install and configure Citrix Secure Gateway 3.1 and test both external and internal secure access to published applications.