Remote Access for Dental Practices: Browser RDP to the Server Without Port Forwarding

Dental practices are a common managed-services client and one of the more awkward sites to reach remotely. The practice management software, the imaging system, and the SQL database all live on a server in a back office, the practice has a consumer router with a dynamic IP, and there is no on-site IT. When Dentrix will not open on Monday morning or a backup has stopped running, the engineer needs to be on that server in minutes, not driving across town.

This guide shows how to give your team browser-based access to a dental practice server and every device on its LAN, with no static IP, no open ports, and nothing installed on the workstations you are trying to reach.

Why Dental IT Is Hard to Reach

The three most common dental practice management platforms, Dentrix, Eaglesoft, and Open Dental, are all on-premise Windows applications backed by a SQL Server database. The data lives on a server in the practice, and the software is installed on each operatory workstation. The digital radiography and imaging capture stations are local too. Cloud platforms like Curve Dental or Dentrix Ascend do not need remote access to a server because there is no server. The on-premise systems are exactly the ones that do.

That leaves two traditional options, and both are bad. Forwarding RDP port 3389 through the router puts the practice server directly on the internet, and exposed RDP is one of the most common ransomware entry points there is. Installing a per-seat remote tool on every workstation is expensive and adds its own risk: TeamViewer and AnyDesk were both breached in 2024. Neither option reaches the router, the managed switch, or the cameras at all.

One Tunnel Covers the Whole Practice

ProxyLink takes a different approach. A single WireGuard tunnel sits at the practice, and the tunnel initiates the connection outbound to our relay. Because the connection is outbound, the practice needs no static IP and opens no inbound ports. The LAN stays dark, there is no listening service for a scanner to find, and a dynamic IP or ISP CGNAT makes no difference because nothing ever connects to the practice.

The ProxyLink gateway agent runs on MikroTik RouterOS or on Linux, so on a small practice the usual pattern is a Raspberry Pi or a small Linux box placed behind the existing router. That one gateway covers the entire LAN, and if the practice segments its network into VLANs you declare each subnet on the tunnel and they are all reachable through the same peer. Nothing is installed on the practice server or any workstation for this to work.

What the Engineer Actually Reaches

Once the tunnel is up, you create a proxy link for each device and service you need. The engineer opens a browser, clicks the device, and the session loads. No VPN client, no RDP client, no IP to remember. It works the same from a laptop, a tablet, or a phone.

• Practice server (RDP, port 3389): a full browser RDP session to fix the PMS, restart the SQL service, or check the backup job, with no mstsc.exe on your machine.
• Imaging and capture PCs (RDP or VNC): reach the radiography workstations without walking an operatory.
• Router, managed switch, and cameras (HTTP or HTTPS): a proxy link to the device web UI, no driver or client.
• Linux appliances (SSH): a browser terminal, with optional session recording on paid plans.

When There Is No Supported Router

Many practices run a consumer router that cannot host the gateway. For those, or when you only need the server itself, deploy the ProxyLink one-liner on the practice server:

irm https://app.proxylink.dev/deploy/<token> | iex

The token is single-use and expires in 30 minutes. The script installs WireGuard and a password-protected VNC service, then the machine registers its own hostname back to ProxyLink. You can push it across workstations with your RMM (NinjaRMM, Datto, or ConnectWise Automate) or by GPO. It is idempotent and it does not touch a practice's existing VNC or WireGuard install if one predates it: it only adds our path.

Patient Data and the Audit Trail

A dental practice holds patient records, so the smaller the attack surface the better. ProxyLink removes the inbound surface entirely. Traffic runs over open WireGuard, the relay is hosted in the EU on German infrastructure, and there is no third-party routing of the session. Every access is recorded: which engineer connected, to which device IP and port, when the session started, and how long it lasted. RDP and SSH sessions can be recorded per link on paid plans. That log is the evidence you need to show that access to patient systems was controlled and monitored.

Access is scoped through the team model too. The practice is a client group, engineers are granted only the sites they manage, and peer isolation keeps every customer's traffic separate at the network layer.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. A dental site takes well under an hour to bring online. Setup guides for MikroTik, Linux gateways, and the Windows deployment are in the docs.