Veterinary Practice Remote Access for MSPs: Reach the Cornerstone Server, Imaging PACS, and Cameras Without Opening Ports

A veterinary practice runs on a small stack of machines that most clinics keep on one flat network behind a consumer router with a dynamic IP. The practice management system, the digital X-ray and ultrasound images, the in-house lab analyzers, and the ward and kennel cameras are all on site. When a server will not start before the first appointment, an imaging workstation loses its link to the modality, or a camera feed drops overnight, someone on your team has to reach that network. This guide shows how to give your engineers browser access to every device in a vet clinic over one outbound tunnel, with no static IP, no open ports, and nothing installed on the clinical machines.

What you actually need to reach in a vet clinic

The core of the practice is its management system, and a large share of clinics still run it on-premise. IDEXX Cornerstone, one of the most widely used, is a Windows, server-based product that runs on an onsite server by default; IDEXX publishes recommended settings for hosting it on Windows Server 2019 and 2022. Around it sit the digital radiography or ultrasound modality and the imaging workstation that drives it, the in-house diagnostic analyzers that feed results back into the record, an NVR watching the wards and kennels, and the file server or NAS holding backups and images.

Almost none of these should ever answer an unsolicited connection from the public internet. Exposed RDP to the practice management server has been one of the most common ransomware entry points for years, and the imaging tier is no safer: digital imaging moves over DICOM, which answers on TCP port 104, and security researchers have repeatedly found PACS systems left reachable on that port with no authentication in front of them. The safe posture is the obvious one: keep every one of these on the LAN with no route in from outside. That leaves the MSP with the familiar bad choices. Forwarding 3389 or 104 publishes the exact service attackers scan for. A per-engineer client VPN is heavy to roll out across every clinic and still has to route the clinical network at the far end.

One tunnel covers the whole clinic

ProxyLink works from the inside out. You install one WireGuard tunnel on the clinic's router or gateway: a MikroTik, a pfSense or OPNsense box, an OpenWrt or EdgeRouter, or any Linux host down to a Raspberry Pi. The tunnel dials outbound to ProxyLink and holds itself open with a keepalive, so the clinic never accepts an inbound connection, needs no static IP, and works fine behind the carrier-grade NAT most small-practice broadband now uses. You declare the LAN, and any separate VLAN the cameras or imaging sit on, as subnets on the tunnel, and every device on those networks becomes reachable with nothing installed on it.

The links you create

With the tunnel up, you create a proxy link per service:

• Practice management server (RDP): a browser RDP session to the Windows server or the workstation running Cornerstone, with no RDP client to launch and port 3389 never exposed to the internet.
• Imaging and PACS workstation: browser RDP to the machine that drives the X-ray or ultrasound, or an HTTPS link to the PACS web console where the platform has one, so images can be pulled without the DICOM port ever facing outside.
• Ward and kennel cameras (HTTP/HTTPS or TCP): a link to the NVR or camera web UI to check on patients overnight, or a TCP link to the stream where you need the native app.
• Switch, file server and printers: HTTPS links to appliance web UIs, browser SSH to the switch, and the same tunnel reaches the NAS holding backups and the networked printers.

ProxyLink's default appliance mode rewrites the Origin and Referer headers so a device's same-origin check accepts the proxied request, the same handling that makes Synology, UniFi, and pfSense UIs work through it. If a console rejects it, one toggle flips the link to app mode.

What this looks like for an MSP

You manage many clinics, so each one is a client group, your engineers are granted only the practices they look after, and peer isolation keeps every clinic's traffic separate at the network layer. An engineer opens ProxyLink, clicks the clinic's Cornerstone server, and is on it in a browser tab with no VPN client to start. Every session is tied to an engineer identity, with the target IP, port, start time, and duration recorded, and access requires a ProxyLink login. SSH and RDP sessions can be recorded per link on paid plans when you want an audit trail of what ran on a practice's server.

The clinical machines keep zero open inbound ports and stay invisible to the internet scans that ransomware campaigns rely on. Traffic runs over open WireGuard, and the relay is hosted in the EU on German infrastructure with no third-party routing of the session, which matters when those servers hold client records and payment details. One tunnel per clinic replaces a tangle of per-device port forwards and per-machine remote tools with one outbound link that covers the whole site.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. Setup guides for MikroTik, pfSense, OPNsense, and Linux gateways are in the docs.