Learning the Basics of Citrix Web Interface 4.6, Citrix Secure Gateway 3.1 and GoDaddy Wildcard SSL Certificate Part 3 of 3

March 8, 2009

Secure Gateway, Web Interface

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

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

Figure 3

Select Secure Gateway and then click Next (Figure 4).

Figure 4

Click Next to accept the default installation folder (Figure 5).

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

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.

Figure 7

Click Finish (Figure 8).

Figure 8

Click OK to start the Secure Gateway Configuration wizard (Figure 9).

Figure 9

Click OK to start configuring Secure Gateway (Figure 10).

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

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.

Figure 12

For “Select secure protocol“, select Secure Sockets Layer (SSLv3) and TLSv1.  For “Select cipher suite“, select All and then click Next (Figure 13).

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.

Figure 14

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

Figure 15

Figure 16

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

Figure 18

Enter the Fully Qualified Domain Name (FQDN) of a XenApp server and then click OK (Figure 19).

Figure 19

If you get an error about The Secure Ticket Authority specified cannot be contacted (Figure 20), there is a name resolution error.

Figure 20

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

Figure 21

Figure 22

Figure 23

Once all the XenApp servers IP addresses or FQDNs have been entered then click Next (Figure 24).

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

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

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

Figure 27

Select the level of logging you wish to receive from the Secure gateway service and click Next (Figure 28).

Figure 28

Check to Start the Secure Gateway service and then click Finish (Figure 29).

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

Figure 30

The Secure Gateway Diagnostics runs (Figure 31).

Figure 31

Expand each of the 5 sections to see the information for each (Figures 32 through 36).

Figure 32

Figure 33

Figure 34

Figure 35

Figure 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

For me:

Internet -> 68.x.y.z -> Router/Firewall -> TCP Port 443 ->

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

Figure 37

In the middle column under Common Tasks, click Manage secure client access and then select Edit Gateway settings (Figure 38).

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

Figure 39

Again under Common Tasks, click Manage secure client access and then select Edit DMZ settings (Figure 40).

Figure 40

Click the Default line and then click Edit… (Figure 41).

Figure 41

Select Gateway Direct from the dropdown list and then click OK (Figure 42).

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

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.

Figure 44

Log in to the Web Interface and your published applications are shown (Figure 45).

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

Figure 46

Click the XenApp server and then click Properties (Figure 47).

Figure 47

The Client Connection Status dialog shows that 256-bit SSL is in use (Figure 48).

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.

, , ,

About Carl Webster

Webster is a Sr. Solutions Architect for Choice Solutions, LLC and specializes in Citrix, Active Directory and Technical Documentation. Webster has been working with Citrix products for many years starting with Multi-User OS/2 in 1990.

View all posts by Carl Webster

No comments yet.

Leave a Reply