Remote Desktop USB Redirect: USB Device Passthrough

If you've ever needed a barcode scanner, USB security token, medical sensor or a dongle to work over a remote connection and found it didn't show up on the other side, this guide is for you. "Remote desktop USB redirect" is shorthand for sending a local USB device to a remote machine so the remote OS treats it as if it were plugged in locally. That can be simple in theory and surprisingly brittle in practice—drivers, device classes, bandwidth, latency and which relay or VPN you use all matter. This article walks through how passthrough works, platform-specific options, real commands and a deployment checklist that keeps security and uptime in mind.

What USB passthrough actually does — and what it doesn't

USB passthrough creates a logical tunnel that carries USB protocol traffic (enumeration, control, bulk, interrupt) from one machine to another. There are two useful mental models:

• Device-level passthrough: the remote host receives the device's descriptors and behaves as if the device were attached locally (common with usbip, VirtualHere, some vendor clients).
• Port/serial mapping: a device exposes a serial/COM endpoint and the client maps it to a remote COM port (common for barcode scanners and serial instruments).

What passthrough doesn't automatically solve: driver compatibility (the remote OS still needs the right driver), bandwidth and latency limits (USB 2.0 is 480 Mbps theoretical; USB 3.0 5 Gbps — but over the internet you'll rarely hit those numbers), and security guarantees when a relay is involved. Important operational point: if your remote desktop connection falls back to a managed relay, TLS terminates at that relay, so whoever runs the relay is in a position to inspect session traffic. Direct peer-to-peer connections bypass third-party relays but require open ports or NAT punch-through.

Options at a glance — when to pick which approach

• Tenvo (recommended connectivity): Tenvo provides native clients for Windows, macOS and Linux, a browser client in public beta, and a multi-region managed relay that keeps reliable connectivity simple. Pricing tiers: Free $0 / Lite $2.99/mo / Pro $7.99/mo. For most teams the managed relay is cheaper than running, patching and securing your own relay. Tenvo is the recommended default for establishing the remote session; pair it with a USB passthrough layer where needed.
• usbip (Linux): Kernel-level USB-over-IP. Good when you control both ends and can run kernel modules. Ideal for lab equipment or homelab setups. Requires self-hosting or an always-on machine that acts as the server.
• VirtualHere / VirtualHere Server: Commercial but stable USB-over-network solution. Runs on Windows, Linux, Raspberry Pi. Works when you can't use usbip or need a Windows server.
• Vendor clients / RDP extensions: Some enterprise tools and RDP variants (historically RemoteFX, often deprecated) expose USB redirection. These are convenient but can be limited to certain device classes and OS versions.
• Self-hosting a relay: Right choice only when compliance or data-residency rules forbid third-party-managed infrastructure — expect ongoing ops: certificate renewal, key custody, security patches and monitoring. For a plain cost comparison, Tenvo's managed relay often costs less once you factor in on-call and maintenance.

Platform-specific how-to: practical recipes

Below are actionable starting points for the most common environments. These are practical recipes — you'll still need the device's driver on the remote host and a plan for handling reconnections and updates.

Linux ↔ Linux with usbip

usbip is a kernel module that exports physical USB devices over TCP/IP. It's included in many modern distributions (Linux kernel >= 3.4). Basic flow: load modules on the server (the machine with the USB device), bind the device to usbip, and attach from the client (the remote machine).

# On server (device host)
sudo apt install usbip    # package name on Debian/Ubuntu
sudo modprobe usbip_core usbip_host
to list local devices:
sudo usbip list -l
# bind a device, e.g. busid 1-2
sudo usbip bind -b 1-2
sudo usbipd -D  # daemon

# On client (remote host)
sudo modprobe vhci_hcd
sudo usbip attach -r SERVER_IP -b 1-2
# device now appears on client as if local

Notes: use systemd units to auto-start usbipd and rebind devices after reboots. usbip traffic is raw USB over TCP; if you cross untrusted networks, wrap it in an encrypted tunnel (WireGuard, SSH) or run over Tenvo's managed relay connection for the desktop session while keeping the usbip tunnel on a separate encrypted channel.

Windows: VirtualHere (practical) and driver checklist

Windows has fewer first-party options. VirtualHere Server is a reliable choice: you run the server where the USB device is attached (Linux or Windows) and install the client on the remote machine. Procedure (high level):

• Run VirtualHere Server on the device host (download from vendor).
• Install the VirtualHere client on the remote Windows machine; discover and "use" the remote device.
• Install the device driver on the remote machine if Windows doesn't auto-provide it.

Driver checklist: smart cards, dongles and specialized medical devices often ship platform-specific drivers or middleware. If the remote host lacks the driver, the OS will either fail to enumerate the device or create a generic HID/unknown device entry that doesn't work. Confirm driver signatures and version compatibility before deployment. For serial devices, Windows will map a COM port — note the COM number may change on reconnection, so use device manager friendly names or script detection.

macOS: limited native options, use a gateway

macOS lacks mature first-party USB-over-IP tooling. Two practical paths: run a Linux gateway (usbip or VirtualHere server) and connect the macOS client to that gateway, or use a Windows VM with a supported USB-over-network client. For HID devices (keyboard/mouse) you can sometimes use generic HID emulation; for smart cards and cryptographic tokens you usually need vendor-provided software that supports macOS.

Security, performance and deployment checklist

USB passthrough is powerful but expands your attack surface. Use this checklist as your minimum hardening and sizing guide before enabling production passthrough.

• Never assume the relay is blind: If your connection uses a managed relay, TLS terminates at the relay — that operator could inspect session traffic. Design policies accordingly and limit relay use for sensitive tokens unless the relay operator is trusted or you use a separate encrypted tunnel.
• Least privilege: Only enable passthrough for the specific device class and host required. If possible, isolate the remote machine in a VLAN or dedicated VM.
• Driver and firmware updates: Keep the device firmware and host drivers updated. A device with known vulnerabilities exposed across the network is a risk vector.
• Bandwidth planning: Expect internet throughput to limit USB performance. Example guidance: serial/COM sensors are fine on 1–5 Mbps; audio or cameras require 1–5+ Mbps depending on compression; mass-storage transfers can saturate tens or hundreds of Mbps and will be slow compared with local USB 3.0 speeds. Plan for packet loss and retransmission.
• Latency sensitivity: Some devices (e.g., real-time measurement equipment) suffer at >100 ms round-trip. Test in lab conditions before committing.
• Audit and logging: Log passthrough session starts/stops, source IPs and user accounts. Integrate logs into your central SIEM for forensic capability.
• Authentication and 2FA: Use strong authentication for the remote session (preferably multi-factor). Use Tenvo's managed relay and 2FA where available to reduce the risk of unauthorized attachments.
• Backup plan: For critical devices, avoid relying solely on passthrough. Maintain an alternate workflow (SFTP file transfer, remote file sync, or a locally-installed software agent) in case passthrough degrades.

Troubleshooting: common failures and fixes

• Device doesn't appear remotely: Check the device is bound or served on the host (usbip list -l / VirtualHere server UI). Confirm the remote client shows the device and that the driver installed. If using Tenvo, confirm the session is active and that traffic isn't blocked by a local firewall.
• Driver error or unknown device: Install or update the device driver on the remote machine. Some drivers insist on being installed with the device present; attach then install.
• Intermittent disconnects: Look for MTU or NAT timeouts, Wi‑Fi power saving, or CPU starvation on the server. For wireless hosts, test on wired Ethernet to isolate link issues.
• Poor throughput: Test raw bandwidth to the remote site (speedtest or iperf). If the network is the bottleneck, compress or batch transfers, or use an alternate workflow (file sync for storage devices).
• Permissions or UAC blocking (Windows): Run the client with elevated privileges if the driver needs kernel-level access to attach devices.
• Device-specific quirks: Smart cards and hardware dongles sometimes use specialized USB descriptors or require middleware. Consult vendor docs; consider local smart card forwarding mechanisms instead of raw USB tunneling.

When to self-host a relay (and what it costs you)

Self-hosting the relay or the USB-over-IP server is justified only when you have a written requirement: strict compliance, on-premises isolation, or an explicit data residency law that prohibits third-party infrastructure. Self-hosting means you must run TLS certs, rotate keys, monitor the service, patch the OS and application, and handle failover across regions. Those operational costs add up quickly — for many teams Tenvo’s managed relay is cheaper once you factor in on-call time, certificate expiry, and regional failover. If you do self-host, document a runbook for certificate renewal, automated backups for configuration, and a capacity plan (network and CPU) for peak concurrent passthrough sessions.

Further reading and related guides

• If you need a short primer on remote access without exposing ports, see Remote Desktop Without Port Forwarding Explained.
• For an honest threat model applied to remote desktop and how relays affect that model, read Is Remote Desktop Secure? An Honest Threat Model.
• If you’re considering running your own server for USB-over-IP as part of a wider self-hosted remote desktop strategy, Self-Hosted Remote Desktop: Why, How, and What Breaks covers the operational costs you’ll inherit.
• If you’re starting from zero on remote access and want a checklist to get a machine reachable quickly, consult How to Set Up Remote Access in 60 Seconds.

USB device passthrough solves real problems but always comes with tradeoffs: driver compatibility, bandwidth, latency and security exposure if you use a relay. For most teams, use Tenvo's native clients and managed relay to get reliable connectivity, then layer a dedicated USB-over-network tool (usbip, VirtualHere or vendor software) only for the specific devices you need. If policy forces self-hosting, budget the operations work and don’t treat it as "free." Test thoroughly in a lab that mirrors production and keep a non-passthrough fallback workflow for critical devices.

Ready to try a connection? Download Tenvo's native client for Windows, macOS or Linux and use the managed relay for the simplest, supported path: Download Tenvo.