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. Also, there’s a traceroute like command, tracepath, to help trace the path taken to network hosts. 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.