Hi,
I passed the proxy ip to the Microsoft Remote Desktop app as shown below, but the session is canceling the moment I connect to the proxy ip from Microsoft Remote Desktop.
Is there any way to use rdp with boundary cli on macOS?
Thanks
boundary connect -exec open -target-id $TARGET_ID -host-id=$HOST_ID --rdp://full%20address=s={{boundary.addr}}
Hi there,
It’s not entirely clear, but it sounds like you might be misunderstanding how Boundary operates. Can you send some more steps of what you’re attempting, ideally with screenshots?
But from what you’ve said so far… Be aware that the Boundary CLI or desktop app will be running on your Mac, where it will create a local proxy port through the Boundary Worker and to the Target, which would be the RDP server. The CLI/app shouldn’t need any information relating to RDP, only things like the host-id and target-id (I’m looking at the use of the rdp:// scheme in your example).
If you’ve configured Boundary correctly and made a connection via the CLI or app, then it should be as simple as pointing your local RDP client at localhost:{THE_BOUNDARY_PROXY_PORT}. There is no proxy IP that your clients will need, you’ll just point them to localhost; this would be the same for RDP, VNC, MySQL, Chrome etc…
More generally, Boundary only cares about setting up a connection between a user’s machine and a remote TCP port. Once that happens, it’s up to you what packets to throw across the connection, so RDP should work just fine.
I hope that helps!
Hi @DirectRoot
I tested two. Manually obtaining ProxyIP and connecting works fine. However, when I call Microsoft Remote Desktop using exec, I cannot connect.
If I use only the boundary connect command to obtain a proxy IP and connect, the connection is possible, but there is a disadvantage that the terminal window must be kept open.
Is there any way to solve this?
Thanks!
boundary connect -exec open -target-id ttcp_4nc4TC1oiO -host-id=hst_CKLtLpQuaN -- rdp://full%20address=s={{boundary.addr}}
Proxy listening information:
Address: 127.0.0.1
Connection Limit: -1
Expiration: Wed, 24 Nov 2021 09:33:49 KST
Port: 49812
Protocol: tcp
Session ID: s_IprUUw5aFs
boundary sessions read -id s_IprUUw5aFs
Session information:
Auth Token ID: at_L5eQM3IRGB
Created Time: Wed, 24 Nov 2021 09:32:09 KST
Endpoint: tcp://10.1.250.97:3389
Expiration Time: Wed, 24 Nov 2021 09:33:49 KST
Host ID: hst_CKLtLpQuaN
Host Set ID: hsst_zFW5E6R2VK
ID: s_IprUUw5aFs
Status: terminated
Target ID: ttcp_4nc4TC1oiO
Termination Reason: canceled
Type: tcp
Updated Time: Wed, 24 Nov 2021 09:32:33 KST
User ID: u_aUDwsaGg7P
Version: 3
Scope:
ID: p_LvatFT3cHg
Name: Windows
Parent Scope ID: o_z5skc7cbfr
Type: project
Authorized Actions:
read:self
cancel:self
States:
Start Time: Wed, 24 Nov 2021 09:32:33 KST
Status: terminated
End Time: Wed, 24 Nov 2021 09:32:33 KST
Start Time: Wed, 24 Nov 2021 09:32:09 KST
Status: canceling
End Time: Wed, 24 Nov 2021 09:32:09 KST
Start Time: Wed, 24 Nov 2021 09:32:09 KST
Status: pending
boundary connect -target-id ttcp_4nc4TC1oiO -host-id=hst_CKLtLpQuaN
Proxy listening information:
Address: 127.0.0.1
Connection Limit: -1
Expiration: Wed, 24 Nov 2021 09:38:59 KST
Port: 49833
Protocol: tcp
Session ID: s_pjcgGDp8GS
boundary sessions read -id s_pjcgGDp8GS
Session information:
Auth Token ID: at_mnQKozVn84
Created Time: Wed, 24 Nov 2021 09:37:19 KST
Endpoint: tcp://10.1.250.97:3389
Expiration Time: Wed, 24 Nov 2021 09:38:59 KST
Host ID: hst_CKLtLpQuaN
Host Set ID: hsst_zFW5E6R2VK
ID: s_pjcgGDp8GS
Status: active
Target ID: ttcp_4nc4TC1oiO
Type: tcp
Updated Time: Wed, 24 Nov 2021 09:37:48 KST
User ID: u_aUDwsaGg7P
Version: 2
Scope:
ID: p_LvatFT3cHg
Name: Windows
Parent Scope ID: o_z5skc7cbfr
Type: project
Authorized Actions:
read:self
cancel:self
States:
Start Time: Wed, 24 Nov 2021 09:37:48 KST
Status: active
End Time: Wed, 24 Nov 2021 09:37:48 KST
Start Time: Wed, 24 Nov 2021 09:37:19 KST
Status: pending
I think I understand what you mean now. I’m glad the second way works, but appreciate that the CLI would be good.
To check my understanding, I experimented on a local Debian VM running Xrdp. I was able to connect via the Microsoft RDP Client via the GUI, both with and without Boundary as the proxy. I was unable to connect at all using open... syntax, whether using Boundary or not. I also received the same error code you did when trying to make a session with -exec open.
There’s a recent forum thread of someone else trying and failing to connect using the Microsoft RDP App’s URI schemes and the open command. They suspect the app has been broken since Big Sur, so this could be your issue if you’re on a recent MacOS (I am and I think it’s what’s stopping me). Please confirm if open rdp://... works for you on a direct connection to a machine, without Boundary involved.
Thanks!
Hi @DirectRoot
After I got the Proxy IP using boundary connect, I confirmed that if I input the Proxy IP using the open command without going through the boundary, it works normally.
boundary connect -target-id ttcp_4nc4TC1oiO -host-id=hst_CKLtLpQuaN
Proxy listening information:
Address: 127.0.0.1
Connection Limit: -1
Expiration: Wed, 24 Nov 2021 12:44:21 KST
Port: 59758
Protocol: tcp
Session ID: s_14HhfIJzG4
open rdp://full%20address=s=127.0.0.1:59758
I was tired last night and was using the wrong URI format, I can now connect via open like you can.
I’m not a Boundary dev but I think the issue is the open command immediately gives a return code after it has completed opening a file or URI, so the Boundary CLI is then closing the session before the RDP app can use it.
Connecting using -exec bash and issuing a sleep after the open command, the RDP app opened and was able to connect with my test instance.
boundary connect -exec bash -target-id ttcp_1234567890 -host-id hst_1234567890 -- -c "open rdp://full%20address=s={{boundary.addr}} && sleep 600"
Weird side note: I couldn’t get open rdp://... to work with more than one URI param using & or the encoded %26. To get the RDP app to prompt me for credentials I can to create a .rdp file on the fly and open that.
boundary connect -exec bash -target-id ttcp_1234567890 -host-id hst_1234567890 -- -c "echo 'full address:s:{{boundary.addr}}' > /tmp/hello.rdp && echo 'prompt for credentials on client:i:1' >> /tmp/hello.rdp && open /tmp/hello.rdp && sleep 600"
I don’t know if there’s a more elegant way to make connect not close the connection when the exec command has returned.
It’s ugly, but I hope it helps, it certainly had me scratching my head!
thank you!
This works, but since I need to add a timeout, I think this bug should be checked by hashicorp.
I don’t have a MacOS system to test this on myself, but if the issue is open returning immediately, the -W flag may help:
-W Wait until the applications exit (even if they were already open).
Use with the -n flag to allow open to function as an appropriate app for the
$EDITOR environment variable.
(The -n flag opens a new instance of the app even if one is already open.)