Probing a port for RDP

Question

I use an ssh tunnel to RDP into my home computer ("home").

Occasionally, the tunneling software running on home crashes and the RDP port stops getting tunneled. I've attempted to resolve this by scheduling a script on home to run every 15 minutes that runs "netstat -tln" on my router and restarts the tunneling software if the tunneled RDP port is no longer open.

Unfortunately, occasionally the crashes are such that the RDP port remains open and accepting connections, but doesn't tunnel any traffic. E.g. the port remains open according to netstat and if I attempt to telnet into the port, it connects and shows me a blank screen. If I attempt to RDP through the tunnel, the session connects but spins on "Configuring remote session".

Bottom line: I'd like my "watchdog" script to actually attempt to connect to the RDP port to determine if the tunnel is still good. How do you probe a port to test if it's an open RDP port?

I'm thinking the ideal test is actually probing the port for RDP, but I'm also open to other ideas.

Solution

I figured out an easy way to do it. When my script executes the netstat command on the router to verify that the RDP tunnel is open, I can also send an RDP connection request over the tunnel using netcat!

This is the command I used to send the connection request packet. I grabbed the packet itself from the example connection sequence in Microsoft's RDP specification.

echo -ne '\x03\x00\x00\x2c\x27\xe0\x00\x00\x00\x00\x00'\
'Cookie: mstshash=eltons\r\n'\
'\x01\x00\x08\x00\x00\x00\x00\x00' |
nc -w 5 localhost 6000 |
xxd -p |
xargs -0 printf 'RDP response: %s\n'

The tunnel is over port 6000. The netcat command has -w 5 so that the connection will be closed if a response is not received within 5 seconds. xxd converts it to a simple hex string and I prefix xxd's output with RDP response: so my script can easily scan for this line in the output.

If the RDP server is listening, I will receive output similar to this.

RDP response: 030000130ed000001234000209080000000000

The only other validation I do is look for the byte 02 at offset 11 to verify that it is an RDP packet that includes a TYPE_RDP_NEG_RSP (RDP negotiate response) structure.

Fixing the crashes would be the obvious solution, but I've had the tunneling software crash in several different ways and I'm not doing anything unusual with it. The software I'm using is BitVise SSH Client. I'm using the latest version and with some Googling I haven't found anyone else that has similar problems. It only crashes once every few days or weeks, but it's frustrating attempting to RDP into my computer to find out that it's not accepting connections and there's nothing I can do about it until I get home.

Comments

[I say Reinstate Monica]

It might actually be easier to fix the root problem, namely, fix the tunneling software crash.

[Tmdean]

@Twisty Thanks for the idea. I've addressed it in my answer.

[I say Reinstate Monica]

Nice solution. Way to put effort into solving the problem.