Setting up UAG in a DMZ requires at least a minimum degree of coordination and collaboration between VDI admins and firewall guys. Sometimes this coordination doesn’t come easily and it can make for a very frustrating experience deploying UAG. While most VDI admins aren’t in a position to hop onto the network equipment themselves and fix it, there are steps they can take to help diagnose and narrow down network issues. I recently discovered two techniques that provide VDI admins with more independence when it comes to confirming port connectivity requirements have been met for their UAG deployments. The first involves using curl to confirm TCP port connectivity between the UAG appliance, the Connection server and the virtual desktop. The second involves using tcpdump on the UAG appliance to confirm receipt and transmission of UDP traffic.
If you’re interested in an excellent overview on UAG and Blast here are the official goods, Blast Extreme Display Protocol In Horizon 7. Otherwise, following are the specifics of
using curl and tcpdump.
Confirming TCP Port Connectivity Between UAG And
Internal Network
With the internet facing TCP ports you can always confirm
they’re open with port scanners or a good old fashion telnet connection. For example, you can test 443 TCP
connectivity like this:
telnet UAG-HOSTNAME-OR-IP 443
Or test port connectivity to 8443 similarly as
well:
As an alternative, here’s a simple port scanner example
using nmap:
Nmap –sS UAG-HOSTNAME-OR-IP
But what about confirming port connectivity from the UAG
appliance, through the internal firewall, to the virtual desktop or the
Connection server? Well, you can log
directly into the console of the UAG appliance and use curl to run telnet
against the connection server or virtual desktop.
Testing Port Connectivity From
UAG To The Connection Server
Log in to the console for the UAG 3.2 appliance. At the prompt, type the following:
curl -v telnet://CONNECTION-SERVER:443
Here’s what a successful connection looks like:
Testing Port Connectivity From UAG To The Virtual
Desktop
I’ve found you can telnet through curl to confirm
connectivity to TCP 22443 on the virtual desktop, with one caveat: initially after
being booted up, 22443 isn’t necessarily open on the virtual desktop yet. So, ensure a session is active with the
virtual desktop by actually making a connection to it, THEN check for
connectivity from UAG to UDP 22443 with this command:
curl -v telnet://VIRTUAL-DESKTOP:22443
With these two curl commands you’ve confirmed TCP port
connectivity from UAG to both the Connection server and the virtual
desktops. Combined with the successful port
checks for external facing ports, you now know you have the port connectivity
required for successful TCP based Blast communication and successful connections
should be possible. Now for UDP.
Confirming UDP Port Connectivity
Tcpdump can easily be installed on the UAG appliance with
this command:
After getting tcpdump installed, to test basic functionality you can run this:
tcpdump -i eth0 -n –v tcp port 443
Or to narrow it in on traffic specifically from the test client, try:
tcpdump -i eth0 host CLIENT-IP-ADDRESS and -n –v tcp port 443
Testing UDP 8443 Port Connectivity On External Interface
Now that we’ve confirmed the basic functionality of tcpdump,
we can use it to confirm port connectivity to UDP 8443. Hit ctrl –c to end the current dump. Then enter in:
To generate UDP traffic for UDP 8443 on the external port, we simply have to attempt a connection to the Horizon environment using, “Typical,” as the network condition:
Testing UDP 22443 Port Connectivity Between UAG
Appliance And Virtual Desktop
The next step is to confirm that UDP traffic is making it
out successfully from the UAG appliance, through the internal firewall and onto
port 22443 on the virtual desktop. We
can start to confirm this by first running tcpdump like this:
Then we can initiate a connection with the Horizon client
using the, “Typical,” network setting.
If UDP 22443 Is Open
At this point, after the user authenticates and selects a
desktop, the Blast protocol will attempt to send protocol traffic over UDP
22443 to the virtual desktop, before failing back to TCP 22443 should sending
UDP traffic fail. With a successful UDP
Connection tcpdump will continuously display changing output. You’ll see constant updates flash across the
screen like this:
If you run Wireshark on the destination virtual desktop at
the same time, in parallel to all this UDP traffic displayed on UAG, you’ll see
the UDP traffic making it to the destination desktop.
If UDP 22443 Is
Blocked
Should UDP 22443 be getting blocked, on the UAG console you’ll
see an initial burst of UDP traffic, then it will completely halt as Blast fails
back to TCP and gives up on sending traffic over UDP. So you’ll see output like this in the console
as it sits paused:
The Horizon connection has given up on using UDP for this
connection and has fallen back to TCP.
You can confirm this behavior hitting ctrl c and then search for TCP
transmissions.
tcpdump -i eth0 -n –v tcp port 22443
You'll see the client continuously sending packets over TCP now.
Also, by looking at Wireshark on the system, you’ll see that
only TCP packets have made it across to the virtual desktop, no UDP.
Other Available Tools
Along with the techniques detailed so far, you have some
other basic but very nifty network commands at your disposal from the UAG
console. You’ve got the ability to run
good old fashion pings from the UAG appliance, as well as nslookup. So, from the UAG console not only do you have curl
and tcpdump at your disposal, but also access to the same basic network
troubleshooting tools most of us are used to working with.
Update (5/15/2020) - If you found this article interesting, you're going to love this latest release from the folks at VMware, "Understand And Troubleshoot Horizon Connections." https://techzone.vmware.com/resource/understand-and-troubleshoot-horizon-connections#intro
Hubba Hubba! Good stuff!
This is an awesome post which gives almost perfect idea about web application scanners.
ReplyDeleteOpen Port Checker
This comment has been removed by a blog administrator.
ReplyDeleteAppreciate yoou blogging this
ReplyDeleteAwesome work and very helpful advice. I think this should be a top article for those who have the following errors: 1. Failed to resolve proxying route for request. 2. The connection to the remote computer ended. 3. The connection to the remote computer failed. “it is possible that remote connections are not enabled on the remote computer or that the computer on network is too busy. 4. VDPCONNECT_REJECTED: the connection to the remote computer has been refused Fix action was as recommended below: proxyDestinationUrl=https://cs1.domain.com:443 or Connection Broker IP:443 with sha256=thumbprint tunnelExternalUrl=https://uag1.domain.com:443 or UAGIP:443 blastExternalUrl=https://uag1.domain.com:8443 OR UAG IP:8443 pcoipExternalUrl=1.1.1.3:4172 UAG IP locked.properties file needs to have checkOrigin=flase portalHost.1=UAG DNS or IP without https:// HTTP(S) Secure Tunnel needs to be unchecked with Horizon Admin Connection Broker Settings PCOIP Secure Gateway needs to be unchecked with Horizon Admin Connection Broker Settings Do not use Blast Secure Gateway Option needs to be selected under Blast Secure Gateway. Reboot Connection Broker
ReplyDelete