I’m interested in understanding what the recommended production architecture is for external users connecting over the Internet using the native client. I have webaccess with MFA and NGNIX as the reverse proxy working but looking at the native client, mainly because of audio support and the best possible graphics performance.
I’ve read the following blog post
Specifically:
Is opening SSH (port 22) to the broker(s) via NAT/port forwarding the recommended approach, or is there a better practice?
How do most orgs deploy multiple brokers for native client access? Is Nginx or another load balancer commonly used, or should clients connect directly to the broker HA VIP?
For a Citrix deployment - Netscaler ADC Gateway’s + MFA would handle this for both web and native clients.
For the native client, the recommended approach is direct access to the SSH port on each machine in the cluster. A properly configured SSH service should be secure enough for this to be done safely, provided you have sufficient public IP addresses available. Network-level restrictions, for example limiting the acceptable inbound IP range, can also be used to increase security.
In the case where only one public IP address is available, NAT/port forwarding can be used, however the optimal configuration is one IP address per server. When using HA, clients should connect directly to the VIP. Reverse proxy (via Nginx or similar) is supported for the browser-based client, but not the native client. Hope that helps.
Thanks for clarifying the setup and to confirm, for a 2 node TL Broker HA pair you would need 2 public IP address - one per broker.
If there’s only one public IP and your using NAT, could we use HAProxy to SSH load balance as outlined in the blog post ? Would this work with Thinlinc ?
I’ve replaced the NGINX HTTP reverse proxy with an HAProxy HA pair that now handles both HTTP reverse proxy and SSH proxy through a single floating VIP.
Unit testing was successful without MFA. After enabling MFA on the brokers, both the web browser client and the native ThinLinc client are able to authenticate with MFA and establish sessions successfully via the VIP
For HTTP persistence I’m currently using source (source IP), similar to how we’d configure persistence on a NetScaler ADC. Initial testing looks promising, although getting everything working took a bit of effort.
At the moment it’s only configured for HTTP browser access and SSH and all testing has been carried out on the LAN. Further unit testing is required.
Before moving on to stage 2—enabling HTTPS on the HAProxy, installing certificates, configuring HSTS, cipher suites, TLS settings, etc. (essentially treating it like a NetScaler ADC gateway)—is there anything I should be aware of or any recommended best practices specific to ThinLinc?
Update:
HTTPS enabled on the HAProxy cluster. SELinux once again likes to make life harder than it should be !
Further testing completed on the HAProxy HA pair.
Validated:
ThinLinc native client access through the HAProxy VIP (SSH proxy).
MFA authentication working through the HAProxy endpoint.
New session creation.
Session disconnect and reconnect.
HAProxy node failure and VIP failover using Pacemaker.
Test scenario:
Active ThinLinc native client session established through the HAProxy VIP.
Active HAProxy node was shut down.
Pacemaker moved the VIP to the remaining HAProxy node.
Existing ThinLinc session remained available.
After disconnecting, the native client successfully reconnected through the new HAProxy node.
So far the HAProxy gateway is behaving as expected and is providing a single HA endpoint for both ThinLinc web access and native client connectivity.
Next steps are HTTPS hardening (trusted certificates, TLS configuration, HSTS, cipher configuration) and further failure testing.
Restricted TLS to v1.2/1.3, limited HAProxy to TLS 1.2/1.3 cipher suites, enabled HSTS, and configured DH parameters across the HAProxy cluster. As this is a lab environment, the certificate will remain self-signed for now, or I’ll generate one from my MS CA for further testing. RockyLinux 9.8 is still using the default configuration—I haven’t applied any additional OS hardening to the cluster yet.
I also ran testssl.sh to see how the HAProxy configuration would compare with a Qualys SSL Labs assessment (thanks to ChatGPT—I wasn’t aware there was an offline equivalent). The result was a T rating, with the grade capped solely because of the self-signed certificate. I’ll rerun the tests using a Microsoft CA-issued certificate to see how much the rating improves.
Summary so far:
TLS 1.2 and 1.3 only
Modern cipher suites only
Secure renegotiation enabled
HSTS enabled
DH parameters configured
More testing to come, especially after upgrading ThinLinc to the 4.21 beta.
That’s a good question - I’m not familiar enough with HAProxy to be able to give you a confident answer I’m afraid. As long as the proxy is configured such that it’s transparent to ThinLinc, I think it should be fine. Everything is tunnelled over the SSH port (for the native client), so a minimally permissive proxy should only have to forward that specific port.
Thanks for getting back to me. Configuration-wise, HAProxy has been working fine with both the web and native clients and everything is behaving as expected. No issues so far.
I think I need to revisit the HAProxy build and work through the Red Hat hardening guidance, or something similar, just to make sure the servers are properly secured before deploying them into a DMZ and exposing them to the internet.