Issue
We have distributed iPads (10th generation) to our staff for use as workstations.
When they work from home, they access WorkSpaces from their own computers.
Since the WorkSpaces client application can be installed on the iPad, we wanted them to be able to connect to WorkSpaces from their iPads when they are away from home.
I assumed they would be using the Magic Keyboard for iPad, but I encountered an issue where they could log in to WorkSpaces, but the arrow keys would not work.
Cause
I have checked and cannot confirm the cause or the same event, and to be honest, the cause is unknown.
Since it is happening on multiple devices, it doesn’t seem to be a problem on the device side or something, but I couldn’t find any reports of similar events on the Internet.
However, I was able to work around the problem as follows and was able to operate the arrow keys for the time being, so that’s good.
Method
As it turns out, we are connecting to WorkSpaces via RDP.
It seems that the problem was caused by the PCoIP connection, and I was able to operate the arrow keys by connecting to WorkSpaces via RDP.
I used the following as a reference;
How do I connect to my WorkSpace with RDP?
https://repost.aws/knowledge-center/connect-workspace-rdp
However, we also have a requirement to keep the subnet where WorkSpaces is located as a private subnet, so we decided to use AWS Client VPN as well.
Since we already use Directory Service with WorkSpaces, we can use it directly for AWS Client VPN authorization.
This is quite nice, and employees can connect to AWS Client VPN with their usual passwords.
The configuration is as follows;
Preparation for the configuration is as follows;
- Create Route 53 private host zone (user.workspaces)
- Create Client VPN endpoints
- Use a server certificate for a domain that has been properly obtained.
- Authentication is user authentication with an existing Directory Service.
- Authorization rule is 0.0.0.0/0 for all users.
(We may narrow this down to the WorkSpaces subnet CIDR in the future.) - Target network is an appropriate subnet
- DNS is the IP address of the VPC CIDR +2
(since we will be using a private host zone)
- Create a Lambda function (AWSClientVPN-ReadyWorkSpaces)
- To start the user’s WorkSpaces
- To assign a domain name to the user’s WorkSpaces IP address
- Grant the necessary permissions to each with IAM roles
- Configure Lambda handlers for Client VPN endpoints
- Download configuration file from Client VPN endpoint and distribute to employees
WorkSpaces is configured in AutoStop mode because it is quite expensive when running.
So, we will use Lambda handlers to start it each time.
Also, when specifying RDP by IP address, we decided to manage by domain name because it is troublesome to deploy to employees.
The Lambda handler will register the WorkSpaces IP address with the Route 53 host zone.
I had Chat GPT write most of it, but here is the code for the Lambda function;
AWSClientVPN-ReadyWorkSpaces code
import boto3
def lambda_handler(event, context):.
# Resource information
directory = '<directory ID>'
hostedzone = '<host zone ID>'
domain = 'user.workspaces'
# Get username from event
username = event.get('username')
if not username:
return {
"allow": True,
"error-msg-on-failed-posture-compliance": "Username not provided",
"posture-compliance-statuses": [],
"schema-version": "v2"
}
# Create WorkSpaces client
workspaces_client = boto3.client('workspaces')
# Get the user's WorkSpaces
response = workspaces_client.describe_workspaces(
DirectoryId=directory,
UserName=username
)
workspaces = response.get('Workspaces', [])
if not workspaces:
return {
"allow": True,
"error-msg-on-failed-posture-compliance": f'No WorkSpaces found for user {username}',
"posture-compliance-statuses": [],
"schema-version": "v2"
}
# Start WorkSpaces
workspace_id = workspaces[0]['WorkspaceId']
workspaces_client.start_workspaces(
StartWorkspaceRequests=[
{'WorkspaceId': workspace_id}
]
)
# Get the IP address of the WorkSpaces
workspace_ip = workspaces[0]['IpAddress']
# Create a Route 53 client
route53_client = boto3.client('route53')
# Create a subdomain name
subdomain = f"{username}.{domain}”
# Create a record
try:
route53_client.change_resource_record_sets(
HostedZoneId=hostedzone,
ChangeBatch={
'Changes': [
{
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': subdomain,
'Type': 'A',
'TTL': 300,
'ResourceRecords': [{'Value': workspace_ip}]
}
}
]
}
)
except Exception as ex:
route53_client.change_resource_record_sets(
HostedZoneId=hostedzone,
ChangeBatch={
'Changes': [
{
'Action': 'UPSERT',
'ResourceRecordSet': {
'Name': subdomain,
'Type': 'A',
'TTL': 300,
'ResourceRecords': [{'Value': workspace_ip}]
}
}
]
}
)
return {
"allow": True,
"error-msg-on-failed-posture-compliance": f'Successfully started WorkSpaces for user {username}',
"posture-compliance-statuses": [],
"schema-version": "v2"
}And for this configuration, we asked our employees to do the following
- Install OpenVPN client on iPad
- Import configuration files into the OpenVPN client (distributed via email)
- Install RD Client on iPad
- Add PC to RD Client
- Host name: .user.workspaces
When employees connect, we decided to have them connect to Client VPN via OpenVPN and then connect to WorkSpaces via RD Client to RDP.
No one stumbled as unexpected and the deployment was smooth.
This seems to work for now, so we will see how it goes.
I hope this will be helpful to someone else.