Warehouse and Logistics Remote Access for MSPs: Reach the WMS, Label Printers, and Scanner Fleet Without Opening Ports

A warehouse or distribution center runs on infrastructure an MSP can rarely put an agent on, and almost all of it is equipment you never want facing the internet. The warehouse management system drives every pick, pack, and ship, the handheld scanners talk to a wireless controller, labels come off networked industrial printers, and conveyors are run by controllers with their own operator panels. When the WMS server needs a patch before the first shift, a print queue jams, or half the scanner fleet drops off the wireless, someone has to reach that network, and the usual ways of doing it are the ways sites get breached.

This guide shows how to give your engineers browser access to every server, printer, controller, and camera across your warehouse clients over one outbound tunnel, with no static IP, no open ports, and no agent on the equipment.

Why a warehouse network is hard to reach and dangerous to expose

A distribution site is usually segmented for good reasons. The scanner fleet sits on its own wireless VLAN, the cameras on another, the office PCs on a third, and the operational gear (controllers, printers, dock and door hardware) somewhere it should never be reachable from outside. The WMS itself is often an on-premise Windows server, and its management interface is exactly what ransomware campaigns scan for: exposed RDP has been one of the most common entry points for years, and a warehouse that cannot ship is losing money by the hour.

Most of the devices cannot run remote-access software at all. An industrial label printer answers on an embedded web server (a ZebraNet print server, for instance, serves its configuration pages over HTTP on port 80), a line controller or wireless LAN controller has a web admin UI, and an NVR streams over its own port. None of them will host a TeamViewer or AnyDesk agent, because there is no general-purpose operating system to install it on. So the site gets locked down, and the MSP is left with two poor options: forward a port, which publishes the exact service attackers hunt for, or roll out a per-engineer client VPN to every site and still route the right internal subnet at the far end.

Reach the whole warehouse 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 main LAN and each additional VLAN (scanners, cameras, operations) as subnets on the tunnel, and every device on them becomes reachable with nothing installed on the equipment itself.

The links you create

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

• Remote desktop to the WMS and application servers: an RDP link opens the Windows server running the warehouse management system or the domain controller 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 touched a client's server.
• Web consoles (HTTP or HTTPS): an HTTP or HTTPS link reaches the admin page of an industrial label printer, a line or wireless LAN controller, or an NVR. 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, managed switch, or gateway on the network, a browser SSH terminal puts you on the shell with nothing installed locally.
• TCP and UDP services: because ProxyLink also proxies raw TCP and UDP, the same tunnel can carry a thick-client management tool or a device protocol to the target. TCP and UDP links are tied to the tunnel for security and must have one.

What this looks like for an MSP

One tunnel per site covers the office LAN and every operational VLAN you declare through the same peer. An engineer opens ProxyLink, clicks the client's WMS server or a jammed printer, 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 site keeps zero open inbound ports and stays 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 warehouse is a group, engineers are granted only the sites they look after, and peer isolation keeps every client's traffic separate at the network layer. One depot or a dozen, a scanner outage and a server patch are reached the same way, from a browser, not with a different tool for each class of device.

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.