Jump to content


VPX HTTPS access different than 443

Started by YAN BENOIST , 14 April 2017 - 03:42 PM
9 replies to this topic


  • 15 posts

Posted 14 April 2017 - 03:42 PM



Here's the situation:


- VPX version 11.1

- "Official" signed SSL certificate


An https web access on the public ip address on default port 443 flows thru the firewall (physical appliance) and arrives on the VPX (port 443 also configured in the virtual server with the delivered server certificate).

No pb, login and application launch works.


Due to another application also accessed from the outside and that seems not to be able to use another port than 443 (and that has it's own SSL certificate), i decided to use port 9090 for my VPX https access.

So, the firewall redirects incoming 9090 traffic to 443 and sends it to the VPX.

After authenticating on the VPX and trying to launch a published application, i get an error claiming about an SSL certificate error (the one use by the other app).
Indeed, if i look in the .ica file, i see this entry:



It seems to say that Receiver trys to launch the app on 443 port and not on 9090.

So, my question is:

Should i change the Virtual server configuration in VPX and indicate to use port 9090 instead of 443 ?

Or is there something else to do ?


Thanks in advance.

(Hope it's clear enough...)




Joe Brozzetti Members

Joe Brozzetti
  • 180 posts

Posted 14 April 2017 - 06:12 PM



You have to 2 URL's that resolve to the same public IP?  


If so, this would probably be a Content Switch.  Is that what you are doing now?


  • 15 posts

Posted 14 April 2017 - 10:34 PM

Hi Joe,


No, i have only one URL that resolves to the public ip. Therefore, i have to toggle with the differents ports and redirect to the different internal servers.

Even with different URLs, the flow would arrive on the same WAN interface and i had to redirect.

Or, there's something i'm missing...

In fact, the question is: how should a VPX be configured to use another port than 443 for https ? Has it just to be indicated in the virtual server config ?

By the way, once the virtual server is created, how to change the port  ?

Rhonda Rowland Members

Rhonda Rowland
  • 153 posts

Posted 15 April 2017 - 06:39 PM

For your last question, if you create a virtual server on port X and then want to change to port y, you will have to create a new virtual server.  Can't change the port on an existing virtual server.


However, you could just select the existing entity and click "Add" to create a copy and then change the port and name on the new one.  Though if this has a lot of dependent settings, view the runningconfig for the vserver name so you can catch all settings and bound objects.  Then you could use the CLI to create a new entity with the name and port you want after deleting the old one.  


For the first part of your question, you should be able to change the gateway port, but it may add some extra troubleshooting. You would have to include the port when defining the Gateway FQDN and Callback address in StoreFront, so the port is communicated to the Citrix Receiver in the client-side connection.  For example:  gateway FQDN and callback fqdn in the StoreFront settings would be:  https://gateway.domain.com:9090.


But the Unified Gateway may also help you work with one VIP if you don't want to change a lot of ports, depending on if you can distinguish non-gateway traffic by URL paths.


  • 15 posts

Posted 16 April 2017 - 11:01 PM

Hi Rhonda,


Thanks for your answers. I'll try this asap.

Joe Brozzetti Members

Joe Brozzetti
  • 180 posts

Posted 24 April 2017 - 05:10 PM

Did you get this working?


After reading the scenario again the Unified Gateway that Rhonda suggested would work if you had different URL's going to the same IP.  Instead of users going to somesite.com:Port they would have 2 URLs.  The Unified Gateway would have a Content Switch that would send URL1 to Gateway1 and URL2 to Gateway2.  This way you have 1 IP, 2 URLs and everything else is internal.


  • 15 posts

Posted 04 May 2017 - 03:22 AM

Hello Joe and Rhonda,


Thanks for the advice. I've read some blogs and articles to see how to implement the Unified Gateway solution.

As i understand, the users log into the Netscaler Gateway and are redirected either to the XenApp servers or to other applications such as web sites or something else.

But, my pb is that my other application doesn't need (and cannot) to authenticate to AD and on the Netscaler.

Or, i'm wrong and there's is another way to do ?

If not, i'll try to reconfigure the Virtual Server to use port 9090.

Paul Blitz Members

Paul Blitz
  • 3,915 posts

Posted 04 May 2017 - 10:34 AM

Here's some ideas that you could consider...



Start by using 2 different domain names, both resolve to the same IP. As this is SSL, then you'll need certs to cover both fqds, so either wildcard cert, SAN cert, or use SNI.


Next you need to split the traffic for the backend: the obvious thing to do is to use a single Content Switching VServer on port 443. This will accept traffic for both FQDNs.


Next create 2 HTTP Load Balancing vservers, one for each application.


Now create two content switching policies: First will match FQDN1, and send that traffic to LB1. Second will match FQDN2, and send traffic to LB2.


The policy will be something like: HTTP.REQ.HOSTNAME.EQ("fqdn1.com")


Bind the policies. to the CSW


Now, traffic for both FQDNs will come to that SSL CSW vserver on port 443: the CSW will terminate the SSL, and will send the incoming traffic to the relevant LBVS.



The other way to do this is to create a pair of LBVS, one on port 443, the other on, say, port 444. Again, using 2 FQDNs. Whilst you might try to get the users to type "https://fqdn2:444" the likelihood is that they WILL forget, and would end up on the wrong vserver.


So, create a responder policy on the :443 vserver, to match FQDN2 (the INcorrect FQDN) and forward them to "https://fqdn2:444". You may find that there are one or two backend links that are absolute links, they will need to be re-written to include the  :444.


Unified Gateway is actually a Content Switch, that uses Netscler Gateway for incoming auth & SSO - it's aimed as connecting to Exchange etc, that NEED auth. You don't need the auth, so a plain CSW VS will work for you.


  • 15 posts

Posted 08 May 2017 - 11:05 PM

Hi Paul,


Thanks for your solutions. I'm note sure i'll be able to configure them cause my Netscaler skill are quite low...

It seems that the other app could use another port than 443, so i'll try to stay configured as i am now.


Anyway, thanks to you all for your help and experience,



mars2k4 Members
  • #10

Tom K├╝nzel
  • 29 posts

Posted 14 June 2017 - 01:10 PM

I got a scenario that is somehow like this.


Imagine the following situation:


1x Citrix Secure Gateway Deplyoment within DMZ at port 443 listening at fqdn: host.domain.com


No I want to replace the CSG with netscaler gateway VPX but I need to run both boxes parallel in order to migrate to netscaler step by step.


So I was thinking just to configure the portforwarding at the firewall for instance on WAN site 444 to netscaler VIP 443.


Like Yan said this seem to result in some problems because Netscaler is not aware of the 444 port, right?


I see no problem in getting up running two FQDNs for both (CSG and Netscaler). But I just want as little config for the parallel runtime scenario for the netscaler.

Wouldn't it be possible to just configure netscaler VIP to a different port than 443?