How New Duo Feature Lets Users Skip the VPN Hassle
It’s a new ending to a familiar story of frustration for users trying to access internal company resources.
The Remote Desktop Protocol (RDP) feature for the Duo Network Gateway prompts users to authenticate only when necessary, instead of first having them try and fail, forcing them to try again after logging into the company’s virtual private network (VPN).
Now that this friction-reducing feature is in public preview, we wanted to share some inside perspective on how it works and what informed our design.
A Familiar Story
We are all very familiar with the current state of remote access with a VPN:
Try to access internal company website
Fail to access internal company website
Wonder why it’s failing for a moment
Log in to the VPN
Try to access internal company website again and hopefully succeed
The Duo Network Gateway (DNG), a VPN-less remote access proxy gateway, elegantly solves this problem for websites, streamlining the end user’s experience:
Try to access internal company website
Get prompted for authentication with your identity provider (IdP)
Get prompted for multi-factor authentication (MFA) with Duo
Proceed to internal company website
End users are only re-prompted to authenticate if their session expires or is terminated by an administrator.
A User-Centered Flow
We love this flow: Users do the thing they want to do, and they might get prompted to authenticate if necessary. We don’t love this flow: Users do the thing they want to do, but, if it fails, they have to think about what to do next.
For SSH connections, the DNG and DuoConnect (our lightweight client for remote access) can leverage the SSH client’s “ProxyCommand” capability, which allows administrators to modify SSH configurations and specify that certain connections should be using DuoConnect with some specific arguments.
With the DNG, connecting to an SSH server is as simple and frictionless as accessing a web server: after initiating the SSH connection the user will be asked to authenticate through a web page if needed. Otherwise, the DNG stays out of the way.
Unfortunately, other protocols — and RDP in particular — don’t have a comparable “proxy” option to specify a relay and a host (like SSH), and they don’t carry enough information to allow DuoConnect and the DNG to infer the destination and state of authentication for an incoming request (like HTTP(s)/web).
We’ve worked hard to replicate this seamless experience for RDP connections. With the new architecture, if a user (for example, Sally) wants to connect to their desktop (for example, sallys-desktop.example.local), which is inside the corporate network, they simply open their RDP client and connect to sallys-desktop.rdp.example.com. If they need to authenticate, a browser will pop up and ask them to do so. Otherwise, the connection is seamless. Notice that the hostnames used to connect here are different, which we’ll explain in the next few paragraphs.
How it Works
The DNG uses two components to make this work: relays and subdomains.
Similar to SSH relays, RDP relays serve as a point to relay traffic to the internal network and a point of authentication. You can protect multiple RDP servers behind one RDP relay, and the relay would have its own hostname (for example, rdp-relay.example.com).
Due to the absence of a “proxy” configuration, we rely on a subdomain being delegated to the DNG. You configure the DNG with an external/internal pair of subdomains, where the external subdomain is delegated by your main domain to the DNG, and the internal subdomain is one that is resolvable within the corporate network.
For instance, if the company name is “Example, Inc.” and it owns example.com, the domain administrator can delegate rdp.example.com to the DNG (via public DNS), and configure the DNG subdomains configuration to make rdp.example.com correspond to example.local.
When Sally attempts to connect to sallys-desktop.rdp.example.com, the DNG will receive the request, correlate it with the existing relay configuration and Subdomains configuration, assign a random temporary IP address to the name sallys-desktop.rdp.example.com, and send it back to the RDP client.
When the temporary IP assignment is received, the connection is internally routed to the installed DuoConnect. Upon receiving the connection, DuoConnect will contact the configured DNG to start the authentication process (if necessary) and tunnel the connection through the RDP Relay at rdp-relay.example.com.
If you’ve purchased Duo Beyond, you can participate in the public preview of RDP support for the Duo Network Gateway.