RDP encryption vs VPN encryption

Home Forums Virtualization Terminal Services RDP encryption vs VPN encryption

This topic contains 3 replies, has 3 voices, and was last updated by Blood Blood 3 months, 1 week ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author

  • raylward102

    I have 30 rdp hosts, port forwarded via SonicWALL on various ports (not standard 3389), for 15years and counting; Never had a problem. IT admins cringe when I explain my setup and wonder why? RDP has encryption built into it and the users are using strong passwords. Almost everyone I talk to, on the subject, immediately says it’s a no-no and should be using a VPN tunnel, because it’s encrypted (almost like everyone saying I’m running naked otherwise). I have audited our systems logs and seen the many bot’s, chewing away, trying to guess our passwords. Recently, I let an IT admin talk me into using our sonicwall SSL vpn; We did this and along the way had to explain to everyone why we made the changes; why we were making the remote access a little more cumbersome, adding a second step; At the end of the day, aren’t these hackers just re-focusing there attention on the hacking of my SSL VPN? What are your thoughts on this?

    James Haynes

    Pre-auth, network accessible, service running as SYSTEM

    if someone should want to mess with your stuff, they can brute force the open connection. a VPN prevents the brute force logon attempts.

    if you have 30 host at one location, you can create VPN tunnels for the entire network. if the people are spread, then VPN is the way to go.

    this shouldnt be too hard if you have a sonicwall in place. idk what your contract is, but you will only get 2 seats without the full security package.

    i wouldnt doubt that you have been being hit, but just not aware of it. its usually a matter of time before people figure out the ports are open, even less when you have DNS records that resolve to that site..


    Assuming your correct, in how they can brute force the connection open and how I’m totally unaware of breeches that probably occurred; you mean to say they gained access and did nothing for 15 years (we’ve had no issues and audited event logs support my theory, logs showing failures to allow access from these bots). A VPN requires a user & password to authenticate the tunneling connection; My question is, how is the VPN tunnel so much safer compared to the brute force against my windows machine?? Can’t the VPN be brute forced? I assume if I were to purposely log attempts to my vpn authentication, the same bots who were trying previously working against my windows hosts are now focusing their efforts on my SSL vpn authentication. Just seems pointless to add VPN as a second step that supposedly means all the difference.


    We have staff using remote desktop via VPN. Never used straight RDP. Our remote access entry is via a router (using NAT), not a Windows host. Staff accounts that use the VPN must also be members of a particular security group otherwise their VPN connection request is refused. I agree with the statement about brute-forcing a VPN connection request, but we also have password failure attempts limited to ten, meaning an attacker is prevented from trying to force an account’s credentials for 15mins. Seems to me the extra layer of encryption offered by the VPN coupled with the password attempt limit and the group membership requirement can only be good.

    I also did the same as the OP when we ran an FTP site from our network. I changed the incoming port and used NAT on the router to switch e.g. 55234 to 21 because 21 was being hammered by connection requests. I think that if you have substituted the public port for an obscure port number then you have gone a fair way to mitigate against brute force attacks on the standard port. Unless there are some out there who cycle through all 65,000 ports on their connection attempts…

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.