← All posts

Warehouse and 3PL Remote Access for MSPs: Reach the WMS, Label Printers, and Scanners Without Opening Ports

Browser access to WMS servers, label printers, scanner APs and cameras across warehouse and 3PL sites over one WireGuard tunnel. No static IP, no open ports.

A warehouse or third-party logistics (3PL) site runs on a dense network that almost never has an engineer sitting next to it. The warehouse management system (WMS) server, the Wi-Fi access points the handheld scanner guns roam across, the label and thermal printers at every pack bench, the conveyor and sortation controllers, and the cameras over the dock doors are all on site, usually behind a basic broadband line with a dynamic IP or carrier-grade NAT. When the WMS will not come up before the first pick wave, a label printer drops off the network, or the scanner access points stop handing out addresses, someone on your team has to reach that site. This guide shows how to give your engineers browser access to every device in a warehouse over one outbound tunnel, with no static IP, no open ports, and nothing installed on the machines.

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

The heart of the operation is the WMS, and plenty of distribution centres still run it on an on-premise Windows server. That server is exactly the kind of box ransomware crews hunt for, because taking it down halts receiving, picking, and shipping at once. Exposed RDP has been one of the most common entry points into networks like these for years, and a warehouse that cannot process orders is losing money by the hour, which is precisely the leverage an extortion crew wants.

The reaching problem is just as real. Warehouses and 3PL sites are often on cheap commodity broadband, frequently unmanned out of hours, and increasingly sit behind carrier-grade NAT with no public IP to forward to at all. That leaves the MSP with the familiar bad choices. Forwarding 3389 publishes the exact service attackers scan for, and does not even work when the site has no public IP. A per-engineer client VPN is heavy to roll out across every depot and still has to route the right subnet at the far end.

One tunnel covers the whole site

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 warehouse never accepts an inbound connection, needs no static IP, and works fine behind carrier-grade NAT. You declare the main LAN, and any separate VLANs the scanners, cameras, or conveyor controls sit on, as subnets on the tunnel, and every device on them becomes reachable with nothing installed on it.

The links you create

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

  • WMS and back-office servers (RDP): a browser RDP session to the Windows server running the WMS or the back-office PC, with no RDP client to launch and port 3389 never exposed to the internet.
  • Label and thermal printers (HTTP): a link to the printer's embedded web page. Networked Zebra printers, for example, serve a ZebraNet print server page over HTTP for checking the queue, network settings, and resetting the unit, so you fix a stalled pack bench without a truck roll.
  • Scanner Wi-Fi access points and controller (HTTPS): a link to the AP or wireless controller web UI to see why the handheld scanners dropped off, without the controller ever facing the internet.
  • Conveyor, sortation, and other controllers (HTTP/HTTPS or TCP): a link to a sortation or conveyor controller's web interface, or a TCP link where you need the native tool. TCP and UDP links are tied to the tunnel for security and must have one.
  • Cameras, NVR, switch and router: links to the NVR or camera web UI over the dock doors, HTTPS to the switch and firewall UIs, and browser SSH to the switch, over the same tunnel.

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 sites, so each warehouse is a client group, your engineers are granted only the depots they look after, and peer isolation keeps every customer's traffic separate at the network layer. An engineer opens ProxyLink, clicks the site's WMS 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 server.

The WMS server, the printers, and the scanner infrastructure keep zero open inbound ports and stay invisible to the internet scans ransomware relies on. Traffic runs over open WireGuard, with the relay hosted in the EU on German infrastructure and no third-party routing. One tunnel per site replaces a tangle of per-device port forwards and per-machine remote tools with one outbound link that covers the whole warehouse.

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.

ProxyLink is free during Early Access

One WireGuard tunnel on a router gives you browser RDP, VNC, and SSH to every device on the LAN. No agent on the target. No credit card. No trial countdown.

Get free access →
← Back to all posts