Closed Tigger2014 closed 2 years ago
This seems related to #10 as i get a similar error from the office MS android app, where as from a windows 10 client i get the above error
Hi @bolkedebruin , we would love to use your project, as there really seems to be no alternative as a free rdp gateway. Thanks a lot for your work.
The setup worked flawlessly, including the connection to oidc with Keycloak as the provider. I also managed to establish connections from Linux systems with Remmina. However, for all connection attempts from Windows systems with MSTSC, I keep running into the error shown above.
Are connections from MSTSC generally not possible, or are there certain configuration parameters that need to be considered? I would be very happy about a tip or hint.
Hi @fxkk we deploy this gateway with over 1000 concurrent users that use MSTSC on Windows 10. Your connections are failing in a very early stage of the protocol. Typically this means that there is a proxy in between that is doing some mangling or a type of firewall (local or otherwise). While I haven't tested it, Remmina only started supporting RDP gateways in 1.4.21 and websockets in 1.4.17. Have you tried the latest version and does the gateway report a websockets connection in the metrics or a legacy connection?
Further, to debug this I would need the decrypted streams between the client and the endpoint. But before that, I suggest having a setup as clean as possible and test with the latest Remmina with Websockets enabled (it is disabled by default). I have tested against MSTSC and the MS Mac Client they have websockets enabled by default.
First, thank you very much for your advice, I wanted to answer much earlier, but it took me a while to make new tests with your suggestions.
In fact, when I first tried it, Remmina's websocket feature was still disabled and a legacy connection was established.
Yet, Remmina can establish a connection even with Websocket mode enabled.
After you reported that the application is mainly tested and run by windows clients and I just can't manage to connect to it with one, makes me a little bit unsure. I'm afraid all the time that I've overlooked something trivial, but I just can't figure it out.
After you suggested it might be the proxy, I verified that again and removed the proxy from the equation. In the production environment there is a Traefik in between, the test setup I used to run the new tests locally looks like this:
To me, it looks like the problem is the first application data going through the websocket tunnel. I unfortunately can't see what is supposed to happen there either.
I made recordings of both connection attempts with Wireshark, if you have time to look at them, you can find them as an attachment.
Unfortunately, I'm not very experienced in Go, and I've reached my limits trying to understand exactly where the error is thrown.
A colleague had the idea if it could be the utilized certificate and mstsc may require special flags to make the use for an rdp gateway permissible. But I haven't verified this theory yet.
If anyone has further ideas where the error could come from, I am always happy to receive hints and try them out.
I have similar problems. However, I actually have an Nginx upstream. I have already adjusted the config:
proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade";
Unfortunately, the whole thing does not work. I would be interested to know if anyone has already connected a reverse proxy upstream and if the whole thing works.
@fxkk unfortunately, there s not enough information in the key files to decrypt the whole stream. Only a very limited part of it can be decrypted.
What you can do to capture it from the container is to set SSLKEYLOGFILE=/tmp/sslkey.log
as an environment variable and then either mount /tmp/sslkey.log
somewhere and copy that or do something like docker exec -it docker_rdpgw_1 tail -f /tmp/sslkey.log > /tmp/sslkey.log
I had exactly the same error message and after getting similarly confused that this must be an error on my part started to investigate. It looked like the server was closing the connection after receiving the handshake response for some reason. And then I found this bit of code and immediately realised my error: https://github.com/bolkedebruin/rdpgw/blob/bd103298280f4b4045292246060b2a2785e51ffe/cmd/rdpgw/protocol/server.go#L184-L186
I forgot to set tokenAuth: true
in my rdpgw.yaml
(and the default is false
)
caps:
tokenAuth: true
Adding this immediately fixed the problem and error messages for me. I'm not sure if this is the cause of you error (I was connecting from a MSTSC to a Windows server) but thought it worth sharing just in case.
@blu3id you saved my day. I tested the recommended setting today, and it immediately worked for me. In retrospect, a lot of testing and research for such a little tweak, but I learned a lot. Deep down I always thought that it must be a configuration Problem like this, a bug on this level made no sense when they are working setups like the one from @bolkedebruin himself. @bolkedebruin I really appreciate that you took the time to deal with the Problem. Thank you very much for your work. I'm really happy right now that I finally got it to work.
I have fixed this issue in master. The server will now report back if there is a capability mismatch.
trying to connect from windows MSTSC to a windows server getting the below errors