unprofessionals

In Royal it's called "secure gateway". I found this blog post:

http://blog.royalapplications.com/2015/04/21/new-feature-secure-gateway-ssh-tunnels/

There's no need to create the putty connection for the tunnels. Last time I checked, it worked well with Royal Ts

I was following this post and I'm also interested in this feature. I also went back to my Royal Tx installation and tried the tunneling there. I'm not sure your statement is correct that you need to create a tunnel object for each connection. In fact you can reuse the tunnel object there for all your connections and it will assign the local ports automatically. So in general, it would be cool if RDM can do the same...

Isn't Sandboxing enabled by default? If so, shouldn't you have made sure the fix at least works with the default settings?

In any case, it works with sandboxing disabled.

Still doesn't work for me unfortunately.

I made sure the "Modern" engine is selected.

Switching the RDP engine doesn't make a difference.

Here's the log file's contents:

[23:28:57:444] [13473:043c2000] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx

[23:28:57:444] [13473:043c2000] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA

[23:28:57:445] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - Attempting NLA security

[23:28:57:445] [13473:043c2000] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_DNS_NAME_NOT_FOUND [0x00020005]

[23:28:57:447] [13473:043c2000] [ERROR][com.freerdp.core] - unable to set TCP_NODELAY

[23:28:57:447] [13473:043c2000] [WARN][com.freerdp.core] - setsockopt() SOL_SOCKET, SO_KEEPALIVE

[23:28:57:447] [13473:043c2000] [WARN][com.freerdp.core] - setsockopt() IPPROTO_TCP, TCP_KEEPIDLE

[23:28:57:447] [13473:043c2000] [WARN][com.freerdp.core] - setsockopt() SOL_TCP, TCP_KEEPCNT

[23:28:57:447] [13473:043c2000] [WARN][com.freerdp.core] - setsockopt() SOL_TCP, TCP_KEEPINTVL

[23:28:57:447] [13473:043c2000] [WARN][com.freerdp.core] - setsockopt() SOL_SOCKET, SO_NOSIGPIPE

[23:28:57:447] [13473:043c2000] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3

[23:28:57:447] [13473:043c2000] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe

[23:28:57:447] [13473:043c2000] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure

[23:28:57:447] [13473:043c2000] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

[23:28:58:267] [13474:0fb94000] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx

[23:28:58:267] [13474:0fb94000] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: FALSE

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: FALSE

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_RDP

[23:28:58:269] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - Attempting RDP security

[23:28:58:272] [13474:0fb94000] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 0

[23:28:58:276] [13474:0fb94000] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 54: Connection reset by peer

[23:28:58:276] [13474:0fb94000] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure

[23:28:58:276] [13474:0fb94000] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]

[23:28:58:276] [13474:0fb94000] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

Note that this happens on all hosts that have been updated to KB4088787. Non-updated hosts are still reachable by RDM.

I'm unable to connect with RDP to any of my systems after installing MS's March 13 patches.

Maybe related to this: https://www.onmsft.com/news/marchs-patch-tuesday-update-will-fix-a-critical-vulnerability-in-microsoft-remote-desktop-protocol

Works fine with Microsoft RDP.

Any ideas?

I'm switching back and forth between Royla TS and RDM but looking at Royal, this feature has been added more than 2 years ago and is called "overview":

http://blog.royalapplications.com/2015/06/07/new-windows-feature-overview/

Admittedly, Royal Tx is not as feature rich as RDM but being more "lightweight" is sometimes quite nice, plus features like the overview push me more and more into using Royal Ts....

Thx for taking care of this quickly!

It's nice that you now support AppleScript for several actions like exporting entries. Unfortunately, there's a rather uncomfortable security issue in the current implementation.

It's possible to retrieve passwords and other confidential data even when the application is locked (File - Lock Application). So as long as an attacker has access to my computer he can get ahold of all my confidential RDM data, even when I explicitly lock the application to prevent this.

And of course, thanks to AppleScript this data theft can be automated quite nicely without requiring any user input whatsoever.

I suggest you move quickly to rectify this situation!

That's definitely an improvement!

It works pretty reliably in my LAN now, but still stalls for EC2 connections.

The session stays open, but I still can't do anything while a transfer is in progress (no mouse or keyboard input).

This happens against all my EC2 instances and while Microsoft Remote Desktop certainly has some input delay while transferring files, it at least responds.

Like previously mentioned I'm using t2.micro instances of Win2k12 R2 (also have some Win2k8 R2) which obviously aren't the fastest but the fact that it works so much smoother with Microsoft's tool is a pointer to a problem in RDM IMHO.

Hi,

I'm having issues with drive redirection on some of my servers.

I can browse the file system on my Mac just fine but when initiating a transfer it stalls the connection for almost half a minute and eventually errors out.

When I then go back to the redirected drive, I get another error and have to reconnect to gain access again.

See the attachments for both error messages.

Most of the time, I'm seeing this on servers that are outside my LAN (they are in fact EC2 instances) and transfering files larger than around 2MB.

When doing the same thing on servers that are inside my LAN the transfers are working most of the time but I can't do anything else while they are in progress. The connection basically freezes and resumes only after the transfer is complete. Obviously this is a major PITA when transferring large files.

Everything works fine for very small files, both on my LAN and WAN.

My LAN connection is 1Gbit and my WAN connection is 70Mbit.

The EC2 instances are freshly set up t2.micro Win2k12 R2 machines and I'm not having the issue with mstsc or MSRDP for Mac from the same machine.

Any ideas?

edited by unprofessionals on 5/19/2015

edited by unprofessionals on 5/19/2015

Gateway connections seem to be not working at all.

Tried against two different Remote Desktop Gateway servers (Win2k8R2 and Win2k12).

In both cases I get "The peer connection was lost". When running with the same configuration from Microsoft Remote Desktop for Mac, everything works fine.

thx, that worked!

It seems RDM for Mac doesn't like Umlauts in Usernames as I cannot logon with my user "Jörg" on a 2012 R2 server.

The error I get reads "Failed to connect to the host. Check your credentials and try again (10009).

Seems fine after deleting the layout file. I'll watch it over the next few days.

RDM's UI layout is somehow really broken on my Retina MacBook Pro Late 2013 running 10.9.2 (13C44) - see attached screenshot.

Everytime I try to create a folder in a vanilla installation (just downloaded V0.9.1.0) with the default local data source the app crashes.

Steps to reproduce:

- Download and install RDM Mac "Beta"

- Start RDM and wait 8 seconds (late 2013 MacBook Pro 15", fastest config) for the app to become responsive

- Click "Add Group/Folder"

- Enter something in the "Name" textfield

- Click "Create" button

- Crash

The app was in development for over a year and you haven't noticed this?

I'm sorry, but this is definitely not enough for a beta. It's an early alpha at best and should be tested internally first before letting users at it.

cheers,

jan

PS: The same happens for Credential Entries...

edited by unprofessionals on 10/30/2013