Some Notes on the Machines

For 10:

netsh advfirewall firewall set rule group="remote desktop" new enable=yes
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

For 7:

netsh firewall Set service REMOTEDESKTOP ENABLE
netsh firewall set service REMOTEAdmin ENABLE
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0

For XP:

netsh firewall set service remotedesktop enable
netsh firewall set service remoteadmin enable
reg ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v  fDenyTSConnections /t REG_DWORD /d 0

This occurs when there is a version mismatch between the client and server of SSH. When it occurs, the client will give the list of available methods provided by the server, e.g.:

$ ssh root@1.2.3.4
Unable to negotiate with 1.2.3.4 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

You’ll have to choose one. Here’s how:

ssh -oKexAlgorithms=diffie-hellman-group14-sha1 root@1.2.3.4

This is easily done in Local Group Policy, on the machine with the RDS licensing server:

Computer Configuration/
Administrative Templates/
Windows Components/
Remote Desktop Services/
Remote Desktop Session Host/
Licensing

In most supported versions of Windows to date, we browse here in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

change DWORD SecurityLayer to zero (0), and we’re done. In Server 2016, we have to change DWORD UserAuthentication to zero.

Remote Web Workplace. Certificates are verified AOK, and yet at the point of RDP, you receive a popup reading “Your computer can’t connect to the remote computer because no certificate was configured to use at the Remote Desktop Gateway server. Contact your network administrator for assistance.”

To fix this, you’ll need the Remote Desktop Gateway Manager. If you have it, it’s in Start, Administrative Tools, Remote Desktop Services. If you don’t have it, install it:

dism /online /Enable-Feature:Gateway-UI

Then:

1. Open the RDGM.
2. Right-click the server object, open properties.
3. Open the SSL Certificate tab.
4. Click Import Certificate.
5. Choose the correct certificate — it’s the Exchange list, if this is SBS — and click OK.

This was tough to find, but it appears current:

https://chrome.google.com/webstore/detail/citrix-receiver/haiffjcadagjlijoggckpgfnoeiflnem

Definitions and items:

• VPN stands for Virtual Private Network. A true VPN connects two different networks, using an encrypted “tunnel” through Internet or other non-private connectivity.
• SSL VPN as defined by OpenVPN (and its wrappers like Watchguard SSL VPN), is not a true VPN. It is an SSL-encryption agreement between devices, building either a TCP tunnel or a UDP dataflow, over which tightly controlled network redirection traffic is distributed.
• This means that the source and destination subnets, though not IPs, can be the same.

So let’s say that we need to give a PC which is sitting on someone else’s 192.168.1.0/24 network, an encryption-protected connection for RDP and file sharing, to the office Windows machine at 192.168.1.20. If SSL VPN were true VPN, this would require a subnet change at either the remote side or the home LAN, no further option. But it’s not, so we can do this:

1. Restrict the SSL VPN capability on the office side, to just the domain controller (e.g., 192.168.1.250) and the RDP destination (192.168.1.20).
2. Make sure that the IP of the device on the remote side, is not a duplicate of either the domain controller or the RDP destination on the office side. So it can’t be either 192.168.1.250 or 192.168.1.20.
3. We can do this by setting a static IP on the remote device; alternatively, we can change the DHCP subnet of the remote site. Either of these are vastly easier than changing subnets!
4. The only loose end left, may be network printing on the remote side. Just make sure that the printer’s IP is not any of the vitals at the office, and is IPv4, and it will work just fine. Some printers (generally consumer-grade) are defaulting to semi-proprietary IPv6 modes in their Windows configurations, and at least some SSL VPN configurations will not play ball; in this scenario you’ll want to convert the PC setup(s) to use v4.

This tool appears to be made for this, among several other things:

https://www.bitvise.com/tunnelier

Some firsthand reports:

https://superuser.com/questions/235395/automatic-ssh-tunneling-from-windows

There are a few others options on that page also.

If you’ve ever wanted an easier interface, here’s SmarTTY:

http://smartty.sysprogs.com/

Try this:

https://www.zoho.com/assist/