Test Packets enables UAG admins to test external port connectivity easily and with surgical precision. Historically port connectivity issues have been the most common challenge with new UAG deployments. Between the nature of firewalls, change management processes and IT silos, it's incredibly easy for organizations to mess up the firewall requirements for UAG. Throw in some unusual UDP ports and unfamiliarity with UAG and you have a perfect storm for finger pointing and frustration. Test Packets addresses this predicament by sending specially marked test packets that are easily viewed on the UAG console using a combination of tcpdump and grep, simplifying the diagnosis of external port connectivity challenges.
Quite often Horizon admins don't have direct access to the networking equipment surrounding a UAG deployment like firewalls and load balancers. Typically they work around this deficit using a combination of port scanners and tcpdump. Though you might not know with certainty how your firewalls or load balancers are configured, you can say with certainty what UAG is able to see with tcpdump while leveraging port scanners to validate external paths to the UAG appliance. With these diagnostics tools Horizon admins have been able to pinpoint blocked ports for faster resolution.
Leveraging tcpdump for port connectivity testing is a well traveled path amongst Horizon admins, but not always an easy go. Clear answers aren't always forthcoming as you may have to sort through other distracting noise on the wire, particularly if the appliance is already supporting multiple sessions. Further, NAT'd addresses or unknown load balancing configs may complicate things as well. The aim of Test Packets is to cut through all the noise and confusion, lending simplicity and surgical precision to the testing of external port connectivity. By crafting test packets with an ASCII payload of, "EvenGooder test packet," we can validate port connectivity on the UAG console with simplicity and certainty.
How To Use It
Before sending our test packets you need to run tcpdump on the command line with some specific arguments. While tcpdump isn't installed on on UAG appliances by default, it's easily installed through a support script included on all versions UAG. The script can be executed with:
/etc/vmware/gss-support/install.shOnce installed, there's a single tcpdump command executed on the UAG appliance to listen for test packets from troubleshoot.evengooder.com. The command is:
tcpdump -i eth0 -l -A -n -v | grep "EvenGooder"At this point, tcpdump is ready and waiting for test packets. Now, navigate to Test Packets at troubleshoot.evengooder.com.
Enter in your externally resolvable hostname and the port you want to test for and click, "Send Packets." Almost instantaneously you'll see if the packets show up on the UAG appliance interface. 3 packets are sent. First, as a test packet, 443 TCP is sent to validate basic connectivity. Then TCP and UDP version of whatever port you enter are sent. So if you entered in 8443, packets for TCP 8443 and UDP 8443 will be sent to the external URL and should show up on the console. Here's an example of a successful test:
What I love about this overall solution is how quick and simple the testing is. Click on the web site, look at the console and know. We're not firing up the Horizon client and entering in creds or fooling around with other simulations. Just an easy to work with web interface and single command on the UAG appliance for immediate and unambiguous validation. Like any useful tool, it might not normally amount to much, but when you need it's functionality you NEED it and it's nice to have round.
Why All The Fuss
Again, for quite some time we've been able to leverage tcpdump on UAG appliances to help pinpoint port connectivity challenges. It's still a very relevant tactic today, particularly when it comes to validating UDP traffic flow. What Test Packets introduces is specificity and clarity. Using tcpdump for real-time diagnostics isn't always a walk in the park. There can be a lot of noise to sort through, particularly in an active deployment. You can limit input to a specific interface, but soon you'll find there's possibly a lot more traffic on that interface than you imagined, making quick diagnostics from the command line a little tricky. Further, while there's always the option to narrow down on source ip, that's no always straight forward either. For one thing, the source you're testing from could be from behind a NAT'd address. For another example, with certain load balancing configurations all external traffic hitting the UAG appliance might show up with the load balancer as source IP. 
These are just two examples that come to mind. They're not absolute show stoppers, but they're challenges you might have work around, which is not always easy, particularly when you're stressed out and not 100% certain what's going on. You can take a packet capture, export the packet off the UAG appliance and take a look at it with wireshark, but then you have to, take a packet capture, export the packet capture off the the UAG appliance and look at it with wireshark. It's doable, but not ideal, especially if your in the middle of a knife fight with your networking guys.
Conclusion
This is a pretty nerdy, down deep in the weeds, solution I've put together for others that are serious about getting a UAG appliances deployed. Maybe there'll only be 12 people in the world using it, but I imagine those who get to using it are going to love it. Please let me know in the comments what your experience with it has been like and if you have any suggestions for improvement.
No comments:
Post a Comment