Troubleshooting Amazon WorkSpace Connectivity from an End-User Device

I recently ran into a situation where I was unable to connect to an Amazon WorkSpace.  Though everything looked great on the AWS side in that no problems were displayed within the WorkSpaces console, the Get-WKSWorkspace PowerShell command, and the CloudWatch WorkSpace dashboard, my connection would launch, present me with a black screen, and then disappear.  Granted, my first task was to reboot the WorkSpace but as you may have guessed, my connection issue remained.  So, I decided to use this opportunity to investigate what resources are available to us as we troubleshoot WorkSpace connection issues from the end-user client/device perspective before breaking down and simply rebuilding the WorkSpace.

1. What Color is the WorkSpaces Network Icon?

The easiest troubleshooting step may also the most overlooked.  When you launch the WorkSpaces client, notice the network icon in the top right-hand corner of the window; the WorkSpaces client performs five “tests” when launched:

• Is the client device connected to the network?
• Is the client device connected to the internet?
• Can HTTPS connectivity be established to the AWS WorkSpaces service?
• Can the client connect to the WorkSpaces services using TCP Port 4172?
• Can the client connect to the WorkSpaces services using UDP Port 4172?

If all tested connections are active and available, then the network icon will be green.  If any of the network tests fail, the icon will be red as shown below.  This provides you with a method to quickly identify the state of your connectivity to the AWS WorkSpaces service.

In my recent case and much to my surprise, my WorkSpaces network icon was red and upon clicking the network icon for more information, I saw that though my laptop was on the network, had internet connectivity, and could even communicate to the WorkSpaces service using HTTPS, I could NOT connect to WorkSpaces over UDP Port 4172

To save us some time, I launched the WorkSpaces client on other computers and had no network issues.  Furthermore, the UDP connectivity test passed when I connected my laptop to a wired ethernet connection.  The issue manifested itself only on a specific laptop when it was connected to my wireless network.  Turns out a recent update to the AV/Security Suite application on my laptop was the reason behind the issue.

Tip #1:  Check the WorkSpaces network icon to ensure the required network connectivity to AWS WorkSpaces is established.

2. Enable WorkSpaces Client Logging

Well, I can assure you that I thought I had my problem fixed!  My WorkSpace was looking good from an AWS console perspective and now my WorkSpaces client network icon was green!  I had an available WorkSpace and network connectivity to it, yet I was still unable to connect?!?!  What’s going on now?

To get more insight into what is going on with the WorkSpaces client, I decided to enable advanced logging.  It’s easy enough to do, simply open a command prompt, and launch the WorkSpaces client with the -l3 flag (workspaces.exe -l3).  You’ll find the logs saved in the %LOCALAPPDATA%\Amazon Web Services\Amazon WorkSpaces\logs directory.

After enabling advanced logging and attempting to launch my WorkSpace, the surprises continued.  I found many entries stating that the connection changed to “……CONGESTED with PCOIP_DISCONNECT_CAUSE_NONE”.  How can a status change with no cause?

Well, if you’ve used or had to troubleshoot PCOIP connectivity issues in the past, you may already know the most likely reason we’re seeing this is that the session was terminated because of a network failure or interruption.  As I did in troubleshooting the earlier UDP connection problem, I tried connecting to my WorkSpace from multiple clients and they all failed to connect with the same reason, DISCONNECT_CAUSE_NONE.  Even though my WorkSpace reads AVAILABLE from the AWS console and each WorkSpaces client I tested connectivity from pass the network checks, I’m unable to connect.

No matter what the Status of my WorkSpace displays within the AWS console, I now believe the problem resides there…

Tip #2:  To gain deep insight into what the WorkSpaces client is doing, enable advanced logging.

3. Can I Test Connectivity to My WorkSpace using RDP?

Though the WorkSpaces client does not support RDP connectivity to a WorkSpace, you can enable RDP access to support troubleshooting efforts via the security group attached to the WorkSpaces network interface as shown on the screenshot below.

SIDE NOTE: I know….I know and I completely agree!  0.0.0.0/0 should not be used as the Source address.  Even if you plan to use this rule to provide temporary access, you may forget to come back and remove the entry from the Inbound rules list.  Instead of 0.0.0.0/0, use the IP address of a bastion host that exists within your AWS environment.

With the inbound rule allowing RDP in place, attempt to connect to the WorkSpace using RDP from an allowed source.  When I connected with RDP, the problem with my WorkSpace was quite clear.

Looks like I was foiled by an update to my WorkSpace as well but at least the resolution was straightforward.

Tip #3:  If you cannot connect to your WorkSpace using PCOIP, you can enable RDP access for troubleshooting.

Wrapping Up….

If everything in your WorkSpaces environment looks good but you are unable to connect, we do have methods available to us to troubleshoot connectivity issues from the end-user client.  Remember, don’t overlook the WorkSpaces client network icon…give it a quick glance to see if it is green or red.  We also have the capability to gain deep insight into a given connectivity issue by launching the WorkSpace client via the CLI with the -l3 flag to enable advanced logging.  In addition to the network icon and advanced logging, AWS has provided a means to enable and allow access to a WorkSpace using RDP as troubleshooting tool.

If all else fails, you can always try rebuilding the WorkSpace…..  😊