Jump to content


Photo

VPX HTTPS access different than 443

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

YAN BENOIST Members

YAN BENOIST
  • 13 posts

Posted 14 April 2017 - 03:42 PM

Hi,

 

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:

SSLProxyHost=external-web-site-name:443

 

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

 

Yan

 



Joe Brozzetti Members

Joe Brozzetti
  • 165 posts

Posted 14 April 2017 - 06:12 PM

Yan,

 

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?



YAN BENOIST Members

YAN BENOIST
  • 13 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
  • 79 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.



YAN BENOIST Members

YAN BENOIST
  • 13 posts

Posted 16 April 2017 - 11:01 PM

Hi Rhonda,

 

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



Joe Brozzetti Members

Joe Brozzetti
  • 165 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.