RDP at home is fine.

@dbeato Has to be at least related because disabling it works

Is Remmina ceashing when RDP to older servers like Server 2008 R2? That’s the only server giving me issues with Remmina. Try freerdp or rdesktop through command line and see if you have a better experience.

@dafyre said in Remote Desktop to Fedora 28?: @black3dynamite said in Remote Desktop to Fedora 28?: @dafyre said in Remote Desktop to Fedora 28?: @black3dynamite said in Remote Desktop to Fedora 28?: @dafyre said in Remote Desktop to Fedora 28?: I just did a fresh install of Fedora 28 to update my instructions for this, however, I've discovered the by default Fedora 28 has switched to Wayland, and there's no working VNC server that I am aware of that works with it. This may be part of the problem. Its been default to Wayland for awhile but you can switch it to Xorg. Yeah. Now I just need to figure out how to switch the greeter to X and I'll be happy. Under [daemon] section in /etc/gdm/custom.conf uncomment #WaylandEnable=false to force the login screen to use Xorg. At the login screen, you will now only have two choices GNOME which is now Xorg instead of Wayland and GNOME Classic. That got me pointed in the right direction! Thanks. I've got it working well enough when the user is logged in... but the catch is that you have to log in after a reboot before being able to use XRDP+VNC.

Thanks.

@dbeato said in Disable Network Level Authentication or NLA Remotely via PowerShell: @scottalanmiller said in Disable Network Level Authentication or NLA Remotely via PowerShell: (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -ComputerName "remoteServer" -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(0) This worked, but also as soon as the server is updated to the latest then the issue goes away. Yes, if you have that option.

This might be useful for some people: https://mangolassi.it/topic/17197/disable-network-level-authentication-or-nla-remotely-via-powershell

Hello. I tried rdp connection to the server by entering the ip address with relative port (192.168.1.66:1512) and it worked. I do not understand why the problem occurred with the installation of the latest Windows 10 release (April 2018). thank you. regards.

Here is the one thing that will shut the dumbasses up about RDP being "insecure". Multi factor authentication. Microsoft even supplies wonderful application for it. https://azure.microsoft.com/en-us/services/multi-factor-authentication/ Eliminates all the shit password problems, even if its 'password', has a mobile app to just hit a button to approve login, and is pretty easy to set up to boot.

Take a look at this as well https://docs.microsoft.com/en-us/windows/client-management/connect-to-remote-aadj-pc

@Dashrender said in Unable to connect to RDP: @JaredBusch said in Unable to connect to RDP: @Dashrender said in Unable to connect to RDP: @JaredBusch said in Unable to connect to RDP: @Dashrender said in Unable to connect to RDP: Does it work from a computer on the same network at the server? Looking to see if it's an ZT problem or a Server problem. Same error over normal IP also once I brought up my IPSEC tunnel OK but you still haven't tried from another PC on that network - i.e. no VPN. Does not matter. No one connect on network. Also two differnt IP protocols do not work. Issue is not whatever the hell you are driving at. two different IP protocols? /sigh... IP subnets.

@DustinB3403 said in RDP support for VMs or Console only Access: Opening up RDP access (not necessarily from the Internet) but in general just opens more ports, more firewall changes etc. Sure, but granting unnecessary access to the console does that, too. You need access to the VMs from far more places than you need it to the console.

Remmina is a great tool. I've had excellent luck with it.

@Dashrender said: @dafyre said: @Dashrender said: @scottalanmiller said: @FATeknollogee said: @Jason said: @FATeknollogee said: Type 3: Users (are contractors), they connect via VPN from overseas Seems like a bad idea. Usually employees are given VPN access from company owned devices. a VPN is too much exposure for non-company owned devices and for people who aren't full employees. I would look into some other form of access, RD Gateway with RDS or Ctirix etc for these people. Are you saying access via ZT is not a good idea? Correct. ZT is a VPN. VPNs from arbitrary devices is normally a bad idea. The only exception to this is when you would have happily exposed the LAN to the Internet and this is purely a handy control of IP addresses. If security is your goal, you are bypassing security using a VPN in this role. VPNs are very dangerous because they are about exposure. The whole trusted network issue. LAN vs LAN-less As more and more things move to networks that are not local to our computers, we're changing seeing how we trust things. Traditionally we trust machines that are on our local LAN, but, if flip that on its ear and trust nothing, and always setup authenticated/trusted communications no matter where device is in comparison to us, then we are much safer. I think that it is beyond time that we stop trusting machines on our local lan. Even my home network has the service discovery disabled, and each machine has its firewall turned on for that very reason. I go back and forth on using the home networking features that Windows has these days. I use them because they are there. I also have linux boxes at my house too, so there's that.

@stacksofplates Btw Centos got updated to: CentOS 7.4 (1708) CentOS Linux release 7.4.1708 (Core) https://wiki.centos.org/Manuals/ReleaseNotes/CentOS7?action=show&redirect=Manuals%2FReleaseNotes%2FCentOS7.1708 Noteable mentions At least 1024 MB RAM is required to install and use CentOS-7 (1708). When using the Live ISOs for install, 1024 MB RAM produces very slow results and even some install failures. At least 1344 MB RAM is recommend for LiveGNOME or LiveKDE installs. The initramfs files are now significantly bigger than in CentOS-7 (1503). You may want to consider lowering installonly_limit in /etc/yum.conf to reduce the number of installed kernels if your /boot partition is smaller than 400MB. New installations should consider using 1GB, which is now the upstream recommended, as the size of the /boot partition. Sadly Centos 7.4 does not work with this guide Damn

@dafyre said: Cool. A few months back, I stumbled across MobaXterm and snagged it when I had a few extra bucks. I'll keep my eyes on RoyalTS for sure, though. Just checked MobaXterm and i really like it. My most favorite option as of now is the file explorer & shell on the same window. Helps me a lot if i need to edit some text files, copy files to and from the desktop etc at the same time while executing other commands.

With so many services starting up, there is a lot of chances for things to have not all fired up yet.

Is say so!