Featured Post

Cloud Options For Accelerating Workspace One Adoption In Traditional Horizon Environments

Cloud options for VMware Identity Manager and Workspace One UEM (AirWatch) make it really easy to extend the benefits of Workspace One to on...

Wednesday, January 24, 2018

Troubleshooting Port Connectivity For Horizon’s Unified Access Gateway 3.2 Using Curl And Tcpdump





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:


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:

/etc/vmware/gss-support/install.sh



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


With the Horizon client set to, “Typical,” as a network condition, you’ll see a bunch of output from this command as authentication to the Horizon environment occurs. Here’s sample output detailing a connection from a client to a UAG appliance:


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:

tcpdump -i eth0 -n –v udp port 8443

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:



With this setting, after we authenticate to the Horizon environment and select a virtual desktop to connect to, Blast will initially attempt to send protocol traffic over UDP 8443, then fail back to TCP 8443 if there’s an issue. So, at minimum, we should see some UDP 8443 traffic sent to the UAG appliance, even if there is fail back to TCP based Blast. Here’s sample output from a connection:


With the above example, Blast initially sent a handful of packets to UDP 8443, then failed over to TCP because of UDP connectivity issues in the internal network. Regardless, we’ve confirmed that UDP 8443 is being received on the external interface. If no 8443 packets had been seen, we’d know there’s an issue with 8443 UDP getting blocked somewhere.


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:

tcpdump -i eth0 -n -v udp port 22443

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.
                               

No comments:

Post a Comment