Law Firm Remote Access for MSPs: Reach the DMS, File Server, and Scanners Without Opening Ports

A law firm is one of the most confidentiality-sensitive networks an MSP will ever manage, and most of what matters sits on infrastructure you can never casually expose to the internet. The matter files, the client correspondence, the billing records: much of it lives on an on-premise document management server, a file server or NAS, and the network scanners that feed paper into the system. When a partner cannot open a document, a scan-to-folder path breaks before a deadline, or the DMS server needs a patch, someone on your team has to reach that network, and the usual ways of doing it are the ways firms get breached.

This guide shows how to give your engineers browser access to every server, document management console, scanner and NVR across your law firm clients over one outbound tunnel, with no static IP, no open ports, and no agent on the sensitive boxes.

Why a law firm network is dangerous to expose

Lawyers carry a professional duty of confidentiality over client information, and for firms handling the data of EU residents the GDPR sits on top of it, so a breach of the firm's systems is not just an IT incident, it is a breach of client confidence. That makes the question of how your team reaches the network one the firm's own obligations depend on.

The systems you need to reach are the ones you least want online. A firm's document management system is often still on-premise: an iManage Work server, for example, runs on Windows Server with SQL Server behind it, and a Worldox deployment is server-based in the same way. Cloud platforms such as NetDocuments remove that server, but plenty of firms still run an on-premise DMS and a file server on site. The one thing all of these share is that their management interface should never answer an unsolicited connection from the public internet. Exposed RDP in particular has been one of the most common entry points for ransomware for years, and a law firm's file server is exactly the prize those campaigns look for.

So the servers get locked down with no route in, and the MSP is left with two poor options. Forwarding RDP or a web admin port publishes the exact service attackers scan for. A per-engineer client VPN is heavy to roll out across every firm you support and still has to route the right internal subnet at the far end.

Reach the whole firm network through one tunnel

ProxyLink works from the inside out. You install one WireGuard tunnel on the site'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 site never accepts an inbound connection, needs no static IP, and works fine behind carrier-grade NAT. Declare the LAN, and any additional VLANs, as subnets on the tunnel, and every device on them becomes reachable with nothing installed on the servers themselves.

The links you create

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

• Remote desktop to the DMS and application servers: an RDP link opens the Windows server running iManage, your practice management software, or the file server in a browser tab, with no VPN client and no RDP client on your laptop. RDP and SSH sessions can be recorded per link on paid plans when you need an audit trail of who did what on a client's server.
• Web consoles (HTTPS): an HTTPS link reaches the admin UI of the NAS, the firewall, or a scanner or MFP's embedded web server. ProxyLink's default appliance mode rewrites the Origin and Referer headers so a device's built-in same-origin check accepts the proxied request, the same handling that makes Synology, UniFi and pfSense UIs work through it.
• Browser SSH: for any Linux host on the network, a browser SSH terminal puts you on the shell with nothing installed locally.

The same tunnel also covers the firm's NVR, door cameras, and phone system, so the server room's failing disk is reached the same way as reception's phone fault, not with a different tool for each class of device.

What this looks like for an MSP

One tunnel per firm covers the office LAN and every VLAN you declare through the same peer. An engineer opens ProxyLink, clicks the client's server, and is on it in a browser with no VPN client to launch. Every session is tied to an engineer identity, with the target IP, port, start time and duration recorded, and access requires a ProxyLink login. The firm's servers keep zero open inbound ports and stay invisible to the internet scans that ransomware relies 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.

Access is scoped through the team model: each firm is a group, engineers are granted only the clients they look after, and peer isolation keeps every firm's traffic separate at the network layer. A new matter does not create a new remote-access headache, and a departing engineer loses access in one place.

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.