Although it all works, I am confused. I have several setups where the CSG and WI are on the same box in a DMZ. The IIS site is set to listen on port 444. The CSG is configured to listen on 443.
My confusion is that all technical schematics of the operation of CSG show the initial connection as hitting the web interface. Then, following some authentication, the actual connection is handed off to the CSG where the application is launched and run via. Question is then, how does the initial connection manage to open the Web Interface connection if it is on port 444 when the user is browsing just on normal https on 443? Are the lines on the diagrams wrong, or am I missing something ?
Hi,
The SSL port for IIS is meaningless. In fact, you can disable the SSL listener for IIS altogether and everything functions as expected.
The reason is that the CtxSGSvc process accepts the incoming connections on port 443, then it reverse proxies a connect to the HTTP listener of IIS (port 80). This holds true for the case where CSG and WI are on separate servers too.
As far as authentication and the STA goes, Citrix published a decent guide on that here:
http://support.citrix.com/article/CTX106975
It explains the interaction between the WI and CSG in detail.
Alan Osborne
President (MCSE, CCNA, VCP, CCA)
VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB
VCIT website My Blog
Thanks Alan. So I wasn't going mad when I thought the same! It's confusing when you look at many of the standard diagrams and descriptions that say the client first makes a secure connection to the web interface, and shows a connection line from the external client, and direct to the WI. After a bit of authentication, it then passed to the CSG. This explanation does not make sense though as the WI utilises IIS, which has the port 443 binding disabled. Therefore, the initial connection MUST connect via the CSG on 443. This is proved somewhat by the immediate retrieval of the certificate at the browser end which sits on the CSG server, not the WI !!!
Have a single remote user visit the CSG/WI server, but ask them not to login. If you issue:
netstat -ano
You should see something similar to this:
In the above table, PID 4 is for the System process (this is actually the HTTP listener for IIS). PID 4480 is for CtxSGSvc.exe, the CSG service. You should also see a second PID for CtxSGSvc.exe as two instances of the CSG service run - the other one is the listener for port 443 (not shown above).
You can see from the table that the remote client (70.68.xxx.xxx) is connected to the CtxSGSvc process (client port 2181 and 2182, CtxSGSvc port 443) - this is the SSL tunnel. You can also see that the CtxSGSvc process and the IIS listener are talking to each other through the localhost address (all internal connections) - reverse proxy. The remote client only communicates directly with the CtxSGSvc process on port 443.
Have the remote user login and launch an application. Once a remote ICA session is established via CGP encapsulation within HTTPS packets, you'll see that the w3wp.exe process has a connection to the XML service of one of your backend server (for authentication and STA). There will also be a connection from the CtxSGSvc process to the backend XenApp server where the session is running. With SR enabled, the remote port will be 2598.