We help IT Professionals succeed at work.

Why can we not access Xen App Fundamentals 6 externally ?

PurityIT asked
We have installed a new Citrix Xen App Fundamentals v6 server and set up both the internal and external sites as per the installation.  We are able to access the internal site internally but when we try to browse to the external site we are unable to access it on port 443.

We have added in the address of the server using the altaddr command and made sure the secure communications for the the WI site is set Default and Alternate however we are unable to browse to get as far as the External Website despite ports 443, 1494 and 2598 being open and forwarded to the Citrix server.  When we also telnet to the external address of the server on port 1494 we get the proper response of ICA repeatedly.

In addition to the testing above we opened the router to forward on port 80 and that took us to the Internal site.  When we downloaded the lauch.ica file and changed the "address" from the internaladdress:1494 to the externaladdress:1494 we are able to log on to our Published server desktop.

Can anyone offer any advice how to fix this or what could be causing it ?

Many thanks in advance
Watch Question

CoralonSenior Citrix Engineer

It depends on your version of Web Interface.

On most of the current versions, you need to change the Secure Access from Direct to Alternate Address to force the connections to use the alternate address as you specified.  

Open up the Web Interface Management Console
Select the website
Select Secure Access on the right side
Select the Default entry and click Edit and change it to Alternate.

If you are going to use the site both internally and externally, it will depend on your firewall and how it presents the ip to the Web Interface server.  

Some firewalls (many of the Cisco's for example) will present the IP of the firewall for the outside connections.  In those cases, you will need to add an entry for the firewall IP as Alternate and leave the default as Direct.  If not, then you add an entry for your internal IP addresses as Direct and leave the default as Alternate.

*However*  I would strongly recommend you look at implementing a gateway of some sort (Citrix Secure Gateway being the most obvious) since that will eliminate this requirement.  In those cases, you would select Gateway Direct  (generally speaking).  Otherwise, your traffic between the clients and your server is unencrypted, unless you publishe your applications with RC5-128 bit security which is good encryption, but is subject to man in the middle attacks.



Hi Coralon,

Thanks for your post.  

We are using version 6 of the Xenn App Fundamentals software

The External website is already set at Alternate.

Citrix Secure gateway is installed and we have configured the server to use a certificate but i'm not so sure that this is working 100% correctly as when I try to telnet to port 443 on the Citrix server this doesn't accept the connection internally or externally
CoralonSenior Citrix Engineer

Ok, that helps then. :-)

You need to change the Secure Access to Gateway Direct (assuming your outside IP address is the same name as the certificate you have. - CSG is very picky about the cert name, it must match exactly what you are using in DNS.  Any SSL errors will cause CSG to fail).

You do *not* need to use Alternate since you are using a CSG.  

So - you need:
443 from the outside to the CSG
(80 from the outside if you want to provide an automatic redirect).

Every other port is handled internally only, there is no need to provide outside access to the other ports.

Your cert must be trusted cert by both the server and the client.



Hi Coralon,

We are now at the stage of implementing this in a live environment so I was able to move the certificate from the old server to the new server.  I installed the certificate on the new server and when I browse to https://localhost I get the Web interface of the Xen App page.  I tried this externally and still get the dreaded "page cannot be displayed" in Internet explorer.  I then tried another another server which is on the same subnet as the Citrix server (so that I could rule out a firewall issue) and unfortunately I still get the same result.

Do you have any idea what could be stopping this from displaying the site ?


Further update for you.

I stopped the Citrix Secure Gateway service then went into IIS .  In here I added port 443 as a binding to the "Citrix XenApp6 Fundamentals Edition External Site".  I restarted IIS and was able to access the external site whenever I type in https://externalurl so it does look like a problem with CSG.
Senior Citrix Engineer
Ok, that is most likely a proxy configuration problem.  

The "proper" way to do this for what you are trying to do is this:

The certificate name should match your CSG.
The CSG is the only address connected to externally.
You configure the CSG with the IIS site hosted on the same server on port 80.
Turn *off* the https encryption for the website (yeah, it sounds backwards, but there is more below that will protect it).
Configure the WI website to *only* allow its port 80 traffic from  (this is key protection - without this, your WI site is exposed and vulnerable.)
Be sure you fix the redirection on the root of the website.  The default page webinterface.htm in the root uses a relative redirection.  It's safer to use a fully qualified redirection (instead of having it say ../citrix/xenapp or whatever, you will have it say https://site.com/citrix/xenapp ...)

The theory here (and it works, it is my "standard" build practice for most sites) is that the incoming WI connection hits CSG, and CSG recognizes the http traffic and proxies it for the IIS site.  The WI site is configured to use the CSG for external connections.  Internal connections get sent directly to the XA server bypassing the CSG.  (Or for a small environment, you can just run all the connections through the CSG).

There are alternate configurations out there that I have seen, such as having the CSG or IIS run on a non-standard port (like 444) but that usually requires opening an additional port on the firewall that may not be open on a remote client.  Since 443 & 80 are almost always open, the config I listed will work in 99% of cases.

Let me know :-)