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).
Clik here to view.
Double-click the CSG_GWY.msi file and click Next (Figure 2).
Clik here to view.
Select I accept the license agreement and then click Next (Figure 3).
Clik here to view.
Select Secure Gateway and then click Next (Figure 4).
Clik here to view.
Click Next to accept the default installation folder (Figure 5).
Clik here to view.
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).
Clik here to view.
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.
Clik here to view.
Click Finish (Figure 8).
Clik here to view.
Click OK to start the Secure Gateway Configuration wizard (Figure 9).
Clik here to view.
Click OK to start configuring Secure Gateway (Figure 10).
Clik here to view.
The Standard configuration does not allow us to set, or verify, all the necessary options. Select Advanced and then click Next (Figure 11).
Clik here to view.
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.
Clik here to view.
For “Select secure protocol“, select Secure Sockets Layer (SSLv3) and TLSv1. For “Select cipher suite“, select All and then click Next (Figure 13).
Clik here to view.
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.
Clik here to view.
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).
Clik here to view.
Clik here to view.
Clik here to view.
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).
Clik here to view.
Enter the Fully Qualified Domain Name (FQDN) of a XenApp server and then click OK (Figure 19).
Clik here to view.
If you get an error about The Secure Ticket Authority specified cannot be contacted (Figure 20), there is a name resolution error.
Clik here to view.
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).
Clik here to view.
Clik here to view.
Clik here to view.
Once all the XenApp servers IP addresses or FQDNs have been entered then click Next (Figure 24).
Clik here to view.
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).
Clik here to view.
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).
Clik here to view.
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).
Clik here to view.
Select the level of logging you wish to receive from the Secure gateway service and click Next (Figure 28).
Clik here to view.
Check to Start the Secure Gateway service and then click Finish (Figure 29).
Clik here to view.
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).
Clik here to view.
The Secure Gateway Diagnostics runs (Figure 31).
Clik here to view.
Expand each of the 5 sections to see the information for each (Figures 32 through 36).
Clik here to view.
Clik here to view.
Clik here to view.
Clik here to view.
Clik here to view.
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
For me:
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).
Clik here to view.
In the middle column under Common Tasks, click Manage secure client access and then select Edit Gateway settings (Figure 38).
Clik here to view.
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).
Clik here to view.
Again under Common Tasks, click Manage secure client access and then select Edit DMZ settings (Figure 40).
Clik here to view.
Click the Default line and then click Edit… (Figure 41).
Clik here to view.
Select Gateway Direct from the dropdown list and then click OK (Figure 42).
Clik here to view.
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).
Clik here to view.
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.
Clik here to view.
Log in to the Web Interface and your published applications are shown (Figure 45).
Clik here to view.
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).
Clik here to view.
Click the XenApp server and then click Properties (Figure 47).
Clik here to view.
The Client Connection Status dialog shows that 256-bit SSL is in use (Figure 48).
Clik here to view.
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.